DEV Community: GUARDIANCHAIN-GC1

Verify an AI Governance Claim Across Six Blockchains in Five Minutes (Without Trusting the Vendor)

GUARDIANCHAIN-GC1 — Fri, 17 Apr 2026 14:54:05 +0000

Most infrastructure asks you to trust it. You send data to a vendor, the vendor promises to handle it correctly, and later, if something goes wrong, you rely on the vendor's word, the vendor's logs, and the vendor's willingness to cooperate with your audit.
Forward verification inverts that. It is a property of infrastructure where any third party can check the vendor's claims independently, using only public data, without the vendor's cooperation, and without trusting the vendor at all. The vendor cannot lie, because the proof is not in the vendor's hands.
This article is a walkthrough. By the end of it, you will have taken a real capsule ID from GuardianChain's production system, verified its claims across six blockchains yourself, and understood the mechanism well enough to explain it to a colleague. The verification takes about five minutes. Everything you need is public.
What a capsule is
A GuardianChain capsule is a signed, hashed record of something that happened. It contains metadata about an event, a cryptographic hash of that event's content, and signatures proving who created it. The content itself stays with you; only the hash goes into the capsule. This is the non-custodial property: GuardianChain never holds your data, only the proof that your data existed at a specific moment.
Once a capsule is created, its hash is anchored into six independent blockchains: Base, Polygon, Ethereum, Optimism, Arbitrum, and Arweave. Anchoring means the hash is written into a transaction on each chain, so each chain now contains an immutable record that this specific capsule hash existed at this specific block height.
The forward verification claim is simple. Given a capsule ID, anyone can independently confirm that the capsule's hash appears in a transaction on each of those six chains, at the block height the capsule claims, with a signature that matches the public key the capsule claims. No GuardianChain API call is required for the verification itself. The blockchains are the source of truth.
The capsule we are going to verify
We are going to verify capsule e1a9a038-9938-4c63-a883-43e0ed21dfc6. This capsule is a RUNNING_STATE_AUDIT, produced on April 17, 2026, documenting a twelve-hour window of operational activity in GuardianChain's production system. It was created, anchored, and made retrievable through the platform's normal pipeline. Nothing about it is special. It is a working example.
Step 1: Retrieve the capsule metadata
Fetch the capsule record from GuardianChain's public DC-1 endpoint:
bashcurl https://gc-1-production.up.railway.app/api/dc1/capsule/e1a9a038-9938-4c63-a883-43e0ed21dfc6
You will get back a JSON object containing the capsule's hash, creation timestamp, anchor transaction hashes for each of the six chains, and the signing public key. Save this response. Everything that follows uses fields from it.
The key insight: GuardianChain is only giving you the pointers. The actual proof lives on chains GuardianChain does not control.
Step 2: Verify on chain one (Base)
Take the base_tx_hash field from the response. Go to the Base block explorer:
https://basescan.org/tx/
You will see the transaction on-chain. Look at the transaction's input data. Embedded in it is the capsule hash. Copy that hash. Confirm it matches the content_hash field in the capsule JSON you retrieved in Step 1.
That is one chain verified. Base's operators do not know GuardianChain exists. Base simply records that at a specific block, at a specific timestamp, a specific hash was written into a transaction. The hash matches. The claim holds.
Step 3: Repeat on the remaining five chains
Do the same thing on each of the other five anchors:

Polygon: https://polygonscan.com/tx/
Ethereum: https://etherscan.io/tx/
Optimism: https://optimistic.etherscan.io/tx/
Arbitrum: https://arbiscan.io/tx/
Arweave: https://viewblock.io/arweave/tx/

Each explorer is operated independently. Each chain is operated independently. The hashes all match. The timestamps all fall within the batch window you would expect for a capsule anchored through a Merkle-batched pipeline.
Step 4: Verify the signature
The capsule metadata includes a signature and a public key. Take the capsule's canonical serialized form (the JSON with fields in a defined order, specified in GuardianChain's public schema), compute its SHA-256 hash, and verify the signature against the public key using any standard Ed25519 library:
javascriptconst nacl = require('tweetnacl');
const verified = nacl.sign.detached.verify(
messageHash,
signatureBytes,
publicKeyBytes
);
console.log(verified); // true
You now have end-to-end proof. The capsule was signed by the holder of a specific private key. The hash of the capsule appears on six independent blockchains. The blockchains were written to at times that predate this moment, meaning no one could have forged this record after the fact without also forging history on six chains simultaneously, which is economically and cryptographically infeasible.
Why this matters
You just verified a claim about an AI governance event without calling GuardianChain's API for anything except the pointer lookup, and even that lookup could be replaced with a local cache or a mirror. The verification itself ran against public blockchain data, using public explorers, using standard cryptographic libraries.
This is what forward verification means as a property. It is not a claim the vendor makes about their own reliability. It is a mathematical structure that makes the vendor's reliability irrelevant. If GuardianChain disappeared tomorrow, every capsule ever created would remain verifiable forever, by anyone, using the same steps you just followed.
For AI governance, this property matters because the alternative is trust. Regulators and auditors currently have to trust that vendor logs are accurate, that vendor timestamps are honest, and that vendor cooperation will be available when needed. Forward verification removes all three dependencies. A capsule either verifies, or it does not. The vendor's posture is not part of the answer.
What to do next
If you want to try this on a capsule you create yourself, the CLI is at npm install -g @guardianchain/cap. Documentation and the public verification endpoint live at guardianchain.io. The MCP tool gc1_forward_verify does the above steps programmatically inside any MCP-capable LLM client.
If you found this useful, the most valuable thing you can do is explain it to another developer. Forward verification only becomes the default expectation for AI governance infrastructure if enough people know it is possible.

How to Create Immutable Audit Trails for AI Agents

GUARDIANCHAIN-GC1 — Thu, 02 Apr 2026 20:52:33 +0000

Troy Anthony Cronin is the founder of GuardianChain, LLC and the architect of GC-1 — non-custodial cryptographic evidence infrastructure for AI accountability. 64,000+ governance capsules sealed, 328-day unbroken sovereign seal chain.

Your AI agent approved a $400K credit line at 2:14 AM. Three months later, the applicant defaults and the regulator calls. Can you prove exactly what the model evaluated, what rules it checked, and why it said yes?

If your agent's audit trail lives in a database you control, the answer is: not really. Mutable logs are not evidence. They are assertions you can edit at any time.

This article shows you how to build immutable audit trails for AI agents — trails that are anchored to public blockchains, independently verifiable by anyone, and cryptographically tamper-proof. No trust in the vendor required.

The Problem with Mutable Logs

Most AI systems log decisions to a database or object store. This creates three problems regulators already understand:

Logs can be altered after the fact. There is no way for an external party to confirm that what you show them today is what actually happened six months ago.
Log completeness is unverifiable. If you deleted an embarrassing entry, no one can prove it was ever there. No one can prove it was not there, either.
Timestamps are self-asserted. Your server clock is not an independent authority. You control it.

Blockchain anchoring solves all three. Once a hash is committed to a public chain, it cannot be edited, deleted, or backdated. The chain's block timestamp is independent of your infrastructure.

Architecture: Non-Custodial Evidence

GC-1's approach is non-custodial. Your data never leaves your infrastructure. Only a SHA-256 hash is submitted. The hash is anchored to up to 6 blockchain networks (Base, Polygon, Ethereum, Optimism, Arbitrum, Arweave) and replicated across 5 cloud storage providers.

This means:

GC-1 cannot read your data (it never receives it).
GC-1 cannot alter your evidence (blockchain anchors are immutable).
Anyone can verify your evidence (public blockchain, no account needed).

Step 1: Seal Agent Decisions

Install the SDK:

npm install @guardianchain-llc/gc1

Seal a governance decision:

import { GuardianChain } from '@guardianchain-llc/gc1';

const gc1 = new GuardianChain({ apiKey: process.env.GC1_API_KEY! });

const decisionData = JSON.stringify({
  agentId: 'lending-agent-v3',
  applicantHash: gc1.hash('applicant-12345'),
  action: 'CREDIT_APPROVED',
  amount: 400000,
  modelVersion: 'gpt-4-turbo-2025-04',
  featuresUsed: ['income', 'employment_length', 'debt_ratio'],
  timestamp: new Date().toISOString(),
});

const capsule = await gc1.seal({
  contentHash: gc1.hash(decisionData),
  anchorClass: 'INSTITUTIONAL_REGULATED',
  metadata: {
    title: "'Credit Decision - Applicant 12345',"
    kind: 'AI_GOVERNANCE',
  },
});

What just happened:

You hashed the decision data locally. The raw data never left your server.
The hash was submitted to GC-1, which anchored it to Base L2 and Polygon.
The hash was replicated to Cloudflare R2, AWS S3, and Backblaze B2.
An Ed25519 certificate was issued and signed.
The capsule was included in the next sovereign seal batch.

The result is a governance capsule with a unique ID, a verification URL, and a certificate PDF — all independently verifiable.

Step 2: Verify Evidence Independently

Any party can verify a capsule without trusting GC-1. The SDK verify method checks the blockchain anchors directly:

const result = await gc1.verify(capsule.data.capsule_id);
// CERTIFIED = anchored on blockchain, signature valid, hash confirmed

For air-gapped or classified environments where no network call is acceptable, use the offline verifier:

npm install -g @guardianchain-llc/gc1-verify

gc1-verify bundle.json
gc1-verify --hash <capsuleId> <contentHash> <anchorClass>
gc1-verify --cert certificate.json

The offline verifier uses only Node.js built-in crypto. No GC-1 libraries, no network calls, no trust in any vendor. If the math checks out, the evidence is valid.

Step 3: Link Decisions to Sessions

Real agents do not make decisions in isolation. They operate in sessions — sequences of related actions. GC-1 links capsules to sessions so the full decision chain is reconstructable:

const sessionStart = await gc1.seal({
  contentHash: gc1.hash(JSON.stringify({
    sessionId: 'lending-review-2026-04-02',
    agentId: 'lending-agent-v3',
    action: 'SESSION_START',
    timestamp: new Date().toISOString(),
  })),
  anchorClass: 'INSTITUTIONAL_REGULATED',
  metadata: {
    title: "'Lending Review Session Start',"
    kind: 'AI_GOVERNANCE',
  },
});

// Agent performs analysis, checks rules, makes decision...

const decision = await gc1.seal({
  contentHash: gc1.hash(JSON.stringify({
    sessionId: 'lending-review-2026-04-02',
    agentId: 'lending-agent-v3',
    action: 'CREDIT_APPROVED',
    amount: 400000,
    ruleResults: [
      { ruleId: 'FAIR_LENDING_001', result: 'PASS' },
      { ruleId: 'DEBT_RATIO_001', result: 'PASS', detail: '0.38 < 0.43' },
    ],
    timestamp: new Date().toISOString(),
  })),
  anchorClass: 'INSTITUTIONAL_REGULATED',
  metadata: {
    title: "'Credit Decision - Approved',"
    kind: 'AI_GOVERNANCE',
  },
});

const history = await gc1.sessionHistory('lending-review-2026-04-02');

Each capsule in the session is independently anchored. If a regulator asks for the complete decision chain, you reconstruct it from the session history — every step is hash-linked and blockchain-proven.

Step 4: Prove What Didn't Happen

Most audit systems can only prove what did happen. GC-1 can prove what didn't happen.

If your lending agent is required to check fair lending rules before every credit decision, the absence of a governance capsule for that check is itself evidence of a violation. GC-1 calls this Silent Witness — an absence proof.

And if your agent was presented with a prohibited action and refused to execute it, that refusal is sealed as a Proof of Restraint capsule. This proves the governance system actively prevented harm, not just that harm didn't happen to occur.

No competitor offers absence proofs or governed refusal evidence. Both are sealed using the same seal method shown above.

Why Not Just Use a Database with Checksums?

You could hash your logs and store the hashes. But who verifies the hashes? You. That is the problem. Self-asserted integrity is not evidence. It is a claim.

Blockchain anchoring moves the trust anchor outside your organization. The hash is committed to a public ledger that you do not control, that you cannot edit, and that anyone can read. That is the difference between a log and evidence.

What This Means for Compliance

The EU AI Act (Article 12) requires high-risk AI systems to maintain logs that enable tracing and auditing. The NIST AI RMF calls for documented AI governance with verifiable records. SEC and FINRA expect auditable decision trails for algorithmic trading and lending.

None of these frameworks are satisfied by mutable database logs. All of them are satisfied by immutable, independently verifiable, cryptographically signed evidence trails.

Getting Started

npm install @guardianchain-llc/gc1

Three lines to provable governance:

import { GuardianChain } from '@guardianchain-llc/gc1';
const gc1 = new GuardianChain({ apiKey: process.env.GC1_API_KEY! });
const capsule = await gc1.seal({ contentHash: gc1.hash(yourData) });

Public verification requires no API key and no account. Anyone can verify any capsule at any time.

Documentation: guardianchain.io
SDK: @guardianchain-llc/gc1 on npm
Offline Verifier: @guardianchain-llc/gc1-verify on npm

GuardianChain, LLC is a Delaware company building non-custodial cryptographic evidence infrastructure for AI accountability. GC-1 proves what happened, what didn't happen, and what was actively prevented from happening — permanently, independently, and without storing any underlying content.