diff --git a/RFPs/RFP-000-template.md b/RFPs/RFP-000-template.md
index 7f62fdd..0b1ddef 100644
--- a/RFPs/RFP-000-template.md
+++ b/RFPs/RFP-000-template.md
@@ -94,19 +94,342 @@ 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
+(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**: Relay, Light Push, Store, RLN Relay,
+  messaging SDK.
+- [ ] **Storage**: 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, 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
+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`" 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., `N-1`) so other documents and reviews can reference them.
+RFP authors must keep the common scenarios verbatim and add
+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;
+  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 (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; 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.
+- **X. External identity correlator.** Holds off-chain data (CEX KYC,
+  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 regardless of which
+components it uses. Each implementation must protect against them or
+explicitly document them as out of scope or inherited.
+
+#### N. Network observer
+
+1. **N-1.** Public surfaces produced by the application (on-chain
+   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 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 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, 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
+
+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 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
+   of scope.
+
+#### C. Malicious counterparty
+
+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, 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.
+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.** 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 Messaging topic, decrypting and republishing a
+   Storage blob, splitting a conceptual operation across multiple
+   user-visible signing steps).
+
+#### X. External identity correlator
+
+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 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.
+
+#### 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
+
+Apply when the application uses Messaging for any user-facing
+communication.
+
+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. **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. **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
+
+Apply when the application uses Storage for content distribution or
+archival.
+
+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. **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. **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
+
+RFP authors must append protocol-specific scenarios under the
+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:
+
+- 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).
+- Group messaging or forum protocols: C-class scenarios for
+  member-join griefing; M-class scenarios for membership-change
+  unlinkability.
+- 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.
+
+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
 
 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..e179cb0
--- /dev/null
+++ b/appendix/logos-stack-trust-assumptions.md
@@ -0,0 +1,307 @@
+# 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 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.
+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`):
+
+- "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`) [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"
+  (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
+
+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`)
+- 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 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
+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 Storage 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 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
+   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.