Hive Canon · Provable Layer · Born Here

ViewKey. One receipt. Three lenses.

The same signed receipt looks different depending on who you are. The holder sees the full record. The regulator sees the compliance-relevant slice. The counterparty sees only what concerns them. One canonical signature. Three audited views. No copies, no edits, no plausible deniability.

Doctrine · Provable Layer URN reserved Schema publish pending

The three lenses

LENS 01

Holder

The full canonical receipt. Every field, every hash. Used for personal audit and dispute defense.

LENS 02

Regulator

The compliance slice. Policy id, scope ceiling, spend totals, jurisdictional fields. No business secrets, no counterparty identities beyond what the regulation requires.

LENS 03

Counterparty

Their slice only. Receipt id, the resource transacted, the price and timestamp. None of the agent's other activity.

Why a single receipt

Most systems solve this with three different exports — the audit log for compliance, the customer copy for the counterparty, the back-office record for the holder. Drift is inevitable, and disputes turn into a fight about which record is real. ViewKey collapses that into one signed record. The signature is on the canonical payload. The lenses are deterministic projections of that payload. Everyone sees less, but they all see the same thing.

Current status

URN reserved at urn:hive:viewkey:v1. Registered in hivetrust.json under the Provable pillar. The public JSON Schema payload at /.well-known/schemas/viewkey-v1.json is targeted for the v0.3.3 publish window. Today, ViewKey ships inside the HiveTrust verifier pipeline as an internal projection rule. The canonical schema publish unlocks third-party verifiers writing their own lens decoders.