Specification

Delegation and operational keys

RVW-3
StatusDraft  Expected to change. Do not build on it without saying so.
Version0.2
Updated9 Nov 2026
Depends onRVW-1
LicenceCC0 1.0. Implement it without asking.
01

Scope

How one professional holds a credential on a cold identity key and still uses a fresh address for every job. A real estate agent wanting a separate address per payout is normal practice, for accounting as much as for privacy, and a protocol that forces one address per person will simply not be used.

02

Two kinds of key

identity key

Holds the claim. Signs delegations. Used a handful of times a year and meant to live in hardware.

operational key

Receives money, signs a job. Short lived, disposable, holds no credential of its own.

Credentials never attach to an operational key. History, reputation and licence evidence all accumulate on the identity, which is what makes a fresh address per job free of cost to the professional.

03

The delegation document

delegation.jsonJSON
{
  "rvw": 3,
  "claim": "fba0fc855026ba9758a1bbb2a41b3a4a5ebe54be5aca29b07c034d5c0e04ae10",
  "identity": "0xa805a67f59cccc9869d5dcb4ffc02fc697b5819d",
  "operator": "0x1f77bd3e5a0c92486df1b0a7c5e4839d2b6f0a11",
  "scope": "payout:0x9c3d...e5f1",
  "not_before": "2026-11-09T00:00:00Z",
  "not_after": "2026-11-23T00:00:00Z"
}

Signed by the identity key as EIP-712 typed data over the fields above. not_after is mandatory and capped at ninety days. scope is an opaque string a consumer matches exactly, or the empty string for any job.

04

Verification order

  1. Verify the claim first

    An operational key with a delegation from an expired or revoked claim carries nothing.

  2. Check the delegation signature

    It must recover to the identity named in the claim subject, not to any other key.

  3. Check the window

    Now must fall between not_before and not_after.

  4. Check the scope

    If a scope is set, it must equal the job the consumer is displaying. A mismatched scope is a failure, not a warning.

05

Unlinkable delegations

Published delegations defeat the purpose for anybody who wanted a fresh address for privacy, since one fetch gives an observer every address an identity has ever used.

The variant under consideration publishes only a Merkle root of delegation digests, periodically. Presenting a delegation means revealing the document and its path to a root. A payer checking one job learns one address. An observer crawling the roots learns a count and nothing else.

This is drafted but not implemented. It does not defeat timing correlation: a root published minutes before a payout still narrows the set. Open problem OP-4.

06

Limits

A compromised identity key signs valid delegations until the claim is revoked, which is the same exposure as any credential system and the reason claims are short lived. A stolen operational key is worth one job and expires by itself.

Read this page as Markdown