Coppice: Decentralized Asynchronous PQ E2EE Group Messaging

[CassOnMars]

Coppice

Post-quantum asynchronous group messaging with tree delivery and per-message forward secrecy

Version 0.4, editorial revision 1.

Protocol identifier: Coppice/4.

This specification describes a protocol for future development.
The protocol uses post-quantum key establishment without a classical hybrid.

Tree delivery is the selected design.
Each receiving node represents a fixed set of devices.
The devices in that set share independent, single-use receiving keys.
An author encrypts the new era state once.
The author then encrypts the entry key for selected nodes that cover all current members without overlap.

The service delivers the resulting ciphertexts directly to the devices.
Members do not forward messages through the tree.
An offline member can fetch its latest prepared entry without an online member.
The member does not need to process intermediate eras first.
These properties require the inventory and retention conditions in §9.

Direct delivery and shard delivery remain comparison workloads.
They are not chat profiles that devices can select automatically.
Tree delivery uses singleton leaves when larger nodes are unavailable.
Forward secrecy, offline reserves, history policy, and sender privacy are core requirements.

The design does not yet have a proof for its complete cryptographic composition or a final wire format.
The research model uses ideal cryptography, a trusted finality service, and an assumption of atomic erasure.
Its tagged encoding and v3 hash labels are research formats.
They are not formats for Coppice/4 interoperability.
The model implements the selected era-entry path.
Sections 13 and 14 identify the work that remains.

Changelog

This table separates protocol changes from editorial changes.
Dates for the earlier protocol revisions are not recorded here.

Revision	Type	Changes
0.4, editorial revision 1 — 2026-10-18	Editorial	Add this changelog. Revise the text toward ASD-STE100 language. Define technical terms. Keep the protocol identifier, algorithms, formulas, and measured values unchanged.
0.4	Protocol design	Select tree delivery and independent era entries. Define exact recipient covers and blinded roster proofs. Make tree delivery the default research simulation. Connect history grants to tree credentials.

Language and technical terms

This draft applies the writing principles of ASD-STE100 where practical.
Use short sentences, active voice, and one meaning for each technical term.
Give one instruction in each procedural sentence.
The editorial targets are 20 words for instructions and 25 words for descriptions.
Keep each paragraph on one topic, with no more than six sentences.

Protocol identifiers, formulas, source titles, and code retain their required forms.
Appendix B defines the technical nouns, technical verbs, and abbreviations used in this specification.

This draft does not claim verified ASD-STE100 conformance.
A complete review of the approved vocabulary and its permitted uses remains necessary.
In requirements, must means required and must not means prohibited.
The text states permissions explicitly.
The word can describes a capability or a possibility.

0. Architecture and guarantees

0.1 Three kinds of state

Coppice separates three operations:

1. Era entries establish authenticated membership and fresh live state.
   Membership changes and explicit group renewals use one ordered checkpoint history.
   Unchanged membership does not require a renewal only because time passed.
2. Entropy contributions distribute fresh randomness to a specified recipient configuration.
   Different producers can create and deliver contributions at the same time.
   Receipt of a contribution does not automatically change the group era.
3. Sender updates advance one sender's ratchet with an explicit set of contributions.
   Each sender orders its own updates.
   Different senders can use different contribution sets and update orders.

Each application message identifies its era, sender lane, sender update, and counter inside an encrypted envelope.
The receiver reconstructs the authenticated history for that sender.
The receiver must not select a group key from a clock round or a shortened contribution-set hash.

The receiving tree defines recipient sets.
It does not define a forwarding network or a signing authority.
Each device holds independent single-use keys for nodes that contain the device.
Each producer has assigned ticket pools.
Different producers use different tickets.

The author prepares the common entry and its wrappers.
Any service replica with the stored objects can deliver them later.
There is no permanent designated preparer or shared signing secret.
A replacement author needs inventory that was already assigned to that author.

The protocol uses three different trees:

Tree	Function
Receiving tree	Groups devices that share independent KEM tickets.
Sender-secret tree	Derives symmetric state for sender lanes and erases the ancestors of opened lanes.
Roster Merkle tree	Authenticates blinded membership records.

No tree supplies a retained master key for another tree.

0.2 Required properties

Property	Requirement
Asynchronous operation	Available dependencies permit messages and updates without a member quorum, acknowledgements, simultaneous connections, or a clock deadline. Fresh contributions require unused tickets. Inventory exhaustion defers the update without weaker delivery (§5.4).
Per-message forward secrecy	Devices erase consumed live message keys and their ancestors. Retained archive capabilities are outside this protection for archived content (§0.4).
Post-compromise recovery	Fresh contributions can recover sender lanes after replacement of compromised receiving capabilities. Recovery depends on events, not elapsed time alone.
Combined exposures	Later endpoint state must not recover a consumed recovery input or its ancestors. An earlier lane snapshot must not combine with later consumed state to decrypt the protected generation (§10.3).
Concurrent updates	Updates from different producers or senders do not conflict. Each update identifies its dependencies.
Offline replay	Members process stored control objects within retention and resource limits. No member needs to reconstruct erased secrets for another member.
Join secrecy and optional history	Admission supplies only current live state. A separate authorized history grant supplies the permitted archive range (§7.5).
Removal	After a finalized removal, informed honest senders use the new era and receiving capabilities that exclude the removed device.
Server confidentiality	Services hold no keys for messages, attachments, archives, or live state. This requirement applies to delivery, directory, archive, and transport services in every chat profile.
Concealed origin	Delivery requests expose no sender identity, author credential, author signature, or sender-account authentication. The existing transport hides source IP addresses (§11.2).
Bounded return	The latest prepared entry supplies current state without full historical replay. This requires cached identity, fresh finality, sufficient inventory, bounded discovery, and retained objects (§9). Current reception can still require a sender backlog.

0.3 Security boundaries

Group members can read the application plaintext for their authorized membership.
The receiving tree reduces delivery cost.
It does not protect plaintext from another authorized member.
Separate conversations need separate group secrets.

Infrastructure is not a group member or an authorized history custodian.
It stores and routes ciphertext.
It has no escrow key, archive root, or authority to create decryption grants.
Endpoints verify membership so that a directory cannot insert its own recipient key.
Coppice must prevent its application records from identifying the sender to the service (§11.2).

An attacker can record traffic, control delivery, withhold objects, replay objects, and present different directory views.
The attacker can also compromise devices.
The security model assumes that the attacker cannot break the selected primitives or recover correctly erased secrets.
Section 3 defines the trust required for membership authorization and consistency.
A compromised authorized recipient can disclose every message that it receives.

Forward secrecy depends on consumption at the compromised endpoint.
An offline recipient needs a retained capability to decrypt an unread message later.
Compromise of that recipient can expose its unread backlog.
A protocol cannot erase that capability and still guarantee unrestricted offline decryption through it.
Key erasure does not protect plaintext archives or application backups.

Safety must hold for any delivery delay.
Progress requires eventual delivery of dependencies and sufficient tickets for new contributions.
A membership change also requires its membership service to be available.
During a partition, a sender with a valid era can continue in that era.
The sender cannot enforce a removal that it has not received.
If a deployment requires fresh global membership before each send, it must block sends during such a partition.

0.4 Explicit chat profiles and history policy

An authenticated chat policy separately selects live protection, history access, and retention.
Group size must not change these selections automatically.
A policy change requires an authorized era boundary.
Members must be able to see the change.
The era's policy commitment binds the change to subsequent messages.
Reject an unknown profile without a downgrade.

Policy axis	Choices and guarantees
Live protection	FS uses the ratchet and consumption rules in this draft. A simpler rotating group-key profile is a future option. Its distribution, nonce, removal, and recovery rules must exist before selection.
History for new members	NONE, a bounded WINDOW, or ALL_RETAINED. These options control archive grants. They do not permit export of live ratchet state.
Archive retention	The policy states a message range or retention period. It also states whether history can remain indefinitely. Expiry cannot remove plaintext or keys that recipients already copied.
Service privacy	Every profile requires end-to-end encryption and encrypted author credentials. Submissions must not authenticate a sender account. History access does not weaken these requirements.

The initial profile is FS with NONE.
An archive-enabled profile deliberately retains a capability for archived content.
Compromise of that capability can expose the content after erasure of its live message keys.
Full-device forward secrecy does not cover those retained copies.
Archive keys must not derive live roots or future independent archive segments.
Group size and history policy never permit shared author-signing keys or service access to plaintext.

1. Primitives and canonical context

1.1 Initial suite

COPPICE4_NTRUHPS2048677_FALCON512_PADDED_SHAKE256_CHACHA20POLY1305

Role	Primitive	Encoding sizes in bytes
Recipient KEM	NTRU-HPS-2048-677, round-3 submission format	Public key: 930. Private key: 1234. Ciphertext: 930. Shared secret: 32.
Identity, control, publication, and content signatures	Falcon-512, padded signature format	Public key: 897. Private key: 1281. Signature: 666.
Hash and domain-separated derivation	SHAKE256	Default digest: 32.
AEAD	ChaCha20-Poly1305	Key: 32. Nonce: 12. Tag: 16.

Do not assume that Falcon submission formats are interchangeable with a future FN-DSA format.
A different algorithm or encoding requires a different suite identifier.
FIPS 202 standardizes SHAKE256.
The complete Coppice suite is not a FIPS-approved suite.
ChaCha20-Poly1305 has separate security assumptions.
Its security does not follow only from SHAKE256.

Each author uses an individual signature key that supports multiple signatures.
Never derive a signature private key from shared node state.
Falcon key generation does not need to be reproducible.
Generate receiving-node KEM key pairs with fresh randomness.
Distribute these keys in encrypted boxes (§5).
This avoids dependence on an unspecified seeded NTRU key generator.

The design excludes hybrid classical and post-quantum key establishment.
The design permits a separate post-quantum ML-KEM/ML-DSA suite if it preserves the state and deletion requirements.
Shared-matrix multi-recipient encryption requires a separate analyzed construction.
Do not apply that construction to standard ML-KEM ciphertexts as an assumed optimization.
Use independent randomness for every NTRU encapsulation slot.

1.2 Encoding and domain separation

All protocol encodings must be canonical.
Integers are unsigned and use big-endian encoding.
Counters, sequences, era numbers, and roster indices use 64 bits.
Each variable byte string starts with a u32 byte length.
Each list starts with a u32 element count, followed by canonical elements.
Sort maps by their encoded keys.

Before memory allocation, reject duplicate entries, noncanonical encodings, unsupported suites, and oversized objects.
Encode(x1, ..., xn) starts with a u32 argument count.
It then concatenates the canonical argument encodings, each with its length prefix.
Literal labels are ASCII bytes.
Each type used by a hash or signature must have one fixed wire encoding.

H(label, x1, ..., xn) =
    SHAKE256(Encode("Coppice/4 hash", label, x1, ..., xn), 32)

KDF(secret, label, context, length) =
    SHAKE256(Encode("Coppice/4 derive", suite_id, secret,
                    label, context, u32(length)), length)

Sign_i(type, body) = Falcon.Sign(ik_i.sk,
    Encode("Coppice/4 sign", suite_id, group_id, type, body))

Each object binds its suite, group, role, scope era, author, sequence, predecessor, and applicable recipient configuration.
The full 32-byte identifier is authoritative.
A transport can use a short cache hint only if a collision causes full-identifier retrieval and verification.
Never select state from the hint alone.

Object identifiers hash the canonical signed body without the signature bytes.
A new randomized signature over the same body does not create a second protocol event.
Conflicting bodies with the same author, era, role, and sequence are equivocation.

2. Devices, immutable cohorts, and private rosters

2.1 Device identity and independent receiving keys

Each device has an individual Falcon identity for each group.
device_id = H("device", group_id, ik.pk).
Do not copy a signing identity and its sending ratchet to another device.
Identity recovery requires authorization that is independent of a stolen device key.
If a device cannot establish that its state has not rolled back, it rejoins with a fresh identity.

Receiving tickets contain independent NTRU key pairs generated with fresh randomness.
No long-lived receiving key, master seed, or ancestor KEM key can regenerate consumed tickets.
After compromise, the random generator must incorporate fresh external entropy.
It must also prevent recovery of past random values from its current state.
Advancing an exposed deterministic generator does not restore secrecy.
Never use one key pair under multiple identifiers, nodes, producers, or purposes.

Each ticket descriptor binds these fields:

• Suite and group.
• Fixed node audience and its generation.
• Assigned producer and purpose.
• Pool nonce and ticket index.
• NTRU public key.

Separate ticket purposes apply to era entries, entropy within an era, and enrollment.
One ticket authorizes one immutable object from its producer.
A retry uses the exact bytes of that object.
It does not consume the ticket again.
Admission tickets and history-grant tickets have separate contexts.

Falcon authenticates individual authors.
It is not a forward-secure signature scheme.
The protocol does not claim protection against retrospective signature forgery after theft of an identity key.

2.2 Immutable receiving cohorts

A cohort contains an ordered set of credential identities and a random generation identifier.
Its complete binary tree has devices at the leaves.
Omit audiences that contain only padding.
Include each identical nonempty audience only once.
Each node has a commitment to its exact audience.

An authorized publisher belongs to the node's audience.
The node has separate ticket pools for eligible authors.
The publisher distributes receiving keys.
The publisher has no authority to sign as another member.

A member holds keys only for nodes that contain that member, including its singleton leaf.
Generate each key independently at every node and pool position.
A parent key cannot derive a child key.
If a member leaves, future deliveries that exclude that identity must exclude every old node that contains it.
Safe sibling nodes remain eligible.

A joining or recovered device receives a fresh cohort and fresh inventory.
Do not give the device an existing node's old private pool.
Do not change an old node's audience.
An authorized rebuild puts retained devices in a new cohort and has separately measured costs.
Keep unread tickets until consumption or explicit abandonment.
Multiple cohorts can exist within the discovery and storage limits.

2.3 Blinded stable roster slots

The membership record binds a roster tree with fixed capacity equal to a power of two.
Each credential leaf contains the device identity, Falcon public key, stable slot, and role or context fields.
It also contains a fresh random 32-byte blinding value.
Empty slots are committed tombstones.
Removal does not change the other slot indices.
A joining device uses a fresh slot.

The research credential retains an unused shard-label field for compatibility.
This label has no role in tree governance.
The service sees only blinded leaf hashes and interior hash nodes.
Clients receive credentials inside encrypted objects and verify their inclusion.
The service can assemble proofs from hash nodes.
After a removal, the author uploads only the changed nodes.

Blinding prevents a service from guessing a leaf from a known credential.
It does not hide tree shape, changed positions, or proof requests.
An old credential proof applies only to its original root.

The research checkpoint's count means slot capacity, not active population.
The final wire schema must distinguish capacity from any active-count field.
Capacity exhaustion requires an explicit resize or rebuild of the directory.
The model does not resize the directory automatically.
Verify node audiences and complete recipient coverage against authenticated credentials, not a count supplied by the service.

3. Membership agreement and checkpoints

3.1 Authority is explicit and outside the refresh path

At group creation, pin the membership authorization policy and the trust anchor for membership history.
The deployment supplies an authenticated, consistent history.
Examples include a finalized ledger with a suitable adapter or an explicitly trusted membership-log authority.
This specification requires an integration adapter.
It does not define a new consensus algorithm.

A log-authority signature relies on trust in that authority's consistency.
The signature alone does not prove the absence of equivocation.
A deployment that uses Byzantine quorum certificates must specify its protocol, membership, locking rules, and fault bound f.
Its quorum q must satisfy 2q > N + f for honest intersection.
Classical-only finality authentication does not satisfy the post-quantum threat model automatically.
The former shard rule ceil(m/3)+1 is not an agreement protocol.

Verify membership authorization separately from history consistency.
The delivery service cannot authorize additions, identity recovery, or removals.
Ordinary key publication and entropy refresh require no receiving-node attestation quorum.
Membership authorizers can collect signatures asynchronously.
A missing authorized membership decision does not stop messages in an established era.

The finality adapter must satisfy §11.
Service-visible commitments and ordering evidence must not expose member signatures, plaintext rosters, or sender-account submissions.
Authorized clients verify the enclosed policy and signatures.
An authority that learns admission identities has a separately declared role.
Do not supply that authority with an identity-linked stream of chat submissions.
A public ledger that reveals those associations fails the privacy requirements, even if its ordering is correct.

3.2 Checkpoint, cover, and state commitments

Before ticket use, the author verifies the proposed membership, authorization, producer eligibility, and exact disjoint cover (§5.3).
A checkpoint binds these fields:

• Group, sequence, and prior checkpoint.
• Roster root and capacity.
• Policy and history boundary.
• Fresh nonce and new-state commitment.

The new state includes a Merkle root over the ordered (node_id, ticket_id) cover.
Authorizations bind the complete checkpoint, not only a roster addition.

The author fixes the checkpoint identifier before encryption of the common entry.
The entry body contains the checkpoint, state, author credential, author proof, and individual signature.
Every wrapper binds the checkpoint and the common ciphertext hash.
Finality signs the fixed checkpoint identifier.
The author attaches that signature after encryption, outside the common ciphertext.
This order prevents a cycle between the checkpoint identifier, ciphertext, and finality signature.

The complete ciphertext outbox must exist before finality or any use of the new era.
A checkpoint can authorize unchanged membership with fresh independent state.
The new entry does not require a previous era's secret for decryption.
It contains no public decryption capability.
Ordinary messages and proposed independent lane contributions do not require new checkpoints.

Clients verify authorization and finality separately.
A fresh challenge-bound response authenticates the latest checkpoint.
Conflicting finalized identifiers cause an error.
Do not resolve that error by timestamp or arrival order.

The research log rejects conflicting predecessors and signs freshness responses.
It is a trusted consistency oracle, not proof that a malicious log cannot equivocate.
Compression of long membership histories relies on this trust rule.

4. Forward secrecy is a state invariant

4.1 Independent era entries

Each authorized era entry introduces fresh independent secrets for the sender tree, metadata, private directory, and delivery authorization.
The common-entry encryption key is separately random.
Neither an old era nor the retained lookup secret derives these values.
Entry into the current era does not need an era_next_previous chain.
New members receive only the new live state and separately authorized archive grants.

Every recipient consumes its selected entry ticket before use of the new era.
This requirement includes the author and all online members.
In one atomic transaction, install the sender frontier and metadata siblings and erase the consumed private key.
Also erase the temporary capsule key and entry plaintext in that transaction.
No second wrapper path for that recipient can remain.

After encryption of all wrappers, the author erases its extra sender-seed and capsule-key copies.
Its retained outbox contains only ciphertext.
The author enters the era through its own selected wrapper.

The research field Session.era_next is an unused independent sibling retained for compatibility.
It has no role in the selected entry schedule and cannot derive the sender tree.
Current measurements include this field.
The final tree-only wire schema should omit it.

The entry author supplies the independent era randomness.
This is not a claim of entropy agreement among multiple parties.
Recovery requires the author and all effective receiving capabilities to satisfy §10.

4.2 Puncturable secret trees

The sender tree has log2(roster_capacity) levels and stable roster slots as leaves.
It is a symmetric derivation tree, separate from the receiving tree.
Its frontier contains only symmetric derivation nodes.

For a node at (depth, index), derive each child as follows:

child_b = KDF(parent, "tree child",
              Encode(scope_era, role, depth, index, b), 32)

To initialize a sender lane, use these steps:

1. Expand the path to its leaf.
2. Retain only the unexpanded sibling subtrees.
3. Delete each expanded parent.
4. Derive the initial lane chaining value and the generation-zero message chain with distinct labels.
5. Delete the leaf after installation of those values.

The stored frontier must contain no ancestor of an initialized leaf.
This process initializes lanes on demand without a retained universal root.
An unopened leaf is an unconsumed capability.
Never reconstruct a consumed leaf from a backup seed, Welcome, checkpoint, or another device.

4.3 Independent sender ratchets

The tuple (group_id, era_id, device_id, role) identifies a lane.
Each application lane has a 64-bit update number g.
Each update has a 64-bit message counter c.
Only the sender creates updates for its application lane.
Each member maintains its own receiving copy of the lane.

Each SenderUpdate body contains these fields:

• Lane identifier, update number, and predecessor update identifier.
• Final message counter for the previous generation, or an explicit empty-generation marker.
• Sorted contribution identifiers without duplicates.
• Fresh 32-byte update nonce.
• Individual Falcon signature over the body.

An update that claims recovery requires at least one contribution.
Combine multiple contributions in canonical order:

input_e = ConsumeContributionLeaf(contribution_id_e, lane)
mix = H("entropy mix", Encode(sorted[(contribution_id_e, input_e)]))
R = KDF(Encode(lane_init_g, mix), "lane update", update_body_without_signature, 32)
lane_init_next = KDF(R, "lane init", lane_context_next, 32)
chain_next = KDF(R, "message chain", lane_context_next, 32)

After the transition, delete R, lane_init_g, and every input_e.
The new lane_init and message chain are sibling outputs.
The new lane_init cannot regenerate that message chain.
Each contribution supplies a different leaf to each eligible lane (§6.4).
Consumption of Alice's leaf does not erase Bob's unread leaf.
No retained node can cover Alice's consumed leaf.

Incorporate an event at most once within a lane.
Retain public consumption and replay markers after the secret frontier becomes empty.
Retrieval of the event again must not reinitialize it.
Stage leaf erasure and the authenticated lane transition together.
A failed transition must not lose an unused leaf.

Different lanes can update concurrently.
If Alice and Bob update at the same time, receivers process their lanes independently.
If Alice's predecessor is missing, fetch it or buffer the dependent update.
Do not apply a successor to a different predecessor.
The design does not assume that KDF(KDF(S,a),b) equals KDF(KDF(S,b),a).

An idle sender does not need to produce empty updates.
Before its next send, it incorporates available eligible entropy according to its local recovery policy.
It then publishes the required update dependency.
Messages do not wait for other senders to incorporate the same entropy.
A sender can continue with its current lane if an optional contribution is unavailable.
It must not claim recovery from that unavailable contribution.

4.4 Message keys and deletion

Derive message material and the next chain head as follows:

key_and_nonce_c = KDF(chain_c, "message key", Encode(lane, g, c), 44)
chain_next = KDF(chain_c, "chain step", Encode(lane, g, c), 32)

After safe installation of chain_next, delete chain_c.
Delete the message key after a send or successful reception.
Retain only bounded unused skipped keys or forward chain heads.
Never retain a generation-zero root for a consumed generation.
Counters and generations must not wrap.
Counter exhaustion requires a fresh authorized lane or era.

A newer update closes the previous generation with an authenticated final counter.
Use that counter to bound unread messages.
An old forward head can remain only for unconsumed counters.
It must not cover a consumed key.
Alternatively, a receiver can derive a bounded set of skipped keys and erase the head.
An excessive advertised counter must not cause unbounded work.

Use temporary state for tentative derivation and decryption.
After successful authentication, atomically commit ratchet movement, replay markers, and deletion.
Erase temporary ancestors and failed candidate keys.
Before ciphertext publication, the sender durably reserves the counter.
A retry sends the identical ciphertext bytes.
After a crash, never encrypt different plaintext with a previously used key and nonce.

4.5 Deletion audit

Secret	Required deletion point
Author's entry plaintext, sender seed, and capsule key	After encryption of the complete immutable entry, before era use.
Recipient's selected ticket and temporary capsule key	In the atomic transaction that installs the authenticated session.
Expanded tree parent and opened sender leaf	After installation of the derived state. No retained ancestor can cover an opened lane.
Consumed message key and previous chain head	After successful use. Retries use the same ciphertext bytes.
Pool-box key, enrollment private key, and plaintext pool	After full validation, in the atomic transaction that imports the pool.
Entropy root and delivery capability for an event	After installation of the restricted frontier. Erase each lane leaf when that lane consumes it.
Skipped message key	On use or explicit local expiry.

A retained encrypted copy is safe only if the device also consumes its decryption capability.
A retained box key, enrollment key, seed, backup, or outbox plaintext can defeat deletion.
Unread capabilities remain an exposure.
This includes other members' copies of shared node keys.
Python tests model these rules but do not establish physical memory or disk erasure.

5. Tree receiving inventory and recipient covers

5.1 Authenticated pool preparation

An immutable scope binds these fields:

• Group and node generation.
• Audience root and count.
• Publisher credential and proof of audience inclusion.
• Assigned producer and purpose.

The membership authorization policy certifies the scope.
The publisher generates independent ticket pairs and signs a Merkle manifest over the public descriptors.
A fetched public key needs a manifest proof before use.

For a shared node, the publisher uploads one encrypted box that contains the complete private pool.
Each other holder first supplies an authenticated single-use enrollment key.
The publisher encrypts four items to that key: the box key, box reference, manifest reference, and holder's audience proof.
Metadata envelopes encrypt all fields that identify the author, audience, or ticket assignment.
The service receives no pool key.

Before import, the holder verifies these items:

• Scope authorization and its own audience inclusion.
• Complete manifest and root.
• Each private-key and public-key pair.
• Key-alias and replay records.
• Local resource limits.

The holder imports the complete pool in one atomic transaction.
That transaction also erases the enrollment private key, box key, and plaintext pool.
The publisher imports its local copy and erases extra copies.
A singleton holder generates keys locally without a private-box upload to itself.

The publisher releases a signed readiness catalog only after pool preparation and erasure of extra key copies.
Eligible producers obtain the authenticated catalog and manifest.
They fetch selected public tickets at the time of use.
The research adapter requires affected holders to be online for setup.
After provisioning, entry creation and offline return require no acknowledgements.
The model does not implement offline replenishment through prepublished enrollment reserves.

5.2 Producer assignment and single use

Different producers have separate assigned pools without shared tickets.
Any eligible retained author with a complete cover can prepare a transition.
No fixed device must create every future entry.
Author rotation requires additional catalogs and private reserves.
A member cannot use another producer's ticket because that producer is offline.

Before encapsulation, durably reserve every selected ticket.
After a crash, abandon those tickets unless a complete immutable outbox already exists.
Retries preserve the original ciphertexts, recipients, context, publication scope, and expiry.
Do not rely on the service to enforce single use.
Preserve consumption records and key-alias tombstones through crashes and backups.

The harness uses a reservation set.
Distributed reservation, persistent state, and equivocation handling still need analysis for production use.

5.3 Exact cover selection

Use a node only if its complete fixed audience remains in the proposed roster.
Its assigned pool must also contain an unused ticket.
Select the largest eligible subsets first, without overlap.
For equal sizes, use full node identifiers to determine the order.
Use smaller descendants for the remaining recipients, down to singleton leaves.

If any current member remains uncovered, reject the transition before reservation or finality.
Do not omit an offline member to make an update succeed.

Consider devices A B C D E F G H and removal of D.
The author can select AB, C, and EFGH.
It uploads one common encrypted entry and three key wrappers.

Device C downloads its wrapper and the common entry.
Device E downloads the EFGH wrapper and the same common entry.
No member forwards these objects.
Device D has no selected node key.

A single exclusion from one fully provisioned balanced cohort needs no more wrappers than the tree depth.
Multiple removals, exhausted pools, multiple cohorts, and abandoned tickets can increase that number.
The worst case is one wrapper for each remaining device.
The design does not promise constant size or logarithmic cost for all updates.

The membership policy must authorize every selected audience.
The selected audiences must cover the complete roster without overlap.
This requirement applies even if a recipient fetches only its own inclusion proof.
The research builder verifies complete coverage.
Production verification by the authorization layer remains a required task.

5.4 Finite reserves, replenishment, and repair

Plan inventory for events, producers, exclusions, and crash abandonment.
Days alone do not determine inventory demand.
Each node use consumes one ticket from each holder's local copy.
If a large node has no unused tickets, smaller nodes can replace it in the cover.
If a required leaf has no unused tickets, further eras can become unavailable.

Established lanes remain available in the current authenticated era.
A blocked removal is not effective.
Do not send in the proposed new era while its transition is blocked.

Replenish pools while the required holders are available.
A repair can create a fresh cohort of available retained devices with fresh pools.
Do not remove absent devices from membership as part of that repair.
Do not assume that absent devices hold the new cohort's keys.
Their existing safe nodes still require coverage.

In the current adapter, repair of all survivors requires all survivors to be online.
Measure repair uploads, downloads, and retained old inventory.
Do not retain a master key or reuse a consumed ticket to repair a tree.

6. Shared entries and independent entropy

6.1 Common entry and wrappers

The era author generates fresh live siblings and a separate random 32-byte capsule key.
The common body contains the checkpoint, siblings, author credential, author proof, and cover commitment.
The author signs this body and encrypts it once with the capsule key.
Each selected node receives an independent NTRU encapsulation and an AEAD wrapper of the capsule key.

Bind these values in the wrapper's authenticated context:

• Suite, group, and purpose.
• Checkpoint, node, and ticket.
• Hash of the common ciphertext.

The common entry and node wrappers are separate immutable service records.
Each wrapper depends on the common entry.
The common entry depends on its roster proof directory.
Upload the common ciphertext once.
Each reader downloads it directly.

The author does not create a complete entry package or upload a membership proof for each device.
A tree parent does not forward the entry.
Merkle inclusion paths bind the selected node and ticket to the cover commitment in the authenticated state.

6.2 Atomic entry consumption

Before session installation, authenticate these items:

• Fresh finalized checkpoint and its authorization.
• Wrapper context and ticket assignment.
• Common ciphertext hash.
• Inner author signature and membership proof.
• Recipient's current membership proof.
• State commitment and cover inclusion.

Then install the session and erase the selected ticket in one atomic transaction.
If an object is missing or malformed, preserve the previous state and unused inventory.
Enforce resource limits before memory allocation or secret derivation.

An entry must not reset the same era or an older era.
If finality reports the existing era, preserve the saved counters and frontiers.
Do not fetch a replacement seed for that era.
After a new era, old unread state can remain only under a separate bounded replay or archive policy.
Account for that retained state separately.
It must not become a backup of consumed current state.

6.3 Discovery and object confidentiality

Before an absence, the device caches its cohort identifiers, node identifiers, and lookup capability.
Opaque selectors depend on that capability, the current checkpoint, and the node.
One bounded request batch finds the selected wrapper.
Exactly one current entry path must exist for the recipient.

Each encrypted control object carries a fresh public 32-byte salt.
Use that salt to derive a distinct AEAD key for the object.
Authenticate the complete context as associated data.
Include the salt in wire-cost measurements.
Do not use a fixed key and nonce for all objects in an era.

The lookup secret decrypts control metadata.
It does not decrypt private pool boxes, common entries, or application payloads.
Former cohort members can still read this metadata.
The research model also retains the control-store capability.
Removed members can still access or abuse that store through its shared authorization.

The new entry excludes removed members and rotates the live submission capability and live metadata keys.
Payload encryption does not revoke old control metadata or old service access.
Full revocation of those capabilities remains unresolved.

6.4 Same-era contributions and lane recovery

Entropy contributions are separate from era entries.
The proposed tree adapter uses assigned pools with separate purposes and an exact cover of the current roster.
It encrypts a common fresh entropy value through single-use receiving tickets.
It authenticates the producer, era, and configuration, and binds the ciphertext recipients.

Different producers can contribute at the same time.
Each sender selects authenticated inputs for its own ordered lane (§4.3).
Group-era renewals do not automatically replace sender updates.

After receipt of delta, derive separate metadata and per-lane entropy-tree outputs.
Then erase delta and its delivery key.
For each lane that incorporates the event, consume and erase exactly one leaf.
An attacker could combine retained delta with an earlier lane snapshot to decrypt past messages.
The same risk applies to a retained ancestor of a consumed leaf.

Keep public replay markers after deletion of the secret frontier.
The contribution author follows the same self-delivery and erasure rules as other recipients.

The symbolic ratchet and earlier delivery experiments exercise these requirements.
The selected tree-entry adapter does not yet implement or measure this contribution transport.
Its current pools support entries only.
Do not reuse them for refresh.
The entry benchmarks establish no daily recovery interval, same-era refresh cost, or complete CGKA proof.
The model supports whole-era recovery only under the exposure conditions in §10.

7. Admission, removal, and optional history

7.1 Authorized admission

An addition requires an invitation or administrator or guardian authorization under the pinned policy.
The authorization binds the prior checkpoint, proposed roster, device credential, and policy.
Key publication alone does not admit a member.
Admission controls limit Sybil insertion.
Random tree placement does not authorize admission.
No node-local threshold controls group membership.

Before the joining device goes offline, authenticate its identity, initial lookup state, and fresh receiving inventory.
A singleton cohort is sufficient.
Initial enrollment and delivery-capability setup require a complete private adapter.
The harness assumes authenticated initial identities and topology.
Entry measurements do not include that initial authentication traffic.

7.2 Join

Provision fresh inventory for the joining device.
Add its fresh cohort to the exact recipient cover.
The finalized common entry supplies independent era state to existing members and new members.
Do not give a new member a preceding era secret or an existing node pool.
Encrypt all entries before use of the era.
The membership policy can permit batches of subsequent joins.

7.3 Removal

Exclude every old node whose audience contains a removed credential.
Select safe sibling nodes, descendant nodes, or singleton leaves for all retained members.
Use unused tickets assigned to the retained author.
The removed member's old lookup capability and ciphertext access must not decrypt a new entry wrapper.
Rotate live state and the submission capability in the entry.
If sufficient reserves exist, no online recipient acknowledgement is necessary.

After receipt of finality, an honest sender must enter the new era before its next send.
A partitioned sender cannot enforce a removal that it has not received.
If reserves cannot cover a retained member, the removal remains pending.
Communication in the established era still has the old membership.
The service cannot create receiving keys, authorize exclusion, or substitute a static shared secret.

7.4 Cohort repair and identity recovery

Cohorts are immutable.
Cohorts from different generations can overlap, but selected covers must not overlap.
A repair provisions a new generation with fresh independent keys.
Measure its setup costs.
Do not destroy old unread keys only to reduce a reported storage value.

A recovered identity needs independent authorization and fresh inventory that excludes compromised holders.
A new KEM key signed by a stolen identity does not restore trust in that identity.

7.5 Optional end-to-end encrypted history

Admission initializes only the new era's live state.
An archive-enabled policy permits a separate signed, encrypted history grant from an authorized member.
The grant binds the group, policy version, recipient device, admission authorization, exact range, and authenticated archive manifest.
It supplies archive capabilities only for that range.
It does not export live chaining values, entropy trees, or admission roots.

The archive must preserve verifiable original authorship and message context.
A grant issuer does not become the author of imported messages.
Each archive segment uses an independent access key.
Access to one segment must not derive later segment keys or current live secrets.
Rotate future archive access after removal or compromise.
No protocol operation can revoke existing grants or copied plaintext.

The service can store encrypted archives and grants.
Authorized endpoints create archives, encrypt keys, validate recipients, and authorize grants.
No profile permits a server-held master key, password-reset escrow, or server-side plaintext search.

The sender must be able to see and authenticate a message's eligibility for future-member history access.
History policy changes apply to future content.
Wider access to older private content requires a separate authorized export.
Such an export cannot recreate content after erasure of its only keys.
A narrower policy cannot revoke grants that already exist.

Use authenticated message or era references for history windows.
Do not let an untrusted server timestamp expand the permitted range.

An inviter can prepare a recipient-specific grant during admission, before either device goes offline.
The recipient can later fetch the grant and encrypted history without the inviter being online.
A previously unknown recipient still needs a grant from an authorized endpoint or a separately analyzed delegation mechanism.
The server cannot create that decryption capability.
Use the concealed-origin path in §11 for history uploads, discovery, and retrieval.
History download must not block live return (§9.5).

The tree prototype and archive layer test independent one-message segments and recipient-bound grants with ideal cryptography (§13).
They also test authenticated ranges and offline retrieval.
The current encoding is deliberately unoptimized.
It is not the final archive or key-wrapper format.
Encrypted indexing, grant-ticket enrollment, scalable pagination, and composition analysis remain required work.
An archive-enabled profile cannot claim forward secrecy against exposure of the retained archive capabilities.

8. Application messages and mandatory privacy

8.1 Encrypted framing

The public envelope contains only these fields:

• Version and opaque group routing identifier.
• Full group era identifier and header-key identifier.
• Content type.
• Length-delimited header and body ciphertexts.

A routing identifier does not establish anonymous transport.
The encrypted sender header contains the sender index for the era and the full sender-update identifier.
It also contains the update number, message counter, and optional dependency or proof references.
The encrypted body contains a length-delimited application message, its individual Falcon signature, and padding.

The signature authenticates these values:

• Group, era, and sender lane.
• Generation, counter, and header-key identifier.
• Message type and unpadded application body.

Keep the signature inside encryption so the service cannot test candidate author public keys against it.
Supply first-contact credentials and membership proofs inside the encrypted frame or through an authenticated private directory.
The same canonical transcript must cover extra fields and lengths.
Attachments use separately scoped keys and authenticated manifests.
File sizes and download patterns require a separate privacy policy.

Application SenderUpdate objects use encrypted control envelopes.
Their authors, signatures, and closing counters must not disclose the encrypted application header.
The service indexes these objects by opaque update identifiers.
The receiver compares the decrypted body's hash with the identifier and verifies the inner signature.
A fresh update nonce prevents identifier guessing from public contributor identities and small counters.

Members can independently verify receiving-node ticket publications.
Their author-bearing bodies and signatures stay inside encrypted directory envelopes (§11.3).

A control envelope contains its group, era, header-key identifier, object identifier, and a fresh random 32-byte envelope nonce.
Derive its AEAD key and nonce under header_base with the label "control envelope".
Use those fields as derivation context and authenticated associated data.

If the same body gets a new signature, use a fresh envelope nonce.
A randomized signature can change the encrypted bytes without changing the body identifier.
A retry uses the complete existing envelope.
Count envelope bytes as additional sender-update overhead.

8.2 Header key derivation without nonce reuse

The initial header-key identifier for an era selects metadata_secret_M.
Alternatively, a sender can select a group contribution from the same era:

header_base = KDF(delta, "contribution metadata", contribution_id, 32)
header_key_id = contribution_id

Derive this metadata sibling once during installation in §6.4, before erasure of delta.
Later header processing uses only the stored sibling.
A receiver with an unused ticket can fetch and install the event.
Do not reopen a consumed event for a header.
This permits header privacy recovery without a synchronized group header epoch.

If an attacker obtains a retained metadata key, the attacker can read historical headers.
It cannot reconstruct the contribution tree or payload inputs.
The protocol does not claim per-message secrecy for historical metadata.

First encrypt the body with its single-use message key.
Bind the body's associated data to the public envelope fields and canonical plaintext sender header.
Then derive the header encryption material from the resulting ciphertext:

body_digest = H("body ciphertext", body_ciphertext)
(k_h, nonce_h) = split(KDF(header_base, "sender envelope",
                         Encode(public_fields, body_digest), 44))
header_ciphertext = AEAD.Seal(k_h, nonce_h, sender_header,
                              Encode(public_fields, body_digest))

Body encryption precedes header encryption, so there is no circular dependency.
Different body ciphertexts derive different header keys and nonces, subject to hash security.
A retry uses the exact complete frame.
Do not change a header while you reuse its body ciphertext and derivation context.
Always bind the group, suite, and era contexts.

This method uses the principle of ciphertext-dependent derivation from MLS sender-data encryption.
Do not use a fixed key and nonce for the whole era.
Header recovery requires a contribution whose secrecy satisfies the recovery conditions.
Retention of the initial metadata secret does not itself restore confidentiality.

8.3 Receive transaction

Use these steps for reception:

1. Enforce envelope-size, pending-byte, and dependency-fetch limits.
2. Resolve the era and header key.
3. Fetch or buffer unknown dependencies within the limits.
4. Authenticate and decrypt the sender header.
5. Resolve the sender credential and referenced update.
6. Buffer dependent updates if their predecessors are missing.
7. Verify the required control signatures and contribution dependencies.
8. Apply updates transactionally to the sender's receiving lane in authenticated predecessor order.
9. Derive only the permitted number of candidate message keys in temporary state.
10. Decrypt the body.
11. Verify the individual Falcon signature.
12. Atomically commit counter consumption, chain changes, replay markers, and erasures.

On failure, preserve the previous authenticated state and erase temporary keys.
A group insider knows header secrets and can forge header AEADs.
Payload signatures still prevent impersonation.
Keep both per-sender and global resource limits after header authentication.
Replays must not reconstruct consumed roots or enlarge the skipped-key cache.

8.4 Padding and transport

Include the signature in the body plaintext before padding.
For sizes up to 2048 bytes, round the body plaintext length to a multiple of 128 bytes.
For larger sizes, round the length to a power of two.
The group policy binds the exact padding profile.
Calculate padding cost from actual traffic rather than a fixed percentage.

Every profile must use concealed-sender submission (§11).
Recipients authenticate the author inside the encrypted envelope.
The service sees only permitted routing information and delivery authorization.
Do not send account credentials or identifying device signatures with a submission.

Use the existing transport that hides source IP addresses.
Its architecture is outside this specification.
Coppice requests and fallback behavior must not disclose the sender's identity.

The protocol does not claim content deniability.
Never deliberately disclose identity keys or control keys.
Do not publish retired content-signing keys.
Their publication could let an attacker forge history that an offline recipient later accepts as a new delivery.

9. Offline participation and bounded state

9.1 Latest-entry return is the normal path

A device first resumes current participation after an offline period.
Optional backlog and history downloads are separate.
The normal return path requires cached identity and cohort state, preinstalled tickets, retained objects, and fresh trusted finality.
It uses four sequential requests:

1. Obtain a fresh challenge-bound response for the latest checkpoint.
2. Request a batch of opaque selectors for known receiving nodes.
   Exactly one current wrapper must exist.
3. Fetch the common encrypted entry.
   Stage and authenticate its opening without ticket consumption.
4. Fetch the current membership proof from the blinded directory.
   Complete validation and atomically install the session with ticket erasure.

No other member acts at the instant of return.
The number of missed eras does not add entry-decryption steps.
If the era is unchanged, verify freshness and preserve the existing ratchets.
Proof size and lookup size still depend on roster capacity and known cohorts.
The design does not promise constant cost for arbitrary group growth.

9.2 Current sending and current receiving

The latest entry supplies a fresh sender lane for the returning device.
Current sending does not require replay of intermediate membership eras.
Current reception can require the active sender's authenticated update history and unread chain positions.
Skipped-key limits still apply.
A bounded first-send path does not establish bounded first-reception latency.
Measure both paths separately, including sender discovery and credential proofs.

Historical replay follows dependencies within each era and lane.
A missing predecessor can defer one lane without blocking unrelated lanes.
Retained old tickets can open unread historical entries within explicit storage and replay limits.
Entry into current state does not recover erased history or remove archive policy requirements.

9.3 Offline service contract

The planning targets are:

• Seven days offline.
• A 30-day object-retention horizon with dependency closure.
• At most 64 KB of entry-control download with cached identities.

Plan assigned tickets for genesis, expected transitions, renewals, alternate authors, removals, and failed reservations.
Elapsed time does not supply this inventory.
The service must retain wrappers, common entries, referenced directory nodes, public manifests, and required private-box dependencies.

The service can withhold objects and prevent progress.
Authentication cannot force delivery.
Return an explicit pending or recovery result for any of these conditions:

• Missing or expired inventory.
• Missing finality or unavailable authorization.
• Exhausted lookup limits.
• Missing ciphertext.

Do not regenerate consumed keys, omit recipients, or use server escrow.
The tree does not solve long-term offline replenishment without a suitable receiving capability already installed.

9.4 Local limits and crash recovery

The initial research limits are:

State or operation	Limit
Raw private tickets	16 MiB
Ticket references	100,000
Subset lookups for one return	256
Entropy frontiers	16 MiB
Pending control state	8 MiB
Skipped message keys	2,000 global; 256 per sender

Some tests use smaller limits to exercise failure behavior.
Measure skipped-key expiry from local derivation, not the original message send time.
A limit can defer work or require explicit abandonment of unread state.
It does not establish complete replay.

Persist ticket reservations, immutable outboxes, entry installation and deletion, message counters, and replay tombstones across crashes.
Rollback recovery requires an independent witness or a fresh authorized identity.
A restored database alone is insufficient.
Python deletion and the ideal durable-store oracle do not implement secure storage.
Repeated cohort rebuilds need an explicit retirement and discovery policy before known nodes exceed the lookup limit.

9.5 Measured scope

simulate.py selects tree delivery by default.
The 128-device run provisions all required pools before a seven-day absence.
It makes seven removals spread across the cohort.
Before the first current send, control traffic is 7,936 downloaded bytes and 1,024 uploaded bytes in four round trips.
No participant acts at return.

Separate current reception downloads 45,952 bytes in 35 round trips.
That workload deliberately uses a small skipped-key limit (§12).

These values measure the research format.
They are not unconditional latency or mobile-data guarantees.
Reports separately show setup, author rotation, current reception, missing-object behavior, exhaustion, and repair.
The full per-device entry, compact direct, and shard workloads remain reproducible comparisons.

10. Post-compromise recovery in an asynchronous system

10.1 Exposure determines recovery

Exposure	Necessary recovery condition
One sender lane; selected entry keys and author remain secret	A fresh later entry can establish a new lane without the old chain.
Node tickets, enrollment keys, or private-box keys	Provision fresh independent keys through capabilities unknown to the attacker. Exclude every compromised holder.
Complete device, including its Falcon identity	Use independent authorization to replace or revoke the identity. Then install fresh safe receiving keys and live state.
Archive capabilities	Disclosed archive content cannot become secret again. Independent keys can protect future segments.

A common entry can have wrappers for many nodes.
Every effective wrapper must be safe for the common entry to remain secret.
One copied selected private key can expose the common state for the whole group.
Verification of only the recovered device's path is insufficient.
Every holder of a selected shared node can be a source of that key.
One malicious authorized endpoint can disclose all application plaintext that it receives.

10.2 Recovery events

Recovery requires all of these conditions:

• Fresh endpoint randomness unknown to the attacker.
• Trusted identity authorization.
• Safe new receiving inventory.
• An honest fresh entry or eligible contribution within the era.
• Incorporation of that input into the sender state that needs recovery.

Erase consumed delivery keys, pool-box ancestors, and contribution inputs at every endpoint covered by the later-compromise claim.
Elapsed time does not restore secrecy.
Use of an unused ticket copied before recovery does not restore secrecy.

One retained device authors each independently random era entry.
The entry alone does not prove contributory randomness against a malicious author.
Independent lane contributions remain the intended contributory extension.
Section 6.4 identifies the missing adapter work.
The prototype establishes neither a universal recovery-time bound nor a complete adaptive-corruption proof.

10.3 Combined exposures and unread copies

After a lane consumes a recovery input, later endpoint state must not recover that input or its ancestors.
Otherwise, an attacker could combine them with an earlier lane snapshot.
This requirement covers the author, publisher, other node holders, enrollment keys, retained boxes, and backups.
An event frontier can retain other lanes' unread leaves.
It must not cover a consumed leaf.

An offline device deliberately retains unused tickets and backlog capabilities.
Compromise can expose the entries that those capabilities open.
Another member's consumption does not erase the offline copy.
An attacker retains any earlier copied ticket after honest devices erase their copies.
Forward secrecy depends on consumption at the exposed endpoint.
It does not require an acknowledgement from every reader or protect content with retained archive capabilities.

Larger groups have more authorized endpoints that can disclose content.
The receiving tree changes delivery costs, not this trust boundary.
Keep history and forward-secrecy policies explicit for every group size.
Services must never become authorized decryptors.

11. Mandatory server confidentiality and concealed origin

11.1 End-to-end sender authentication

Every profile keeps content, attachments, archives, grants, author identities, author signatures, and sender credentials encrypted from infrastructure.
Authorized recipients authenticate the sender after decryption.
Infrastructure receives no message keys, archive keys, private directory keys, or member private keys.
Content remains encrypted end to end without the underlying transport encryption.

This separation follows Signal's sealed-sender design.
Recipients verify the enclosed sender.
The service accepts delivery without authentication of a sender account.
The existing transport hides source IP addresses (§11.2).
Coppice does not copy Signal's classical envelope primitives into its post-quantum suite.

11.2 Existing transport assumption and application boundary

The deployment already supplies source-IP hiding.
Its design is outside Coppice's scope.
Coppice does not select a relay topology or proxy protocol.
It does not specify network cover traffic, operator separation, or defenses against network traffic analysis.
The transport's guarantees and costs remain integration inputs.

Coppice must prevent application requests from disclosing sender identity.
The service must receive no plaintext author identity, member signature, identifying credential, or stable per-sender upload handle.
Source-IP hiding does not make an account-authenticated request anonymous.
Routing aliases and delivery capabilities must not encode or uniquely identify the sender.

Observer	Permitted visibility	Protected information
Authorized recipient	Decrypted content and authenticated author. The recipient can copy either.	No secrecy claim against an authorized reader.
Delivery, directory, or archive service	Opaque destination routes, selectors, shared delivery authorization, ciphertext sizes, and timing visible through the existing transport.	Plaintext, content keys, author credentials, member signatures, sender-account authentication, and identifying control records.

Source-IP hiding does not hide all other metadata.
Group routes, repeated ciphertext, access patterns, and timing can remain linkable.
Document this visibility without a redesign of the network transport.
Directory and archive requests must obey the same application boundary as message submissions.

11.3 Private control and directory objects

Sender concealment applies to the complete workflow.
It includes contributions, producer signatures, ticket assignments, node publications, membership records, admission entries, return entries, archive grants, receipts, and attachments.
A plaintext signed node descriptor exposes its author even with encrypted application headers.
Do not expose such author-bearing records to the service.

Member-verifiable signed bodies and their identifiers remain inner protocol objects.
Store them in authenticated encrypted control or directory envelopes with opaque selectors.
Keep producer identities, assignment-to-account links, and fields that permit candidate-signature tests inside those envelopes.
Service-visible membership commitments must hide their underlying records.
Clients verify retrieval proofs.
Opaque group routes can still link traffic within a group.

Directory keys must be separate from payload and archive keys.
The service must never hold directory keys.
A control envelope must use a metadata capability that its authorized reader can already obtain.
Do not create a circular dependency between a ticket record and the contribution that needs that ticket.
In particular, do not encrypt that only ticket record solely under the contribution it opens.
Admission and return entries must supply the required directory capability inside endpoint-encrypted packages.

Authenticate the inner object identifier and outer context.
Use fresh envelope randomness after a change to the encrypted encoding.
Never use metadata decryption to restore erased payload capabilities.
Receivers fetch credentials and proofs on demand.
Sender concealment must not require download of every member's inventory.

Initial directory setup, selectors, padding classes, and exact envelope encodings remain required adapter work.
Earlier public-directory estimates omit this protection.
Do not present those estimates as complete device costs.

11.4 Anonymous delivery authorization and abuse control

The service authorizes delivery without sender identity.
Its admission check can use a random group or recipient bearer capability shared by permitted senders.
A capability unique to one member would identify that sender.
The capability authorizes service delivery only.
Recipients still verify signatures and membership before acceptance.
Keep the capability independent of message, metadata, and archive keys.

After removal, rotate the live submission capability to exclude the removed device.
The prepared entry supplies it to an offline member without an identifying submission.
The control-store capability has the separate revocation limit in §6.3.

A shared bearer capability permits only aggregate delivery limits.
An insider can leak or abuse it.
Individual quotas without sender identification require a separately specified unlinkable credential scheme.
That scheme must cover these properties:

• Unlinkability between issuance and redemption.
• Bounded use and replay control.
• Compatible cryptographic assumptions.

A normal login token or unique device API key does not provide those properties.
A blind-token label without a construction is also insufficient.

Submissions must not contain these identifying items:

• Sender cookies or account bearer tokens.
• Phone numbers, wallet signatures, or client certificates.
• Device-specific tracing headers or identifying analytics.

If enrollment or quota issuance needs identity, separate it from delivery without a stable cross-link.
Apply the same rule to key publication, history uploads, and reconnection traffic.
If delivery credentials are missing, queue the work or report an error.
Never fall back to sender-account authentication.
Push notification payloads must not expose authors or plaintext to push infrastructure.

11.5 Retrieval, padding, and device costs

Section 8.4 specifies content padding.
Also account for request padding, response padding, and distinguishable control sizes.
Application padding alone does not hide a recognizable burst of ticket publications.
History and directory requests use the existing transport without stable sender identifiers.
Batch retrieval and proof caching should reduce bytes and round trips without a cross-request client identifier.

For stronger retrieval privacy, evaluate stable fetch cohorts or a measured private information retrieval construction (PIR).
Independent random decoys are insufficient.
Consider one fixed real slot among 78 candidates and seven random decoys per query.
After three queries, the expected false candidates in the intersection are 77 * (7/77)^3 = 0.058.
Evaluate PIR with actual record sizes, updates, response bytes, and amortized costs.
Retrieval privacy does not change authorization for archive keys.

Report each device's upload, download, and round trips before return to participation.
Include encrypted envelopes, delivery credentials, and padding.
Server bandwidth savings are secondary.
Report the existing source-IP-hiding transport cost separately.
Do not add an invented relay or cover-traffic design to Coppice's cost model.
Each application-level batching or retrieval-privacy extension must state its additional device cost.

12. Device bandwidth and storage

12.1 What the tree changes

Use these variables for cost calculations:

Variable	Meaning
C	Number of selected receiving nodes.
N	Number of live roster members.
L	Number of nodes known to the device.
P	Number of eligible producers.
d	Reserve tickets for each node and producer.

The entry author uploads one common ciphertext, C wrappers, changed directory nodes, and framing.
Each reader fetches one wrapper, the common entry, and its proof.
The reader also makes bounded discovery requests.
Public catalogs and provisioning have separate costs.
Do not omit those costs from a device budget.

A NTRU wrapping slot contains at least 930 ciphertext bytes, 32 wrapped key bytes, and a 16-byte tag.
This totals 978 bytes before identifiers, proofs, signatures, encryption envelopes, and padding.
An unchanged balanced cohort needs one wrapper if its root has available inventory.
Singleton fallback can need up to N wrappers.
Each independent ticket has a 930-byte public key and a 1234-byte private key.

A device in one balanced cohort belongs to at most ceil(log2(N)) + 1 distinct nodes.
Before consumption, its raw private reserve is at most 1234 * d * P * (ceil(log2(N)) + 1) bytes.
Additional cohorts add reserves.
This bound excludes metadata, enrollment keys, catalogs, and runtime state.

The model pads serialized requests and responses to multiples of 128 bytes.
It counts device traffic, not service egress.
Service replication and the existing source-IP-hiding transport have separate integration costs.
All KB and MB values in this section use decimal units.

12.2 Selected 128-device workload

The default tree report uses 128 devices and seven removals spread across the cohort.
One device remains offline for seven days.
Each node has eight tickets for each producer, including genesis inventory.
There is one eligible author.
Each transition has fresh common state.
The model starts with cached identities and topology.

Item	Measured tree cost
Author upload over the seven changes	277,376 B
Author public-ticket download over those changes	164,736 B
Wrappers at successive changes	7, 10, 14, 17, 22, 25, 29
Returning device's provisioning upload / download before absence	32,512 / 160,384 B
Returning device's raw private reserve before absence	77,742 B
Returning device's encoded ticket metadata before absence	10,150 B
Current-entry control upload / download	1,024 / 7,936 B; four round trips
Separate reception from a busy sender: upload / download	4,608 / 45,952 B; 35 round trips
Largest single-device provisioning upload / download	397,696 / 1,652,480 B
Busiest device's control upload, including setup and genesis	853,376 B
Busiest device's upload / download for the complete run	1,163,392 / 1,880,576 B
Total provisioning upload / download across devices	10,070,144 / 20,491,520 B

The complete run includes setup, genesis, online control reception, application sender uploads, first send, and the selected returning reader.
It does not include every device's download of every application message.
The JSON reports control-only totals and peaks separately.
With unchanged membership, seven fresh entries require 46,592 bytes of author upload.
Membership changes therefore affect the comparison.

12.3 Comparisons and scale

The 128-device comparison measures author upload over the same seven changes:

Layout	Author upload
Compact direct	1,614,592 B
Shard	1,163,008 B
Selected tree	277,376 B

Tree delivery reduces that upload but increases total provisioning traffic.
It does not minimize every device's total data use.

The 1,000-device comparison has two removals.
Its tree author uploads 65,536 B.
Provisioning all nodes in advance makes the busiest producer download 11,746,176 B.
The tree's busiest device uploads 3,320,832 B over the complete run.
The corresponding shard value is 1,606,400 B.

Variable reserve depths and smaller authenticated catalogs need further measurement.
These results include no savings from unimplemented changes.

The rotating-author workload explicitly provisions two authors.
Offline guarantees must include replacement-author availability and pool count.
Exhaustion and repair experiments measure replenishment and retain old unread tickets.
They are not current tree device budgets.

12.4 Application and endpoint storage

Each individual padded Falcon signature costs 666 bytes before framing.
A representative inner frame from the earlier layout has 864 bytes before plaintext, padding, dependencies, and uncached proofs.
The final v4 schema must confirm that size.
Sender-update signatures and dependencies add traffic according to active senders' updates.
Membership changes alone do not determine this traffic.
The default tree experiment does not measure a complete daily contributory-refresh workload.

Account for all of these storage items:

• Private receiving tickets, encoded scopes, and tombstones.
• Producer catalogs and credential or proof caches.
• Sender frontiers and entropy frontiers.
• Message heads, skipped keys, and pending objects.
• Enrollment keys and archive capabilities.
• Persistent-store overhead.

Ten thousand Falcon public keys alone cost 8.97 MB.
A global cache of 2,000 skipped keys holds 88 KB of raw 44-byte key and nonce material, before bookkeeping.

Fragmented entropy frontiers can require substantial storage.
The symbolic 10,000-lane experiment retains 160,000 secret bytes for each event after alternating consumption.
For 4,320 events, that pattern projects to 691.2 MB.
A 16 MiB limit does not make this workload fit.
The device must defer work or explicitly abandon unread state.
Tree delivery does not remove this symmetric-state cost.

12.5 Accounting requirements

Reports must include these costs and conditions:

• Setup and steady traffic.
• Busiest-device upload and download.
• Offline return and separate current reception.
• Membership changes, repair, and alternate authors.
• Inventory exhaustion and endpoint storage.

Identify any omitted initial identity or directory setup and authorization exchange.
Also identify omitted finality costs, retained metadata access, actual PQ processing, transport costs, and physical erasure.
Compare alternatives with matching policies and workloads.
One small wrapper or average upload value does not establish a complete device budget.

13. Executable research model and conformance

The research suite uses Python's standard library and ideal cryptography.
Run the tests and vector check with these commands:

python3 -B research/coppice/run.py
python3 -B research/coppice/vectors.py --check

simulate.py selects the tree profile.
Use --profile legacy-direct for the old full-entry workload.
compare_covers.py compares compact direct, shard, and tree delivery.
This work does not change production crates.

Module	Research function
cover.py	Models independent node keys, scopes, manifests, exact covers, common entries, blinded roster proofs, and bounded return.
cover_lab.py	Measures provisioning and author rotation.
tree_profile.py	Creates the selected reports and runs exhaustion, repair, and tree-history experiments.
history.py	Verifies blinded credentials, original signatures, authorized ranges, and recipient-bound grants. It does not export live secrets.

Keep the following scenario numbers for regression tracking:

1. Independent sender updates commute across lanes, but not within one lane's predecessor chain.
2. Receivers buffer and authenticate reordered dependencies before update application.
3. On-demand sender initialization deletes every parent that covers the consumed leaf.
4. Combined earlier and later compromise cannot recover a consumed input.
   Deliberate retention of raw entropy is a failing negative control.
5. Immutable retries and equivocation detection do not depend on a malicious service to reveal a fork.
6. Admission and credential recovery require independent authorization and single-use delivery.
7. Header and control encryption avoid fixed era-wide keys and nonces.
8. Return after several days uses prepared material without a live inviter.
9. Removal excludes every receiving node that contains a removed identity.
10. Exhaustion or missing assigned-author inventory does not advance finality or permit ticket reuse.
11. The model enforces limits for frontiers, pending objects, parsing, and skipped keys.
12. Reservation, consumption, retries, and rollback witnesses have explicit crash boundaries.
13. Publication-fork detection requires authenticated view comparison.
    Permanently isolated views remain a negative result.
14. Authors consume their self-delivery capability.
    Publishers cannot reconstruct consumed tickets from a retained box or seed.
15. Deferred dependency work is not recorded as complete.
16. Service traces contain no plaintext member credentials, author signatures, or content keys.
17. Missing anonymous authorization does not cause sender-account authentication.
18. Separate history grants bind ranges, recipients, and policies and preserve verifiable original authorship.
19. Reports separate the first current send from busy-sender reception and historical replay.
20. Exact covers are complete, disjoint, and producer-assigned.
    They exclude removed identities and give new members no old pool secrets.
21. Pool preparation, readiness, atomic import, erasure, and failed entry opening preserve consumption rules.
22. Reports measure setup, cover fragmentation, alternate authors, exhaustion, repair, and busiest-device costs.
23. The default tree profile supports all three history policies with blinded roster proofs.
    Unavailable archives do not block current sending.

Tests do not certify cryptographic security.
IdealCrypto owns fixture secrets outside endpoint and service compromise snapshots.
Lab and CoverLab are test harnesses, not devices.
Core plaintext and key oracle fields never cross the modeled service boundary.
The tests do not establish actual NTRU or Falcon behavior, traffic unlinkability, initial enrollment, production consistency, or hardware erasure.

The research format retains inherited hash labels, the checkpoint count field, the unused shard label, and the unused era_next sibling.
vectors.json fixes that format for regression checks, not v4 interoperability.
Contribution and lane tests are separate layers.
They do not establish a complete tree contribution adapter.

14. Remaining research and implementation gates

Tree delivery is the selected research direction.
Complete the following work before production adoption:

1. Analyze adaptive compromise of every selected node holder, publisher, author, enrollment key, unread ticket, and archive capability.
   Include combined past and future snapshots and malicious entry authors.
2. Specify and test the adapter for purpose-separated contributions within an era.
   Analyze exact-cover authorization and per-lane erasure together.
   Measure sender-update distribution costs and frontier storage.
3. Reduce advance provisioning and catalog overhead without keys that can regenerate consumed secrets.
   Include repair costs and the keys that offline devices actually possess.
   Measure directory resizing, cohort retirement, and enrollment-reserve exhaustion.
4. Complete private initial setup and revocation of control-store and metadata access after removal.
   Preserve bounded offline return without identifying upload handles.
   Secrecy of individual fields does not prove sender unlinkability.
5. Specify canonical v4 types, purpose domains, roster capacity and count, retained-state formats, and key validation.
   Produce cryptographic vectors for multiple implementations.
   Fix the NTRU and padded-Falcon formats.
   Audit randomness and side channels.
6. Supply the consistency and finality adapter.
   Specify complete-cover authorization, durable reservation, erasure, and rollback behavior.
   A trusted log signature is not Byzantine consensus or proof against equivocation.
7. Complete scalable archive indexing and grant enrollment.
   Preserve the explicit NONE, WINDOW, and ALL_RETAINED policies.
   Do not give the service a decryption key.

Current deliverables are specifications, research code, adversarial schedules, reproducible vectors, and device-cost measurements.
This draft does not authorize crate implementation, integration, or deployment.

References

These sources motivate components and comparisons; their proofs do not automatically cover the Coppice composition.

• RFC 9420, MLS, especially sender-data encryption (§6.3.2), secret trees and deletion (§9), and multiple proposals per Commit (§12).
• RFC 8439, ChaCha20-Poly1305, especially uniqueness requirements for key/nonce use.
• Signal Double Ratchet specification, for asynchronous ratcheting, skipped-key limits, and post-quantum ratchet composition.
• Signal ML-KEM Braid specification, for a potential future sparse ratchet building block; its bidirectional progress and composition assumptions remain explicit.
• Signal PQXDH specification, for asynchronous prepublished-key and single-use-prekey considerations; its authentication choices are not silently inherited here.
• A Concrete Treatment of Efficient Continuous Group Key Agreement via Multi-Recipient PKEs, for recipient-directed delivery and committing encryption.
• CoCoA: Concurrent Continuous Group Key Agreement and The Key Lattice Framework for Concurrent Group Messaging, for concurrency models and their coordination assumptions.
• Revocation and Tracing Schemes for Stateless Receivers, §3.1, for the complete-subtree recipient layout; its static-key results do not establish the single-use ticket or CGKA composition selected in §5.
• Signal sealed sender design, for encrypted sender credentials and delivery without sender-account authentication, with distinct network-correlation limits.
• FIPS 202, for SHAKE256.

Appendix A — Planning parameters

Parameter	Selected research setting
Delivery	Complete-subtree cover with independent one-use node tickets and singleton leaves
Default workload	128 devices, seven spread removals, seven days offline
Inventory	Eight entry tickets per node per producer, including genesis; event budget
Eligible entry authors	One in the default measurement; explicit two-author comparison
Tree repair	New immutable cohort; separately provisioned and metered
Retention	30 days plus referenced dependency closure
Return control target	At most 64 KB with cached identities and provisioned reserves
Return discovery	At most 256 known subsets per lookup batch/path
Private ticket storage	16 MiB raw private keys; 100,000 reference limit
Entropy frontier / pending bytes	16 MiB / 8 MiB initial budgets
Skipped keys	2,000 global / 256 per sender; 30-minute TTL after local derivation
Content signatures	Individual padded Falcon-512, encrypted from infrastructure
Finality	Explicit consistent-history adapter; trusted oracle in research
Service privacy	No decrypting infrastructure or service-visible sender credentials; existing source-IP hiding assumed
History	NONE by default; WINDOW / ALL_RETAINED through separate encrypted grants

Appendix B — Technical terms

These project terms retain their cryptographic meanings.
Algorithm names, field names, source titles, and code identifiers retain their exact forms.

B.1 Roles, objects, and state

Term	Meaning in this specification
Adapter	Component that connects a protocol requirement to a deployment service or another research layer.
Archive capability	Secret or authorization material that permits access to specified archived content.
Audience	Fixed set of credential identities authorized to hold a node's receiving keys.
Author	Device that creates and signs a protocol object.
Backlog	Unread messages and dependencies that remain for a recipient to process.
Bearer capability	Secret token whose possession permits a specified service operation.
Blinding value	Random value in a credential leaf that prevents guessing the leaf hash from known credential fields.
Canonical encoding	One specified byte encoding for a value.
Capsule key	Random key that encrypts the common era entry.
Checkpoint	Authorized record that binds membership, policy, prior history, and the new-state commitment.
Ciphertext	Output of encryption.
Cohort	Ordered set of device credentials with a fixed generation identifier and receiving tree.
Commitment	Cryptographic value that binds specified data without supplying its decryption capability.
Common entry	Encrypted era state that all authorized recipients obtain through their selected wrappers.
Cover	Selected recipient sets whose union is the full roster. An exact cover has no overlap.
Credential	Authenticated identity record with the fields required to verify its owner and membership.
Dependency	Object or state that must be available before another operation can complete.
Dependency closure	An object and every referenced object needed to process it, including indirect dependencies.
Domain separation	Use of distinct labels and contexts so cryptographic outputs have separate purposes.
Enrollment key	Single-use receiving key for private-pool setup.
Entropy contribution	Authenticated delivery of fresh randomness for use in sender updates.
Envelope	Outer protocol structure that carries encrypted content and permitted public fields.
Epoch	General term for a cryptographic state interval. Coppice uses an authenticated era, not a clock round.
Equivocation	Conflicting authenticated objects for the same author, era, role, and sequence.
Era	Group state identified by an authorized checkpoint.
Finality	Decision that fixes a checkpoint under the deployment's declared consistency rule.
Forward secrecy	Protection of consumed content after later state exposure, subject to the stated erasure and retained-capability limits.
Frontier	Retained tree nodes that can derive only the leaves that remain unconsumed.
Generation	Numbered state within a sender lane, or a distinct cohort or inventory instance. The field context identifies which use applies.
Genesis	Initial group state and its setup.
Guardian	Authority that approves membership or scope under the pinned policy.
History grant	Authorized encrypted object that supplies archive capabilities for a specified recipient and range.
Ideal cryptography	Research functionality that models cryptographic behavior without implementing the actual primitive.
Immutable object	Object whose bytes and authenticated context cannot change after creation.
Inventory or pool	Collection of independent tickets prepared for specified recipients, producers, and purposes.
Lane	Sender-specific sequence of authenticated updates and message-key state within an era and role.
Manifest	Signed record that binds a set of descriptors, normally through a Merkle root.
Metadata sibling	Independent metadata output that cannot derive the corresponding payload secret or entropy tree.
Nonce	Context value used to prevent unsafe repetition of a cryptographic operation. Its exact requirement depends on the construction.
Opaque selector	Lookup identifier that does not expose the underlying author or object fields directly.
Oracle	Ideal test functionality. Its internal fixture state is not endpoint or service state.
Outbox	Durable collection of immutable ciphertext objects prepared for publication or retry.
Plaintext	Data before encryption or after authorized decryption.
Producer	Author identity assigned to a ticket pool for creation of the objects that consume its tickets.
Publisher	Authorized audience member that creates and distributes a receiving pool.
Ratchet	State transition that derives new key material and deletes the required earlier secrets.
Roster	Authenticated membership records indexed by stable slots.
Scope	Authenticated statement of a pool's group, node audience, publisher, producer, and purpose.
Sender-secret tree	Symmetric derivation tree for initial sender-lane state. It is separate from the receiving tree.
Sibling output	Independently derived or generated value that cannot regenerate the other outputs from the same setup.
Singleton	Recipient set with one device.
Skipped key	Unconsumed message key retained for a message that has not yet arrived.
Snapshot	Copy of endpoint state at a specified point in the protocol.
Ticket	Independent single-use receiving key pair and its authenticated descriptor.
Tombstone	Retained marker for an empty roster slot or retired identifier. It does not restore erased secret state.
Welcome	Recipient-specific admission object that supplies authorized initial state.
Wire format	Specified encoding of transmitted objects.
Wrapper	Encrypted delivery of a common secret to one selected node or recipient.

B.2 Technical verbs

Verb	Meaning in this specification
Authenticate	Establish the claimed identity or origin under the specified cryptographic rules.
Bind	Cryptographically associate fields so that unauthorized changes fail verification.
Commit state	Make the specified state change durable as one transaction.
Consume	Use a single-use capability, record that use, and erase the required secret in the same transaction.
Decrypt	Use authorized secret material to obtain plaintext from ciphertext.
Derive	Calculate an output from a secret and the specified cryptographic context.
Encapsulate	Use a KEM public key to create a ciphertext and its associated shared secret.
Encrypt	Transform plaintext into ciphertext with the specified key and context.
Hash	Calculate a digest with the specified hash function and context.
Pin	Store a trusted identity, policy, or parameter that untrusted delivery cannot replace.
Provision	Prepare, authenticate, and install the inventory required for later use.
Puncture	Erase a consumed leaf's derivation capability while retaining capabilities for other unused leaves.
Replay	Process retained protocol objects in authenticated dependency order. An unauthorized replay can instead be an attack.
Reserve	Durably assign an unused ticket or counter to one operation before publication.
Revoke	Remove authorization for future operations. Revocation cannot erase copies already held by recipients.
Sign	Produce an individual cryptographic signature over the specified body and context.
Verify	Test a cryptographic object against its required signatures, proofs, bindings, or state rules.

B.3 Abbreviations and other technical names

Name	Meaning
AEAD	Authenticated encryption with associated data.
API	Application programming interface.
CGKA	Continuous group key agreement.
FIPS	Federal Information Processing Standards.
FN-DSA	Name for the NIST signature standard based on Falcon. This draft does not assume format interchangeability.
FS	Forward secrecy; the initial live-protection profile.
IP	Internet Protocol.
JSON	JavaScript Object Notation.
KDF	Key derivation function.
KEM	Key encapsulation mechanism.
MLS	Messaging Layer Security, specified in RFC 9420.
PCS	Post-compromise security: restored secrecy after the required recovery events.
PIR	Private information retrieval.
PQ	Post-quantum.
Atomic transaction	State change that completes as a unit or leaves the prior committed state intact.
Byzantine quorum	Set of agreement participants whose threshold and intersection rules account for malicious participants.
Merkle proof	Hash path that authenticates an included leaf against a root and its required context.
Sybil insertion	Admission of multiple attacker-controlled identities to gain influence or access.
u32 / u64	Unsigned 32-bit / 64-bit integer.

[blacks1ne]

Full disclosure up front: I worked through this spec together with an AI assistant — Anthropic's Fable — and the technical questions below are Fable's work, not mine. I'm no crypto guru; my part was collaborating with it, sanity-checking what I could, and deciding this was worth posting. We hope the questions bring value, but please take them with the grain of salt AI-produced analysis deserves.

With that said: the bandwidth math reproduces everywhere we tested it — the 962-byte slot, the 74/121 KB contributions, the 1.9 KB receiver fetch, the 547 KB/day control plane, the 218 KB sweep, the ~105 expected max shard at d = 7, and the 3%-of-optimal claim for m = 78 all check out. And the self-assessment in §5.4/§12/N7 is unusually honest for a v0.1; it's what makes the document reviewable at all. Questions, roughly ordered by how much the answer would change:

1. Is G2's "forward secrecy at message granularity" actually message-granular, given §9.2's retention? Sender chains derive lazily from spine_enc[E] (§6.3), and the retained window keeps spine_enc for W = 3 rounds. So a device seized at time t yields spine_enc for the last ~30 minutes, from which chain[i,0] for every sender — and hence every message key in the window, including already-consumed positions — is recomputable. Within the window, the intra-chain ratchet-and-delete seems to add nothing against seizure; effective FS granularity looks like W × T_round, with per-message FS holding only for epochs older than the window. (§6.4's inventory of what a seizure yields omits retained spine_enc, which may be the same oversight.) Is the fix as cheap as it looks — eagerly derive all n sender roots at epoch advance (320 KB and a few ms of SHAKE at n = 10⁴), delete spine_enc immediately, and retain only chain heads and skipped keys? The one edge we see is a mid-epoch joiner's first sends, whose chain root receivers could no longer derive — but that's bounded by one round of NACK.

2. Why t = ⌈m/3⌉+1, when disjoint quorums are exactly the §5.4 failure mode? At m = 78, t = 27, a clean 39/39 partition lets both halves produce validly-attested but conflicting re-anchors (or removals) with no dishonest signer at all — the same divergence the WOTS⁺ fallback exists to rescue. §10.2 does concede a partitioned view is a security failure, but this instance is silent and cheap to prevent: majority attestation (t = 40) makes any two conflicting attestation sets intersect, so equivocation requires a member signing both — detectable and attributable, which matches the design's own philosophy in §7.3. Cost is ~27.6 KB vs 18.9 KB on an infrequent event. Is ⌈m/3⌉+1 chosen for liveness under a heavy offline fraction, and if so is that trade worth stating explicitly?

3. Split view on ShardPublications. §5.4's third mitigation says reuse detection is trivial "for the delivery service and for any member" — but the DS is adversarial in §10.1 and can equivocate: show one of the two conflicting publications to a victim spine contributor and the other to everyone else, defeating detect-and-re-anchor precisely when it matters. The roster gets a transparency log for exactly this class of attack; should shard publications be committed into the same KT structure (or gossiped member-to-member, out of band of the DS) so a split view is auditable? §12.2's scope arguably includes the publication chain, not just the roster.

4. What authorizes a join? In §8.4 the joiner publishes keys and the roster increments — there's no authorization object anywhere in the spec, and contributors encapsulate to whatever roster they see. Is the intent that KT identity-binding plus an out-of-protocol invite carries this (as the M6 discussion seems to imply), or should an existing-member signature over the addition be a spec-level object? This also composes with §12.5's join-flood.

5. Sequencing. Appendix B's lineage is recognizably the channel crate's triple ratchet (Ed448 + Feldman), which is classical ECC and therefore harvest-exposed today. Is Coppice the intended successor for Quorum's group channels on the mainnet path — spec first, then a crate — or a research track alongside 2.1.x? And in a Quilibrium deployment, what plays the DS/roster-authority role — is the roster meant to live as on-network state, with the hypergraph as the KT log? That answer bears directly on 3 and 4.

Two things we'd simply endorse: folding M1 (encrypted sender data) into the base spec, as Appendix C already argues, and the NTRU+X25519 hybrid from Appendix E §6.1 — at ~3% contribution cost it closes the one place PQ MLS is unambiguously more conservative.

Obvious caveat: none of this is cryptanalysis. The NTRU/Falcon/WOTS⁺ choices — especially the §5.4 chain — deserve professional eyes and ideally a CGKA-style formal treatment. These are consistency questions from a careful read, not a certification.

[blacks1ne]

We reviewed v0.4 (editorial revision 1). It resolves most of what we raised on v0.1: the spine_enc window is gone (§4.2), the ceil(m/3)+1 rule and the WOTS⁺ chain are dropped, admission and identity recovery need independent authorization (§2.1, §7.1), and header keys now derive from the body ciphertext (§8.2). Our July comments refer to v0.1. Seven points remain, each with a proposed change:

1. Recovery depends on pre-provisioned shared pools. Each device holds the private tickets of every node containing it, root included, provisioned for several eras (Appendix A). Copying one device once opens every later entry wrapped to those nodes, and §5.3 prefers the largest nodes. Since §10.1 requires replacing the compromised capabilities, an undetected compromise heals only through a rebuild with all survivors online (§5.4). Proposal: a self-rotation that removes and re-admits the device's own credential (fresh local singleton pool, all old nodes containing it excluded, about tree-depth wrappers, nobody else online), run on the recovery schedule, plus a maximum ticket age in eras.

2. Recipients cannot verify a removal. §5.3 leaves the complete, disjoint cover check to an authorization layer that §3.1 forbids from seeing the roster. A faulty author can keep wrapping to an old node containing the removed device, or drop a member, and nobody notices. Proposal: an active-slot bitmap in the checkpoint, the cover list (node, audience slots, ticket) in the common entry, and a rule that every recipient verifies the cover partitions the active slots before installing.

3. One offline member can block every removal. After a sibling's removal, a retained member's singleton leaf is in every later cover; with eight tickets per producer it runs dry within a few eras, and §7.3 then holds every removal until that member returns. Proposal: let an authorized transition mark an uncoverable member "pending re-entry"; on return it provisions a fresh singleton pool and the next entry covers it. Removing one member should never wait on another's inventory.

4. Racing checkpoints. The text does not say what happens to a proposal that loses finality (its reserved tickets are burned; holders keep the private keys), or to a finalized checkpoint whose authorization fails. A member allowed to renew can win races against a pending removal and drain the remover's pools. Proposal: the canonical successor is the first finalized checkpoint for a predecessor whose authorization verifies; renewals must carry pending authorized removals; take the sequence slot from the adapter before reserving tickets. For a Quilibrium deployment, please also state the adapter: who submits checkpoints without an identifying account, and which signer set answers freshness.

5. Removed members keep metadata and store access (§6.3). Proposal: derive selectors and control-envelope keys from per-node lookup keys delivered in each node's pool; a removed device held only nodes that later covers exclude. Rotate a control-store write capability in each entry, like the submission capability.

6. Header key identifiers link senders. header_key_id = contribution_id is public (§8.1, §8.2); a sender that alone adopts a contribution tags all its messages with it. Proposal: switch header keys per era or through a finalized metadata step that all senders follow.

7. Hybrid key establishment. §1.1 excludes a hybrid without a reason. NTRU-HPS-2048-677 was not standardized, and the repository already ships sntrup761 and Falcon-512. Proposal: an X-Wing-style combiner (X25519 + ML-KEM-768, or + sntrup761), with the wrapper key derived from both shared secrets, both ciphertexts, the ticket public key and the checkpoint. Even without a hybrid, specify that derivation.

Smaller: §6.2 should say that after installing a removal, receivers reject old-era messages from removed lanes and accept other old-era messages only within a stated bound.