In partnership with the Sui Foundation, OpenZeppelin has been equipping developers with tools to build production-ready applications on Sui, including libraries for DeFi Math and Access Management in OpenZeppelin Move Contracts.
The marketplace reference build puts these tools to work: an end-to-end example showing how to build USD-pegged commerce that accepts multiple token types via Pyth Network oracles, spanning contracts, transaction logic, and frontend.
The marketplace shows Sui's three-layer architecture, a pattern used across production apps:
Move Smart Contracts (bottom): Smart contracts that define state, enforce business rules, and encode access control. The marketplace uses this layer to manage items, pricing, and permissions through the ShopOwnerCap capability.
TypeScript Orchestration (middle): Atomic composition units that orchestrate multiple smart contract calls without requiring new contract deployment. The marketplace uses PTBs to coordinate price feeds, purchase logic, and settlement.
React frontend (top): Client applications that construct PTBs, manage wallet connections, and submit transactions. The marketplace frontend handles wallet integration, real-time data, and transaction building before signing.
Sui applications are built on three principles. Understanding them explains every design decision in the marketplace.
Ownership: Every object has an owner. Authorization isn't something you check, it's built into the object itself. If you own something, you can act on it.
Object-Centricity: State and identity live in objects. Listings, discounts, currencies, receipts, capabilities, and oracles are all addressable on-chain objects.
Capabilities: Permissions are generally handled by typed objects you possess. Instead of checking conditions, you pass proof of authorization to functions.
Items within the Shop object are stored as separate entries using dynamic fields, not as independent objects. Concurrent buys are sequenced through consensus (the contract for mutable shared access), but Sui's shared-object throughput is high enough that this rarely matters in practice. Splitting listings into their own shared objects would buy parallelism at the cost of heavier indexer, client queries and extra per-listing storage.
The Shop owner configures which currencies they accept: the marketplace reference build is currency agnostic. The frontend fetches current Pyth prices and includes them in the transaction. The blockchain verifies they're recent and uses them atomically, without calling an oracle contract.
The owner has ShopOwnerCap: a typed object. Functions that modify the shop require it. Without it, the transaction can't be constructed. Authorization isn't checked at runtime. It's enforced by the type system.
Discounts, listings, and accepted currencies are composed as dynamic fields within a single Shop object, utilizing Sui's Table data structure. This keeps related marketplace data organized while preventing vulnerabilities like multiple redemptions from the same user. Authorization flows through the ShopOwnerCap capability.
Purchases, inventory changes, and discount claims each emit an event. Your backend subscribes and reacts in real time without polling. Events keep offchain systems in sync automatically.
Functions don't check "are you the owner?" Instead, they require ShopOwnerCap as a parameter. The type system guarantees its presence or the transaction fails. No runtime checks and no modifiers.
In our hands-on walkthrough, we show how to build a marketplace featuring:
The marketplace reference build is live on GitHub, demonstrating production-grade Sui architecture: object ownership, capability-gated authorization, and pull-based oracle integration via Pyth, built with OpenZeppelin Contracts for Sui. Fork it and use it as a starting point for your own protocol!
Additional developer resources can be found at docs.openzeppelin.com/contracts-sui and docs.sui.io.
What is the Sui marketplace reference build?
It's a complete, battle-tested marketplace application built on Sui that demonstrates production-grade architecture. It shows how to structure access control, decompose state, integrate oracles, and emit events, all in a working system.
How does the oracle integration work?
The frontend fetches the latest Pyth price data and includes it directly in the transaction. The contract verifies the price is fresh (within confidence bounds) and uses it atomically to calculate how much token to charge. This is more efficient than onchain oracle calls because there's no external contract dependency or latency.
How does Sui's approach differ from EVM?
On EVM, you call an oracle contract onchain to fetch prices, which adds latency and creates a contract dependency. On Sui, prices travel in the transaction itself: the client fetches them and the contract verifies freshness. Both approaches are valid; Sui's model is more efficient for high-throughput applications because it eliminates the oracle contract call.