- Total Prize Pool: $101,000 in USDC
- HM awards: up to $89,760 in USDC
- If no valid Highs or Mediums are found, the HM pool is $0
- QA awards: $3,740 in USDC
- Judge awards: $7,000 in USDC
- Scout awards: $500 USDC
- HM awards: up to $89,760 in USDC
- Read our guidelines for more details
- Starts April 1, 2026 20:00 UTC
- Ends April 14, 2026 20:00 UTC
- Judging phase risk adjustments (upgrades/downgrades):
- High- or Medium-risk submissions downgraded by the judge to Low-risk (QA) will be ineligible for awards.
- Upgrading a Low-risk finding from a QA report to a Medium- or High-risk finding is not supported.
- As such, wardens are encouraged to select the appropriate risk level carefully during the submission phase.
Anything included in this section is considered a publicly known issue and is therefore ineligible for awards.
Not applicable.
The LayerZero V2 on Stellar implementation enables cross-chain messaging between Stellar and other blockchains. Built on Soroban (Stellar's smart contract platform) using Rust, it follows a modular, plugin-based architecture that maintains compatibility with LayerZero's V2 protocol design while adapting to Stellar's unique characteristics.
The protocol preserves LayerZero's core values of permissionlessness, immutability, and censorship-resistance.
The Stellar LayerZero implementation maintains the same four-step messaging flow as other LayerZero V2 implementations:
- Send: OApp calls EndpointV2 with message parameters
- Verify: DVNs verify messages and submit their validation to the message lib
- Commit: Via a permissionless call, the message library asserts commitment requirements and commits payload hash to the endpoint
- Execute: Via a pull model, the OApp calls endpoint.clear to receive the verified message
Stellar-Specific Design Considerations
The implementation addresses four major Stellar/Soroban constraints:
- bytes32 Address Format: Stellar uses variable-length addresses while LayerZero V2 uses fixed bytes32. LayerZero treats all OApp addresses as contract addresses.
- TTL-Based Storage: Soroban storage entries have TTL (Time-To-Live). The protocol uses a hybrid extension strategy to ensure critical state is never lost.
- Storage Read Limits: Soroban limits reads to 200 per transaction. The protocol uses eager inbound nonce tracking with pending nonce lists to stay within limits.
- No Reentrancy: Soroban prohibits reentrancy. The implementation uses Abstract Account patterns for DVN and Executor, and adopts pull-mode message delivery to support the ABA pattern (where the executor appears twice in the call stack).
- Previous audits: Reports are still in the draft phase and cannot be shared at the moment.
- Documentation:
contracts/protocol/stellar/docs - Website: https://layerzero.network/
- X/Twitter: https://x.com/LayerZero_Core
For a machine-readable version, see scope.txt
| File/Directory | File Count |
|---|---|
All test files in in-scope directories (**/tests/*, **/integration_tests/*, **/integration-tests/*) |
170 |
| contracts/protocol/stellar/contracts/oapps/* | 134 |
| contracts/protocol/stellar/contracts/workers/executor/* | 12 |
| contracts/protocol/stellar/contracts/workers/executor-fee-lib/* | 8 |
| contracts/protocol/stellar/contracts/workers/executor-helper/* | 5 |
| contracts/protocol/stellar/contracts/workers/dvn-fee-lib/* | 5 |
| contracts/protocol/stellar/contracts/workers/price-feed/* | 9 |
| contracts/protocol/stellar/contracts/message-libs/simple-message-lib/* | 7 |
| contracts/protocol/stellar/contracts/layerzero-views/* | 9 |
| contracts/protocol/stellar/contracts/upgrader/* | 3 |
| contracts/protocol/stellar/contracts/macro-integration-tests/* | 129 |
| packages/* | 58 |
| tools/* | 29 |
| configs/* | 1 |
| tooling-configs/* | 16 |
| Total | 625 |
For a machine-readable version, see out_of_scope.txt
- DVN / ULN interaction security: Verify correctness of the verification flow between DVNs and the ULN302 message library
- Soroban storage and TTL handling: Is there a way to grief the Endpoint or ULN (which will be immutable) through TTL expiration or storage manipulation?
- Censorship resistance: Is there a way on the native payment path that LayerZero can use its permissions to censor user messages? This should not be possible under proper configurations
- Soroban-specific behaviour: No reentrancy, storage read limits (200 per transaction), TTL expiration edge cases
- bytes32 address format conversion: Correctness of conversion between Stellar variable-length addresses and LayerZero's fixed-length bytes32 format
- Abstract Account pattern security: DVN and Executor use Soroban's custom account interface (
__check_auth) instead of self-calls. Has this pattern been implemented securely? - Pull-mode message delivery: Correctness of the pull-mode delivery model (OApp calls
Endpoint.clear()) under Soroban's reentrancy prohibition
- Endpoint owner should not be able to censor messages
- Endpoint is immutable
- Only delegate or OApp can set configs for OApp
- ULN is immutable
- ULN owner should not be able to censor messages through native path
- DVN is secured through its multisig
- DVN cannot suffer a replay attack
- Only Admin can execute arbitrary signed payloads through DVN
- DVN can set Admin through signed payload without Admin's permission
- Owner should not be able to block user messages
- Treasury is immutable
- Treasury owner config should not be able to block user messages when using native token fee path
N/A
git clone https://github.com/code-423n4/2026-04-layerzero
cd 2026-04-layerzero/contracts/protocol/stellarPrerequisites:
- Rust 1.90.0 with
wasm32v1-nonetarget (automatically installed viarust-toolchain.tomlwhen using rustup) - Stellar CLI for building WASM contracts
Build all contracts to WASM:
stellar contract buildRun all tests:
cargo testEmployees of LayerZero and employees' family members are ineligible to participate in this audit.
Code4rena's rules cannot be overridden by the contents of this README. In case of doubt, please check with C4 staff.
