Push Chain

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 Gateway is a cross-chain interoperability protocol that bridges funds and payloads between external EVM chains and Push Chain. The protocol uses a TSS (Threshold Signature Scheme) relayer network to finalize transactions across chains.

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

• The project provides comprehensive documentation covering architecture, transaction flows, and security analysis. High-level architecture is described in 1_PUSH_CHAIN.md with clear actor definitions and component relationships.

• Per-contract documentation (2_UniversalGateway.md, 3_UniversalGatewayPC.md) includes TXTYPE inference tables, rate-limit mechanics, fee models with worked examples, and sequence diagrams. Full outbound and inbound transaction flow documentation is provided in **4OutboundTxFlows.md** (covering all four categories: withdrawals, DeFi execution, CEA self-calls, and reverts with Mermaid sequence diagrams for each variant) and **5InboundTx_Flows.md**. Revert handling, threat modelling, and upgrade plans are documented separately.

• NatSpec comments are present on most public and internal functions. Minor inconsistencies exist: the IUniversalCore interface in the gateway declares BASE_GAS_LIMIT() which does not exist on the actual UniversalCore implementation, and some line references in documentation do not match current code after remediation commits.

Code quality

• The codebase properly reuses OpenZeppelin upgradeable libraries for access control, pausability, reentrancy protection, and safe ERC-20 operations.

• Code duplication exists in both UniversalGateway and Vault, where identical transfer logic is copy-pasted with only the emitted event name differing.

• Function naming and visibility conventions are inconsistent Mutable state variables use CONSTANT-style ALL_CAPS naming across all contracts.

• The development environment is fully configured with Foundry, including profiles for CI, coverage, debugging, and fork testing.

Test coverage

Code coverage of the project is  76.61% (branch coverage).

• Tests cover admin actions, all four transaction types (GAS, GAS_AND_PAYLOAD, FUNDS, FUNDS_AND_PAYLOAD), rate limiting (block-based and epoch-based), oracle integration, protocol fees, CEA-based inbound flows (58 tests), rescue operations, vault withdrawals, and vault token migration.

• Fuzz tests are provided for protocol fee collection, rate limits, transaction routing, and vault invariants. The primary coverage gap is in UniversalGateway.sol branch coverage (70%) — uncovered branches include edge cases in Uniswap v3 pool discovery, concurrent multi-user rate-limit exhaustion, and certain L2 sequencer oracle failure paths.

Push Chain Gateway is a cross-chain interoperability protocol that bridges funds and payloads between external EVM chains and Push Chain. The protocol uses a TSS (Threshold Signature Scheme) relayer network to finalize transactions across chains. The following contracts are in scope:

• UniversalGateway — the primary inbound gateway deployed on external EVM chains (e.g., Ethereum, Arbitrum). It accepts user deposits of native ETH or whitelisted ERC-20 tokens and routes them to Push Chain. Supports four transaction types: pure gas top-ups, gas with payload execution, large-ticket fund transfers, and fund transfers with payload. Enforces per-transaction USD caps and per-block USD caps (via Chainlink ETH/USD oracle) for the instant gas route, and epoch-based per-token rate limits for the standard fund route. Supports ERC-20-to-native gas abstraction via Uniswap V3 swaps. Collects a flat native protocol fee on each inbound transaction. Provides revert and rescue paths for failed cross-chain transactions, callable only by the Vault. Uses OpenZeppelin UUPS-compatible upgradeability, access control (admin, TSS, Vault, pauser roles), pausability, and reentrancy guards.

• Vault — the ERC-20 custody contract on external EVM chains. Holds bridged tokens and releases them on the destination chain upon TSS instruction. Routes all outbound executions through deterministic Chain Execution Accounts (CEAs) deployed via a factory. Supports three outbound operations: finalize (withdraw or execute via CEA), revert (refund failed inbound transactions), and rescue (recover stuck funds). All state-changing operations are restricted to the TSS role. Uses OpenZeppelin upgradeability, access control, pausability, and reentrancy guards.

• UniversalGatewayPC — the outbound gateway deployed on Push Chain. Handles user-initiated transactions from Push Chain to external EVM chains. Burns PRC-20 synthetic tokens at request time, collects a protocol fee in native PC sent to VaultPC, and swaps remaining native PC to gas tokens via UniversalCore for cross-chain execution costs. Supports three outbound transaction types: funds only, funds with payload, and payload with gas. Also provides a rescue-funds flow for requesting release of stuck tokens on external chains. Uses OpenZeppelin upgradeability, access control, pausability, and reentrancy guards.

• VaultPC — a simple fee custody vault deployed on Push Chain. Stores protocol fees collected from outbound transactions. Supports withdrawal of both native PC and PRC-20 tokens by a designated manager role. Uses OpenZeppelin upgradeability, access control, pausability, and reentrancy guards.

• Types — shared library defining the transaction type enum (GAS, GASANDPAYLOAD, FUNDS, FUNDSANDPAYLOAD, RESCUE_FUNDS), revert instruction struct, multicall struct for CEA execution, packed epoch-usage struct for rate limiting, and signature verification types.

• TypesUG — defines the inbound request structs for UniversalGateway: a standard request (native gas) and a token-gas request (ERC-20 gas with Uniswap swap parameters).

• TypesUGPC — defines the outbound request struct for UniversalGatewayPC, including recipient (raw bytes for cross-VM compatibility), PRC-20 token, amount, gas limit, payload, and revert recipient.

• Errors — shared custom error library used across all gateway and vault contracts. Defines common validation errors and domain-specific errors for deposits, withdrawals, rate limiting, slippage, and token burns.

Privileged roles

• The DEFAULT_ADMIN_ROLE holder in the UniversalGateway contract can update all critical protocol parameters including the TSS address (via updateTSS), the Vault address (via updateVault, which also transfers VAULT_ROLE), USD rate-limit caps, the per-block USD cap, Uniswap V3 router and factory addresses, Chainlink oracle feed addresses and staleness thresholds, L2 sequencer feed and grace period, the CEA factory address, the protocol fee amount, token whitelist and rate-limit thresholds, and the epoch duration. Changing these parameters takes effect immediately without a timelock or delay.

• The DEFAULT_ADMIN_ROLE holder in the Vault contract can update the gateway address (via setGateway), the CEA factory address (via setCEAFactory), and migrate all token balances (ERC20 and native) to a new vault (via migrateTokens, which requires both the Vault and Gateway to be paused). These changes take effect immediately.

• The DEFAULT_ADMIN_ROLE holder in the UniversalGatewayPC contract can update the VaultPC address (via setVaultPC) and the UniversalCore address (via setUniversalCore). These changes take effect immediately.

• The DEFAULT_ADMIN_ROLE holder in the VaultPC contract has no protocol-specific configuration setters beyond granting and revoking other roles.

• Across all four contracts, the DEFAULTADMINROLE holder can grant and revoke any other role, including granting the admin role itself to other addresses.

• The TSS_ROLE holder in the Vault contract is the sole authority that can finalize outbound transactions (releasing funds to users on external chains via CEA contracts), revert failed inbound transactions (returning funds to the original sender via the Gateway), and rescue stuck funds. All fund movement from the Vault to end users passes through this role.

• Note: TSSROLE is **not defined** in the UniversalGateway contract. The Gateway tracks a `TSSADDRESS` state variable that serves as the recipient for native fees and deposits, but TSS-related authorization for outbound operations is enforced exclusively in the Vault contract. The previous TSS_ROLE in UniversalGateway was removed as it was not used for any access control check.

• The VAULT_ROLE holder in the UniversalGateway contract is the only address authorized to trigger revert and rescue operations on the gateway. In practice, this role is assigned to the Vault contract, allowing it to route refund and rescue flows through the gateway's replay-protected transfer logic.

• The PAUSER_ROLE holder can pause and unpause the respective contract. When paused, all user-facing operations (deposits, outbound transactions, finalizations, reverts, rescues) are halted. This role exists in all four contracts: UniversalGateway, Vault, UniversalGatewayPC, and VaultPC.

• The MANAGER_ROLE holder in the VaultPC contract can withdraw any amount of native PC tokens or PRC-20 tokens from the fee vault to any address. This role has full custody authority over all fees accumulated in VaultPC.

The scope of the project includes the following smart contracts from the provided repository:

Assets in Scope