Cross Chain Timing

---
name: "cross-chain-timing"
description: "Trigger Pattern wormhole|allbridge|debridge|bridge|cross_chain|vaa|guardian|emitter|LayerZero|CCIP|nonce.sequence|relay - Inject Into Breadth agents, depth-external"
---

# CROSS_CHAIN_TIMING Skill (Solana)

> **Trigger Pattern**: `wormhole|allbridge|debridge|bridge|cross_chain|vaa|guardian|emitter|LayerZero|CCIP|nonce.*sequence|relay`
> **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 Solana and other chains, account creation requirements, nonce/sequence replay protection, and cross-chain price relay staleness.

Solana's fast finality (~400ms optimistic, ~30s confirmed/rooted) 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 Solana.

---

## Step 1: Identify Cross-Chain Messaging Infrastructure

Find all cross-chain messaging calls and infrastructure:

| # | Bridge/Protocol | Direction | Solana Instruction | Remote Chain | Message Type |
|---|----------------|-----------|-------------------|-------------|-------------|
| 1 | {Wormhole/Allbridge/deBridge/custom} | {Solana->Remote / Remote->Solana} | {instruction name} | {Ethereum/Arbitrum/etc.} | {token transfer / state sync / price relay / governance} |

### Wormhole-Specific Inventory
If Wormhole is detected:

| Component | Instruction/Account | Purpose | Location |
|-----------|-------------------|---------|----------|
| VAA Verification | `verify_signatures` + `post_vaa` | Guardian signature verification | {file:line} |
| Message Posting | `post_message` | Send message from Solana | {file:line} |
| Token Bridge | `complete_transfer` / `create_wrapped` | Token bridging | {file:line} |
| Emitter Account | PDA (emitter seeds) | Message source identity | {file:line} |

### Allbridge/deBridge-Specific Inventory
If Allbridge or deBridge detected:

| Component | Account/Instruction | Verification Method | Location |
|-----------|-------------------|-------------------|----------|
| Message Account | {account type} | {signature/merkle/optimistic} | {file:line} |
| Relayer | {relayer constraint} | {how relayer is validated} | {file:line} |
| Nonce Tracking | {nonce account} | {replay prevention method} | {file:line} |

---

## Step 2: Cross-Chain Message Verification Audit

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

### 2a. Wormhole VAA Verification Checklist

| # | Check | Status | Location | Notes |
|---|-------|--------|----------|-------|
| 1 | Guardian signature count >= quorum (13/19) | YES/NO | {line} | Check: does protocol verify `vaa.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 |
| 8 | VAA account owner is Wormhole program | YES/NO | {line} | Prevents fake VAA account substitution |

**Critical**: Missing checks 1-5 = **CRITICAL** (arbitrary cross-chain message injection). Missing checks 6-8 = **HIGH** (message quality/integrity issues).

### 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/bitmap) | YES/NO | {line} | |
| 5 | Message freshness (timestamp/block check) | 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 |
|-------|--------------------|--------------------|-----------------|
| Solana | ~400ms (processed) | ~30s (rooted/finalized) | {which level?} |
| {Remote Chain} | {time} | {time} | {which level?} |
| **Asymmetry Window** | - | - | **{max delay between chains}** |

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

### 3b. Stale State Usage Trace

For each piece of state synced cross-chain:

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

For each dependent instruction on Solana:
- Is fresh state required or is stale acceptable?
- What decisions are made with potentially stale data?
- Can an attacker exploit the staleness window?

### 3c. Solana-to-Remote Timing Attack

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

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

### 3d. Remote-to-Solana Timing Attack

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

---

## Step 4: Account Creation Requirements

Cross-chain operations on Solana have unique account requirements:

| # | Check | Status | Notes |
|---|-------|--------|-------|
| 1 | Recipient token account exists (ATA) before transfer arrival? | YES/NO | If NO: who creates it? Who pays rent? |
| 2 | `init_if_needed` used for receiver accounts? | YES/NO | If YES: check for re-initialization risk |
| 3 | What happens if recipient account does not exist? | {revert/skip/queue} | Reverted transfers may be lost |
| 4 | Can attacker close recipient ATA before message arrives? | YES/NO | Token account close + re-create with different owner |
| 5 | Are PDAs used for cross-chain escrow? | YES/NO | Check PDA seed uniqueness per message |
| 6 | Is there a recovery mechanism for failed deliveries? | YES/NO | Lost funds if no recovery |

**Critical Solana pattern**: Cross-chain token transfers require the destination ATA to exist. If it does not:
- Some bridges revert and the tokens are stuck on the source chain
- Some bridges create the ATA (who pays rent-exempt minimum?)
- Some bridges queue the transfer for later claim (is the queue unbounded?)

---

## Step 5: Nonce and Sequence Management

| # | Check | Status | Location | Notes |
|---|-------|--------|----------|-------|
| 1 | Replay protection exists | YES/NO | {line} | Method: {bitmap/counter/hash set/PDA 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 | Nonce account sized for growth | YES/NO | {line} | Bitmap may run out of space |
| 6 | Double-spend across chains | YES/NO | {line} | Same asset spent on both chains during relay |

**Solana replay patterns**:
- **PDA per message**: Derive PDA from message hash/sequence. If PDA exists, already processed. Reliable but creates many accounts.
- **Bitmap account**: Store processed sequences as bits. Space-efficient but must handle bitmap growth.
- **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 Solana side | 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 + solana_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_ESTIMATE})
3. Attacker executes on Solana at {EXPLOIT_INSTRUCTION} using stale {STALE_STATE}
4. Sync message arrives, state updates on Solana
5. Profit = {PROFIT_FORMULA}
6. Cost = bridge_fees + Solana_tx_fees + capital_lockup_cost + Jito_tip
7. Viable if: profit > cost AND repeatable
```

**Solana cost model**: Solana transaction fees are very low (~5000 lamports base + priority fee). The primary cost is capital lockup and bridge fees, not gas. This makes small-margin attacks more viable on Solana 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 Solana? (Solana'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 accounts pre-created, or must they be created on arrival?
6. Is replay protection complete (covers all message types, all chains)?
7. Can an attacker exploit Solana's fast finality to act before the remote chain sees Solana state?
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 bridge fees
- **Rate limiting**: If operations have cooldowns longer than sync latency, window may not be exploitable
- **Confirmed finality enforcement**: If protocol requires rooted/finalized Solana confirmations before processing, timing window is ~30s (larger but more reliable)
- **Bridge-level protections**: Some bridges (Wormhole) have rate limiting or value caps that bound exploitation

---

## Instantiation Parameters
```
{CONTRACTS}           - Programs to analyze
{BRIDGE_PROTOCOL}     - Specific bridge (Wormhole, Allbridge, deBridge, custom)
{SYNC_POINT}          - Instruction where cross-chain state is consumed
{DEPENDENT_FUNCTIONS} - Instructions that read synced state
{SOURCE_CHAIN}        - Chain where state originates
{MONITOR_POINT}       - What attacker monitors on source chain
{EXPLOIT_INSTRUCTION} - Instruction attacker calls on Solana
{STALE_STATE}         - Specific state that becomes stale
{LATENCY_ESTIMATE}    - Realistic bridge latency
```

---

## 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 |
| account_creation | yes | Recipient account 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 |

---

## 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. Account 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 account creation can fail -> cross-reference with ACCOUNT_LIFECYCLE skill for stranded asset analysis (Rule 9).

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