@serfab/cadre-core 0.9.0 → 0.11.0

package/dist/control-schema.js

@@ -14,26 +14,125 @@ declare schema CadreControl {
     -- A key that can authorize various control changes
     table OwnerKey (
         Key text primary key,
-        StampId text not null unique,   -- single-use authorization nonce (anti-replay)
-        constraint Authorized check (
-            -- Bootstrap: first owner key needs no existing authorization
-            (select count(1) from OwnerKey) <= 1
+        StampId text not null unique,   -- per-row authorization nonce, bound into the signed digests below.
+                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
+                                        -- permanently into Revocation (NotRevoked below), so the never-expiring
+                                        -- enrollment signature cannot resurrect a removed owner.
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert
+        -- naming a retired stamp: the approval that seated this row can never re-seat it after
+        -- removal. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
+        -- freed the stamp and the original never-expiring signature verified again. A
+        -- legitimate re-add mints a FRESH StampId and a fresh signature, so it is unaffected.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'OwnerKey' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'OwnerKey' and R.StampId = old.StampId and R.RowKey = old.Key)
+        ),
+        -- A party must never lose its last owner key: every other CadreControl table's
+        -- CHECK requires an OwnerKey row, so an owner-less control database can never
+        -- authorize anything again — emptying this table is a permanent denial of the
+        -- party's control plane. Deferred (subquery), so the count is the POST-delete count.
+        -- NOTE: this is a per-transaction check against locally visible rows. Two
+        -- partitioned nodes that concurrently remove different owners can each see a
+        -- survivor and still converge to zero; if partitioned rotation ever becomes a real
+        -- workflow, the floor needs a cross-node guard, not a local count.
+        constraint MinOneOwner check on delete (
+            (select count(1) from OwnerKey) >= 1
+        ),
+        -- Enrollment is insert + delete only; rotation is add-then-remove. No writer
+        -- updates an OwnerKey row, and a self-rotation branch would double as a sole-owner
+        -- takeover: a deferred post-image count is also true of an update that re-points
+        -- the only row at an attacker key. Mirrors Strand.Manager.NoUpdate.
+        constraint NoUpdate check on update (false),
+        -- NOTE: the domain tag scopes an approval to a table and an action, not to a PARTY. Two
+        -- parties that share an owner key would accept each other's approvals. Fine today (each
+        -- party has its own owner key); if shared-owner multi-party ever ships, bind a party
+        -- identity row into these digests.
+        constraint Authorized check on insert, delete (
+            -- Every authorizer is read from the PRE-transaction snapshot (committed.*):
+            -- this CHECK auto-defers to commit (it has a subquery), by which point the row
+            -- being inserted — and any sibling inserted alongside it — is live, so a plain
+            -- from-OwnerKey would let a row authorize itself, or two strangers seat each
+            -- other. committed.* excludes both, stating the rule directly: the authorizer
+            -- must have existed BEFORE this transaction.
 
-                -- Old owner authorizes by signing over THIS row (Key, StampId); single-use via unique StampId
-                or (old.Key is not null and old.Key = context.OwnerKey and verify(digest(new.Key, new.StampId), context.Signature, old.Key, 'ed25519'))
+            -- Every signed digest below (and in every other CadreControl table) leads with two
+            -- fixed literals — a 'CadreControl.<Table>' domain tag and an 'add'/'remove'/
+            -- 'vouch'/'publish' action tag (cadre-core control-authorization.ts) — so an
+            -- approval verifies ONLY against the one rule it was minted for. Without them,
+            -- e.g. a ValidationKey enrollment approval covered the identical bytes as an
+            -- OwnerKey enrollment: a narrow grant that doubled as full ownership.
 
-                -- or other owners authorize by signing over THIS row (Key, StampId); single-use via unique StampId
-                or exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(new.Key, new.StampId), context.Signature, A.Key, 'ed25519'))
+            -- Bootstrap: the FOUNDING transaction — one whose pre-transaction owner set is
+            -- empty — needs no authorization, and every row it inserts rides this branch
+            -- (whoever writes it already owns the party outright, so a co-founder row grants
+            -- nothing a single row would not). Gated on the PRE-transaction count, so a
+            -- same-transaction swap of the sole owner (delete the founder, insert the
+            -- attacker — post-image count still 1) cannot ride it.
+            (old.Key is null and (select count(1) from committed.OwnerKey) = 0)
+
+                -- or a pre-existing owner authorizes by signing over THIS row (Key, StampId)
+                or (old.Key is null and exists (select 1 from committed.OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.OwnerKey', 'add', new.Key, new.StampId), context.Signature, A.Key, 'ed25519')))
+
+                -- or a removal authorized by ANOTHER pre-existing owner over the DISTINCT
+                -- 'remove'-tagged digest bound to the stored row's StampId, so an enrollment
+                -- signature can never be replayed as a removal (cf. CadrePeer.AuthorizedDelete).
+                -- A.Key <> old.Key: an owner cannot sign its own removal (no self-resignation).
+                or (new.Key is null and exists (select 1 from committed.OwnerKey A where A.Key = context.OwnerKey and A.Key <> old.Key and verify(digest('CadreControl.OwnerKey', 'remove', old.Key, old.StampId), context.Signature, A.Key, 'ed25519')))
         )
     ) with context (OwnerKey text null, Signature text null);
 
     -- A key that can validate a strand formation disclosure
     table ValidationKey (
         Key text primary key,
-        StampId text not null unique,   -- single-use authorization nonce (anti-replay)
-        constraint Authorized check (
+        StampId text not null unique,   -- single-use authorization nonce (anti-replay).
+                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
+                                        -- permanently into Revocation (NotRevoked below), so the never-expiring
+                                        -- enrollment signature cannot resurrect a removed key.
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert naming
+        -- a retired stamp: the approval that seated this row can never re-seat it after removal.
+        -- Same rationale as OwnerKey.NotRevoked, stated in full there.
+        -- NOTE: this table gained a consumer — FormationUsage.Authorized reads it to gate redemption of
+        -- a ValidationUrl invite — so the convergence gap noted on Strand.StampId now has teeth here: on
+        -- a node that has not yet seen the tombstone, a replayed enrollment re-seats the key and it can
+        -- approve redemptions there until the Revocation row arrives. Still no per-request READ surface to
+        -- filter (the gate is a write-time CHECK), so there is nothing to add today; if one appears, filter
+        -- retired stamps there.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'ValidationKey' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'ValidationKey' and R.StampId = old.StampId and R.RowKey = old.Key)
+        ),
+        -- Enrollment is insert + delete only; rotation is add-then-remove. No writer in the repo
+        -- updates a ValidationKey row. Required because the AuthorizedInsert / AuthorizedDelete
+        -- pair below covers neither update — and a bare \`check\`, which is what this rule used to
+        -- be, covers insert+update but NOT delete. Mirrors OwnerKey.NoUpdate.
+        constraint NoUpdate check on update (false),
+        constraint AuthorizedInsert check on insert (
             -- Owners authorize by signing over THIS row (Key, StampId); single-use via unique StampId
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(new.Key, new.StampId), context.Signature, A.Key, 'ed25519'))
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.ValidationKey', 'add', new.Key, new.StampId), context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound to
+            -- the STORED row (Key, StampId), so an enrollment approval — which never expires — can
+            -- never be replayed as a removal. Same shape as CadrePeer.AuthorizedDelete.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.ValidationKey', 'remove', old.Key, old.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or REAP: a COMMITTED tombstone already retires this exact row incarnation, so a node
+                -- that was offline at removal time may delete the stale row locally with no owner key.
+                -- Why committed.* and why the stamp must be bound: stated in full on
+                -- CadrePeer.AuthorizedDelete.
+                or exists (select 1 from committed.Revocation R where R.TableName = 'ValidationKey' and R.RowKey = old.Key and R.StampId = old.StampId)
         )
     ) with context (OwnerKey text, Signature text);
 
@@ -43,15 +142,133 @@ declare schema CadreControl {
         Id text primary key,    -- UUID
         MemberPrivateKey text null unique,   -- Our private key as a member of this strand
         Type text, -- Types: 'o' = Open, 'c' = Closed -- Open can still control writes in the sApp, but only Closed controls reads
-        StampId text not null unique,   -- single-use authorization nonce (anti-replay)
-        constraint Authorized check (
+        StampId text not null unique,   -- single-use authorization nonce (anti-replay).
+                                        -- \`unique\` holds over LIVE rows only; a removed row's stamp is retired
+                                        -- permanently into Revocation (NotRevoked below).
+        -- NOTE: NotRevoked is a per-transaction check against LOCALLY VISIBLE rows, so a node that
+        -- has not yet converged on the Revocation row can still accept a replayed add and end up
+        -- holding the resurrected strand alongside its tombstone. CadrePeer has a read-side
+        -- mitigation for this class (ControlDatabase.queryCadrePeers drops rows whose stamp is
+        -- retired, so every membership reader inherits it); Strand and ValidationKey deliberately
+        -- do NOT, because neither has a
+        -- per-request authorization surface today. If one ever gains one, filter it there.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'Strand' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey. That is what makes
+        -- the consent branch of AuthorizedInsert below trustworthy: a removal cannot file a
+        -- tombstone that omits or misnames the id it retires.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'Strand' and R.StampId = old.StampId and R.RowKey = old.Id)
+        ),
+        -- Strand rows are insert + delete only. Required: the consent branch of AuthorizedInsert
+        -- below authorizes by the EXISTENCE of a FormationUsage row naming (new.Id, new.StampId)
+        -- and carries no signature, so while this rule was a bare \`check\` (insert+update) it also
+        -- said "anyone may REWRITE any consent-formed strand, unsigned" — flipping Type to 'o' and
+        -- nulling MemberPrivateKey destroys the party's own membership key for that network in place.
+        -- Mirrors OwnerKey.NoUpdate / FormationInvite.Immutable.
+        constraint NoUpdate check on update (false),
+        constraint AuthorizedInsert check on insert (
             -- Authorized by an owner signing over THIS row (Id, Type, MemberPrivateKey, StampId); single-use via unique StampId
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(new.Id, new.Type, coalesce(new.MemberPrivateKey, ''), new.StampId), context.Signature, A.Key, 'ed25519'))
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Strand', 'add', new.Id, new.Type, coalesce(new.MemberPrivateKey, ''), new.StampId), context.Signature, A.Key, 'ed25519'))
 
-                -- or authorized by a cadre peer who has received a valid formation invitation.
-                -- That path has no signed writer yet; when one is built it must still supply a
-                -- fresh, unique StampId to satisfy the not-null/unique anti-replay column.
-                or exists (select 1 from FormationUsage FU where FU.StrandId = new.Id)
+                -- or authorized WITHOUT a signature by a redemption record naming THIS EXACT ROW: a
+                -- FormationUsage row carrying both this strand's Id and its one-off StampId
+                -- (control-database.ts:redeemInvitation writes the pair in one transaction; both
+                -- CHECKs defer, so each sees the other's row at commit).
+                --
+                -- Matching the STAMP, not the id alone, is what makes a removal stick. FormationUsage
+                -- is append-only, so a redemption record outlives the strand it formed forever; keyed
+                -- on the id alone it re-authorized ANY later insert of that id, so after a legitimate
+                -- owner-signed, tombstoned removal any writer could re-seat the strand unsigned with a
+                -- fresh StampId (sidestepping NotRevoked, which retires only the removed row's stamp)
+                -- and an ATTACKER-CHOSEN MemberPrivateKey — the party's own secret for that network.
+                -- Bound to the stamp, the removal retires that stamp into Revocation and NotRevoked
+                -- closes this consent record's branch permanently.
+                --
+                -- Beyond the stamp match, the branch is deliberately NARROW — each clause closes one door:
+                --   * Type = 'o' / MemberPrivateKey null — a consent-seated strand looks exactly like
+                --     what the unbound redemption path writes (open, keyless). A closed strand carrying
+                --     a caller-chosen member key (the party's own read-gating secret for that network)
+                --     has no legitimate producer. MemberKeyClosedOnly already implies the second clause
+                --     from the first today; both are stated so this rule does not silently depend on
+                --     another constraint staying as it is.
+                --   * the inner FI.StrandId is null — only an UNBOUND invite may seat a strand at all.
+                --     A bound invite's host strand is owner-provisioned up front; letting the invite
+                --     consent-seat that id would allow an open, keyless downgrade of the real (possibly
+                --     closed, key-bearing) host row on a node where it has not converged yet. The bound
+                --     path records usage only (resolveStrand reports an absent host as missing and the
+                --     formation manager rejects cleanly).
+                --   * the not-exists over OTHER stamps — a strand id may be consent-seated once, EVER.
+                --     FormationUsage is append-only, so the first redemption's record survives a later
+                --     owner-signed removal and permanently forecloses a second consent-seating of the
+                --     id (a spare use of the same token minted a new stamp and rode this branch to
+                --     re-seat the id with an attacker-chosen row). Re-joining a removed id is
+                --     owner-gated: the owner re-seats it signed (fresh stamp, fresh signature) and
+                --     issues a BOUND invite the returning party records consent against — the id is
+                --     not blacklisted, only its unsigned re-seat is. This cannot be weaponised to
+                --     pre-block a legitimate id: StrandExists refuses a usage row naming a strand that
+                --     does not exist, so no usage row can be pre-planted for an unseated id — and ids
+                --     are 128 random bytes anyway.
+                --   * the not-exists over Revocation — a strand id may be consent-seated once EVER
+                --     and never after ANY removal of that id, however it was seated. The usage-row
+                --     rule above binds only ids that ever carried a consent record; an id seated
+                --     purely owner-signed (insertStrand, no usage row) leaves nothing behind on
+                --     removal, so its removal needs its own trace. Every removal files a Revocation
+                --     row naming the removed row's key (RowKey), and this clause refuses any id
+                --     that has ever been tombstoned. RevocationRecorded above makes that trace
+                --     mandatory AND correctly named, so no removal can slip past this clause. The
+                --     usage-row clause is arguably subsumed by this one (a usage row implies the
+                --     strand row existed, and its removal must file a tombstone), but it reaches
+                --     the same conclusion without depending on Revocation at all; both are stated,
+                --     per the style note above. The owner-signed branch is deliberately unaffected,
+                --     so re-join stays owner-gated exactly as described.
+                --     What is NOT schema-verified is a STANDALONE tombstone (one with no
+                --     accompanying delete — see Revocation.Authorized): an owner can file one
+                --     naming an id that never existed and thereby permanently foreclose
+                --     consent-seating of that id — owner-only, the owner already controls invite
+                --     issuance, and unbound ids are 128 random bytes minted at redemption, so no
+                --     escalation (same reasoning as the pre-plant note above).
+                --     NOTE: like NotRevoked above, this is a write-time check against LOCALLY
+                --     VISIBLE rows — a node that has not yet converged on the Revocation row still
+                --     accepts the re-seat. Fails in the safe direction: the tombstone wins after
+                --     merge for the STAMP, and the resurrected row coexists with it (same class as
+                --     the StampId note above).
+                or (
+                    new.Type = 'o'
+                    and new.MemberPrivateKey is null
+                    and exists (
+                        select 1 from FormationUsage FU
+                            where FU.StrandId = new.Id
+                                and FU.StrandStampId = new.StampId
+                                and exists (select 1 from FormationInvite FI where FI.Token = FU.Token and FI.StrandId is null)
+                    )
+                    and not exists (
+                        select 1 from FormationUsage FU2
+                            where FU2.StrandId = new.Id and FU2.StrandStampId <> new.StampId
+                    )
+                    and not exists (
+                        select 1 from Revocation R
+                            where R.TableName = 'Strand' and R.RowKey = new.Id
+                    )
+                )
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound to
+            -- the STORED row (Id, StampId), so the add approval — which never expires — can never be
+            -- replayed as a removal. Note the consent branch above is deliberately NOT mirrored
+            -- here: an invitation authorizes forming a strand, never destroying one.
+            --
+            -- DELIBERATELY no REAP branch (cf. CadrePeer.AuthorizedDelete): this row carries
+            -- MemberPrivateKey — the party's own membership secret for that network, stored nowhere
+            -- else — so this is the one guarded delete whose effect is unrecoverable, and a stale
+            -- row is already inert for the purpose a tombstone serves (the consent branch of
+            -- AuthorizedInsert above refuses any id ever tombstoned). Do not "fix" the asymmetry;
+            -- tickets/backlog/debt-strand-tombstone-reap.md owns any future change.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Strand', 'remove', old.Id, old.StampId), context.Signature, A.Key, 'ed25519'))
         ),
         constraint MemberKeyClosedOnly check (
             -- An open strand ('o') has no membership gate, so it must not carry a
@@ -70,15 +287,34 @@ declare schema CadreControl {
         Multiaddr text,                 -- comma-joined current addrs (signaling / p2p-circuit first)
         UpdatedAt int null,             -- epoch ms; strictly increases per self-update (replay/rollback guard)
         Sig text null,                  -- ed25519 self-signature over the signed payload (base64url); null until self-published
-        StampId text not null unique,    -- single-use authorization nonce (anti-replay), bound into the voucher/remove digests; rotates on (re)insert
+        StampId text not null unique,    -- per-row authorization nonce, bound into the voucher/remove digests; rotates on
+                                         -- (re)insert. A removed row's stamp is retired permanently into Revocation
+                                         -- (NotRevoked below), so a captured admission approval cannot re-seat a removed peer.
         VouchOwner text null,        -- ed25519 (base64url) owner key that vouched this membership (== insert context.OwnerKey)
-        VouchSig text null,              -- that owner's signature over digest(PeerId, StampId) (== insert context.Signature). A reader checks VouchOwner against its NODE-LOCAL trusted-owner anchor (not this replicated table, which a self-owner can pollute) to decide authorized membership.
+        VouchSig text null,              -- that owner's signature over the 'vouch'-tagged digest below (== insert context.Signature). A reader checks VouchOwner against its NODE-LOCAL trusted-owner anchor (not this replicated table, which a self-owner can pollute) to decide authorized membership. The domain/action tags keep this STORED, REPLICATED signature useless against every other rule (pre-tag it satisfied OwnerKey/ValidationKey inserts for Key = PeerId).
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert
+        -- naming a retired stamp: the approval that seated this row can never re-seat it after
+        -- removal. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
+        -- freed the stamp and the original never-expiring signature verified again. A
+        -- legitimate re-add mints a FRESH StampId and a fresh signature, so it is unaffected.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'CadrePeer' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'CadrePeer' and R.StampId = old.StampId and R.RowKey = old.PeerId)
+        ),
         constraint AuthorizedInsert check on insert (
             -- Authorized by an owner key, which vouches both membership and the
             -- PublicKey<->PeerId binding (cadre-core derives PublicKey from PeerId before insert).
             -- The digest binds PeerId + the single-use StampId nonce (two TEXT fields),
-            -- matching cadre-core peer-authorization.ts:cadrePeerVoucherDigest.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
+            -- matching cadre-core peer-authorization.ts:cadrePeerVoucherDigest. The same
+            -- 'vouch'-tagged digest is DELIBERATELY shared with the owner branch of
+            -- AuthorizedUpdate below: both mean "this owner vouches this membership row".
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'vouch', new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
             -- Persist the vouching (owner, signature) onto the row so a reader can later
             -- re-check VouchOwner against its node-local anchor. The stored pair MUST equal
             -- the pair the verify above validated, so a writer cannot store a voucher it did
@@ -87,11 +323,34 @@ declare schema CadreControl {
             and new.VouchSig = context.Signature
         ),
         constraint AuthorizedDelete check on delete (
-            -- Delete is authorized by a signature over a DISTINCT 'remove'-scoped digest bound
+            -- Delete is authorized by a signature over the DISTINCT 'remove'-tagged digest bound
             -- to the row's StampId (cadre-core peer-authorization.ts:cadrePeerRemoveDigest), so
-            -- the stored voucher (a signature over digest(PeerId, StampId)) can NEVER be replayed
-            -- to authorize a delete. The remove signature rides in context and is never stored.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(old.PeerId, old.StampId, 'remove'), context.Signature, A.Key, 'ed25519'))
+            -- the stored voucher (a signature over the 'vouch'-tagged digest) can NEVER be
+            -- replayed to authorize a delete. The remove signature rides in context and is never stored.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'remove', old.PeerId, old.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or REAP: this node already holds a COMMITTED tombstone retiring THIS EXACT row
+                -- incarnation, so the party owner has already authorized this row's removal and this
+                -- node is merely catching up. That is what lets a node which was offline at
+                -- revocation time delete the stale row locally, with no owner private key
+                -- (control-database.ts:reapRevokedRow). Same shape as the consent branch of
+                -- Strand.AuthorizedInsert: authorization by the EXISTENCE of a row rather than by a
+                -- signature — and that row is itself owner-signed (Revocation.Authorized), so this
+                -- widens WHO may execute a removal, never WHO may decide one. RevocationRecorded is
+                -- satisfied by the same committed tombstone, so a reap files no second one.
+                --
+                -- committed.Revocation, NOT Revocation — and the stamp clause — are both load-bearing:
+                --   * committed.* : this CHECK defers to commit (it has a subquery), by which point a
+                --     tombstone written in the SAME transaction is live. Reading plain Revocation
+                --     would therefore let deleteGuardedRow's own sibling tombstone satisfy this
+                --     branch, making the 'remove'-tagged delete signature above dead weight and
+                --     collapsing two domain-separated approvals into one. committed.* states the rule
+                --     exactly: the tombstone must have existed BEFORE this transaction.
+                --   * R.StampId = old.StampId : binds the ROW INCARNATION, not the name. One name may
+                --     legitimately carry several tombstones over its life (seat -> delete -> owner
+                --     re-seat -> delete). Without this clause a tombstone from a PREVIOUS incarnation
+                --     would authorize deleting the CURRENT row, which the owner never removed.
+                or exists (select 1 from committed.Revocation R where R.TableName = 'CadrePeer' and R.RowKey = old.PeerId and R.StampId = old.StampId)
         ),
         constraint AuthorizedUpdate check on update (
             -- Peer self-updates its own addrs + freshness, signing with its OWN ed25519 key
@@ -107,13 +366,19 @@ declare schema CadreControl {
                 and new.VouchSig = old.VouchSig
                 and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
                 and verify(
-                        digest(new.PeerId || '|' || new.Multiaddr || '|' || cast(new.UpdatedAt as text)),
+                        digest('CadreControl.CadrePeer', 'publish', new.PeerId, new.Multiaddr, cast(new.UpdatedAt as text)),
                         new.Sig, new.PublicKey, 'ed25519')
             )
                 -- or an owner re-authorizes (rotation / correction): re-vouches the row over
                 -- its current StampId, so the stored voucher is re-bound to the re-authorizing owner.
+                -- StampId is immutable here too: an update that rotated it would leave the OLD
+                -- stamp live-free and untombstoned (RevocationRecorded only retires the stamp a
+                -- delete carries), so the original admission approval — which is stored on the
+                -- replicated row as VouchSig — would resurrect the peer after a later removal.
+                -- Retiring a stamp is delete + Revocation row, never an update.
                 or (
-                    exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
+                    new.StampId = old.StampId
+                    and exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.CadrePeer', 'vouch', new.PeerId, new.StampId), context.Signature, A.Key, 'ed25519'))
                     and new.VouchOwner = context.OwnerKey
                     and new.VouchSig = context.Signature
                 )
@@ -132,26 +397,86 @@ declare schema CadreControl {
         Token text not null,            -- opaque platform device/registration token
         UpdatedAt int null,             -- epoch ms; strictly increases per self-update (replay guard)
         Sig text null,                  -- ed25519 self-sig over (PeerId|Platform|Token|UpdatedAt)
-        constraint AuthorizedInsert check on insert, delete (
+        StampId text not null unique,    -- single-use authorization nonce, bound into the add/remove digests;
+                                         -- rotates on (re)insert. A cleared token's stamp is retired permanently
+                                         -- into Revocation (NotRevoked below), so the approval that published a
+                                         -- token cannot re-seat it after the owner cleared it (logout).
+        -- A removed row's StampId is retired into Revocation, and this refuses any insert
+        -- naming a retired stamp: the approval that seated this row can never re-seat it after
+        -- the clear. \`unique\` alone did not do this — it only holds over LIVE rows, so a delete
+        -- freed the stamp and the original never-expiring signature verified again. A legitimate
+        -- re-register mints a FRESH StampId and a fresh signature, so it is unaffected. This
+        -- matters more here than the stored-approval case (CadrePeer.VouchSig): a resurrected
+        -- push token has NO freshness ceiling to retire it — cadre-node.ts:resolveDeviceToken
+        -- defaults maxAgeMs to infinity by design — so retirement is the only thing that sticks.
+        constraint NotRevoked check on insert (
+            not exists (select 1 from Revocation R where R.TableName = 'DeviceToken' and R.StampId = new.StampId)
+        ),
+        -- Retirement is MANDATORY: a delete must carry the matching Revocation row in the same
+        -- transaction, or the stamp would free up again. Deferred (subquery), so the sibling
+        -- insert is visible at commit regardless of statement order. The tombstone must also
+        -- name the removed ROW, not just its stamp — see Revocation.RowKey.
+        constraint RevocationRecorded check on delete (
+            exists (select 1 from Revocation R where R.TableName = 'DeviceToken' and R.StampId = old.StampId and R.RowKey = old.PeerId)
+        ),
+        constraint AuthorizedInsert check on insert (
             -- Authorized by an owner key (membership vouch), exactly like CadrePeer.
-            -- The single-field digest frames the base58btc PeerId as TEXT.
-            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(coalesce(new.PeerId, old.PeerId)), context.Signature, A.Key, 'ed25519'))
+            -- The digest binds the WHOLE row behind the domain/action tags — every column,
+            -- with the nullable UpdatedAt/Sig signing as '' when absent (the shape
+            -- FormationInvite and Strand already use) — so a replayed approval can only ever
+            -- reproduce the row it approved, never one carrying attacker-chosen
+            -- Platform/Token/UpdatedAt; NotRevoked above then refuses even that exact row
+            -- once it has been cleared. The DISTINCT 'remove'-tagged digest below keeps a
+            -- captured insert approval from doubling as a delete (and vice versa).
+            -- Mirrors cadre-core peer-authorization.ts:deviceTokenAddDigest.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
+                digest(
+                    'CadreControl.DeviceToken', 'add',
+                    new.PeerId,
+                    new.Platform,
+                    new.Token,
+                    coalesce(cast(new.UpdatedAt as text), ''),
+                    coalesce(new.Sig, ''),
+                    new.StampId
+                ),
+                context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint AuthorizedDelete check on delete (
+            -- Bound to the STORED row's (PeerId, StampId) — cadre-core
+            -- peer-authorization.ts:deviceTokenRemoveDigest — so the never-expiring insert
+            -- approval can never be replayed as a clear, and a captured clear approval is
+            -- dead once the stamp it names is retired.
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.DeviceToken', 'remove', old.PeerId, old.StampId), context.Signature, A.Key, 'ed25519'))
+
+                -- or REAP: a COMMITTED tombstone already retires this exact row incarnation, so a node
+                -- that was offline at removal time may delete the stale row locally with no owner key.
+                -- Why committed.* and why the stamp must be bound: stated in full on
+                -- CadrePeer.AuthorizedDelete.
+                or exists (select 1 from committed.Revocation R where R.TableName = 'DeviceToken' and R.RowKey = old.PeerId and R.StampId = old.StampId)
         ),
         constraint AuthorizedUpdate check on update (
             -- Peer self-updates its own token, signing with its OWN ed25519 key (the key
-            -- behind PeerId). PeerId is immutable, UpdatedAt must strictly increase (replay
-            -- guard), and Sig is verified against the stored CadrePeer.PublicKey over the
-            -- signed payload (cadre-core device-token.ts:deviceTokenSignedPayload). Platform
-            -- and Token may change on self-update (platform switch / reinstall / rotation).
-            (
-                new.PeerId = old.PeerId
-                and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
-                and exists (select 1 from CadrePeer P where P.PeerId = new.PeerId and verify(
-                        digest(new.PeerId || '|' || new.Platform || '|' || new.Token || '|' || cast(new.UpdatedAt as text)),
-                        new.Sig, P.PublicKey, 'ed25519'))
-            )
-                -- or an owner re-authorizes (rotation / correction)
-                or exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest(new.PeerId), context.Signature, A.Key, 'ed25519'))
+            -- behind PeerId). PeerId and StampId are immutable, UpdatedAt must strictly
+            -- increase (replay guard), and Sig is verified against the stored
+            -- CadrePeer.PublicKey over the signed payload (cadre-core
+            -- device-token.ts:deviceTokenSignedPayload). Platform and Token may change on
+            -- self-update (platform switch / reinstall / rotation).
+            -- StampId is immutable for the reason CadrePeer spells out: an update that
+            -- rotated it would leave the OLD stamp live-free and untombstoned, so retiring a
+            -- stamp stays delete + Revocation row, never an update.
+            -- This is the ONLY branch: there is deliberately NO owner re-touch. The branch
+            -- that used to sit beside it verified an owner signature over the peer id alone
+            -- and sat OUTSIDE the monotonicity requirement, so one captured owner approval
+            -- rewrote Platform/Token and rolled UpdatedAt BACKWARDS — and seating a
+            -- far-future UpdatedAt wedged the peer's own self-updates permanently. No writer
+            -- used it. An owner that must correct a row deletes it (retiring the stamp) and
+            -- inserts a fresh one, the same path it already takes for CadrePeer.
+            new.PeerId = old.PeerId
+            and new.StampId = old.StampId
+            and new.UpdatedAt > coalesce(old.UpdatedAt, 0)
+            and exists (select 1 from CadrePeer P where P.PeerId = new.PeerId and verify(
+                    digest('CadreControl.DeviceToken', 'publish', new.PeerId, new.Platform, new.Token, cast(new.UpdatedAt as text)),
+                    new.Sig, P.PublicKey, 'ed25519'))
         )
     ) with context (OwnerKey text null, Signature text);
 
@@ -164,59 +489,313 @@ declare schema CadreControl {
         ValidationUrl text null,   -- Web hook - send disclosure, IP address...
         StrandId text null,   -- Host strand this invite binds to (provision-then-record). Non-null => the responder records consent against this pre-existing strand; null => legacy responder-provisions path.
         StampId text not null unique,   -- single-use authorization nonce (anti-replay)
-        constraint AuthorizedAddOrRemove check on insert, delete (
+        constraint AuthorizedInsert check on insert (
             -- Authorized by an owner signing over THIS row
             -- (Token, sAppId, ExpiresAt, TotalUses, ValidationUrl, StrandId, StampId); single-use via unique StampId.
-            -- coalesce(new.F, old.F) binds the NEW row on insert and the OLD row on delete (cf. CadrePeer).
-            -- StrandId is a nullable bound field: it signs as '' when absent (cf. ValidationUrl).
+            -- Nullable bound fields (ExpiresAt/TotalUses/ValidationUrl/StrandId) sign as '' when absent.
+            -- The 'remove'-tagged AuthorizedDelete digest below is DISTINCT, so a captured
+            -- insert approval can never be replayed to revoke-then-reissue an invite (or vice versa).
             exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
                 digest(
-                    coalesce(new.Token, old.Token),
-                    coalesce(new.sAppId, old.sAppId),
-                    coalesce(cast(coalesce(new.ExpiresAt, old.ExpiresAt) as text), ''),
-                    coalesce(cast(coalesce(new.TotalUses, old.TotalUses) as text), ''),
-                    coalesce(coalesce(new.ValidationUrl, old.ValidationUrl), ''),
-                    coalesce(coalesce(new.StrandId, old.StrandId), ''),
-                    coalesce(new.StampId, old.StampId)
+                    'CadreControl.FormationInvite', 'add',
+                    new.Token,
+                    new.sAppId,
+                    coalesce(cast(new.ExpiresAt as text), ''),
+                    coalesce(cast(new.TotalUses as text), ''),
+                    coalesce(new.ValidationUrl, ''),
+                    coalesce(new.StrandId, ''),
+                    new.StampId
+                ),
+                context.Signature, A.Key, 'ed25519'))
+        ),
+        constraint AuthorizedDelete check on delete (
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(
+                digest(
+                    'CadreControl.FormationInvite', 'remove',
+                    old.Token,
+                    old.sAppId,
+                    coalesce(cast(old.ExpiresAt as text), ''),
+                    coalesce(cast(old.TotalUses as text), ''),
+                    coalesce(old.ValidationUrl, ''),
+                    coalesce(old.StrandId, ''),
+                    old.StampId
                 ),
                 context.Signature, A.Key, 'ed25519'))
         ),
         -- Invites are insert/delete only: forbid in-place mutation so the row-bound
-        -- AuthorizedAddOrRemove signature cannot be sidestepped by updating consent
+        -- AuthorizedInsert signature cannot be sidestepped by updating consent
         -- parameters (TotalUses/ExpiresAt/...) after a legitimate insert. A bare check
-        -- defaults to insert+update; the check on insert, delete above excludes update,
+        -- defaults to insert+update; the checks on insert / on delete above exclude update,
         -- so this guard is required. Mirrors FormationUsage.InsertOnly.
         constraint Immutable check on update (false)
     ) with context (OwnerKey text, Signature text);
 
     table FormationUsage (
-        Token text,
-        UseNumber int,
+        Token text not null,            -- the FormationInvite this acceptance redeems. Stated explicitly because
+                                        -- Token is no longer a primary-key prefix; Authorized below would refuse a
+                                        -- null anyway (null = null is never true, so its FormationInvite
+                                        -- exists-clause cannot match), but the column carries the invariant rather
+                                        -- than leaving it to a CHECK.
+        UsageStampId text not null,     -- single-use nonce for THIS redemption, and this table's PRIMARY KEY.
+                                        -- The JOINING peer mints it and sends it in its contact message, having
+                                        -- signed it into its own 'consent' digest (PeerConsented below); the
+                                        -- responder inserts that same value and asks the approver about it, so it
+                                        -- is bound into the 'vouch' digest below too and one sign-off is spendable
+                                        -- exactly once. Neither side can swap it: a substituted nonce fails the
+                                        -- joiner's consent signature.
+                                        -- As the row key, a verbatim replay of an approval collides on the
+                                        -- primary key locally instead of on a column \`unique\`. Unlike every other
+                                        -- StampId in this schema, this table is append-only (InsertOnly below),
+                                        -- so the nonce is never freed by a delete: the key alone makes it
+                                        -- permanent and there is deliberately NO NotRevoked / RevocationRecorded
+                                        -- pair here — do not go looking for the missing one.
+                                        -- NOTE: the key is evaluated against LOCALLY VISIBLE rows, so two nodes
+                                        -- that have not yet converged could each admit the same nonce and both
+                                        -- rows survive the merge. Same class as the NotRevoked convergence notes
+                                        -- on OwnerKey / Strand / ValidationKey; the digest binding still holds on
+                                        -- both nodes, so the outcome is a duplicated audit row, never a join
+                                        -- nobody approved.
+        PeerKey text not null,          -- the joining peer's own ed25519 public key (base64url, 32 bytes), bound
+                                        -- into BOTH the approver's 'vouch' digest and the joiner's 'consent'
+                                        -- digest below, so an approval cannot be re-filed under a different
+                                        -- joiner's name and the named joiner provably agreed (PeerConsented).
+                                        -- The key IS the joiner's identity — its libp2p peer id is derivable
+                                        -- (identity multihash of these bytes), never stored here.
+        PeerSig text not null,          -- the joining peer's signature over the 'consent' digest — see
+                                        -- PeerConsented below for what it proves and why it is stored on the row.
         Disclosure text,
         StrandId text,
-        primary key (Token, UseNumber),
+        StrandStampId text not null,   -- the Strand.StampId this consent record authorizes. Consent is
+                                       -- bound to ONE strand ROW, not to a strand id forever — see
+                                       -- Strand.AuthorizedInsert's consent branch for why. NOT unique:
+                                       -- in the bound (provision-then-record) path several invitees
+                                       -- each write a usage row against the SAME host strand, so many
+                                       -- usage rows legitimately share one stamp.
+        primary key (UsageStampId),
         constraint InsertOnly check on update, delete (false),
-        constraint Monotonic check (
-            -- Read the PRE-transaction snapshot (committed.*): this CHECK auto-defers
-            -- to commit (it has a subquery), by which point the row being inserted is
-            -- live, so a plain from-FormationUsage would count this row itself and make
-            -- UseNumber = max+1 unsatisfiable. committed.* excludes the in-flight row,
-            -- giving sequential 1,2,3... per token (cross-transaction; concurrent
-            -- redemptions of the same token collide on the (Token, UseNumber) PK).
-            new.UseNumber = coalesce((select max(UseNumber) from committed.FormationUsage U where U.Token = new.Token), 0) + 1
-        ),
         constraint Authorized check on insert (
             -- Satisfies an invitation
             exists (
                 select 1 from FormationInvite FI
                     where FI.Token = new.Token
-                        and (FI.TotalUses is null or FI.TotalUses >= new.UseNumber)
+                        -- The use cap is COUNTED against the pre-transaction snapshot, never
+                        -- sequenced. This CHECK auto-defers to commit (it has a subquery), by
+                        -- which point the in-flight row is live; committed.* is what excludes
+                        -- it, so a sequentially exhausted invite — every seat already committed
+                        -- on this node — is still refused here. What is deliberately NOT
+                        -- refused: concurrent redeemers on separate nodes (or nodes that have
+                        -- not yet converged) each count the same committed snapshot and both
+                        -- land, over-admitting by at most the number of concurrent redeemers.
+                        -- Both rows survive in this append-only record, so the overage is
+                        -- auditable, and removal is owner-gated (member removal + Revocation).
+                        -- Same class as the convergence note on UsageStampId above.
+                        -- One rule for FUTURE writers: two FormationUsage rows for one token
+                        -- inserted in ONE transaction each read the same committed count, so
+                        -- they can jointly exceed the cap. No writer in this repo does that; it
+                        -- is a constraint on new writers, not a case to engineer for.
+                        -- Do not "fix" this into a per-token sequence number to restore a
+                        -- strict cap — that trade was weighed and rejected (2026-08-04): a
+                        -- fought-over sequence key turns a concurrent redemption into a silent,
+                        -- unrecoverable loss of a consented join, which is strictly worse than
+                        -- a visible, reversible over-admission.
+                        and (FI.TotalUses is null or FI.TotalUses > (select count(1) from committed.FormationUsage U where U.Token = new.Token))
                         and (FI.ExpiresAt is null or FI.ExpiresAt > context.Now)
-                        and (FI.ValidationUrl is null or verify(digest(new.Token || new.Disclosure), context.ValidationSignature, context.ValidationKey, 'ed25519'))
+                        -- An invite carrying a ValidationUrl demands a sign-off from a key the party
+                        -- ENROLLED in ValidationKey. The signature is verified against the STORED VK.Key,
+                        -- NOT against context.ValidationKey — that distinction is the whole point:
+                        -- context.ValidationKey is a plain insert parameter, so verifying against it asked
+                        -- only "did the redeemer sign its own disclosure with SOME key it holds?", which any
+                        -- redeemer answers by minting a throwaway keypair. context.ValidationKey survives
+                        -- purely to SELECT which enrolled row is being claimed; naming an enrolled key while
+                        -- signing with a different one fails the verify against VK.Key.
+                        --
+                        -- Deliberate: CHECKs run on write only, so removing a validation key later does NOT
+                        -- re-examine the FormationUsage rows it already approved. The sign-off was valid when
+                        -- given and the strand it authorized stays formed; removal narrows who may approve
+                        -- FUTURE redemptions, it is not a retroactive revocation of past ones.
+                        --
+                        -- What ONE sign-off buys: exactly ONE row. The digest covers
+                        -- (Token, UsageStampId, StrandId, PeerKey, Disclosure), so an approval is NOT
+                        -- transferable across invitations, redemptions, networks, joiners, or disclosure
+                        -- text. Replay is closed twice over, by two independent mechanisms: presenting an
+                        -- approval VERBATIM repeats its UsageStampId and is refused by this table's
+                        -- primary key; presenting it under any OTHER redemption changes a signed field
+                        -- and fails this verify.
+                        -- Every signed field is supplied by the redeeming side — nothing derived from
+                        -- the table's current state is bound — so no concurrent write can invalidate an
+                        -- approval between the sign-off and the row landing.
+                        -- Why StrandStampId is deliberately NOT bound: it names the strand ROW
+                        -- incarnation, which the unbound path (redeemInvitation) mints inside its own
+                        -- transaction, and it adds nothing on top of a strictly single-use approval —
+                        -- StrandId already pins WHICH network the approver approved joining.
+                        and (FI.ValidationUrl is null or exists (
+                            select 1 from ValidationKey VK
+                                where VK.Key = context.ValidationKey
+                                    and verify(digest('CadreControl.FormationUsage', 'vouch', new.Token, new.UsageStampId, new.StrandId, new.PeerKey, new.Disclosure), context.ValidationSignature, VK.Key, 'ed25519')))
+                        -- A bound invite (non-null StrandId) may only ever name its own host strand:
+                        -- without this, any holder of a bound token could record consent against an
+                        -- arbitrary strand id — annotating an unrelated strand, or (before
+                        -- Strand.AuthorizedInsert's consent branch was narrowed to unbound invites)
+                        -- consent-seating that id outright.
+                        -- NOTE: an UNBOUND invite is deliberately left free to name any strand, so a
+                        -- holder can spend a use appending a consent row to an unrelated existing
+                        -- strand. Harmless today (the row grants nothing, it only burns a use and
+                        -- forecloses that id's consent-seating, which is the safe direction); if
+                        -- unlimited-TotalUses invites ever become common, this is an append-only
+                        -- growth surface worth bounding.
+                        and (FI.StrandId is null or FI.StrandId = new.StrandId)
             )
         ),
-        constraint StrandExists check (exists (select 1 from Strand S where S.Id = new.StrandId)),
-    ) with context (PeerId text, PeerSignature text, Now datetime, ValidationKey text null, ValidationSignature text null);
+        -- Matched on the (id, stamp) PAIR, the same key Strand.AuthorizedInsert's consent branch
+        -- reads back: a usage row may only ever name a strand ROW that exists, so a consent record
+        -- can never be filed against a stamp of the writer's choosing and held in reserve to
+        -- re-seat the id after a removal.
+        constraint StrandExists check (exists (select 1 from Strand S where S.Id = new.StrandId and S.StampId = new.StrandStampId)),
+        -- The JOINING peer proves it consented to this redemption: PeerKey is its own ed25519
+        -- public key and PeerSig is its signature over the 'consent'-tagged digest below.
+        -- Unlike the approver's sign-off (context.ValidationSignature, checked against a STORED
+        -- ValidationKey row), the identity here IS the key, so there is no enrolled row to look
+        -- up and nothing for a writer to substitute: a forged joiner would need that joiner's
+        -- private key. Stored rather than passed in context so any later reader can re-check it
+        -- (verifyFormationConsent); the 'consent' action tag keeps this replicated signature
+        -- useless against every other rule in this schema (notably the approver's 'vouch'
+        -- digest over the same table).
+        -- NOTE: StrandId is deliberately NOT in this digest — the joiner cannot know it when it
+        -- signs (a bound invite's host strand arrives only in the result frame; an unbound
+        -- strand is responder-minted). The responder cannot substitute a strand anyway: bound
+        -- invites are pinned by Authorized's FI.StrandId check, unbound invites mint fresh.
+        constraint PeerConsented check on insert (
+            verify(digest('CadreControl.FormationUsage', 'consent',
+                          new.Token, new.UsageStampId, new.PeerKey, new.Disclosure),
+                   new.PeerSig, new.PeerKey, 'ed25519')
+        ),
+    -- Context here is only what the approver-side rules read: Now for expiry, and the
+    -- ValidationKey/ValidationSignature pair for the 'vouch' check in Authorized. The joiner's
+    -- signature is NOT context — it lives on the row (PeerSig, verified by PeerConsented above).
+    ) with context (Now datetime, ValidationKey text null, ValidationSignature text null);
+
+    -- Token is no longer a primary-key prefix (the key is the redemption nonce), so the
+    -- per-token filters — the cap count in Authorized above, and cadre-core's
+    -- countFormationUsage / isTokenUsed / hasOutstandingFormationInvite — get an index
+    -- rather than a table scan.
+    index FormationUsageByToken on FormationUsage (Token);
+
+    -- Append-only retirement record for the one-off StampId nonces of removed OwnerKey /
+    -- CadrePeer / ValidationKey / Strand rows. Without it a removal was undoable: the add
+    -- approval is a signature over
+    -- (row key, stamp) that never expires, and deleting the row freed the stamp, so anyone who
+    -- kept a copy of the approval could resurrect the row.
+    -- Each tombstone also records WHICH row was retired (RowKey below): the consent branch of
+    -- Strand.AuthorizedInsert reads it to refuse consent-seating any strand id that has ever
+    -- been removed, whichever way it was seated.
+    -- NOTE: the guarded tables' NotRevoked CHECK runs against locally visible rows, so a node
+    -- that has not yet converged on a Revocation row can still accept the replayed add, and the
+    -- resurrected row coexists with the tombstone after merge — same class as the MinOneOwner
+    -- note on OwnerKey. The read-side mitigation is ControlDatabase.queryCadrePeers, which
+    -- drops any CadrePeer row whose StampId appears here; every membership reader inherits it.
+    -- NOTE: append-only, so this table only ever grows. Every append is owner-signed
+    -- (Authorized below), so the growth surface is the owner keys, not every writer that can
+    -- reach the control database. Cadres are a handful of peers and owner rotation is rare, so
+    -- unbounded growth is fine today; revisit if either changes.
+    -- A tombstone committed while the node was alone is local-only (never broadcast); the
+    -- ReissuedAt counter below exists so an owner can re-write — and therefore re-broadcast —
+    -- such a tombstone once peers are reachable, without changing what it means.
+    table Revocation (
+        TableName text,             -- 'OwnerKey' | 'CadrePeer' | 'ValidationKey' | 'Strand' | 'DeviceToken' (confined by RowIsGone below)
+        RowKey text not null,       -- primary key of the removed row: OwnerKey.Key / ValidationKey.Key /
+                                    -- CadrePeer.PeerId / DeviceToken.PeerId / Strand.Id
+                                    -- Every guarded table's RevocationRecorded CHECK requires the
+                                    -- accompanying tombstone to carry the removed row's key here, so
+                                    -- a REMOVAL cannot file a misnamed tombstone. A tombstone with no
+                                    -- accompanying delete is not covered by that (see Authorized).
+        StampId text,               -- the retired nonce
+        -- Bumped by an owner-signed re-issue so a tombstone written while the node was alone
+        -- (committed local-only, never broadcast) can be re-written and therefore re-broadcast
+        -- on cohort growth. Carries NO semantics: nothing reads it, and retirement is decided
+        -- by the row's existence, not by this value.
+        ReissuedAt integer not null default 0,
+        -- Keyed on the stamp, not the RowKey: stamps are unique per row incarnation, and one
+        -- name may legitimately carry several tombstones over its life (seat -> delete ->
+        -- owner re-seat -> delete).
+        primary key (TableName, StampId),
+        -- Retirement is permanent: a tombstone may never be withdrawn.
+        constraint NoDelete check on delete (false),
+        -- Pinned at 0 on insert so an owner cannot seat a tombstone at a saturated counter and
+        -- thereby freeze its own later re-issues (ReissueOnly below). Deliberately NOT folded
+        -- into the Authorized digest: the value is fixed by this rule, so signing over it would
+        -- only widen the signed surface for no gain, and would invalidate every existing
+        -- insert-side digest.
+        constraint FreshTombstone check on insert (new.ReissuedAt = 0),
+        -- A re-issue may move NOTHING but the counter, and only upward. Without the identity
+        -- clause an "update" would be a way to re-point a tombstone at a different row,
+        -- restoring exactly the replay this table exists to stop.
+        constraint ReissueOnly check on update (
+            new.TableName = old.TableName and new.RowKey = old.RowKey
+                and new.StampId = old.StampId and new.ReissuedAt > old.ReissuedAt
+        ),
+        -- A stamp may only be retired once its row is actually gone. Deferred (subquery), so a
+        -- delete in the same transaction has already landed. Retiring a stamp that never
+        -- existed is permitted and harmless: a stamp carries 128 bits of CSPRNG output
+        -- (control-database.ts:generateStampId — 16 bytes of sha256(PeerId) followed by 16
+        -- random bytes), so a future legitimate one cannot be guessed and pre-planted.
+        -- Deliberately keyed on the STAMP only, not RowKey: checking "no live row named
+        -- new.RowKey" breaks under out-of-order convergence — a peer removed (tombstone names
+        -- it, stamp1) then re-admitted (stamp2) would leave a node that converges on the
+        -- re-add FIRST rejecting the stamp1 tombstone forever, never learning that stamp is
+        -- retired. The stamp-only form passes there (stamp1 is not live).
+        constraint RowIsGone check on insert (
+            (new.TableName = 'OwnerKey' and not exists (select 1 from OwnerKey K where K.StampId = new.StampId))
+                or (new.TableName = 'CadrePeer' and not exists (select 1 from CadrePeer P where P.StampId = new.StampId))
+                or (new.TableName = 'ValidationKey' and not exists (select 1 from ValidationKey V where V.StampId = new.StampId))
+                or (new.TableName = 'Strand' and not exists (select 1 from Strand S where S.StampId = new.StampId))
+                or (new.TableName = 'DeviceToken' and not exists (select 1 from DeviceToken D where D.StampId = new.StampId))
+        ),
+        -- Appending a tombstone is an OWNER action, like every other write in this schema.
+        -- Ungated, any writer that could reach the control database could retire a stamp:
+        -- filing one against a CadrePeer row not visible locally (RowIsGone reads LOCALLY
+        -- VISIBLE rows — see the convergence note above) evicted that peer party-wide AND
+        -- permanently blocked the owner's own later re-admission of it (NotRevoked), and
+        -- filing arbitrary stamps flooded a table whose rows never go away.
+        -- The digest binds the WHOLE row (TableName, RowKey, StampId); the 'CadreControl.Revocation'
+        -- domain tag keeps it disjoint from every other rule — including the
+        -- 'CadreControl.CadrePeer' 'remove' digest the same owner signs in the SAME
+        -- transaction for the delete this tombstone accompanies.
+        -- RowKey is not cross-checked HERE against the retired row: positively binding it (e.g.
+        -- requiring a committed.Strand row carrying the pair) would reject a tombstone re-issued
+        -- in a LATER transaction — which the delete-while-alone durability path
+        -- (docs/architecture.md) plans to do — and reject it outright on a node that never
+        -- converged on the removed row. The binding lives on the other side instead: each
+        -- guarded table's RevocationRecorded requires the tombstone accompanying a DELETE to
+        -- name that row's key, which the re-issue path never trips (it files no delete).
+        -- Residual: a STANDALONE tombstone — owner-signed, naming a stamp no live row holds —
+        -- is still accepted, so an owner can name an id that never existed and thereby
+        -- permanently foreclose CONSENT-seating of that id (Strand.AuthorizedInsert).
+        -- Owner-only, the owner already controls invite issuance, and unbound ids are 128
+        -- random bytes minted at redemption — no escalation (same reasoning as the pre-plant
+        -- note on RowIsGone).
+        -- Reads LIVE OwnerKey (like ValidationKey / Strand / CadrePeer / DeviceToken), not
+        -- committed.OwnerKey. The one difference that makes: a founding transaction on an
+        -- owner-less database could seat an owner key and file a tombstone in one go. An
+        -- owner-less control database is already a total loss, and a second transaction
+        -- achieves the same thing under committed.*, so consistency with the siblings is
+        -- worth more than the distinction — do not "tighten" this without a reason other
+        -- than that one.
+        -- RowIsGone and NoDelete are unchanged: they guard an owner retiring a stamp early
+        -- or withdrawing one later, which authorization does not cover.
+        constraint Authorized check on insert (
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey and verify(digest('CadreControl.Revocation', 'remove', new.TableName, new.RowKey, new.StampId), context.Signature, A.Key, 'ed25519'))
+        ),
+        -- A re-issue is an OWNER action, like the original append. Distinct 'reissue' action
+        -- tag, so an append approval can never be replayed as a re-issue and vice versa. The
+        -- digest adds ReissuedAt so a captured re-issue signature cannot bump the counter to
+        -- any other value. Reads LIVE OwnerKey, matching Authorized above.
+        constraint AuthorizedReissue check on update (
+            exists (select 1 from OwnerKey A where A.Key = context.OwnerKey
+                and verify(digest('CadreControl.Revocation', 'reissue',
+                                  new.TableName, new.RowKey, new.StampId, cast(new.ReissuedAt as text)),
+                           context.Signature, A.Key, 'ed25519'))
+        )
+    ) with context (OwnerKey text, Signature text);
 }
 
 apply schema CadreControl;`;