/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? | |----------------|--