FEP-5fcf: Anchor (privacy-preserving one-person proofs for federated services)

Status: DRAFT · v0.6 · 2026-08-20 · author: Robin Genis · intended venue: codeberg.org/fediverse/fep (slug 5fcf)

Engelstalige specificatie

Specificaties en standaard-drafts schrijven we in het Engels, de voertaal van protocollen en review. Dit is een levend werkdocument: commentaar is welkom.

BLOCKING DEPENDENCY. This specification requires a seed attribute conforming to the profile in §2.1: issuer-derived, deterministic per person, one value per person for the federation acting as one relying party, at least 128 bits of entropy. It is uncertain whether the EUDI-wallet pseudonym attribute exists in this form or will become available per member state; the current ARF line is per-relying-party and wallet-generated, which does not conform. Enrolment in a context MUST NOT start before a conforming attribute has been verified for every involved member state (open question F). Until that verification, a country's document anchors enrol at social or institutional assurance level only.

In plain words

Some things should be one-per-human: a basic-income floor, a vote in a poll, a "one account per person" community. On today's internet that is hard to guarantee without building the very thing nobody wants: a central register linking real names to accounts.

Anchor solves it with two everyday ideas. A state-issued identity attribute proves you are one unique person, but a cryptographic trick (a zero-knowledge proof) lets you show that without showing who. And a body that knows you is alive confirms it periodically: your neighbours if that is safe for you, or a professional bound by confidentiality (a doctor, a shelter, the municipality) if it is not. A blinded stamp (a nullifier) derived from your identity is recorded in the service's own list, so a second attempt by the same person bounces.

That list is never published. Outsiders see only a fingerprint of the list and some banded counts; never a stamp, never your status, never the moment your status changed. Your stamp is also different at every community, so there is no public number that follows you around the federation.

One honest exception, because denying it would be a lie: communities that check "this person is not already enrolled somewhere else" each keep one encrypted value derived from your identity, and that value matches across all of them. It is never published, and it leaves a community only inside a protocol whose only answer is yes or no, only for someone who actually walked in that same period, and never toward a community you left while you are under protection. It is destroyed when you leave, and also as soon as a safety flag stands at that community. And one step back from what the previous version of this document promised, because the promise could not be kept: refreshing that value periodically is something nobody can build today, so for as long as you are a member it stays the same value. It is the last federation-wide link in this design, and it is named here instead of denied.

Enrolling through a document or wallet anchor always requires a live session with the chip or the wallet, plus something only you hold (a PIN or your fingerprint on the wallet). A copy of your passport data (a hotel scan, a landlord's photocopy) is never enough, and neither is your document alone in someone else's hands. If you lose your phone, your keys, everything: a new live session brings the very same stamp back.

And if you want none of it: there is a counter route. A person, not a protocol, establishes that you are one human being, with no token recorded anywhere and nobody from your community vouching for you. Refusing the identity layer is a choice about your own data, and this specification does not let that choice cost you your floor. Your record does not show which route you took, and you can switch to it at any time.

If someone in your home is the danger. This is the part to find when you need it, and also the part to check before you join. What follows is what this specification requires a community to build. It does not by itself mean your community has built it. Ask, before you enrol: does this community run the safety route, and which bodies does it recognise? The list of accredited bodies is kept at federation level, not by your own community, so your community cannot quietly drop the shelter that is supposed to protect you from it. A community that cannot show the route actually running should not be recruiting people who need it, and this document says so as a requirement, not as advice.

What the route must do where it runs. You say it yourself, or a shelter, doctor, municipality or police safeguarding desk says it for you: disclosing my location, or the fact that I moved, would put me in danger. From that moment on, three things follow. Your money moves immediately: no announcement, no waiting period, nobody gets a veto, and no one has to vouch for you first. Your keys move immediately too: if the person who has your old phone and PIN still counts as the current key holder, you can rebind to a new device on one attestation from an accredited body plus a live session, or on two such attestations if your document is gone; the old keys stop working at that same moment, and that person gets no notice, no date and no objection period. Without that second part the first one is hollow, because the man holding your phone could stall your recovery for days and would learn the exact day you replaced it. One thing this document will not pretend: he gets no message, but he will see it, because his app stops working at the moment you rebind. That is the whole point of the step and it cannot be hidden. So the moment is chosen together with the body helping you, as part of a plan, and not alone at the kitchen table. The outside world keeps seeing the old picture: for as long as the safety flag stands, the public view and every authorised lookup keep showing your old destination and old status. The system deliberately shows the onlooker something untrue, because otherwise the announcement itself would be the alarm that you left. Every attempt to look up your entry is recorded and reported to you, never to the person looking. And you can say "this document is no longer mine" in one action, without giving a reason and without losing your floor; if that document is presented later, you are told and the presenter is not. Only you, or the body acting for you, can lift the flag.

What the route does not do, said plainly. It covers your status and your enrolment, and it does not cover the published energy and money figures: those have to add up to the last unit, so they cannot show a decoy, and in a community small enough for people to know each other a household that stops drawing can still be noticed. And the decoy is never used against a lawful order from an authority: it protects you from the people around you, not from a court.

Four honest limits, stated up front. First, the special identity attribute this design needs (issued by the state, the same value for you for life, unpredictable to everyone else) may not exist yet anywhere: until a country demonstrably offers it, enrolment there cannot start. Second, the privacy of the design is strong but conditional, not magic: it holds as long as fewer than a threshold of the independent key-holders collude, and as long as the identity attribute has enough randomness that nobody can simply try all possible values. Third, your own community organisation knows who you are: it has your membership record, so it does not need any cryptographic key to unmask you, and this specification therefore forbids it to build a second unmasking path (an escrow) that it does not need. Fourth, in a community of a few hundred people, local knowledge (who moved, who died, who suddenly draws nothing) can place people without any attack on the cryptography; anyone with a reason not to be found must be told that before they sign.

Summary

This FEP defines a vocabulary and a set of activities for federated proof-of-unique-personhood: enrolment through a live document or wallet session with holder binding produces a deterministic nullifier, scoped to a single instance and recorded in that instance's nullifier set, which is never published. The public view is a per-interval signed tree head, a banded assurance distribution and suppressed-below-k aggregate counts, co-signed by independent witnesses. Uniqueness is enforced by an element-hiding non-membership proof at enrolment against a current-state authenticated dictionary whose root is committed, per interval, inside that same witness-co-signed log, and, across instances, by private set intersection that returns a single bit to the querying instance only and that admits only values freshly derived from a live session in that interval. Beside the anchor routes there is a manual admission route: a human assessor establishes uniqueness with no token and no community attestations, so that refusing the identity layer costs nobody their floor. Ongoing validity is maintained by liveness attestations, from the community where that is safe and from an institutional attester where it is not; attester-hiding is a hard condition for both routes, and institutional attesters are accredited at federation level, never by the instance they check. A safety route lets an endangered person move both their payout destination and their key binding immediately, while the public view keeps showing the previous state. Pseudonymity is the default; an instance that already knows its members MUST NOT build an escrow, and lawful unmasking through threshold escrow exists only in the federation phase, under a split transparency log.

Anchor was designed for CBER (an energy-backed community-credit grammar needing "one person, one basic floor" across instances), but is generic: one-person-one-vote polls, sybil-resistant rate limiting, one-account communities.

Requirements

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY", "OPTIONAL" are to be interpreted as described in [RFC2119].

1. Terms

• Anchor: a source of unique-personhood evidence. Document anchors (ICAO passport chip with active authentication, national/EU eID, EUDI wallet) reach document assurance only when they carry holder binding (§2.1); institutional anchors (an attester bound by professional confidentiality) and social anchors (web-of-trust vouching) are weaker but inclusive, and are the routes that stay open to people who cannot safely use the others.
• Seed: a per-person secret derived, inside a zero-knowledge proof, from a conforming seed attribute (attribute profile, §2.1): issuer-derived, deterministic per person, high-entropy. The seed MUST NOT be derived from a national personal number, and wallet-instance-generated pseudonyms do not conform. The seed never leaves the proof and is regenerable: a new live session re-derives it.
• Live session: a challenge-response with the document chip (Chip Authentication or Active Authentication per ICAO Doc 9303 / BSI TR-03110) or an equivalent eID/wallet attestation, cryptographically bound to the enrolment or evaluation nonce, and accompanied by holder binding. It proves presence of the genuine document or wallet, not a copy of its data.
• Holder binding: an authentication factor held by the person themselves (wallet PIN, biometric holder authentication). Required at document assurance level (§2.1).
• Context: the scope within which enrolment uniqueness is enforced: one instance. A person enrolled at two instances holds two unlinkable nullifiers. Anchor defines exactly one other context, the federation cross-check context, used solely to derive the cross-check nullifier below; no other federation-wide context is permitted, and no context value is ever published.
• Nullifier: ThresholdOPRF(seed, context): a deterministic token, never published (§2.3). Same person + same instance → same nullifier; different persons → different; different instances → unlinkable. Its unlinkability is computational and conditional (§2.2).
• Cross-check nullifier: ThresholdOPRF(seed, federation cross-check context), carrying a federation-epoch component only where an updatable construction under §2.6 actually runs, derived only by instances that run the cross-instance uniqueness check of §2.3. It is a federation-wide correlator: it matches across every participating instance. It is never published, is stored encrypted, leaves an instance only inside a PSI run and only as an element freshly derived in that interval (§2.3), and is destroyed on exit. Whether it rotates at all depends on a construction that does not exist yet: see §2.6, where the unexecutable rotation MUST of v0.5 is withdrawn and replaced. It is the one federation-wide link this design still contains, and §4 T12 states what its compromise costs.
• Nullifier set: the instance's own, non-public collection of enrolled nullifiers and their current status. It is a collection of pseudonymised personal data without direct identifiers, and is treated as such (§5).
• Transparency log: the append-only, witness-co-signed log of per-interval commitments over batched salted deltas, and of the state-dictionary root for that interval (§2.3). It carries no readable entry.
• State dictionary: the current-state authenticated dictionary holding, per entry, uniqueness and status, against which element-hiding non-membership proofs are produced (§2.3). Distinct object from the transparency log, deliberately, but not a separate trust domain: its root is committed per interval inside the witness-co-signed log, and a proof against a root that does not appear there is invalid.
• Public view: the only thing published about the set: the per-interval signed tree head, a banded assurance distribution and suppressed-below-k aggregate counts (§2.3).
• Witness: an independent external party (not a monetary counterparty) that co-signs the per-interval roots (§2.3).
• Institutional attester: a body bound by professional confidentiality (health, shelter, social work, housing corporation, municipality, police safeguarding desk), accredited at federation level and never by the instance it attests to (§2.5), whose single attestation fully substitutes for the k community attestations. The instance records that a valid institutional attestation exists and until when; it MUST NOT record which body issued it.
• Attestation: a signed statement that the person is alive and present, by an already-enrolled actor or by an institutional attester. Both routes are attester-hidden (§2.5).
• Safety flag: a marker, set by the person or by an accredited safeguarding body from the federation-level list and revocable only by them, that switches the entry to the safety route of §2.4.
• Escrow record: an encrypted off-set record linking a nullifier to an account under an m-of-n threshold scheme. Forbidden where the instance already knows its members; available only in the federation phase (§5).
• Assurance level: the declared strength of the anchor behind an enrolment.

2. Model

2.1 Layer 0: Regenerable seed (nothing to remember)

Seed source. The seed MUST be derived, inside a zero-knowledge proof that verifies the issuer's signature, from a pseudonym attribute conforming to the profile below. Derivation from the BSN or any national personal number is forbidden, for two independent reasons:

1. Entropy. National personal numbers live in an enumerable space (roughly 10^9 to 10^10 values; the population register is literally the dictionary). A seed derived from one turns the OPRF key into a retroactive de-anonymisation key (§4, T1).
2. Law. In several jurisdictions (in the Netherlands: Wabb, art. 46 UAVG) any processing of the national number, including a zero-knowledge derivation that takes it as input, requires a formal statutory basis that private federations do not have.

Attribute profile. A conforming seed attribute MUST be: (a) issuer-derived and deterministic per person, yielding the identical value after loss or reinstallation of any wallet or device; (b) scoped such that the entire federation context acts as one relying party, so that one person cannot obtain two different attribute values by applying at two instances; (c) of at least 128 bits of entropy; (d) issuer-signed and verifiable inside the zero-knowledge proof, which MUST verify that the attribute conforms to this profile. Wallet-instance-generated pseudonyms (per-relying-party random, WebAuthn-style) do NOT conform: they are neither regenerable nor unique per person; a wallet reinstall would yield a new seed, reviving the amnesia fork and opening a sybil route (a second floor per reinstall). Note the deliberate asymmetry with §2.3, and note its price: the attribute is one value per person for the whole federation, the nullifier derived from it is scoped per instance, so no federation-wide token exists in any set or in any public view. A federation-wide value does exist where instances run the cross-instance check: the cross-check nullifier of §2.3, encrypted at rest and computable directly from the attribute by anyone who compromises the cross-check context (§4, T12).

BLOCKING DEPENDENCY. It is uncertain whether the EUDI pseudonym attribute exists in the profile's form or will become available per member state; the only clean instantiation known today is an issuer-derived deterministic pseudonym (the state computing a PRF over its own register under its own key, which the state, unlike private parties, may lawfully do). Enrolment in a context MUST NOT start before a conforming attribute has been verified for every involved member state (open question F).

Honest residual dependency. This makes the scheme depend on the issuing state twice: for uniqueness (exactly one conforming attribute per person) and for entropy (the attribute must be unpredictable). A corrupt or sloppy issuer degrades both. That dependency cannot be engineered away at this layer; it is handled by assurance downgrade and context suspension (§2.6), and an eID/MRTD specialist MUST verify, per country, which suitable attribute is actually available in signed form before a context accepts that country's anchors.

Live session and holder binding. Enrolment, recovery and evaluation through a document anchor MUST include a live session: the zero-knowledge proof MUST cover a Chip Authentication or Active Authentication challenge-response (or an equivalent eID/wallet attestation) bound to the enrolment or evaluation nonce. Passive document data (DG files plus SOD) is a static, copyable file that hotels, airlines and landlords read every day; it never suffices. Beyond that, holder binding is REQUIRED at document assurance level: the live session MUST be accompanied by an authentication factor held by the person (wallet PIN or biometric holder authentication). A document anchor that cannot carry holder binding never reaches document assurance level, whatever the chip supports. The reason is not theoretical: seizing someone's documents is a standard control tactic in coercive households (§4, T10), and a chip in someone else's drawer answers a live challenge perfectly.

Document revocation by the holder. A person MAY unilaterally and immediately revoke the document-anchor route for their own enrolment ("this document is no longer in my possession"), without losing their benefit and without stating a reason. The enrolment then continues at institutional-attester assurance under the safety route of §2.4. Revocation MUST NOT be disclosed to any party that presents that document; a presentation of a revoked document MUST be logged and disclosed to the person, and MUST NOT be disclosed to the presenter. Without this action there is no way for anyone to say: my papers are no longer mine.

The revocation MUST NOT be legible as an event. A document revocation, and a switch from community attestations to the institutional route, are state changes that would otherwise announce to the instance that a person is in trouble, which in a small cooperative is an announcement to their social circle. Neither MUST be recoverable as a separate datum in the member record: the record carries the current assurance level and the validity of the current attestation, not a history of route changes, not the identity of an attesting body and not a revocation event. The published assurance distribution is banded (§2.3), so a single person moving from document to institutional assurance does not move a published figure by one.

Consequences, both REQUIRED properties of any conforming derivation:

• No amnesia forks. A person who loses every device and credential re-derives the same seed and the same nullifier at the same instance through a new live session; re-enrolment finds the existing entry instead of creating a second person.
• No stored master secret. There is nothing for the user to back up and nothing for a server to leak.

2.2 Layer 1: Blind evaluation (conditional, and honestly so)

The nullifier MUST be computed via a threshold OPRF: the evaluation key is t-of-n shared among independent parties, the client input is blinded, and evaluations are rate-limited. No single party can compute or test anyone's nullifier alone.

The unlinkability guarantee is computational and conditional, not unconditional: it holds as long as (a) fewer than t shareholders collude, and (b) the seed-attribute space has enough entropy that enumeration is infeasible. A coalition holding t shares evaluates the OPRF among themselves; rate limits, evaluation binding and logging do not restrain them. If the seed were low-entropy, such a coalition could de-anonymise every nullifier it can obtain. Both conditions are therefore load-bearing MUSTs:

• the high-entropy seed source of §2.1 is mandatory;
• the OPRF key MUST NOT ever be reconstructed in one place: threshold evaluation only, including in backups and ceremonies;
• shares MUST be proactively refreshed (§2.6);
• the n shareholders MUST be organisationally independent, with at least one outside every state whose residents the context enrols;
• every evaluation request MUST carry the same zero-knowledge proof of correct derivation from a valid anchor, including a fresh live session with holder binding bound to an evaluation nonce, as enrolment requires (§2.1); shareholders MUST refuse evaluation of unproven inputs. Computing a nullifier is thereby possible only for the person presenting the genuine document or wallet, never for a holder of copied attribute data (§4, T7);
• the public transparency log records evaluation volume as per-interval aggregate counts, aligned with the set-mutation batching intervals of §2.3; per-request timestamps remain private to the shareholders and are deleted on the published retention term. Per-request public logging would de-batch the set mutations: an evaluation timestamp followed by a change in the next aggregate is exactly the timing side channel the batching exists to close.

This residual risk MUST be stated in every user-facing privacy notice of a conforming deployment.

2.3 Layer 2: The set is never published

The nullifier set MUST NOT be published, in any form, at any granularity. Publication is not needed for the purpose: uniqueness requires that a second enrolment collides, not that anyone can read the list. A published list of per-person tokens is a re-identification surface at community scale (§4, T11), it can never be un-published (append-only plus archiving plus scraping), and combined with a stable token it is a private personal number, which is precisely the artefact that per-relying-party pseudonyms in eIDAS 2.0 and national rules on personal numbers exist to prevent.

Two objects, not one. A conforming deployment MUST implement two distinct authenticated data structures and MUST name its construction for each; "an accumulator" is not a specification. The v0.4 text asked one object to be a chronological append-only log, an efficient non-membership prover and a mutable status store at the same time, and no single structure is all three.

1. Transparency log: append-only, Certificate Transparency style [RFC9162], carrying per-interval commitments over batched salted deltas, with consistency proofs between consecutive roots and witness co-signatures. It carries no readable entry and no status.
2. State dictionary: a current-state authenticated dictionary holding, per entry, the nullifier and its current status, supporting element-hiding non-membership proofs.

Two objects, one trust domain. Splitting the object MUST NOT split the guarantee. Each interval the transparency log MUST commit to the root of the state dictionary, and the witnesses MUST co-sign that commitment together with the log root. A non-membership proof or a status proof is valid only against a dictionary root that appears in the co-signed log, and client software MUST verify both chains: consistency of the log between consecutive roots, and presence, in that log, of the dictionary root the proof is offered against. A proof against any other root MUST be rejected, and an instance that cannot show the root MUST NOT enrol against it.

The reason is the threat this specification already names. Without this rule the object that decides uniqueness and status hangs outside the witnessed structure, so an operator can show applicant A a dictionary in which a nullifier is absent and applicant B a dictionary in which it is present, without ever breaking a consistency proof between two log roots. That is equivocation (§4, T4), and its consequence here is not only privacy: it mints a second floor for the same human while every public artefact still verifies. The split of v0.5 was right and this sentence is its missing half.

The non-membership proof MUST be element-hiding: a sparse Merkle tree over H(nullifier), an RSA-accumulator non-membership witness, or an equivalent construction whose proof reveals no set element. Predecessor-successor proofs are forbidden: the cheap standard construction (an indexed Merkle tree) proves absence by showing the two neighbouring real elements, which would hand every applicant two live entries and break the rule at the head of this section.

Public view. Per interval, the instance publishes exactly three things about the set:

1. the signed tree head of the transparency log, with witness co-signatures, carrying that interval's commitment to the state-dictionary root;
2. the assurance distribution, published rounded or banded (never exact counts per level), so that one person moving between assurance levels never moves a published figure by one;
3. aggregate counts, including counts of status transitions in that interval, suppressed below k.

Nothing else: no leaf, no nullifier, no per-entry status, no per-entry timestamp, no per-entry event. Mutations MUST be batched per interval (never per event) with randomised delay within the interval.

Suppression, including zero. Every count below k is suppressed, and zero counts as below k: a published zero would otherwise make the difference between "no transitions this interval" and "suppressed" a per-interval bit saying "someone moved, and there were fewer than k of them", which in a village during the week someone disappeared is not an anonymous datum. The suppression notice MUST have a fixed form per series, independent of the underlying figure, and MUST NOT change when the underlying figure changes. Note the asymmetry with the unmasking counter of §5, which is published including zero on purpose: that counter reports the instance's own conduct toward authorities, where silence must be falsifiable (the canary logic); these counts report person-derived events, where a published zero is a signal about people. Where the two rules meet, the rule protecting persons wins. Honest consequence at field-test scale: below roughly k participants the public view of the set carries no counting information at all, and verification rests entirely on the witnesses, the consistency proofs and each member's own inclusion proof. That is a real cost and it is stated rather than papered over.

Commitments and witnesses. Client software MUST verify consistency proofs between consecutive roots and the presence of the dictionary root it relies on inside the co-signed log, and each member MUST receive privately an inclusion proof for their own entry and its mutations. Each interval's log root, including the dictionary-root commitment it carries, MUST be submitted to and co-signed by at least three independent external witnesses: never monetary counterparties; where federation peers exist they MAY serve, and where they do not (a single-instance deployment), named third parties serve instead (a transparency-log operator, an archival institution, a newspaper). Two different histories then require conflicting signed roots, which is portable proof of fraud that any member can hold. This applies from day one of any deployment, not only once a federation exists.

Uniqueness enforcement. Two mechanisms, and no published list:

• Within a context: at enrolment the applicant obtains and verifies an element-hiding non-membership proof for their nullifier against the state dictionary, offered against a dictionary root that appears in the witness-co-signed log; a duplicate enrolment fails because the proof cannot be produced. The instance learns that this nullifier is new, and nobody learns the set.

• Across instances: uniqueness is checked by private set intersection. Requirements, all normative:

  • the protocol MUST deliver the output bit exclusively to the querying instance; the responding instance MUST learn neither the existence of a match nor which of its entries matched (circuit-PSI or private set membership with one-sided output);
  • queries MUST be batched on a fixed cadence with indistinguishable dummy queries, so that neither the timing nor the volume of enrolments elsewhere is observable to a peer;
  • the querying side is bound to fresh applicants. An instance MUST NOT include in a PSI batch any value it did not derive, in that interval, from a live session with an applicant actually present (§2.1). Each real element MUST carry a proof of fresh derivation for that interval; elements without one MUST be refused by the responding side. The number of real elements per batch MUST be recorded, and the auditor MUST reconcile that number against the instance's own enrolment record; a mismatch is a grammar break and carries the enforcement consequences of the companion grammar, not an internal note;
  • a person under a standing safety flag is never the subject of a query originating from the instance they left, on any route: not live, not deferred, not through a third party, not inside a dummy-padded batch, and not through a peer asking on that instance's behalf;
  • where a safety flag stands, the cross-instance check MUST NOT run as a live query to the instance of origin either: it is deferred, routed through a third party that is neither instance, or satisfied through the institutional route.

  The reason is not hypothetical, and v0.5 fixed only half of it. Without the first two rules the uniqueness check is itself a message, sent to the very community someone has just left, on the day they enrolled elsewhere (§4, T10). But rules about the direction of the output bit say nothing about the legitimacy of the asker: the instance she fled still holds her cross-check value from the time she was a member, and a batch of dummy-padded queries is, by this specification's own traffic-analysis mitigation, indistinguishable from a real one, while the responder is forbidden to learn that anything matched and therefore cannot report it. Village A can put her value in its fixed batch against B, C and D and read the bit; within one cadence it knows which village she is in. The old design leaked passively through a published list; a naive repair leaks actively through a targeted question; this is the rule that removes the question instead of turning it around.

  What this closure is worth, said out loud, because it is procedural rather than cryptographic: an instance whose board harbours the adversary keeps its copy of the value whatever this text says, and nothing here makes the query cryptographically impossible. What the rule buys is that the query becomes detectable and sanctionable: real elements must carry fresh-derivation proofs, their count is reconciled against the enrolment record by an auditor, and a mismatch is a break rather than a discrepancy. A construction that carries per-element freshness proofs inside a one-sided-output PSI is not a standard protocol off the shelf; it is part of the build order in open question G.

  Stated honestly: a cross-instance check needs a value comparable across instances, so a participating instance derives a cross-check nullifier under the federation cross-check context. That value is a federation-wide correlator. It MUST never be published, MUST be stored encrypted, MUST never leave the instance except inside a PSI run and only as an element derived in that interval from a present applicant, MUST be destroyed on exit, MUST be destroyed rather than kept where it cannot be updated (§2.6), and its existence and its lifetime MUST be stated in the privacy notice. An instance that does not need federation-wide uniqueness MUST NOT derive it at all. PSI keeps it from becoming a public correlator; it does not make it disappear, and §4 T12 states what its compromise costs.

Status. Status (active | dormant | revoked | disputed) lives in the set, never in the public view. A status opening is available solely to services holding context authorisation, returns the current status only, is logged, and is disclosed to the person concerned. Status history is never published, never transferred between instances, and never returned on a status opening. A person MAY request a fresh assurance determination at any instance, and the receiving instance MUST NOT condition it on the history of the entry.

Expiry of adverse statuses. A disputed status expires automatically after a published maximum term and reverts to active, unless a competent authority has ordered otherwise. A dormant status set without a completed human review (§2.5) expires likewise. An adverse status that nobody is willing to substantiate MUST NOT become permanent by inertia.

No pre-built linkage. An instance MUST NOT operate any facility that links pseudonyms to persons in advance and without concrete cause. Where the instance already knows its members by other means (a membership register), such a facility adds no protection and creates a second unmasking path; see §5.

Exit route. A person MAY leave. On request the instance MUST: set the entry to revoked in the state dictionary; publish, in the next interval, the updated dictionary root committed inside the transparency log, with the witnesses co-signing that log root (there are two roots, and only this pairing is meant: a dictionary root that never reaches the co-signed log revokes nothing anyone can verify); destroy that person's cross-check nullifier; destroy any escrow record for that person; and irreversibly aggregate that person's history so that only counts remain. Destroying the cross-check value is the operative step in a deployment without an escrow, since it is the only durable federation-wide artefact; an exit route that leaves it in place destroys nothing. Note what the exit route cannot carry: a person fleeing a household does not file a departure request with the community she is fleeing, so her value stays where it is. That is why the protection against the instance of origin sits in the query rules above and in the destruction duty of §2.6, and not here. Where a safety flag stands at that instance, the instance MUST destroy its copy of that person's cross-check value at the next batch boundary, on the same terms as an exit and without waiting for a request. The honest limit: the existence of a flag is never disclosed to a peer (§3), so this duty binds only the instance that holds the flag, and a value held by a peer that was never told is reached by the query rules above and by nothing else. The consequences MUST be communicated in writing and confirmed separately beforehand, and they are real: the log entry cannot be un-created (it is append-only), so leaving means revocation plus aggregation, not erasure, and a revoked entry ends the recovery route. Saying this plainly is part of the specification; see §5.

Enrolment. The actor presents a zero-knowledge proof of correct derivation from a valid anchor, covering the live session and holder binding of §2.1, plus the non-membership proof. If the person is already enrolled at this instance, the attempt does not silently rebind: it goes to the recovery and dispute procedure of §2.4.

2.4 Recovery, destination changes, disputes and the safety route

Recovery is, together with enrolment, the most powerful operation in the system: whoever controls recovery controls floors. It is specified here as a normative baseline; a deployment MUST NOT go to field trial with an ad-hoc recovery procedure.

A destination change is not a recovery. A change of the payout destination by the holder, under an unchanged and uncompromised key binding, is NOT a recovery: it takes effect immediately, opens no waiting period, gives no objection right to anyone, and is recorded only inside the per-interval aggregate. Only a change of the key binding itself carries the waiting period below. The previous specification tied these together, which meant that moving your money required announcing your move; that is exactly backwards for anyone whose danger lives in the same house.

Recovery baseline. Recovery of an enrolment (lost or compromised keys) REQUIRES all of:

1. a new live session with holder binding (§2.1) or equivalent eID re-authentication, or a single institutional attestation where the document is not in the person's possession;
2. k fresh liveness attestations (§2.5), or one institutional attestation, which fully substitutes;
3. notice to the incumbent key binding, opening a waiting period of N days in which it can object, recorded publicly only inside the per-interval aggregate.

If the waiting period passes without objection, the old keys are revoked and the enrolment binds to the new keys. The nullifier stays the same: recovery never mints a new person.

Dispute baseline. If a second claimant appears, or the incumbent objects during a waiting period, the entry moves to disputed: the attached benefit continues to the destination on record and no change of destination or binding takes effect while the dispute runs, so a hijacker gains no redirect. (The freeze holds the current destination; it does not restore any earlier one, and it does not invoke destination binding to a home, meter or provider, which the companion grammar has abolished.) The binding is awarded to the claimant who presents a new live session with holder binding plus k fresh liveness attestations or one institutional attestation. A disputed status expires per §2.3.

A freeze is a decision about a person, and carries the same safeguards. Freezing someone's subsistence on another party's filing has at least the consequences that §2.5 attaches to a dormant transition, so it MUST NOT be a solely automated decision (GDPR art. 22): prior notification to the person whose entry is frozen, human review with stated reasons by a reviewer outside the operational staff, suspensive effect (the benefit keeps flowing during objection and appeal), and the published maximum term of §2.3. A freeze that nobody is willing to substantiate in person MUST lapse.

Dispute authentication. An entry moves to disputed only when the second claimant presents, at filing time, a fresh valid derivation proof including a live session for that nullifier. An objection during a waiting period is valid only when signed by the keys of the incumbent binding. Unauthenticated claims and objections MUST be rejected without status effect and logged as attempts. This closes cheap griefing (freezing arbitrary entries) and denial of service on the recovery channel, aimed at people who have just lost their devices.

Safety route (protected persons). A conforming deployment MUST offer this route, and MUST NOT enrol people who would depend on it before it demonstrably runs (§5). Where a person declares, or a safeguarding body from the federation-level accreditation list (§2.5) declares on their behalf, that disclosure of their location or of a change to their enrolment would endanger them:

• the destination of their benefit MUST be redirectable immediately: without a public announcement, without a waiting period, without an objection right for the incumbent binding, and without fresh community attestations;

• a single attestation by an accredited institutional attester (shelter, general practitioner, municipality, police safeguarding desk) substitutes for the full set of k attestations, and for the live session where the document is not in the person's possession;

• the change is recorded only inside the per-interval aggregate; no per-entry event is published;

• while the safety flag stands, the public view and every authorised status opening MUST continue to show the previous destination and the previous status, unchanged;

• every attempted opening of that entry MUST be recorded and disclosed to the person, and MUST NOT be disclosed to the party attempting it;

• a dispute filed against a safety-flagged entry never freezes delivery to the previous destination; delivery continues to the new one;

• the key binding MUST be movable on the same terms as the destination: under a standing safety flag, rebinding to new keys takes effect immediately, with no notice to the incumbent binding and no objection period, against one institutional attestation plus a live session, or, where the document is not in the person's possession, against two institutional attestations. The old keys are revoked at that same moment, and the person is not asked why. Without this bullet the safety route protects the money and abandons the control: an adversary holding the phone and the PIN is the incumbent binding, so the person needs a rebinding rather than a destination change, and the standard baseline would hand that adversary a protocol-valid notice with a date on it plus N days of veto, signed with the very keys he took. That is the same alarm the safety route exists to remove, relocated from a public log to his inbox.

  What this bullet does not do, and no deployment may imply otherwise: the revocation of the old keys is visible to whoever holds that device. No notice is sent, no date is disclosed and no objection is possible, but the old keys stop working at the moment of rebinding, and that is the point of the step rather than a defect in it. Silence is not invisibility. Deployments MUST NOT describe the rebinding as unnoticeable, in the user-facing material or in the privacy notice, and MUST say instead that the moment of rebinding is chosen together with the accredited body as part of a safety plan, since the timing is the only variable the person controls. The failure this prevents is concrete: a person reads that rebinding is immediate and unnoticed, rebinds while still living in the house, and the app on the phone the adversary holds stops working while he is in the next room. That is a flight alarm raised by the protection itself;

• the safety flag is revocable only by the person or the accredited safeguarding body, never by the instance.

Say plainly what this is: here, and only here, the system deliberately shows the observer something that is not true. Every other mechanism in this specification publishes; this one shows a decoy. The argument is not that lying is elegant, it is that the alternative is worse. A public waiting period on a destination change is, for a person fleeing a household, an alarm that announces both the fact and the week of their departure to the one adversary who is already inside their security perimeter; an honest status opening tells a well-connected ex-partner, employer or landlord where the money now goes. A protection that publishes the moment it is used is not a protection. Implementers MUST NOT weaken this into a delay, a notification or a redaction: the previous state stays visible, and the operators of the instance MUST be unable to tell the difference from the outside.

The limits of the decoy, stated as normative scope. Three limits, and none of them may be quietly widened:

• Never against authority. The decoy MUST NOT be presented to a competent authority acting on a legally valid order, and MUST NOT be used to obstruct any lawful request. It exists against the people around a person, not against a court. An instance receiving such an order answers from the true state.

• Status and enrolment layer only. The decoy covers the public view of the set, the status opening and the enrolment record. It does not cover published measurement, delivery or settlement series, and a conforming deployment MUST say so where it describes the route. The reason is structural rather than a matter of will: those series must reconcile against measured sums, so a decoy there would manufacture an unexplained difference and trip the very invariants that make the books auditable. A community small enough for people to know each other can therefore still notice, from aggregate movements, that a household stopped drawing. Deployments MUST NOT promise more than this, and where a published series would be thin enough for a single flagged person to be legible in it, that series MUST be widened, quantised or withheld rather than published.

  Quantisation here is a condition, not a wish, and it is stated so that nobody can satisfy the letter of the previous sentence while leaking through arithmetic. A common quantum across series of different dimensions is meaningless (energy, money and a ratio do not share a unit), and a quantum chosen per series protects nothing in a value derived from several of them, because a derived quantity inherits the precision of its inputs. The executable rule: the published precision of every series MUST be chosen such that the propagated uncertainty in each value derivable from the published series exceeds the largest single contribution to that value. Where the derived value is a claim or a queue, the largest single contribution is the largest single claim. The companion grammar carries this condition for its own published series; a deployment that publishes both sets applies one rule to both, and MUST NOT present a threshold on a derivable quantity as the protective measure (§4, T11). Honest caveat, since the reviewing cryptographer supplied it against his own earlier text: deterministic rounding is not a defence against repeated releases, because the rounding error averages out over publications and a level shift reappears; where quantisation carries the load, it MUST be sticky (a published figure moves only when it crosses a band edge with margin) or replaced by a noise budget accounted across releases.

• The cost of the decoy lands on the instance. Where the decoy causes an operational error (a payment reconciled against a stale destination, a status shown that has since changed), the loss and the correction are the instance's, never the protected person's. A person MUST NOT be charged, downgraded, suspended or held liable for a discrepancy created by a protection the specification obliged the instance to run.

2.5 Layer 3: Liveness (without handing the floor to the neighbours)

Document anchors prove uniqueness but not life. Services gating recurring per-person benefits SHOULD require periodic attestations, at low frequency and low friction. The attestation layer only tells the service that a person is alive and present; it MUST NOT become a vote on whether they deserve the benefit.

Confidentiality is a hard condition, for both routes. Attester-hiding is a MUST: attestations MUST be submitted such that the service learns only that the required attestations exist, not who gave them (for example a ring or threshold signature over the enrolled set). There is no encrypted fallback: storing attester identities under a threshold scheme would assemble the community's full social graph under the same quorum that performs unmasking, which is the central honeypot this design exists to avoid. Where attester-hiding is not implemented, attester identities MUST NOT be stored at all: the count is retained, the identities are destroyed immediately after verification. A deployment that does not run attester-hiding MUST NOT gate a subsistence benefit on community attestations; it may use them only for non-essential purposes, and must use the institutional route below for anything a person needs to live on.

The honest lower bound on hiding, on the institutional route. Attester-hiding is prescribed above as a property; on the institutional route the property is bounded by the size of the anonymity set, and that set is a regional accreditation list of perhaps three to six bodies whose meanings differ (a shelter, a general practitioner, a municipality, a police safeguarding desk). A ring of four semantically distinct members hides little, and combined with the region it is often identifying. Two consequences, both normative. The federation MUST publish a minimum list size per region for the institutional route. While the regional list is smaller than that minimum, the route does not hide the attesting body, and a deployment MUST NOT claim that it does: the limitation belongs in the privacy notice (§5), in plain language, before a person chooses that route, instead of being promised as a property the construction cannot deliver at that size. Where the list is below the minimum, the instance MUST still record no issuer (the duty below is unchanged), and the residual is that the set of possible issuers is small enough to guess. The construction itself is not chosen yet: an anonymous credential or a threshold signature over the federation list, with revocation that does not reveal the issuer, is named in open question G as part of the build order, and prescribing the property without naming a construction is the same incompleteness this section penalises elsewhere ("an accumulator is not a specification", §2.3).

Hiding applies to institutional attesters too. The instance MUST NOT record which body issued an institutional attestation: it records that a valid institutional attestation exists and until when, verified against the federation-level accreditation list, and nothing more. The category of the attesting body (a shelter, a general practitioner, a police safeguarding desk) is by its nature a special category of personal data under GDPR art. 9, and it is also the reason a person switched routes; recording it would tell the instance, which in a small cooperative means telling someone's social circle, both that they are in trouble and what kind. For the same reason the switch from community to institutional attestation MUST NOT be legible as an event in the member record (§2.1), and the published assurance distribution is banded (§2.3).

Institutional route. Institutional attesters are bodies bound by professional confidentiality (health, shelter, social work, housing corporation, municipality, police safeguarding desk). Accreditation happens at federation level, never by the instance being checked: the federation maintains a published list of accredited attesters and safeguarding bodies, per region, amended only through the slow public parameter procedure. An instance MUST accept every body on that list and MUST NOT accredit, prefer, exclude or de-accredit bodies of its own. De-accreditation never operates retroactively on standing safety flags or valid attestations: those stand until the person themselves, or a successor accredited body, withdraws them.

The reason is the shape of the threat rather than tidiness of governance. Where the instance accredits, the party being guarded against appoints its own guard: de-accrediting a shelter would silently expire every safety flag resting on that shelter's attestations at the next validity date, which is formal protection with the lock on the inside of the door. In a cooperative of 50 to 200 households, where the adversary can sit on the board, that route is not theoretical.

A single attestation by an accredited institutional attester fully substitutes for the k community attestations, at unchanged assurance level for benefit purposes. Offering this route is an obligation of the instance, not a favour, and it MUST be offered before any adverse status is proposed. No person's benefit may depend solely on attestations from actors they cannot safely approach.

Conflicted attesters. At most one of the k community attesters may have a landlord, employer, creditor or care relationship to the person. An attestation set that fails this test is not valid. Attesting is a power over someone else's subsistence, and concentrating it in the hands of the parties who already hold power over them turns a liveness check into leverage.

Attestations never gate first enrolment. Uniqueness comes from the anchor, life from the attestation; a person MUST be able to enrol without anyone vouching for them.

Absence of attestations. Effects of the attestation layer:

• absence of attestations is never, on its own, a ground for dormant, and never on its own evidence of death or emigration where an institutional route was available and not offered. Where attestations do not arrive, the person can maintain the entry with any alternative proof of life, including a live session at a staffed counter;
• a dormant proposal MUST be reviewed by a human who is outside the attestation community of the person concerned and outside the operational staff of the instance; the review MUST establish whether the absence has a social cause (a person who fled, was ostracised, is detained, hospitalised or in hiding); the review MUST NOT disclose the person's location to the instance; and it MUST NOT be triggered at all while a safety flag stands;
• extinguishing a per-person benefit is never a solely automated decision (GDPR art. 22): prior notification, human review with stated reasons, suspensive effect during objection and appeal, appeal to a body outside the community, continued payment throughout, and a grace period of at least 90 days;
• a dormant status set without a completed human review expires per §2.3.

Actors without documents MAY enrol through institutional or social attestation, at a lower assurance level. Payment, stake, deposit or proof-of-work as an enrolment gate is forbidden: inclusivity is a design property, not a nice-to-have. Note, against an earlier claim of this specification: a coerced enrolment slot is not made worthless by requiring communal life, because a co-resident coercer does not have to fake anything; he lives there. The defences against coercion are the safety route, holder binding, the institutional route and the reviewer outside the community, not the attestation requirement itself.

Manual admission: refusing the identity layer costs nobody their floor. A conforming deployment that gates a subsistence benefit MUST offer a manual admission route, in which a human assessor establishes uniqueness without deriving or recording any token and without community attestations. Refusing the anchor, the nullifier, the attestation economy or this specification as a whole is a decision a person may make about their own data, and a route that exists only for people who accept the technology is not a route. The companion grammar carries the same obligation on the monetary side; this section states it here so that the FEP knows the refusal route its own layer must not obstruct. Terms, all normative:

• the route MUST NOT be legible as a route marker in the member record, in the vocabulary or in the wire format, for exactly the reason a switch to the institutional route MUST NOT be legible (§2.1): in a small cooperative, knowing which route someone took is knowing something about them;
• only the number of manual admissions is published, as an aggregate under the suppression rules of §2.3; the full count is available to the auditor, and nothing about who was admitted this way or why is published or circulated internally beyond the assessor and that audit right;
• the assessor falls under the same conflict rule as attesters (a landlord, employer, creditor or care relationship disqualifies) and under the same exclusion as anyone consulting a member record. The assessor creates the record rather than consulting one, so an access rule written for consultation does not reach them, and in a village the wrong person behind the counter is the first contact of someone who is fleeing;
• what the assessor MAY request MUST be bounded and published in advance, the minimum substantiation retained MUST carry a published retention term, and nothing beyond that may be kept;
• a refusal is a decision about a person, and until v0.6 the route had no way to say no: it MUST carry written reasons, a review by someone other than the assessor and outside the operational staff, and an appeal to a body outside the community, with a published maximum term for the decision. Where the person is already receiving the benefit, payment continues throughout, as under the art. 22 safeguards this section attaches to a dormant transition;
• the residual sybil risk of the route is carried explicitly by the instance and never by the applicant, and it is a cost of admission rather than a ground to refuse one. Stated honestly, and this is new in v0.6: "the instance carries it" is an allocation of blame and not a mechanism, because a fraudulent floor draws real energy that is divided over real people. The route therefore MUST carry a published cap or ratchet per interval, and the deployment MUST state where the shortfall is absorbed. See §4, T13.

2.6 Layer 4: Governance of contexts and keys

• Enrolment contexts are per instance (§1). Coupling contracts declare which anchors and assurance levels members recognise (mirroring eIDAS mutual recognition) and whether the parties run the cross-instance check of §2.3. Below the agreed minimum, services MAY still federate content and value but MUST NOT run a shared uniqueness check.

• Federation-level lists are federation parameters. The accreditation list of institutional attesters and safeguarding bodies (§2.5), the published minimum size of that list per region (§2.5), the k thresholds and suppression rules (§2.3), the cross-check epoch length where an updatable construction runs, and the maximum terms of §2.3 are amended only through the slow, public parameter procedure, never by a single instance. An instance that could edit these could disarm the protections that exist against itself.

• Rotation of the cross-check nullifier: the v0.5 requirement is withdrawn, and what replaces it. v0.5 required that "at rotation every participating instance derives the new value". No instance can do that. The value is ThresholdOPRF(seed, cross-check context, epoch), the seed never leaves the zero-knowledge proof (§1), and every evaluation requires a fresh live session with holder binding that shareholders MUST refuse to skip (§2.2). What that sentence actually prescribed was a federation-wide live-session ceremony for every participant at every epoch, which contradicts the bullet below it ("nullifiers stay stable, nobody re-enrols") and appears in no staffing model and no budget. The named suite family is also the wrong one: RFC 9497 (OPRF, VOPRF, POPRF) provides no key rotation with an update token. A requirement nobody can meet is worse than an honest gap, so it goes.

  What stands in its place, in three parts. First, the construction. Where a federation states that the cross-check value rotates, it MUST run an updatable threshold OPRF with an update token (Pythia-style: the key holders issue a token with which each instance updates its stored values without the person being present), it MUST name that construction and its parameters before the first cross-check run, and the choice is part of the build order in open questions A and G. Second, the price of that construction, stated before anyone chooses it. Updatable values are stored as group elements rather than hashes, which makes a stolen store marginally more useful to the thief; and a leaked update token is itself a federation-wide linkability secret: anyone holding it plus a copy of the pre-rotation values can map old to new, so the rotation is undone retroactively for every instance whose old store was ever copied. The token MUST therefore be issued under the same threshold as the OPRF key, MUST NOT be reconstructed in one place, and MUST NOT be retained after the update window closes. Third, where no such construction runs, no rotation is claimed. The instance MUST NOT state or imply, in the privacy notice or anywhere else, that the value is refreshed, and MUST state the residual instead: the cross-check value stands for the whole of that person's membership and ends only on exit, on a safety flag, or on destruction under the next bullet. That is a real weakening against v0.5 on paper, and no weakening at all in practice, because the v0.5 promise was unimplementable.

  The fallback sentence of v0.5 is reversed. It read: persons who cannot participate in a rotation (no live session available) are carried through the institutional route. Under a token-based update nobody needs to participate, so the sentence is moot there. Under any other arrangement it produced exactly the wrong result: the people with no document and the people in flight would be the only group whose correlator never changes, which hands the mitigation to everyone except the population it exists for. The rule is therefore: a cross-check value that cannot be updated MUST be destroyed rather than kept. Cross-instance uniqueness for that person is then satisfied through the institutional route, which §2.3 already permits under a safety flag, and destruction is something an instance can execute alone, since it holds the ciphertext. Nobody is dropped and nobody is carried with a frozen correlator.

• Epochs are proactive resharing, nothing else. At each epoch boundary the share distribution of the same OPRF key is refreshed (proactive secret sharing): nullifiers stay stable, nobody re-enrols, and no cross-epoch mapping ever exists. Stated honestly: resharing protects the key against gradual share compromise; it does not bound the damage of a full key compromise in time, and it is not a linkability boundary.

• Context retirement (key compromise). Because resharing does not bound a full compromise, every context MUST publish, before its first enrolment, a context-retirement procedure covering: how a compromise is established and by whom; the moment the context stops accepting evaluations; the migration to a successor context (which requires a fresh live session per person, since nullifiers are not portable across contexts); how existing benefits continue during migration, with an explicit rule that no benefit lapses because of a compromise the person did not cause; and how the retired accumulator is frozen and its aggregates archived. Stated honestly: retirement makes the old context inert going forward, it does not undo exposure that already happened, and a person who cannot complete a fresh live session (lost or seized document) MUST be migrated through the institutional route rather than dropped.

• A corrupt attribute issuer (duplicate or predictable pseudonym attributes) is handled by assurance downgrade and context suspension, not by protocol change.

2.7 Relation to portable identity

Anchor composes with, but does not require, portable (DID-bound) actors in the [FEP-ef61] style. The two binding layers are complementary: key-bound identity carries money, relationships and content (and dies with the key), while the person-bound seed of this protocol carries the floor (and survives key loss via §2.4).

Since enrolment contexts are per instance, a uniqueness enrolment is not portable: a person moving to another instance derives a new, unlinkable nullifier there through a fresh live session, and cross-instance duplication is prevented by the check in §2.3 rather than by carrying a token along. This is a deliberate cost. It buys the property that no public federation-wide identifier exists, and it gives a person moving away from a community a clean start in the ways that can be given: status history never travels, and no member-identifying data crosses an instance boundary in any form.

It does not buy the absence of a federation-wide correlator, and this specification will not claim that it does. Where instances run the cross-instance check, each of them holds the person's cross-check nullifier, encrypted, until the person exits, until a safety flag obliges destruction, or until an update token refreshes it where such a construction is actually running (§2.3, §2.6). Since v0.6 that last case is the exception rather than the assumption: the rotation promised in v0.5 could not be executed and has been withdrawn, so the working assumption for anyone weighing a move is that the value stands for the whole of their membership. The clean start is therefore real toward the public and toward the receiving instance's view of history, and partial toward the federation's ability to tell that the same human is involved. Anyone deciding whether to move on the strength of this property is entitled to that distinction, so §5 requires it in the privacy notice.

Attestations, vouches and set commitments SHOULD carry Data Integrity proofs per [FEP-8b32], with keys advertised per [FEP-521a].

Scope note: this composition is in scope for monetary deployments (CBER). Social platforms MAY deliberately stay out of it: pinning social-network identities to durable cryptographic anchors is a choice, not a requirement, and some communities rightly refuse it.

3. Vocabulary

All terms live under the namespace https://ns.klonkt.com/anker# (RECOMMENDED prefix anker).

Term	Where	Meaning
anker:UniquenessProof	credential attached to an Actor	zero-knowledge proof object: anchor type, assurance level, context, live-session and holder-binding attestation, non-membership proof
anker:nullifierSet	non-public Collection held by the instance	the set for a context; never published (§2.3)
anker:SetCommitment	object published per interval	signed tree head of the transparency log including that interval's commitment to the state-dictionary root (§2.3), banded assurance distribution, suppressed-below-k aggregate counts, witness co-signatures. A commitment object without the dictionary root does not conform, and a proof offered against a root absent from it is invalid
anker:Attest	Activity	liveness attestation, submitted attester-hidden. One type for both routes. Whether an attestation came from enrolled peers or from an accredited institutional body MUST NOT be distinguishable in the vocabulary, in the wire format or in the member record; a separate InstitutionalAttest type existed in v0.4 and is removed, because its presence in a record discloses that the person could not safely use their community and, by category, why (§2.5, GDPR art. 9)
anker:attestationValidUntil	property	the only attestation datum an instance retains beside the fact of validity: no issuer, no route, no history
anker:assuranceLevel	property	declared anchor strength (integer scale fixed per federation); published only banded (§2.3)
anker:context	property	the instance this enrolment is scoped to
anker:status	property	active / dormant / revoked / disputed; never published per entry, openings return the current status only
anker:safetyFlag	property	protected-person marker (§2.4); its presence is never disclosed to any party other than the person and the safeguarding body

There is deliberately no term for the manual admission route of §2.5, and none may be added: a vocabulary that can express "admitted without a token" makes the refusal route legible in the record, which is the same disclosure that removed InstitutionalAttest in v0.5. A manually admitted person carries an assurance level and nothing else.

Consumers that do not understand these terms MUST ignore them and continue normal operation.

4. Security considerations and threat model

• T1: colluding OPRF shareholders. A coalition holding t shares can evaluate the OPRF at will; rate limits, evaluation binding and logging do not restrain them. If the seed space were enumerable, they could de-anonymise every nullifier they can obtain. Mitigations: high-entropy seed source (§2.1, MUST), no key reconstruction ever, proactive resharing, organisationally independent shareholders with at least one outside every involved state, per-interval aggregate evaluation counts (§2.2), and the fact that the set itself is no longer published, so a coalition must first obtain the nullifiers it wants to test. Residual, stated honestly: against t colluders plus a compromised attribute issuer, the scheme fails; that is the trust floor of the design.

• T2: chip-data clone. Passive document data is integrally copyable by anyone who ever scanned the document. Defeated by the live-session requirement (§2.1): a clone cannot answer a CA/AA challenge bound to a fresh nonce. This defeats copies, not relays or coercion; see T6 and T10.

• T3: enrolment front-running and floor hijack by an outsider. Blocked twice: a clone cannot complete a live session with holder binding, and the dispute procedure (§2.4) holds the destination on record and awards the binding to whoever passes a new live session plus attestations. Note the interaction with T10: the freeze is an anti-hijack measure that becomes a weapon when the hijacker is the co-resident, which is why it never applies to safety-flagged entries and why it now carries art. 22 safeguards of its own (§2.4).

• T4: split-view / equivocation. An operator showing different histories to different audiences. Defeated by signed tree heads, mandatory client-side consistency proofs, private per-member inclusion proofs, and per-interval co-signing by at least three independent witnesses (§2.3). This holds in a single-instance deployment with zero federation peers. Reopened by the v0.5 split and closed again in v0.6. Splitting the accumulator into a transparency log and a state dictionary left the object that decides uniqueness and status outside the witnessed structure: an operator could show applicant A a dictionary in which a nullifier is absent and applicant B one in which it is present without ever breaking a consistency proof between two log roots, and could thereby mint a second floor for the same human with no public artefact failing. Closed by the per-interval commitment of the dictionary root inside the co-signed log, by the rule that a non-membership or status proof is valid only against a root appearing there, and by client verification of both chains (§2.3). A deployment that implements the split without the commitment has this threat wide open and its published evidence will not show it.

• T5: cross-context linkage. Reduced, not eliminated. Enrolment nullifiers carry no epoch component and epochs are share-refresh only (§2.6), and enrolment contexts are per instance, so a person's enrolments at two instances are unlinkable from those values. The cross-check value of §2.3 remains linkable across every participating instance by construction, and since v0.6 it is linkable for the whole of a membership rather than for one epoch, because the rotation that bounded it could not be built: see T12, which treats it as its own threat rather than as a footnote here.

• T6: live-session relay and coercion. A live session proves presence of the genuine chip at protocol time, not the holder's consent: real-time relays and coerced sessions pass it. Mitigations: holder binding is REQUIRED at document assurance (§2.1), so a seized document alone no longer suffices; attended enrolment at high assurance; the challenge binds the specific transaction; and a person may revoke the document route unilaterally. Residual: a person compelled to enter their own PIN under threat cannot be distinguished cryptographically from a willing one. That is T10, and the answers there are procedural, not cryptographic.

• T7: targeted membership test. An adversary who knows a specific person's attribute value computes that person's nullifier and tests it against the set. Closed twice: every evaluation requires a fresh live session with holder binding (§2.2), and the set is not published, so there is nothing to test against (§2.3).

• T8: status-diff and leaf-diff leakage. Publishing leaves, or per-entry status inside them, would let anyone diff consecutive roots and follow individual entries and their status transitions, which at community scale is re-identification with no cryptography involved. Closed by publishing no leaves at all (§2.3), by the element-hiding non-membership proof (a predecessor-successor proof would hand every applicant two live entries), by banding the assurance distribution so a single route change does not move a figure by one, and by suppressing counts below k including zero, so the suppression notice itself carries no bit about whether anything happened.

• T9: escrow sabotage and framing. Where an escrow exists (federation phase only), a client encrypting garbage buys itself unconditional pseudonymity and an operator encrypting a wrong linkage frames a third party. Closed by verifiable encryption at enrolment (§5). In deployments where the escrow is forbidden (§5), this threat does not arise because the artefact does not exist.

• T10: the adversary in the same household. The most dangerous adversary in this design is not the state, the operator or a remote attacker: it is the person who shares the front door. This adversary holds the documents (seizure is a standard control tactic), usually the device and the PIN, is frequently the incumbent key binding, is frequently in the attestation circle, is sometimes on the board of a small instance, and can weaponise the protocol's own protections: a notification becomes a tripwire, an objection right becomes a veto, a dispute becomes a freeze, and a report against the person becomes a status change. Six routes and their closures:

  • the money: destination change decoupled from recovery and immediate under a flag (§2.4);
  • the keys: this was open until v0.5. Because the adversary usually holds the phone and the PIN, he is the incumbent binding, so the victim needs a rebinding rather than a destination change, and the standard baseline gave him notice with a date plus N days of veto, valid precisely because he signs with her keys. Closed by the eighth safety-route bullet (§2.4): under a standing flag, rebinding is immediate, unannounced, unappealable, and revokes the old keys on the spot. Closed, not hidden: the revocation is visible to whoever holds that device, because the old keys stop working, so the protocol removes his notice, his date and his veto but cannot remove his observation. The timing is therefore part of a safety plan made with the accredited body, and no deployment may describe the step as unnoticeable (§2.4);
  • the documents: mandatory holder binding plus unilateral document revocation that is not legible as an event (§2.1);
  • the community: institutional attestation with attester-hiding, conflicted-attester limits, and a reviewer outside both the community and the instance, with accreditation held at federation level so the instance cannot de-accredit the body that guards against it (§2.5);
  • the cross-instance check, incoming: the uniqueness query is itself a message. Without the rules of §2.3 it arrives at the community someone just fled, on the day they enrolled elsewhere, and at village enrolment rates even its timing is a signal. Closed by one-sided output, fixed-cadence batching with dummy queries, and by never routing the check to the instance of origin while a flag stands;
  • the cross-instance check, outgoing: this was open until v0.6, and it was opened by the repair above. Rules about the direction of the output bit say nothing about the legitimacy of the asker. The instance she fled still holds her cross-check value from her membership, so it can put that value in its own fixed batch against every peer and read the bit: within one cadence it knows which community she is in. The two mitigations make it worse rather than better, which is why it survived a review round: dummy queries make a probing question indistinguishable from a real one by design, and the responder is forbidden to learn that anything matched, so it cannot report what it may not know. Closed by binding every real element to a fresh derivation from a live session in that interval, by recording the count of real elements per batch and having the auditor reconcile it against the enrolment record with a mismatch counting as a grammar break, by the absolute rule that a person under a standing safety flag is never the subject of a query originating from the instance they left on any route, and by the destruction duty that removes the value from that instance's store altogether (§2.3, §2.6). Honest limit: the closure is procedural and detective rather than cryptographic; a board that harbours the adversary keeps its ciphertext regardless, and what changed is that using it is now a detectable break instead of an ordinary query. Exit does not help here, because a person in flight does not file a departure request with the community she is fleeing.

  Residual, stated honestly: an adversary present at the moment of enrolment, holding both the document and the person, cannot be excluded by cryptography. That is why the institutional route exists, why it must never require the instance to be told where the person is, and why the safety flag is revocable only by the person or an accredited safeguarding body. Second residual: the decoy covers status and enrolment and cannot cover the published money and measurement series (§2.4), so a determined local observer may still infer a departure from aggregates.

• T12: compromise of the cross-check context or store. The cross-check nullifier is derived deterministically from the federation-wide seed attribute and is replicated, encrypted, at every participating instance. Consequences if it falls: a t-of-n coalition on the cross-check context can compute any person's value directly from their attribute, without first obtaining any nullifier, so the "must first obtain what to test" barrier that limits T1 does not apply here; and a leak of one instance's encrypted store yields a join key against every other participating instance. Mitigations: derive it only where federation-wide uniqueness is actually needed, encrypted at rest, never published, out of the instance only inside a PSI run and only as an element freshly derived in that interval (T10, outgoing route), destruction on exit (§2.3), destruction where a standing safety flag makes the holder the risk, and destruction wherever the value cannot be updated (§2.6). The rotation that v0.5 listed here as a mitigation is withdrawn (§2.6): no instance can derive a new value, since it holds neither the seed nor a live session, and the named OPRF suite family offers no key rotation. Where an updatable threshold OPRF with an update token is actually built, rotation returns as a mitigation and brings its own exposure: a leaked token maps old values to new, which undoes the rotation retroactively for every store that was copied before it. Residual, stated honestly and now larger than in v0.5: unless such a construction runs, this value is fixed for the whole of a person's membership, and it is exactly the federation-wide correlator that the per-instance scoping removed from the public layer. It is named in §1, §2.3, §2.6, §2.7 and in the plain-words section rather than denied in any of them.

• T11: re-identification at community scale. With a few hundred participants, local side knowledge (who moved, who died, who suddenly draws nothing) places entries without any attack on the cryptography, and every published series derived from person-level events is a channel. On the Anchor side this is closed as far as it can be: no published leaves, no per-entry status or timing, aggregate counts suppressed below k, batched mutations with randomised delay, aggregate-only evaluation logging. What remains is arithmetic that this specification cannot fix alone: an aggregate count still moves by one when a person joins or leaves, and a service that publishes person-derived series elsewhere (deliveries, queues, payouts) can undo all of the above. Deployments MUST therefore apply the same k-threshold discipline to every series they derive from these entries, and MUST warn participants in writing that pseudonymity is weak below roughly 10,000 participants (§5). Two refinements that a threshold alone does not give, both normative in §2.4: a threshold on a derivable quantity protects nothing, so the published precision of the inputs MUST be chosen such that the propagated uncertainty in each derivable value exceeds the largest single contribution to it; and deterministic rounding is not a defence against repeated releases, so quantisation MUST be sticky or replaced by a noise budget accounted across releases. Whether the resulting parameters actually hold against change-point detection at 50 to 200 participants is a question for a disclosure-control specialist, not for this document (open question B).

• T13: sybil through the manual admission route. The refusal route of §2.5 establishes uniqueness by a human judgement with no token and no attestations, so nothing in this specification prevents the same person from being admitted twice, at one instance by two assessors over time or at two instances that both run the route. That is the deliberate price of a route that costs nobody their floor, and it MUST NOT be paid back by narrowing the route. What bounds it: the assessor is bound by the conflict rule and by a published limit on what may be requested; the count of manual admissions is reconciled by the auditor even though only an aggregate is published; and the route carries a published cap or ratchet per interval (§2.5). What does not bound it, and is stated because the earlier formulation implied otherwise: saying that the instance carries the residual risk assigns blame without moving energy. A fraudulent floor draws real kWh through the same per-capita divisor as everyone else's, so the cost lands on all participants and hardest on those already at the floor. A deployment MUST state where that shortfall is absorbed before it opens the route, and the honest reading of this threat is that a manual route at scale needs an answer this document does not have.

• Replay: enrolments, attestations and evaluations MUST be signed, timestamped and nonced; live sessions are bound to the enrolment or evaluation nonce.

• OPRF availability: evaluation needs t of n shareholders online; degradation blocks new enrolments and recoveries only, never existing status, and never the safety route.

• Residual, stated honestly: an issuer that hands one person two conforming attributes defeats Layer 0; the answer is assurance downgrade (§2.6).

5. Privacy considerations

• The set is personal data. The nullifier set is a collection of pseudonymised personal data without direct identifiers, and so are the aggregates derived from it. It is never "contains no personal data". A data-protection impact assessment (GDPR art. 35) is an admission requirement per instance, and it MUST be completed before the first enrolment, not after.

• Erasure, honestly. An entry in an append-only log cannot be un-created. The exit route of §2.3 (revoke in the state dictionary, republish the dictionary root inside the witness-co-signed log, destroy the cross-check nullifier, destroy any escrow record, irreversibly aggregate the history) is what this design can offer instead of erasure. The DPIA MUST state this explicitly, state the retention term of the entry and the actual lifetime of the cross-check value (§2.6), state that the log entry survives account deletion, and state the consequence the person must confirm in writing beforehand: a revoked entry ends the recovery route.

• The federation-wide correlator is disclosed, not denied. Where the instance runs the cross-instance check, the privacy notice MUST state in plain language that a federation-wide value derived from the person's identity is held encrypted by every participating instance; how long it lives, which since v0.6 means for the whole of the membership unless an updatable construction with an update token is actually running (§2.6), and never a claim of periodic refreshment that the deployment cannot execute; that it is destroyed on exit and on a standing safety flag; and that moving to another community therefore gives a clean start toward the public and toward the new instance's view of history, but not a guarantee that the federation cannot tell the same human is involved (§2.7, §4 T12).

• No pre-built unmasking machinery. An instance MUST NOT build or operate a facility that links pseudonyms to persons in advance and without concrete cause. In particular, where the instance already knows its members by other means (a membership register), the escrow record is forbidden: it protects nothing the instance does not already hold, and it manufactures a second, population-wide unmasking path with additional parties. No law obliges a private party to create traceability it does not have; building it anyway fails necessity and data-protection-by-design (GDPR art. 5(1)(c), art. 25).

• Escrow in the federation phase. Where an instance genuinely does not know the persons behind its pseudonyms, a threshold escrow becomes defensible, under all of: trustees established in the EEA or in a country covered by an adequacy decision; never a trustee subject to extraterritorial production legislation; a published transfer impact assessment; at least one trustee outside the instance and at least one outside government; and verifiable encryption at enrolment (a zero-knowledge proof that the ciphertext under the trustees' public keys decrypts to the account identity attested in the same live session; records failing verification make the enrolment invalid, §4, T9).

• Unmasking, layered and conditional. Default is pseudonymity toward everyone outside the instance. Two exceptions exist and both are deliberate:

  1. Unmasking resistance is computational and conditional (§2.2, T1), never "impossible by construction"; a conforming deployment MUST say so in its privacy notice.
  2. Where an escrow lawfully exists, decryption happens only on a legally valid order of the competent authority under applicable law. Silent decryption is technically impossible for any coalition below the quorum m. At or above m the transcript is enforced procedurally, not cryptographically: trustees MUST release shares only against an inclusion proof of the request in the witness-co-signed log, and this residual trust in a full quorum MUST be stated in the privacy notice, symmetric with T1. Mitigations for that residual: trustee diversity (organisational and jurisdictional), share refresh alongside the OPRF resharing cadence, and the log as deterrent and evidence trail, never as proof of non-occurrence.

• The split transparency log. An unmasking record MUST NOT be a public register of suspicion, and it MUST NOT force a trustee to tip off an investigation. The record is therefore split:

  • Public and immediate: per interval, the number of requests and the number of granted openings, the category of the demanding authority and the legal basis. Never a pseudonym, an account, a case detail or anything traceable to the person. Published on a fixed cadence, including when the number is zero, so that silence is itself informative. Note the deliberate opposite treatment in §2.3, where a zero is suppressed: this counter describes the instance's own conduct toward authorities, where an unpublished zero would let a real request hide behind a gap; the set counts describe events happening to persons, where a published zero is a signal about them. The rule protecting persons wins wherever the two meet.
  • Private and immediate: an inclusion proof of the request delivered to the person concerned, unless deferral of notification has been ordered by a competent authority, in which case the identifying part rests under a salted commitment and the proof is released automatically when the deferral expires. What the commitment is for, and what it is not for. It exists so that the public aggregate above can be shown and verified while the identifying side stays illegible; it is not an early-access mechanism for the person concerned. The opening by the data subject becomes available once the deferral has expired, and not before. The formulation carried in v0.5 (that the person may open their own entry at any time) cancelled the very deferral an authority had ordered, and put the instance back in the position this construction exists to remove: break the grammar or break the law. Deferral regimes exist precisely because the subject may not know while the order runs. The opening is automatic at expiry, so nothing depends on the instance remembering, and the deferral itself remains bounded, published as a maximum and never renewable by the instance. This construction MUST be reviewed by a criminal-procedure specialist before this FEP goes FINAL (open question I).
  • Trustees MUST NOT release a share without an inclusion proof of the request in the log, and MUST NOT make any disclosure that would reveal an ongoing investigation. Where a confidentiality obligation also forbids the aggregate entry, the instance publishes a periodic canary statement instead, and the privacy notice states that this enforcement is procedural and not cryptographic.

• Attestations. Attester-hiding is a MUST for both routes with no encrypted fallback (§2.5); the identity and the category of an institutional attester are never recorded, and the route a person used is not legible in their record. Services MUST NOT publish more than the aggregate effect of attestations. The honest lower bound is a disclosure duty, not a property. Where the regional accreditation list is below the published minimum size (§2.5), the privacy notice MUST state, in plain language and before the person chooses that route, that the anonymity set is that small list, that the categories on it differ visibly, and that the instance can therefore often guess which body attested even though it records nothing. Promising attester-hiding at a list size that cannot deliver it is the one failure mode this section cannot afford, because the person weighing it is choosing between two ways of being seen.

• The manual admission route MUST be described in the privacy notice (§2.5), with the way to invoke it, what the assessor may ask, how long the substantiation is kept, and the refusal and appeal route. A person MUST be able to move to it at any time without disadvantage, since the whole point is that the identity layer of this specification is refusable. The notice MUST NOT present the route as an exception for difficult cases.

• Small worlds leak. Below roughly 10,000 participants the anonymity set is weak against local side knowledge (§4, T11). A written warning to that effect is mandatory, and it MUST appear in the material a participant reads before joining, not only in the specification.

• The safety route MUST be described in the privacy notice, in plain language, with the way to invoke it and the name of at least one accredited safeguarding body from the federation-level list. A protection that only specialists can find does not exist for the people who need it. Three further requirements, because a promise here is read by people making an irreversible decision:

  • the notice MUST state whether the route is actually in operation at this instance, and MUST NOT describe it in the present tense while it is being built. A deployment that cannot demonstrate the route running MUST NOT recruit participants who would depend on it (people at a protected address, people in a coercive household);
  • the notice MUST state the limits of §2.4 plainly: the decoy covers status and enrolment, it does not cover the published measurement and settlement series, and it is never used against a lawful order from an authority;
  • the notice MUST state that the key rebinding is unannounced but not invisible: whoever holds the old device sees it stop working, so the moment is planned with the accredited body rather than chosen alone (§2.4). A notice that promises an unnoticeable rebinding sets off the alarm it was written to prevent.

  The notice MUST also state, plainly, that within the instance the person is known.

6. Open questions (before FINAL)

• (A) Concrete ciphersuites: ZK system for wallet-attestation verification and live-session (CA/AA) binding with holder binding; threshold-OPRF suite (RFC 9497 family); hash-to-context; proactive-resharing scheme. Added in v0.6: an updatable threshold OPRF with an update token (Pythia-style), which is the only way the cross-check value can be rotated without the person, since RFC 9497 provides no key rotation and the instance holds no seed (§2.6). Selecting it means selecting its price as well: values stored as group elements, and a leaked update token that maps pre-rotation values to post-rotation values, undoing the rotation retroactively for every store copied before it. Until this is chosen and built, no deployment claims rotation.
• (B) Parameters and recommended defaults: attestation cadence, k, grace periods, recovery waiting period N, maximum term for disputed and for unreviewed dormant, the k-threshold for suppressing published aggregates, the banding width of the assurance distribution, the PSI batching cadence and dummy-query volume, the federation epoch length where an updatable cross-check construction exists, the published minimum size of a regional accreditation list (§2.5), the cap or ratchet on manual admissions (§2.5), and the published precision per series that satisfies the propagation condition of §2.4. The last two of these need a disclosure-control specialist rather than a reviewer: whether the chosen thresholds and quanta survive change-point detection over repeated releases at 50 to 200 participants is a measurement, not an opinion.
• (C) Resharing cadence and ceremony for the OPRF shares (§2.6).
• (D) Cross-anchor recognition table format for coupling contracts.
• (E) Cross-reference existing FEPs and W3C VC work before submission; cite live numbers.
• (F) Per-country attribute survey (the BLOCKING DEPENDENCY of §2.1): which signed attribute conforming to the §2.1 profile is actually available per member state, verified by an eID/MRTD specialist; production readiness and proof times of ZK proofs over chip/wallet signatures on consumer hardware; and per country whether holder binding (PIN, biometrics) is actually available, since §2.1 now requires it for document assurance. Enrolment in a context cannot start before this survey confirms a conforming attribute for each involved member state.
• (G) Construction choice, now a build order rather than an open-ended question, and four constructions rather than two. Name, parameterise, build and measure, per deployment, and publish each: (1) the element-hiding non-membership construction for the state dictionary (sparse Merkle over H(nullifier), RSA accumulator, or equivalent) whose root is committed per interval inside the witness-co-signed transparency log (§2.3); (2) the one-sided-output PSI (circuit-PSI or private set membership) carrying a per-element proof of fresh derivation from a live session in that interval (§2.3), which is no longer a protocol available off the shelf and is the price of closing the outgoing route of T10; (3) the updatable threshold OPRF with a rotation token of question A, without which the cross-check value does not rotate at all; (4) an attester-hiding construction over the federation accreditation list for the institutional route (anonymous credential or threshold signature over that list, with revocation that does not reveal the issuer), which must hide the issuer from the instance while letting the instance verify validity and follow revocation, over a list of perhaps three to six semantically distinct bodies (§2.5). The feasibility caveat carried in v0.4 is withdrawn on the reviewing cryptographer's own correction: sparse-Merkle non-membership over hundreds to thousands of entries and unbalanced PSI with one-bit output are not the bottleneck; the bottleneck is the ZK proof over chip and wallet signatures, which is question F. Stated plainly, since v0.6 grew this list rather than shrinking it: this specification writes properties and does not deliver constructions, and that gap is now the largest single item between this draft and an implementable one. It needs an implementing cryptographer, not another reviewing one.
• (H) Institutional attesters, restated: which bodies are willing and legally able to attest liveness under professional confidentiality, per region, and how the federation-level accreditation list is governed and funded. The question is no longer how to avoid creating a second gatekeeper; it is how to keep the party being checked from appointing and dismissing its own checker (§2.5). Answering it requires talking to the bodies themselves, and to people who have used a shelter, before any deployment relies on this route.
• (I) The deferred-notification construction of §5, referred to a criminal-procedure specialist before FINAL: does a salted commitment that opens automatically at the expiry of an ordered deferral, and only then, sit correctly against the national deferral and tipping-off regimes (in the Netherlands art. 126bb, 126ng and 126ug Sv under the new code, and art. 23 Wwft), and does the public canary counter of §5 survive beside them. v0.6 removed the sentence that let the person open the commitment during the deferral, which is what made the construction unlawful on its face; whether what remains is lawful is not a question this document can answer about itself.

Acknowledgements

Designed in the CBER project as the resolution of "one person, one floor" across federated instances; sibling of the CBER settlement FEP and of FEP-Guardians in spirit: minimal shared grammar, free house rules. Version 0.2 incorporated the repairs from the adversarial council review of 2026-08-19, session 2 (seed source, live sessions, conditional unlinkability, threshold-escrow unmasking, resharing-only epochs, recovery baseline, witness-co-signed transparency). Version 0.3 incorporated the session 3 re-review (formal seed-attribute profile with blocking-dependency label, honest below-quorum escrow claim, evaluation bound to live sessions, salted status commitments, authenticated disputes, verifiable escrow encryption, relay and coercion in the threat model, aggregate evaluation logging, art. 22 safeguard). Version 0.4 rebuilds the privacy layer after the privacy council of 2026-08-19, session 8, which rejected the design five votes to zero and sent this layer back to the drawing board: the set is no longer published and nullifiers are scoped per instance (A10), the safety route for protected persons is normative (A5), attester-hiding is a hard condition with an institutional route beside it (A6), the escrow is forbidden where the instance already knows its members (A11), the unmasking transcript is split (A12), holder binding is required with a unilateral document revocation (A20), and status history neither travels nor persists (A23). The threat model now names the adversary that none of the earlier models contained: the person in the same house. The safety route is owed to the domestic-violence threat modeller, who was alone in demanding it.

Version 0.5 answers the review of that rebuild, council session 9 of 2026-08-20, which did not withdraw the rejection: two of five members voted to reject again. The blocking repair is that the safety route now covers the key binding and not only the destination (A29), because a route that leaves the person holding the phone with a notice and a veto protects the money and abandons the control. Beside it: attester-hiding extended to the institutional route with the attesting body never recorded (A42), accreditation moved out of the instance to federation level with no retroactive de-accreditation (A43), the PSI check given one-sided output, batching, dummy traffic and a bypass under a safety flag (A44), the single accumulator split into a transparency log and a state dictionary with element-hiding non-membership proofs (A45), the cross-check nullifier stated honestly everywhere instead of denied in three places, rotated per federation epoch (that rotation is withdrawn in v0.6 as unexecutable) and destroyed on exit (A46, T12), the dispute freeze brought under art. 22 safeguards with the abolished destination binding removed (A47), the decoy bounded in scope with its cost assigned to the instance (A52), and the zero-suppression rule reconciled with the canary rule (A54). The plain-words section now says that the safety route is a requirement a deployment must build, not a fact about every deployment, because the reviewer noticed it was promised in the present tense to the reader least able to afford that error.

Version 0.6 answers council session 10 of 2026-08-20, which withdrew the architectural rejection of session 8: all five members agreed with amendments, including the two who had voted to reject twice, no member found an architectural defect this round, and the chair declared the panel redundant for this layer. What was left was a sweep, and most of it was self-inflicted: the reviewing cryptographer found four holes that the previous batch had created itself, and three of them sat inside his own amendments. The PSI repair of v0.5 turned the arrow around instead of removing the question, so the instance a person fled could still initiate the cross-check and read a location bit under cover of the mandated dummy traffic; elements are now bound to fresh derivations, counted, reconciled by the auditor, and never aimed at a flagged person by the instance they left, and T10 carries it as a sixth route (A71). The epoch rotation of v0.5 could not be executed by anyone, since the instance holds no seed and RFC 9497 offers no key rotation, and its fallback sentence handed the mitigation to everyone except people with no document and people in flight: the requirement is withdrawn, an updatable threshold OPRF with an update token is named with its price, and a value that cannot be updated is destroyed rather than kept (A72). Splitting the accumulator split the guarantee, so the state-dictionary root is now committed per interval inside the witness-co-signed log and no proof is valid against any other root, which closes the equivocation route that T4 had claimed closed since v0.4 (A73). Quantisation became a propagation condition instead of a common quantum (A74). Attester-hiding on the institutional route got its construction named and its honest lower bound written down, since a ring of four semantically distinct bodies hides nothing (A75). The deferral clause no longer lets the person open their own commitment while the deferral runs, which is what had made it cancel itself (A78). The eighth safety-route bullet now says that the key revocation is visible to whoever holds the old device and that the timing therefore belongs in a safety plan, which is a worse promise and a true one (A82). And the manual admission route, refusing the identity layer entirely, is written into §2.5 with its own threat entry, so this FEP knows the refusal route the companion grammar already has (A68). Owed by name: the cryptographer, for dissenting against three of his own amendments in the same session he approved the design; the domestic-violence threat modeller, whose withdrawal of a fatal dissent hangs on a recruitment ban that must actually bind; and the sceptic, who found the heaviest finding of the round by running the reference engine instead of reading the text.

References

• CBER-1: The Grammar (companion specification), in particular the unmasking invariant I12 (numbering as of CBER-1 v0.4/v0.5) and the internal-access invariant I14
• [RFC2119]; RFC 9497 (OPRFs, which notably provide no key rotation, §2.6); Pythia (updatable PRF with key-rotation tokens, cited in §2.6 as the class of construction a rotation claim would need, not as an endorsement of a specific scheme); RFC 9162 (Certificate Transparency v2); ICAO Doc 9303 (machine-readable travel documents); BSI TR-03110 (Chip Authentication / EAC); eIDAS 2.0 / EU Digital Identity Wallet (pseudonym attribute); Regulation (EU) 2016/679 (GDPR), in particular art. 5, 22, 25, 35 and Chapter V; W3C Verifiable Credentials; Semaphore (zk nullifier pattern)
• [FEP-521a] Representing actor's public keys (FINAL); [FEP-8b32] Object Integrity Proofs (DRAFT); [FEP-ef61] Portable Objects (DRAFT); [FEP-c390] Identity Proofs (DRAFT, related work: proves control of external identities, where Anchor proves uniqueness of a person; complementary, not overlapping); [FEP-633c] Guardianship (representation of persons who cannot act for themselves; this is the representation relationship CBER-1 §7 relies on for minors, who do receive an entitlement, whose uniqueness is established in a separate non-shared context without publication of any token and without community attestations, and whose representative holds no control over the entitlement itself, only over its practical delivery). Statuses verified against the FEP index, 2026-07-17.

Copyright

To the extent possible under law, the authors have waived all copyright and related or neighboring rights to this work ([CC0]).