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.

Step 6: Cross-Chain Price Relay Audit

If oracle prices are relayed cross-chain to Soroban:

Staleness calculation: relay_staleness = source_price_age + bridge_latency + stellar_ledger_processing

No flash loan price manipulation on Stellar itself: Stellar's DEX (SDEX / AMM) does not support flash loans natively, and Soroban flash loan patterns are protocol-specific. However, prices relayed FROM Ethereum via bridge can be manipulated on the source chain before relaying. Apply Rule 16 (Oracle Integrity).

Step 7: Quantify Arbitrage Viability

1. Attacker monitors {SOURCE_CHAIN} for state changes at {MONITOR_POINT}
2. State change triggers sync message (latency window opens: {LATENCY_ESTIMATE})
3. Attacker submits Soroban transaction in next ledger using stale {STALE_STATE}
4. Bridge relay arrives on Soroban; state updates
5. Profit = {PROFIT_FORMULA}
6. Cost = bridge_fees + Stellar_tx_fees (very low, ~0.00001 XLM base) + capital_lockup_cost
7. Viable if: profit > cost AND repeatable

Stellar cost model: Stellar transaction fees are extremely low (100 stroops = 0.00001 XLM base fee). Soroban resource fees add compute/memory costs but are typically fractions of a cent. The primary cost is bridge fees and capital lockup, NOT gas. Small-margin attacks are viable.

Key Questions (must answer all)

1. What is the realistic sync latency for {BRIDGE_PROTOCOL}? (cite documentation or relay bot config)
2. Can an attacker observe the remote chain and submit a Soroban transaction in the next ledger before the relay bot? (5s window per ledger)
3. What is the maximum state change during normal operation within the sync window?
4. Is this attack repeatable or one-time?
5. Are replay-protection nonces stored in Persistent storage with sufficient TTL to outlast the attack window?
6. Is replay protection complete (covers all message types, all source chains)?
7. Do trustline requirements create griefing or blocking vectors for cross-chain token delivery?
8. Are cross-chain prices validated for freshness AND deviation bounds?
9. For Stellar anchor integrations: what happens if the anchor server becomes unresponsive?

Common False Positives

• Monotonic state: If synced state only increases, arbitrage may not be profitable in both directions
• Negligible delta: If max delta during sync window is <0.1%, may not be economically viable after bridge fees
• Persistent nonces with long TTL: Replay protection is adequate if nonces are Persistent with TTL >> relay latency
• SAC isolation: Stellar Asset Contract (SAC) token balances in Soroban contracts are isolated from classic Stellar trustline limits — trustline griefing does not apply to SAC-denominated operations
• Bridge-level protections: Some bridges enforce rate limiting or value caps that bound exploitation

Instantiation Parameters

{CONTRACTS}           - Soroban contracts to analyze
{BRIDGE_PROTOCOL}     - Specific bridge (Wormhole, Allbridge, Axelar, Stellar anchor, custom)
{SYNC_POINT}          - Contract function where cross-chain state is consumed
{DEPENDENT_FUNCTIONS} - Functions that read synced state
{SOURCE_CHAIN}        - Chain where state originates
{MONITOR_POINT}       - What attacker monitors on source chain
{EXPLOIT_FUNCTION}    - Soroban function attacker calls
{STALE_STATE}         - Specific state that becomes stale
{LATENCY_ESTIMATE}    - Realistic bridge relay latency

Output Schema

Step Execution Checklist (MANDATORY)

Cross-Reference Markers

After Step 2: If message verification is incomplete -> immediate finding, do not wait for timing analysis.

After Step 3: Feed timing windows to TEMPORAL_PARAMETER_STALENESS skill for parameters cached across chain boundaries.

After Step 4: If trustline creation can fail or be griefed -> cross-reference with economic design analysis for stranded asset risk.

After Step 5: If replay-protection nonces use temporary or instance storage -> mandatory HIGH finding for TTL expiry replay vector.

After Step 6: Feed price staleness findings to ORACLE_ANALYSIS if applicable.