cross-chain-timing

name	cross-chain-timing
description	Type Thought-template (instantiate before use) - Trigger Pattern bridge|wormhole|axelar|layerzero|sui_bridge|cross_chain|relay|vaa|guardian|emitter|ccip

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}:

#	Function	Module	Direction	Bridge Protocol	State Synced	Trigger
1	{func}	{module}	OUTBOUND/INBOUND	{protocol}	{what state}	{when sent}

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:

Component	Function/Object	Purpose	Location
VAA Verification	vaa::parse_and_verify()	Guardian signature verification	{module:line}
Message Posting	publish_message()	Send message from Sui	{module:line}
Token Bridge	complete_transfer() / create_wrapped()	Token bridging	{module:line}
Emitter Object	Shared or owned emitter state	Message source identity	{module:line}

Sui Bridge (Native) Inventory

If the native Sui Bridge is detected:

Component	Function/Object	Purpose	Location
Bridge Committee	Shared committee object	Validator attestation	{module:line}
Message Verification	verify_and_execute()	Committee signature check	{module:line}
Token Transfer	Bridge treasury operations	Lock/unlock bridged tokens	{module:line}

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)

#	Check	Status	Location	Notes
1	Guardian signature count >= quorum (13/19)	YES/NO	{line}	Does protocol 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
5	Sequence number replay check	YES/NO	{line}	Each VAA should be processed exactly once
6	Consistency level validated	YES/NO	{line}	finalized vs confirmed
7	Payload format validated	YES/NO	{line}	Malformed payload handling
8	VAA object authenticity	YES/NO	{line}	Is VAA object from the actual Wormhole package? Type check on package address.

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:

#	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 vs clock::timestamp_ms)	YES/NO	{line}
6	Relayer authorization (if applicable)	YES/NO	{line}

---

Step 3: Timing Window Analysis

3a. Finality Asymmetry Model

Chain	Optimistic Finality	Checkpointed Finality	Protocol Assumes
Sui	~400ms (execution)	~2-3s (checkpoint)	{which level?}
{Remote Chain}	{time}	{time}	{which level?}
Asymmetry Window	--	--	{max delay between chains}

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:

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

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:

#	Check	Status	Notes
1	Recipient object/account exists before transfer arrival?	YES/NO	Who creates it? Who pays gas?
2	Are wrapped/bridged coin types created correctly?	YES/NO	TreasuryCap held by bridge, OTW consumed correctly?
3	What happens if recipient cannot receive the object?	{revert/queue/escrow}	Reverted transfers may be lost on source chain
4	Can attacker manipulate shared objects between message arrival and execution?	YES/NO	Consensus ordering is non-deterministic from user's perspective
5	Are bridged asset objects shared or owned?	{shared/owned}	Shared: contention risk. Owned: only recipient can use.
6	Is there a claim/complete mechanism or auto-delivery?	{claim/auto}	Claim: user must submit tx. Auto: relayer delivers.

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

#	Check	Status	Location	Notes
1	Replay protection exists	YES/NO	{line}	Method: {Table<Hash,bool> / dynamic field / counter / unique object 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	Replay storage bounded	YES/NO	{line}	Table/Bag may grow unbounded (DoS via storage cost)
6	Double-spend across chains	YES/NO	{line}	Same asset spent on both chains during relay

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.

---

Step 6: Cross-Chain Price Relay Audit

If oracle prices are relayed cross-chain:

#	Check	Status	Notes
1	Price freshness validated on Sui side (clock::timestamp_ms)	YES/NO	Max acceptable age?
2	Price source authenticated (bridge signature)	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 price spot or TWAP?

Staleness calculation: relay_staleness = source_price_age + bridge_latency + sui_processing

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

---

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} minutes)
3. Attacker executes on Sui at {EXPLOIT_FUNCTION} using stale {STALE_STATE}
   - Sui transaction cost is very low (<$0.01 per tx)
   - PTB allows multi-step atomic exploitation
4. Sync message arrives on Sui, state updates
5. Profit = {PROFIT_FORMULA}
6. Cost = bridge_fees + Sui_gas + capital_lockup_cost
7. Viable if: profit > cost AND repeatable

Sui cost model: Sui gas is paid in SUI, typically very low (<$0.01 per tx). Cost barrier is primarily bridge fees and capital requirements. Low gas makes small-margin attacks more viable than on EVM.

---

Key Questions (must answer all)

1. What is the realistic sync latency for {BRIDGE_PROTOCOL} on Sui? (cite documentation)
2. Can an attacker monitor {SOURCE_CHAIN} and exploit stale state on Sui (or vice versa) before sync completes?
3. What is the maximum {STALE_STATE} change during normal operation within the sync window?
4. Is this attack repeatable or one-time?
5. Does the protocol validate message timestamps against clock::timestamp_ms()?
6. Are bridged token TreasuryCaps exclusively held by the bridge?
7. Is replay protection complete (covers all message types, all chains)?
8. Are cross-chain prices validated for freshness AND deviation bounds?

---

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 costs
• Rate limiting: If operations have cooldowns longer than sync latency, window may not be exploitable
• Timestamp freshness check: If protocol compares message timestamp against clock::timestamp_ms() and rejects stale messages, window is bounded
• Epoch-aligned sync: If sync happens once per epoch (~24h) and this is documented/intended, staleness within an epoch may be by design
• Bridge-level protections: Some bridges have rate limiting or value caps that bound exploitation

---

Instantiation Parameters

{CONTRACTS}           -- List of modules to analyze
{BRIDGE_PROTOCOL}     -- Specific bridge (Wormhole, Axelar, Sui Bridge, custom)
{SYNC_POINT}          -- Function where inbound sync occurs
{DEPENDENT_FUNCTIONS} -- Functions that read synced state
{SOURCE_CHAIN}        -- Chain where state originates
{DEST_CHAIN}          -- Chain where stale state is exploited (may be Sui)
{MONITOR_POINT}       -- What attacker monitors on source chain
{EXPLOIT_FUNCTION}    -- Function attacker calls using stale state
{STALE_STATE}         -- Specific state variable that becomes stale
{PROFIT_FORMULA}      -- (new_value - old_value) * position_size
{MAX_DELTA}           -- Maximum observed state change during sync window
{LATENCY}             -- Estimated bridge latency in minutes

---

Output Schema

Field	Required	Description
bridge_inventory	yes	All cross-chain messaging infrastructure
verification_audit	yes	Message verification completeness
timing_windows	yes	Asymmetry windows with duration estimates
object_creation	yes	Bridged asset object 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

---

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		All cross-chain calls enumerated
2. Cross-Chain Message Verification Audit	YES		VAA/message verification complete
3. Timing Window Analysis (both directions)	YES		Cite bridge documentation
4. Object Creation Requirements	YES		Bridged token TreasuryCap security
5. Nonce and Sequence Management	YES		Replay storage boundedness
6. Cross-Chain Price Relay Audit	IF price relay detected
7. Quantify Arbitrage Viability	YES		Profit vs cost with real numbers

Cross-Reference Markers

After Step 2: If message 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 bridged token TreasuryCap is not exclusively held by bridge -> cross-reference with TYPE_SAFETY Coin/Balance section.

After Step 6: Feed price staleness findings to ORACLE_ANALYSIS if applicable.

If any step skipped, document valid reason (N/A, no cross-chain messaging, single chain only).