Cross Chain Timing

CROSS_CHAIN_TIMING Skill (Aptos)

Trigger Pattern: wormhole|layerzero|ccip|bridge|cross_chain|vaa|guardian|emitter|relay|remote_chain|payload|nonce.*sequence 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 Aptos and other chains, resource creation requirements, nonce/sequence replay protection, and cross-chain price relay staleness.

Aptos's fast finality (~1 second with BFT consensus) 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 Aptos. Additionally, Move's type-safe resource model introduces unique account/resource requirements for cross-chain operations.

Step 1: Identify Cross-Chain Messaging Infrastructure

Find all cross-chain messaging calls and infrastructure:

Wormhole-Specific Inventory

If Wormhole is detected:

LayerZero-Specific Inventory

If LayerZero is detected:

Generic Bridge Inventory

For custom or other bridges:

Step 2: Cross-Chain Message Verification Audit

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

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).

Aptos-specific: Move's type system provides some protection - a VAA resource type can only be created by the Wormhole module. However, verify that the consuming module checks the VAA was created by the CORRECT Wormhole deployment (not a cloned module at a different address).

2b. Generic Bridge Verification

For non-Wormhole bridges:

Step 3: Timing Window Analysis

3a. Finality Asymmetry Model

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

3b. Stale State Usage Trace

For each piece of state synced cross-chain:

For each dependent function on Aptos:

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

Aptos-specific: Check if synced state is stored in a global resource (move_to/borrow_global) or a Table. If a global resource, ALL functions reading it are affected by staleness. If a Table, trace which keys are stale.

3c. Aptos-to-Remote Timing Attack

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

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

3d. Remote-to-Aptos Timing Attack

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

Step 4: Resource Creation Requirements

Cross-chain operations on Aptos have unique resource requirements due to Move's ownership model:

Critical Aptos pattern: Cross-chain token transfers require the destination account to have a CoinStore<T> registered for the specific coin type. If it does not:

• The transfer transaction aborts - tokens may be stuck on the source chain
• Some bridges auto-register (requires signer capability or resource account)
• Some bridges queue the transfer for later claim (is the queue bounded? Who can claim?)

Resource account pattern: Many Aptos bridge modules use resource accounts (account::create_resource_account) for escrow. Verify:

• The resource account seed is deterministic and collision-free per message
• The resource account signer capability is stored securely (not extractable)
• Resource account creation cannot be front-run by an attacker

Step 5: Nonce and Sequence Management

Aptos replay patterns:

• Table per message: Store processed sequences in Table<u64, bool> or Table<vector<u8>, bool>. If key exists, already processed. Reliable but Table lookups have gas cost proportional to depth.
• Counter: Only process sequence N if N-1 was processed. Enforces ordering but blocks on gaps.
• Resource per message: Create a unique resource per processed message hash. Existence check prevents replay. Creates many resources (storage cost).
• EventHandle sequence: Use event::counter on an EventHandle as implicit sequence. Not reliable for replay - events are not queryable on-chain.

Move-specific concern: Table entries cannot be iterated or enumerated on-chain. If replay state is in a Table, ensure the lookup key is deterministic from message content (not relayer-supplied).