cross-chain-timing

name	cross-chain-timing
description	Trigger Pattern wormhole|layerzero|ccip|bridge|cross_chain|vaa|guardian|emitter|relay|remote_chain|payload|nonce.sequence - Inject Into Breadth agents, depth-external

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:

#	Bridge/Protocol	Direction	Aptos Function	Remote Chain	Message Type
1	{Wormhole/LayerZero/CCIP/custom}	{Aptos->Remote / Remote->Aptos}	{function name}	{Ethereum/Arbitrum/etc.}	{token transfer / state sync / price relay / governance}

Wormhole-Specific Inventory

If Wormhole is detected:

Component	Module/Function	Purpose	Location
VAA Verification	vaa::parse_and_verify / guardian signature check	Guardian signature verification	{file:line}
Message Posting	wormhole::publish_message	Send message from Aptos	{file:line}
Token Bridge	complete_transfer / create_wrapped_coin	Token bridging	{file:line}
Emitter Resource	Emitter capability or resource	Message source identity	{file:line}

LayerZero-Specific Inventory

If LayerZero is detected:

Component	Module/Function	Verification Method	Location
Endpoint	endpoint::lz_receive / receive handler	Oracle + Relayer attestation	{file:line}
Remote Mapping	Trusted remote configuration	Address/chain validation	{file:line}
Nonce Tracking	Inbound/outbound nonce resources	Replay prevention	{file:line}

Generic Bridge Inventory

For custom or other bridges:

Component	Module/Function	Verification Method	Location
Message Resource	{resource type}	{signature/merkle/optimistic}	{file:line}
Relayer	{relayer constraint}	{how relayer is validated}	{file:line}
Nonce Tracking	{nonce storage}	{replay prevention method}	{file:line}

---

Step 2: Cross-Chain Message Verification Audit

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

2a. Wormhole VAA Verification Checklist

#	Check	Status	Location	Notes
1	Guardian signature count >= quorum (13/19)	YES/NO	{line}	Does module verify guardian_set_index is current?
2	Guardian set is current (not expired)	YES/NO	{line}	Old guardian sets may be compromised
3	Emitter chain ID validated	YES/NO	{line}	Reject messages from unexpected source chains
4	Emitter address validated	YES/NO	{line}	Reject messages from unexpected contracts on source chain
5	Sequence number replay check	YES/NO	{line}	Each VAA sequence should be processed exactly once
6	Consistency level validated	YES/NO	{line}	finalized vs confirmed - determines security guarantee
7	Payload format validated	YES/NO	{line}	Malformed payload handling - Move's bcs::from_bytes may abort on bad data
8	VAA resource authenticity	YES/NO	{line}	Is the VAA resource created by the Wormhole module (not user-supplied)?

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:

#	Check	Status	Location	Notes
1	Message source authenticated (signatures/proofs)	YES/NO	{line}
2	Source chain ID validated	YES/NO	{line}
3	Source contract/address validated	YES/NO	{line}
4	Replay protection (nonce/sequence/Table lookup)	YES/NO	{line}
5	Message freshness (timestamp check against timestamp::now_seconds())	YES/NO	{line}
6	Relayer authorization (if applicable)	YES/NO	{line}

---

Step 3: Timing Window Analysis

3a. Finality Asymmetry Model

Chain	Optimistic Finality	Confirmed Finality	Protocol Assumes
Aptos	~1s (BFT commit)	~1s (BFT - single round)	{which level?}
{Remote Chain}	{time}	{time}	{which level?}
Asymmetry Window	-	-	{max delay between chains}

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:

State Variable	Source Chain	Sync Trigger	Max Staleness	Aptos Functions Using It	Fresh Required?
{state}	{chain}	{event/periodic/manual}	{time estimate}	{list functions}	YES/NO

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:

#	Check	Status	Notes
1	Recipient CoinStore<CoinType> registered before transfer arrival?	YES/NO	If NO: who registers it? Who pays gas?
2	coin::register<CoinType> called for recipient?	YES/NO	If NO: transfer aborts with ECOIN_STORE_NOT_PUBLISHED
3	What happens if recipient has not registered the coin type?	{abort/skip/queue}	Aborted transfers may be lost if no recovery path
4	Are wrapped coin types (WrappedCoin<T>) registered before first bridge transfer?	YES/NO	First bridged token of a type requires coin creation + registration
5	Are resources created for cross-chain escrow (move_to)?	YES/NO	Check signer requirements - does the bridge module have the correct signer capability?
6	Is there a recovery mechanism for failed deliveries?	YES/NO	Lost funds if no recovery
7	Can an attacker front-run resource creation with a malicious resource?	YES/NO	Move type system prevents this for same types, but check wrapper types

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

#	Check	Status	Location	Notes
1	Replay protection exists	YES/NO	{line}	Method: {Table lookup/counter/EventHandle sequence/resource per message}
2	Replay check is BEFORE state changes	YES/NO	{line}	If after: partial replay possible
3	Out-of-order messages handled	YES/NO	{line}	Strict ordering vs any-order processing
4	Sequence gaps handled	YES/NO	{line}	What if message N+1 arrives before N?
5	Table storage sized for growth	YES/NO	{line}	Table<u64, bool> grows unboundedly - gas cost implications
6	Double-spend across chains	YES/NO	{line}	Same asset spent on both chains during relay

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:

#	Check	Status	Notes
1	Price freshness validated on Aptos side (timestamp::now_seconds() - price_timestamp < MAX_STALENESS)	YES/NO	Max acceptable age?
2	Price source authenticated	YES/NO	Can fake price be relayed?
3	Price deviation bounds	YES/NO	Max delta from last known price?
4	Fallback if relay is delayed/offline	YES/NO	What happens to price-dependent operations?
5	Flash loan on source chain can manipulate relayed price	YES/NO	Is source chain price spot or TWAP?

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

Field	Required	Description
bridge_inventory	yes	All cross-chain messaging infrastructure
verification_audit	yes	VAA/message verification completeness
timing_windows	yes	Asymmetry windows with duration estimates
resource_creation	yes	Recipient resource requirements and failure modes
replay_protection	yes	Nonce/sequence management assessment
price_relay_audit	if applicable	Cross-chain price freshness and manipulation risk
arbitrage_viability	yes	Quantified attack profitability or NOT_VIABLE
finding	yes	CONFIRMED / REFUTED / CONTESTED
evidence	yes	Code locations with line numbers
step_execution	yes	Status for each step

---

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)

Step	Required	Completed?	Notes
1. Identify Cross-Chain Messaging Infrastructure	YES
2. Cross-Chain Message Verification Audit	YES
3. Timing Window Analysis (both directions)	YES
4. Resource Creation Requirements	YES
5. Nonce and Sequence Management	YES
6. Cross-Chain Price Relay Audit	IF price relay detected
7. Quantify Arbitrage Viability	YES

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