SP1 and USP changes Audit

Scope

OpenZeppelin performed a diff audit of the across-protocol/contracts repository at the 7e425d2 commit against the base commit 9fd82a4.

In scope were the changes made to the following files:

 contracts/
├── SpokePool.sol
└── sp1-helios/
    ├── SP1AutoVerifier.sol
    └── SP1Helios.sol

Update: All resolutions and the final state of the audited codebase mentioned in this report are contained at commit 0c05cb2.

System Overview

Across Protocol is a cross-chain bridge in which relayers fill user intents on destination chains and are later reimbursed from HubPool-managed liquidity on Ethereum. The protocol’s core contracts include HubPool and chain-local SpokePools, with additional adapter and proof-verification components for cross-chain administration and message execution.

The following in-scope changes are relevant to the Tron migration:

• SP1Helios compatibility updates: compiler target has been adjusted to ^0.8.25 and require(..., CustomError(...)) patterns were refactored to explicit if (...) revert ... checks, preserving behavior while aligning with the selected toolchain/profile.
• SP1AutoVerifier added: a testing-only no-op implementation of ISP1Verifier that accepts any proof, enabling SP1Helios integration testing without real ZK proof verification.
• SpokePool minor refactor: contract-detection checks switched to AddressLibUpgradeable.isContract(...) call sites, with no intended business-logic change.

Overall, this commit range does not introduce new bridge flows and it introduces adjustments that support Tron deployment workflows.

Tron Migration Considerations

Due to differences between the Tron blockchain and typical EVM chains, the following migration considerations should be accounted for during deployment and future development:

• Address representation differs from Ethereum: Tron hex addresses use a 41 prefix (and user-facing Base58Check addresses start with T). Interop code must normalize this when converting to 20-byte EVM-style ABI addresses.
• CREATE2 semantics differ at TVM level: TVM uses 0x41 in CREATE2 address derivation. Any manual CREATE2 address-prediction logic must account for this.
• Native precision differs: TRX uses 6 decimals (1 TRX = 1,000,000 sun), not 18. Any msg.value/fee accounting must be treated as sun units.
• Standard TRX transfers bypass fallback/receive: On Tron, a native transfer sent via TransferContract is handled by balance-accounting logic (not TVM execution), so contract receive/fallback is not invoked. These handlers are only reached through contract-execution paths, such as TriggerSmartContract or contract-to-contract CALL.
• Runtime environment deltas: TVM uses Energy/Bandwidth (not EVM gas market semantics) and has opcode/precompile differences that can matter when contracts rely on EVM-specific behavior.

Security Model and Trust Assumptions

Throughout the audit, the following trust assumptions have been made: - Verifier correctness: Security of cross-chain message verification depends on the correctness of the external verifier configured in SP1Helios; because the current SP1AutoVerifier is a no-op test verifier that accepts arbitrary proofs, production security assumes it is replaced before launch with the correct SP1 verifier and matching vkey configuration. - Privileged role honesty: Throughout the audit, we assumed privileged entities (including holders of VKEY_UPDATER_ROLE and STATE_UPDATER_ROLE in SP1Helios) act honestly and in the best interest of the protocol and its users. - Light-client liveness: Security assumes at least one honest updater continues submitting updates frequently enough to keep SP1Helios within its MAX_SLOT_AGE window. - Deployment/configuration correctness: Security assumes cross-chain configuration is correct and consistent, including source-chain/genesis alignment, hubPoolStore, helios, and wrapped-native-token addresses.

Privileged Roles

In the scope being audited, no additional privileged roles have been introduced.

Notes & Additional Information

Mutability Mismatch in SP1AutoVerifier.verifyProof

In SP1AutoVerifier.sol, verifyProof is declared external pure, while the imported interface in lib/sp1-contracts/contracts/src/ISP1Verifier.sol declares the same function as external view. There is a mutability mismatch between the concrete implementation and the interface contract surface.

Consider aligning the implementation with the interface by changing verifyProof to external view, or documenting that the stricter pure override is intentional for this no-op verifier. This removes unnecessary ambiguity and keeps the verifier surface consistent.

Update: Resolved in pull request #1376 at commit 0c05cb2. A comment explaining the stricter override has been added. 

Conclusion

This diff audit reviewed a limited set of Tron-migration-related changes to SP1Helios, the addition of SP1AutoVerifier, and minor compatibility refactors in SpokePool. The audited modifications are narrow in scope and do not materially expand the protocol’s attack surface.

No notable issues were identified in the in-scope changes. Overall, the implementation is clean and focused; the primary security dependencies are operational controls, especially production verifier replacement, role governance, and correct Tron-specific deployment and configuration.

We would like to thank the Across team for their cooperation and responsiveness throughout the audit.

Appendix

Issue Classification

OpenZeppelin classifies smart contract vulnerabilities on a 5-level scale:

• Critical
• High
• Medium
• Low
• Note/Information

Critical Severity

This classification is applied when the issue’s impact is catastrophic, threatening extensive damage to the client's reputation and/or causing severe financial loss to the client or users. The likelihood of exploitation can be high, warranting a swift response. Critical issues typically involve significant risks such as the permanent loss or locking of a large volume of users' sensitive assets or the failure of core system functionalities without viable mitigations. These issues demand immediate attention due to their potential to compromise system integrity or user trust significantly.

High Severity

These issues are characterized by the potential to substantially impact the client’s reputation and/or result in considerable financial losses. The likelihood of exploitation is significant, warranting a swift response. Such issues might include temporary loss or locking of a significant number of users' sensitive assets or disruptions to critical system functionalities, albeit with potential, yet limited, mitigations available. The emphasis is on the significant but not always catastrophic effects on system operation or asset security, necessitating prompt and effective remediation.

Medium Severity

Issues classified as being of medium severity can lead to a noticeable negative impact on the client's reputation and/or moderate financial losses. Such issues, if left unattended, have a moderate likelihood of being exploited or may cause unwanted side effects in the system. These issues are typically confined to a smaller subset of users' sensitive assets or might involve deviations from the specified system design that, while not directly financial in nature, compromise system integrity or user experience. The focus here is on issues that pose a real but contained risk, warranting timely attention to prevent escalation.

Low Severity

Low-severity issues are those that have a low impact on the client's operations and/or reputation. These issues may represent minor risks or inefficiencies to the client's specific business model. They are identified as areas for improvement that, while not urgent, could enhance the security and quality of the codebase if addressed.

Notes & Additional Information Severity

This category is reserved for issues that, despite having a minimal impact, are still important to resolve. Addressing these issues contributes to the overall security posture and code quality improvement but does not require immediate action. It reflects a commitment to maintaining high standards and continuous improvement, even in areas that do not pose immediate risks.