- Hacken
- Audits
- push-chain
- [SCA] Push Chain | Core Contracts | Mar2026
Audit name:
[SCA] Push Chain | Core Contracts | Mar2026
Date:
Apr 13, 2026
Table of Content
Introduction
We express our gratitude to the Push Chain team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Push Chain is a fully EVM-compatible Proof-of-Stake Layer 1 blockchain designed to enable universal application deployment. It allows developers to deploy a Solidity-based smart contract once on Push Chain, while enabling users from multiple blockchain networks to interact with it using their existing wallets.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Push Chain |
| Audited By | Olesia Bilenka; Kornel Światłowski |
| Approved By | Ivan Bondar |
| Website | https://push.org→ |
| Changelog | 31/03/2026 - Preliminary Report |
| 14/05/2026 - Remediation Report | |
| 27/05/2026 - Post Audit Changes | |
| Platform | Push Chain, Ethereum, Solana |
| Language | Solidity |
| Tags | ERC20, Signatures, Factory, Bridge |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Push Chain
- Audited By
- Olesia Bilenka; Kornel Światłowski
- Approved By
- Ivan Bondar
- Website
- https://push.org→
- Changelog
- 31/03/2026 - Preliminary Report
- 14/05/2026 - Remediation Report
- 27/05/2026 - Post Audit Changes
- Platform
- Push Chain, Ethereum, Solana
- Language
- Solidity
- Tags
- ERC20, Signatures, Factory, Bridge
Review Scope | |
|---|---|
| Repository | https://github.com/pushchain/push-chain-core-contracts/tree/audit-main→ |
| Commit | 15b70544feba1586f488a90e38650bf33ea3c634 |
| Remediation commit | daf74825d22121896964e2d542201e623c4e994c |
| Post Audit Changes | a2b61850d765679aa9e1e39998a47a348404bc08 |
Review Scope
- Commit
- 15b70544feba1586f488a90e38650bf33ea3c634
- Remediation commit
- daf74825d22121896964e2d542201e623c4e994c
- Post Audit Changes
- a2b61850d765679aa9e1e39998a47a348404bc08
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided via markdown documentation (docs/) covering architecture overview, UEA/CEA flows, migration mechanics, and threat modelling.
Technical description is provided at a high level. Low-level implementation details (storage layout, upgrade invariants, exact encoding rules) are not documented.
Code quality
The codebase uses OpenZeppelin upgradeable contracts for access control (AccessControlDefaultAdminRulesUpgradeable), pausability (PausableUpgradeable), reentrancy guards (ReentrancyGuardUpgradeable), and proxy patterns (Clones, ERC1967Proxy). Custom implementations are used where protocol-specific logic is required (UEA/CEA proxy storage slots, PRC20 synthetic token, WPC wrapper).
Shared constants and types are properly centralized in Types.sol and Errors.sol. Custom errors are used consistently across all contracts, improving gas efficiency and debuggability.
Role-based access control follows a granular separation pattern: ROLE_MANAGER_ROLE administers operational roles, contract-specific admin roles (UVCORE_ADMIN_ROLE, UEA_ADMIN_ROLE, CEA_ADMIN_ROLE) control configuration, OPERATOR_ROLE manages address setters and unpause operations, and PAUSER_ROLE is restricted to pause-only actions. This design limits the blast radius of a single compromised key.
The development environment is configured with Foundry (forge build/forge test toolchain), Solidity 0.8.26, Shanghai EVM target, and via_ir optimization enabled.
Test coverage
Code coverage of the project is 91.92% (branch coverage).
The test suite includes unit tests, fuzz tests (property-based), fork tests.
Deployment and basic user interactions are well covered.
Proxy initialization edge cases (UEAProxy, CEAProxy) have lower branch coverage (~50–67%).
Cross-contract interaction scenarios (e.g., full UEA→CEA round-trip, migration under concurrent operations) are not tested end-to-end.
System Overview
Push Chain is an EVM-compatible Proof-of-Stake Layer 1 designed for universal app execution across multiple ecosystems. Developers deploy once on Push Chain, while users from different chains interact using their native identities/wallets via protocol-managed execution accounts.
Core Module
UniversalCore.sol is the main protocol coordinator on Push Chain. It manages PRC20 deposit/refund flows, chain gas metadata, supported gas tokens, and swap-and-burn logic through Uniswap-style integrations.
PRC20.sol implements upgradeable synthetic ERC-20 assets representing external-chain tokens. It supports protocol-authorized minting (deposit), user burning, and stores source-chain token metadata plus UniversalCore linkage.
WPC.sol is the wrapped native Push coin contract with standard wrap/unwrap and ERC-20-style transfer/allowance behavior used by core swap paths.
UEA Module Universal Executor Accounts
UEAFactory.sol is the upgradeable factory/registry for UEAs. It maps chain identifiers to VM types, stores UEA implementations, deploys deterministic proxy instances (CREATE2), and controls pause/migration configuration.
UEAProxy.sol is the minimal per-account proxy that stores implementation in a fixed slot and delegates all runtime calls.
UEA_EVM.sol is the EVM UEA implementation. It validates ECDSA universal payloads (with trusted-module bypass path), applies nonce/deadline logic, and executes single-call, multicall, and migration dispatch.
UEA_SVM.sol is the SVM UEA implementation. It mirrors EVM execution flow but verifies Ed25519 signatures through the verifier precompile before dispatching calls.
UEAMigration.sol is the delegatecall-only migration singleton used to update UEA proxy implementation slots (separate targets for EVM/SVM logic).
CEA Module Chain Executor Accounts
CEAFactory.sol is the upgradeable factory for destination-chain CEAs. It deploys deterministic proxy clones, maintains UEA↔CEA mappings, and manages vault/gateway/implementation/pause/migration parameters.
CEAProxy.sol is the lightweight per-account proxy for CEAs with fixed-slot implementation storage.
CEA.sol is the execution logic for CEAs. It is vault-gated, tracks executed tx IDs for replay protection, supports single-call/multicall/migration execution, and exposes outbound universal transaction initiation toward the gateway.
CEAMigration.sol is the delegatecall-only migration singleton that updates CEA proxy implementation slots.
Shared Libraries
Errors.sol centralizes common and module-specific custom errors.
Types.sol defines shared structs/enums/constants (universal account ID, payload formats, multicall entries, selectors, and signing typehashes).
Utils.sol provides utility helpers, including strict decimal-string-to-uint256 conversion (StringUtils).
Privileged roles
UniversalCore.sol
DEFAULT_ADMIN_ROLE: root governance control with 1-day timelock for admin role transfers; can grant/revoke
ROLE_MANAGER_ROLE.ROLE_MANAGER_ROLE: grants operational roles (
UVCORE_ADMIN_ROLE,OPERATOR_ROLE,PAUSER_ROLE); acts as the role admin for all operational roles.UVCORE_ADMIN_ROLE: controls protocol configuration — protocol fees, gas tokens, gas limits, staleness thresholds, fee tiers, auto-swap support, deadline defaults, and native PC rescue.
OPERATOR_ROLE: address setters (
updateWPC,updateUniversalGatewayPC,updateUniswapV3Addresses) andunpause.PAUSER_ROLE: can pause core operational entrypoints, acting as an emergency stop operator.
UNIVERSAL_EXECUTOR_MODULE (hardcoded:
0x14191Ea54B4c176fCf86f51b0FAc7CB1E71Df7d7): executes module-only flows (token deposit, auto-swap, gas refund, chain metadata updates), making it a high-trust execution authority.universalGatewayPC (privileged actor): exclusive caller for gateway burn/swap flow (
swapAndBurnGas), so gateway integrity is a hard dependency.
PRC20.sol
UNIVERSAL_EXECUTOR_MODULE: can update key token-level admin settings (
updateUniversalCore,setName,setSymbol).UNIVERSAL_CORE + UNIVERSAL_EXECUTOR_MODULE (mint authority): both are allowed to mint via deposit path, so issuance trust is shared between these two actors.
UEAFactory.sol
DEFAULT_ADMIN_ROLE: root governance with 1-day timelock; can grant/revoke
ROLE_MANAGER_ROLE.ROLE_MANAGER_ROLE: grants operational roles (
UEA_ADMIN_ROLE,OPERATOR_ROLE,PAUSER_ROLE).UEA_ADMIN_ROLE: controls UEA ecosystem governance — implementation mapping, migration target, chain/VM registration, Push Chain ID; defines what logic UEAs trust over time.
OPERATOR_ROLE: can unpause UEA deployment operations.
PAUSER_ROLE: can pause UEA deployment operations.
UEA_EVM.sol and UEA_SVM.sol
UNIVERSAL_EXECUTOR_MODULE: can execute UEA payloads without user-signature verification path, including migration-triggering payload types; this is a strong delegated execution trust assumption.
CEAFactory.sol
DEFAULT_ADMIN_ROLE: root governance with 1-day timelock; can grant/revoke
ROLE_MANAGER_ROLE.ROLE_MANAGER_ROLE: grants operational roles (
CEA_ADMIN_ROLE,OPERATOR_ROLE,PAUSER_ROLE).CEA_ADMIN_ROLE: controls CEA factory implementation configuration — proxy implementation, logic implementation, migration target.
OPERATOR_ROLE: address setters (
updateVault,updateUniversalGateway) and unpause.PAUSER_ROLE: can pause CEA deployment operations.
VAULT: exclusive deploy caller for
deployCEA, so operational control of vault affects account rollout.
CEA.sol
VAULT: only inbound executor for universal tx handling; vault controls what gets executed on each CEA.
address(this) self-call gate (execution constraint): outbound gateway-send path (
sendUniversalTxToUEA) is intentionally restricted to internal/self-call flows, not arbitrary external callers.
Potential Risks
Critical trust in privileged executor module: A single hardcoded address embedded in bytecode across all core contracts can bypass signature checks, trigger migrations, mint synthetic tokens via privileged paths, and execute arbitrary operations on any user account without consent.
Bridge and Vault integrity dependency: Chain Executor Account execution correctness depends on off-scope relay stack; any compromise there can break message authenticity and execution safety.
External DEX dependency for gas conversion: UniversalCore relies on Uniswap V3 router and pools for fee swaps; liquidity manipulation, pool unavailability, or protocol outage can cause failed or expensive execution.
SVM verifier precompile dependency: UEA_SVM security and liveness depends on chain-specific Ed25519 precompile behavior and availability.
Forced migration and execution capability: The privileged executor module path allows account execution (including migration flow) without user signature consent.
Admin role transfer delay: Factory and core contracts enforce a 1-day delay on root admin role transfers. Operational role changes via the role manager remain immediate.
Gas oracle staleness validation (opt-in): UniversalCore supports per-chain staleness checks for gas data. When configured, outbound fee queries revert if gas data exceeds the configured age. However, this check is opt-in and no hard safety bounds exist on gas price values.
Treasury-like rescue authority: Protocol admin can invoke rescue functions to move protocol-held native assets.
Single hardcoded address controls all protocol-critical privileged paths: The privileged executor module address is embedded in bytecode across UniversalCore, PRC20, UEA_EVM, and UEA_SVM. This single address can mint arbitrary synthetic tokens, execute any operation on any user account without signature, call privileged admin functions on token contracts, and bypass pause states on token minting. There is no enforced separation of duties, multi-signature requirement, or governance mechanism visible in the on-chain contracts. Changing this address requires a full contract redeployment or proxy implementation upgrade.
Factory admin controls account deployments and upgrades: The role manager on UEAFactory and CEAFactory can grant operational admin roles, which control implementation addresses, proxy templates, migration contracts, and chain registrations. Role separation mitigates single-key compromise, but the role manager remains a single point of trust for granting operational roles.
Delegatecall migration trust model: Proxy upgrade path depends on migration contracts writing storage correctly; malicious or buggy migration logic can cause systemic damage to all affected accounts.
Limited review window for operational changes: While root admin role transfers have a 1-day delay, operational configuration changes via granular roles are effective immediately, reducing reaction time for users and integrators.
Version fragmentation: Updates at factory level do not automatically patch already deployed account proxies; existing accounts remain on their original implementation until explicitly migrated.
Liveness tied to relayer and infrastructure health: Downtime of privileged executor module, Vault, or bridge relay components can halt cross-chain execution flows.
Stale configuration risk: Delayed operational updates (e.g., gas pricing) may lead to incorrect fee behavior. The opt-in staleness check mitigates this when configured, but chains without staleness limits set remain vulnerable to stale quotes.
Potential state divergence: No strong on-chain reconciliation guarantee that Push-side intent and destination-side execution always stay synchronized.
Address and configuration drift over time: Factory-level configuration changes can create operational mismatch between expected and active deployment parameters across chains.
Report Modification Notice: This report was modified on May 27th, 2026, at the client’s request to incorporate minor code changes introduced up to commit a2b6185. While these updates were intended to align the report with the latest version of the codebase provided by the client, modifications to previously published audit content may affect the continuity and integrity of the original findings. Hacken reviewed the updated changes to confirm that they correspond solely to the requested modifications. However, any future changes involving substantial code updates or additional commits should undergo a separate security assessment to ensure that no new risks are introduced to the project’s security posture.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1556 | ERC-20 Return Path Missing Token Approval Despite Documentation Requirement | fixed | High | |
| F-2026-1556 | Domain Separator Omits Push Chain Network Identifier, Enabling Cross-Deployment Signature Replay | fixed | Medium | |
| F-2026-1556 | SVM Domain Separator Encodes chainId Incorrectly Relative to EIP-712 | fixed | Medium | |
| F-2026-1556 | CEA Migration Path Does Not Enforce Self-Targeting Semantics | fixed | Medium | |
| F-2026-1551 | defaultDeadlineMins Default Value Is Not Initialized in Proxy Storage | fixed | Medium | |
| F-2026-1561 | Absence of Granular Role Separation | fixed | Low | |
| F-2026-1559 | UEA migration can be triggered by UNIVERSALEXECUTORMODULE without user signature/consent | accepted | Low | |
| F-2026-1558 | PRC20 Direct Mint Path Bypasses UniversalCore Pause | fixed | Low | |
| F-2026-1558 | VerificationType field is signed but never enforced on-chain | accepted | Low | |
| F-2026-1556 | Single-Call Execution Uses Implicit Dual Semantics for Value Handling | mitigated | Low |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/pushchain/push-chain-core-contracts/tree/audit-main→ |
| Commit | 15b70544feba1586f488a90e38650bf33ea3c634 |
| Remediation commit | daf74825d22121896964e2d542201e623c4e994c |
| Post Audit Changes | a2b61850d765679aa9e1e39998a47a348404bc08 |
| Whitepaper | - |
| Requirements | https://github.com/pushchain/push-chain-core-contracts/tree/15b70544feba1586f488a90e38650bf33ea3c634/docs→ |
| Technical Requirements | https://github.com/pushchain/push-chain-core-contracts/tree/15b70544feba1586f488a90e38650bf33ea3c634/docs→ |
Scope Details
- Commit
- 15b70544feba1586f488a90e38650bf33ea3c634
- Remediation commit
- daf74825d22121896964e2d542201e623c4e994c
- Post Audit Changes
- a2b61850d765679aa9e1e39998a47a348404bc08
- Whitepaper
- -
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.