Invarians

CRE INTEGRATION

Add structural sensing to your Chainlink CRE workflow.
Hybrid · Q3-Q4 2026 · Integration guide

TypeScript SDK Python SDK HTTPClient runInNodeMode Cron trigger
The structural gap

Since EIP-4844 (Dencun, March 2024), L1 basefee decoupled from L2 activity. Sequencer outages, bridge posting gaps and structural anomalies produce no economic signature on L1. Fee monitors are 100% blind to them. Every cross-chain agent operating today has no native observability of the substrate it executes on.

Documented example: a 37-minute batch posting gap on an L2 sequencer. L1 ETH basefee held at 7–25 gwei throughout — S1D1, structurally normal. Fee monitors: no signal. Invarians: BS2 bridge state, L2 regime S1D2 (×1,649 block ratio). The substrate was degraded. Every fee-based signal said green.
Execution and sensing are separate concerns

Every agentic system has an execution layer that orchestrates, calls and coordinates. No agentic system today has a layer that observes the structural state of the blockchain substrate it acts on.

Concern Execution layer Sensing layer: Invarians
Role Orchestrate, call, coordinate Observe structural substrate state
What it knows What to do, when, how What the infrastructure is doing right now
Blind spot Sequencer degradation, bridge stress, structural regime shifts None: that is exactly what it measures
Signal type Transaction status, gas price, confirmations Signed regime attestation: L1 × L2 × Bridge
Examples Chainlink CRE, intent solvers, keepers, RWA automation Invarians: live, calibrated, signed
Execution tells systems what to do. Sensing tells them whether it is safe to do it.
SxDx: The regime framework, Four execution contexts. One sensing layer.

Invarians classifies the blockchain infrastructure state across two independent axes: τ (structural rhythm) and π (demand pressure). Each combination maps to an execution context with distinct implications for autonomous agents.

S1D1
structural nominal · demand nominal
Infrastructure operating within calibrated norms on both axes. Agent implication Standard execution conditions. Full throughput available.
S1D2
structural nominal · demand elevated
Infrastructure structurally sound. Demand above calibrated historical percentiles. Agent implication Elevated costs, no structural risk. Fee-sensitive agents adjust.
S2D1
structural stress · demand nominal
Structural stress without economic signature. Not detectable by fee monitors. Agent implication Structural degradation in progress. Nothing shows on gas.
S2D2
structural stress · demand elevated
Structural stress coinciding with elevated demand. Both axes degraded simultaneously. Agent implication Compound stress. High execution risk across both dimensions.
L1 and L2 are measured independently. Bridge state (BS1 nominal / BS2 degraded) adds a third dimension. A complete attestation covers all three layers simultaneously.
A signed attestation of infrastructure state

Every call to Invarians returns a cryptographically signed snapshot of the current execution context: regime, freshness, and lineage. The agent applies its own policy. Invarians observes infrastructure state and signs it. Nothing more.

"chain":            "arbitrum",
"oracle_status":    "OK",
"l1_regime":        "S1D1",
"l2_regime":        "S1D2",
"bridge_state":     "BS1",
"l2_verified":      true,
"data_age_seconds": 312,
"signature":        "inv_sig_..."
Calibrated per chain. Thresholds derived from 4+ years of BigQuery backtests. ETH: 34,697 windows, FPR 1.23%. Polygon: 25,906 windows. No cross-chain normalization.

Cryptographically signed. HMAC-SHA256 attestation on every response. Ed25519 signatures across the internal collection pipeline. Independently verifiable via /verify.

Agent-owned policy. Invarians publishes infrastructure state. The agent applies its own execution policy. There is no execution window, no recommendation, no prescription embedded in the signal.
Every execution layer benefits from sensing

Invarians is not built for one platform. Any system that executes autonomously on blockchain infrastructure gains observability by integrating the sensing layer.

Orchestration
Chainlink CRE
Runtime Environment for autonomous on-chain agents. Invarians provides the structural sensing layer missing from the execution stack.
Cross-chain execution
Intent Solvers
Across Protocol, Li.Fi, Uniswap X: routing cross-chain transactions. Bridge state (BS1/BS2) and L2 regime are directly relevant to fill logic.
Institutional automation
RWA & Keepers
Ondo Finance, tokenized asset managers, automated compliance workflows: execution context for audit trails and risk-aware operation.
A Chainlink CRE agent without Invarians orchestrates execution without knowing if the sequencer is in S2D1 or the bridge is in BS2 at execution time. A 37-minute batch posting gap that L1 fee monitors never detected is the documented example of what that costs.
The sensing pattern, One extra step before execution

The integration is a single HTTP call inserted between your trigger and your execution logic. Your workflow asks Invarians for the current regime: then decides based on that.

Step 1
Trigger fires
Cron, HTTP, or EVM log starts your workflow execution
Step 2: Invarians
Query sensing layer
Fetch regime context via HTTPClient: L1 × L2 × Bridge state
Step 3
Gate on regime
Proceed if S1D1, defer if S2D1 or BS2, handle STALE
Step 4
Execute
Your business logic: onchain write, cross-chain, computation
Why runInNodeMode?: External API calls in CRE are non-deterministic at the DON level (different nodes may receive slightly different timestamps or network latency). Wrapping the Invarians call in runInNodeMode with mode aggregation ensures all DON nodes reach BFT consensus on the regime value before your callback uses it.
Complete TypeScript workflow, Invarians sensing in a CRE workflow

Drop this pattern into any existing CRE workflow. The sensing call adds one HTTP request per trigger fire: negligible overhead, complete infrastructure observability.

// ── my-workflow/main.ts ──────────────────────────────────────────────
import {
  CronCapability, HTTPClient, handler,
  consensusStringModeAggregation, Runner,
  type NodeRuntime, type Runtime
} from "@chainlink/cre-sdk"

// ── Config (from config.staging.json) ──────────────────────────────
type Config = {
  schedule:         string
  inVariansApiKey:  string   // your inv_* API key
  targetL1:         string   // "ethereum"
  targetL2:         string   // "arbitrum" | "base" | "optimism"
}

// ── Invarians response type ─────────────────────────────────────────
type InVariansContext = {
  oracle_status: "OK" | "STALE" | "OFFLINE"
  regime:        "S1D1" | "S1D2" | "S2D1" | "S2D2"
  l2_regime:     string
  bridge_state:  "BS1" | "BS2"
}

// ── Step 1: Fetch Invarians context (runs on every DON node) ────────
const fetchInVariansContext = (
  nodeRuntime: NodeRuntime<Config>
): InVariansContext => {
  const http = new HTTPClient()
  const l1 = nodeRuntime.config.targetL1
  const l2 = nodeRuntime.config.targetL2

  const resp = http.sendRequest(nodeRuntime, {
    url:    `https://sdpilypwumxsyyipceew.supabase.co/functions/v1/attestation/execution-context?from=${l1}&to=${l2}`,
    method: "GET" as const,
    headers: {
      "Authorization": `Bearer ${nodeRuntime.config.inVariansApiKey}`,
    }
  }).result()

  const data = JSON.parse(
    new TextDecoder().decode(resp.body)
  )
  const poc = data.proof_of_execution_context ?? {}

  return {
    oracle_status: data.oracle_status,
    regime:        poc.l1_regime    ?? "S1D1",
    l2_regime:     poc.l2_regime    ?? "N/A",
    bridge_state:  poc.bridge_state ?? "BS1",
  }
}

// ── Step 2: Main callback ────────────────────────────────────────────
const onTrigger = (runtime: Runtime<Config>): string => {

  // Query Invarians: BFT consensus across DON nodes on regime string
  const ctx = runtime.runInNodeMode(
    fetchInVariansContext,
    consensusStringModeAggregation()   // mode = most common value across nodes
  )().result()

  runtime.log(`Invarians: ${ctx.oracle_status}: L1:${ctx.regime} L2:${ctx.l2_regime} Bridge:${ctx.bridge_state}`)

  // ── Gate 1: Attestation freshness ────────────────────────────────
  if (ctx.oracle_status !== "OK") {
    runtime.log("Attestation STALE: deferring execution")
    return "deferred:oracle_stale"
  }

  // ── Gate 2: L1 structural stress ─────────────────────────────────
  if (ctx.regime === "S2D1" || ctx.regime === "S2D2") {
    runtime.log(`Structural stress detected (${ctx.regime}): deferring`)
    return `deferred:structural_stress:${ctx.regime}`
  }

  // ── Gate 3: Bridge state (cross-chain workflows) ──────────────────
  if (ctx.bridge_state === "BS2") {
    runtime.log("Bridge degraded: deferring cross-chain execution")
    return "deferred:bridge_degraded"
  }

  // ── Infrastructure nominal: proceed ──────────────────────────────
  runtime.log(`Nominal (${ctx.regime}): executing`)

  // ... your business logic here (onchain write, CCIP, computation)

  return `executed:${ctx.regime}`
}

// ── Workflow entry point ─────────────────────────────────────────────
const initWorkflow = (config: Config) => {
  const cron = new CronCapability()
  return [handler(cron.trigger({ schedule: config.schedule }), onTrigger)]
}

export async function main() {
  const runner = await Runner.newRunner<Config>()
  await runner.run(initWorkflow)
}
// config.staging.json
{
  "schedule":        "*/30 * * * * *",
  "inVariansApiKey": "inv_your_key_here",
  "targetL1":        "ethereum",
  "targetL2":        "arbitrum"
}
The three gates, What your workflow checks before executing

Each gate handles a distinct failure mode. None of these are visible to fee monitors or accessible without a dedicated sensing layer.

Check Failure mode What it means
oracle_status !== "OK" Attestation freshness Invarians data older than 3,600 seconds triggers STALE. Executing on stale context is executing blind: defer and retry at the next trigger fire.
regime === "S2D1" or "S2D2" Structural stress S2 means infrastructure rhythm has deviated from baseline. This is the invisible regime: no fee signature, no gas spike. Detected only by Invarians τ axis measurement.
bridge_state === "BS2" Bridge degraded BS2 signals abnormal batch posting latency to L1. For cross-chain workflows, this means the bridge is not operating at normal cadence. Applicable from Phase 2C (~April 22, 2026).
What changes when you add sensing
CRE workflow without Invarians
Executes without knowing if L2 is in S2D1
No structural information post-EIP-4844: fee monitors only
Cross-chain execution during bridge posting gap (BS2)
Arbitrum June 20, 2024: executes at ×1,649 nominal basefee
CRE workflow with Invarians sensing
Regime-aware: defers on S2D1, S2D2
Structural context signed and verifiable: not just gas price
Bridge state gate: cross-chain deferred when BS2
Arbitrum June 20, 2024: detects S1D2 × BS2: defers
Setup in 4 steps
01
Set up Chainlink CRE
Follow the official getting started guide at docs.chain.link/cre. CRE is currently in Early Access: request access from Chainlink directly.
02
Get your Invarians API key
Sign up at invarians.com: free tier available (20 req/day for testing). Your key starts with inv_.
03
Add the sensing pattern to your workflow
Copy the TypeScript workflow above into your project's main.ts. Add your Invarians API key and target chain to config.staging.json.
04
Test and deploy
Simulate locally: verify the Invarians regime appears in your workflow logs. Deploy following the CRE documentation.
Invarians API is live. L1 + L2 + Bridge across 7 networks. Signed attestations. Free tier for development.

API documentation →  ·  CRE docs →