What we will and will not say
Trust
The product’s only real moat is that it does not over-claim. Four audits found the code held that discipline and the surrounding material did not. So the permitted claims live in the codebase as data, this page renders them, and a claim that is not here does not appear on this site.
Claims register
| Claim | Status | Required qualifier, or the reason it is refused |
|---|---|---|
| Tamper-evident | Allowed | Accurate at every tier, including the free Sealed tier. Signed over canonical bytes and hash-chained to the previous record. |
| Anchored to Bitcoin | Qualified | Via OpenTimestamps, which commits a Merkle root and confirms in roughly an hour. Until you supply and accept a block-header source, the attestation reads asserted_unverified, not verified. |
| Provable even against the vendor | Qualified | True on the Anchored tier with accepted trust pins. NOT true of a default deployment, where nothing is pinned and every record caps at SIGNED_PENDING. |
| Compliance-grade | Qualified | Anchored tier only. The Sealed tier is terminal — those records never become anchored — and the library refuses to build a report from them by default. |
| eIDAS timestamps | Qualified | Article 41(1) admissibility only. The default TSAs (DigiCert, Sectigo) are publicly-trusted commercial services, not qualified trust service providers on any Member State Trusted List. Article 41(2)’s presumption of accuracy applies only to a qualified timestamp; without one, the party relying on it carries the evidential burden. |
| Ships the controls a data-protection programme needs | Allowed | Crypto-shredding, retention and purge, a minimisation gate defaulting to digest-only, an enforced residency allowlist, supersession, and dossier access logging. It cannot supply your lawful basis, DPIA, processor contract or privacy notice. |
| Independently audited | Qualified | Four independent adversarial audits produced 86 findings, all dispositioned. Every audit is published here in full, opening verdict included. Never phrase this as "audited and passed". |
| Production-ready | Never | No wire format has yet been exercised against a live DigiCert, Sectigo, OpenTimestamps calendar, Rekor or Witness endpoint. Until those integration tests exist, the honest phrasing is "production-grade engineering, wire formats not yet exercised against live endpoints". |
| MiCA-ready / MiCA reporting / AML screening | Never | No AML capability exists at all — no screening provider, no screening field, no integration. MiCA obligations attach to issuers and authorised CASPs and consist of authorisation, prudential safeguards, governance arrangements, record-keeping, complaints handling, conflicts of interest, custody segregation and market-abuse controls. This product performs none of them. |
| EU AI Act Article 12 logging | Never | A category error. Article 12 imposes event-logging duties on high-risk AI systems so their own functioning is traceable. This product seals human governance actions. There is no AI system in the loop whose operation is being logged. |
| The customer holds the signing key | Never | There is no local signing anywhere in the codebase. Every record is signed server-side by VDA Witness. The only private key this software touches is the Ed25519 controller key used to renew an API key, which signs a renewal challenge and never a record. |
| GDPR-compliant / legally compliant / reduces your liability | Never | Nothing here makes a deployment compliant, and nothing here is legal advice. The product produces evidence a human then interprets and attests to. |
Which key signs what
Sealed records are signed under did:web:witness.getvda.ai. That is VDA Witness, and it is the identity every offline verification resolves against.
This site is a different service. It signs no records, its agent card is currently unsigned, and if it later publishes a service DID for signing that card, that key will attest the card and never any evidence. Two DIDs on adjacent subdomains, one of which attests evidence and one of which does not, is exactly the sort of thing that gets conflated in a courtroom.
Fetch the record-signing key yourself rather than trusting a copy: https://witness.getvda.ai/.well-known/did.json
What this site processes
| Surface | What it receives | What is retained |
|---|---|---|
/scan | Your identifier. It then reads Snapshot or Safe on your behalf, which returns voter and signer addresses. | No addresses. They are counted and discarded within the request. Results are aggregates and the response contains no address. |
/verify | The proof bundle you paste, which may contain addresses and free text. | Nothing. Verification is in-memory and makes no network call. |
/mcp, /a2a | Tool arguments, which are the same inputs as above. | Nothing beyond the rate-limit counter. |
| Rate limiting | Your IP address. | A salted SHA-256 prefix of it and a counter, expiring hourly. The raw IP is never stored. Current store: in-memory — per-instance, so it is a courtesy brake rather than a control. |
This site sets no cookies, runs no analytics, and has no account system. When you scan a DAO, that DAO’s hub or transaction service sees a request from this service — your query pattern is visible to them, as it would be if you queried them directly.
The product itself processes considerably more, and it is documented rather than summarised: read DATA-PROTECTION.md before your first seal.
For agents
Read-only, free and unauthenticated — because nothing exposed here is worth authenticating. No tool writes a record, spends an anchoring budget, mints a credential, or returns personal data.
Remote MCP
Streamable HTTP. POST JSON-RPC 2.0 to the endpoint; it is stateless and issues no session id.
{
"mcpServers": {
"witness-dao": { "url": "https://witness-dao.getvda.ai/mcp" }
}
}A2A
Agent card at /.well-known/agent-card.json (also served at /.well-known/agent.json). JSON-RPC endpoint at https://witness-dao.getvda.ai/a2a, implementing message/send. Invoke a skill with a DataPart shaped { "skill": "<id>", "input": { … } }.
Skills and tools
| MCP tool | A2A skill | Does |
|---|---|---|
governance_readiness_scan | governance-readiness-scan | Governance evidence readiness scan |
verify_evidence_bundle | verify-evidence-bundle | Verify a Witness-DAO proof bundle |
evidence_strength_matrix | evidence-strength-matrix | Explain the evidence-strength calculus |
witness_dao_capabilities | witness-dao-capabilities | What Witness-DAO does, does not do, and does not yet do |
Deliberately absent
There is no liability-defence skill, and its absence is advertised. The pack is a behavioural profile of an identified natural person — what they voted on, what they did not, when, and with how much weight — and the subject is usually not the requester. Returning that into an agent’s context puts it in the conversation transcript and whatever provider retention sits behind it, for a person who was never asked and never told.
The identical call serves “defend our own signer” and “build a file on a rival”, and only a recorded purpose tells them apart afterwards. A public capability advertisement reading “I will profile any address you name” is not a feature. It stays in the CLI, behind a mandatory purpose and a local access log.
Sealing is likewise not offered here: it needs your Witness credential and your git-held governance rules, and a decision recorded without the rule that authorised it is a log line, not evidence. Machine-readable description at /llms.txt.
The audits
Four independent adversarial audits, published in full with their opening verdicts intact, alongside the disposition of all 86 findings. Read them. Three of those findings invalidated the product’s core promise before they were fixed; that is stated in the remediation document rather than softened.