Firee - Decentralized Marketplace
Firee is a decentralized marketplace for physical goods. Buyers pay in USDC on Base, but the money never goes straight to the seller: it sits in a smart contract escrow until the item ships, arrives, and the buyer confirms delivery. A flat 3% fee, automatic refunds if the seller never ships, and every order state verifiable on chain.
The Problem
Buying physical goods from a stranger with crypto is a trust problem with no referee. Pay first and the seller can vanish; ship first and the buyer can. Marketplaces that tried this before, like OpenBazaar, solved the payment rail but died because the experience was built for crypto natives, not shoppers. The interesting problem was not the escrow contract. It was making an escrow state machine feel like a normal online store.
Research & Discovery
- 01Started from a simple question: what would Amazon look like if the trust layer were a smart contract instead of a corporation?
- 02Studied why OpenBazaar failed despite proving demand: crypto native onboarding, no familiar checkout, and no clear answer to "what happens if my package never arrives."
- 03Designed the escrow state machine before any screen: Paid, then Shipped with a tracking number, then Delivered on buyer confirmation, with timeout branches for refunds and disputes. Every screen after that is a projection of one state.
Key Design Decisions
The order timeline is the product
Each order shows a plain language status: Awaiting Shipment, Shipped with tracking number, Delivered. The same state machine drives the buyer view, the seller view, and the contract. Trust comes from visibility, not from hiding blockchain mechanics.
Deadlines instead of customer support
If the seller never ships within 14 days, the buyer claims a full refund directly from the contract. If the buyer goes silent after delivery, funds auto release to the seller after 30 days. Both failure modes resolve without a human in the loop, and the UI states the rules up front instead of burying them in terms.
Web2 onboarding, Web3 settlement
Users sign up with email or Google and enter a normal shipping address at checkout. The wallet only appears at the moment of payment. This is the direct answer to why OpenBazaar style marketplaces lost mainstream buyers at the front door.
Confirm Delivery as a deliberate action
Releasing payment is the highest stakes tap in the product, so it is an explicit button on the order, never automatic on a courier scan. The buyer decides when the deal is done, and the copy makes the consequence clear: confirming pays the seller.
Built With
Outcome
Shipped the full physical goods flow as a solo designer and developer: checkout with shipping address, escrow payment, a seller order dashboard with Mark as Shipped and tracking input, buyer side delivery confirmation, and a Solidity escrow contract with timeout based refunds and auto release. It reads like a familiar Web2 store while every payment step stays verifiable on chain.
What I Learned
Firee started as a digital goods marketplace with instant file delivery. Pivoting to physical goods forced a rebuild of the trust model, because an escrow that settles on instant download makes no sense when delivery takes two weeks. The lesson: design the state machine first, and when the fulfillment model changes, expect the contract, the database, and the UI to change together. Screens are cheap; states are architecture.
Next case study
Amana Protocol - Decentralized Exchange