Push Chain

We express our gratitude to the PushChain team for the collaborative engagement that enabled the execution of this Blockchain Protocol Security Assessment.

Push Chain is a shared-state Layer 1 that brings together Cosmos-style blockchain infrastructure with full Ethereum app compatibility, so developers can build in familiar tools while the chain coordinates activity across networks. Rather than connecting chains one bridge at a time, Push acts as a central hub where cross-chain actions are observed, agreed on, and executed—enabling universal applications that can reach users and assets on many chains from one place.

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

{FindingsVulnSeverityStatusTable}

Documentation quality

• The root readme.md provides a concise product overview, environment prerequisites, local network startup guidance, and a repository layout. It does not articulate functional requirements, explicit security assumptions, or normative guarantees for cross-chain execution paths.

• Documentation for the custom modules (x/uexecutor, x/uregistry, x/uvalidator, x/utss) is largely introductory. It does not systematically document message lifecycles, failure and recovery behavior, voting or quorum semantics, or administrative control boundaries to a level typically expected for independent protocol review.

• A consolidated technical specification covering trust model, finality and confirmation policy, upgrade authority, and state-transition invariants—is not present as a standalone deliverable. Protocol behavior is inferred primarily from source code and protobuf definitions the latter describe data shapes but do not substitute for a full protocol specification. chain_metadata.json includes placeholder or non-specific external references, which is consistent with metadata that has not been finalized for production publication.

Code quality

• The implementation builds on established Cosmos SDK and Cosmos EVM components in a conventional manner. Push-specific EVM system contracts are integrated using widely used proxy patterns, with contract bytecode embedded in the registry module rather than distributed as a separately versioned contract package.

• Some module scaffolding remains (for example unwired or placeholder migrations and example chain metadata). If activated or merged without additional review, such artifacts can increase operational and maintenance risk.

• The universal modules and Universal Client introduce substantial custom logic. Cross-cutting concerns including hash normalization, ballot or observation identity, and oracle-related updates—are not uniformly enforced across all components, which can complicate reasoning about end-to-end behavior.

• The repository provides a workable development setup: Makefile, Docker-oriented tooling, local and testnet-oriented scripts, and stated prerequisites (Go 1.23+, Docker, jq).

Architecture quality

• Scalability: The network is implemented as a single CometBFT-based L1 without sharding. Capacity is bounded by block limits, EVM execution cost, and off-chain operator throughput. Certain on-chain bookkeeping paths rely on linear scans over growing state, which may become a scaling consideration as history accumulates.

• Decentralization: Consensus follows a standard validator model. Cross-chain operation additionally depends on a distinct universal-validator role, registry-defined routing and asset policy, and EVM-layer upgrade control for system contracts. Together, these introduce administrative and operational trust assumptions beyond the base staking layer.

• Interoperability: The design targets interoperability via IBC, EVM interfaces, CosmWasm, and hub-style connectivity to external EVM and Solana networks through Universal Client. Cross-chain settlement is attestation-based and configuration-dependent rather than light-client–verified on a per-event basis.

• Resilience: End-to-end resilience of cross-chain flows is not fully evidenced by the reviewed materials. Operational availability depends on Universal Client processes, external RPC reliability, and alignment between staking-derived validator state and universal-validator registry state. EVM system-contract upgrade authority represents a concentrated dependency in the overall architecture.

Push Chain is a Cosmos SDK Layer 1 on CometBFT with native EVM and CosmWasm support. The node binary is pchaind the native token is upc. Alongside standard Cosmos, EVM, IBC, and token-factory modules, the chain adds four custom modules for universal cross-chain apps: registry, validator voting, on-chain execution, and threshold-signing coordination.

External chains connect through a hub model: operators run puniversald to observe events, validators vote them into consensus, Push executes the workflow (including EVM), and signed transactions complete actions on destination chains. Selected user and validator transactions can be processed without gas fees when they use only approved message types.

Custom Modules

• Universal Client (universalClient ) Off-chain service run by universal validators alongside pchaind. Watches external chains (EVM and Solana), submits vote transactions to Push, and collectively signs outbound transactions via threshold cryptography so no single operator holds full signing authority. Persists the chain-specific state locally and coordinates TSS sessions between validators.

• Universal Registry (x/uregistry) Defines which external chains, tokens, and gateways Push recognizes. Administrators manage this configuration; execution modules reject operations on unsupported or disabled routes.

• Universal Validator (x/uvalidator) Maintains the universal validator set and runs ballot voting on cross-chain observations. When enough validators agree, results are passed to the executor and TSS modules.

• Universal Executor (x/uexecutor) Runs universal workflows on Push: processing inbounds from other chains, tracking transaction status, executing user payloads, and handling outbounds. Integrates with the EVM layer for contracts and account logic.

• Universal TSS (x/utss) Coordinates threshold signing and fund migration when validator keys rotate. On-chain votes align with off-chain signing performed by Universal Client operators.

EVM Precompiles

Push extends the standard EVM precompile set so Solidity can call into Cosmos: bech32, p256, staking, distribution, IBC transfer, bank, gov, slashing, and evidence.

Push also adds usigverifier, which lets contracts verify signatures from supported external chains (e.g. Ed25519).

The scope of the project includes the following components from the provided repository:

Assets in Scope