The actors
Alice — Information Owner
Date of birth: 2 April 2007
Retailer — Information Requestor
Wants a single yes/no answer
Databank
Holds the encrypted record & the permission policy
Step by step
- 1
Query submissionThe retailer submits an algorithm to the Databank — not a request for data. There's no third party in the loop: the Databank itself runs the sandbox.
- 2
Permission checkThe Databank checks Alice's standing permissions. She has pre-authorised age-threshold checks from verified retailers, twice per requestor per year. The query passes. Outside those standing permissions, the Databank could reject the query outright, or forward a one-off consent request to Alice before proceeding.
- 3
Sandboxed executionThe algorithm runs inside a secure enclave or equivalent — visible only to the Databank, never to the retailer.
- 4
Bit-scarce outputExactly one bit crosses the boundary: { "eligible": true }. No date of birth, no exact age, no margin.
- 5
Settlement & auditThe transaction is logged on Alice's statement; the retailer pays an access fee; Alice receives her statutory share.
What actually executes
def age_over_threshold(date_of_birth, threshold_years, as_of):
age_years = years_between(date_of_birth, as_of)
return age_years >= threshold_years
result = age_over_threshold(
date_of_birth="2007-04-02", # never leaves the sandbox
threshold_years=18,
as_of="2026-06-19",
)
# result = True
Why one bit, and not ten
The whitepaper calls this property bit-scarce: an
output intentionally constrained to reveal only a small amount of
information relative to the underlying dataset, capped in practice at
three to four bits. A boolean answers the retailer's actual commercial
question with the minimum information needed to settle it. Richer
responses leak more than they need to:
| Response design | Bits leaked (approx.) | Reconstructable from repeated queries? |
|---|
| Exact age in years | ~7 bits | Yes — narrows date of birth to a 1-year window |
| Age bracket (5-year bins) | ~3–4 bits | Partially — narrows to a 5-year window |
| Boolean (over / under threshold) | 1 bit | Only the single threshold tested; a new, logged query is needed for each one |
Even the boolean isn't perfectly safe against a requestor who runs many
threshold queries (18, 19, 20…) to binary-search someone's exact birth
year. That residual risk is closed by rate limits and the audit trail,
not by bit-scarcity alone — the two mechanisms are complementary, not
substitutes. Formalising this cumulative-leakage bound across repeated
queries is ongoing work for the forthcoming Technical Architecture Paper, not
something the whitepaper itself tries to settle.
What the retailer never receives
- Alice's date of birth, or her exact age
- Any document or image
- Any data reusable for a different purpose, e.g. marketing by age cohort
Real-world precedents — and their limits
Pieces of this pattern already exist, narrowly, in single-purpose products:
- Sign in with Apple & Hide My Email — a per-service forwarding address stands in for your real email.
- iCloud Private Relay — splits your browsing traffic so no single party sees both who you are and what you're visiting.
- Tokenised age verification (Yoti, Telefónica Open Gateway) — returns an age-check result, not the underlying date of birth.
Each is a voluntary, single-vendor feature covering one attribute.
None give you one custodial account across every category of personal
data, a statutory revenue share, or a regulatory mandate to operate
this way — which is precisely the gap Databanking proposes to close.
← Back to the concept overview
