CrowdStore is a browser-based, fully decentralized P2P marketplace and store network, which lets anyone run stores without servers, with orders and ratings encrypted in Zcash memo fields and data shared among peers. Anonymous, signature-verified trades and post-order rating create trust and transparency while showcasing Zcash’s privacy tech. CrowdStore completes the Zcash ecosystem by giving users a practical way to earn and spend Zcash.
I will update this thread with more information about CrowdStore over time, and I’d appreciate your feedback. I’ll also include some of my replies from other forum threads here, so everything is in one place.
Currently, there is little practical reason for users to pay with Zcash in everyday life. Adoption remains limited, as most merchants and users are satisfied with Bitcoin or other widely accepted cryptocurrencies. While Zcash’s privacy features are technically advanced, most people do not feel a strong need for them in routine transactions.
CrowdStore changes this by introducing a peer-to-peer marketplace where anything can be bought or sold directly between users. In this context, Zcash’s private memo fields become essential, as they enable secure, encrypted communication between buyer and seller within each transaction. This gives Zcash a concrete and practical use case that goes beyond simple private payments.
CrowdStore is designed to let anyone create and operate their own online store without relying on centralized servers or third-party intermediaries. Each store functions as an independent storefront identified by a unique Store ID, and all transactions are conducted directly between buyers and sellers using Zcash, ensuring financial privacy through encryption and anonymous payments. Order details are securely encrypted, and an escrow system is used to protect both parties during transactions.
Additional features that will become available to store owners later are described below. (These are not part of the retroactive grant and will be implemented at a later stage, as they are not essential for the core operation of the marketplace. I am mentioning this here for clarity.)
Because CrowdStore operates as a distributed network, stores remain accessible as long as at least one peer hosts them, such as through a user’s browser. To maintain constant availability, store owners can either keep their stores open in their browser, or use the optional “CrowdBoost” service, which ensures continuous hosting even when no peers are online, using other peers network capacity. This system enables censorship-resistant commerce, protecting user freedom and data privacy while allowing for fully autonomous online marketplaces.
To protect merchants and buyers from cryptocurrency price volatility during transactions, CrowdStore offers “PriceLock”. When an order is placed and funds are held in escrow, PriceLock temporarily stabilizes the value of the payment by pegging it to a fiat equivalent (using third party exchange). This means that even if the market price of Zcash fluctuates while the order is being processed, the seller still receives the (near) original agreed-upon value when the escrow is released.
The Alias feature in CrowdStore allows store owners to replace their long, cryptic Store ID with a short, readable name that is easier for customers to remember and share. Instead of relying on the default 44-character identifier, merchants can register a custom alias - similar to a domain name -that directly links to their store. These aliases are allocated on a first come, first gets basis, meaning that once an alias is claimed, no one else can register the same name until it expires. This system not only enhances store branding and accessibility but also introduces a limited-name economy within the decentralized marketplace, where recognizable or desirable aliases may carry added value over time.
Regarding custom offer for special client, that is very interesting idea.
At the moment, this feature is not directly supported, but there is a simple workaround.
When a buyer places an order, the system calculates the total amount in ZEC and displays a payment QR code. However, the payment amount itself is not strictly enforced — the buyer can technically send either a higher or lower amount. The merchant will then see the actual payment received and can choose whether to accept or reject the order. If the merchant agrees to honor a lower payment, this effectively allows for a negotiated price between buyer and seller, functioning much like the requested feature.
At this stage, it can be tricky to sort out any issues, especially if it’s a big project. Scammers might flood sellers with small transactions from a bunch of accounts and then ask for a full refund. This happens a lot with P2P sales on exchanges.
If the seller and buyer have agreed on a different amount, the seller changes it in their ad, and the buyer pays only what the system charges them, which is safer.
I didn’t hear about such problems with p2p sales on exchanges. Nevertheless, in CrowdStore, the buyer cannot ask for refund. So if any buyer sends small transactions, he does not get the funds back unless the merchant actively marks such payments eligible for refund.
But based on your feedback, I am thinking about a setting for each Store to automatically reject payments below specified amount, which would solve this situation, if that ever happens. Thank you for idea
I’m happy to announce that the peer to peer marketplace is now fully functional and live, including admin interface for creating new stores. Store owners can register their shops directly from the web interface.
CrowdStore gets order information from Zcash memo field of the payment.
As we know, Zcash memo field is limited to 512 bytes. The CrowdStore system requires approximately 200 bytes of that space for its own overhead, which includes store identification, encryption keys, signatures, and other metadata. This leaves about 222 bytes available for order information such as ordered items, shipping details, delivery address, recipient name, country, phone number, and email address.
Although this may not seem like much, the custom BPE (Byte Pair Encoding) compression I developed allows a significant amount of text to fit within this limit. For example, the following address (188 characters) compresses to just 133 bytes, achieving a 60% compression ratio.
Thanks to this encoding, even complex addresses - including those containing international characters such as Japanese - fit into the limited memo space. In the user interface, an indicator in the top-right corner shows how many characters remain available. If the entered address exceeds the limit, the system prompts the user to shorten it by removing non-essential details to ensure successful delivery.
Notice that the memo includes the delivery information encrypted, and only the store can decrypt that. The length is 345 characters here, leaving lots of space for more information if necessary (more items, longer addresses, etc).
