Access Gates for Metanet Rooms

Crumbs, zer0_dt_

He that received seed into the good ground is he that heareth the word, and understandeth it; which also beareth fruit, and bringeth forth, some an hundredfold, some sixty, some thirty.

Access is normally something granted. You ask, somebody authorised to say yes decides, and your name goes into their table. That decision is discretionary, unaccountable, and free to whoever makes it — and the last of those is the flaw. Admitting somebody who damages the room costs the room; refusing somebody who would have improved it costs the applicant; neither lands on the desk that decided. A decision-maker insulated from the consequences of the decision is the textbook shape of a moral hazard, and it is why access lists rot.

A gate inverts the arrangement. The condition is published, the facts are the applicant's own, and nobody grants anything — you satisfy a rule or you do not, the world supplies the answer, and the cost of it falls on whoever moved. Standing at such a door means having put something at risk: a holding you could lose, a name somebody attached to you and can withdraw, a record of conduct written by people who were there. The party who gains from being inside is therefore the party who paid to get in, and whoever set the rule is exposed to their own rule, since one drawn carelessly excludes exactly the people it was meant to attract.

That is worth the trouble because of what is behind the door. Information placed well returns more than was put into it, which is why a room's contents are worth a rule at all and why a careless rule destroys something rather than merely causing offence. Price entry in stake rather than in permission and any meeting of minds can become a market in information: everybody inside has put up something real to be there, nobody profits by degrading what they bought into, and the entrant's incentive, the incumbent's and the room's point the same way. It is the principle behind proof of work applied to a door instead of a chain — a claim is worth what it cost to make, provided the cost is real and anybody can check it — and access earned that way widens as the record does and narrows the same way, because every fact beneath it can be withdrawn by the world rather than by an administrator.

Abstract

This document describes access gates: conditions attached to a room, evaluated by a client against verifiable facts about a reader, that decide whether the room's contents are rendered to them.

Five gate types are described — holding, vouch, renounce, quorum and timelock — together with a ban, which appears in no manifest and applies to every room, an optional recurring fee, a manifest format so that two clients evaluate the same rule identically, and a verdict structure so that the result is data rather than a sentence. A room's roles are derived from the same conditions rather than from a list of appointees, which is what lets a room say who may moderate without keeping a register of moderators.

Every fact a gate reads is one BRC-169 already publishes: a holding, a peer attestation, a statement written against a handle. No new cryptographic mechanics are introduced and no command verbs are claimed; the conversational surface for configuring a gate is BRC-218. This document subsumes BRC-218 section 11, which sketched three of these gates in a page.

Motivation

What a room is, here. A room is a space with more than two parties, contents that persist, and a participant set somebody could enumerate. A group chat is the obvious case; a channel, a forum, a comment thread and an open feed are the same shape. This document does not say how a room comes to exist, where its contents are carried, or what an ecosystem calls it — those differ everywhere, and standardising them is not necessary in order to standardise the door. It asks two things of whatever an ecosystem provides: a stable identifier, so that a rule attaches to the right thing, and a holder, so that a change to the rule is attributable to somebody.

Two things are deliberately not rooms. A one-to-one conversation is not one — reachability between two identities is already answered by BRC-169's scopes and tolls at the messagebox, each party is their own gate, and a predicate would be a worse version of a decision they can make directly. Nor is anything with a single participant: a feed you alone post to is a publication, and who may read it is a question about distribution rather than about membership.

The distinguishing feature is that a room accumulates. What is said in it stays, so admitting somebody admits them to everything already there. That is what makes a rule worth having, what makes a careless one expensive, and what makes removing one irreversible.

A room needs a rule about who is in it, and the reflex is a membership list. A list fails the way administrators fail. It goes stale, because nobody enjoys pruning it. It bottlenecks on whoever holds it and stops working the week they lose interest. It cannot say why anyone is on it, so nobody can audit it and nobody can join by satisfying it — they can only ask. And it lives in a vendor's table, which makes it exactly as portable as that vendor.

A gate is a predicate over claims other parties have already made, in public, for their own reasons. Nobody has to be asked. The answer is the same for everyone who evaluates it, and a reader can read the rule that excluded them.

The deeper difference is the reason for most of what follows. A list marks; a gate wagers. Being on a list is a fact about the list: it predicts nothing, forbids no outcome, and cannot turn out to have been wrong — a name sits there whether or not the thing it stood for is still true, and it comes off only when somebody removes it. A gate names a condition reality decides. It can be satisfied and it can stop being satisfied, both without anyone's permission.

That difference has a price attached. A gate costs something to satisfy and a list does not. A holding gate asks you to have something you could lose; a vouch gate asks somebody to attach their name to you, which is theirs to withdraw; a fee asks you to keep paying. Each is exposure, and each can be checked by anyone who cares to. An entry on a list is free to the person on it and free to whoever put them there, which is precisely why lists drift: nothing about them is answerable to anything, so nothing corrects them.

The failure mode is a gate that has stopped wagering. Roles are derived rather than granted for this reason and no other — a moderator who holds a rare item stops being one by selling it, where an appointed moderator can only be un-appointed by whoever appointed them. It is also why section 9 is blunt about gating being presentation. A gate described as a security boundary has changed categories: it has stopped being a checkable claim about who holds what and become a promise about what cannot happen, which is a promise it cannot keep and which nothing will ever falsify to the person relying on it.

None of this argues that every room should be gated, and section 10 says which should not be. A room can be perfectly good without a rule, and most are; a gate applied to a room that never needed one converts a group of people who know each other into a predicate that is wrong about some of them. The claim is narrower: a room that is going to have a rule is better off with one that can be read, checked, satisfied and lost than with a list nobody can audit and nothing can correct.

Two properties make this worth writing down rather than leaving to clients. Determinism is the product — if two clients disagree about who may read a room, the room is a different room in each of them, and a rule that varies is worse than no rule because it looks like a guarantee. The excluded reader is the design — the difference between a door and a disappearance is what the person outside is told, and somebody refused should be able to read the rule that refused them and say what would change the answer.

BRC-218 reserves /gate for charging admission to a room: the write half, needing custody and refunds. This document covers the read half only — a condition, evaluated locally, deciding what is rendered.

Prior Art

Three bodies of existing work bear on this. The design converges with the first, diverges deliberately from the second, and comes close enough to the third to be worth distinguishing carefully.

Policy languages. The three-state verdict of section 3.1 is not a novelty. XACML has carried Permit, Deny, Indeterminate and NotApplicable since 2003, with Indeterminate meaning exactly what it means here: the decision point could not evaluate, which is neither an admission nor a refusal. This document arrives at the same three states by a different route and drops the fourth, because a room with no condition is answered by section 2 rather than by the evaluator. Where a design converges with a mature policy language it is usually because the problem has a shape, and it is worth saying so rather than presenting the state as a discovery.

The stored grant. The dominant answer to "may this person be here" is to write the answer down. The access matrix of the early 1970s made it a table of principals against objects; role-based access control, standardised as ANSI INCITS 359 in 2004, added an indirection so the row names a role rather than a person; directory groups, workspace memberships and cloud IAM policies are the same object at scale, and a Discord member list or a Slack workspace is its consumer form. In every one, somebody with authority writes a row, and the row is what is consulted afterwards.

The arrangement has real advantages, and this document is not improved by pretending otherwise. A table read is cheaper than any predicate — no lookup, no indexer, and no state in which the answer cannot be computed. It is private, since being on a list discloses nothing about why, where a gate makes the qualifying facts legible to anybody who can evaluate it. It is precise in a way no predicate is, because a person can admit exactly who is meant and nobody else, including where the criterion is "my colleagues" and no public fact means that. It is recoverable: an administrator restores access to somebody who lost their keys, which section 8.4 cannot. And it can refuse an adversary who satisfies every stated condition, which a gate structurally cannot, because anybody who can buy in gets in.

What it costs is what the Motivation names. The grant outlives the reason for it, nothing about a row being answerable to anything. It cannot be audited by its subject, who can neither read the rule that excluded them nor discover that no rule did. It bottlenecks on whoever holds the write. It is not portable, being a row in one vendor's table. And whoever writes it bears none of the cost of writing it wrongly, which is the moral hazard this document opens by objecting to. A gate does not discipline that administrator; it removes the object they were writing to.

Token-gated rooms as a product category. Guild.xyz, Collab.Land and Discord's own role gating have shipped hold-a-token-get-a-role for years, and Lens and Farcaster channels do a version of it too. The mechanism there is a service: a bot holds an API key, checks a wallet on a schedule, and writes a row into a platform's membership table. What it produces is a list — the gate runs once and its output is an entry that persists until something else removes it, which is why those systems need periodic re-checks and why their failure mode is a stale roster nobody notices.

So the product category is a stored grant with an automated writer. It moves the discretion from a person to a bot and leaves the row where it was, which is why the trust it asks for is the same trust: the reader must believe a service they cannot inspect about a check they did not witness against a table they cannot read.

The difference this document draws is that the predicate is the membership. There is no row to write, so there is nothing to go stale; the answer is recomputed by whoever is rendering, from facts the reader's own client can verify, rather than asserted by a service the reader must trust. Four consequences follow that neither the product category nor the stored grant has. The rule is portable, being a signed object rather than a configuration inside one platform, so a room survives the platform it was formed on. The excluded reader can read it, because it is published rather than held in a bot's database, which is what makes a refusal answerable. Roles fall out of the same evaluation, so a moderator who sells the qualifying item is demoted by arithmetic rather than by a synchronisation job that may never run. And there is no privileged reader: the room's own operator evaluates the same predicate over the same public facts as everybody else, and cannot admit a favourite without changing the rule where the participants can see it.

That last one is the whole of the difference from a centralised system, and it is worth stating as a limit rather than as a boast. A gate does not make an operator honest. It makes an operator's dishonesty a signed, published edit to a rule with a notice period attached (section 2.4), rather than an unlogged row in a table nobody outside can read.

Specification

The key words MUST, MUST NOT, SHOULD, SHOULD NOT and MAY are to be interpreted as described in RFC 2119. They are used sparingly, and where interoperability actually breaks; the rest of this document describes a mechanism.

Throughout, "resolve" means the client resolution algorithm of BRC-169 section 5.7, and "handle" has the meaning given in BRC-169 section 2.1.

1. Terminology

• Room: as described in the Motivation — more than two parties, persistent contents, an enumerable participant set, a stable identifier and a holder.

• Reading: rendering a room's contents to someone. Every gate here governs reading.

• Admission: becoming a participant — a different thing from reading, and specified only for a room that publishes a condition.

• Manifest: the conditions attached to a room, encoded per section 2.

• Condition: one typed test a reader is evaluated against. Five are configured in a manifest and are on or off; the ban of section 4.6 is configured nowhere and applies to every room.

• Verdict: the outcome of evaluating a manifest against a reader — qualifying, failing, or indeterminate.

• Holder: the single identity that holds a room. Custody, not qualification.

• Role: what a participant may do, derived per section 7.

2. The Manifest

A manifest is a signed JSON object attached to a room. Every condition that is on must pass; there is no OR across types, because a room admitting readers who satisfy either of two unrelated conditions is two rooms and the reader cannot tell which one they are in. A condition that is on but not yet configured admits — manifests are edited in live rooms, and a half-typed condition that locks everyone out for the seconds it takes to finish typing is a broken editor rather than a strict door.

Three properties are load-bearing enough to state as requirements. The manifest MUST be readable by anyone who can see the room exists, including readers who fail it, since a rule you cannot read is a rejection with the reason withheld. It MUST NOT enumerate the identities it admits: naming a handle as an attestor is a condition on the reader, while naming one as an admittee is a membership list with extra steps. And a change to it is reported in the room, being at least as much the participants' business as a change to the room's name.

Where a manifest states at least one condition, admission is self-service: a reader who satisfies it may join without anybody's approval. A room that has stated no condition has published nothing to satisfy, so nothing here entitles anyone to join it — an ungated room is not thereby open to strangers, and how somebody joins one is out of scope. Discovery is out of scope too; section 6 governs what a reader sees once they have a room's identifier, not whether rooms are listed anywhere.

2.1 Shape

Field	Type	Required	Meaning
version	integer	yes	format version; 1 for this document
counter	integer	yes	monotonic per room
signedAt	block height	yes	the chain-anchored moment of signing, per 2.4
room	string	yes	room:<domain>/<local>, per 2.2
holder	handle	yes	custody
effectiveFrom	block height	no	when this manifest starts deciding, per 2.4
replaces	digest	no	the manifest superseded; required while pending
burn	outpoint	no	the unspendable output of 2.4, where ungating
ungateBurn	decimal string	conditional	satoshis to burn to ungate; required while any condition is on
successor	handle	no	who may assume custody after dormancy, per 8.3
dormantAfter	blocks	no	holder silence after which successor may sign, per 8.3
token vouch renounce quorum fee roles	object	no	conditions, per 2.3

An absent condition and one present with "on": false evaluate identically; the distinction exists for an editor holding a half-configured condition and nowhere else.

Condition shapes:

token     { on, mode, assets[], minimums{}, shares{}, fees{}, source }
vouch     { on, mode, handles[], source }
renounce  { on, mode, handles[], source }
quorum    { on, count, distinctEcosystems, source }
timelock  { on, minimum, blocks, source }
fee       { on, asset, amount, period, to }
roles     { on, rarity{}, minimums{}, shares{}, weights{}, counts{}, entitiesAreAdmins }

There is no ban condition, and section 4.6 says why: a ban is a decision about one person rather than a rule about who may enter, so it is carried in the room's record and applies whether or not a manifest exists.

mode is "any" or "all" and is present wherever the field it governs holds more than one entry; each gate type below gives the default when it is absent, because the two produce very different rooms and neither is obvious enough to leave to a client. minimums{}, shares{} and fees{} are keyed by asset reference, canonicalised as <protocol>:<id>. On a timelock condition minimum is satoshis and blocks is a count, both per section 4.5; in roles, weights{} takes a role name to a lock weight in satoshi-blocks. source names where a client may look for facts it cannot hold itself: the attestation lookup of section 4.2 on a vouch, renounce or quorum condition, and the chain indexer of section 4.1 on a token condition. In both cases it is a hint and not an authority, per those sections. In roles, each map takes a role name — "admin", "mod", "member" — to its threshold.

Two encoding rules matter for agreement rather than taste. Thresholds are decimal strings, compared as decimals — always, not where precision demands it, since a rule that applies sometimes is one two implementations will disagree about the boundary of. And the manifest is canonicalised per RFC 8785 before signing, or two encodings of the same rule hash differently and the integrity check below means nothing.

A client rejects rather than partially evaluates a manifest carrying more than one condition of each type or more than sixteen entries in any array. A manifest naming two hundred contracts forces two hundred lookups on every render, which makes a room a denial-of-service instrument against everyone who opens it.

A client meeting a version it does not know treats every condition as indeterminate rather than evaluating the subset it recognises, since silently ignoring an unrecognised condition admits people the room excluded. The cost is that a version bump is a hard break; a later document wanting a gradual path should add optional conditions within version 1.

2.2 Identifiers

A room identifier is room:<domain>/<local>, the domain being one the holder's ecosystem controls. Uniqueness comes from the domain exactly as it does for handles, since a bare local string collides the first time two ecosystems both have a room called general.

An asset is named by a pair — a protocol and an id meaningful within it. This document registers 1sat (an origin outpoint, <txid>_<vout>) and bsv21 (a token id); a client meeting an unregistered protocol returns indeterminate rather than failing the reader. An asset MUST NOT be identified by name: a collection called "Naka Motor Club" is a display string anybody can choose, so a gate on a name is one an impersonator satisfies by minting a contract with the same one. Clients show the name beside the reference, resolved from it rather than the other way round.

2.3 Integrity

A manifest is signed over its canonical form by the holder named in the manifest it replaces, or for a room's first manifest by the holder in the room's creation record. Nobody else: a role derived from a holding carries no authority to rewrite the rule that derived it, and an arrangement letting admins sign successors lets any of them name themselves holder and keep the room. Roles govern the day to day; custody governs the rules. It follows that an acting admin under section 7.4 cannot change a manifest — succession lets an abandoned room be moderated, not re-founded.

A client MUST verify the signature before evaluating, and MUST treat a manifest that fails verification as indeterminate rather than absent. Absent means ungated, so a relay able to turn a gated room into an ungated one by corrupting a byte would have the cheapest possible attack on all of this. The counter must exceed the highest already accepted for that room, or a relay can replay yesterday's manifest and quietly readmit somebody excluded this morning.

Signing defends against alteration and not against deletion, since removing a manifest achieves what corrupting one cannot. Two rules close most of that gap: a room's creation record states whether the room carries a manifest, and a client served none for a room whose record asserts one treats it as indeterminate; and a client that has accepted a manifest never afterwards treats that room as ungated without a later signed manifest turning the conditions off. Together they cover the returning reader completely and the first-time reader as far as the creation record can be trusted. A reader handed a forged creation record for a room they have never seen cannot detect it from within this document — where that matters, the room's identifier should commit to its creation record.

2.4 Change

A room's rules have to be changeable; a room that cannot be gated after the fact must know on the day it is created what it will become, and no room knows that. But rules rewritable at will are not much use either, and the people rewritten are the ones who never agreed to the new version.

The instinct is to make the first gate easy and later ones hard. The axis that matters is not first-versus-later but who a change puts out of the room.

A change excluding nobody currently in the room takes effect immediately — turning a condition off, lowering a threshold, removing an attestor, widening a band. A change that would newly exclude a current participant carries an effectiveFrom at least 1,008 blocks beyond its signedAt, is reported when signed rather than when it lands, and shows affected participants that they are affected. Until then the manifest it replaces continues to decide.

The same interval applies to a change that would demote a current participant without excluding them. A role threshold raised past somebody currently moderating takes their capability away, and the fact that they can still read the room does not make that a change they should discover by finding a control missing. Section 7.1 already requires that a demotion be told directly; this requires that a demotion by rule change be told in advance.

Which of the two a change is MUST be decided by comparing the manifests, per section 2.5, and MUST NOT be decided by evaluating current participants. The obvious implementation — apply the proposed rule to the roster and see who drops out — is the balance oracle the Security Considerations warn about, and it would make the notice rule of this section implementable only by running it.

Both are block heights rather than wall-clock times, and signedAt exists so that the interval has a reference point inside the object it constrains. A notice measured in days would need a clock two clients agree on, and they do not have one: skew between them would land a tightening at different moments in each, which is exactly the disagreement section 3.1 exists to prevent. A height is a fact both can look up. At the network's ten-minute target 1,008 blocks is about a week, and it is a week measured in the only unit the parties share.

Two details make the notice real rather than nominal. A pending manifest carries replaces, the digest of its predecessor, and a client holding no copy of that predecessor fetches it or returns indeterminate — otherwise the notice protects only clients already watching, and a reader arriving mid-window served nothing but the pending manifest would apply the tightening early. And at most one change may be pending: signing a new manifest replaces any pending one and restarts its notice, without which a holder can chain changes so the notice never arrives, or announce a mild change and swap a harsher one into a clock the room has already read.

The asymmetry people expect falls out of this rather than being stipulated. A room's first gate is usually chosen to fit the people already in it, because the room formed around the thing it gates on; such a gate excludes nobody and lands at once, which is why upgrading an ordinary group chat is easy. A later change is usually made because somebody should not be there. Those exclude, and those wait.

Grandfathering is not available, and the reason is structural. Letting existing participants keep access under the old rule means recording who was admitted under which manifest — a list of individuals with privileges attached, the exact object this document exists to replace. The notice preserves nobody's access; it gives them time to keep it or to leave with warning, which is less than grandfathering and is honest about being less.

Ungating is the one change that cannot be undone. It excludes nobody, so the rule above would land it instantly, and it exposes everything already said to everybody arriving afterwards — people spoke under a rule about who would hear them. So a manifest with any condition on declares ungateBurn, the amount that turning them all off will cost, and turning them off references an output that is provably unspendable and worth at least that much, verified before the change is accepted and treated as indeterminate where it cannot be verified, which leaves the gate standing.

The amount is declared rather than computed, because a computed one is not checkable. An earlier draft scaled it by participant count, which two clients verifying at different moments would count differently and so disagree about whether an ungating was valid — a rule that fails the agreement of section 3.1 is not a rule. A declared figure sits in a manifest anybody can read before they speak, which is the disclosure that makes it useful: a room declaring nothing is telling its members that their history is one signature from public, and that is information they can act on. It may be raised at once, since raising it excludes nobody and takes nothing away. Lowering it follows the notice above, because it withdraws a protection participants have been relying on even though it puts nobody out of the room.

What the burn buys is narrow and worth stating. It does not protect the archive; anyone determined to publish a room's contents copies them out without touching the manifest, and no rule here could stop them. It makes the supported path deliberate, verifiable by anyone, and profitable to nobody — the amount is destroyed rather than paid, so no participant, holder or third party gains from a room being opened and no constituency forms around making it happen. Provably unspendable means exactly that: a famous address that has never been spent from is an ordinary output whose key may exist, which makes it a gift to whoever holds that key rather than a cost to nobody.

2.5 Comparing two manifests

Section 2.4 turns on whether a change excludes anybody, and that question has an answer that does not require knowing who is in the room.

Manifest X is at least as strict as Y when every reader admitted by X would also be admitted by Y. The relation is about admitted sets and not about text. It is a partial order: a rule requiring a vouch from @deggen and one requiring a vouch from @crumbs admit neither a subset nor a superset of the other, and no amount of comparison will sort them.

Where the replacement is no stricter than the manifest it replaces, no reader who qualified stops qualifying — for every possible reader, not merely for the present ones — and the change takes effect immediately.

A manifest is a conjunction: section 2 admits only readers who pass every condition that is on. So turning a condition on is stricter, turning one off is looser, and otherwise the comparison is condition by condition:

Condition	Stricter when
token	minimums or shares raised, per asset; assets[] shrinks under mode: any, or grows under mode: all; mode any → all
vouch	handles[] shrinks under any, or grows under all; mode any → all
renounce	handles[] grows under any, or shrinks under all
quorum	count raised, or distinctEcosystems false → true
timelock	minimum raised, or blocks raised
fee	amount raised, period shortened, or asset or to changed
roles	never — a role map admits nobody and excludes nobody, and is compared for demotion under 2.4 rather than for exclusion
source, on any condition	never — section 4.1 makes it a hint a client may decline, so it cannot move the admitted set

Renounce runs the other way, and an implementation will get this wrong. Every other condition admits on a match; renounce excludes on one and admits by default (section 4.3). Adding a handle to a vouch gate under mode: any gives the reader another way in, and adding one to a renounce gate under the same mode gives another party the power to shut them out. Same field, same keyword, opposite sign.

ban does not participate. It appears in no manifest (section 4.6), so there is nothing to compare.

The comparison is sound and incomplete, and the incompleteness is the price. Proving that a replacement admits a superset proves that nobody is excluded; failing to prove it does not mean anybody is. Raising a minimum from 500 to 600 in a room where everybody holds thousands is stricter by this order and excludes nobody in fact, and the room waits 1,008 blocks anyway. Where two manifests are incomparable a client MUST treat the change as excluding, which means swapping one attestor for another also waits.

Erring this way is deliberate. The alternative to a conservative structural test is an exact one, and the only exact test is to run the proposed rule against the people in the room — which yields, for whoever is editing, a per-member verdict they can refine by editing again. A week's delay on a harmless change is a smaller cost than shipping that.

A room that wants an exact answer may ask its members for one: each client evaluates the proposed manifest against its own user and returns whether they still qualify. That discloses one boolean per member instead of a quantity, supports no binary search, and licences immediate effect where every current participant answers yes. It requires the members to be present and willing, so it is a fallback rather than the rule.

3. Evaluation

3.1 Order and determinism

Two conforming clients evaluating the same manifest against the same reader from the same facts MUST reach the same verdict. Conditions are evaluated ban, renounce, vouch, quorum, holding, timelock, fee, and the first failure is the one reported. The order runs from the most categorical to the most quantitative, so the reason a reader sees is the most fundamental rather than an accident of iteration. A ban comes first because it is the only one a person in the room decided — telling a reader they do not hold a token when the truth is that a moderator excluded them gives them a reason they cannot act on. The fee comes last because it presupposes the holding it accompanies.

Where a client cannot obtain a fact, the verdict is indeterminate: not passing, not failing, and surfaced as its own state. Fail-open is the obvious hazard; fail-closed-and-say-nothing is the subtler one, because "you do not qualify" and "I could not check" send a reader to do entirely different things.

3.2 Freshness

A gate is evaluated against a reader's current standing rather than their standing when they joined — balances are spent, vouches withdrawn, statements written. A cached verdict does not outlive the shortest ttl of the resolutions it depended on, and does not exceed five minutes where no ttl is available; "bounded" without a bound is a requirement every implementation satisfies and no two satisfy alike. A cache is discarded on a key change for that reader under BRC-169 section 4.4, since the facts a gate reads are facts about a key. Discarding the verdict is not the same as concluding the reader has nothing; section 8 covers what a rotation should and should not cost them.

3.3 Verdicts

A verdict is produced as data and rendered afterwards, never produced as a sentence:

{
  "outcome": "fails",
  "condition": "token",
  "index": 0,
  "shortfall": { "held": "12.32", "required": "21.8" }
}

The outcomes are qualifies, fails and indeterminate and no others. condition is one of ban, renounce, vouch, quorum, token, timelock, fee; index says which entry of a multi-entry condition decided; period accompanies a fee verdict; height accompanies a timelock verdict, per section 4.5(4); shortfall accompanies a quantitative failure, and on a timelock condition it carries whichever of the two figures fell short:

{ "outcome": "fails", "condition": "timelock", "height": 921740,
  "shortfall": { "locked": "40000", "required": "100000", "blocks": 900, "requiredBlocks": 4032 } }
``` Wording is the client's — two clients rendering it differently is fine, two clients computing it differently is not. An agent acting under BRC-218 is given the structure rather than the sentence, since prose is not an interface.

**Quantities are only ever the reader's own.** A client evaluating a manifest against its own user shows the arithmetic. Evaluating against anybody else — to mark a roster, filter a picker, preview a manifest — it MUST NOT display, log or export any quantity: not the amount held, not the shortfall, not a bar derived from either. A qualitative reason may be shown, because it discloses nothing new; that a named handle has not vouched for somebody is an absence in a public record. A balance is not. A roster annotated "holds 12.32 of the 21.8 required" turns a settings screen into a balance oracle over everyone in the room, and an administrator who can edit the minimum can binary-search a participant's holdings in a few keystrokes. The line falls between public claims and private quantities, in the same place on every surface, and `shortfall` is omitted from an exported verdict for the same reason.

A client also MUST NOT report a verdict, or that one was computed, to the room or to any ecosystem host. Evaluation happens on the reader's machine against public facts, and phoning the result home would hand every room a list of who looked and failed — a more sensitive list than the participant list the gate is protecting.

Finally, a verdict is not a judgement. Failing a gate is a condition on a room rather than a finding about a person, and a client that renders "does not meet this gate" in the visual language of a failed signature has editorialised on the room's behalf.

#### 3.4 Delegation

Where a reader acts through a delegate under BRC-169 section 9, the gate is evaluated against the **principal**. A delegate's own holdings, vouches and statements never substitute in either direction: an agent holding a rare item does not make its principal an administrator, and an agent holding nothing does not lock a qualifying principal out of their own room. A delegate exercises no capability its principal lacks and none outside its certificate's scope — roles are the ceiling, the certificate is the aperture — and an action it takes is attributable to both.

### 4. Gate Types

Five gate types are configured in a manifest. A sixth condition, the **ban** of section 4.6, is configured nowhere and applies to every room; it is described here because section 3.1 evaluates it and section 3.3 reports it.

#### 4.1 Holding

The reader holds a named asset. A holding gate names a **contract**, not an item: a room wants holders, and a gate on a serial stops being true the moment somebody sells one item and buys another from the same issue. Where the asset is fungible the gate may set a minimum; where it is non-fungible it does not, holding one not being a quantity and 1.5 of an item being a question with no answer. A minimum of zero is not a threshold and is rendered as "any holding" rather than as a decorative `0`. Where several assets are named the default is **any**. Where a contract publishes a register, showing which item satisfies the gate is the difference between "allowed" and "holds hat 13", and the second is what makes a gated room feel like a room rather than a permission.

**Which outputs are the handle's.** Before a client can ask what a handle holds it has to know which outputs to look at, and BRC-169 does not answer that: resolution binds a handle to an **identity key**, while assets sit at derived or separate keys and are not found by looking at the identity key alone. The mapping is a second thing, and this document requires it to be **published by the holder**, as one or more `holdingKeys` served alongside the handle at the resolution endpoint of BRC-169 section 5.1.

Publication rather than proof-on-demand is the whole reason a gate is evaluable by a stranger. A holder who instead proved control when asked would make every evaluation interactive, which would mean nobody could be evaluated while offline, and a member who sold their qualifying asset would become indistinguishable from a member who was asleep. Section 11 records what it would take to relax this.

**A declaration MUST be signed in both directions**, and an implementation that omits the second signature is broken in the way that matters. The identity key signs a statement naming the holding key; the holding key signs a statement naming the handle. Without the second, a declaration is an unverified claim about somebody else's coins, and any handle could name the richest key on the chain and inherit its standing. This is the bidirectional rule of BRC-169 section 5.5 applied to a different pair: one side asserts, the other consents, and both are required so that nothing can be bound to a party that has not agreed.

Two consequences a holder should be told before declaring. The declaration is **public and permanent in effect**: every output at a declared key is thereafter attributable to the handle, by anybody, including for the past. And it is therefore worth declaring a **dedicated** key rather than a wallet's main one — qualifying assets are moved to it, the rest of the holder's activity stays unlinked, and the room learns what it needs and nothing else. A client SHOULD offer that arrangement rather than proposing the key the user already uses.

Rotation follows from this rather than complicating it. A declaration signed by an identity key that has since changed is stale, not void: section 8.2's evidence decides whether the rotation is genuine, and a genuine one is re-declared under the new identity key while the holdings and the holding key stay exactly where they are.

**Where the facts come from.** Neither of the protocols registered in section 2.2 can be read from a transaction in isolation. Determining that a handle holds an item of a `1sat` contract, or how many units of a `bsv21` token it controls, means following a chain of transfers from an origin, which is what an indexer does and why one is already a dependency of any client that displays a balance at all. A holding gate adds no new infrastructure; it asks the question the client's wallet surface is already asking, about somebody else. Two facts are read: the outputs a handle controls, which is a mapping distinct from the identity binding for the reason section 8.1 gives, and, where the gate uses a share or a rarity band, the contract's own published supply or bands (section 7.3).

**An indexer is a witness, not an authority, and a client MUST NOT treat one as authoritative.** A token condition MAY carry a `source`, and it is a hint about where to look rather than a delegation of the answer: a client is free to prefer its own indexer, and should. The distinction is load-bearing rather than fastidious. Two honest indexers agree because they are reading the same chain, so naming one buys convenience and not agreement — unlike the attestation lookup of section 4.2, where the stores genuinely differ. And a manifest able to bind every reader to one indexer would hand the room's holder a privileged view: an operator who controls the source controls the verdict, which is precisely the arrangement this document exists to remove. A client that can reach no indexer it trusts returns indeterminate under section 3.1.

Two properties of the underlying data are worth stating, because a client reading a balance for its own user forgives both and a gate does not. An indexer answers about chain state at a height it has reached, so lag reads as a holding that is not yet there or one that is no longer there, and it is bounded by section 3.2 exactly as a stale resolution is. And an unconfirmed transfer is not a holding: a gate satisfied by an unconfirmed spend admits a reader whose qualification can still be undone, which is a distinction the room's own participants cannot see and the reader can.

#### 4.2 Vouch

The reader is vouched for by named handles, under BRC-169 section 10. The handles are resolvable and shown resolved: a gate naming `@deggen` names a specific key, and BRC-169 section 2.3's confusability rules apply exactly as they do to a payee, since a homoglyph in a manifest is a gate on somebody else's signature. Only **attributed** attestations count — an attestation is a [BRC-52](../peer-to-peer/0052.md) certificate with a peer as certifier, and one whose signer cannot be resolved to a handle the reader can look up does not satisfy the gate. Attestations of a handle-to-key _binding_ are not vouches for the person; a gate summing them admits on the strength of people confirming the reader's spelling. Where several handles are named the default is **any**.

**Attestations must be discoverable, and discovery is a SHOULD rather than a guarantee.** A vouch gate reads the attestations made _about_ an identity, which is a different question from how a peer publishes one, and it is unevaluable without an answer. BRC-169 section 10.8 supplies the shape: an ecosystem SHOULD answer it for its own handles at the resolution endpoint of section 5.7, as a list of attestation outpoints with their certifiers. That is where a client looks first, and where the ecosystem answers it a vouch gate needs nothing further.

Because it is a SHOULD, some ecosystems will not answer it, and a gate naming attestors across several ecosystems only needs one of them to be silent. A manifest may therefore name the lookup it expects to be answered from, as `source`, which is a fallback for that case rather than a substitute for the endpoint. A client that can reach neither returns indeterminate rather than concluding nobody has vouched: absence of evidence and evidence of absence are the same bytes over a failed connection, and only one of them should close a door.

#### 4.3 Renounce

A statement written against the reader by any named handle closes the door. Alone among the types this gate **admits by default** — everyone passes until a specific claim exists — which makes it the only one that scales to a room open to strangers, and the only one whose absence of configuration is a meaningful state. It follows that an unreachable source does not make it indeterminate as it would a vouch gate: no claim found is the same state as no claim existing, and the alternative lets anyone who can knock over a lookup service take an open room dark. The gate admits, and the client says the check did not complete.

**Only attributed statements gate.** BRC-169 section 10.7.1 makes negative statements unattributed by default, deliberately, so that speaking against somebody does not require a reputation large enough to survive it. Acting on unattributed statements would convert an anonymous claim into an exclusion the subject cannot answer, at whatever scale the claimant can manage. The reader is told which handle blocked them: the statement is attributed by construction, and withholding the name protects nobody who has already signed it. Where several handles are named the default is **any** — one statement closes the door.

#### 4.4 Quorum

The reader is vouched for by at least **N distinct** handles, unnamed. This is the vouch gate for a room that knows what standing it wants and not whose, which makes it the one a new room can actually configure: naming three trusted handles requires already having a view, and a room's first members are the people forming one. Attestations are counted once per **signing key**, since counting per attestation lets one party clear any threshold alone. Discovery is subject to section 4.2 and the exposure is worse here — a vouch gate can at least be evaluated against the handles it names, while a quorum gate has none to ask about.

A quorum gate may require attestors to resolve to **distinct ecosystems**, computed from the domain part of the handle. Without it, a ring of mutually-attesting accounts in one ecosystem clears any N for the cost of creating N accounts. With it, the same attack costs coordination across independently operated domains — which is a cost and not a proof, since one operator can run several domains, and a room relying on it should say so rather than describe the requirement as independence.

#### 4.5 Timelock

The reader has locked satoshis, to their own key, until a stated height. The condition sets a **minimum amount** and a **minimum remaining duration**, and both must be met; the ladder of section 7.3 reads the two together as a single weight.

What distinguishes this from a holding gate is not the asset but what the reader gives up. A balance is a fact about now, and it survives being lent, borrowed for the length of one evaluation, or bought from somebody on their way out — section 11 records that a rented balance is the weakness the holding-shaped gates share. A lock cannot be rented, because renting implies return and the coins do not move; it cannot be bought from somebody exiting, because the lock pays to their key and not to yours; and it cannot be assembled for the moment of evaluation and dissolved afterwards, which is the whole of the Sybil economics. It is the strongest condition in this document, and it is strong for one reason: the cost is real, ongoing, and borne by the person claiming it.

1. The lock is an output the reader controls, encumbered so that it cannot be spent before a stated height. It is read through the mapping and the indexer of section 4.1, which also verifies that the encumbrance is genuine — an output merely *intended* to be held is a holding, and belongs to section 4.1 rather than here.
2. **Duration is measured forward, not backward.** What counts is the blocks remaining between the current tip and the unlock height, not how long the lock has already run. A lock therefore decays: its weight falls as it matures, and a reader approaching a threshold is demoted before they are excluded. That is the intended behaviour rather than a defect. It gives warning where a cliff would not, and it means standing is maintained by re-committing rather than by having committed once, which is the difference between a wager and a receipt.
3. Both figures are compared as decimals per section 2.1, amounts in satoshis and durations in blocks. Blocks are used for the reason section 2.4 gives: two clients share a chain and do not share a clock.
4. **Determinism holds at the level section 3.1 requires and no higher.** Two clients at the same tip reach the same verdict. Two clients one block apart can differ on a reader sitting exactly at a boundary, because the remaining duration is genuinely different between them — that is two clients with different facts rather than two clients disagreeing, and section 3.2's freshness bound is what keeps the window small. A verdict on a timelock condition carries the height it was computed at, so a disagreement can be explained rather than merely observed.
5. A lock that has passed its unlock height is not a lock. It contributes nothing, whether or not the coins have been moved, and a client MUST NOT count it — an expired lock is an ordinary balance, and counting it would let one commitment be spent for standing forever.
6. Where several locks are held, they sum: amount is the total locked and the weight of section 7.3 is the sum of each lock's own amount-by-duration product. Summing weights rather than multiplying totals is what stops a reader pairing one large brief lock with one tiny long one and claiming the product of the extremes.

**Unlocking, and getting the coins back.** Nothing in this document moves anybody's satoshis, and neither a room nor a client can. The lock pays to the reader's own key; at the unlock height they spend it as they would any other output. There is no claim to submit, no counterparty to release it, no room permission to obtain, and nothing that can fail. The room never sees a reclaim as an event — it observes only that a condition has stopped being met, exactly as it would a sold token. This is the whole of the difference from the stake of section 11, where somebody else is holding the money and can decline to give it back.

The corollary is that **a term cannot be shortened**, and a reader should be told so before they choose one. Leaving is not immediate: somebody who loses interest in a room a week into a six-month lock is committed for the remaining five, because the encumbrance answers to a height and not to their intentions. That is the cost that makes the condition worth anything, and it is also the one a reader is most likely to have skipped past.

**Standing is held with overlapping locks, not with one.** Because an output cannot be spent before its height, a lock cannot be extended — a reader can only add another. A single lock is therefore a cliff rather than a slope: its weight decays to nothing at exactly the moment its coins become available, so the capital needed to replace it is locked up until it is already too late. The arrangement that works is several locks with staggered heights, each reclaimed and re-committed further out as it matures, which is why the amounts and weights of rule 6 sum. A client creating a lock should say this — recommend a term well beyond the room's minimum, and more than one lock — because it is the difference between a commitment a reader can maintain and one that lapses on them while their money is immobile.

A room wanting more commitment raises `blocks`. It does not get a minimum *original* term, and the omission is deliberate: such a rule would penalise the reader running staggered locks, whose most recent commitment is deliberately short because it is topping up several longer ones, and reward the reader with a single distant lock they cannot maintain. The forward measure already prices commitment, and it prices the commitment that still exists rather than the one that has already been served.

**What a client shows.** Each lock's unlock height, in blocks and as an estimate in days, and the height at which the reader's weight falls below each rung they currently hold. That is the ladder disclosure of section 6 applied to time, and it is the form in which it matters most: a decaying weight means every rung a reader holds has a date on it, and a client that knows the date and does not show it has withheld the only actionable thing about the condition.

**What it costs, stated here rather than left to the reader to find.** A timelock gate prices membership in forgone liquidity, which is a wealth test with patience added rather than an alternative to one, and section 10.1's warning about a room gated on wealth applies with the same force. It is also the harshest condition in this document for somebody who loses a key, because section 8.4 loses them their standing and the lock loses them the coins as well. And it is public: a lock is an on-chain object, so a reader satisfying a demanding gate has announced both the amount and the term to anybody watching, which no stored grant would have disclosed.

#### 4.6 The ban condition

A participant banned from a room does not read it. This is the one condition with no entry in a manifest, and the omission is deliberate: a ban is not a rule the room states about who may enter, it is a decision a moderator took about one person, and section 2.1 forbids a manifest naming the identities it admits for the same reason it should not name the ones it excludes — a ban array is a membership list with the sign flipped. So the condition is on for every room, gated or not, and needs no configuration.

1. The facts are the **room's own record**, not a global store. A ban is created by section 7.2 as an attributed statement against the handle, scoped to the room, and it is recorded where the room's contents are. A client evaluating a room already holds them.
2. That is why section 3.1 evaluates the ban first. It is the only condition answerable without a network lookup, and the only one a person in the room decided.
3. Only statements scoped to **this** room count. A room-scoped statement does not satisfy a renounce gate elsewhere (section 7.2), and the converse holds: a statement written about somebody outside this room is not a ban in it. A client that conflates the two lets one moderator's decision follow a person across the network, which section 7.2 exists to prevent.
4. Where a client cannot determine whether a ban is in force — it holds a partial record, or the room's contents are served by something it cannot reach — the verdict is indeterminate. This differs from the renounce gate of section 4.3, which admits on an unreachable source: there, absence of a claim and absence of a lookup are the same state and an open room should not be closable by knocking over a service. Here the record is the room's own, so failing to read it means the client does not know what the room decided rather than that the room decided nothing.
5. A ban is **lifted** by a signed statement referencing it, from any role that could have imposed it (section 7.2). Where both a ban and a lift exist, the later-signed one is current. Nothing is deleted: a lifted ban remains readable, since a moderation record that erases itself cannot be reviewed and the subject has as much interest in the lift being visible as in the ban being so.

### 5. Recurring Fees

A holding gate with a minimum may also charge for continued access. This is a different kind of thing from everything above, and the two sit next to each other in every interface that offers both: the gates of section 4 are predicates over facts that already exist, and a reader satisfies one by being who they are. A fee is an obligation the room creates, satisfied by paying, again, for as long as they want to keep reading.

A fee is not specified without a minimum, and is discarded when the minimum is removed. A charge for holding nothing is a subscription, BRC-218 section 5.6 already specifies subscriptions with disclosure rules a room-settings screen does not have, and a subscription wearing a gate's clothes is a recurring outflow hidden inside a screen about who is allowed in. It is denominated in the **same asset** as the minimum, since a threshold in one asset and a charge in another are two unrelated demands sharing a control. It carries a period from the BRC-218 section 2 `period` rule, and it **names its recipient** as a handle, resolved and displayed as a payee is — an unnamed charge cannot be refused, audited or attributed, and a room collecting from its participants without saying to whom has made all of them party to something none of them can inspect. Amount, period and recipient are disclosed together before the reader commits; disclosing them apart converts a decision into a discovery.

**A room cannot pull a fee.** Enforcement is the gate itself: stop paying, stop meeting the condition, contents stop rendering. Any arrangement in which the room debits a participant is a standing authority, and standing authority is BRC-218 section 5.6 with its disclosure and its visible list, not a room setting. A period once paid is paid, and a change raising a fee does not reach a period already settled.

Two rules make the fee evaluable rather than merely stated. A payment MUST be identifiable as **this room's fee for this period**, labelled with the room identifier and the period using the transaction labelling of [BRC-65](../wallet/0065.md) — "has this person paid" is only answerable to a second client if the payment says what it was for, and without that the fee is not a gate condition at all. Where a client cannot enumerate payments to the recipient the condition is indeterminate rather than failing; the reader may well have paid. And the first period is settled as part of joining rather than invoiced afterwards, since self-service admission would otherwise make every new arrival immediately in arrears — admitted, unpaid, and failing the condition they just satisfied.

**A fee is not offered on a timelock condition.** A lock already prices entry in forgone liquidity, and adding a periodic outflow to an immobilised balance charges a reader twice for the same commitment while removing the funds they would meet the charge from. A room wanting both should hold and charge, per section 4.1, rather than lock and charge.

A fee is not a **toll** (BRC-169 section 8.2) and is not described as one. A toll is per-envelope, paid to the recipient, enforced at their messagebox; a fee is periodic, paid to a named party, and enforced by nothing but the gate.

### 6. What a Failing Reader Is Told

A reader who fails a gate still sees that the room exists, its name, and the **number** of participants — not the participant list, not the messages, not anything derived from them. This is not a courtesy. A room invisible to those outside it cannot be asked about, cannot be joined on request, and is indistinguishable from a room that does not exist, so the people who most need to find their way in are the ones who cannot see there is a way in. Showing the shape and withholding the contents is what makes a gate a door.

The reader is told **which requirement they do not meet**, rendered from the verdict structure, in their own terms and with their own arithmetic: "you cannot read this" is not actionable, and "holds 12.32 BSV of the 21.8 required" is. An indeterminate verdict is presented as such rather than worded as a failure. A client may offer the action that would satisfy the condition, which is a value-moving action authored by a third party and passes BRC-218 section 4 confirmation in full. Nothing shown to a failing reader discloses another participant's standing, holdings, or reason for lapsing.

**The whole rule is shown, not only the part that failed.** Section 3.1 reports the first failure, which is the right thing to put at the top and the wrong thing to show alone: a reader told they lack the holding, who satisfies that and is then told they lack the lock, has been walked through a rule they could have read at once and has spent money finding out its second clause. A client therefore renders every condition that is on, marking which the reader meets, which they do not, and which could not be checked. This costs nothing — the manifest is readable by anyone under section 2, so nothing is disclosed that a determined reader could not assemble — and it is the difference between a door with its terms posted and a door that answers one question at a time.

**The ladder is shown with it.** A room whose `roles` condition is on is stating two rules and not one: what admits a reader, and what a participant must reach to moderate or administer. Both are in the same signed manifest and both are equally public, so a client shows the rungs alongside the door — for a timelock gate, what must be locked and for how long to enter, and what weight reaches mod and admin. Withholding the ladder from somebody deciding whether to commit hides the part of the offer they are most likely to be deciding on, and a room that would rather not publish what its moderators had to do has chosen the wrong mechanism, because section 2 publishes it regardless.

**A participant already inside is shown their own position on it.** The rung they hold, the next one, and what would reach it, with their own quantities under section 3.3 and nobody else's. This matters most where standing decays: a lock weight falls as its locks mature (section 4.5(2)), so a moderator can be demoted by the calendar while doing nothing wrong, and a client that surfaces the drop only at the moment the role disappears has turned a warning into a surprise. Section 7.1 requires that a demotion be told directly; showing the distance beforehand is what makes that requirement useful rather than merely correct.

A participant may also cease to satisfy a room they are already in. That is surfaced rather than resolved silently — whether they are removed is the room's policy, and a client removing them quietly produces a roster that disagrees with the door. The roster marks that they no longer qualify without quantifying the shortfall; the participant themselves is told directly and in full, rather than left to infer it from an icon beside their own name in a list they may never open. Lapsing is not retroactive: a participant who has already received messages has them, and section 9 explains why no client can change that.

### 7. Roles

A gate answers whether somebody may read a room. Every room beyond a few people needs a second answer — what they may do once inside — and the temptation is a list of appointed moderators, which is the administrator-shaped object of the Motivation reintroduced one level down.

So roles are derived from the same conditions as the door. Nobody is _made_ a moderator; they hold a rare item, or 21.8 units, or a vouch from a handle the room named. What follows is the point: sell the item and the role goes with it, on the same evaluation that would have kept them out.

#### 7.1 Derivation

There are three roles — **member**, **mod**, **admin** — and no others, each additional rung being one every participant must reason about before answering "can they delete my message". A role is never assigned by naming an individual. It is read off a condition the room already gates on, and this document describes four mappings:

- **By rarity**, for a non-fungible contract publishing bands. A band is a **threshold**, not a set: assigning mod to Rare makes every band above Rare a mod too, since a rarer item buying a lesser role is a rule nobody would guess and one that silently demotes the Legendary holder standing beside the Rare. The ordering comes from the contract; a client assuming one would eventually meet a collection whose "Exotic" is its commonest tier.
- **By amount**, for a fungible token, as an absolute quantity or a share of supply (section 7.3). Thresholds rise with the role, and a map where the mod threshold exceeds the admin one contradicts itself.
- **By named entity**, for a vouch or renounce gate: the handles the gate names are admins. This is an explicit choice rather than an assumption, because wanting somebody's vouch as a door is not the same as handing them the room.
- **By attestation count**, for a quorum gate: three attestors to moderate, ten to administer, subject to the same distinctness the gate itself uses.
- **By lock weight**, for a timelock gate: the product of satoshis locked and blocks remaining, summed across the reader's locks per section 4.5(6). This is the mapping in which the two dimensions the gate reads separately are traded against each other — a smaller amount committed for longer reaches the same rung as a larger one committed briefly, and the room decides the exchange rate by where it puts the thresholds. It is also the only mapping here that moves without anybody acting: a weight decays as its locks mature, so a moderator who does not re-commit is demoted by the calendar. Section 7.3 says what that does and does not cap.

Where several apply, the strongest role wins. A role is re-evaluated with the gate, and a participant who stops meeting the condition is demoted and told directly rather than left to find a control missing. A role may be shown beside a name — it is qualitative, so section 3.3 permits it — while the quantity behind it remains nobody else's business.

#### 7.2 Capabilities

A **member** reads the room and posts in it. A **mod** also deletes messages and bans members. An **admin** also bans mods and closes the room; changing the manifest is not among them, being custody's under section 2.3.

Banning is strictly downward and never sideways: no role bans its own rank. An admin banning an admin is the one action that can empty a room's admin set in a single click. **Custody is not a rank** — the holder sits underneath the ladder rather than on top of it, may act on any participant, and cannot be acted on; without that, an ungated room where everybody is an admin has nobody able to act on anybody. Deleting a message leaves a record that a message was removed rather than silently closing the gap, since a transcript that rewrites itself is one nobody can reason about afterwards.

A **ban** is recorded as a statement against the handle under BRC-169 section 10.7, scoped to the room — so it has an author, a time and a claim, which a row in a ban array does not. It is **attributed**, reversing BRC-169 section 10.7.1's default: that default protects somebody speaking against a peer at their own risk, and a moderator acting inside a room they moderate is in the opposite position. A room-scoped statement does not contribute to the subject's standing anywhere else and does not satisfy a renounce gate in another room; being unwelcome in one room is not a reputation, and a mechanism letting one moderator's decision follow somebody across the network would be worse than the list it replaced. The subject is told, and by whom, and any role that could impose the ban can lift it. How a ban is then read back as a condition — where the record lives, what scoping means at evaluation time, and what lifting is — is section 4.5.

Closing a room is a signed statement carrying who closed it and when; conforming clients stop accepting posts and render the room as closed. History remains readable, because section 9 is why nothing here can un-deliver a message, and a client presenting closure as deletion has promised something no client can perform.

#### 7.3 Thresholds that cap themselves

An absolute threshold admits an unbounded number of admins: a fixed bar means that as a room grows, a supply inflates, or a price falls, the number of people above it only rises. Two forms avoid that, and both work by capping the privileged population arithmetically.

**A share of supply** caps it directly. 6.9% admits at most fourteen people and 21.8% at most four, because fifteen holders of 6.9% would need 103.5% of the supply and five holders of 21.8% would need 109%. The ceiling holds for a room of eight and a room of eighty thousand. A proportional threshold names the total supply the contract publishes as its denominator — supply held by participants would make a role depend on who else is currently in the room, so leaving would promote everybody left behind — and is not offered for a token whose supply is unbounded or not knowable. The denominator and the band ordering below are both read from the contract through the same indexer as the holdings themselves, under section 4.1: they are the issuer's published facts rather than the room's, which is what makes the ceilings computable by anybody and why a client that cannot read them returns indeterminate rather than falling back to an absolute comparison. Comparison is exact: the threshold is met when `held × 100 ≥ threshold × supply`, on integers where the token is indivisible.

**A rarity band** is a percentage the issuer already computed. Reading a scarcity curve cumulatively produces the same self-limiting property, with the work done by the party who knew what the bands meant:

Naka Motor Club — 2,222 items

band in band band and above share of supply Exotic 22 22 0.99% Legendary 66 88 3.96% Epic 134 222 9.99% Rare 333 555 24.98% Uncommon 555 1,110 49.95% Common 1,112 2,222 100.00%

Choosing Exotic for admin is choosing the top 1% and capping administrators at twenty-two; choosing Rare for mod is choosing the top quarter. Neither number was picked by the room, and every client reading the contract computes the same ceiling, which is why a client shows the cumulative populations at the point of configuration — a room choosing between Rare and Epic is choosing between two ceilings it cannot otherwise see. A band also cannot be diluted, an item's rarity being fixed at mint; the inverse hazard is narrower, in that a contract able to mint _into_ a band can inflate the role assigned to it.

**A lock weight does not cap anything, and the section is not weakened by saying so.** Satoshi-blocks are unbounded: no quantity of them is 100% of anything, so a weight threshold is an absolute one and admits as many administrators as there are people willing to clear it. Everything this section says against absolute thresholds applies. What a weight has instead is a cost that continues — a rung held is a rung being paid for, in liquidity, for as long as it is held — where a rarity band is bought once and kept. The two properties are not substitutes: a room that wants a ceiling on its administrators should cap the top rung by rarity or by share and use lock weight for the rung that ought to scale with the room, which is the pairing this section already recommends for absolute and proportional forms. A room that uses weight for every rung has chosen an ongoing cost over a bounded population, and should be told so at the point of configuration rather than discovering it at forty administrators.

##### The shareholder ladder

The proportional form's natural reading is a cap table, and the thresholds a room reaches for are usually borrowed from company law. Borrow the shape, not the numbers.

Statutory thresholds sit far above what a room needs. A blocking minority is **above 25%** where a special resolution needs 75%, and **above one third** where it needs two thirds; amending articles of association needs the supermajority itself. Those numbers exist because a shareholder cannot leave — their capital is locked in, and a majority able to expropriate them will. A room is the opposite: exit is free, the stake is speech, and the worst an administrator can do is close the room, at which point everybody walks away holding what they walked in with. Protection that expensive buys nothing here.

| Role   | Share           | What it buys                 | Why there                                                                         |
| ------ | --------------- | ---------------------------- | --------------------------------------------------------------------------------- |
| Member | below 6.9%      | Read, post, be heard         | Participation needs no stake                                                      |
| Mod    | 6.9% and above  | Delete messages, ban members | Caps moderators at 14 — about the largest group that can moderate to one standard |
| Admin  | 21.8% and above | Ban mods, close the room     | Caps rule-enforcers at 4: collusion is visible, one absence is not deadlock       |

The rungs stand in a ratio of √10, so each is roughly three times as hard to reach as the one below.

Room size changes what these mean, in opposite directions for the two forms. A proportional ladder empties as a token disperses: ten million units across four thousand holders averages 0.025% each, so a room of two thousand derives no moderators at exactly the size needing the most. A rarity ladder does not, the privileged population being a property of the collection rather than of the room — two thousand holders drawn from a 2,222-item collection still contain most of the 555 items at Rare and above. Where a proportional ladder would empty, the answer is not a lower percentage, which abandons the ceiling: it is **absolute for the rung that scales with the room, proportional for the rung that must not.** Moderation is labour and should scale with how much of it there is; the authority to close a room is not.

Small rooms come out flat under either form. Three people holding a third each are all administrators and none may ban another, which is the right answer — three co-owners need no hierarchy — and an equal five-way split lands at 20% and derives no administrator at all, since 21.8% sits just above one fifth. Section 7.4 is what keeps such a room governable.

#### 7.4 Custody

A derived ladder can empty itself: the only Exotic holder sells, the thresholds are set above what anybody holds, a room is founded by somebody holding a Common. Then there is no admin, and appointing one is a manifest change only an admin could make. Nothing about deriving roles is wrong; what is wrong is having nothing underneath the derivation.

The **holder** is an admin regardless of what any condition derives, and is **exempt from the room's own gates** — without the exemption a room can lock out its own administrator by naming an attestor who later renounces them, or by being founded by somebody below its own threshold. A client shows who holds the room and shows it as custody rather than qualification, an exemption nobody can see being a backdoor and one stated plainly being the reason the room still works. There is no separate guard against a room deriving no admin, because there cannot be one: the holder is an admin unconditionally, a holder is mandatory, and only the holder can submit a configuration at all.

A client warns before applying a manifest under which no current participant would qualify. Unlike the above this is legitimate — a room may tighten and expect people to lapse — so it warns rather than refuses, and does not apply silently.

Where the holder is not a participant and no participant derives admin, a client treats one participant as **acting admin**: highest derived role, then the earliest message attributable to them, then the lowest identity key as an unsigned integer. The first two are the room's own record; the third is arbitrary, is included because the first two can tie, and is written down because an arbitrary rule every client applies identically is worth more than a fair one they each invent. Such a room stays moderatable, which is the most succession can offer — its rules cannot be changed by anybody but a holder who is no longer there. Custody is transferable, and a transfer is reported like any other change to who runs the place. Section 8.3 covers the case where the holder cannot sign a transfer because they can no longer sign anything.

#### 7.5 A room with no gate

Where a room has no manifest, or none of its conditions is on, **every participant is an admin**. This follows from roles being derived rather than being an exception to it: with no band, amount or attestor to read, the only ways to produce a hierarchy are to appoint somebody or to withhold every power from everybody. The first is the list this design refuses to keep; the second makes an ordinary group chat unmoderatable and then requires an appointment to fix it. Flat means everybody at the top rather than everybody at the bottom.

A client does not badge a role every participant holds — a badge distinguishes, and in a flat room there is nothing to distinguish, the holder excepted. Only the holder can gate such a room, which is section 2.3 rather than a rule of its own: every participant being an admin does not make every participant able to sign, and without that a member could enable a condition only they satisfy and take the room.

### 8. Preventing "Not Your Keys, Not Your Room"

Four mechanisms in this document read a key. A holding gate asks what outputs a handle controls (section 4.1). A vouch or quorum gate counts certificates naming the reader as subject, each signed by an attestor's key (sections 4.2 and 4.4). A role is derived from whichever of those the room uses (section 7.1). And custody is a single key, the only one permitted to sign a manifest (section 2.3). Each is checkable by a stranger precisely because it reduces to a signature or an unspent output — and each fails the same way when the key behind it is gone.

Who loses what is worth being specific about, because the three cases are not equally bad. A reader stops qualifying, and the room stops rendering. A moderator is demoted by the same evaluation that would have kept them out, which is what section 7.1 is designed to do and is the right outcome only when the demotion is real. A holder loses the ability to amend the room at all: section 2.3 admits no other signer, section 7.4 denies the power to an acting admin, and the room therefore keeps whatever rules it had, permanently. That third case is the severe one, and section 8.3 is about it.

What a client actually observes is much narrower. Under BRC-169 section 4.4 it compares the identity key a fresh resolution returns against the one it already recorded for that handle, and finds the two differ. That single observation has two causes, and nothing in the resolution response separates them: the person rotated to a new key, or the handle was released and reassigned to somebody else — which BRC-169 section 2.1(4) permits and its section 4.4 exists to catch.

Both of the simple rules are therefore wrong. Carry standing across every key change, and a reassigned handle inherits the previous holder's admissions, roles and room: the impersonation BRC-169 section 4.4 was written to prevent, with a room attached to it. Carry it across none, and section 3.2's cache discard becomes permanent dispossession for anybody who rotates a key for a good reason — which is the behaviour that would make "not your keys, not your room" true here rather than something to design against. So the question is not whether standing survives a rotation. It is what evidence distinguishes a rotation from a reassignment, and BRC-169 already publishes three kinds of it. Section 8.2 sets them out; section 8.1 first disposes of a loss that is largely illusory.

#### 8.1 Holdings are not the identity key

A gate asks what a handle holds, which is a different question from which key signs for it. Assets sit at derived or separate keys, so evaluating a holding gate reads the declared holding keys of section 4.1, and that declaration is not the identity binding. It follows that rotating an identity key does not move anybody's coins: the holding key is unchanged, the outputs at it are unchanged, and a client that zeroes a reader's holdings because their identity key changed has confused two different lookups.

What a rotation does invalidate is the *declaration*, since it was signed by the key that has been replaced. That is a stale attestation rather than an absent holding, and section 8.2 is what decides whether to accept a re-declaration under the new key.

Section 3.2 requires a cached verdict to be discarded on a key change, which remains correct — the verdict must be recomputed. It does not follow that the recomputation should find nothing.

#### 8.2 A rotation the room can verify

Three kinds of evidence can show that a rotation is a rotation, and they are available in different circumstances.

The **old key signs the handover**. This is the ordinary case and it covers a key being retired rather than lost. It is also unavailable exactly when it is most needed.

The **ecosystem reissues**. Within its own namespace a host can rebind a handle to a new key, which is a power BRC-169 already grants it and which every client already trusts for resolution. It is the cheapest recovery and the one that concentrates the most trust in the host.

The **prior attestors say so**. A quorum of the handles that had already vouched for a reader attest the new binding. This needs no new primitive — it reads the same store as section 4.4, counted the same way — and it has the property the other two lack: an attestor who signs a false recovery has staked the name that made their vouch worth anything in the first place. It is also the only one of the three available to somebody who has genuinely lost a key rather than retired it.

A room may treat any of the three as carrying prior standing forward, and a room gating on something valuable should prefer the third. The second asks the reader to trust their host; the third asks them to trust the people who already spoke for them, which is the trust the gate was reading anyway.

#### 8.3 Custody, and the room that freezes

The severe case is the holder. Only the holder signs a manifest (section 2.3) and an acting admin cannot (section 7.4), so a room whose holder has lost their key keeps the rules it has, permanently: never re-gated, never ungated, never handed on. It stays moderatable and becomes unamendable, which is a slower failure than a locked door and not a better one.

A manifest may therefore name a **successor** — one handle, with a `dormantAfter` height. Where the holder has signed nothing for that many blocks, the successor may sign a manifest transferring custody to themselves, under the ordinary notice of section 2.4 and reported like any other change to who runs the place. A holder resets the clock by signing anything at all, including a manifest that changes nothing, so the mechanism costs an active holder one transaction whenever they choose to make it and costs an absent one nothing they were using.

Two alternatives were considered and rejected. A vote among participants is a membership list with a ballot attached, and it re-creates the register this document exists to avoid. A host able to reassign a room puts the room back in a vendor's table, which is the arrangement the Motivation opens by objecting to.

The successor is the one place a manifest names an individual, and it is worth saying why that is not the list section 2.1 forbids. A successor is not admitted by being named. They gain no access they did not already have, the naming grants nothing at all until the dormancy expires, and what they may eventually receive is custody rather than membership — the obligation to sign, not the right to read.

#### 8.4 What is not recoverable

A reader with no attestors, no successor and no ecosystem willing to reissue has lost their standing along with their keys, and nothing here reconstructs it. That is what a stake means: skin in the game is only skin in the game if it can actually be lost, and a document offering a way back from every loss would be describing something else.

What this section prevents is the avoidable version — the person who still holds the assets, still has the vouches, still has a host that will rebind them, and is treated as a stranger anyway because a client read a key change as a new person. Recovery is also cheaper before it is needed than after: a client should prompt for a successor at the moment a room is gated, since that is the moment the room acquires something to lose.

### 9. What a Gate Is Not

A gate decides what a conforming client renders. It does not encrypt, does not authenticate, and does not constrain a non-conforming client at all. Accurate wording says that conforming clients will not show the room's contents to readers who do not qualify; a client promising more has sold a UI toggle as a security boundary.

The enforcement point for who may **send** to an identity is that identity's messagebox, under BRC-169 section 8, exactly as a toll is enforced there and not in the sender's client. There is no equivalent for who may **read** a room whose contents have already been delivered. A room whose confidentiality matters must key its contents so that non-holders cannot decrypt them; that mechanism is out of scope here, and a gate is not a substitute for it.

A gate is therefore best understood as a rule the room states and conforming clients honour. That is a weaker claim than it sounds — it is the same claim as a mailing list's charter — and it is sufficient for the great majority of rooms, which want a shape rather than a secret.

### 10. Choosing a Gate

Everything above describes how a gate behaves. This section is about when to use one, because a document answering only _how_ leaves every client to discover _whether_ by shipping it.

#### 10.1 Rooms better left ungated

- **A room whose value is reach.** Announcements, support, anything somebody arrives at because they need something. A gate on a help channel excludes exactly the people who most need in, in the name of quality.
- **A room small enough to know each other.** Five people who have met need no predicate to decide who is among them. A gate replaces a question nobody was asking with a new failure mode: a friend locked out by a spent balance, at the worst moment, by a rule nobody remembers setting.
- **A room whose membership is a fact about people rather than holdings.** A family, a team. There is no public fact meaning "my colleagues", and a token approximating it is wrong in both directions — admitting strangers who bought in, excluding the colleague who did not.
- **A room where the real problem is one person.** Gating the room to exclude somebody is collective punishment with a technical veneer. A ban is the instrument for one person.
- **A room needing confidentiality**, per section 9.
- **A room whose archive might one day be opened**, since ungating is irreversible.
- **A room whose members may need their money.** A timelock gate is the one condition here that takes something away for a fixed term rather than reading something the reader already has. Where members are not in a position to immobilise capital, it selects for who can afford to wait rather than for who belongs.

The general form: **gate on a fact, never on a feeling.** Where you cannot write the predicate down, do not approximate one — an approximate gate is wrong about specific people, and they can read the rule that is wrong about them.

One consequence is about time rather than about any room, and is invisible on the day the gate is set. A holding gate gives standing to holders and roles give holders the policing of the room, so a room gated on wealth tends to become a room moderated by its wealthiest members, in their interest, without anybody deciding it should. What limits the drift is that moderation is all it reaches — custody keeps the rules — and where ownership is not genuinely the criterion, a vouch or quorum gate has neither property.

#### 10.2 Which gate suits which room

| The room                                       | Suited                             | Why                                                                                    |
| ---------------------------------------------- | ---------------------------------- | -------------------------------------------------------------------------------------- |
| Small, informal, people who know each other    | **None**, or renounce              | Nothing to enforce; at most keep out a known bad actor                                 |
| Small, formal — a board, a working group       | **Vouch**, named                   | The criterion genuinely is one person's judgement, and there are few enough to name    |
| Large, open to strangers, informal             | **Renounce**                       | The only gate admitting by default, so it scales to people you have never heard of     |
| Large, anonymous, formal — holders, a treasury | **Holding** or **share of supply** | The room is about the thing held, and ownership is the criterion honestly              |
| Large, open to strangers, where cheap accounts are the problem | **Timelock** | The only condition that cannot be rented, borrowed or assembled for one evaluation; it costs patience as well as capital |
| Large, dispersed, tight-knit — a guild, alumni | **Quorum**                         | Nobody knows who to name, but the network already knows who is vouched for             |
| A collection's room, with published bands      | **Rarity**                         | The issuer designed the scarcity curve; section 7.3 reads it rather than inventing one |
| Any room with running costs                    | A **fee** on a holding gate        | Never on its own                                                                       |

Four axes change the answer. **Formal against informal**: a formal room can say what its rule is, while an informal one usually cannot, and the gate ends up inventing a rule to justify itself — if configuring the gate is the first time anybody articulated the membership criterion, the criterion is being invented by the tool. **Small against large**: gates pay for themselves at scale and cost more than they return below it, the crossover being roughly where members stop recognising each other's names, and section 7.3 gives the mechanical consequence for each threshold form. **Tight-knit against strangers**: a tight-knit room has a web of vouches to read, so a quorum gate works and nobody need be named, while a room of strangers has none — which is why a holding gate is attractive there and exactly why it is a wealth test. **Growing against settled**: a settled room can tighten cheaply because everybody who would be excluded has already left, while a growing room should gate early or not at all.

### 11. Not Specified Here

Three further gate types were designed and are left unspecified, along with one alternative route to satisfying the conditions that are specified, recorded so the next author does not rediscover them or ship them incompatibly.

**Stake.** The reader has paid into the room. Section 4.5 now specifies the half of this that needs no custodian: a timelock immobilises the reader's own coins at the reader's own key, so nobody holds them, nothing is refunded, and the room ending changes nothing — the lock expires and the owner spends what was always theirs. What remains unspecified is the custodial half, where the satoshis actually move to the room. That still needs what BRC-218 section 6 says `/gate` needs — custody, a rule for what happens when the room ends, and a refund path — and it belongs with that verb. The distinction is worth stating plainly, because the two look identical to a reader and differ entirely in what can go wrong: a lock can only be lost by losing a key, while a stake can be lost by whoever is holding it.

**Tenure.** Not how much somebody holds but how long they have held it — the most attractive of the three, because a threshold can be cleared in one transaction by somebody who arrived this morning and time cannot be acquired on demand. Two things stop it. It needs transfer history rather than balance state, a materially heavier dependency than anything in section 4. And it is weaker than it looks: tenure attaches to a key, and an aged key can be bought along with what it holds, while measuring continuous holding punishes a holder who moves an item between their own wallets for doing what every security guide advises.

**Proofs instead of lookups.** A reader could satisfy a quantitative condition by presenting a proof that they meet it, rather than by publishing the holding keys of section 4.1 and letting anybody add up the outputs. This is recorded rather than specified, and the reason is worth setting down, because the obvious version of it is a net loss.

Where a fact is publicly enumerable, any client can evaluate any reader, which is what makes a lapse detectable: sell the token and every client notices on the next render. A proof replaces that with something only the reader can produce, so the room can no longer re-derive their standing, and a reader who has sold their asset is indistinguishable from one who is offline. A proof is a row that goes stale — the failure the Prior Art section identifies in the product category, arriving by a different route — and the fix, short validity with mandatory re-proof, is the periodic re-check that section criticises. Anywhere the facts are already public, this trades a working property for one the document did not need.

The case where it costs nothing is the mirror image: a reader who has **not** declared holding keys cannot be evaluated by anybody today, so there is no lapse detection to lose. Their present choice is to publish the declaration, permanently and to everybody, or to stay out. A proof would be a third option that takes nothing from anyone else, since they were never inside. Confined that way — an alternative route for undeclared readers, never a replacement for public evaluation, and enabled per room so that a client which does not offer it needs no verifier — the trade is contained.

Four requirements fall out of the rest of this document, and any candidate that fails one is unsuitable rather than merely awkward. The setup MUST be transparent: a per-circuit ceremony makes whoever ran it able to forge admission to every room using that circuit, which is exactly the privileged reader the Prior Art section claims to have removed. Verification has to be cheap enough to run at render time, under the same reasoning that caps a manifest at sixteen entries in section 2.1. The proof has to carry the chain height it was made against, so that section 3.2 can bound its freshness rather than take it on trust. And it has to say what happens on lapse, because a specification that leaves that open has shipped a stored grant.

**Recency.** The handle registered before a date, or active within one. Age is the one property a spammer cannot buy, which makes it the most efficient anti-abuse condition and the most hostile to newcomers. It is unspecified because there is no fact to read: BRC-169's resolution carries no registration date, and a certificate's validity window measures reissuance rather than arrival. It would need a field, and a host's claim about the age of its own accounts is the claim it has most incentive to shade.

### 12. Relationship to Other Documents

This document subsumes and replaces BRC-218 section 11, which now stands as a pointer. Configuring a gate from a conversational interface is a BRC-218 concern; no verbs are defined or reserved here. `/gate`, reserved in BRC-218 section 6, remains the write half — charging admission, with custody of a stake — and the custody of section 7.4 is custody of the _room_, a different object carrying no funds. Every fact read by sections 4.2, 4.3, 4.4 and 4.6 is defined in BRC-169 section 10, and no way to create one is added here; sections 4.1 and 4.5 read chain state through an indexer, and define no new script, encumbrance or transaction format — a ban is that document's section 10.7 statement, scoped to a room by section 7.2 and read back by section 4.6.

## What a Gate Buys, and What It Costs

The case for a gate is made at the front of this document and the concessions to it are distributed across sections 8, 9, 10 and the Security Considerations below. A reader deciding whether to gate a room is entitled to see both totalled in one place.

**What it buys, against a stored grant.** It is auditable by the person it excludes, who can read the whole rule, including the ladder above the door, and say what would change the answer (sections 2 and 6); a list cannot be read by anyone it keeps out, and cannot even be distinguished from the absence of one. It is self-service, so nobody is asked and nobody's attention is the bottleneck (section 2). It is self-correcting, because there is no row to prune and standing lapses on its own when the fact beneath it does (section 3.2). It is portable, being a signed object rather than a configuration inside one platform (section 2.3). And it has no privileged reader: an operator evaluates the same predicate over the same facts as everybody else.

**What it costs.** Five things, and none of them is small.

*It cannot exercise discretion.* Everyone who satisfies the condition is admitted, including the person a human would have refused for reasons no predicate captures. Section 10.1's rule — gate on a fact, never on a feeling — says where not to use a gate; it does not repair this, because it cannot be repaired. A door priced in stake admits anybody who pays.

*It prices membership, and the strongest form prices it hardest.* Section 4.5's timelock is the one condition here that cannot be rented, borrowed or assembled for the moment of evaluation, and it earns that by demanding capital and patience together. It is a wealth test with a term attached rather than an alternative to one, it is the harshest condition in the document for somebody who loses a key, and it publishes what the reader committed. A room reaching for it because it is the strongest should be clear it is also the most exclusive.

*It makes private facts legible.* The facts a gate reads are individually public, but a gate collects them and attaches them to names, and the mitigations of section 3.3 are partial by the Security Considerations' own admission. A stored grant discloses nothing about why somebody is on it. This is a straight loss and there is no version of a public predicate that avoids it.

*Standing is lost with the keys that evidence it.* Section 8 recovers what can be recovered and section 8.4 states the limit plainly. An administrator with a table simply restores access; nothing here can.

*It is not confidentiality.* Section 9 is the whole of it. A gate decides what a conforming client renders and constrains nothing else, which is a weaker claim than users will hear.

*It can fail to answer.* An unreachable source yields indeterminate rather than a decision (section 3.1), and a room can therefore be unenterable for reasons that have nothing to do with the reader. A table read has no such state.

**On the rule-setter being exposed to their own rule.** The Motivation claims it and section 7.4 exempts the holder from the room's own gates, which is a real tension and worth answering rather than leaving to a reader to notice. The exemption is from the mechanism, not from the consequence. A holder who draws a rule too tight is left holding a room nobody can enter; one who draws it to admit everybody has a room worth nothing to be in. What disciplines them is not the gate but the exit: participation is voluntary, the stake is usually speech rather than capital, and a room whose rule is wrong loses the people it was for. That is a weaker constraint than being subject to your own gate, and it is the one that actually operates.

**Except under a timelock, where the exit is not free.** Section 4.5 immobilises a reader's coins for a term they cannot shorten, so the discipline just described is suspended for as long as the lock runs: a participant who wants out waits, and a holder facing them faces somebody who cannot walk away. It is the one place in this document where the mechanism that keeps a holder honest is switched off by the strongest condition on offer. A room choosing that gate is asking its members for more trust than any other, and should be told as much at the point of configuration — the strength of the condition and the weakness of the constraint on the person who set it are the same property seen from the two ends.

**On the drift the design invites.** A holding gate gives standing to holders, and section 7 gives holders the policing of the room, so a room gated on wealth tends to become a room moderated by its wealthiest members, in their interest, without anyone deciding it should. The Security Considerations add that such a role is purchasable at whatever it costs, and that whoever can mint can dilute a moderator out of one. These are consequences of refusing to keep a list of appointees, not defects in the refusal, and they are the price of that choice rather than an argument that the choice is free.

The honest summary is narrow. A room whose membership is a fact about holdings, attestations or conduct is better served by a rule that can be read, checked, satisfied and lost than by a row nobody outside can audit. A room whose membership is a fact about people is better served by the row, and section 10.1 says so.

## Security Considerations

**A gated roster is a balance oracle.** The facts a gate reads are individually public; a gate makes them legible in bulk and attaches them to names. An administrator who can edit a manifest and watch a roster re-evaluate can binary-search any participant's holdings in a handful of edits. Section 2.5 removes the one place this document previously required that operation — classifying a change under 2.4 is a comparison between manifests and not an evaluation against members — and section 3.3 is the mitigation for the rest of it, partially: strip every quantity from a verdict about somebody else before it reaches an interface, and treat "preview this manifest against the current members" as the oracle it is. The underlying disclosure is inherent in evaluating a public predicate over a known set of people.

**A named source is attacker-influenced input, and a verdict oracle.** A manifest may name where to look for facts, and both `source` fields carry the same two hazards: an indexer or lookup chosen by the room sees every reader who evaluates the room, which is the disclosure section 3.3 refuses to send to the room itself arriving by another route, and one that lies decides admissions for anybody who defers to it. Section 4.1 is why a client should prefer its own indexer for a token condition and must never treat a named one as authoritative. Section 4.2's case is worse, because there the stores genuinely differ and a client may have no alternative to the one named.

**A manifest is attacker-influenced input.** Anyone who can create a room can name any contract, any handle and any fee recipient. Offering the reader "here is what would satisfy this" is therefore a payment prompt authored by a stranger and rendered inside their own client; it passes BRC-218 section 4 confirmation in full, and a client treating it as a room feature has built a phishing surface with the room's credibility behind it.

**Unattributed statements must never gate.** Section 4.3 is a security requirement rather than an etiquette one. BRC-169 section 10.7.1 makes negative statements unattributed by default so they can be made at all; wiring that store into an exclusion mechanism would let an anonymous claimant lock a target out of every room using the gate, with no name to answer and no cost to the claim. The two mechanisms are safe separately and dangerous composed, which is exactly the interaction a client author will not notice.

**A vouch gate is a signature dependency.** Naming a handle makes a room's admissions a function of one party's ongoing behaviour, and of nobody noticing if that handle is later recycled. BRC-169 section 4.4's key-change rule applies to attestors as much as to counterparties.

**A tightening can be unsatisfiable by a reader whose funds are locked.** Section 2.4 gives a participant 1,008 blocks to keep their access when a change would exclude them, which assumes they can act. A timelock condition breaks that assumption in the one direction that matters: a reader whose coins are committed for longer than the notice period cannot add to them without new capital and cannot recover them at all, so the notice runs out while they are able to do nothing. A room raising a timelock threshold is excluding, with warning, participants who are demonstrably the most committed to it. A client should say so at the point of configuration, and a room should expect it.

**A locked reader cannot leave, and cannot be made whole.** Every other condition here can be abandoned at will: sell the token, and the room stops rendering. A timelock cannot, so a reader who regrets a room, or who finds it is not what it appeared to be, waits out a term chosen before they knew. Nothing in this document or any client can shorten it, and a room that behaves badly toward somebody whose capital is committed faces a participant with no exit — which is the opposite of the discipline the closing section relies on.

**A lock is a public declaration of means.** Satisfying a demanding timelock gate publishes both the amount and the term to anybody watching the chain, indefinitely and to people who never saw the room. Section 3.3 keeps quantities about a reader inside their own client, and cannot reach this: the disclosure is made by the act of qualifying rather than by the evaluation of it. A stored grant discloses nothing of the kind, and section 4.5 states the cost where a reader will meet it.

**A purchasable role is a purchasable moderator.** Deriving a role from a rarity band or a share of supply puts it on sale at whatever that costs, to anybody, without the room being consulted. That is the honest consequence of refusing to keep a list of appointees, it is sometimes the right trade, and a client should say so at the point of configuration rather than leave it to be discovered.

**Supply is a lever the issuer holds.** Where a role is a share of supply, whoever can mint can dilute a moderator out of their role without touching their balance; where it is a rarity band, a contract that can mint into the top band manufactures administrators for every room gating on it. Neither is visible to the holder as anything but a verdict flipping, which is why the fixedness of a supply is disclosed before a room configures a threshold against it.

**Custody concentrates what derivation spreads.** Section 7.4 puts one identity underneath the ladder so the ladder cannot empty, which makes that identity worth attacking and its key worth losing. Succession limits the damage of abandonment and does nothing about a compromised holder, who can rewrite the manifest and close the room.

**A flat room is one signature from a captured one.** Every participant of an ungated room is an admin, and only section 2.3's holder can sign a manifest — which is what stops any of them writing the room's first gate around everybody else. A client that lets a role sign a manifest has built a one-click takeover into every group chat that never configured anything.

**A ban is a signed public claim.** Scoping keeps a room-scoped statement out of the subject's general standing, but the statement is written by a named party and readable by anybody. Moderating in public is the price of moderating attributably.

**Fail-open on missing data is the classic failure**, and a client that cannot reach a source and admits anyway has a gate any network condition disables. The indeterminate state exists so implementers are not forced to choose between two wrong answers.

**A gate is not confidentiality, and users will assume it is.** Section 9 exists because the mistake is one of wording rather than of code, and wording is what users act on.

## Implementations

The reference implementation is the Nexus client. What it covers is listed rather than summarised, because "implements this specification" is the claim a reader most needs to be able to check.

**Implemented.** Sections 4.1, 4.2 and 4.3; the disclosure rules of 3.3 and 6; lapse handling; and all of section 7 except as below, including the band ceilings, the flat-room rules and the confirmation before a gate is switched off. Verdicts are produced as structures and rendered afterwards.

**Specified and not yet implemented.** Section 4.5's timelock gate, its lock-weight ladder in section 7.3, and the ladder disclosure of section 6. Section 4.4's quorum gate and its count thresholds. The proportional form of section 7.3; the client offers absolute amounts only. The manifest encoding of section 2 and its integrity checks: the prototype holds a manifest in memory and identifies contracts by display name, which section 2.2 forbids and which is the largest remaining distance between the client and this document. Section 5's fee is configurable but not settled, nothing there verifying a payment.

**Depends on infrastructure that already exists.** Section 4.1's holdings, supply and rarity bands are read from a token indexer, which any client displaying a balance already runs or already calls; section 4.5's locks are read the same way, and require the indexer to report an output's encumbrance and unlock height rather than only its value. This is the one external dependency the document does not have to argue for.

**Depends on something no ecosystem serves yet.** Section 4.2's attestation discovery. BRC-169 section 10.8 specifies where the answer belongs — the resolution endpoint of section 5.7, as a list of attestation outpoints with their certifiers — but it is a SHOULD, and no ecosystem answers it today. Until one does, a vouch or quorum gate cannot be evaluated by a stranger's client; the prototype reads a local store, which works only because everything in it is local. The gap is in deployment rather than in specification.

A minimal implementation supports section 4.3 alone with sections 2, 3, 4.6 and 6. Renounce is the cheapest gate to evaluate, the only one admitting by default, and the one a room open to strangers actually needs; section 4.6 is not optional in any implementation, since a room whose bans are not enforced is not moderatable.

## Test Vectors

### Canonicalisation and digest

The manifest below, canonicalised per RFC 8785 and hashed with SHA-256. An implementation that produces a different digest from the same object has a canonicalisation bug, and its signatures will not verify against anybody else's.

```json
{
  "version": 1,
  "counter": 7,
  "room": "room:nexus.app/naka-motor-club",
  "holder": "@[e-mail]",
  "signedAt": 921600,
  "ungateBurn": "100000",
  "token": {
    "on": true,
    "mode": "any",
    "assets": [
      {
        "protocol": "1sat",
        "id": "4449436086e3cd58b73508aa498d886f62a5e88a049d3e27d49d2c9b90add05a_0"
      }
    ]
  },
  "roles": {
    "on": true,
    "rarity": { "admin": "Exotic", "mod": "Rare", "member": "Common" }
  }
}

Canonical form, 351 bytes:

{"counter":7,"holder":"@[e-mail]","roles":{"on":true,"rarity":{"admin":"Exotic","member":"Common","mod":"Rare"}},"room":"room:nexus.app/naka-motor-club","signedAt":921600,"token":{"assets":[{"id":"4449436086e3cd58b73508aa498d886f62a5e88a049d3e27d49d2c9b90add05a_0","protocol":"1sat"}],"mode":"any","on":true},"ungateBurn":"100000","version":1}

SHA-256:

75e2c17e9f7b5d2a62ce5a6c3dbe8461b64c69c4eda226a69755e7794ba50a17

Ordering

A manifest with a renounce condition naming @[e-mail] and a holding condition requiring an asset, evaluated against a reader who is both renounced and holds nothing. Section 3.1 fixes which failure is reported:

{ "outcome": "fails", "condition": "renounce" }

Not token. Both conditions fail; the order decides, and an implementation reporting the holding has an iteration-order bug that will show up as two clients giving a reader different reasons.

Decimal comparison

A minimum of "0.3" against a holder of "0.1" plus "0.2". Compared as decimals the holder meets it exactly; compared as IEEE-754 doubles the sum is 0.30000000000000004 and the holder appears to exceed it. Both admit here, so the bug is invisible — which is why the vector below is the one that matters.

A minimum of "0.3" against a holder of "0.29999999999999998". As decimals this fails. As doubles it is indistinguishable from 0.3 and passes. An implementation admitting this reader is not conforming, and section 2.1's decimal rule exists for exactly this case.

Third-party disclosure

The same failing verdict, computed for the reader themselves and for anybody else:

{ "outcome": "fails", "condition": "token", "index": 0, "shortfall": { "held": "12.32", "required": "21.8" } }
{ "outcome": "fails", "condition": "token", "index": 0 }

An implementation emitting the first form in a roster, a picker, a preview or an export has leaked a balance, and section 3.3 forbids it on every surface rather than only the visible ones.

Appendix A: Worked Examples

A.1 A rarity-gated room

{
  "version": 1,
  "counter": 7,
  "room": "room:nexus.app/naka-motor-club",
  "holder": "@[e-mail]",
  "signedAt": 921600,
  "ungateBurn": "100000",
  "token": {
    "on": true,
    "mode": "any",
    "assets": [
      {
        "protocol": "1sat",
        "id": "4449436086e3cd58b73508aa498d886f62a5e88a049d3e27d49d2c9b90add05a_0"
      }
    ]
  },
  "roles": {
    "on": true,
    "rarity": { "admin": "Exotic", "mod": "Rare", "member": "Common" }
  }
}

Signed by @[e-mail] over the RFC 8785 canonical form. The contract publishes 2,222 items in the six bands tabulated in section 7.3.

@randy@twetch holds item #1872, band Epic. No renounce, vouch or quorum condition is present, so the holding condition decides:

{ "outcome": "qualifies", "condition": "token", "index": 0 }

Epic is above Rare in the contract's order and below Exotic, so the role is mod. The client renders a badge; it does not render the band to other participants, a band being a quantity about a third party.

@lena@handcash holds nothing from the contract:

{ "outcome": "fails", "condition": "token", "index": 0 }

No shortfall — the condition is a holding rather than a threshold, so there is no quantity to fall short by. She is shown the room's existence, name and participant count, and told which requirement she does not meet.

If the client cannot reach an indexer for the contract:

{ "outcome": "indeterminate", "condition": "token", "index": 0 }

Contents are not rendered, and she is told the check could not be performed rather than that she failed it.

A.2 A fungible gate with a fee

{
  "version": 1,
  "counter": 2,
  "room": "room:nexus.app/holders",
  "holder": "@[e-mail]",
  "signedAt": 921740,
  "ungateBurn": "2500000",
  "token": {
    "on": true,
    "mode": "any",
    "assets": [{ "protocol": "bsv21", "id": "a19c...f3" }],
    "minimums": { "bsv21:a19c...f3": "500" },
    "shares": { "bsv21:a19c...f3": "21.8" }
  },
  "fee": {
    "on": true,
    "asset": { "protocol": "bsv21", "id": "a19c...f3" },
    "amount": "0.5",
    "period": "week",
    "to": "@[e-mail]"
  },
  "roles": {
    "on": true,
    "minimums": { "mod": "5000" },
    "shares": { "admin": "21.8" }
  }
}

The minimum is the door at 500 units; the share is the admin threshold, permitted only because a minimum is present. The fee is in the same asset, names its recipient, and its first week is paid as part of joining. The role map uses both vocabularies — mod by absolute amount, admin by share — which is the pairing section 7.3 recommends for a room larger than its concentration.

A reader holding 6,000 units of a 10,000,000 supply, paid up:

{ "outcome": "qualifies", "condition": "token", "index": 0 }

Their role is mod: 6,000 clears the 5,000 threshold, and 0.06% of supply does not clear 21.8%. Three weeks later, having stopped paying:

{ "outcome": "fails", "condition": "fee", "period": "2026-W34" }

The holding still passes and the fee does not. They are told directly and in full; the roster shows them lapsed without saying by how much. Nothing is deducted and nothing pursues them — the only consequence of not paying is that the room stops rendering.

References

• BRC-52: Identity Certificates

• BRC-65: Transaction Labels and List Actions

• BRC-169: Universal Handle Addressing and Resolution for the Metanet

• BRC-218: Chat-Native Command Grammar for the Metanet

• RFC 2119: Key words for use in RFCs to Indicate Requirement Levels

• RFC 8785: JSON Canonicalization Scheme (JCS)

• OASIS eXtensible Access Control Markup Language (XACML) Version 3.0

• Matthew 13:23, GNV