Public · format-agnostic · verifiable without us
The Open Evidence Rail
CapchaCloud today seals evidence in its own shapes. The Open Evidence Rail (OER) makes the rail format-agnostic: anyone registers their own data format, seals a payload through it, and any third party can verify the result offline — forever, without trusting us. We stop being a vendor with integrations and become a registry with a chain under it.
What a receipt PROVES
- The exact payload bytes you submitted, canonicalized under the format's declared mode (RFC 8785 JCS, raw bytes, or RFC 8949 deterministic CBOR), hash to a specific value.
- That value was validated against the exact registered format@version's JSON Schema and content hash — cited on the receipt, so you can independently fetch and re-check the schema it was sealed against.
- The payload was written into CapchaCloud's content-addressed, hash-verified evidence vault (with WORM retention only where the underlying bucket lock is configured) and folded into CapchaChain's tamper-evident, hash-linked, Ed25519 + ML-DSA-65 (post-quantum) signed block structure, anchored by multiple independent RFC 3161 timestamp authorities (DigiCert, Sectigo, FreeTSA) plus Bitcoin/OpenTimestamps.
- Sealing time is ≈50ms end to end.
What a receipt does NOT prove
- Regulatory approval, legal compliance, or execution of any real-world action described
by the payload — every receipt says this explicitly (
does_not_prove). - That the payload's contents are true. CapchaCloud canonicalizes, schema-validates, and seals exactly what you submitted; it does not interpret or attest to its real-world meaning beyond what the format's own field map projects.
- Anything about a party's identity beyond what your own format and payload assert.
- Immediate global availability: a fresh seal is chain-inclusion-pending until the next block production run (daily) or the operator's on-demand seal — the vault write, audit-chain hash, and receipt are immediate; Merkle inclusion into a signed block follows.
20-line quickstart
Dependency-free JavaScript, works in Workers, Node 18+, Deno, Bun, and the browser. No account needed to verify anyone's receipt; you only need a key to seal your own.
import { OerClient } from "https://capchacloud.com/sdk/oer.js";
const oer = new OerClient({ apiKey: process.env.CAPCHACLOUD_API_KEY });
// 1. Register a format once (first-come, permanent ownership of the format_id).
await oer.registerFormat({
formatId: "my-app-event", version: "1.0.0", humanName: "My App Event",
canonicalizationMode: "jcs",
jsonSchema: { type: "object", required: ["subject"], properties: { subject: { type: "string" } } },
});
// 2. Seal a payload through it.
const receipt = await oer.seal({ formatId: "my-app-event", payload: { subject: "order-123" } });
console.log(receipt.seal_id, receipt.chain_hash);
// 3. Anyone (not just you) can fetch and verify it offline.
const bundle = await oer.fetchBundle(receipt.seal_id);
const result = await oer.verifyBundleOffline(bundle);
console.log(result.ok); // true
No account, no build step, no CapchaCloud-specific SDK lock-in required to verify a receipt — the bundle is a self-contained, signed JSON object anyone can check against the published key at /api/v1/chain/pubkey. The full, authoritative offline check (Merkle inclusion + RFC 3161 + OpenTimestamps, not just the signature) is a standalone Node script, same one every other CapchaCloud evidence bundle uses.
What's built today
Canonicalization
JCS (RFC 8785), raw bytes, and RFC 8949 deterministic CBOR. Fail-closed: an ambiguous payload (duplicate keys, a float that can't round-trip exactly) is rejected with a precise reason, never best-effort-hashed.
Format registry
Register a format, publish new versions, first-come/permanent ownership. Every registration is content-hashed and immutable — publishing v2 never changes what v1 receipts were sealed against. Browse every registered format.
Cross-format references
A receipt in one format can cite a receipt in a completely different format, from a completely different tenant, with no coordination required. Verification walks the reference graph and confirms each cited receipt's integrity and chain inclusion — without ever disclosing its payload.
Reference adapters
Plain JSON (zero-friction on-ramp), a Gordian-Envelope-aligned subject/assertion adapter, and an ISO 20022 exact-bytes adapter — all three built on nothing but the public SDK, proving the rail needs no privileged access.
Conformance suite
Run it against your own adapter to earn L1 (seals + verifies offline), L2 (+ deterministic canonicalization over a randomized corpus), or L3 (+ cross-format references verify). Built to fail loudly against a broken adapter — a mark that can't fail is worthless.
Self-serve onboarding
Claim an invite code, get a tenant and API key, register your first format, seal your first receipt, and see it verify — with zero human contact from us. Start here.
evaluate: true) described in early design notes is NOT implemented — a request
with it gets an explicit 400, never a fake verdict. Per-tenant reference visibility opt-out
(hiding that your receipts are cited at all) is also not implemented; the default policy
(reference existence disclosed, payload never disclosed) is the only one shipped. We say so here
instead of leaving you to find out the hard way.