Modern marketplaces still rely heavily on centralized payment rails. This introduces friction: payment processors, escrow services, platform custody, and trust assumptions between buyers and sellers.
To explore a simpler architecture, we built a blockchain-native marketplace powered by:
- A stablecoin contract (WUSD)
- A payment coordination protocol (x402)
- A marketplace contract
The key idea is simple: payments and ownership changes should be enforced by contracts, not by backend services.
System Architecture
The system consists of three contracts:
- Marketplace Contract — stores items and manages ownership
- WUSD Stablecoin Contract — provides the payment token
- x402 Payment Contract — orchestrates payment verification and settlement
The x402 contract acts as a payment router that atomically verifies funds, transfers stablecoins, and updates marketplace ownership.
The Marketplace Contract
The marketplace contract maintains the inventory and ownership state. Each item contains an ID, name, URI pointing to external metadata, a price denominated in WUSD, and an owner field that is None when unsold.
The constructor deploys the marketplace, designates the deployer as owner, and seeds it with sample items. Crucially, the sale logic is intentionally minimal — the contract checks that an item is unsold and assigns the buyer as owner. Payment logic is delegated entirely to the x402 protocol.
The WUSD Stablecoin
WUSD is a fungible stablecoin built on top of a reusable token module. It supports standard transfers, allowance-based transfers, owner-restricted minting, and user-initiated burning. The contract tracks cumulative supply through total_minted and total_redeemed counters.
One notable addition is an embedded WebServer module, which allows the contract to serve static resources directly — useful for frontend hosting or asset distribution without an external server.
The x402 Payment Protocol
The x402 contract is the core of the system. Rather than executing payment directly, it introduces a payment intent — a lightweight record capturing who initiated a purchase and which resource they want to buy.
Generating an Intent
intent_id = generate_intent(item_id)
This stores the caller's address alongside the target item and returns an intent ID for use in the next step.
Submitting Payment
submit_payment(intent_id)
This single call performs three operations atomically:
- Verification — confirms the intent exists, the caller matches the original invoker, the item is still unsold, and the buyer's WUSD balance covers the price
- Token Transfer — moves WUSD from the buyer directly to the marketplace owner
- Ownership Update — calls
sell_item()on the marketplace contract to assign the item to the buyer
The x402 protocol communicates with the other contracts through proxy interfaces (WUSDProxy, MarketplaceProxy), keeping each contract focused on its own responsibility while the payment layer coordinates across them.
End-to-End Purchase Flow
A complete purchase looks like this:
- Buyer calls
generate_intent(item_id)→ receivesintent_id - Buyer calls
submit_payment(intent_id) - Contract verifies balance ≥ price
- WUSD transfers from buyer to marketplace owner
- Item ownership updates on-chain
All steps are enforced by contracts — no centralized backend required.
Design Takeaways
This architecture separates responsibilities cleanly:
- Marketplace: item registry, ownership state
- Stablecoin: fungible payment medium
- x402 protocol: payment verification, cross-contract coordination
The modular design allows replacing the token contract, plugging x402 into a different marketplace, or extending verification logic without modifying the marketplace itself.
Conclusion
The marketplace demonstrates how stablecoins and programmable payment protocols can replace traditional payment infrastructure. By introducing a lightweight intent-based payment layer, we coordinate token transfers and asset ownership changes across contracts in a deterministic and verifiable way.
The result is a marketplace where payments are on-chain, ownership updates are automatic, and no trusted intermediary is required. Everything is enforced directly by code.