Sensing structural invariants from inside a Chainlink CRE workflow: a 140-line gate over Bridge State v1.2.

An autonomous agent that settles a tokenized fund across two chains makes a decision the operator never sees in production logs: can I act right now, or should I wait? Fee monitors answer the easy half of that question by reporting the price of gas. The harder half, whether the cross-chain settlement path is operating inside its calibrated envelope at this exact moment, requires a different signal entirely. This note documents a 140-line Chainlink Runtime Environment (CRE) workflow that consumes the Invarians BRIDGE_STATE_STRUCTURAL_v1.2 attestation through an HTTPS fetch, applies a three-state gate to the response, and emits one of three verdicts to a downstream business action. Two live simulation runs anchor the result.

1. Why a CRE workflow consumes Invarians

The Invarians panel API (three primitives, one signed payload) was designed for autonomous agents to read execution context before acting cross-chain. A Chainlink CRE workflow is a programmable runtime that schedules and supervises that act: it can fire on a cron trigger, fan out HTTPS calls under Byzantine-tolerant consensus across a Decentralized Oracle Network (DON), and proceed to a CCIP send or an onchain write conditionally. The two pieces fit naturally: Invarians provides the sensing layer, CRE provides the supervised execution shell around it.

What this note demonstrates is the canonical consumer pattern: a CRE workflow performs one HTTPS fetch per cron tick against https://api.invarians.com/v2/panel, parses a specific corridor entry, and emits a verdict the rest of the workflow uses as a structural gate before triggering anything irreversible. The pattern is documented in the Invarians CRE integration page; what follows isolates it in its smallest runnable form and shows it executing against the live API.

2. What Invarians publishes — the v1.2 sidecar

Two vocabularies coexist in what follows, and they belong to two distinct actors. Invarians publishes a state — BS1, BS2, or null — along with the methodology version, the SHA-256 integrity tie, and five structural invariants on the CCTP V2 corridor: four window-based conditions on the Fast mode (I1 attestation success rate ≥ 0.995, I2 mode fallback rate ≤ 0.05, I3 instrument valid, I4 sample sufficient) and one event-based check on Standard mode (I5: no message older than 48 h without an Iris attestation signature). The workflow shown here is one example consumer; its three-state gate (ACT, DEFER, WAIT_FOR_DATA) is the consuming agent's own policy that translates the Invarians state into a decision. The gate is not part of the BRIDGE_STATE_STRUCTURAL_v1.2 contract; it lives entirely on the agent side. This section documents what Invarians publishes; section 3 documents the example agent's policy and code.

Each bridge entry in the panel response carries a bridge_state_v1_2 sidecar populated by the Invarians classifier service (Rust, written every thirty seconds into the ans_bridge_states Postgres table, then exposed by the Edge function since SDK 0.13.0, 2026-06-02). The sidecar reports the methodology version, its SHA-256, the combined verdict on the corridor (state in {BS1, BS2, null}), the per-mode breakdown, and the stuck-detection flag (stuck_standard in {true, false, null}). The methodology contract BRIDGE_STATE_STRUCTURAL_v1.2 is signed Ed25519 three times and Bitcoin-anchored through OpenTimestamps in agentnorthstar/calibration; the SHA-256 echoed by the sidecar (b46793407f…) is the integrity tie back to that contract.

The state on a corridor is the output of two invariant families. The first four invariants — I1 attestation_success_rate ≥ 0.995, I2 mode_fallback_rate ≤ 0.05, I3 instrument valid, I4 sample sufficient — are window-based, evaluated on a 1-hour rolling window over the Fast mode (the temporal scale at which Fast latency lives natively, 8 to 30 seconds nominal). The fifth invariant I5 is event-based: any Standard-mode message older than forty-eight hours without an Iris attestation signature flips the corridor to BS2. The forty-eight-hour cap is mechanically derived (Polygon-Heimdall pathological reorg envelope four hours, plus Ethereum non-finalization upper bound twenty-four hours, plus Iris attestation envelope one hour, times a one-and-a-half safety margin) and immutable unless Circle publishes a superseding SLA. The combined state field is BS1 only when all five invariants hold, BS2 on any breach, and null when invariant I4 fails (Fast sample below the n_eligible threshold of five). The full definitions live in the glossary entry on CCTP V2 invariants.

3. The example agent's policy

The workflow shown below is one example consumer of the Invarians state. The policy it applies is its own; another agent could derive a different decision from the same state. The doctrine line is the same as everywhere else on the Invarians surface: the panel qualifies the state of the infrastructure, the agent decides what to do with it. What follows lives on the agent side of that line.

The example policy maps the three states Invarians publishes into three decisions on the workflow side. ACT when the state is BS1 and stuck_standard is false: all invariants hold, the corridor is operating inside its calibrated envelope, the agent proceeds with the business logic. DEFER when the state is BS2 or stuck_standard is true: at least one invariant is breached, the agent withholds the action and re-evaluates on the next cron tick. WAIT_FOR_DATA when the state is null: I4 has not produced a verdict yet (sample below threshold), the agent has no signal to act on; the workflow returns the state honestly and the operator policy decides what to do — retry, fall through to a default route, alert.

The third decision matters precisely because it preserves the separation. A two-state policy (ACT vs DEFER) conflates known bad and unknown, and either always defers on unknown (cautious, paralyzes low-traffic corridors) or always acts on unknown (optimistic, ignores absence-of-signal). The three-state policy lets the agent distinguish a corridor in distress from a corridor whose Invarians verdict is simply pending. The semantics of WAIT_FOR_DATA belong to the agent's policy, not to the Invarians sidecar; the sidecar only reports that state === null.

4. The workflow code

The complete workflow is 140 lines of TypeScript, including comments and type definitions. It uses the @chainlink/cre-sdk primitives CronCapability (the trigger), HTTPClient (the fetch), runInNodeMode with consensusIdenticalAggregation (the DON-level Byzantine fault tolerant consensus on the read value), and handler + Runner (the lifecycle). The pure gate function is exported separately and unit-tested on synthetic snapshots in companion main.test.ts, five tests covering each verdict branch.

The core of the workflow, the snapshot fetcher and the gate, in their full form:

The configuration is a three-field JSON: a cron schedule, an Invarians API key (publicly redacted as inv_REPLACE_WITH_YOUR_KEY in the sample repository), and the corridor identifier in the {source}-{dest}/{protocol} form used throughout the panel. The full source, including the onCronTrigger entry point that calls runInNodeMode for BFT consensus, the unit tests, and the deployment scaffold, is published verbatim alongside this note.

The Byzantine consensus call

The single line of the workflow that requires Chainlink-side understanding is the runInNodeMode call: runtime.runInNodeMode(fetchInvariansSnapshot, consensusIdenticalAggregation<Snapshot>())(). Each DON node executes fetchInvariansSnapshot independently against the same HTTPS endpoint, then the runtime aggregates results across nodes under the chosen consensus rule. consensusIdenticalAggregation requires every node to produce a byte-identical Snapshot for the workflow to proceed, which is correct here because all nodes querying the same Edge function during the same cycle window read the same row of ans_bridge_states. The workflow becomes Byzantine-tolerant on the read step before the gate logic is ever applied.

5. Two live simulation runs

The Chainlink CRE CLI simulator (cre workflow simulate) compiles the workflow to WebAssembly, enforces production resource limits (HTTP request 10 KB, response 100 KB, timeout 10 s, consensus observation 25 KB, ChainWrite report 5 KB, gas 5,000,000, WASM binary 100 MB / compressed 20 MB), and runs the trigger end to end against the live Internet, including the live Invarians panel.

Two corridors were exercised back to back on 2026-06-04, one with sufficient Fast-mode sample and one without. The corridor identifier in config.staging.json was the only variable changed between the two runs.

Run A, corridor ethereum-arbitrum/cctp:

Run B, corridor ethereum-polygon/cctp:

Two observations on the runs side by side. The binary hash is identical in both runs (abeb67…): the code is unchanged, only the config differs (visible in the different config hashes). The methodology version and calculated-at timestamp stamped in each log line come from the live ans_bridge_states row written by the Rust classifier service ninety seconds before each fetch, which closes the loop on the integrity claim: the verdict the workflow acts on can be traced back to the signed methodology contract through the SHA-256 the sidecar carries.

The third verdict, DEFER, is not demonstrated in this pair of runs because no corridor in production currently has either Fast-mode invariants breached or a stuck Standard-mode message: n_stuck_standard_messages = 0 across the ten CCTP V2 corridors as of the snapshot. The branch is exercised in the unit tests (bun test, five tests pass) on synthetic snapshots where state === "BS2" and stuck_standard === "true" respectively. The absence of a live DEFER today is the honest measurement of corridors that are operating nominally, not a gap in the gate logic.

6. What the simulation does and does not prove

The CRE simulator runs the workflow locally on the developer machine. The binary and config hashes printed in the simulator output are local fingerprints of what the simulator compiled, not blockchain attestations. The HTTPS call hits the live Invarians panel, but the consensus aggregation is exercised by a single simulator node, not by a Byzantine-tolerant DON of multiple independent nodes. The simulator concludes each run with the message Run cre account access to request deployment access, which is the explicit handoff from local validation to a production DON deployment.

What the simulation does prove is that the code compiles to WebAssembly under production resource limits, that the HTTPS fetch returns the live panel correctly, that the sidecar fields are parsed as expected, that the gate function emits the right verdict on the live data, and that the trigger lifecycle (cron → fetch → gate → log → return) completes within one run. It does not prove that a DON of independent nodes would reach byte-identical agreement on the snapshot, nor that the consensus rule chosen here (consensusIdenticalAggregation) is robust under DON timing variance at scale. Those validations require a deployed workflow.

The Q4 2026 step on the Invarians roadmap moves beyond the consumer pattern documented here. In its full form, the same threshold-signature mechanism Chainlink CCIP uses on CommitReportAccepted events is intended to host the Invarians attestation flow itself: each DON node fetches structural metrics from its own RPC endpoint and reaches consensus on the regime vector, rather than consuming a centrally signed payload. The sample in this note is the consumer half of that picture; the producer half is the open architectural question that follows.

7. Reproducing the runs

The full source, the configuration, and the test suite are published in a dedicated repository. Reproducing the two runs above requires the Chainlink CRE CLI, the Bun runtime, an Invarians API key (free Beta tier sufficient, sign-up here), and four terminal commands: cre workflow init, copy in the three files (main.ts, main.test.ts, config.staging.json), set the API key in the config, then cre workflow simulate from the parent directory of the workflow folder. The complete protocol is in the repository README.

The interesting next step from this point is not to polish the sample further, but to exercise the gate against a CRE workflow that does something downstream of the verdict: an intent solver that withholds a fill when WAIT_FOR_DATA is returned, a treasury rebalancer that retries on the next tick when DEFER appears, an RWA settlement automation that proceeds only on ACT. The structural sensing is the cheap part; the policy attached to each verdict is what each consumer brings.

Code repository: agentnorthstar/calibration (methodology, signed). Sample workflow repository: to be published with this note. Edge function source: foundations.html § 04. CRE integration documentation: invarians.com/cre.html.