From 279f0c2878f69a6d1419bda7bc84dbc5fbb10b41 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 28 Apr 2026 12:08:28 +1000 Subject: [PATCH 1/4] template: add Threat Model & Security Requirements section Add a top-level section to the RFP template listing common privacy/security scenarios grouped by adversary class (O, A, C, S, F, X), each with stable codes that protocol-specific scenarios extend. Add appendix/logos-stack-trust-assumptions.md as a dated snapshot (2026-04-28) of the five component FURPS at roadmap.logos.co, with verbatim citations and a distilled list of what RFPs can rely on vs must not assume. Retarget Supportability item 9 so the privacy and anonymisation document must address every Threat Model scenario. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-000-template.md | 212 ++++++++++++++- appendix/logos-stack-trust-assumptions.md | 306 ++++++++++++++++++++++ 2 files changed, 511 insertions(+), 7 deletions(-) create mode 100644 appendix/logos-stack-trust-assumptions.md diff --git a/RFPs/RFP-000-template.md b/RFPs/RFP-000-template.md index 7f62fdd..0d547d5 100644 --- a/RFPs/RFP-000-template.md +++ b/RFPs/RFP-000-template.md @@ -94,19 +94,217 @@ Standard requirements (adapt as needed): 7. Submit a [doc packet](https://github.com/logos-co/logos-docs/issues/new?template=doc-packet.yml) for the CLI, covering the core operator/user journey. 8. Provide Figma designs or equivalent for all GUI artifacts. -9. Provide a privacy and anonymisation properties document covering: - what on-chain state and transaction data is visible to observers; - what data is protected when the private account path is used; - trust assumptions, specifying which guarantees are enforced by - the on-chain program and which depend on correct client - behaviour; and what happens if a user bypasses the expected - interaction path. +9. Provide a privacy and anonymisation properties document that + addresses every scenario listed in the Threat Model & Security + Requirements section. For each scenario, the document must state + how it is defended (test reference, formal argument, or program + invariant) or explicitly mark it out of scope with rationale. ### Soft Requirements Explain all the optional soft requirements of the RFP in points. +## 🛡️ Threat Model & Security Requirements + +This section enumerates the adversaries and scenarios the implementation +must protect against. Each numbered scenario is a testable hard +requirement. The proposal must respond to each scenario with one of: + +- a corresponding test or formal argument that the scenario is + defended, +- an explicit out-of-scope acknowledgement with rationale, or +- a documented trust assumption inherited from the Logos stack (see + below). + +Supportability item 9 (privacy and anonymisation properties document) +must address every scenario listed here in the same form. + +The threat model is scoped to what the delivered application stack +(on-chain program, SDK, mini-app) controls. Properties of the +underlying Logos platform are inherited as trust assumptions and are +not the responsibility of this RFP. + +### Trust assumptions inherited from the Logos stack + +The proposal inherits the trust assumptions documented in +[`appendix/logos-stack-trust-assumptions.md`](../appendix/logos-stack-trust-assumptions.md). +That appendix is a dated snapshot of the +[stack FURPS](https://roadmap.logos.co) and lists both what an RFP can +rely on (programmable privacy, sequencer behaviour, indexer +correctness, blockchain finality, block proposer privacy) and what an +RFP must not assume (anonymous transaction submission at the network +layer, mempool privacy, anonymous RPC queries, off-chain storage +privacy for LEZ state, sequencer-level censorship resistance, side +channels). + +The proposal must not claim to defend against weaknesses in the +inherited assumptions. The proposal must not claim to inherit a +guarantee that the snapshot does not commit to. + +If the proposal depends on a specific FURPS item, it must cite the +item by component and number (e.g., "relies on +`lez:programmable-privacy.22`") so that reviewers can verify the +dependency against the snapshot. + +### Adversary classes + +Scenarios are grouped by adversary class and identified by a stable +code (e.g., `O-1`) so other documents and reviews can reference them. +RFP authors must keep the common scenarios verbatim and add +protocol-specific scenarios within the relevant adversary class, +continuing the numbering. + +- **O. On-chain observer.** Reads all public on-chain state and the + full transaction history touching the program. Also sees any + user-correlatable patterns the SDK or mini-app produce through RPC + and indexer queries, since the application chooses those query + patterns. Does not submit transactions. +- **A. Active on-chain attacker.** Submits arbitrary transactions, + deploys other programs, pays priority fees, and controls multiple + addresses. Tries to break the program's invariants. +- **C. Malicious counterparty.** A user the victim transacts with + directly through the program: trade counterparty, LP, borrower, + lender, launchpad participant, swap maker. +- **S. Sequencer with elevated visibility.** The LEZ sequencer + receives, orders, and posts user transactions. The stack does not + commit to non-censorship or to non-correlation against the + sequencer. The application controls what it reveals to the + sequencer beyond what is unavoidable, and what its safety depends + on. +- **F. Malicious or buggy client.** A user runs a hostile mini-app, a + third-party SDK, or hand-crafted transactions that bypass the + official SDK. +- **X. External identity correlator.** Holds off-chain data (CEX KYC, + IP logs, social graph, public wallet labels) and tries to link it + to on-chain activity. + +### Common scenarios + +The following scenarios apply to every Logos RFP that supports private +account interaction. Each implementation must protect against them or +explicitly document them as out of scope or inherited. + +#### O. On-chain observer + +1. **O-1.** Given a series of operations executed via the + deshield→interact→re-shield pattern, the observer cannot determine + which private account originated the funds for any operation from + on-chain state alone. +2. **O-2.** Given two operations from the same private-account user, + the observer cannot link them on-chain. The program does not store + any field that joins two ephemeral accounts to a common owner. +3. **O-3.** Given an ephemeral public account used for one operation, + the observer cannot link it to the destination private account + that receives the re-shielded output. +4. **O-4.** The program's account layout, transaction structure, and + event emissions do not include identifiers, salts, or correlatable + metadata that would let an observer cluster operations by + originating private account. +5. **O-5.** The SDK and mini-app do not issue RPC or indexer queries + that re-link ephemeral accounts to a common owner (e.g., a + batched lookup that names multiple ephemeral accounts in a + single request, or a query that pairs an ephemeral account with + the user's private-account identifier). RPC-level anonymity is + not inherited from the stack; the application minimises leakage + through call patterns. + +#### A. Active on-chain attacker + +1. **A-1.** The attacker cannot drain protocol funds, mint phantom + positions, or corrupt protocol state via reentrancy, race + conditions, compute-budget exhaustion, or arithmetic overflow. +2. **A-2.** The attacker cannot bypass authority checks (admin, + freeze, role-gated operations) by forging signatures, replaying + transactions, or substituting accounts. +3. **A-3.** The attacker cannot front-run, sandwich, or otherwise + target a victim by linking the victim's on-chain identity to a + transaction. Identity-linked attacks (wallet profiling, repeated + targeting of the same victim) must be impossible when the victim + uses the deshield→interact→re-shield pattern. Size-based or + pool-state-based attacks (sandwiching, back-running) that do not + rely on identity are out of scope unless the RFP explicitly states + otherwise. + +#### C. Malicious counterparty + +1. **C-1.** A counterparty cannot steal funds mid-settlement. Every + protocol-mediated exchange must complete atomically or fully + revert. +2. **C-2.** A counterparty cannot grief the user by leaving funds + locked, stranded in an ephemeral account, or recoverable only via + privileged intervention. + +#### S. Sequencer with elevated visibility + +1. **S-1.** Program safety must not depend on the sequencer behaving + honestly. A malicious or compromised sequencer that censors, + reorders, or delays transactions can cause liveness loss but + cannot mint, steal, or corrupt protocol state. +2. **S-2.** Information the sequencer learns from a user's + transaction submission (transaction contents, the user's network + identity at submission time, pre-confirmation ordering) does not + exceed what is already visible on-chain. The program does not + place additional user-correlatable metadata in fields the + sequencer reads but the chain does not commit. + +#### F. Malicious or buggy client + +1. **F-1.** The on-chain program rejects any transaction that + violates protocol invariants regardless of how the transaction is + constructed. Integrity guarantees do not depend on SDK or + mini-app correctness. Where privacy depends on client behaviour + (e.g., the deshield→interact→re-shield pattern), the proposal + states this explicitly and the SDK enforces the pattern as a + single indivisible user action. +2. **F-2.** The SDK rejects privacy-breaking inputs by construction: + re-shielding to a public account, reusing an ephemeral account, + funding an ephemeral account from an external source, or + splitting a single conceptual operation across multiple + user-visible signing steps. + +#### X. External identity correlator + +1. **X-1.** Funding the ephemeral public account from any source + other than the atomic deshield (e.g., a CEX withdrawal, a + transfer from an existing wallet) creates an on-chain link to a + known identity and breaks the privacy guarantee. The SDK makes + external funding impossible by construction. The deshield + (operation token plus gas) is a single indivisible user action. +2. **X-2.** The mini-app and documentation make the privacy + boundaries explicit, identifying which user actions preserve + unlinkability and which actions break it (re-shielding to a + known wallet, sending re-shielded funds to a CEX, signing with a + publicly attested key). + +### Protocol-specific scenarios + +RFP authors must append protocol-specific scenarios under the +relevant adversary class, continuing the numbering. Use the same +format: a concrete adversary capability, a clear scenario, and the +testable defence. + +Examples of where protocol-specific scenarios commonly apply: + +- Oracle-dependent protocols (lending, perpetuals): A-class + scenarios for oracle manipulation and liquidation-driven MEV. +- Launchpad and auction protocols: C-class scenarios for griefing + the price discovery process; F-class scenarios for sniping + protections. +- DEXes: A-class scenarios that document the boundary between + identity-linked attacks (in scope) and pool-state attacks (out of + scope by default). +- Protocols sensitive to ordering: S-class scenarios documenting + whether the program's correctness depends on sequencer ordering + or only on chain-finalised order. + +Scenarios that the proposal treats as out of scope (e.g., +side-channel correlation via transaction timing, sandwich attacks +based purely on pool state, network-layer observability of +transaction submission, key-loss recovery) must still be listed with +explicit rationale rather than omitted. + + ## 👤 Recommended Team Profile Signal the bar without gatekeeping. Mention all the areas where the applying should ideally have experience with. Examples: diff --git a/appendix/logos-stack-trust-assumptions.md b/appendix/logos-stack-trust-assumptions.md new file mode 100644 index 0000000..eb1ee24 --- /dev/null +++ b/appendix/logos-stack-trust-assumptions.md @@ -0,0 +1,306 @@ +# Logos Stack Trust Assumptions for RFPs + +**Snapshot date:** 2026-04-28 +**Source:** [roadmap.logos.co](https://roadmap.logos.co), tracked at +[github.com/logos-co/roadmap](https://github.com/logos-co/roadmap) + +This appendix captures what the Logos technology stack commits to in +its FURPS documents as of the snapshot date, so that RFPs can scope +their privacy and security requirements correctly. RFPs should not +claim to defend against things the stack already guarantees, and must +not claim to inherit guarantees the stack does not commit to. + +The snapshot is intentionally narrow: each entry quotes the FURPS +language verbatim and links to the exact commit-dated source. When the +stack FURPS evolve, this appendix should be re-snapshotted before the +next batch of RFPs is updated. + +## Sources reviewed + +| Component | File | Last updated | Source | +|-----------|------|--------------|--------| +| Blockchain / LEZ | `blockchain/furps/index.md` | 2026-03-23 | [link](https://github.com/logos-co/roadmap/blob/v4/content/blockchain/furps/index.md) | +| AnonComms (overview) | `anoncomms/furps/index.md` | 2025-12-01 | [link](https://github.com/logos-co/roadmap/blob/v4/content/anoncomms/furps/index.md) | +| AnonComms Mix | `anoncomms/furps/mix.md` | 2026-04-08 | [link](https://github.com/logos-co/roadmap/blob/v4/content/anoncomms/furps/mix.md) | +| AnonComms RLN | `anoncomms/furps/rln.md` | 2026-03-24 | [link](https://github.com/logos-co/roadmap/blob/v4/content/anoncomms/furps/rln.md) | +| Logos Core | `logoscore/furps/logos-core.md` | 2025-12-15 | [link](https://github.com/logos-co/roadmap/blob/v4/content/logoscore/furps/logos-core.md) | +| Messaging (Waku) overview | `messaging/furps/index.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/index.md) | +| Messaging Mix | `messaging/furps/core/mix.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/core/mix.md) | +| Messaging RLN Relay | `messaging/furps/core/rln_relay.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/core/rln_relay.md) | +| Storage privacy filesharing | `storage/furps/privacy-preserving-filesharing-furps.md` | 2026-04-08 | [link](https://github.com/logos-co/roadmap/blob/v4/content/storage/furps/privacy-preserving-filesharing-furps.md) | +| Storage anonymous downloads | `storage/furps/anonymous-downloads-over-mix.md` | 2026-04-08 | [link](https://github.com/logos-co/roadmap/blob/v4/content/storage/furps/anonymous-downloads-over-mix.md) | + +## What each component commits to + +### Blockchain and LEZ + +The Blockchain FURPS commits to the following items relevant to RFP +threat modelling. Quotations are verbatim. + +**Blockchain consensus and propagation:** + +- "Leaders can propose blocks privately" + (`blockchain:ppos.2`) +- "Leaders can claim block rewards without revealing their block + proposal" (`blockchain:ppos.3`) +- "Censorship resistance against malicious broadcasters" + (`blockchain:ppos.6`) +- "Blend edge node privacy" (`blockchain:ppos.7`) +- "Distributed block building. Enabling tagging attack resistance and + removing the leader as SPOF" (`blockchain:block-building.21`) + +**LEZ programmable privacy:** + +- "LEZ supports Programmable Privacy by allowing LEZ Programs to be + agnostic as to whether they are interacting with private or public + accounts" (`lez:programmable-privacy.22`) +- "The same LEZ Programs can be used in both private and public + execution contexts" (Usability `lez.7`) + +**LEZ sequencer:** + +- "LEZ Sequencer accepts transactions from users, orders them and + posts them to Logos Blockchain" (`lez:sequencer.23`) +- "Sequencer manages pending vs. safe vs. confirmed transactions" + (`lez:sequencer.24`) +- "Sequencer maintains funds to pay for blockchain transactions" + (`lez:sequencer.25`) +- "LEZ Sequencer supports decentralized sequencing through Blockchain + enforced sequencer coordination, ensuring crash tolerance" + (Reliability `lez.4`) + +**LEZ indexer and RPC:** + +- "Indexer follows LEZ channel in blockchain" (`lez:indexer.26`) +- "Indexer validates messages in the channel, skips invalid + messages" (`lez:indexer.27`) +- "Indexer maintains state history" (`lez:indexer.29`) +- "Indexer provides RPC endpoints for querying LEZ state" + (`lez:indexer.30`) + +**LEZ program model:** + +- "Programs have defined interface exposing input/output accounts and + contextual information (block number, random oracle, etc.)" + (`lez:program-interface.31`) +- "Programs can call other programs deployed on LEZ" + (`lez:cross-program-calls.32`) + +**LEZ bridging:** + +- "Channel Balance management" (`lez:bridging.33`) +- "Sequencer signing on withdrawal" (`lez:bridging.34`) +- "User deposits from Blockchain to LEZ" (`lez:bridging.35`) + +**Blockchain liveness and finality:** + +- "Blockchain prioritizes liveness over safety ensuring we are + resilient to large network failures" (Reliability `blockchain.1`) +- "Blockchain provides 18hrs for failures to resolve before the chain + may split requiring manual intervention" (Reliability + `blockchain.2`) +- "Blockchain finalizes transactions in 18hrs" (Performance + `blockchain.1`) +- "Practical finality can be achieved much sooner" (Performance + `blockchain.2`) +- "Blocks are produced on average every 30s" (Performance + `blockchain.3`) + +What the Blockchain / LEZ FURPS does **not** commit to: + +- No statement that LEZ user transactions submitted to the sequencer + are routed over an anonymising mixnet. +- No statement about mempool or pre-confirmation observability for + third parties. +- No statement that Indexer RPC queries are anonymised or that the + caller of an RPC query is unlinkable from the address being queried. +- No statement about availability or privacy of off-chain storage + used by LEZ programs. + +### AnonComms + +The AnonComms component delivers a mix protocol and an RLN service. +Critically, the AnonComms FURPS describes integration targets but does +**not** list LEZ transaction submission as one of them. + +**Mix integration targets** (`anoncomms/furps/mix.md`): + +- "The libp2p mix protocol with DoS and Sybil protection is + integrated in nim-libp2p" (Usability `mix.2`) +- "The libp2p mix protocol with DoS and Sybil protection is + integrated into Waku Lightpush protocol as reference integration" + (Usability `mix.3`) +- "A libp2p module with mix capability is integrated into Logos + Core" (Usability `mix.4`) +- "The libp2p mix protocol is integrated into the Logos Chat module" + (Usability `mix.12`) + +**Mix functional properties:** + +- "The libp2p mixnet is protected against trivial DoS attacks" + (`mix.3`) +- "The libp2p mixnet is protected against a 50% + 1 Sybil attack" + (`mix.4`) +- "Nodes can generate cover traffic to increase K-anonymity in the + mixnet" (`mix.10`) +- "Providers can anonymously register as a hidden service" + (`mix.11`) +- "Clients can discover and anonymously access hidden services" + (`mix.12`) + +**RLN:** + +- "An RLN membership allocation service can register ID commitments + on behalf of third parties" (`rln.1`) +- "Logos modules can use the service as client to obtain adequate + registered RLN identities without interacting with the contract" + (`rln.3`) +- "The RLN contract is implemented for Logos Execution Zone" + (Usability `rln.3`) + +What AnonComms does **not** commit to: + +- LEZ transaction submission (user → sequencer) is not listed as a + Mix integration target. An RFP cannot assume that transactions + submitted to LEZ via the Logos Core wallet are anonymised at the + network layer. + +### Logos Core + +Logos Core (`liblogos`) is a minimal Qt-based module loader. + +- "The library shall enable loading and unloading of modules" + (Functionality `logos-core.1`) +- "The library shall provide a central QObject Registry" + (Functionality `logos-core.2`) +- "The library shall minimally facilitate the Qt event loop without + providing additional functionalities (such as transports, UI, + networking) directly" (Functionality `logos-core.5`) + +What Logos Core does **not** commit to: + +- It is explicitly not a transport or networking layer. Anonymity, + privacy, and security properties for an RFP do not come from Logos + Core itself; they come from the modules that an RFP composes. + +### Messaging (Waku) + +Messaging FURPS (dated 2025-11-13) commits to a Waku-based stack with +its own Mix and RLN. Relevant items for RFPs that use Waku: + +- Mix at the messaging layer: "Relay nodes can mount mixnet protocol, + acting as sender, intermediary or exit nodes" (`messaging:mix.1`) +- RLN Relay for spam protection at the messaging layer: + "Relay node can attach RLN proof for outbound messages" + (`rln_relay.2`); "Relay node can verify RLN proof for inbound + messages" (`rln_relay.3`) +- Store: "Provides historical message retrieval from the relay + network" (`store.1`) +- Store explicit limitation: "(limitation) No guarantees in terms of + message presence or retention duration" (Reliability `store.2`) + +Messaging is a separate sub-system from LEZ. RFPs that use Waku for +out-of-band communication (e.g., a chat-style interaction layer) +inherit these properties; RFPs that interact only with LEZ programs do +not. + +### Storage + +Storage FURPS (dated 2026-04-08) define privacy properties for +Codex-based filesharing. + +- "Neither the identity of publishers nor that of downloaders should + be revealed to other participants; i.e., we want full publisher and + downloader unlinkability. This includes queries" + (`privacy-preserving-filesharing-furps`, Security 1) +- "Cache nodes should be able to plausibly deny knowledge of the + contents they are caching" (`privacy-preserving-filesharing-furps`, + Security 2) +- "The node downloading the file should not be linkable to the + download. Note that the node that provides the file is not + anonymized here" (`anonymous-downloads-over-mix`, Security 1) + +Storage is a separate sub-system from LEZ. RFPs that use Codex for +file or asset distribution inherit these properties for the file +distribution path. They do not extend to LEZ on-chain state. + +## Stack-wide trust assumptions an RFP can rely on + +These are the consolidated assumptions an RFP for an LEZ program (and +its SDK / mini-app) can rely on without needing to re-prove them. + +1. **Programmable privacy works as specified.** LEZ private accounts + provide the cryptographic unlinkability properties advertised by + the underlying primitives. The same program logic runs in both + private and public contexts. +2. **The LEZ sequencer behaves as specified.** It accepts + transactions, orders them, posts them to Logos Blockchain, and + manages the pending / safe / confirmed transaction lifecycle. It + tolerates crashes through state persistence. Decentralised + sequencing is enforced by the blockchain. +3. **The LEZ indexer is correct.** It validates messages, skips + invalid ones, applies blocks to local state, maintains history, + and exposes RPC endpoints with content that reflects committed + chain state. +4. **Blockchain liveness and finality.** Transactions finalise within + 18 hours; practical finality is achieved sooner; blocks every 30 + seconds on average. +5. **Block proposer privacy.** Logos Blockchain leaders propose + blocks privately and claim rewards without revealing their + proposal. The blockchain is censorship-resistant against malicious + broadcasters at the consensus layer. +6. **LEZ bridging primitives.** Deposits from Blockchain to LEZ and + sequencer-signed withdrawals from LEZ are provided by the + platform. +7. **Program model.** Programs can read input/output accounts and + contextual data (block number, random oracle), and can call other + programs. + +## Stack-wide non-guarantees an RFP must not assume + +These are properties that, as of the snapshot date, the stack FURPS +do **not** commit to. RFPs that need them must either treat them as +out-of-scope explicitly or design around them at the application +layer. + +1. **No anonymous LEZ transaction submission at the network layer.** + The AnonComms Mix integration list does not include LEZ transaction + submission. An LEZ transaction sent to the sequencer is observable + on the network path and the sequencer learns the submitter's + network identity. +2. **No mempool / pre-confirmation privacy.** The sequencer is + documented to manage pending / safe / confirmed transactions. + There is no commitment that the pending state is hidden from + third-party observers (sequencer operators, indexer operators, + sophisticated network observers). +3. **No anonymous indexer RPC queries.** The indexer exposes RPC + endpoints for querying LEZ state. There is no commitment that the + originator of a query is unlinkable from the address being + queried, or that an RPC operator cannot correlate a sequence of + queries to a single user. +4. **No off-chain storage privacy by default for LEZ state.** Storage + FURPS apply to the Codex filesharing stack, not to LEZ on-chain + state nor to private-account witness data unless an RFP + explicitly composes Codex for that purpose. +5. **Censorship resistance is at the consensus layer, not the + sequencer.** "Censorship resistance against malicious + broadcasters" applies to block propagation. There is no equivalent + commitment that the LEZ sequencer cannot censor or reorder + user transactions. +6. **No commitment about side channels.** Transaction timing, gas + patterns, account size, and similar side channels visible on + public chain state are not addressed by any FURPS. + +## How RFPs should use this appendix + +RFPs that build on LEZ should: + +- Assume guarantees only from the "Stack-wide trust assumptions" + list above. +- Treat anything in the "Non-guarantees" list as either explicitly + out of scope or as a problem the application layer must address. +- Cite the specific FURPS item by component and number when relying + on a guarantee, so reviewers can verify against this snapshot. + +When the underlying FURPS change, this appendix must be re-validated +before its trust assumptions are referenced in new RFPs. From c25c3db7f199b5cf4c1bccf200cf35c2cc064a9e Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 28 Apr 2026 12:21:42 +1000 Subject: [PATCH 2/4] template: generalise threat model to the whole Logos stack MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Rework the Threat Model section so it covers any application built on any part of the Logos stack, not only LEZ programs. Adversary classes are stack-wide: - N (Network observer): any public surface the app touches - A (Active attacker): any layer - C (Malicious counterparty): any user-mediated exchange - P (Platform operator with elevated visibility): sequencer, Waku store/relay, Codex cache/provider, RPC, RLNaaS — replaces the prior LEZ-specific S - F (Malicious or buggy client): any client surface - X (External identity correlator): any cross-system linkage Common scenarios are component-agnostic. Component-specific scenarios move to dedicated subsections (Blockchain/LEZ, AnonComms, Logos Core, Messaging/Waku, Storage/Codex) that apply only when the RFP declares the component in a new "Stack components consumed" subsection. The deshield→interact→re-shield language and ephemeral-account hygiene now live under L-1..L-6 in the LEZ-specific section instead of in the common scenarios. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-000-template.md | 394 +++++++++++++++++++++++++-------------- 1 file changed, 258 insertions(+), 136 deletions(-) diff --git a/RFPs/RFP-000-template.md b/RFPs/RFP-000-template.md index 0d547d5..3ec4fde 100644 --- a/RFPs/RFP-000-template.md +++ b/RFPs/RFP-000-template.md @@ -107,9 +107,10 @@ Explain all the optional soft requirements of the RFP in points. ## 🛡️ Threat Model & Security Requirements -This section enumerates the adversaries and scenarios the implementation -must protect against. Each numbered scenario is a testable hard -requirement. The proposal must respond to each scenario with one of: +This section enumerates the adversaries and scenarios the +implementation must protect against. Each numbered scenario is a +testable hard requirement. The proposal must respond to each scenario +with one of: - a corresponding test or formal argument that the scenario is defended, @@ -121,22 +122,32 @@ Supportability item 9 (privacy and anonymisation properties document) must address every scenario listed here in the same form. The threat model is scoped to what the delivered application stack -(on-chain program, SDK, mini-app) controls. Properties of the -underlying Logos platform are inherited as trust assumptions and are -not the responsibility of this RFP. +(programs, modules, SDKs, mini-app) controls. Properties of the +underlying Logos platform are inherited as trust assumptions. + +### Stack components consumed + +The proposal must declare which Logos stack components the application +consumes. The relevant component-specific scenarios then apply in +addition to the common scenarios. Tick all that apply: + +- [ ] **Blockchain / LEZ**: programs, sequencer, indexer, wallet, + bridging. +- [ ] **AnonComms**: Mix transport, RLN identity service. +- [ ] **Logos Core**: module loader, QObject Registry, Process + Manager. +- [ ] **Messaging (Waku)**: Relay, Light Push, Store, RLN Relay, + messaging SDK. +- [ ] **Storage (Codex)**: privacy-preserving filesharing, + anonymous downloads. ### Trust assumptions inherited from the Logos stack The proposal inherits the trust assumptions documented in [`appendix/logos-stack-trust-assumptions.md`](../appendix/logos-stack-trust-assumptions.md). That appendix is a dated snapshot of the -[stack FURPS](https://roadmap.logos.co) and lists both what an RFP can -rely on (programmable privacy, sequencer behaviour, indexer -correctness, blockchain finality, block proposer privacy) and what an -RFP must not assume (anonymous transaction submission at the network -layer, mempool privacy, anonymous RPC queries, off-chain storage -privacy for LEZ state, sequencer-level censorship resistance, side -channels). +[stack FURPS](https://roadmap.logos.co) and lists, per component, both +what an RFP can rely on and what an RFP must not assume. The proposal must not claim to defend against weaknesses in the inherited assumptions. The proposal must not claim to inherit a @@ -144,145 +155,252 @@ guarantee that the snapshot does not commit to. If the proposal depends on a specific FURPS item, it must cite the item by component and number (e.g., "relies on -`lez:programmable-privacy.22`") so that reviewers can verify the -dependency against the snapshot. +`lez:programmable-privacy.22`" or "relies on `messaging:rln_relay:F.3`") +so that reviewers can verify the dependency against the snapshot. ### Adversary classes Scenarios are grouped by adversary class and identified by a stable -code (e.g., `O-1`) so other documents and reviews can reference them. +code (e.g., `N-1`) so other documents and reviews can reference them. RFP authors must keep the common scenarios verbatim and add -protocol-specific scenarios within the relevant adversary class, -continuing the numbering. - -- **O. On-chain observer.** Reads all public on-chain state and the - full transaction history touching the program. Also sees any - user-correlatable patterns the SDK or mini-app produce through RPC - and indexer queries, since the application chooses those query - patterns. Does not submit transactions. -- **A. Active on-chain attacker.** Submits arbitrary transactions, - deploys other programs, pays priority fees, and controls multiple - addresses. Tries to break the program's invariants. -- **C. Malicious counterparty.** A user the victim transacts with - directly through the program: trade counterparty, LP, borrower, - lender, launchpad participant, swap maker. -- **S. Sequencer with elevated visibility.** The LEZ sequencer - receives, orders, and posts user transactions. The stack does not - commit to non-censorship or to non-correlation against the - sequencer. The application controls what it reveals to the - sequencer beyond what is unavoidable, and what its safety depends - on. +component-specific and protocol-specific scenarios within the +relevant adversary class, continuing the numbering. + +- **N. Network observer.** Reads everything visible on the public + surfaces the application touches: on-chain state and transactions; + Waku messages, topics, and metadata; Codex content delivery and DHT + queries; indexer and RPC traffic; client-issued query patterns. Does + not actively interfere. +- **A. Active attacker.** Submits transactions, messages, queries, + uploads. Deploys programs, runs malicious peer nodes (Waku store or + relay, Codex cache or provider, RPC endpoints, sequencer-attached + infra). Pays priority fees. Controls multiple identities. Tries to + break protocol invariants or coerce malicious responses. +- **C. Malicious counterparty.** A user or peer the victim transacts, + communicates, or exchanges with directly through the application: + trade counterparty, LP, lender, launchpad participant, chat peer, + swap maker, content publisher. +- **P. Platform operator with elevated visibility.** A node or + operator the application routes through and trusts for liveness + only: LEZ sequencer; Waku store, relay, or RLNaaS provider; Codex + cache or provider; indexer or RPC operator. The stack does not + commit to non-correlation against these operators; the application + chooses what it reveals to them and what it depends on them for. - **F. Malicious or buggy client.** A user runs a hostile mini-app, a - third-party SDK, or hand-crafted transactions that bypass the - official SDK. + third-party SDK, or hand-crafted requests that bypass the official + client. - **X. External identity correlator.** Holds off-chain data (CEX KYC, - IP logs, social graph, public wallet labels) and tries to link it - to on-chain activity. + IP logs, social graph, public address labels, leaked address books) + and tries to link it to application activity. ### Common scenarios -The following scenarios apply to every Logos RFP that supports private -account interaction. Each implementation must protect against them or +The following scenarios apply to every Logos RFP regardless of which +components it uses. Each implementation must protect against them or explicitly document them as out of scope or inherited. -#### O. On-chain observer - -1. **O-1.** Given a series of operations executed via the - deshield→interact→re-shield pattern, the observer cannot determine - which private account originated the funds for any operation from - on-chain state alone. -2. **O-2.** Given two operations from the same private-account user, - the observer cannot link them on-chain. The program does not store - any field that joins two ephemeral accounts to a common owner. -3. **O-3.** Given an ephemeral public account used for one operation, - the observer cannot link it to the destination private account - that receives the re-shielded output. -4. **O-4.** The program's account layout, transaction structure, and - event emissions do not include identifiers, salts, or correlatable - metadata that would let an observer cluster operations by - originating private account. -5. **O-5.** The SDK and mini-app do not issue RPC or indexer queries - that re-link ephemeral accounts to a common owner (e.g., a - batched lookup that names multiple ephemeral accounts in a - single request, or a query that pairs an ephemeral account with - the user's private-account identifier). RPC-level anonymity is - not inherited from the stack; the application minimises leakage - through call patterns. - -#### A. Active on-chain attacker - -1. **A-1.** The attacker cannot drain protocol funds, mint phantom - positions, or corrupt protocol state via reentrancy, race - conditions, compute-budget exhaustion, or arithmetic overflow. -2. **A-2.** The attacker cannot bypass authority checks (admin, - freeze, role-gated operations) by forging signatures, replaying - transactions, or substituting accounts. -3. **A-3.** The attacker cannot front-run, sandwich, or otherwise - target a victim by linking the victim's on-chain identity to a - transaction. Identity-linked attacks (wallet profiling, repeated - targeting of the same victim) must be impossible when the victim - uses the deshield→interact→re-shield pattern. Size-based or - pool-state-based attacks (sandwiching, back-running) that do not - rely on identity are out of scope unless the RFP explicitly states - otherwise. +#### N. Network observer + +1. **N-1.** Public surfaces produced by the application (on-chain + transactions, Waku messages, Codex content and queries, indexer + and RPC traffic) do not contain user-correlatable identifiers, + salts, or metadata that allow an observer to cluster a user's + operations beyond what the underlying primitive intentionally + exposes. +2. **N-2.** The client and SDK do not issue queries that re-link + user activity across operations: no batched RPC over multiple + ephemeral identities in one request, no Waku store query that + pairs ephemeral and persistent topics, no Codex DHT query that + names a sequence of CIDs from one user. +3. **N-3.** Where the application composes a private-state container + (LEZ private account, encrypted Waku topic, end-to-end encrypted + Codex blob) with a public-action surface, the transition between + them is enforced as an indivisible user action. Seeding the + public surface from external sources (a known wallet, a public + peer identity, a long-lived RLN membership) is impossible via + the official SDK. +4. **N-4.** Persistent identifiers the application issues (LEZ + public account addresses, Waku content topics, Codex CIDs, RLN + memberships) do not encode information that links them to a + user's other identifiers across the stack. + +#### A. Active attacker + +1. **A-1.** The attacker cannot violate protocol invariants + regardless of how a transaction, message, query, or upload is + constructed. Authoritative validation (on-chain program, + server-side validator, peer-side verifier) rejects all invalid + state transitions. +2. **A-2.** The attacker cannot bypass authority or access checks + (admin roles, RLN membership, encryption-key gates, + capability-based permissions) by forging, replaying, or + substituting credentials. +3. **A-3.** The attacker cannot identity-link a target through + patterns the application could prevent: user fingerprints in + transaction structure, peer identifiers in Waku metadata, + address fingerprints in Codex DHT lookups, repeated client + fingerprints in RPC traffic. Attacks that depend on properties + the application does not control (raw network position, timing + visible at the transport layer) must be marked inherited or out + of scope. #### C. Malicious counterparty -1. **C-1.** A counterparty cannot steal funds mid-settlement. Every - protocol-mediated exchange must complete atomically or fully - revert. -2. **C-2.** A counterparty cannot grief the user by leaving funds - locked, stranded in an ephemeral account, or recoverable only via - privileged intervention. - -#### S. Sequencer with elevated visibility - -1. **S-1.** Program safety must not depend on the sequencer behaving - honestly. A malicious or compromised sequencer that censors, - reorders, or delays transactions can cause liveness loss but - cannot mint, steal, or corrupt protocol state. -2. **S-2.** Information the sequencer learns from a user's - transaction submission (transaction contents, the user's network - identity at submission time, pre-confirmation ordering) does not - exceed what is already visible on-chain. The program does not - place additional user-correlatable metadata in fields the - sequencer reads but the chain does not commit. +1. **C-1.** Where the application mediates an exchange (trade, + swap, settled message, asset transfer, file delivery), a + counterparty cannot steal mid-settlement. The exchange completes + atomically or fully reverts. +2. **C-2.** A counterparty cannot grief the user by stranding their + state: funds locked in an ephemeral account, content stuck + mid-upload, messages in a deadlocked group, cryptographic + capability lost, recoverable only via privileged intervention. + +#### P. Platform operator with elevated visibility + +1. **P-1.** Application safety does not depend on the honesty of + any platform operator. A malicious or compromised operator (LEZ + sequencer, Waku store or relay, Codex cache or provider, + RPC endpoint, RLNaaS provider) can cause liveness loss but + cannot mint, steal, corrupt protocol state, or break the + application's documented privacy guarantees. +2. **P-2.** The application reveals to each platform operator only + what is unavoidable for that operator's role. Metadata the + application could withhold (correlatable salts, batched + queries, payload framing, identity hints) is withheld. #### F. Malicious or buggy client -1. **F-1.** The on-chain program rejects any transaction that - violates protocol invariants regardless of how the transaction is - constructed. Integrity guarantees do not depend on SDK or - mini-app correctness. Where privacy depends on client behaviour - (e.g., the deshield→interact→re-shield pattern), the proposal - states this explicitly and the SDK enforces the pattern as a - single indivisible user action. -2. **F-2.** The SDK rejects privacy-breaking inputs by construction: - re-shielding to a public account, reusing an ephemeral account, - funding an ephemeral account from an external source, or - splitting a single conceptual operation across multiple - user-visible signing steps. +1. **F-1.** Authoritative components (on-chain programs, server-side + validators, peer-side verifiers) reject invariant-violating + inputs regardless of how they are constructed. Integrity + guarantees do not depend on client correctness. +2. **F-2.** Where privacy depends on client behaviour, the SDK + enforces the privacy-preserving pattern as a single indivisible + user action and rejects privacy-breaking inputs by construction + (e.g., funding an ephemeral account from a known wallet, reusing + a single-use Waku topic, decrypting and republishing a Codex + blob, splitting a conceptual operation across multiple + user-visible signing steps). #### X. External identity correlator -1. **X-1.** Funding the ephemeral public account from any source - other than the atomic deshield (e.g., a CEX withdrawal, a - transfer from an existing wallet) creates an on-chain link to a - known identity and breaks the privacy guarantee. The SDK makes - external funding impossible by construction. The deshield - (operation token plus gas) is a single indivisible user action. -2. **X-2.** The mini-app and documentation make the privacy - boundaries explicit, identifying which user actions preserve - unlinkability and which actions break it (re-shielding to a - known wallet, sending re-shielded funds to a CEX, signing with a - publicly attested key). +1. **X-1.** The application makes external linkage difficult by + construction. Where the user crosses a privacy boundary + (re-shielding to a known wallet, sending to a CEX, posting under + a publicly-attested key, uploading content from a known + publisher identity), the SDK and mini-app warn explicitly before + the action. +2. **X-2.** Documentation enumerates which user actions preserve + unlinkability and which actions break it, in user-visible + language. + +### Component-specific scenarios + +The following scenarios apply only when the corresponding component +is declared in the "Stack components consumed" section above. RFP +authors must include the scenarios for each declared component +verbatim and may extend them with protocol-specific items +(continuing the numbering). + +#### Blockchain / LEZ + +Apply when the application runs an LEZ program or interacts with +LEZ accounts. + +1. **L-1.** Operations executed via the deshield→interact→re-shield + pattern do not link the originating private account to any + on-chain artefact. The program stores no field that joins two + ephemeral accounts to a common owner. +2. **L-2.** Ephemeral public accounts created during a + deshield→interact→re-shield flow are single-use. The SDK does + not reuse them across operations. +3. **L-3.** Where a deshield→interact→re-shield flow is required for + privacy, the deshield is a single indivisible user action that + transfers both the operation token and the gas required for the + downstream interaction in one step. +4. **L-4.** The SDK validates that the re-shield destination is a + private (shielded) account before submitting the transaction and + rejects with an explicit error if it is not. +5. **L-5.** Program correctness does not rely on the LEZ sequencer's + honesty. A malicious or compromised sequencer that censors, + reorders, or delays transactions can cause liveness loss but + cannot mint, steal, or corrupt protocol state. Cite + `lez:sequencer.23-25` for the inherited liveness role. +6. **L-6.** SDK and mini-app queries to the LEZ indexer RPC do not + pair multiple ephemeral accounts in a single request and do not + batch ephemeral and persistent identifiers in a way that re-links + them. + +#### AnonComms + +Apply when the application explicitly composes Mix or RLN. + +1. **AC-1.** Where the application routes traffic through Mix, it + does so via the documented integration points (the libp2p mix + protocol, Logos Core mix module, or Waku Lightpush mix path) and + does not bypass them on a fallback path that lacks the same + protections. +2. **AC-2.** RLN memberships obtained through the AnonComms RLN + service are not reused across application sessions where + unlinkability is required between sessions. + +#### Logos Core + +Apply when the application ships as a Logos Core module. + +1. **LC-1.** The module fails closed on platform errors. A failing + QObject Registry lookup, a crashed sibling module, or a stalled + Process Manager does not cause the module to bypass + authority checks or expose user state. +2. **LC-2.** The module declares its inter-module dependencies and + does not assume the presence of capabilities (transport, UI, + networking) that Logos Core does not itself provide. + +#### Messaging (Waku) + +Apply when the application uses Waku for any user-facing +communication. + +1. **W-1.** Content topics chosen by the SDK do not encode + user-identifying information. Ephemeral topics used for + unlinkable interactions are not reused across user sessions. +2. **W-2.** RLN proofs attached to outbound messages do not leak + identity beyond the rate-limit guarantee. The application does + not include user-correlatable metadata in message envelopes that + the RLN proof would otherwise protect. +3. **W-3.** Waku store queries do not pair ephemeral and persistent + topics in a single request. The SDK pages and time-windows store + queries to limit what a store node operator can correlate. +4. **W-4.** Application safety does not depend on the chosen Light + Push or RLNaaS provider's honesty. Provider failure causes + liveness loss only. + +#### Storage (Codex) + +Apply when the application uses Codex for content distribution or +archival. + +1. **CX-1.** Codex uploads from the application do not include + metadata that links them to a known publisher identity. Where + the application's privacy model requires publisher + unlinkability, the upload path uses the privacy-preserving + variant rather than a direct provider upload. +2. **CX-2.** Downloads use the anonymous-downloads-over-mix path + when the application's privacy model requires downloader + unlinkability. The SDK does not query for the same content via + two distinguishable downloader identities in a way that + re-links a single user. +3. **CX-3.** Where the application caches Codex content, it does so + in a form that supports the cache plausible-deniability property + declared in the Storage FURPS (the cache does not store + plaintext or otherwise gain knowledge of the contents it caches). ### Protocol-specific scenarios RFP authors must append protocol-specific scenarios under the -relevant adversary class, continuing the numbering. Use the same -format: a concrete adversary capability, a clear scenario, and the -testable defence. +relevant adversary class or component-specific section, continuing +the numbering. Use the same format: a concrete adversary capability, +a clear scenario, and the testable defence. Examples of where protocol-specific scenarios commonly apply: @@ -294,15 +412,19 @@ Examples of where protocol-specific scenarios commonly apply: - DEXes: A-class scenarios that document the boundary between identity-linked attacks (in scope) and pool-state attacks (out of scope by default). -- Protocols sensitive to ordering: S-class scenarios documenting - whether the program's correctness depends on sequencer ordering - or only on chain-finalised order. - -Scenarios that the proposal treats as out of scope (e.g., -side-channel correlation via transaction timing, sandwich attacks -based purely on pool state, network-layer observability of -transaction submission, key-loss recovery) must still be listed with -explicit rationale rather than omitted. +- Group messaging or forum protocols: C-class scenarios for + member-join griefing; W-class scenarios for membership-change + unlinkability. +- Filesharing and archival protocols: CX-class scenarios for + publisher anonymity sets and download cover-traffic. +- Protocols sensitive to ordering: P-class scenarios documenting + whether correctness depends on a specific operator's ordering. + +Scenarios the proposal treats as out of scope (e.g., side-channel +correlation via transaction timing, sandwich attacks based purely +on pool state, network-layer observability of transaction +submission, key-loss recovery) must still be listed with explicit +rationale rather than omitted. ## 👤 Recommended Team Profile From 690683687b9deebe4ce61a2f9858face820e8465 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 28 Apr 2026 12:48:23 +1000 Subject: [PATCH 3/4] template, appendix: drop deprecated Waku/Codex names MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Use stack-level names "Messaging" and "Storage" throughout instead of the deprecated "Waku" and "Codex" codenames. Renumber the component-specific scenarios accordingly: - Messaging scenarios W-1..W-4 → M-1..M-4 - Storage scenarios CX-1..CX-3 → ST-1..ST-3 The one remaining "Waku" string in the appendix is inside a verbatim quote from the upstream FURPS source; it is annotated to indicate the current stack-level term. Co-Authored-By: Claude Opus 4.7 (1M context) --- RFPs/RFP-000-template.md | 115 +++++++++++----------- appendix/logos-stack-trust-assumptions.md | 25 ++--- 2 files changed, 72 insertions(+), 68 deletions(-) diff --git a/RFPs/RFP-000-template.md b/RFPs/RFP-000-template.md index 3ec4fde..0b1ddef 100644 --- a/RFPs/RFP-000-template.md +++ b/RFPs/RFP-000-template.md @@ -136,10 +136,10 @@ addition to the common scenarios. Tick all that apply: - [ ] **AnonComms**: Mix transport, RLN identity service. - [ ] **Logos Core**: module loader, QObject Registry, Process Manager. -- [ ] **Messaging (Waku)**: Relay, Light Push, Store, RLN Relay, +- [ ] **Messaging**: Relay, Light Push, Store, RLN Relay, messaging SDK. -- [ ] **Storage (Codex)**: privacy-preserving filesharing, - anonymous downloads. +- [ ] **Storage**: privacy-preserving filesharing, anonymous + downloads. ### Trust assumptions inherited from the Logos stack @@ -168,24 +168,26 @@ relevant adversary class, continuing the numbering. - **N. Network observer.** Reads everything visible on the public surfaces the application touches: on-chain state and transactions; - Waku messages, topics, and metadata; Codex content delivery and DHT - queries; indexer and RPC traffic; client-issued query patterns. Does - not actively interfere. + Messaging messages, topics, and metadata; Storage content delivery + and DHT queries; indexer and RPC traffic; client-issued query + patterns. Does not actively interfere. - **A. Active attacker.** Submits transactions, messages, queries, - uploads. Deploys programs, runs malicious peer nodes (Waku store or - relay, Codex cache or provider, RPC endpoints, sequencer-attached - infra). Pays priority fees. Controls multiple identities. Tries to - break protocol invariants or coerce malicious responses. + uploads. Deploys programs, runs malicious peer nodes (Messaging + store or relay, Storage cache or provider, RPC endpoints, + sequencer-attached infra). Pays priority fees. Controls multiple + identities. Tries to break protocol invariants or coerce malicious + responses. - **C. Malicious counterparty.** A user or peer the victim transacts, communicates, or exchanges with directly through the application: trade counterparty, LP, lender, launchpad participant, chat peer, swap maker, content publisher. - **P. Platform operator with elevated visibility.** A node or operator the application routes through and trusts for liveness - only: LEZ sequencer; Waku store, relay, or RLNaaS provider; Codex - cache or provider; indexer or RPC operator. The stack does not - commit to non-correlation against these operators; the application - chooses what it reveals to them and what it depends on them for. + only: LEZ sequencer; Messaging store, relay, or RLNaaS provider; + Storage cache or provider; indexer or RPC operator. The stack does + not commit to non-correlation against these operators; the + application chooses what it reveals to them and what it depends on + them for. - **F. Malicious or buggy client.** A user runs a hostile mini-app, a third-party SDK, or hand-crafted requests that bypass the official client. @@ -202,27 +204,27 @@ explicitly document them as out of scope or inherited. #### N. Network observer 1. **N-1.** Public surfaces produced by the application (on-chain - transactions, Waku messages, Codex content and queries, indexer - and RPC traffic) do not contain user-correlatable identifiers, - salts, or metadata that allow an observer to cluster a user's - operations beyond what the underlying primitive intentionally - exposes. + transactions, Messaging messages, Storage content and queries, + indexer and RPC traffic) do not contain user-correlatable + identifiers, salts, or metadata that allow an observer to cluster + a user's operations beyond what the underlying primitive + intentionally exposes. 2. **N-2.** The client and SDK do not issue queries that re-link user activity across operations: no batched RPC over multiple - ephemeral identities in one request, no Waku store query that - pairs ephemeral and persistent topics, no Codex DHT query that - names a sequence of CIDs from one user. + ephemeral identities in one request, no Messaging store query + that pairs ephemeral and persistent topics, no Storage DHT query + that names a sequence of content identifiers from one user. 3. **N-3.** Where the application composes a private-state container - (LEZ private account, encrypted Waku topic, end-to-end encrypted - Codex blob) with a public-action surface, the transition between - them is enforced as an indivisible user action. Seeding the - public surface from external sources (a known wallet, a public - peer identity, a long-lived RLN membership) is impossible via - the official SDK. + (LEZ private account, encrypted Messaging topic, end-to-end + encrypted Storage blob) with a public-action surface, the + transition between them is enforced as an indivisible user action. + Seeding the public surface from external sources (a known wallet, + a public peer identity, a long-lived RLN membership) is impossible + via the official SDK. 4. **N-4.** Persistent identifiers the application issues (LEZ - public account addresses, Waku content topics, Codex CIDs, RLN - memberships) do not encode information that links them to a - user's other identifiers across the stack. + public account addresses, Messaging content topics, Storage + content identifiers, RLN memberships) do not encode information + that links them to a user's other identifiers across the stack. #### A. Active attacker @@ -237,8 +239,8 @@ explicitly document them as out of scope or inherited. substituting credentials. 3. **A-3.** The attacker cannot identity-link a target through patterns the application could prevent: user fingerprints in - transaction structure, peer identifiers in Waku metadata, - address fingerprints in Codex DHT lookups, repeated client + transaction structure, peer identifiers in Messaging metadata, + address fingerprints in Storage DHT lookups, repeated client fingerprints in RPC traffic. Attacks that depend on properties the application does not control (raw network position, timing visible at the transport layer) must be marked inherited or out @@ -259,7 +261,7 @@ explicitly document them as out of scope or inherited. 1. **P-1.** Application safety does not depend on the honesty of any platform operator. A malicious or compromised operator (LEZ - sequencer, Waku store or relay, Codex cache or provider, + sequencer, Messaging store or relay, Storage cache or provider, RPC endpoint, RLNaaS provider) can cause liveness loss but cannot mint, steal, corrupt protocol state, or break the application's documented privacy guarantees. @@ -278,8 +280,8 @@ explicitly document them as out of scope or inherited. enforces the privacy-preserving pattern as a single indivisible user action and rejects privacy-breaking inputs by construction (e.g., funding an ephemeral account from a known wallet, reusing - a single-use Waku topic, decrypting and republishing a Codex - blob, splitting a conceptual operation across multiple + a single-use Messaging topic, decrypting and republishing a + Storage blob, splitting a conceptual operation across multiple user-visible signing steps). #### X. External identity correlator @@ -337,9 +339,9 @@ Apply when the application explicitly composes Mix or RLN. 1. **AC-1.** Where the application routes traffic through Mix, it does so via the documented integration points (the libp2p mix - protocol, Logos Core mix module, or Waku Lightpush mix path) and - does not bypass them on a fallback path that lacks the same - protections. + protocol, Logos Core mix module, or the Messaging Light Push mix + path) and does not bypass them on a fallback path that lacks the + same protections. 2. **AC-2.** RLN memberships obtained through the AnonComms RLN service are not reused across application sessions where unlinkability is required between sessions. @@ -356,43 +358,44 @@ Apply when the application ships as a Logos Core module. does not assume the presence of capabilities (transport, UI, networking) that Logos Core does not itself provide. -#### Messaging (Waku) +#### Messaging -Apply when the application uses Waku for any user-facing +Apply when the application uses Messaging for any user-facing communication. -1. **W-1.** Content topics chosen by the SDK do not encode +1. **M-1.** Content topics chosen by the SDK do not encode user-identifying information. Ephemeral topics used for unlinkable interactions are not reused across user sessions. -2. **W-2.** RLN proofs attached to outbound messages do not leak +2. **M-2.** RLN proofs attached to outbound messages do not leak identity beyond the rate-limit guarantee. The application does not include user-correlatable metadata in message envelopes that the RLN proof would otherwise protect. -3. **W-3.** Waku store queries do not pair ephemeral and persistent - topics in a single request. The SDK pages and time-windows store - queries to limit what a store node operator can correlate. -4. **W-4.** Application safety does not depend on the chosen Light +3. **M-3.** Messaging store queries do not pair ephemeral and + persistent topics in a single request. The SDK pages and + time-windows store queries to limit what a store node operator + can correlate. +4. **M-4.** Application safety does not depend on the chosen Light Push or RLNaaS provider's honesty. Provider failure causes liveness loss only. -#### Storage (Codex) +#### Storage -Apply when the application uses Codex for content distribution or +Apply when the application uses Storage for content distribution or archival. -1. **CX-1.** Codex uploads from the application do not include +1. **ST-1.** Storage uploads from the application do not include metadata that links them to a known publisher identity. Where the application's privacy model requires publisher unlinkability, the upload path uses the privacy-preserving variant rather than a direct provider upload. -2. **CX-2.** Downloads use the anonymous-downloads-over-mix path +2. **ST-2.** Downloads use the anonymous-downloads-over-mix path when the application's privacy model requires downloader unlinkability. The SDK does not query for the same content via two distinguishable downloader identities in a way that re-links a single user. -3. **CX-3.** Where the application caches Codex content, it does so - in a form that supports the cache plausible-deniability property - declared in the Storage FURPS (the cache does not store +3. **ST-3.** Where the application caches Storage content, it does + so in a form that supports the cache plausible-deniability + property declared in the Storage FURPS (the cache does not store plaintext or otherwise gain knowledge of the contents it caches). ### Protocol-specific scenarios @@ -413,9 +416,9 @@ Examples of where protocol-specific scenarios commonly apply: identity-linked attacks (in scope) and pool-state attacks (out of scope by default). - Group messaging or forum protocols: C-class scenarios for - member-join griefing; W-class scenarios for membership-change + member-join griefing; M-class scenarios for membership-change unlinkability. -- Filesharing and archival protocols: CX-class scenarios for +- Filesharing and archival protocols: ST-class scenarios for publisher anonymity sets and download cover-traffic. - Protocols sensitive to ordering: P-class scenarios documenting whether correctness depends on a specific operator's ordering. diff --git a/appendix/logos-stack-trust-assumptions.md b/appendix/logos-stack-trust-assumptions.md index eb1ee24..6ac53d3 100644 --- a/appendix/logos-stack-trust-assumptions.md +++ b/appendix/logos-stack-trust-assumptions.md @@ -24,7 +24,7 @@ next batch of RFPs is updated. | AnonComms Mix | `anoncomms/furps/mix.md` | 2026-04-08 | [link](https://github.com/logos-co/roadmap/blob/v4/content/anoncomms/furps/mix.md) | | AnonComms RLN | `anoncomms/furps/rln.md` | 2026-03-24 | [link](https://github.com/logos-co/roadmap/blob/v4/content/anoncomms/furps/rln.md) | | Logos Core | `logoscore/furps/logos-core.md` | 2025-12-15 | [link](https://github.com/logos-co/roadmap/blob/v4/content/logoscore/furps/logos-core.md) | -| Messaging (Waku) overview | `messaging/furps/index.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/index.md) | +| Messaging overview | `messaging/furps/index.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/index.md) | | Messaging Mix | `messaging/furps/core/mix.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/core/mix.md) | | Messaging RLN Relay | `messaging/furps/core/rln_relay.md` | 2025-11-13 (dated) | [link](https://github.com/logos-co/roadmap/blob/v4/content/messaging/furps/core/rln_relay.md) | | Storage privacy filesharing | `storage/furps/privacy-preserving-filesharing-furps.md` | 2026-04-08 | [link](https://github.com/logos-co/roadmap/blob/v4/content/storage/furps/privacy-preserving-filesharing-furps.md) | @@ -129,7 +129,8 @@ Critically, the AnonComms FURPS describes integration targets but does integrated in nim-libp2p" (Usability `mix.2`) - "The libp2p mix protocol with DoS and Sybil protection is integrated into Waku Lightpush protocol as reference integration" - (Usability `mix.3`) + (Usability `mix.3`) [verbatim quote from source; current + stack-level term: Messaging Light Push] - "A libp2p module with mix capability is integrated into Logos Core" (Usability `mix.4`) - "The libp2p mix protocol is integrated into the Logos Chat module" @@ -183,10 +184,10 @@ What Logos Core does **not** commit to: privacy, and security properties for an RFP do not come from Logos Core itself; they come from the modules that an RFP composes. -### Messaging (Waku) +### Messaging -Messaging FURPS (dated 2025-11-13) commits to a Waku-based stack with -its own Mix and RLN. Relevant items for RFPs that use Waku: +Messaging FURPS (dated 2025-11-13) commits to a stack with its own +Mix and RLN. Relevant items for RFPs that use Messaging: - Mix at the messaging layer: "Relay nodes can mount mixnet protocol, acting as sender, intermediary or exit nodes" (`messaging:mix.1`) @@ -199,15 +200,15 @@ its own Mix and RLN. Relevant items for RFPs that use Waku: - Store explicit limitation: "(limitation) No guarantees in terms of message presence or retention duration" (Reliability `store.2`) -Messaging is a separate sub-system from LEZ. RFPs that use Waku for -out-of-band communication (e.g., a chat-style interaction layer) +Messaging is a separate sub-system from LEZ. RFPs that use Messaging +for out-of-band communication (e.g., a chat-style interaction layer) inherit these properties; RFPs that interact only with LEZ programs do not. ### Storage Storage FURPS (dated 2026-04-08) define privacy properties for -Codex-based filesharing. +filesharing. - "Neither the identity of publishers nor that of downloaders should be revealed to other participants; i.e., we want full publisher and @@ -220,7 +221,7 @@ Codex-based filesharing. download. Note that the node that provides the file is not anonymized here" (`anonymous-downloads-over-mix`, Security 1) -Storage is a separate sub-system from LEZ. RFPs that use Codex for +Storage is a separate sub-system from LEZ. RFPs that use Storage for file or asset distribution inherit these properties for the file distribution path. They do not extend to LEZ on-chain state. @@ -279,9 +280,9 @@ layer. queried, or that an RPC operator cannot correlate a sequence of queries to a single user. 4. **No off-chain storage privacy by default for LEZ state.** Storage - FURPS apply to the Codex filesharing stack, not to LEZ on-chain - state nor to private-account witness data unless an RFP - explicitly composes Codex for that purpose. + FURPS apply to the filesharing stack, not to LEZ on-chain state + nor to private-account witness data unless an RFP explicitly + composes Storage for that purpose. 5. **Censorship resistance is at the consensus layer, not the sequencer.** "Censorship resistance against malicious broadcasters" applies to block propagation. There is no equivalent From 8f3e5f980c6cde0f27134ada1cdea0f02979ebc1 Mon Sep 17 00:00:00 2001 From: fryorcraken Date: Tue, 28 Apr 2026 12:50:06 +1000 Subject: [PATCH 4/4] appendix: drop Critically hedge marker Co-Authored-By: Claude Opus 4.7 (1M context) --- appendix/logos-stack-trust-assumptions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/appendix/logos-stack-trust-assumptions.md b/appendix/logos-stack-trust-assumptions.md index 6ac53d3..e179cb0 100644 --- a/appendix/logos-stack-trust-assumptions.md +++ b/appendix/logos-stack-trust-assumptions.md @@ -120,8 +120,8 @@ What the Blockchain / LEZ FURPS does **not** commit to: ### AnonComms The AnonComms component delivers a mix protocol and an RLN service. -Critically, the AnonComms FURPS describes integration targets but does -**not** list LEZ transaction submission as one of them. +The AnonComms FURPS lists integration targets for the mix protocol; +LEZ transaction submission is not one of them. **Mix integration targets** (`anoncomms/furps/mix.md`):