Apex Q1 2025 Reactor & Skyline Critical Path Audit Report Final

Security Audit Report

Apex Q1 2025: Reactor and Skyline critical path

Last revised 01.05.2025

Contents Audit overview 5 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Audit Dashboard 7 Target Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Engagement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Severity Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

System Overview 8 Reactor bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Skyline bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Threat Model 13 Property BSC-01: if a sender submits a bridging request, the funds must eventually be either received on the destination or refunded to the sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Property BSC-02: claims and batches must be processed only for registered chains . . . . . . . . . . . . . 13 Property BSC-03: bridging request claims can only be submitted by trusted oracles . . . . . . . . . . . . 14 Property BSC-04: a bridging request claim will be processed if and only if a quorum of validators have signed over it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Property BSC-05: every confirmed bridging request claim must eventually enter a batch . . . . . . . . . . 15 Property BSC-06: no confirmed bridging request claim is included in more than one batch . . . . . . . . . 15 Property BSC-07: confirmed bridging request claims remain stored on the bridge until a batch transaction either succeeds or fails on the destination chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Property BSC-08: batches can only be submitted by trusted batchers . . . . . . . . . . . . . . . . . . . . 16 Property BSC-09: batch executed claims can only be submitted by trusted oracles . . . . . . . . . . . . . 17 Property BSC-10: failed batch claims can only be submitted by trusted oracles . . . . . . . . . . . . . . . 17 Property BSC-11: for any given batch, all batchers must include the same set of confirmed transactions . 17 Property BSC-12: a batch will never be relayed to the destination if a quorum of validators have not signed over it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Property BSC-13: a batch will eventually be relayed if and only if a quorum of validators have signed over it 18 Property BSC-14: for every confirmed batch, the bridge must eventually process either a batch executed claim or a batch execution failed claim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Property BSC-15: there must be at most 1 in-flight batch per destination chain . . . . . . . . . . . . . . . 19 Property BSC-16: a batch execution failed claim will be processed if and only if a quorum of validators have signed over it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Property BSC-17: for any batch that does not successfully execute on the destination chain, at most one failed batch claim must be processed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Property BSC-18: refund request claims can only be submitted by trusted oracles . . . . . . . . . . . . . 20 Property BSC-19: a refund request claim will be processed if and only if a quorum of validators have signed over it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Property BSC-20: for any batch that does not successfully execute on the destination chain, at most one refund request claim must be processed for each bridging request included in the batch . . . . . . . . 21 Property BSC-21: hot wallet increment claims can only be submitted by trusted oracles . . . . . . . . . . 22 Property BSC-22: a hot wallet increment claim will be processed if and only if a quorum of validators have signed over it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Property BSC-23: only the fund admin is authorized to execute a hot wallet defund transaction . . . . . . 22 Property BSC-24: the bridge blockchain must accurately track the quantity of tokens available in the multisig accounts on all registered chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Property BTCHR-1: lagging behind batcher will eventually catch up with the rest of the batchers . . . . 24 Property BTCHR-2: batchers having out-of-sync indexers can generate valid batches . . . . . . . . . . . . 24 Property BTCHR-3: batchers are creating batches in a deterministic way . . . . . . . . . . . . . . . . . . 25 Property BTCHR-4: high frequency of bridging requests will not cause system to halt . . . . . . . . . . . 26 Property BTCHR-5: batcher must be resilient to Cardano connection failures . . . . . . . . . . . . . . . . 27 Property CNS: quorum is reached when more than two thirds of validator agree on a decision . . . . . . . 27 Property IDX-01: all validators must set the same address configurations in their block indexer . . . . . . 27 Property IDX-02: indexers must gracefully handle rollback in case of chain reorganizations . . . . . . . . 28 Property IDX-03: indexers must perform database operations atomically to ensure consistency . . . . . . 28 Property IDX-04: indexers must be resilient to Cardano connection failures . . . . . . . . . . . . . . . . . 29 Property IDX-05: indexers must maintain a single connection to a Cardano node . . . . . . . . . . . . . . 29 Property IDX-06: indexers must maintain UTXO states of the observed chains . . . . . . . . . . . . . . . 30 Property IDX-07: indexers must store transactions of interest consistently in their database . . . . . . . . 30

Findings 31 Calculated quorum may be lower than required to guarantee BFT . . . . . . . . . . . . . . . . . . . . . . 33 Unreliable sorting of UTXOs in database query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Incorrect quorum formula fails to guarantee BFT safety in edge cases . . . . . . . . . . . . . . . . . . . . 35 Centralisation risk due to owner with privileged rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 The system heavily depends on external Gouroboros library . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Quorum may be reached for multiple refund request claims that only differ on one field . . . . . . . . . . 38 Out-of-sync batchers are not able to sync with others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Lack of validation for validators’ verifying key when owner registers a chain . . . . . . . . . . . . . . . . . 42 Quorum may be reached for multiple batch executed claims or multiple batch execution failed claims (or both) for the same batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Addresses expected to be contract accounts may be set to EOA addresses . . . . . . . . . . . . . . . . . . 47 Contracts may be initialised with zero addresses for owner and upgrade admin . . . . . . . . . . . . . . . 49 Batcher heavy relies on out of scope packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Missed opportunity to consolidate UTXOs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Loops over unbounded arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Duplicate validator addresses may inflate quorum requirement . . . . . . . . . . . . . . . . . . . . . . . . 56 Redundancy in GenerateBatchTransaction code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Validators have different address configurations in their block indexer . . . . . . . . . . . . . . . . . . . . 59 Cardano transactions with zero amount will be created when there is no multisig and fee UTXOs . . . . . 60 Skyline Batcher miscellaneous code concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Token type not specified in NotEnoughFunds event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Batchers could appear synced if smart contract has outdated block data . . . . . . . . . . . . . . . . . . . 63 Bridge smart contracts miscellaneous code improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Optimization in validator data key verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 LevelDB indexer implementation is not tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Redundant database queries in the processing of confirmed blocks can be optimized . . . . . . . . . . . . 69 Recommendations for optimising gas usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Error handling function not fully tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Exposing a testing function in production code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Batcher miscellaneous code concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Systematic lack of documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Appendix: E2E Tests Review 78 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Test Coverage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Test Execution Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Observations and Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Appendix: Fuzz testing getNeededUtxos() 81

Appendix: Tests Review 84 Indexer Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Bridge Smart Contracts Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Batcher tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Appendix: Vulnerability classification 85

Disclaimer 88

Audit overview The Project In March and April 2025, Apex Foundation engaged Informal Systems to conduct a security audit of several scopes:

Reactor bridge • batcher in apex-bridge • indexer in cardano-infrastructure • The bridge smart contracts in apex-bridge-smartcontracts • The following e2e tests in blade-apex-bridge – apex_bridge_test.go – nexus_bridge_test.go – testnet_bridge_test.go

Skyline bridge • batcher in apex-bridge • The bridge smart contracts in apex-bridge-smartcontracts • The following e2e tests in blade-apex-bridge – apex_bridge_test.go – nexus_bridge_test.go – testnet_bridge_test.go

Scope of this report The audit focused on the components of the Reactor and Skyline bridges that the development team deemed as most critical: the Cardano block indexer, the off-chain batcher component and the bridge smart contracts. We reviewed correctness and security properties of the mentioned parts.

Audit plan The audit was conducted between March 13th, 2025 and April 25th, 2025 by the following personnel: • Aleksandar Ignatijevic • Simon Noetzlin • Carlos Rodriguez

Conclusions The Apex Reactor and Skyline bridges connect the Apex Fusion ecosystem—among its constituent chains and with Cardano, respectively. These bridges form a complex system that operates as blockchains with a validator set running several off-chain components. In this audit, we focused on the parts of the system the development team identified as the highest priority: the Cardano indexer, batcher, and bridge smart contracts. The system is highly asynchronous and distributed; its correct functioning depends on all moving parts working well together. We dedicated significant time to reasoning through scenarios that could raise safety or liveness issues. Most of these were unlikely given the design choices and trust assumptions (e.g., trusted off-chain oracle and batcher components, honest behavior of contract administrators, and a designated validator set). However, we did identify three critical issues: one that could have halted cross-chain transactions, and two that could have reduced the

system’s Byzantine fault tolerance. Upon disclosure, the development team acknowledged the issues and promptly implemented fixes. Overall, the project demonstrates a well-thought-out design and a high-quality implementation. While we reported several code improvements, we also recommend enhancing code documentation, as many functions lacked adequate comments. The cooperation and expertise of the development team significantly contributed to the success of this audit, and we believe the project is on a solid foundation going forward.

Audit Dashboard Target Summary • Type: protocol and implementation • Platform: Go, Solidity • Artifacts: – Reactor bridge: ∗ The batcher in apex-bridge at commit hash 0dd6cc0. ∗ The indexer in cardano-infrastructure at commit hash b150d63. ∗ The bridge smart contracts in apex-bridge-smartcontracts at commit hash 422fc3f. ∗ e2e tests in blade-apex-bridge at commit hash 66247f3: · apex_bridge_test.go · nexus_bridge_test.go · testnet_bridge_test.go – Skyline bridge: ∗ The batcher in apex-bridge at commit hash e527566. ∗ No changes for the indexer with respect to the Reactor implementation at commit hash ed906ee. ∗ The bridge smart contracts in apex-bridge-smartcontracts at commit hash 2392a60. ∗ e2e tests in blade-apex-bridge at commit hash a3a5962: · apex_bridge_test.go · nexus_bridge_test.go · testnet_bridge_test.go

Engagement Summary • Dates: 24.03.2025 - 25.04.2025. • Method: code review

Severity Summary

Finding Severity Number Critical 3 High 2 Medium 7 Low 4 Informational 14 Total 30

System Overview The Apex Fusion ecosystem consists of a three-chain architecture designed to optimize scalability, security, and decentralization. Each of these interconnected blockchain networks serve a unique purpose. At its core is the Prime network, the foundational layer that provides security and decentralization. Based on Cardano, it uses the Ouroboros Proof of Stake (PoS) consensus protocol and an e-UTXO accounting system for energy-efficient, robust security through decentralized liquid staking. The Prime chain is also the exclusive issuer of the APEX token, used for transaction fees, staking rewards, and governance, with token holders voting on proposals. Supporting the Prime chain are two Layer 2 solutions:

Vector network: a secondary layer that enhances scalability and performance, designed for high-throughput applications and services. The Vector chain uses a UTXO model to deliver high throughput and low latency.
Nexus network: a secondary layer focused on speed and cost-efficiency. It handles smart contract execution and complex transactions. The Nexus chain uses an EVM-based framework, making it compatible with many decentralized applications and ensuring efficient DeFi interactions. These networks are interconnected through the Reactor bridge, enabling seamless interoperability across the Apex Fusion ecosystem. This architecture addresses the blockchain trilemma by providing dedicated blockchains optimized for specific uses, offering users greater flexibility.

Reactor bridge The Apex Reactor bridge connects the three chains in the Apex Fusion ecosystem: the Layer 1 Prime chain and two Layer 2 chains (Vector and Nexus). The bridge operates as a blockchain with a validator set. During token bridging, the system locks APEX tokens on the source blockchain in a multisig address controlled by bridge validators and releases an equivalent amount on the destination blockchain. Each validator runs two (trusted) off-chain components: • The oracle monitors bridging activities, including bridging requests and batch executions. It detects bridging requests by observing transactions that deposit funds to the bridge multisig address, which controls the bridging funds. • The batcher monitors the bridge blockchain to determine when to create a new batch. When specific conditions are met, the batcher creates a batch instance—a transaction intended for the destination blockchain. To submit the batch to the destination chain, a trustless component called the relayer operates as a single standalone instance. The relayer retrieves batches from the bridge blockchain and submits transactions to the destination chain.

Bridging workflow The following example demonstrates a cross-chain token transfer from Prime to Vector, where Prime is the source chain and Vector is the destination chain. A similar same process applies to transfers from Prime to Nexus or from any L2 network back to Prime. The red-highlighted components indicate the audit scope.

Submit bridging transaction: the sender initiates the cross-chain transfer by creating a transaction on the source chain using their funds to cover the network fee for block inclusion, the bridging fee for cross-chain relay, and the amount of tokens to be bridged. The funds are locked in the bridge’s multisig (hot) address, and the transaction metadata contains the destination chain ID and address, and amount.
Detect bridging transaction: the oracle of each validator of the bridge chain monitors bridging transactions by watching for transactions on the source chain that transfer funds to the bridge multisig address.
Witness bridging transaction: each oracle submits a bridging request claim to the bridge blockchain to confirm it has observed the bridging transaction.
Confirm bridging transaction: the transaction becomes valid and ready for batching once a quorum of validator oracle votes confirms it.

Retrieve confirmed transactions: the batcher generates a batch with the confirmed transactions when either enough bridging transactions have been confirmed or the maximum time between batches is reached.
Submit batch transaction: to construct the batch, the batcher leverages the block indexer’s database to acquire input UTXOs that belong to the multisig address controlling the bridged funds and to the multisig address responsible for covering the network fee on the destination chain. Following that, output UTXO instances associated with receiver addresses are formed by processing the confirmed bridging transactions retrieved from the bridge.
Confirm batch transaction: before submission to the destination blockchain, the batch requires confirmation from a quorum of bridge validators.
Retrieve confirmed batch: the relayer retrieves the confirmed batch and it combines the individual signatures from the batch to create the multi-signature

Excerpt (19999 of 172496 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation