WHAT THIS PAGE OFFERS
Three attestation tools for compliance teams and AI agents. Creating records
requires an API key (any active subscription, including the free trial).
Verifying a record you were handed is public and needs no account, the same
trust model as a TLS certificate.
1. SIGNED DECISION RECORDS
Mint an Ed25519-signed record of a compliance decision: which node was
consulted, what was decided, when. Anyone holding the record ID or the record
itself can verify the signature independently.
POST /api/v1/attest create a signed record (API key required)
GET /api/v1/attest/{id} fetch and re-verify a record (public)
GET /api/v1/attest/mine list your records (API key required)
GET /api/v1/attest/keys the full public keyset (current + retired keys)
Every signature carries a key id (kid, an RFC 7638 JWK thumbprint). Signing
keys rotate on a fixed schedule; the public half of every retired key stays
published forever at /api/v1/attest/keys, so old records never stop verifying.
INDEPENDENT OFFLINE VERIFICATION
The signed-view fields and canonicalisation rules are published at
https://bidda.com/.well-known/bidda-attestation-spec.md and are a frozen
public contract. A browser-based verifier that runs entirely on your machine
lives at https://bidda.com/verify-attestation/. You can reproduce
verification byte-for-byte in any language from the spec alone.
2. POINT-IN-TIME RECORDS
A signed statement of which node version was authoritative at a given moment,
anchored to the public per-node version history.
POST /api/v1/pit create a point-in-time record (API key required)
GET /api/v1/pit/{id} fetch and re-verify (public)
GET /api/v1/pit/mine list your records (API key required)
History anchors: /api/v1/history/{node_id}.json and /api/v1/history/index.json
3. RUN LEDGER (SIGNED RECEIPT FOR AN ENTIRE AGENT SESSION)
Open a run at the start of an AI agent session, append one hash-chained entry
per step or turn, then seal the run to receive a signed Run Receipt containing
a Merkle root over every entry. Any tampering with any entry breaks the chain.
POST /api/v1/runs open a run (API key required)
POST /api/v1/runs/{id}/entries append one entry (owner only)
POST /api/v1/runs/{id}/seal seal the run, returns the signed Run Receipt
GET /api/v1/runs/{id} fetch a run (owner always; public once sealed)
GET /api/v1/runs/mine list your runs (API key required)
GET /api/v1/runs/{id}/audit-pack auditor-ready evidence pack for a sealed run
Governed runs: the consult_node MCP tool (and SDK Run.consult) fetches a full
node and records a verified, hash-pinned run entry in one call, so the sealed
receipt proves exactly which version of the rule the agent read.
The Run Receipt is signed with the same rotating Ed25519 keyset as decision
records and verifies against /api/v1/attest/keys. Sealed runs are publicly
fetchable by ID, so an auditor can confirm an agent session without a Bidda
account.
AGENT ACCESS
All three tools are also exposed as MCP tools on the Bidda MCP server
(https://bidda.com/mcp): create_attestation, point_in_time, open_run,
record_run_entry, consult_node, seal_run, get_run, get_audit_pack.
Start a free trial at https://bidda.com/pricing. Questions: [email protected]