Designing BDX as a Trustworthy Negative-Price Marketplace
Designing a marketplace where storage providers paid to store public data.
Overview
BDX was a Web3 data marketplace built on Filecoin. It connected data clients and communities with storage providers through an auction-style market, helping large public datasets find reliable decentralized storage.
The product was built around a counterintuitive economic model. In traditional cloud storage, clients pay vendors to store their data. In BDX, storage providers competed to pay data clients in FIL tokens for the right to host their datasets. That inversion came from Filecoin’s incentive structure. Verified useful data could help storage providers earn more network rewards, so high-value datasets became valuable assets inside the marketplace.
This created both a strong product opportunity and a trust problem. Filecoin had the infrastructure for verifiable decentralized storage. Data clients still needed a practical way to find providers, understand why the market worked, and feel confident enough to participate.
I led design across the full product lifecycle, from the initial brand and product foundation to launch materials, marketplace flows, design system expansion, and later product iteration. My role was to make a technically complex and unfamiliar market model feel clear, credible, and usable as the product moved from concept to real ecosystem use. The opportunity was larger than storage. It was trust and coordination.
Challenge
The model made economic sense, yet it looked suspicious at first glance. A first-time user would see the core promise, “storage providers will pay to store your data,” and immediately question whether something was wrong. For most people, cloud storage has a familiar mental model: I have data, I pay a vendor, the vendor stores it. BDX reversed that expectation.
The design problem was larger than explaining blockchain. The product had to close the credibility gap before users reached the point of making a transaction. Three conditions made it difficult.
- First, the payment model was unfamiliar. The product needed to explain why storage providers were willing to pay without forcing users to understand the full protocol economy.
- Second, the technical layer was opaque. FIL tokens, DataCap, wallet connection, smart contracts, and settlement logic all mattered. They had to appear in the right places without dominating the experience.
- Third, the marketplace had two very different sides. Data Clients needed confidence that their datasets would be stored reliably and that payments would be handled clearly. Storage Providers needed a way to discover valuable opportunities, compare deals, submit bids, and track fulfillment.
If the product failed to make the incentive model believable, the marketplace would lose users before they could understand its value.
Approach
- Define a trust language before scaling the product
- Because I owned both brand and product design, I started by defining a visual and verbal language that could support the product beyond the first release.
- The experience needed to feel credible enough for financial and infrastructure decisions while still feeling accessible to users who were new to Filecoin. I used a dark base palette to signal seriousness and high contrast gradients to create energy around auctions, bids, and key actions. This direction became more than a visual style. It gave the product, event materials, investor-facing assets, and future interface work a shared foundation. It also helped the team make faster and more consistent decisions as the product expanded.
- Make the economic logic legible
- The most important design task was to make the inverted market model understandable. Instead of explaining every protocol detail upfront, I focused on the user’s core question: why would a storage provider pay me?
- The interface needed to translate the incentive chain into plain language. Verified useful data had value inside the Filecoin network. Storage providers could benefit from storing that data. BDX allowed them to compete for those opportunities through auctions. The goal was incentive comprehension. Users needed enough understanding to see why the market was rational and why participation could make sense.
- Reveal technical concepts only when they affect decisions
- Web3 products often overexpose technical mechanics. In BDX, I treated protocol concepts as decision signals instead of background knowledge.
- FIL was presented where payment and settlement mattered. DataCap appeared where deal quality and eligibility mattered. Wallet connection was framed as identity and transaction access, rather than a technical ritual. Smart contract logic was translated into visible status, timing, and settlement paths. This helped users understand what they needed to know at the moment they needed it.
- Separate role journeys on one shared system
- Data Clients and Storage Providers came to BDX with different goals. Data Clients needed to create auctions, define storage requirements, evaluate bids, and manage datasets. Storage Providers needed to discover opportunities, submit bids, track fulfillment, and monitor performance.
- I designed separate role-based journeys while keeping them on one shared system. Auctions, bids, datasets, provider profiles, wallet identity, and status states all followed reusable patterns. This kept the product coherent and allowed each role to move through the marketplace in a way that matched their own mental model.
- Build a system that could evolve with the product
- BDX needed to support an initial launch, then continue growing as the marketplace, ecosystem needs, and user workflows became clearer.
- I built reusable modules around trust-critical objects: auction cards, bid tables, provider profiles, dataset summaries, status badges, wallet states, and settlement patterns. These modules allowed the interface to expand across new pages, flows, and communication touchpoints without fragmenting the experience. The system made the first release possible and gave later product work a stable foundation.
Solution
I designed BDX’s brand identity and product experience across the core workflows for both sides of the marketplace.
For Data Clients, the experience supported auction creation, storage requirement setting, bid evaluation, and dataset management. The interface helped clients understand why providers were bidding, compare offers clearly, and follow the path from auction to storage.
For Storage Providers, the product supported opportunity discovery, bid submission, fulfillment tracking, and performance monitoring. The interface gave providers a structured way to evaluate deals, compete on price and reliability, and manage their commitments.
The auction experience became the center of the product. It needed to do more than show numbers. It had to explain the market logic, surface meaningful differences between bids, and make payment and settlement feel traceable.
The modular design system supported the product as it expanded. It kept dense information readable, made Web3 states easier to understand, and helped the product maintain consistency across dashboards, marketplace pages, auction flows, provider-facing tools, event materials, and later iterations.
Impact
BDX launched with over 150 high-fidelity screens across both user roles and continued to evolve after the initial release.
The product reached real use in the Filecoin ecosystem. Data clients used the platform to source storage providers, and high-value public datasets moved onto the network through it.
BDX also became part of the ecosystem conversation around useful data onboarding. The team cohosted Data Onboarding Day with Protocol Labs at FIL Singapore 2022, and I designed the event’s online and offline materials.
Across the product lifecycle, my work helped BDX maintain a consistent trust language across product experience, brand presence, marketplace workflows, and ecosystem-facing moments.
For me, the most important outcome was the clarity of the market model. A highly counterintuitive product became understandable enough for early users, partners, and investors to evaluate.
Reflection
BDX was eventually sunset as Filecoin’s incentive and governance environment changed. From a design perspective, the project showed how important clarity is when users are asked to trust an unfamiliar market model.
The main lesson was that Web3 trust needs to be visible in the interface. Users needed clear signals around provider credibility, bid logic, wallet state, settlement timing, and dataset status. Technical concepts had to appear only when they helped users make decisions.
If I revisited the project, I would invest more in the content system behind the product. Concepts like DataCap, FIL and provider commitments needed consistent language across onboarding, auction details, and support states. A stronger content system would make the experience easier to scale as the marketplace introduced new rules, data types, and user roles.
The strongest design decision was recognizing that the product needed to make the incentive system trustworthy before it could make the marketplace efficient.
(Product currently offline)
