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.