CROSS_CHAIN_TIMING Skill (Solana)

Trigger Pattern: wormhole|allbridge|debridge|bridge|cross_chain|vaa|guardian|emitter|LayerZero|CCIP|nonce.*sequence|relay 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 Solana and other chains, account creation requirements, nonce/sequence replay protection, and cross-chain price relay staleness.

Solana's fast finality (~400ms optimistic, ~30s confirmed/rooted) creates a fundamental timing asymmetry with slower chains (Ethereum ~12min, rollups 10-60min). This asymmetry is the primary attack vector for cross-chain timing exploits on Solana.

Step 1: Identify Cross-Chain Messaging Infrastructure

Find all cross-chain messaging calls and infrastructure:

Wormhole-Specific Inventory

If Wormhole is detected:

Allbridge/deBridge-Specific Inventory

If Allbridge or deBridge detected:

Step 2: Cross-Chain Message Verification Audit

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

2a. Wormhole VAA Verification Checklist

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

2b. Generic Bridge Verification

For non-Wormhole bridges:

Step 3: Timing Window Analysis

3a. Finality Asymmetry Model

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

3b. Stale State Usage Trace

For each piece of state synced cross-chain:

For each dependent instruction on Solana:

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

3c. Solana-to-Remote Timing Attack

Solana's fast finality means actions on Solana are visible almost immediately, but take time to propagate to remote chains:

1. Attacker acts on Solana (visible in ~400ms)
2. Solana message posted via bridge (begins relay)
3. TIMING WINDOW: Remote chain does not yet know about Solana action
4. Attacker acts on remote chain using pre-Solana-action state
5. Bridge message arrives on remote chain - state updates
6. Attacker profited from acting on both chains during asymmetry

3d. Remote-to-Solana Timing Attack

1. State changes on remote chain (e.g., price moves, governance action)
2. Bridge message relay begins (latency: {estimate})
3. TIMING WINDOW: Solana still uses old remote state
4. Attacker acts on Solana using stale remote state
5. Bridge message arrives on Solana - state updates
6. Attacker profited from Solana action with stale state

Step 4: Account Creation Requirements

Cross-chain operations on Solana have unique account requirements:

Critical Solana pattern: Cross-chain token transfers require the destination ATA to exist. If it does not:

• Some bridges revert and the tokens are stuck on the source chain
• Some bridges create the ATA (who pays rent-exempt minimum?)
• Some bridges queue the transfer for later claim (is the queue unbounded?)

Step 5: Nonce and Sequence Management

Solana replay patterns:

• PDA per message: Derive PDA from message hash/sequence. If PDA exists, already processed. Reliable but creates many accounts.
• Bitmap account: Store processed sequences as bits. Space-efficient but must handle bitmap growth.
• Counter: Only process sequence N if N-1 was processed. Enforces ordering but blocks on gaps.

Step 6: Cross-Chain Price Relay Audit

If oracle prices are relayed cross-chain:

Staleness calculation: relay_staleness = source_price_age + bridge_latency + solana_processing

If relay_staleness > acceptable_threshold at worst case, price is stale. 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 executes on Solana at {EXPLOIT_INSTRUCTION} using stale {STALE_STATE}
4. Sync message arrives, state updates on Solana
5. Profit = {PROFIT_FORMULA}
6. Cost = bridge_fees + Solana_tx_fees + capital_lockup_cost + Jito_tip
7. Viable if: profit > cost AND repeatable

Solana cost model: Solana transaction fees are very low (~5000 lamports base + priority fee). The primary cost is capital lockup and bridge fees, not gas. This makes small-margin attacks more viable on Solana than EVM.

Key Questions (must answer all)

1. What is the realistic sync latency for {BRIDGE_PROTOCOL}? (cite documentation)
2. Can an attacker monitor the remote chain and front-run sync on Solana? (Solana's low fees make this cheap)
3. What is the maximum state change during normal operation within the sync window?
4. Is this attack repeatable or one-time?
5. Are recipient accounts pre-created, or must they be created on arrival?
6. Is replay protection complete (covers all message types, all chains)?
7. Can an attacker exploit Solana's fast finality to act before the remote chain sees Solana state?
8. Are cross-chain prices validated for freshness AND deviation bounds?

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
• Rate limiting: If operations have cooldowns longer than sync latency, window may not be exploitable
• Confirmed finality enforcement: If protocol requires rooted/finalized Solana confirmations before processing, timing window is ~30s (larger but more reliable)
• Bridge-level protections: Some bridges (Wormhole) have rate limiting or value caps that bound exploitation

Instantiation Parameters

{CONTRACTS}           - Programs to analyze
{BRIDGE_PROTOCOL}     - Specific bridge (Wormhole, Allbridge, deBridge, custom)
{SYNC_POINT}          - Instruction where cross-chain state is consumed
{DEPENDENT_FUNCTIONS} - Instructions that read synced state
{SOURCE_CHAIN}        - Chain where state originates
{MONITOR_POINT}       - What attacker monitors on source chain
{EXPLOIT_INSTRUCTION} - Instruction attacker calls on Solana
{STALE_STATE}         - Specific state that becomes stale
{LATENCY_ESTIMATE}    - Realistic bridge latency

Output Schema

Step Execution Checklist (MANDATORY)

Cross-Reference Markers

After Step 2: If VAA 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 account creation can fail -> cross-reference with ACCOUNT_LIFECYCLE skill for stranded asset analysis (Rule 9).

After Step 6: Feed price staleness findings to ORACLE_ANALYSIS (Solana version) if applicable.