PRODUCTS

Per-chain structural regime (12 signed S/D codes) computed on a rolling 30-day baseline. Each L1 has independent observables (rhythm, beacon participation where applicable, structural cadence) and an independent Delta.

Solana sits on a different substrate physics family from EVM chains (slot-based 400ms cadence, leader rotation, vote economics). Calibration on Solana requires its own observable set distinct from EVM chains, programmed for 2026-Q3.

Per-rollup regime tracking sequencer publish latency P97, batch posting cadence, and inclusion behavior. Anchored to Ethereum L1 finality for parent-chain context.

Each CCIP lane has its own OnRamp / OffRamp / RMN configuration. ETH → ARB and ARB → ETH are two physically distinct lanes with separate contracts and potentially different DON commit cadences. Each direction is processed as an independent signal.

Four lanes operate on Chainlink CCIP V1.6 chain-based architecture (ETH ↔ ARB and ETH ↔ BASE). The six remaining lanes operate on CCIP V1.5 lane-based architecture. The two protocol versions emit different events at the source (CCIPSendRequested V1.5 vs CCIPMessageSent V1.6) and the destination (ExecutionStateChanged with different ABIs and indexed fields); both versions are decoded by the same collector and surfaced uniformly in the panel.

ETH ↔ SOL CCIP is the only lane in the matrix that crosses substrate physics families (EVM blocks vs Solana slots). Solana support is native to CCIP V1.6. Treated as a primary observability target once the Solana side of the CCIP infrastructure (dual-RPC capture, program log parsing) is integrated.

CCIP capability level: per_message_attested on both V1.5 and V1.6 lanes. Source send and destination execute are matched per message via the bytes32 messageId (same canonical join key on both versions). Latency P90 is computed on captured messages. crypto.anchor is null today; DON multi-sig CommitReport capture is the next step toward per_message_crypto_anchored.

CCTP attestation latency is dominated by source-chain finality: the Circle Iris V2 service waits for source confirmation before issuing the attestation. ETH→X and X→ETH therefore have fundamentally different latency distributions because L1 finality (~13 min) is much slower than L2 soft confirmations. Scope migrated to V2 on 2026-05-27 (Circle V1 sunset 2026-07-31): 10 ETH-paired bidirectional routes (ETH ↔ ARB / BASE / OP / AVAX / POL). L2-to-L2 routes are dropped from V2 scope.

Each attested message is captured with its Circle ECDSA signature (65-byte secp256k1). This signature is independently verifiable against Circle's published attester public key, anchoring CCTP route signals in a cryptographic chain of trust distinct from the Invarians HMAC envelope. Per-message attestations are retrievable via /v2/cctp/attestation/{nonce} — V2 keys retrieval by the Circle-attributed nonce (bytes32), since the V2 protocol no longer carries a deterministic at-burn message hash.

Standard / Fast asymmetry-by-design. Each CCTP V2 route carries two execution modes. Invarians treats them asymmetrically because we serve agents whose temporality is slow and finality-bound — a one-hour aggregation window does not represent Fast (whose nominal latency lives in seconds), and Fast is contraindicated for the RWA execution context anyway (finality risk a settlement agent cannot take). The panel exposes Standard at the top of each bridge entry (metrics) as the canonical mode for the audience, and Fast in a subordinated observed_fast_mode object documented as "observed but outside the RWA calibration frame".

Classification under BRIDGE_STATE_STRUCTURAL_v1.2. The corridor flips to BS2 when the Fast-mode window invariant breaches its calibrated envelope (success rate, fallback rate over the 1 h window), or when invariant I5 detects a Standard-mode message older than 48 h without an Iris attestation. The 48 h cap is mechanically derived (Polygon-Heimdall pathological reorg 4 h + Ethereum non-finalization upper bound 24 h + Iris attestation envelope 1 h, times 1.5 safety margin) and immutable unless Circle publishes a Standard-mode SLA that supersedes it.

ETH ↔ SOL CCTP is the only route where the source event lives in EVM logs on one side and in a Solana program log on the other. The Iris V2 attestation client is chain-agnostic (keyed by (source_domain, source_tx_hash), both delivered by Circle regardless of source substrate), so the integration cost sits in the source / destination capture path, not in attestation handling. Targeted for 2026-Q3.