GLOSSARY

An on-chain execution context is a cryptographically signed attestation of the structural regime of blockchain infrastructure at a given time. It is produced by Invarians and consumed by AI agents before executing on-chain operations.

An execution context attestation is not a recommendation. Invarians certifies a state. The agent applies its own execution policy.

A structural regime describes the operating state of a blockchain over a structural time window (~1 hour). It is not an event. It is a certified state of the infrastructure substrate, derived from two independent axes: τ (structural rhythm) and π (demand pressure).

The regime is measured over a calibrated structural window with multi-confirmation hysteresis. A regime change takes ~3 hours to confirm. MEV, arbitrage, and short-term fee spikes do not create false regime changes.

Limit: the regime describes substrate dynamics under observation, not absence of substrate. The regime classification is computed on the blocks observed during each hour. A sequencer downtime that suppresses block production leaves no blocks to classify on the affected hour, so the matrix produces no regime signal for that hour (the regime stays at S1D1 by construction, since there is nothing to qualify as structural divergence). Downtime detection is the responsibility of the per-entry status field on each panel entry (OK, STALE, UNAVAILABLE, UNCALIBRATED), which is orthogonal to the regime code. An agent reading the panel inspects both: status for substrate availability, regime for substrate dynamics conditional on availability.

S2D1 is the most operationally significant regime for AI agents. It describes structural degradation (S2) with no apparent demand pressure (D1). No gas spike. No mempool congestion. No fee monitor alert. The chain appears calm at the surface.

S2D1 has been observed during:

An AI agent acting during S2D1 without a certified execution context is acting on incomplete information.

An infrastructure-aware agent is an autonomous on-chain agent that consumes a certified execution context before deciding to execute, defer, or reroute. It does not rely solely on gas price or mempool depth. It reads the structural regime of the infrastructure it operates on.

The operational state of a cross-chain bridge, measured independently from the L1/L2 structural regime. Bridge state is measured on a shorter window (5–15 min polling) because bridges can transition from healthy to congested faster than a structural regime change.

A semantic enum on each bridge entry that tells consumers the depth of signal captured for this bridge type. Added 2026-05-11 alongside the CCTP per-message attestation upgrade.

For each CCTP message that completes attestation through the Circle Iris service, a 65-byte ECDSA secp256k1 signature is emitted by Circle's attester. The Invarians CCTP collector captures this signature per message (since 2026-05-11) and stores it in ans_cctp_message_attestations. The signature is independently verifiable against Circle's published attester public key, providing a cryptographic chain of trust distinct from the Invarians HMAC envelope.

Exposed in the bridge entry as crypto.anchor = "circle_ecdsa" plus a retrieval pointer crypto.verifiable_via. The signature itself is retrievable via GET /v2/cctp/attestation/{message_hash} to keep the panel payload lean.

A queue of CCTP messages observed on the source chain but whose Iris attestation has not yet been issued at poll time. Handles the asymmetry between collector cycle (10 min) and source-chain finality (~13-19 min on Ethereum-anchored chains).

Each new CCTP message observed is inserted with attestation_signature = NULL. At every subsequent cycle, all NULL-signature rows of the route are re-polled against the Circle Iris API. When the attestation becomes available, the row is UPDATEd with the signature, the observed timestamp, and the latency in ms. Expiry is 2 h: messages whose signature does not arrive within that window are presumed rejected by Circle and not re-polled.

A bytes32 identifier unique to each CCIP message, present in the CCIPSendRequested event emitted by the source OnRamp and repeated in the ExecutionStateChanged event emitted by the destination OffRamp upon execution. The Invarians CCIP collector uses this messageId as the join key to match source send with destination execute, deriving real send-to-execute latency per lane per direction.

The full row is retrievable via GET /v2/ccip/message/{message_id}: source send metadata (sender, receiver, sequence_number, nonce, gas_limit, fee_token, source_tx_hash, source_block_*) and, when executed, destination metadata (dest_tx_hash, dest_block_*, execution_state). A status field reads "pending" or "executed". crypto_anchor is null today; will become "don_threshold_sig" once CCIP CommitReport DON multi-sig and Merkle inclusion proofs are captured.

A queue of CCIP messages observed on the source OnRamp but not yet matched against a destination ExecutionStateChanged event at poll time. Analogous to the CCTP pending queue, it handles the asymmetry between collector cycle (10 min) and CCIP end-to-end latency (typically a few minutes to tens of minutes depending on the lane and source-chain finality).

Each new CCIPSendRequested observed is inserted with dest_tx_hash = NULL. At every subsequent cycle, destination OffRamp logs are scanned for ExecutionStateChanged events matching pending messageIds. When matched, the row is UPDATEd with the destination tx hash, destination block number, destination block timestamp, and the execution state (0 Untouched, 1 InProgress, 2 Success, 3 Failure). Expiry is 2 h: messages still NULL beyond that window are assumed lost (lane misconfigured, RMN cursed, or out-of-scan) and are not retried.

A panel item becomes stale when Invarians has not refreshed the underlying data within its expected window (1h for L1/L2, 10m for bridges). Staleness is per-item: each entry in panel.l1[], panel.l2[], panel.bridges[] carries its own status. The global oracle_status flips to DEGRADED whenever any item is STALE or UNAVAILABLE (UNCALIBRATED does not trigger it).

The Pattern Reference is a historical record of all 32 possible execution contexts (4 L1 regimes × 4 L2 regimes × 2 bridge states), with observed frequencies and documented events for each combination. It is non-prescriptive — the agent reads the execution context, consults the Pattern Reference, and applies its own policy.

The current expected behavior of a chain or a bridge under no exceptional condition, measured along structural rhythm, demand pressure, and posting continuity. The nominal is not a fixed number. It evolves with the chain itself: protocol upgrades, application mix changes, and rising agentic load all reshape the underlying distribution. Invarians qualifies the nominal per chain, per layer and per bridge, through continuous calibration on a rolling baseline, and exposes the current state relative to that nominal.

The third primitive of the v2.0 API. Delta is the umbrella for every signal that measures how the current state of a chain or a bridge departs from its 30-day baseline. Two layers compose Delta. The per-metric layer exposes shift (signed deviation versus the 30-day baseline), shift_delta (change in the signed deviation between consecutive observations), and shift_magnitude_delta (change in the absolute deviation). The composite layer exposes axis-level drift aggregates (drift.structural, drift.demand) plus their own _magnitude_delta counterparts. Sign and magnitude are preserved at every level so an agent can read both the direction of the deviation and whether the deviation is amplifying or reverting. Drift and shift are themselves not primitives; they are observables that compose Delta. The primitive name is the umbrella.

Chain-type-exclusive calibration. Two corpora were tested in 2025 (ETH-ARB-CCTP and ETH-OP-CCTP) with a 648-configuration grid and Benjamini-Hochberg FDR correction. Each corpus produces its own validated precursors (six on ARB with lift 1.53 to 2.36x; one on OP with lift 3.72x), and the two sets are disjoint. Configurations do not transfer across corpora. The v3 redesign replaces the composite Delta block with an explicit precursors[] array scoped per chain. Documented in the research note.

A precursor is a named, calibrated boolean flag exposed on an L1 or L2 panel entry that fires when a specific substrate shift axis enters an amplifying mode statistically validated as anticipating a specific bridge layer outcome at a documented lead time. Each precursor carries explicit calibration metadata: the axis it reads (e.g. structural.sequencer_publish_latency), the threshold on shift_magnitude_delta, the K consecutive hours required, the lead window in hours, the predicted outcome, the validated lift, precision, and alert rate from the calibrating corpus, and the cross-chain status. Precursors are scoped per chain: six configurations were validated on ETH-ARB-CCTP 2025 with combined Benjamini-Hochberg FDR at alpha=0.05 and lift 1.53 to 2.36x; one configuration was validated on ETH-OP-CCTP 2025 with lift 3.72x. Configurations validated on one corpus do not transfer to the other (Delta calibration is chain-type-exclusive). Documented in the research note.

The change of a chain's nominal over time. Distinct from a short-term deviation, where the chain temporarily falls outside its window and returns. Drift is structural: the window itself moves. Ethereum's nominal post-Dencun is statistically different from its nominal pre-Dencun. Drift is intrinsic to evolving systems and must be tracked, not assumed away. Invarians measures drift on rolling windows so an agent's reference frame stays current with the chain it acts on. In the v2.0 API, drift was exposed as a composite per axis (drift.structural, drift.demand) inside the Delta primitive. The v2.0 composite did not pass independent validation on the 2025 corpora; v3 replaces it with explicit per-chain precursors carrying their calibration metadata.

A measurement showing the current state of a chain or a bridge falls outside its calibrated nominal window. Divergence may be statistical, expressing how unlikely the present state is under the rolling distribution, or event-based, matching the present state to a documented historical incident with known failure mode. Invarians qualifies divergence. The agent owns the decision on what to do with it. The agent's policy determines whether a given divergence is operationally critical.

The continuous process by which Invarians defines the nominal window for each chain, each layer and each bridge, on a rolling 30-day baseline updated hour by hour. Distinct from a static threshold. The calibration tracks the nominal as it drifts. Calibration is what allows divergence to be qualified meaningfully against the chain's present distribution rather than against an arbitrary fixed value. Reproducible methodology and historical backtests are published at github.com/agentnorthstar/calibration.

The numerical bound, per chain and per measurement axis, above or below which a signal is considered to have left its nominal window. Thresholds are not arbitrary constants. They are the output of the continuous calibration process, derived statistically from the rolling 30-day distribution of each observable (P97 by default, percentile-based to remain robust to outliers). Each chain has its own thresholds because each chain has its own nominal: Ethereum's nominal rhythm differs from Polygon's, Arbitrum's batch posting cadence differs from Optimism's. Thresholds are recalibrated on a rolling basis so the bound moves with the chain's drift, not against it. Both upper and lower bounds may be calibrated for two-sided signals (rhythm, sigma, size, tx, beacon participation), enabling the signed regime classification (S2+ / S2- and D2+ / D2- codes, see Polarity). Threshold values per chain and per axis are stored in dedicated tables and re-published with each calibration cycle. Reproducible methodology at github.com/agentnorthstar/calibration.

Each ratio reported by Invarians is computed against two exponentially weighted moving averages of the chain's history. The short EMA uses a memory of approximately ten hours and tracks the local pulse. The long EMA uses a memory of approximately thirty days and captures the structural baseline. Both are produced continuously per chain. The short ratio answers is the chain off its recent rhythm right now. The long ratio answers is the chain off its monthly baseline. The two together allow Invarians to separate transient deviations from sustained drift.

The signed difference between the short EMA ratio and the long EMA ratio for a given measurement axis. shift = ratio - ratio_long. A positive shift means the chain is currently above its 30-day baseline; a negative shift means it has dropped below or has converged toward the long baseline; a near-zero shift means the chain is following its historical pace. Shift is exposed per metric in the API v2.0 panel response (MetricBlock), in ?include=diagnostic mode and above. Shift is the empirical demonstration of the nominal not fixed thesis. Where the regime classification answers is the chain stressed right now, shift answers is the chain drifting out of its 30-day window.

The direction of a deviation relative to the calibrated nominal. A signal can deviate in two opposite ways: above the upper threshold (positive polarity, noted +) or below the lower threshold (negative polarity, noted -). Polarity makes this distinction explicit in the signed regime classification: S2+ means the structural axis is stressed in the direction where rhythm is elongated (sequencer slowdown, validator delays), S2- means the structural axis is stressed in the opposite direction where rhythm is too short (sequencer overproducing, validator overactivity). Similarly for the demand axis: D2+ = demand surge above the upper threshold, D2- = demand starvation below the lower threshold, D2± = composition split (at least one demand ratio above and one below).

Polarity is operationally critical: a sequencer slowing down and a sequencer overproducing share a label without it (both are simply non-nominal), but they have opposite root causes and an AI agent's policy must distinguish them. The signed classification produces 12 codes per chain (instead of 4) and is the form currently emitted by the panel API v2.0 for chains where calibration of both bounds is committed.

The self-contained block exposed for each classifying observable in the panel API v2.0 response. In ?include=core mode, the block contains only ratio (plus auxiliary fields like epoch for beacon or seconds for sequencer publish latency). In ?include=diagnostic mode and above, the block extends to ratio, ratio_long, shift, shift_delta, and shift_magnitude_delta. The MetricBlock answers three questions in one structure: where is the value now, how far from the long-term baseline, and is the deviation amplifying or shrinking. The new structural observables (Beacon Chain participation on Ethereum, sequencer publish latency on L2 chains) emit shift_available: false during their slow-EMA stabilization period.

shift_delta = shift_now - shift_prev. The raw difference between the current shift and the shift at the previous measurement cycle. Tells the agent the direction in which the value moved: positive = up, negative = down, near-zero = stable. This signal is a complement to shift_magnitude_delta: they typically agree, except when shift crosses zero between cycles (the chain transitions through a nominal state). Exposed per metric in ?include=diagnostic mode and above.

shift_magnitude_delta = |shift_now| - |shift_prev|. The change in the absolute deviation magnitude between cycles. Positive means the deviation is widening (regime persists or worsens). Negative means the deviation is shrinking (chain is reverting toward the nominal baseline, regime exit likely). Near-zero means the deviation is stable. Together with shift_delta, this signal answers the agent's fitness-for-action question: is the regime sticky or about to flip back to nominal? Exposed per metric in ?include=diagnostic mode and above.

A composite summary of the trend signal per axis (structural / demand) exposed in the v2.0 payload. The drift object on each panel entry contains six fields: structural (max of |shift| over structural observables), structural_delta, structural_magnitude_delta, demand, demand_delta, demand_magnitude_delta. An initial heuristic mapped magnitudes to reading bands (below 0.005 stable, 0.005 to 0.02 mild, 0.02 to 0.05 active, above 0.05 imminent transition probable). The 2025 empirical campaign on ETH-ARB-CCTP and ETH-OP-CCTP showed that this composite aggregation does not carry a validated agent-orientation signal across 648 pre-engaged configurations with combined Benjamini-Hochberg FDR. The v3 redesign replaces the composite block with an explicit per-chain precursors array, each precursor carrying its calibration metadata and cross-chain status. Drift remains exposed in v2.0 for backward compatibility, flagged deprecated_unvalidated in v3.

The fraction of active Ethereum validators that successfully attested during a given Beacon Chain epoch. Measured per epoch (~6.4 minutes), exposed as a structural axis observable on Ethereum since API v2.0. A drop below the calibrated lower threshold triggers S2- on the structural axis. Documented historical drops include April 2023 (Geth attestation cascade), May 2023 (finality stall), and various Lido / Coinbase staking node operator outages in 2024. Exposed in the panel as panel.l1[].structural.beacon_participation with ratio, epoch, and (after slow-EMA stabilization) ratio_long + shift + trend fields.

The delay between two consecutive L2 batches inscribed on L1 by the rollup sequencer. Measured in seconds, observed from L1 events. A spike above the calibrated upper threshold triggers S2+ on the L2 structural axis. Documented historical events include the Arbitrum sequencer halt of 2024-12-21 (~1h30 outage), the Optimism sequencer halt of 2025-09-14, and Base sequencer issues of November 2024. sequencer_publish_latency is the third structural observable on L2 chains (alongside rhythm and continuity), unlocking real S2 detection on rollups where rhythm and continuity are architecturally compressed by the sequencer's fixed cadence. Exposed since API v2.0 as panel.l2[].structural.sequencer_publish_latency.

The legacy 4-state grid (S1D1, S1D2, S2D1, S2D2) classifies only deviations above the calibrated nominal window. Adding lower bounds on each axis, in addition to the upper bounds, produces a set of signed regime codes: 12 codes on L1 and 12 codes on L2 (since v2.0, L2 reaches S2 thanks to sequencer_publish_latency). Each extended code carries an explicit direction suffix (+, -, ±) on the affected axis. Activated chain by chain since 2026-04-29: ETH, POL on L1; ARB, BASE, OP on L2. SOL and AVAX scheduled for July 2026.

The signed grid captures signatures invisible to the legacy 4-state model: cascading liquidations (composition asymmetric, D2±), sequencer halts (rhythm slowed, demand depressed, S2+D2-), censorship of transaction classes (selective tx exclusion, D2-), agentic bundle dominance (size up, tx down, D2±). 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 (tx_ratio dropping to 0.74 below baseline) instead of the legacy S1D1.

The demand axis (π) has four states once signed codes are active. D1 means all demand ratios are within their nominal bounds. D2+ (legacy D2 alias) means at least one ratio is above its high threshold and none is below — the chain is in elevated demand (DeFi season, ETF events, liquidations spread evenly). D2- means at least one ratio is below its low threshold and none is above — the chain is in depressed demand (sequencer halt, censorship of small transfers, mempool gel). D2± means at least one ratio is above and at least one is below — composition asymmetry, the chain is processing fewer but larger (or larger but fewer) transactions than baseline. This is the canonical signature of agentic concentration: bots dominating the user-operation flow with bundled, complex transactions while regular user activity drops.

The structure axis (τ) has three states once signed codes are active. S1 means rhythm and continuity are within nominal bounds. S2+ (legacy S2 alias) means rhythm slows abnormally (blocks taking longer than baseline) — sequencer drift, validator outages, congestion- induced delays. S2- means rhythm accelerates abnormally (blocks coming faster than the historical baseline) — possible client optimisations, infrastructure migration, or shifts in the slot-timing distribution. S2- on L1 is rare but informative: it captures structural changes that fee monitors and gas trackers do not see. On L2 rollups, the rhythm distribution is intrinsically tight ("τ dormant") and S2- detection is generally disabled (rhythm_threshold_low = NULL) to avoid sub-percent noise.

The SxDx regime is derived from two independent axes, measured separately and combined to produce a four-state classification.

The JSON field in the Invarians API response that carries the HMAC signature and digest of the panel.

This is not a consensus mechanism. The name does not refer to Proof of Work, Proof of Stake, or any blockchain consensus protocol. In Invarians v1.0.0 the field is signed_execution_context (renamed from the former proof_of_execution_context): the panel is serialised canonically, hashed, and signed HMAC-SHA256. The anchor sub-field is currently null and will be populated with an on-chain Merkle root from May 2026 onward.

An Invarians API field indicating the freshness state of the attestation at the moment of response.

This is not a blockchain oracle. Invarians does not operate as a decentralized oracle network (such as Chainlink or Band Protocol, which relay off-chain data on-chain). Invarians reads on-chain data via RPC and delivers certified attestations to off-chain agents. The term "oracle" in oracle_status is an internal Invarians denomination referring to the data collection and attestation service, not a decentralized oracle node.

Two distinct technical terms for two distinct measurement types in Invarians.

The terminology is intentional: bridges transition faster than structural regimes. Using different words reflects different measurement scales.

The complete signed payload delivered by the Invarians API (v2.0.0). A panel is the broadest container: it encompasses all L1 entries, L2 entries, bridge entries (each with axis-grouped structural + demand objects, per-metric MetricBlock, and a composite drift object per axis), and the signed_execution_context.

The internal name of the Invarians backend service responsible for collecting on-chain data, computing structural regimes, and delivering signed attestations via the API.

Not a decentralized oracle network. The term "oracle" here refers to the Invarians data collection and attestation service, a centralized backend (Hetzner VPS + Supabase) that reads public on-chain data via RPC and certifies the structural state it observes. Decentralization via Chainlink Functions is on the roadmap for Q4 2026.