FOUNDATIONS

Mempool observations · raw price volatility · liquidity depth · transaction intent signals · gas market narrative.

τ texture (long-term structural regime, 5–13 h window) · π pressure (short-term operational friction, ~5 min window) · their divergence. The single exception on the demand side: the echo of activity (sigma, size, transaction count) measured on confirmed blocks, not on intent flow.

There is no cross-chain normalization. Every threshold is derived from each chain's own multi-year historical distribution. What constitutes an anomaly on Ethereum is calibrated from Ethereum data. What constitutes an anomaly on Solana is calibrated from Solana data.

The data is what Invarians produced at computed_at. It is non-repudiable on the server side, integrity-protected end-to-end, and reproducible against the canonical JSON form (sorted keys).

That the underlying observation is correct (calibration responsibility) · that the regime classification is appropriate for the agent's policy (interpretation responsibility) · that the chain is safe to act on (fitness-for-action responsibility, see Primitive 3).

The HMAC envelope includes "anchor": null in v2.0. Once the InvariansAnchor contract is deployed on Arbitrum, each canonical payload hash will be batch-anchored on-chain (Merkle root with epoch boundary). The anchor field will then contain { tx_hash, block_number, contract }, providing a permissionless integrity check independent of the HMAC server.

S2D1 is the regime with the highest diagnostic value. It captures infrastructure events, validator behavior anomalies, timing disruptions, network-layer issues, that produce no fee signature. A fee monitor would report S1D1 during an S2D1 period. This is the core of the two-axis approach: the structural and demand layers must be read independently to detect it.

D2± captures composition asymmetry that the legacy 4-state grid misses. Size-up + tx-down (or vice versa) means the chain is processing fewer but larger transactions than baseline (the typical profile of a bot cascade on Aave or Compound, MEV searcher dominance, or stablecoin depeg arbitrage HFT). The first such pattern observed on Invarians was the rsETH cascade of 2026-04-18 on Ethereum: with signed codes active, the panel would have emitted S1D2- at 14h UTC instead of the legacy S1D1.

Each classifying observable carries two exponential moving averages: a short EMA (~10 h half-life) tracking the current state, and a long EMA (~30 d half-life) representing the chain's structural baseline. The shift = ratio_short - ratio_long measures how far the chain currently deviates from its 30-day pace.

The shift alone tells you the magnitude of deviation. Two derived fields tell you whether it is amplifying or reverting:

shift_delta = shift_now - shift_prev  — direction of the value movement between cycles.

shift_magnitude_delta = |shift_now| - |shift_prev|  — whether the deviation is growing (positive) or shrinking (negative), regardless of which side of the baseline.

An agent that reads only the regime sees a snapshot. An agent that reads each per-metric shift, shift_delta and shift_magnitude_delta in addition can distinguish situations of the form:

• Regime D2+, shift_magnitude_delta > 0 on tx → demand surge whose divergence is currently amplifying on this metric
• Regime D2+, shift_magnitude_delta < 0 on tx → divergence resorbing on this metric, return toward baseline in progress
• Regime D2-, shift_magnitude_delta > 0 on size → demand starvation whose divergence is deepening on this metric
• Regime D2-, shift_magnitude_delta < 0 on size → starvation resorbing on this metric

These readings are raw per-metric inputs, not validated anticipation signals. The reading is left to the agent's policy — Invarians provides the data per axis observable, not a threshold for action. The composite axis aggregate exposed under JSON key drift is deprecated_unvalidated in v3 and should not be used as a fitness signal.

The Delta is a substrate-physics concept. Chains evolve under sustained agentic load on the time scale of weeks: structural rhythm slowly shifts, demand baselines slowly migrate, validator participation slowly trends. The 10 h / 30 d EMA pair captures exactly that scale.

Bridges are operational pipelines, not substrates. Their fitness-for-action is fully captured by current state (BS1 / BS2), per-message latency P90 / P99, success rate, and crypto anchor verifiability — at the cycle granularity of the collector (10 min). Forcing a substrate-style drift onto operational latency would conflate two different physical phenomena. The three-primitive architecture therefore exposes Delta on L1 and L2 entries only; bridge entries expose state, metrics, and crypto pointer without a drift block.

L1/L2 regimes (SxDx) reflect structural conditions, inertial, slow-moving, derived from multi-year calibration. Bridge state (BS1/BS2) reflects operational throughput, fast-moving, binary, measured in seconds to minutes. The distinction is architectural. Mixing them would distort both signals.

Each CCTP V2 message is captured individually from the source-chain DepositForBurn V2 event (a single log carries the requested mode in topic3 via minFinalityThreshold and the destination domain in data — V2 no longer requires a separate MessageTransmitter.MessageSent decode at burn time). The Circle ECDSA secp256k1 attestation signature (65 bytes) is fetched from the Iris V2 API once the message is attested, together with the Circle-attributed nonce (bytes32, the V2 join key — V2 does not have a deterministic at-burn messageHash like V1 did). The signature is retrievable via GET /v2/cctp/attestation/{nonce} and is independently verifiable against Circle's published attester public key, providing a cryptographic chain of trust distinct from the Invarians HMAC envelope.

Each route carries two execution modes. The panel reflects an intentional asymmetry-by-design: metrics.* at the top of each bridge entry exposes Standard (the RWA-canonical mode); observed_fast_mode.* exposes Fast as observed data, explicitly subordinated. The 1 h aggregation window matches Standard's 13-30 min nominal latency natively; Fast (8-30 s nominal) is too granular for this window and contraindicated for RWA execution context anyway (finality risk). A confounded_by_iris_downtime boolean marks rows the BS1/BS2 calibration must exclude (Iris instrument degraded during the window, not the bridge substrate). A pending queue handles the asymmetry between collector cycle (10 min) and source-chain finality (~13-19 min on Ethereum-anchored chains): messages whose Iris attestation arrives after their first observation are re-polled at each subsequent cycle until attested or 2 h expiry. An hourly out-of-band sweep re-polls every NULL-signature row beyond that window, so no Iris-attested message is lost between 2 h and the I5 cap.

Standard mode is the canonical RWA-execution mode for CCTP V2. Its nominal envelope (13-30 min) is too short to drive a window-only invariant in the presence of a long, legitimate physical tail. Methodology v1.2 therefore adds an event-based invariant: any Standard-mode message whose source_block_timestamp is older than 48 h and that still lacks an attestation signature from Iris flips the corridor to BS2. There is no rolling window, no statistical baseline, no quantile, only a binary structural check at the message level.

The 48 h cap is mechanically derived, not calibrated on data: Polygon-Heimdall pathological reorg envelope 4 h + Ethereum non-finalization upper bound 24 h + Iris attestation envelope 1 h, times a 1.5 safety margin. It coincides with the LATENCY_WINDOW_S["Standard"] = 48 × 3600 constant of the 2025 signed calibration corpus. The cap is immutable unless Circle publishes an explicit Standard-mode SLA that supersedes it.

Methodology hash: b46793407f9b1eabe1bbbdc5f0e70442906295ae36a556e647829e754548b351 (bridge_state_methodology.md, v1.2). Ed25519 ×3 + OpenTimestamps Bitcoin pre-engagements published in the calibration registry.

Each CCIP message is captured individually. On V1.5 lanes (6 lanes: OP / POL / AVAX in both directions), source CCIPSendRequested event on the lane-specific OnRamp + destination ExecutionStateChanged on the lane-specific OffRamp, matched per message by the bytes32 messageId (V1.5 emits messageId in topic[2]). On V1.6 lanes (4 lanes: ETH ↔ ARB and ETH ↔ BASE), source CCIPMessageSent event on the chain-shared OnRamp (one OnRamp per source chain handles all destinations, dispatched by destChainSelector in topic[1] indexed) + destination ExecutionStateChanged on the chain-shared OffRamp (one OffRamp per destination chain handles all sources, with messageId in topic[3] indexed). Both versions produce the same downstream record; the collector dispatches on the lane's protocol version.

Real send-to-execute latency per lane per direction is derived from the match. Bridge entry exposes metrics.execute_latency_p90_s computed on per-message latencies, plus metrics.sequence_gap and metrics.messages_confirmed_1h. RMN.isCursed() per chain remains a safety boolean. crypto.anchor is null today (no per-message cryptographic anchor captured yet for CCIP). Each captured message is retrievable via GET /v2/ccip/message/{message_id}.

A pending queue handles the asymmetry between collector cycle and CCIP end-to-end latency, mirroring the CCTP pending model.

For every axis (structural, demand) the panel reports three numbers in a single object exposed under the JSON key drift: magnitude, raw delta, and magnitude_delta. Magnitude is the maximum absolute shift across the axis observables (rhythm, continuity, beacon_participation on ETH; sigma, size, tx, complexity, gas_complexity on demand). Magnitude_delta tells whether that maximum shift is widening (positive) or shrinking (negative) between cycles. Per-metric blocks (in diagnostic mode) expose the same triplet (shift, shift_delta, shift_magnitude_delta) at observable granularity.

The JSON key historically named drift at the axis level was originally documented as a "fitness-for-action" anticipation signal. Independent testing on the 2025 ETH-ARB-CCTP and ETH-OP-CCTP corpora, with Benjamini-Hochberg FDR correction at α = 0.05 over a 648-configuration grid, did not confirm this aggregation as a validated orientation signal. The v3 redesign replaces it with explicit per-chain precursors carrying their calibration metadata (axis, threshold, lead, outcome, lift). The axis aggregate remains exposed for one release cycle, flagged predictive_status: "deprecated_unvalidated" in the payload, and will be retired in the v3 cutover. The empirical reading is documented in the Delta calibration research note.

Naming clarification. The canonical Invarians taxonomy reserves the word drift for the slow movement of the baseline itself (the long EMA migrating over months under protocol upgrades and agentic load), not for the per-axis aggregate of current shifts. The JSON key drift is a historical artifact of the v2.0 payload and is retained for backward compatibility only. See how-it-works §2 Drift and §3 Divergence for the canonical definitions.

Invarians certifies what the infrastructure is and where it is drifting. It does not prescribe what the agent should do. Execution policy, thresholds, risk tolerance, fallback logic — belongs to the agent. The three primitives provide the factual basis for that policy. The decision does not.