Cross Chain Timing

Skill: Cross-Chain Timing Analysis (Sui)

Type: Thought-template (instantiate before use) Trigger Pattern: bridge|wormhole|axelar|layerzero|sui_bridge|cross_chain|relay|vaa|guardian|emitter|ccip Inject Into: Breadth agents, depth-external Finding prefix: [CCT-N] Rules referenced: R1, R2, R4, R8, R10, R16 Research basis: Multi-block arbitrage windows, bridge latency exploitation

Covers: cross-chain message verification, timing asymmetry between Sui and other chains, object creation requirements for bridged assets, nonce/sequence replay protection, and cross-chain price relay staleness.

Sui's consensus model produces checkpoints every 0.5-2 seconds and epochs every ~24 hours. Cross-chain messaging relies on bridge protocols (Wormhole, Axelar, Sui Bridge native) that verify Sui checkpoints before relaying messages. Sui's fast finality (2-3s checkpointed) creates timing asymmetry with slower chains (Ethereum ~12min, rollups 10-60min).

Trigger Patterns

bridge|wormhole|axelar|layerzero|sui_bridge|cross_chain|vaa|relay|messenger|
send_message|receive_message|bridge_transfer

Step 1: Identify Cross-Chain Messaging Infrastructure

Find all cross-chain messaging calls in {CONTRACTS}:

For each call, determine:

• What state is being synced? (rates, balances, epochs, totals, oracle prices)
• What triggers the sync? (every operation, periodic, manual keeper call)
• What bridge/messenger is used? (Wormhole VAA, Axelar GMP, Sui Bridge native, custom relay)
• Is the message authenticated? (VAA signatures, validator attestations, committee signatures)

Wormhole-Specific Inventory (Sui)

If Wormhole is detected:

Sui Bridge (Native) Inventory

If the native Sui Bridge is detected:

Sui-specific outbound/inbound:

• Outbound messages: typically emitted as events or written to shared objects for relayer pickup
• Inbound messages: typically processed by a function receiving a VAA or equivalent proof
• clock::timestamp_ms() provides millisecond timestamps -- check if timestamp freshness is validated on message receipt

Step 2: Cross-Chain Message Verification Audit

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

2a. Wormhole VAA Verification Checklist (Sui)

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

Sui-specific: On Sui, Wormhole VAAs are represented as objects. Verify the VAA object type comes from the authentic Wormhole package (check package address) -- an attacker could deploy a fake Wormhole package with matching type names.

2b. Generic Bridge Verification

For non-Wormhole bridges:

Step 3: Timing Window Analysis

3a. Finality Asymmetry Model

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

3b. Stale State Usage Trace

For each piece of state synced cross-chain:

For each dependent function on Sui:

• Is fresh state required or is stale acceptable?
• What decisions are made with potentially stale data?
• Is there a staleness check (e.g., comparing clock::timestamp_ms() against message timestamp)?

Sui-specific checks:

• Are there epoch-boundary effects? (Sui epoch changes can affect staking rewards, validator sets)
• Is the synced state stored in a shared object that other transactions can race against?
• No mempool in Sui: front-running model differs from EVM (but sequencing attacks via validator collusion possible for shared objects)

3c. Sui-to-Remote Timing Attack

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

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

3d. Remote-to-Sui Timing Attack

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

Step 4: Object Creation Requirements

Cross-chain operations on Sui have unique object requirements:

Sui-specific: Bridged tokens on Sui are typically Coin<BridgedType> where BridgedType was registered by the bridge via OTW. Verify: is the TreasuryCap for bridged tokens held exclusively by the bridge? Can anyone else mint bridged tokens? If TreasuryCap is stored in a shared object, check that access control prevents unauthorized minting.

Step 5: Nonce and Sequence Management

Sui replay patterns:

• Table<Hash, bool>: Store processed message hashes. Reliable but Table grows unbounded.
• Dynamic field per message: Add dynamic field with message ID as key. Same growth concern.
• Unique object per message: Create an object per processed message (exists = processed). Objects persist permanently on-chain.
• 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 + sui_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} minutes)
3. Attacker executes on Sui at {EXPLOIT_FUNCTION} using stale {STALE_STATE}
   - Sui transaction cost is very low (<$0.01 per tx)
   - PTB allows multi-step atomic exploitation
4. Sync message arrives on Sui, state updates
5. Profit = {PROFIT_FORMULA}
6. Cost = bridge_fees + Sui_gas + capital_lockup_cost
7. Viable if: profit > cost AND repeatable

Sui cost model: Sui gas is paid in SUI, typically very low (<$0.01 per tx). Cost barrier is primarily bridge fees and capital requirements. Low gas makes small-margin attacks more viable than on EVM.

Key Questions (must answer all)

1. What is the realistic sync latency for {BRIDGE_PROTOCOL} on Sui? (cite documentation)
2. Can an attacker monitor {SOURCE_CHAIN} and exploit stale state on Sui (or vice versa) before sync completes?
3. What is the maximum {STALE_STATE} change during normal operation within the sync window?
4. Is this attack repeatable or one-time?
5. Does the protocol validate message timestamps against clock::timestamp_ms()?
6. Are bridged token TreasuryCaps exclusively held by the bridge?
7. Is replay protection complete (covers all message types, all chains)?
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 costs
• Rate limiting: If operations have cooldowns longer than sync latency, window may not be exploitable
• Timestamp freshness check: If protocol compares message timestamp against clock::timestamp_ms() and rejects stale messages, window is bounded
• Epoch-aligned sync: If sync happens once per epoch (~24h) and this is documented/intended, staleness within an epoch may be by design
• Bridge-level protections: Some bridges have rate limiting or value caps that bound exploitation

Instantiation Parameters

{CONTRACTS}           -- List of modules to analyze
{BRIDGE_PROTOCOL}     -- Specific bridge (Wormhole, Axelar, Sui Bridge, custom)
{SYNC_POINT}          -- Function where inbound sync occurs
{DEPENDENT_FUNCTIONS} -- Functions that read synced state
{SOURCE_CHAIN}        -- Chain where state originates
{DEST_CHAIN}          -- Chain where stale state is exploited (may be Sui)
{MONITOR_POINT}       -- What attacker monitors on source chain
{EXPLOIT_FUNCTION}    -- Function attacker calls using stale state
{STALE_STATE}         -- Specific state variable that becomes stale
{PROFIT_FORMULA}      -- (new_value - old_value) * position_size
{MAX_DELTA}           -- Maximum observed state change during sync window
{LATENCY}             -- Estimated bridge latency in minutes

Output Schema

Denylist Enforcement Lag

• Denylist enforcement lag: For cross-chain denylist/blocklist updates, check the window between message receipt and enforcement. Can transactions from denylisted addresses execute during this window? Are in-flight operations for denylisted addresses cancelled or allowed to complete?

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 bridged token TreasuryCap is not exclusively held by bridge -> cross-reference with TYPE_SAFETY Coin/Balance section.

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

If any step skipped, document valid reason (N/A, no cross-chain messaging, single chain only).