What is DEEP?
What is DEEP? Learn how DeepBook’s token connects on-chain trading fees, staking, governance, burns, supply unlocks, and market access.
Introduction
DEEP is the token behind DeepBook, the on-chain central limit order book built on Sui, and its value depends less on branding than on whether DeepBook becomes a real liquidity venue that traders and market makers actually use. If DeepBook becomes important inside Sui DeFi, DEEP is the instrument through which fees, incentives, eligibility, and governance are organized. If DeepBook remains peripheral, DEEP’s role weakens with it.
The compression point for this token is straightforward: DEEP is not a generic ecosystem token. It is the operating token for a specific market structure. DeepBook is trying to be shared order-book infrastructure for the Sui ecosystem rather than a single retail app. Buying DEEP is therefore exposure to whether an on-chain order book on Sui can become the place where liquidity concentrates, and whether the protocol’s fee-and-burn design can convert that usage into token demand and lower effective supply.
DeepBook itself is a decentralized central limit order book, or CLOB. Traders and market makers place explicit bids and offers into an order book rather than depositing into an automated market maker curve. Sophisticated liquidity providers often prefer that model because it gives exact control over prices and size. DeepBook’s design aims to make an order-book venue workable on-chain by using Sui’s fast execution paths and low fees.
What does DEEP do in DeepBook?
DEEP sits at the center of four linked functions in DeepBook’s design: paying trading fees, qualifying for fee discounts and maker incentives through staking, governing key pool parameters, and absorbing residual fee flow through burns. These are connected parts of one system. They are how the protocol tries to bootstrap and defend liquidity.
The first function is transactional. In the documented design, DEEP is used for trading fees on DeepBook. That gives the token a direct role in market activity: if you want to use the venue under its tokenized fee model, DEEP has to appear somewhere in the flow.
The second function is eligibility. DeepBook does not simply hand out rewards to anyone holding DEEP passively. To participate in its volume-based taker fee program and its maker incentive program, users must stake a minimum amount of DEEP on a specific pool for an epoch. Those stakes do not earn a passive base yield for merely existing. Staking changes your economic status inside the market: it can make taker trading cheaper, and it can make market makers eligible for rebates or incentives.
The third function is control. DEEP staked in individual pools gives governance rights over that pool’s key parameters. Governance is intentionally narrow. Tokenholders are not voting on everything; they can change a small set of variables that shape market economics, including the taker baseline fee, the maker fee, and the minimum stake requirement for participation.
The fourth function is sink. After fees are collected and incentives are distributed, residual fees can be burned. This is one of the most economically important parts of the design because it removes a portion of token flow from circulation rather than routing it back to insiders or a treasury by default.
Put together, DEEP is best understood as a market-access and market-control token whose strongest claim to value is that actual order-book usage can require it, lock it, and burn it.
How does DeepBook convert trading activity into demand for DEEP?
The economic question for any exchange token is simple: does usage force people to acquire or hold the token, or is the token mostly decorative? DeepBook’s answer is more rigorous than many exchange-token designs because it ties token utility to participation conditions inside the venue itself.
For takers, staking DEEP can lower trading fees. For makers, staking DEEP can make them eligible for incentives and rebates. Active users may need to hold and commit DEEP because it improves their economics on the venue. This is the healthiest form of token demand: users acquire the token to do a job more cheaply or profitably.
The strength of that demand depends on a chain of cause and effect. DeepBook needs meaningful trading volume and useful pools. Useful pools attract makers because order books with flow are worth quoting. Makers then improve execution quality and depth, which can attract more takers and downstream Sui apps. If that flywheel works, more participants may find it rational to acquire and stake DEEP to reduce fees or qualify for incentives. If it does not work, the token’s functional demand shrinks.
That is why DeepBook positions itself as wholesale liquidity infrastructure for Sui rather than just another standalone trading app. An order book becomes more valuable when other applications route into it, integrate it, or rely on it as shared liquidity. The token thesis is stronger if DeepBook becomes a base layer for Sui DeFi than if it depends only on one frontend’s retail traffic.
There is also a more subtle demand driver: pool creation. Developer documentation indicates a permissionless pool creation fee of 500 DEEP. Compared with trading usage, this is a smaller demand engine, but it still creates a direct token cost for expanding the venue’s market surface and discourages spam pool creation.
Why does DeepBook burn fees and how does that affect DEEP scarcity?
Many tokens claim to benefit from fees, but the crucial detail is where those fees go. If fees are routed to a treasury, insiders, or future discretionary programs, traders can reasonably assume paid fees may later return to circulation or subsidize the same users who paid them. DeepBook’s whitepaper makes a different choice for residual fees: burn them.
That choice is not cosmetic. It is presented as the protocol’s defense against wash trading, which is trading with yourself or an aligned counterparty to farm rewards. If users believed that the fees they paid could later be recouped through redistribution, fake volume could become economically attractive. Burning residual fees tries to make that recouping impossible. The whitepaper explicitly frames this logic as inspired by Ethereum’s EIP-1559 fee burn model.
The implication is straightforward. DEEP has a fixed launch supply and no further minting, but fixed-supply tokens do not automatically get scarcer in practice. A burn mechanism can offset circulation growth from unlocks and reduce outstanding supply over time, but only if the venue generates real fee flow. The burn strengthens the token thesis conditionally. It is powerful if DeepBook is used. It is mostly symbolic if usage stays thin.
There is an important caveat in the design. If a pool lacks oracle pricing to DEEP, fees may be collected in pool tokens rather than DEEP, and those fees are not automatically rebated or burned under the same clean logic. The later handling of those accumulated non-native assets is left to governance. The cleanest version of the token sink therefore works best where DEEP-denominated fee accounting is available.
How do DeepBook's maker incentives work and what tradeoffs do they create?
DeepBook is explicitly trying to solve a bootstrapping problem: order books are unattractive when they are thin, but they only become thick if makers are willing to quote into them early. DEEP is the tool used to bridge that gap.
The protocol’s maker incentives are designed to be countercyclical. Incentives are stronger when liquidity is scarce and fade as liquidity becomes plentiful. The whitepaper describes a shared phaseout point for a pool and epoch: once aggregate liquidity from other makers is high enough, a maker’s incentive falls to zero. This is meant to avoid overpaying for liquidity that the market is already supplying on its own.
Many token incentive schemes spray rewards regardless of whether they are still needed. DeepBook’s design is more disciplined. It tries to pay for missing liquidity rather than permanent mercenary liquidity. The whitepaper also states the system is parameterized so that aggregate incentives paid are no greater than aggregate fees collected, which acts as a solvency safeguard.
Still, the tradeoff is real. The protocol acknowledges its anti-wash-trading defenses are imperfect, especially in low-liquidity periods when incentives need to be generous enough to bootstrap activity. DEEP holders are exposed to a difficult balance: incentives must be strong enough to attract market makers early, without becoming a subsidy machine for low-quality or circular volume.
How does staking DEEP change your exposure compared with just holding it?
Holding DEEP idle and staking DEEP on pools are different exposures.
An idle holder owns a token with a fixed maximum supply, governance potential, and whatever market narrative surrounds DeepBook’s adoption. But an idle holder is not automatically participating in the protocol’s fee discount system or its maker-incentive eligibility. Passive holding is the weakest form of exposure because you are relying on the market to price the token’s role without directly using that role.
A staker is making a more specific bet. Staking commits DEEP to a pool for an epoch and converts the token from a passive asset into a market credential. If you are a taker, the point is lower fees. If you are a maker, the point is incentive eligibility and governance influence. The cost is reduced flexibility: staked tokens are committed to a specific venue context rather than remaining fully liquid for immediate sale or redeployment.
DeepBook’s governance also operates at the pool level, which makes staking more granular than a broad vote on the whole protocol. You are aligning with the economics of particular markets. That is a more operational form of governance than many token systems, but its value depends on whether individual pools become economically important.
The whitepaper’s voting function is also worth noting because it changes what large stakes mean. Voting power is linear up to a cutoff and then becomes concave, roughly square-root-like beyond that point. The intent is to reduce governance capture by very large holders while still preserving the importance of stake. This does not eliminate concentration risk, but owning twice as many tokens does not necessarily translate into twice as much effective governance influence at larger sizes.
What does DEEP's fixed 10 billion supply mean for unlocks and circulating supply?
DEEP launched with exactly 10 billion tokens and no further minting. That removes perpetual inflation risk from future token issuance. But fixed max supply is only the starting point. Market exposure depends on how much of that supply is circulating, how much is vesting, and how much may become liquid over time.
The primary project materials describe the broad split as 10% for an initial community airdrop, about 31.02% for core contributors and early backers, and about 58.98% for future grants and community programs. Secondary tokenomics summaries break that down more specifically into roughly 61.57% community, 10% initial airdrop, 10.93% investors, 10% Mysten Labs, and 7.5% early contributors. Those summaries also describe staggered vesting: the airdrop unlocked at launch, community allocations vest over a long multi-year schedule, and investor and contributor buckets include a 12-month cliff followed by 24 months of linear release.
The practical takeaway is that DEEP is not an inflationary token in the minting sense, but it is still subject to dilution of float through unlocks. Existing holders may face selling pressure not because new tokens are created, but because already-existing tokens become transferable.
This makes the burn mechanism more relevant. Burns can counteract some unlock-related supply expansion, but only if DeepBook generates enough fee activity. DEEP’s effective supply trajectory is therefore the result of two opposing forces: vesting adds liquid float over time, while burns can remove tokens from circulation. The market exposure is to that net effect, not just to the headline “10 billion max supply.”
What governance powers does DEEP grant, and what can tokenholders not change?
Governance can strengthen a token or hollow it out, depending on how much it can change. DeepBook’s design is relatively constrained. Pool governance can change only a small number of parameters, and fee parameters are bounded. For non-stableswap pools, the taker baseline fee cannot exceed ten basis points or fall below five basis points; stableswap pools have their own lower bounds.
Those constraints limit a common failure mode in exchange governance: tokenholders using governance to overextract fees from captive users. By narrowing the menu of things governance can change, DeepBook is trying to keep market settings competitive and predictable.
This also clarifies what DEEP governance is not. Holding the token does not give you open-ended claims on protocol cash flows, treasury discretion, or unrestricted rule changes. It gives bounded control over the local economics of participation. That is less romantic than broad community-ownership language, but it is more concrete.
What risks could weaken DEEP’s role as DeepBook's operating token?
The main risk is not abstract competition; it is failure to become indispensable liquidity infrastructure. DEEP is strongest if Sui applications and traders actually route through DeepBook and if order-book liquidity concentrates there. It is weaker if Sui liquidity remains fragmented, if AMMs remain good enough for most use cases, or if rival venues capture the most valuable flow.
A second risk is that token-required fees or staking requirements may feel like friction rather than utility. If users can get similar execution elsewhere without needing to source and manage DEEP, the token’s built-in demand could be weaker than intended.
A third risk is operational and security-related. DeepBook’s account model includes BalanceManager objects with one immutable owner and up to 1,000 traders, where only the owner can deposit or withdraw. That can be useful for structured trading workflows, but it introduces custody and permissions considerations for teams and integrations. Separately, reputable secondary sources indicate no formal third-party audit was listed on the referenced monitoring pages. Public code and visible development activity help, but they are not the same as an audit.
There are also unresolved design edges. The treatment of non-DEEP fees in pools without DEEP oracle pricing is left to governance. Some earlier repository materials described initial-release restrictions such as permissioned pool creation and DEEP-denominated fee requirements that were expected to evolve. For investors, parts of the token’s market role depend on implementation choices that can change over time, even if the high-level design is already clear.
How can you buy DEEP and how do custody choices affect its on‑chain utility?
For most people, buying DEEP on an exchange gives price exposure to the token, not automatic participation in DeepBook’s on-chain fee discounts, maker programs, or governance. To get those functions, you generally need the token in a context where you can stake it on the relevant pools and interact with the protocol directly.
The distinction also affects custody. Keeping DEEP on a centralized exchange may be convenient for trading and rebalancing, but it is different from self-custody on Sui where you can use the token in-protocol. If your goal is simply market exposure, exchange custody may be enough. If your goal is to use DEEP as a market credential inside DeepBook, you need a setup that supports on-chain control.
Readers who want straightforward access can buy or trade DEEP on Cube Exchange, moving from a bank-funded USDC balance or an external crypto deposit into either a simple convert flow or spot trading from one account. That changes the user experience, not the token’s underlying economics: what you hold is still DEEP, but the convenience of exchange access is different from the fuller on-chain exposure that comes with self-custody and protocol staking.
Because DEEP is a Sui-native token, verifying the correct token address and network is important whenever you withdraw or self-custody. The published Sui token identifier is 0xdeeb7a4662eec9f2f3def03fb937a663dddaa2e215b8078a284d026b7946c270.
Conclusion
DEEP is best understood as the operating token of an on-chain order book, not a generic ecosystem chip. Its value proposition rests on a simple loop: if DeepBook becomes important liquidity infrastructure on Sui, users may need DEEP to trade efficiently, qualify for incentives, govern pool settings, and absorb fee flow through burns. If that venue importance does not materialize, the token’s role becomes much easier to bypass.
How do you buy DeepBook?
DeepBook can be bought on Cube through the same direct spot workflow used for other crypto assets. Fund the account, choose the market or conversion flow, and use the order type that fits the trade you actually want to make.
Cube lets readers move from a bank-funded USDC balance or an external crypto deposit into trading from one account. Cube supports both a simple convert flow for first buys and spot markets with market and limit orders for more active entries.
- Fund your Cube account with fiat or a supported crypto transfer.
- Open the relevant market or conversion flow for DeepBook and check the current price before you place the order.
- Use a market order for immediacy or a limit order if you want tighter price control on the entry.
- Review the estimated fill and fees, submit the order, and confirm the DeepBook position after execution.
Frequently Asked Questions
Staking DEEP commits tokens to a specific pool for an epoch and makes you eligible for taker-fee discounts, maker incentives/rebates, and pool-level governance; it reduces liquidity flexibility because staked tokens are locked into that pool context rather than remaining immediately transferable.
Residual fees after rebates and incentives are burned under the whitepaper’s design (inspired by EIP‑1559) to remove tokens from circulation and defend against recouping fees via redistributions, but that burn only meaningfully tightens supply if the venue generates substantial fee flow.
Governance is granular and pool‑level: DEEP staked in an individual pool grants voting control only over a small set of that pool’s parameters (e.g., taker baseline fee, maker fee, minimum stake), and fee bounds (like taker fees) are explicitly constrained in the design.
The protocol uses burns and countercyclical maker incentives (stronger when liquidity is scarce, phasing out as liquidity grows) to discourage wash trading, but the whitepaper acknowledges these defenses are imperfect - especially in low‑liquidity periods when generous incentives are needed to bootstrap activity.
Purchasing DEEP on an exchange gives you price exposure, but to receive on‑chain fee discounts, participate in maker programs, or exercise pool governance you generally need on‑chain control of the token and must stake it in the relevant pool; exchange custody alone does not automatically enable those protocol functions.
DEEP has a 10 billion fixed max supply, but large allocations are vesting over multiple years and therefore add transferable float over time; burns can offset some of that unlock‑driven supply expansion, so effective circulating supply is the net result of vesting unlocks versus protocol burns rather than the headline cap alone.
If a pool lacks an oracle price for DEEP, the highest fee tiers may be collected in the pool’s native tokens rather than DEEP, and those accumulated non‑DEEP assets are not automatically rebated or burned - the whitepaper leaves their later treatment to governance.
Public materials and monitoring pages indicate the project did not list a formal third‑party audit on the referenced CertiK page (the repository and public code exist, but a formal third‑party audit report was not shown there), which is a noted operational caveat in the source evidence.
DeepBook’s token design targets an on‑chain CLOB use case - DEEP is intended as a market‑access and market‑control token for order‑book trading where makers and sophisticated liquidity providers prefer explicit bids/offers; that differs from AMM tokens, which are primarily tied to liquidity provisioning on curves rather than order‑book credentials.
Maker incentives are explicitly countercyclical and phase out once aggregate liquidity crosses a pool‑specific threshold (the design uses a phaseout point tied to recent median liquidity), and the system is parameterized so aggregate incentives are no greater than aggregate fees collected to help preserve solvency - this reduces permanent mercenary reward payments but requires careful calibration early on.
Related reading