BDX: Building a Trusted Two-Sided Marketplace

The challenge: earn trust from both sides

A first-time data owner was asked to accept an offer that broke a familiar rule, described in crypto vocabulary they had never seen. Each side had its own questions before committing:

• Data Clients: Why would anyone pay me? Can I trust this provider? When do I get paid?
• Storage Providers: Is this dataset worth a bid? Do I qualify? What do I owe if I win?

The constraints were one designer, four weeks, and a team spread across several countries. If data owners couldn’t believe the offer, they would leave before ever reaching an auction.

Learn what made both sides hesitate

Before BDX, these deals happened privately through personal contacts, with no public price and no protection for either side. No product we knew of let providers openly bid to pay data owners, so I drew on many references that each solved part of the problem. Three shaped the design most: Filfox, a Filecoin data explorer, for how network metrics, provider rankings and data tables are organized and explained; OpenSea for how auctions, offers, and expiry dates work; and Uniswap for how complex steps, fees and risks can be explained simply. After launch, I collected and analyzed user feedback from Slack to decide what to improve next.

Two findings drove the design:

• Both sides asked the same first question: will I get paid, and when?
• Before placing a single bid, a provider had to convert FIL on a separate network and wait about two hours. Every technical step was a chance to lose someone, so each one had to earn its place.

Let the market prove the offer

Telling people “providers will pay you” wasn’t enough to make it believable, so I let market activity prove it. The homepage led with live numbers: how much data had been stored, total bids, and the average price providers paid in each region. The full explanation stayed one click away in the FAQ. The trade-off was that this proof only works once the market is busy.

Show technical terms only when they matter

Most blockchain details never changed what a user did next, so I kept them out of the way. Each term appeared only at the step where it mattered:

• Payment: FIL appeared as an amount and the date it would arrive.
• Eligibility: DataCap appeared as a simple yes or no.
• Sign-in: the crypto wallet appeared only as the user’s login.
• Deal progress: the automated contract behind each deal appeared as a plain status.

Give both sides the same view of every deal

Data owners and providers each had their own journey, built on the same building blocks: auction, bid, dataset, provider profile, wallet, and status. A data owner saw exactly the bid a provider submitted, with the same status the provider saw. Shared facts built trust on both sides and let one designer cover both roles in four weeks. The cost was that every component had to work for two viewpoints.

Build the content system early

BDX depended on Filecoin’s reward for real data. When the network tightened the rules for granting that reward in 2024, BDX’s approval was not renewed, and the product was sunset.

The project taught me that when people are asked to trust an unfamiliar market, the interface has to carry the trust signals. If I did it again, I would build a content system from the start. Explaining terms in context across many screens, plus a shared glossary, would have kept the language consistent as the product grew.