Invarians

FAQ

Signed execution context for cross-layer AI agents.

Why Invarians at all
Q1
I already have access to every block, every log, every mempool tx. Why would I use Invarians to equip my AI agents instead of building it in-house ?

You have the raw layers, yes. What an institution deploying AI agents on-chain does not have out of the box :

  • A threshold calibrated per chain, for example basefee_nominal_arb vs basefee_stressed_arb, recomputed every 3 to 6 months because the distribution shifts (post EIP-4844, post Dencun, future Prague, etc.)
  • A composite cross layer view (L1, L2 and bridge read together in a single signed response)
  • A signed composite execution context, bound per cross layer action. For any action (settlement ETH↔ARB via CCTP, rebalance on Base, call a CCIP lane POL to ETH), Invarians returns the pair or triple of states that matters for that action (L1 regime, L2 profile, bridge state) as one atomic signed record. The blockchain seals the inputs, Invarians seals the execution context the agent actually acts on
  • Hard protocol gates that flip the state regardless of statistical calibration. If the CCIP Risk Management Network marks a lane cursed, or if the CCTP Circle Iris attestation service is unreachable, the lane is marked not nominal immediately. These gates work on day one, even on a lane too young for P97 over 30 days calibration to be active yet, so a freshly deployed route still returns a defensible verdict

An institution can build this in-house. Per chain calibration plus permanent recalibration as distributions drift is a standing engineering commitment. Invarians runs it, signs every attestation, and publishes the full methodology and backtests at github.com/agentnorthstar/calibration. The agent stays the focus of the team, the sensor is operated by Invarians.

Q2
When my AI agent fails, do I get a signed attestation of the conditions at that moment ?

Yes. Every panel response is HMAC-SHA256 signed. The integration pattern for post execution review :

before execute:
  panel = invarians.get_panel_v2(include="diagnostic")    # signed
  log(panel.signed_execution_context.payload_hash, tx_hash, panel)

after failure:
  POST /v2/verify {payload, signature}
  → { "valid": true, "key_id": "invarians-v1", "version": "2.0.0" }
  read panel.l1[...].regime, panel.l1[...].drift
  → "agent failed at 14:22, arb was in S2+D1, drift.demand 0.18 amplifying, decision was not sound"

From May 2026, an on-chain Merkle anchor is added to each batch, making the attestation non-repudiable, verifiable without asking Invarians.

Use case, an AI agent takes an on-chain action. You keep the signed panel alongside the tx_hash. Later, anyone can reconstruct the infrastructure state at t0. This is the black box log pattern.
Q3
Does Invarians predict anything, does it orient the agent, how does it work exactly ?

Invarians predicts nothing. For a given cross layer action, Invarians returns the composite execution context, the pair or triple of states that matters for that action (L1 regime, L2 profile, bridge state), calibrated per chain and per bridge, signed atomically. The agent consumes the signed execution context and decides.

Blockchain raw data INVARIANS (observe, calibrate, bind, sign) AGENT (decide) (raw layers) (signed execution_context per action) (GO / DEFER / REROUTE)

Invarians is the signed sensor of the execution context. The agent is the pilot. A flight sensor does not predict turbulence, it measures the conditions of the flight right now, and the pilot decides what to do. Same pattern here, per action.

Usage and integration
Q4
How long does integration take ?

Five minutes to install, twenty lines of code to branch your agent on the response. Minimal pattern :

pip install "invarians[requests]>=0.5.0"

from invarians import InvariansClient
panel = InvariansClient("inv_...").get_panel_v2(include="diagnostic")

eth = panel.l1_by_chain("ethereum")
arb = panel.l2_by_chain("arbitrum")

if arb.regime.startswith("S2"):
    defer()                                                      # structural stress on ARB
elif arb.drift.demand_magnitude_delta > 0.05:
    defer()                                                      # demand drift amplifying, transition imminent
elif panel.bridge_by_id("arbitrum-ethereum/cctp").state == "BS2":
    reroute()
else:
    execute()

Full walkthrough in /developers.

Q5
What SLA do you actually commit to today ?

V1 is centralized, a single Hetzner node. Observed uptime since March 2026 is above 99.5%. Freshness budget is 10 minutes for bridge signals, 60 minutes for L1 and L2. If any item is STALE, oracle_status flips to DEGRADED automatically and the agent sees it in the same response.

Stricter SLA arrives with the two upstream trust tiers : Hybrid (Chainlink DON, Q3-Q4 2026) and Decentralized INVAR Network (2027).

Trust model
Q6
What if Invarians is wrong ?

Every attestation is signed, timestamped, stored. You can replay any past decision against the signed panel and verify the claim yourself. The calibration methodology (P97 over 30 days, per chain) and the backtests are public at github.com/agentnorthstar/calibration. If a declared regime was wrong on a past event, the evidence is public and addressable. No opinion, only data.

Q7
Do I have to trust your server ?

Today, yes. V1 is centralized. Signing is a single node. What you get in exchange :

  • HMAC-SHA256 signatures you can verify offline
  • A public calibration methodology (anyone can reproduce it)
  • An on-chain Merkle anchor of every batch from May 2026

The decentralized INVAR Network (2027) removes the single node trust assumption entirely, independent nodes compute and sign.

Q8
Why not just use an existing data provider ?

Price oracles, cross-chain messaging networks, gas and mempool analytics providers each solve a specific slice, prices, transport, latency statistics. None of them calibrate blockchain structural state (regime S1D1 / S1D2± / S2±D2± across L1 and L2, unified BS1 / BS2 across CCIP and CCTP) and bind it per cross-layer action.

Invarians sits beneath those layers, it tells the agent whether the infrastructure itself is in a nominal window, before any price-based or routing decision. Complementary, not competing. Invarians consumes and composes over existing data providers rather than replacing them.

Signal selection is strict : only physical and protocol-infrastructural metrics (block cadence, basefee, batch age, RMN cursed state, CCTP burn events, Circle attestation latency, etc.). Narrative and economic metrics (token prices, TVL, volume, sentiment) are out of scope by design, they are reflexive and manipulable, not a stable substrate for agent decisions.

Technical limits
Q9
What latency between on-chain event and attestation ?

Invarians is an off-chain observer. It polls chain state on a structural cadence, not a tick cadence. Current freshness budgets, exposed per item in every panel response :

  • L1 regime signals : 60 minutes
  • L2 profile signals : 60 minutes
  • Bridge states : 10 minutes

Any item older than its budget flips to STALE and oracle_status moves to DEGRADED automatically, visible in the same response.

If sub-second reaction on tick level events is needed, Invarians is not the right tool, use eth_subscribe. Invarians is structural, not tick level.

Q10
Does this work for non-EVM chains ?

Solana L1 regime calibration lands July 2026 (different collector, different calibration window due to SOL block cadence). Solana side CCIP lanes land Q1 2027. Non-EVM cross-chain execution context is actively under construction, not vaporware, see /roadmap.

Q11
Is there a case where Invarians says "I don't know" ?

Yes, explicitly. Any panel entry with calibrated:false is in that state. The 10 CCTP routes and 10 CCIP lanes are captured per message (capability_level: per_message_attested); BS1/BS2 state classification is preliminary on the per-message latency baseline and may show state:null while the baseline window builds up.

In that case :

  • Raw signals are still visible (latency, sequence advance, RMN status)
  • Safety overrides still fire (RMN cursed, Iris down force a degraded state regardless of calibration)
  • The classified state is null and the agent decides with its own policy

Invarians does not invent certainty it does not have.

Q12
What claims are not yet backed by published numbers ?

Transparency on what is operational today vs what is still being measured :

  • P(tx revert | regime = S2D2) and similar conditional failure rates are not yet published. The link between stressed regime and agent failure is an operational hypothesis supported by observation (basefee ×3 to ×10 in S2, bridge latency p95+ in BS2), not a published statistical claim with error bars
  • Regime criticality per action type (S2D1 vs S1D2 vs S2D2) is not yet mapped publicly. A pure L2 action is not affected the same way as a cross-layer action, the matrix will be published
  • Drift quantification across months (is the nominal window of January 2026 the same as November 2025 ?) is handled operationally by the rolling 30-day calibration, but the empirical drift is not yet published. Post EIP-4844, post Dencun, basefee distributions shifted, the rolling window absorbs it in roughly 30 days, graphs month-over-month are pending publication
  • Acting only in nominal is not a hard rule Invarians imposes, it is the zone of densest calibration sample and lowest outcome variance. An agent with a sufficient edge can decide to act in stress, Invarians signs the regime and leaves the decision to the agent

Everything above is in the publication pipeline at github.com/agentnorthstar/calibration. Until the numbers are public, the honest framing is : Invarians signs the observed regime, the causal link to agent outcome is a working hypothesis being measured.

Audit and replay
Q13
How do I replay a past decision after the fact ?

Store the full signed panel alongside your tx_hash before execution. Later :

POST /v2/verify
body: { payload: panel_minus_signed_execution_context, signature }
→ { "valid": true, "key_id": "invarians-v1", "version": "2.0.0" }
read panel.l1[...].regime, panel.l1[...].drift at that exact instant

You now have a signed, replayable decision record. "At t0 the infrastructure was in state X with drift Y, the agent's decision is justified by that state." Full example in /developers.

Q14
Can I prove to a third party that the decision was sound ?

Today, the signed attestation is independently verifiable, but the signature depends on Invarians holding the HMAC key. From May 2026, the on-chain Merkle anchor makes each attestation non-repudiable, verifiable without asking Invarians.

Example, a DAO treasury AI agent executes a disputed cross-chain transfer. The team presents the signed panel showing BS1 nominal at t0, the agent logic was sound, the decision record holds up in front of the DAO, an arbitrator, or a regulator.

Documented past events and replayed agent behavior will be published at evidence.invarians.com.

Q15
Can Invarians be used for fast transactions ?

No. Invarians is not a routing engine for speed, MEV, or arbitrage. It is a context tool for AI agents.

Chains have rhythms, cadences, granularities, densities. Invarians observes those physical properties continuously, locates the states judged nominal, and signs attestations at those moments. An agent reads the panel and picks a stable path for its cross-chain action, not the fastest path.

Typical use : an agent that moves value across chains and prefers predictable execution (low variance of finality, no bridge stall, no reorg pressure) over fastest execution. Invarians signs the context of stability, it does not rank latency.

Q16
Are narrative metrics as effective as the physical signals Invarians uses ?

No, and the question is not "which one is better", it is "better for what". Narrative and physical metrics answer different questions and serve different layers of an AI agent.

Where narrative metrics win (sentiment, volume, TVL, token prices, mempool $ flow, orderflow) :

  • Predicting market direction (momentum, price moves)
  • MEV and arbitrage timing
  • Cycle detection (hype, sector rotation)
  • Strategic allocation (which chain actually has real liquidity)

On those use cases, a well built narrative signal beats a physical signal. A trading agent should not gate on basefee.

Where physical and protocol-infrastructural metrics win (basefee, block cadence, batch age, RMN cursed state, CCTP burn events, Circle attestation latency) :

  1. Non-reflexivity. basefee in gwei is a deterministic function of block utilization. gas_price_USD depends on ETH/USD, which depends on sentiment, which depends on the agents reading the signal. An agent gating on gas_USD during an ETH pump defers wrongly on a structurally nominal chain.
  2. Non-manipulability. TVL can be inflated (wash deposits, points farming). Volume can be faked (wash trading). Sentiment can be botted. Basefee, block cadence and RMN isCursed() cannot be moved without touching the protocol itself.
  3. Falsifiability. "Basefee above 3x the 30d EMA at block N" is checkable by anyone with an archive RPC. "Market sentiment is bearish" is not falsifiable. Invarians signs only claims that are falsifiable against chain state.
  4. Calibration stability over time. Narrative regimes shift every few months (bull, bear, meme). Physical rhythms shift at hard forks. P97 over 30d is stable for basefee, it is noise for TVL.
  5. Cryptographic attestability. "Basefee = X gwei at block N" can be signed with HMAC, anchored on-chain via Merkle root, and verified by a third party without asking Invarians. "The market is nervous" cannot be signed without injecting an opinion oracle. This is precisely why price oracles carry oracle risk, and why on-chain signalling infrastructure should not depend on them.

Architectural positioning. Invarians sits beneath the narrative layer, not beside it. A well designed AI agent reads both :

  • Narrative to decide what to do (which asset, which strategic moment)
  • Physical (Invarians) to decide whether the infrastructure can execute that action predictably right now

An agent that mixes both into a single signal produces something reflexive, non falsifiable and non attestable. That is exactly what DAO treasuries, restaking protocols, and regulators cannot audit.

Narrative metrics tell the agent what the market thinks. Physical metrics tell the agent what the infrastructure is doing. A cross-chain AI agent needs both, but they cannot be signed by the same attestor. Invarians picked the layer that can be cryptographically proven and independently replayed. The narrative side is already well served by others.
A question is missing ? Write via /contact. Recurring questions land here, with the answer and the date they were added.