Sovereign Storefront

1Where selling a file stands today

Creators already have websites and audiences. Selling a download still usually means a platform account, an email address, or both.

Crypto checkout is available. Tools already take Bitcoin or shielded ZEC. That is payment, not a private purchase.

• Platforms hold the customer relationship, often the files, and the checkout.
• Invoice plugins settle money, then deliver through email or a shop account.
• If the buyer pays and closes the tab, recovery is an inbox.
• Private settlement does not mean a private shopping workflow. Some plugins send customer name and address to their service.

What is missing as one seller-owned product: a private order, shielded payment the seller verifies, encrypted delivery, and a purchase the buyer can recover without creating an account.

2Proposed solution

Sovereign Storefront is seller-owned checkout, not a marketplace. Creators keep their site, audience, files, and money. Buyers do not create another platform account.

The product handles:

Private order → shielded payment → encrypted delivery → recoverable purchase.

A simple storefront is the first interface. Embeddable checkout is the distribution path after that.

Positioning: private checkout and recoverable digital delivery, powered by Logos for communication and file distribution, and Zcash for shielded settlement.

Starting point: seller-owned checkout links. Pilot sellers bring existing buyers. No new marketplace audience required.

3How it works

1. Seller’s website or shared product link
2. Buyer checkout client
3. Encrypted order via Logos Messaging
4. Seller-controlled service Zcash wallet scanner verifies incoming payment
5. Encrypted delivery key via Logos Messaging
6. Buyer retrieves encrypted file through Logos Storage
7. Local decryption

No bridge, wrapped ZEC, LEZ payment token, or custom blockchain is required by this proposal.

Logos contribution

Logos Messaging provides transport and an end-to-end encrypted Chat layer. Its Store protocol retains messages temporarily but does not guarantee availability. [2]

Logos Storage provides CID-based file distribution and replication. Its API exposes upload/download operations and completion events. [1] [5]

Files must be encrypted before publication. A CID is not access control: anyone holding it can download the associated file. [1]

Zcash contribution

Payment requests can use ZIP-321. Receipt must be verified separately: a URI is an instruction to a wallet, not evidence of payment. [3]

The Zcash client backend documents methods for reading transaction heights and note memos. These are foundations for an invoice scanner, not a complete commerce integration. [7]

The product work is connecting these components reliably. Evaluate existing payment integrations before building a new payment backend.

Example purchase

1. Seller encrypts a product and publishes the ciphertext through Logos Storage.
2. Buyer requests an invoice through an encrypted conversation.
3. Seller returns a payment request bound to the product version and buyer delivery key.
4. Buyer authorizes a shielded payment in their wallet.
5. Seller-controlled service detects the payment and applies its confirmation policy.
6. Seller service releases the decryption key through encrypted messaging.
7. Buyer downloads and decrypts the product locally.

This is not trustless exchange. The buyer trusts the seller to deliver the advertised file. Removing that trust requires a substantially harder protocol.

4Customer promise

The seller still knows which product was purchased. The goal is to avoid unnecessarily exposing the purchase to other parties, not to conceal fulfillment details from the seller.

First users

Independent digital publishers and software creators whose customers already use ZEC.

This is a starting segment, not a permanent restriction. The same flow can serve books, software, educational downloads, design assets, and other digital goods.

Starting with everyone would require solving distribution, onboarding, currency conversion, and fulfillment at once. We start with buyers who already hold ZEC.

5Fulfillment is the hard problem

Design requirements

• Bind each invoice to product version, amount, network, expiry policy, and buyer delivery key.
• Use a unique invoice identifier; do not match solely by amount.
• Keep durable payment and fulfillment records on the seller side.
• Make fulfillment idempotent: retries return the same entitlement rather than create inconsistent orders.
• Provide an exportable buyer recovery capability, with clear warnings about loss and sharing.
• Keep spending keys out of the fulfillment service where the selected wallet integration permits it.
• Treat read-only wallet access as privacy-sensitive: inability to spend does not imply inability to expose payment history.
• Do not treat a buyer-supplied transaction ID, a sent-payment message, or opening a wallet URI as settlement evidence.

The intended value is a dependable purchase without a platform account—not another encrypted messenger.

6Ownership and trust boundaries

A managed provider sees whatever the seller delegates to it. A deployment where the provider holds decryption keys and readable order records must not be advertised as opaque to that provider.

Hosted checkout also introduces trust in served JavaScript. A browser interface is not automatically as sovereign as a locally installed client.

Deployment choices

• Native client: stronger local control, more installation friction.
• Browser checkout: easier distribution, additional trust in hosting and gateway infrastructure.

A native client may be reasonable for a Logos event demonstration. For broader adoption, browser feasibility is a go/no-go question rather than an assumed solved problem.

7Scale: distinguish reach from capacity

Market reach

The workflow applies across digital-product categories. This is plausible breadth, not proof buyers will switch.

The adoption barrier is whether buyers already have ZEC and find the privacy benefit worth additional payment steps. Currency acquisition, price volatility, and seller conversion needs can outweigh the benefit.

Technical capacity

How we keep it cheap to operate:

• Distribute encrypted product files independently of individual orders.
• Send small invoice and key-delivery messages rather than files over messaging.
• Isolate each merchant’s wallet access, keys, and order state.
• Maintain deliberate replicas rather than rely on buyers to keep files available.
• Measure scanning lag, payment-to-delivery latency, retry behavior, and operating cost.

Logos explicitly states that organic replication does not guarantee persistence; replication groups are not currently provided out of the box. [1]

Messaging documentation describes a trade-off between shared content topics for privacy and topic buckets for distributing load. [2]

Scale is a measurement target, not a launch claim.

No DRM promise

Once a buyer obtains plaintext, they can copy it. Encrypting a product once and distributing its key is efficient, but buyers can redistribute that key as well. Encryption protects distribution from unauthorized intermediaries; it does not guarantee control after purchase.

8Privacy, claimed carefully

• Storage documentation describes fully anonymous filesharing as a future-maturity property, not a present blanket guarantee. [1]
• Store and Filter messaging connections can associate a peer with queried topics. [2]
• The storage onboarding guide targets a testnet release. [6]
• Public listings, hosting logs, access timing, network observations, endpoints, wallet infrastructure, and cash-out can expose information.
• Seller-controlled fulfillment does not establish atomic fair exchange.
• Decentralized replication does not guarantee deletion, permanent availability, or immunity from legal obligations.

9First product

One-time paid downloads from seller-owned links.

Demonstration

A buyer pays and disconnects before receiving the file. They later recover the purchase. The file remains downloadable after the original uploader goes offline because another participating node retains and serves it.

This demonstrates payment reconciliation, recoverable delivery, and independent file availability—not merely a successful checkout screen.

What a first merchant run must prove

• Real testnet payment rather than simulated payment status.
• Wrong amount, duplicate payment, missing reference, and late payment handling.
• Restart between payment detection and key delivery.
• Duplicate or reordered messages.
• Buyer recovery without email.
• File retrieval from an independent replica.
• Documented confirmation and chain-reorganization behavior.
• Explicitly documented information visible to every actor.

10Business

Revenue

Sellers pay for operations, not a cut of settlement:

• Managed seller instances.
• Replication and availability services.
• Backups and recovery.
• Storefront integrations.
• Support.

A mandatory percentage fee is a poor fit when the promise is seller control and direct settlement.

What we need to learn with the first merchants

1. Problem: can sellers describe a concrete privacy or platform-dependence problem?
2. Distribution: can they bring actual buyers without a new marketplace?
3. Payment: will those buyers use ZEC?
4. Operations: do sellers prefer this setup to existing checkout tools?
5. Value: will sellers pay for reliable operation rather than merely endorse the privacy story?

When we would stop or narrow

• Sellers only want a Zcash payment button; existing products already cover much of that need.
• Buyers abandon checkout because obtaining ZEC is too difficult.
• Browser/native-client requirements make purchase completion impractical.
• Storage and messaging operations cost more than merchants will pay.
• Sellers gain no meaningful benefit over an existing self-hosted shop.

11What we do next

Ship private checkout and recoverable digital delivery through a small storefront, then an embeddable checkout link.

Prove it with one merchant’s real purchases and repeat use before adding marketplace, reputation, or subscriptions.

12Alternatives

Paying in crypto and getting a file is already possible. Private settlement is already possible. None of these is the full private purchase.