# Cross Chain Timing

> Type Thought-template (instantiate before use) - Research basis Multi-block arbitrage windows, bridge latency exploitation

- Skill: `plamentsv/cross-chain-timing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add plamentsv/cross-chain-timing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/plamentsv/cross-chain-timing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: plamentsv (https://skillmd.com/u/plamentsv)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/plamentsv/cross-chain-timing

---


# Skill: Cross-Chain Timing Analysis

> **Type**: Thought-template (instantiate before use)
> **Research basis**: Multi-block arbitrage windows, bridge latency exploitation

## Trigger Patterns
```
bridge|L1|L2|tunnel|messenger|crossChain|sendMessage|receiveMessage|
_processMessageFrom|LayerZero|CCIP|Wormhole|Arbitrum|Optimism
```

## Reasoning Template

### Step 1: Identify Sync Mechanism
- Find all cross-chain messaging calls in {CONTRACTS}
- For each call, determine:
  - What state is being synced? (rates, balances, epochs, totals)
  - What triggers the sync? (every operation, periodic, manual)
  - What bridge/messenger is used?

### Step 2: Measure Timing Window
- Research {BRIDGE_PROTOCOL} documentation for realistic latency
- Typical ranges: optimistic rollups (10-30 min), zk-rollups (minutes), standard bridges (20-60 min)
- Document: submission -> finality -> execution timeline

### Step 3: Trace Stale State Usage
- From {SYNC_POINT}, identify all state that depends on synced values
- For each dependent operation at {DEPENDENT_FUNCTIONS}:
  - Is fresh state required or is stale acceptable?
  - What decisions are made with potentially stale data?

### Step 4: Model Arbitrage Sequence
```
1. Attacker monitors {SOURCE_CHAIN} for state changes at {MONITOR_POINT}
2. State change triggers sync message (latency window opens)
3. Attacker executes on {DEST_CHAIN} at {EXPLOIT_FUNCTION} using stale {STALE_STATE}
4. Sync message arrives, state updates
5. Attacker profits: {PROFIT_CALCULATION}
```

### Step 5: Quantify Viability
- Maximum {STALE_STATE} delta during sync window: {MAX_DELTA}
- Profit calculation: {PROFIT_FORMULA}
- Cost calculation: gas + bridge fees + capital lockup
- Viable if: profit > cost AND repeatable

## Key Questions (must answer all)
1. What is the realistic sync latency for {BRIDGE_PROTOCOL}? (cite documentation)
2. Can an attacker monitor {SOURCE_CHAIN} and front-run sync on {DEST_CHAIN}?
3. What is the maximum {STALE_STATE} change during normal operation?
4. Is this attack repeatable or one-time?

## Common False Positives
- **Monotonic state**: If {STALE_STATE} only increases (never decreases), arbitrage may not be profitable in both directions -- verify directionality
- **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
- **Same-block dependency**: If dependent operation requires same-block freshness (checked via block number), stale state is rejected

## Instantiation Parameters
```
{CONTRACTS}           -- List of contracts to analyze
{BRIDGE_PROTOCOL}     -- Specific bridge (LayerZero, CCIP, Arbitrum Messenger, etc.)
{SYNC_POINT}          -- Function/event where sync occurs
{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 that becomes stale
{PROFIT_CALCULATION}  -- Formula for attacker profit
{MAX_DELTA}           -- Maximum observed state change
{PROFIT_FORMULA}      -- (new_value - old_value) * position_size
```

## Output Schema
| Field | Required | Description |
|-------|----------|-------------|
| sync_mechanism | yes | How state is synced (bridge, function, event) |
| latency_estimate | yes | Realistic sync latency with source |
| stale_operations | yes | List of operations using potentially stale state |
| arbitrage_sequence | yes | Step-by-step attack if viable |
| profit_viability | yes | VIABLE / NOT_VIABLE / NEEDS_VERIFICATION |
| finding | yes | CONFIRMED / REFUTED / NEEDS_DEPTH |
| evidence | yes | Code locations with line numbers |