Q1 2026 Security & Compliance Report44 incidents, $482M in losses, insights from 11 industry leaders.
Read the report
Push Chain logo

Push Chain

Audit name:

[SCA] Push Chain | SVM Gateway | Mar2026

Date:

Apr 24, 2026

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

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 Solana-side bridge gateway that locks user deposits in a PDA-controlled vault and releases them via TSS-signed outbound operations (withdraw, execute, revert, rescue), enabling bidirectional asset and payload bridging between Solana and Push Chain.

Document

NameSmart Contract Code Review and Security Analysis Report for Push Chain
Audited ByFelipe Donato, Seher Saylik
Approved ByIvan Bondar
Websitehttps://push.org→
Changelog10/04/2026 - Preliminary Report
19/05/2026 - Final Report
PlatformSVM
LanguageRust
TagsBridge, Cross-chain, Vault
Methodologyhttps://docs.hacken.io/methodologies/smart-contracts→

Review Scope

Repositoryhttps://github.com/pushchain/push-chain-gateway-contracts/tree/audit-main/contracts/svm-gateway→
Commit93db3c8e66cc1399ee74fc58339440e78321ae06

Audit Summary

18Total Findings
14Resolved
2Accepted
2Mitigated

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

Documentation quality

  • Functional requirements are provided.

  • Technical description is provided.

Code quality

  • Some compute-inefficient patterns were identified, such as redundant oracle calls or redundant validations.

  • The development environment is configured.

Test coverage

Code coverage of the project is 95.4% (line coverage).

  • Deployment, initialization, and admin configuration flows are fully covered.

  • Positive and negative cases are covered across deposit, withdraw, revert, and rescue paths, including replay protection, pause enforcement, zero-amount rejection, and insufficient balance checks.

  • Multi-user interactions involving SPL token deposits into non-canonical vault accounts are covered via PoC tests.

  • Execute-mode CPI paths with TSS signature verification are covered through the test-counter integration tests.

  • Uncovered lines (4.6%) are primarily error branches in initialize.rs and edge cases in pricing.rs and validation.rs.

System Overview

The Push Chain SVM Gateway is the Solana-side bridge gateway for asset movement between Solana and Push Chain. It accepts inbound deposits on Solana, escrows assets under protocol-controlled accounts, and later processes outbound withdrawals, finalize operations, reverts, and rescues based on TSS authorization.

Architecture

The gateway maintains two core custody accounts:

  • Vault (vault_sol) holds bridged native SOL and serves as the authority for SPL token vault accounts.

  • Fee Vault (fee_vault) holds protocol fees collected from inbound deposits and is intended to fund relayer reimbursements without consuming bridge collateral.

Additional protocol state includes:

  • Config: stores admin and pauser authorities, pause state, protocol fee settings, USD cap parameters, and Pyth oracle configuration.

  • TssPda: stores the active TSS Ethereum address and chain ID used for secp256k1 verification on outbound operations.

  • CEA: a per-user PDA used as a persistent execution identity for outbound CPI and staged execution flows.

  • ExecutedSubTx: replay-protection state keyed by sub_tx_id.

  • RateLimitConfig: stores the per-slot USD cap and epoch duration for inbound rate limiting.

  • TokenRateLimit: stores per-token epoch-based rate-limit state.

Inbound Flow

Users initiate deposits through send_universal_tx. The gateway collects the protocol fee, classifies the request by route type, applies route-specific controls, transfers assets into protocol custody, and emits a UniversalTx event for downstream processing.

  • GAS / GAS_AND_PAYLOAD: native SOL route with USD-denominated checks using the configured Pyth SOL/USD feed.

  • FUNDS / FUNDS_AND_PAYLOAD: standard bridge route for native SOL or SPL tokens with token-based epoch rate limiting.

Outbound Flow

All outbound operations require a valid TSS secp256k1 signature. The gateway supports four outbound paths:

  • Withdraw (withdraw) releases assets from protocol custody to a Solana recipient.

  • Finalize (finalize_universal_tx) stages assets to a user-specific CEA, then transfers, executes CPI, or routes assets back into the gateway.

  • Revert (revert_universal_tx) returns assets when a cross-chain operation must be canceled or rolled back.

  • Rescue (rescue_funds) provides an operator-controlled recovery path for exceptional cases.

Privileged Roles

The admin (config.admin) holds the highest privilege. It can update the TSS address, rotate admin and pauser authorities, configure the Pyth oracle feed, set USD caps and rate limits, set the protocol fee, and pause or unpause the gateway. All admin actions take effect immediately with no timelock.

The pauser (config.pauser) can pause and unpause the gateway. The admin can also pause and unpause, meaning the pauser cannot enforce a pause against the admin's will.

The TSS is the sole authorization mechanism for all outbound operations. It produces ECDSA secp256k1 signatures verified on-chain. No funds can leave the vault without a valid TSS signature.

Potential Risks

TSS Compromise: The TSS threshold signature scheme is the sole authorization mechanism for all outbound fund releases (withdraw, execute, revert, rescue). A compromised TSS can drain the entire vault.

Off-Chain Liveness Dependency: Users who deposit funds via senduniversaltx have no on-chain mechanism to cancel or reclaim their deposit if the off-chain infrastructure (Universal Validators, TSS) becomes unresponsive.

Oracle Dependency: Inbound gas route deposits rely on a single Pyth SOL/USD price feed for USD cap enforcement. If the Pyth feed becomes unavailable, stale, or manipulated, all gas route deposits are either blocked or processed with incorrect price data.

Upgradeable Program: The program is upgradeable via the Solana upgrade authority. A compromised upgrade authority can replace the program logic entirely, overriding all on-chain security controls including TSS verification and replay protection.

Centralization Risk: All privileged operations (authority rotation, TSS update, oracle swap, rate limit configuration, pause/unpause) are controlled by a single admin signer with no timelock, multisig enforcement, or two-step transfer. A compromised admin key can reconfigure the entire protocol in a single block.

Off-Chain Token Whitelisting Assumption: If the protocol opts for off-chain validation of token mint authorities instead of on-chain enforcement, the security of vault-held SPL tokens depends on an operational trust assumption outside the audit scope. Tokens with active freeze or mint authorities carry risks described in findings section.

Findings

Code
―
Title
Status
Severity
F-2026-1575Inconsistent Pause Constraints Across Admin Functions
fixed

Medium
F-2026-1570Missing Canonical ATA Enforcement on Vault Token Accounts Causes SPL Liquidity Fragmentation
fixed

Medium
F-2026-1569Insufficient Privilege Separation in PauseAction Allows Pauser to Unpause the Gateway
fixed

Medium
F-2026-1569Unsigned revert_msg Allows Forged Revert Data in Cross-Chain Events
fixed

Medium
F-2026-1567Missing Per-Slot USD Cap in FUNDS Route Leads To Uncontrolled Deposit Throughput
accepted

Medium
F-2026-1562Wrong Gas Fee Reimbursement Source In finalizeuniversaltx Breaks The 1:1 Backing Invariant
mitigated

Medium
F-2026-1570limit_threshold = 0 Causes Token-Level DoS Instead of Disabling Rate Limiting
fixed

Low
F-2026-1569settokenrate_limit Unconditionally Resets Epoch Usage on Threshold Update
fixed

Low
F-2026-1562Excessive Pyth Oracle Staleness Window Enables Rate Limit Bypass
fixed

Low
F-2026-1595Missing Mint Authority Validation in settokenrate_limit Allows Whitelisting Tokens with Unsafe Authorities
fixed

Observation
1-10 of 18 findings

Identify vulnerabilities in your smart contracts.

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

Repositoryhttps://github.com/pushchain/push-chain-gateway-contracts/tree/audit-main/contracts/svm-gateway→
Commit93db3c8e66cc1399ee74fc58339440e78321ae06
Final commit0a0c9c1030196c73ff16712f0642f4f87ffd7a37
WhitepaperN/A
Requirementshttps://www.notion.so/pushprotocol/SVM_Crucial_Checks-335188aea7f480bebd07ebb8a8e592f6?source=copy_link→
Technical Requirementscontracts/svm-gateway/README.md

Assets in Scope

admin.rs - admin.rs
deposit.rs - deposit.rs
encoding.rs - encoding.rs
errors.rs - errors.rs
execute.rs - execute.rs
initialize.rs - initialize.rs
lib.rs - lib.rs
mod.rs - mod.rs
pricing.rs - pricing.rs
rate_limit.rs - rate_limit.rs
rescue.rs - rescue.rs
revert.rs - revert.rs
state.rs - state.rs
transfers.rs - transfers.rs
tss.rs - tss.rs
validation.rs - validation.rs
withdraw.rs - withdraw.rs

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.

Disclaimer