Trust Architecture
Every receipt is signed.
Check it yourself.
Trust Hierarchy
Root. Service. Producer.
Each DRM3 product signs with its own Ed25519 key. Keys form a three-level hierarchy. Verification walks the chain from any producer receipt up through its service signer to the DRM3 root.
DRM3 Root
Master signer. Certifies all services.
Path: drm3/root
Service Signers
Each product derives a service-level key. Signs Merkle roots over all producer receipts.
Path: {service}/signer
Producer Keys
Individual signing keys for specific data operations. Every row, every scan, every fetch.
Path: {service}/{producer}
Verification flow: receipt→producer key listed in service registry→service certified by root→root key published at /.well-known/drm3-keys.json
Receipt Anatomy
Every operation in DRM3 produces a receipt. The receipt is the claim and the proof in one act: what was done, what data went in, what came out, and who signed it.
Receipts are chained. Each receipt can point to its parent via parent_id, forming a directed graph from raw source through every transformation to the final output. Walk the chain backward to verify the full provenance.
{
"id": "rcpt_a1b2c3d4e5f6a7b8",
"action": "signals.row.nasdaq",
"timestamp": "2026-04-07T06:00:40.045Z",
"input_hash": "sha256:7d4e3eec80026719...",
"output_hash": "sha256:3f2b8a91cc4d7e6f...",
"duration_ms": 496,
"parent_id": "rcpt_9c8b7a6f5e4d3c2b",
"metadata": {
"_meta": {
"protocol": "drm3-provenance-v1",
"product": "DRM3 3P Signals",
"signer": "signals-3p/nasdaq",
"source": "nasdaq",
"vendor": "nasdaq",
"api_urls": [
"https://api.nasdaq.com/api/quote/AAPL/info"
],
"query_description": "NASDAQ listings - 12455 securities",
"fetched_at": "2026-04-07T06:00:40Z",
"response_status": 200,
"bytes_in": 0,
"bytes_out": 839597,
"duration_ms": 496,
"data_license": "https://github.com/DRM3Labs/drm3-data-licenses/blob/73e09ab/third-party/nasdaq.md",
"attestation": "This data was fetched from nasdaq at 2026-04-07T06:00:40Z and signed with Ed25519 by signals-3p/nasdaq. US Government public domain data."
}
},
"public_key": "ed25519:cfc9748b46dc1945a6ef4fdabff44871de40fad616c59fee98d7ec90e73dac22",
"signature": "ed25519:..."
}Core fields
The _meta attestation packet
Every receipt that signs fetched or external data includes a _meta object inside the outputs. Because output_hash covers the data and _meta together, the attestation is cryptographically inseparable from the data it describes.
On-Chain Lookup
Check any signer path against the DRM3Registry on Base. No wallet needed. Reads directly from the contract via public RPC.
Who holds the keys
Three questions an auditor asks first, answered from the registry itself.
- Custody
- Every service signs with its own Ed25519 key, and the registry that lists those keys is itself signed by the DRM3 root key. The registry states the root's custody tier in its own note: today the root is an operational hot secret, not an offline hardware root, and the cold-root migration is tracked as a follow-up. That is the truth as published, not a promise.
- Rotation
- A key is published with the date it took over and, for most keys, the date it is expected to retire. When a key rotates, the new key becomes current and the old one moves into the service's history with its dates, so any receipt is checked against the key that was current when it was signed. Rotations to date are in the history of each service.
- Compromise
- A compromised key is rotated the same way: retired into history with the window it was current, and replaced. Receipts signed inside that window stay attributable to that key and that window. Nothing signed is re-signed or removed; the history records what was current when.
Read it yourself: the signed key registry.
Verify a Receipt
Paste a DRM3 provenance receipt below. Verification runs entirely in your browser using the Web Crypto API. Nothing is sent to any server.