Hive Canon · Provable Layer · Born Here

ViewKey. One receipt. Three views.

The same signed receipt looks different depending on who's reading it. The holder sees the full record. The regulator sees the compliance-relevant part. The counterparty sees only what concerns them. One signature backs all three views, so there's no separate copies, no edits, and no room to argue about which version is real.

Doctrine · Provable Layer URN reserved Schema publish pending

The three views

VIEW 01

Holder

The full receipt. Every field, every fingerprint. Used for personal record-keeping and defending against disputes.

VIEW 02

Regulator

Just the compliance-relevant part: policy ID, scope ceiling, spend totals, jurisdictional fields. No business secrets, and no counterparty identities beyond what the law actually requires.

VIEW 03

Counterparty

Only their own slice: the receipt ID, what was traded, the price, and the timestamp. Nothing else about the agent's other activity.

Why keep it to one receipt

Most systems handle this by creating three separate exports: an audit log for compliance, a customer copy for the counterparty, a back-office record for the holder. Those three copies drift apart over time, and any dispute turns into an argument about which one is real. ViewKey keeps it all as one signed record. The signature covers the whole payload, and each view is just a fixed, repeatable slice of that same payload. Everyone sees less than the full picture, but what they do see is never a different story.

Where this stands today

URN reserved at urn:hive:viewkey:v1. Registered in hivetrust.json under the Provable pillar. The public JSON Schema file at /.well-known/schemas/viewkey-v1.json is planned for the v0.3.3 release. Right now, ViewKey runs inside the HiveTrust verifier pipeline as an internal rule. Once the schema is public, other verifiers will be able to build their own view decoders too.