plamentsv / cross-chain-timing

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

Step 6: Cross-Chain Price Relay Audit

If oracle prices are relayed cross-chain:

Staleness calculation: relay_staleness = source_price_age + bridge_latency + aptos_processing

If relay_staleness > acceptable_threshold at worst case, price is stale. Apply Rule 16 (Oracle Integrity).

Aptos-specific: timestamp::now_seconds() returns seconds (not milliseconds). Ensure staleness comparisons use consistent units. Also verify timestamp::now_microseconds() is not confused with now_seconds() - a 1000x unit mismatch could make staleness checks ineffective.

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 Aptos at {EXPLOIT_FUNCTION} using stale {STALE_STATE}
   -- Aptos execution is near-instant (~1s), so attacker can react quickly
4. Sync message arrives on Aptos, state updates in resource
5. Profit = {PROFIT_FORMULA}
6. Cost = bridge_fees + Aptos_gas + capital_lockup_cost
7. Viable if: profit > cost AND repeatable

Reverse direction (Aptos -> remote chain):

1. Attacker monitors Aptos state change (near-instant visibility due to BFT finality)
2. Attacker front-runs the bridge message on remote chain (longer finality window)
3. Attacker exploits stale state on remote chain before sync arrives

Aptos cost model: Aptos gas costs are low (~0.001 APT per tx). The primary cost is capital lockup and bridge fees, not gas. This makes small-margin attacks more viable on Aptos 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 Aptos? (Aptos'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 CoinStores registered before cross-chain transfer arrival?
6. Is replay protection complete (covers all message types, all chains)?
7. Can an attacker exploit Aptos's fast finality to act before the remote chain sees Aptos state?
8. Are cross-chain prices validated for freshness AND deviation bounds?
9. Does VAA/message verification check BOTH source chain AND source address?

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
• Move type safety: Move's resource type system prevents fake VAA/message resource injection from incorrect modules - but still verify the module address is correct
• Bridge-level protections: Some bridges (Wormhole) have rate limiting or value caps that bound exploitation
• Freshness enforcement: If protocol requires timestamp::now_seconds() - last_sync < MAX_STALENESS, stale state is rejected

Instantiation Parameters

{CONTRACTS}           -- Modules to analyze
{BRIDGE_PROTOCOL}     -- Specific bridge (Wormhole, LayerZero, CCIP, custom)
{SYNC_POINT}          -- Function where cross-chain state is consumed
{DEPENDENT_FUNCTIONS} -- Functions that read synced state
{SOURCE_CHAIN}        -- Chain where state originates
{DEST_CHAIN}          -- Chain where stale state is exploited
{MONITOR_POINT}       -- What attacker monitors on source chain
{EXPLOIT_FUNCTION}    -- Function attacker calls on dest chain
{STALE_STATE}         -- Specific state variable/resource field that becomes stale
{LATENCY_ESTIMATE}    -- Realistic bridge latency
{PROFIT_FORMULA}      -- (new_value - old_value) * position_size

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 VAA verification is incomplete -> immediate finding, do not wait for timing analysis.

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

After Step 4: If resource creation can fail -> cross-reference with REF_LIFECYCLE skill for stranded asset analysis.

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