Cross Chain Timing

CROSS_CHAIN_TIMING Skill (Soroban)

Trigger Pattern: stellar_bridge|soroban_bridge|horizon|anchor_protocol|bridge|cross_chain|relay|wormhole|allbridge|debridge|axelar|LayerZero|sequence|emitter Inject Into: Breadth agents, depth-external Finding prefix: [CCT-N] Rules referenced: R1, R2, R4, R8, R10, R16

Covers: cross-chain message verification, timing asymmetry between Stellar/Soroban and other chains, Stellar anchor (fiat on/off-ramp) integration risks, nonce/sequence replay protection, and cross-chain price relay staleness.

Stellar's SCP consensus achieves finality in approximately 3-5 seconds per ledger close — significantly faster than Ethereum (~12 min for high-confidence finality) and most rollups (10-60 min), but slower than Solana. Key distinction from EVM chains: There is NO mempool reordering on Stellar; once a transaction is included in a closed ledger it is final with no rollback risk. This changes the timing attack surface: there is no front-running at the consensus level, but there IS a meaningful finality asymmetry between Stellar and slower chains.

No MEV / validator manipulation: Stellar's federated quorum (SCP) has no block-ordering incentive for validators. Timing attacks on Soroban therefore target cross-chain relay windows, not intra-chain ordering.

Step 1: Identify Cross-Chain Messaging Infrastructure

Find all cross-chain messaging calls and infrastructure:

Stellar Anchor Integration (fiat on/off-ramp)

If a Stellar SEP-6/SEP-24/SEP-31 anchor is detected:

Anchor integration introduces a trusted off-chain actor (the anchor server). Enumerate what the Soroban contract trusts the anchor to report and what state it changes based on that report.

Wormhole / Generic VAA Bridge Inventory (if detected)

Step 2: Cross-Chain Message Verification Audit

For EACH inbound cross-chain message consumed by the contract:

2a. VAA / Signed Message Verification Checklist

Critical: Missing checks 1-5 = CRITICAL (arbitrary cross-chain message injection). Missing checks 6-8 = HIGH (message quality/integrity issues).

2b. Stellar Anchor Callback Verification

If the protocol relies on a Stellar anchor to report off-chain fiat events:

Step 3: Timing Window Analysis

3a. Finality Asymmetry Model

Critical question: When Soroban processes a message about remote chain state, how old can that state be? Compute: max_staleness = remote_finality + bridge_relay_delay + stellar_processing_time

No MEV nuance: Because Stellar has no mempool, the attacker cannot front-run a pending relay transaction. However, they CAN front-run the relay by observing the source chain and submitting a Soroban transaction in the next ledger before the relay bot does — because Soroban transactions in the same ledger are ordered deterministically by fee but submitted permissionlessly.

3b. Stale State Usage Trace

For each piece of state synced cross-chain:

For each dependent function on Soroban:

• Is fresh state required or is stale acceptable?
• What decisions are made with potentially stale data?
• Can an attacker exploit the staleness window between relay submissions?

3c. Soroban-to-Remote Timing Attack

1. Attacker acts on Soroban (visible after ~5s ledger close — FINAL, no reorg)
2. Soroban event/message picked up by bridge relay (begins relay to remote chain)
3. TIMING WINDOW: Remote chain does not yet know about Soroban action
4. Attacker acts on remote chain using pre-Soroban-action state
5. Bridge relay arrives on remote chain — state updates
6. Attacker profited from acting on both chains during the asymmetry window

Stellar-specific note: Because Soroban finality is hard (no reorgs), the attacker can be confident the Soroban action is settled before acting on the remote chain, making the attack more reliable than on probabilistic chains.

3d. Remote-to-Soroban Timing Attack

1. State changes on remote chain (e.g., price moves, governance action, token mint)
2. Bridge relay begins (latency: {estimate})
3. TIMING WINDOW: Soroban still uses old remote state
4. Attacker submits Soroban transaction in next available ledger using stale remote state
5. Bridge relay arrives on Soroban — state updates
6. Attacker profited from Soroban action with stale state

Step 4: Stellar Asset Trustline Requirements

Cross-chain token operations on Stellar/Soroban have trustline prerequisites with no EVM analogue:

Stellar-specific: The Stellar base reserve (currently 0.5 XLM per trustline entry) means creating trustlines has a cost. Contracts that auto-create trustlines may be drained of their XLM reserve by an attacker triggering many trustline creations.

Step 5: Nonce and Sequence Management

Soroban-specific replay concern: Soroban storage entries have TTLs (instance, persistent, temporary). If replay-protection nonces are stored in temporary or instance storage with insufficient TTL, they may expire and a replayed old message would be accepted. All replay-protection entries MUST use Persistent storage with extended TTL.