Why Sui changes DeFi primitives

Most EVM chains force DeFi protocols into a single, global state account. This account-based model creates a bottleneck: every transaction, whether it involves the same token or completely unrelated assets, must execute sequentially to prevent state collisions. Sui breaks this constraint by shifting from account-based storage to an object-centric model. In this architecture, every asset—tokens, NFTs, or protocol state—is a distinct object with its own unique ID and owner.

This distinction is the foundation of Sui’s parallel execution engine. When transactions involve disjoint sets of objects, the Move runtime can process them simultaneously rather than queuing them in a single line. For DeFi developers, this means higher throughput and lower latency, but more importantly, it enables new composability patterns that are difficult or expensive to implement on EVM chains.

Consider a typical DeFi interaction: a user swaps tokens on a decentralized exchange (DEX) while simultaneously claiming rewards from a yield aggregator. On an EVM chain, these actions often compete for the same global state locks. On Sui, if the underlying assets are distinct objects, the network can execute these operations in parallel. This architectural advantage reduces gas costs and prevents the "gas wars" that often disrupt DeFi operations during high network congestion.

The Move programming language reinforces this model by enforcing strict ownership and borrowing rules at the type level. Developers define how objects can be transferred or modified, ensuring that state transitions are predictable and safe. This combination of object-centric storage and parallel execution allows Sui to support high-frequency trading strategies and complex, multi-step DeFi primitives that require low latency and high finality.

By leveraging these primitives, developers can build protocols that are not just faster, but fundamentally more composable. The ability to treat assets as independent, parallelizable units opens the door to novel liquidity mechanisms and user experiences that were previously constrained by the sequential nature of traditional blockchain architectures.

Set up the Move development environment

Build DeFi Primitives on Sui works best as a sequence, not a scramble through settings. Do the minimum first: confirm compatibility, connect the core hardware, update only when needed, and test the result before adding optional features. That order keeps the task understandable and makes failures easier to isolate. After each step, pause long enough for the interface to finish syncing. Many setup problems are timing problems disguised as configuration problems. If the same step fails twice, record the exact error, restart the smallest affected piece, and retry before moving deeper.

1
Confirm prerequisites
Check compatibility, account access, firmware, network, and physical access before changing the Build DeFi Primitives on Sui setup.
2
Make one change at a time
Apply the setup steps in order so any connection, pairing, or permission failure is easy to isolate.
3
Verify the result
Test the final state from the app and from the physical device before adding automations or optional settings.

Implement shared liquidity with DeepBook

DeepBook is Sui’s native order book primitive, designed to replace traditional automated market makers (AMMs) with concentrated liquidity models. By allowing liquidity providers to allocate capital to specific price ranges, DeepBook achieves higher capital efficiency and tighter spreads. This structure mirrors traditional finance order books but leverages Sui’s parallel transaction processing to handle high-frequency trades without congestion.

To build a shared liquidity pool, you must interact with the deepbook_v3 module. The core concept involves creating a Pool object that manages the order book state and a Position object that tracks individual liquidity allocations. Because Sui uses an object-centric model, these components are distinct, composable, and can be updated independently.

Step 1: Define the trading pair and tick spacing

Before creating the pool, define the asset types and the tick spacing. Tick spacing determines the granularity of the order book. Smaller spacing offers better price discovery but requires more gas for updates. Choose a spacing that balances precision with cost.

MOVE
module my_project::deepbook_pool {
    use sui::coin::{Coin, Self};
    use sui::deepbook_v3::pool::{Pool, PoolId};
    use sui::deepbook_v3::tick::{Tick, TickId};
    use sui::object::{Self, UID};
    use sui::tx_context::{Self, TxContext};

    const TICK_SPACING: u64 = 10; // Adjust based on asset volatility
}

Step 2: Initialize the DeepBook Pool

Create the Pool object using the Pool::new function. This function requires the two asset types (base and quote) and the tick spacing. The pool object acts as the central registry for all orders and liquidity positions within that trading pair.

MOVE
public fun create_pool(
    base_coin: Coin<BASE_TOKEN>,
    quote_coin: Coin<QUOTE_TOKEN>,
    ctx: &mut TxContext
): PoolId {
    // Initialize the pool with the specified tick spacing
    let pool_id = Pool::new(
        base_coin, 
        quote_coin, 
        TICK_SPACING, 
        ctx
    );
    
    // Return the unique ID for the pool
    pool_id
}

Step 3: Add concentrated liquidity

Liquidity providers do not deposit into a global pool. Instead, they create a Position within a specific price range. This concentrated approach means that a smaller amount of capital can support significant trading volume, provided the price stays within the allocated range. If the price moves out of range, the position becomes inactive.

MOVE
public fun add_liquidity(
    pool_id: PoolId,
    tick_lower: u64,
    tick_upper: u64,
    coin_base: Coin<BASE_TOKEN>,
    coin_quote: Coin<QUOTE_TOKEN>,
    ctx: &mut TxContext
): UID {
    // Create a new position within the specified tick range
    let position = Pool::add_liquidity(
        pool_id,
        tick_lower,
        tick_upper,
        coin_base,
        coin_quote,
        ctx
    );
    
    // Return the position ID to track the liquidity
    position
}

Step 4: Execute trades using the order book

Once liquidity is in place, traders can submit limit or market orders. Sui’s parallel execution engine processes these orders efficiently. Unlike EVM-based DEXs that rely on a single transaction per block, Sui can process multiple orders in parallel, reducing latency and improving fill rates. The Pool::place_order function handles the logic for matching bids and asks.

MOVE
public fun place_limit_order(
    pool_id: PoolId,
    is_buy: bool,
    tick: u64,
    amount: u64,
    ctx: &mut TxContext
): UID {
    // Place a limit order at the specified tick
    let order = Pool::place_order(
        pool_id,
        is_buy,
        tick,
        amount,
        ctx
    );
    
    order
}

Step 5: Remove liquidity and claim assets

When a liquidity provider decides to exit, they can close their position. This action burns the Position object and returns the underlying assets (base and quote coins) to the provider’s wallet. The amount returned depends on the current price and the volume traded within their price range.

MOVE
public fun remove_liquidity(
    pool_id: PoolId,
    position_id: UID,
    ctx: &mut TxContext
): (Coin<BASE_TOKEN>, Coin<QUOTE_TOKEN>) {
    // Close the position and retrieve the underlying assets
    let (coin_base, coin_quote) = Pool::remove_liquidity(
        pool_id,
        position_id,
        ctx
    );
    
    (coin_base, coin_quote)
}

Key Takeaways

  • Concentrated Liquidity: DeepBook allows liquidity to be allocated to specific price ranges, increasing capital efficiency compared to uniform AMMs.
  • Parallel Processing: Sui’s architecture enables high-throughput order matching, reducing slippage and latency for traders.
  • Object-Centric Design: Pools and positions are distinct objects, making them composable and easy to manage within the Move language.

How does DeepBook differ from traditional AMMs?

Traditional AMMs use a constant product formula ($x * y = k$) where liquidity is spread uniformly across all prices. DeepBook uses a limit order book model with concentrated liquidity, allowing providers to target specific price ranges. This results in better price execution and lower capital requirements.

Can I use DeepBook for cross-chain assets?

Yes, as long as the assets are wrapped and exist on the Sui network. You can create pools for any pair of Sui-compatible tokens, including wrapped versions of Ethereum or Bitcoin assets that have been bridged to Sui.

What happens if the price moves out of my liquidity range?

If the market price moves outside your allocated tick range, your position becomes inactive. No new trades will be executed against your liquidity until the price returns to your range. You can adjust your range by adding new liquidity or removing existing liquidity.

Create yield strategies with programmable blocks

Programmable Transaction Blocks (PTBs) allow you to bundle multiple operations—such as swapping assets, depositing into a lending protocol, and staking—into a single atomic transaction. On Sui, this isn't just about convenience; it's about composability. Because Sui uses an object-centric model, these primitives can be manipulated and combined without the linear bottlenecks of traditional EVM-style execution. You can construct complex yield strategies that execute in parallel, ensuring that either all steps succeed or the entire transaction reverts, eliminating partial execution risks.

1
Define the input assets and targets

Start by identifying the assets you want to yield-generate and the protocols involved. For example, you might want to swap SUI for USDC, then supply that USDC to a lending market, and finally stake the resulting liquidity position. In your Move code, declare the input objects (e.g., Coin<SUI>) and the target protocol addresses. This step ensures your PTB has the necessary inputs to execute the chain of operations.

2
Compose the swap operation

Use the DEX primitive to swap your base asset for the target collateral. In a PTB, you can call the swap function directly, passing the input coin and the desired output type. Because Sui processes transactions in parallel, this swap can occur alongside other preparatory logic without contention. Ensure you handle the output Coin<T> object, as it will be the input for your next step.

3
Execute the lending deposit

Take the output from the swap and pass it to the lending protocol’s deposit function. This creates a new object representing your lent position (e.g., aUSDC). In a PTB, you can chain this directly: the output of the swap becomes the input of the deposit. This atomicity guarantees that you never hold the intermediate asset, reducing exposure to price volatility during the strategy execution.

4
Add staking or further yield layers

If your strategy requires staking, take the lending receipt object and pass it to the staking module. You can also add conditional logic using Move’s if statements within the PTB to handle different market conditions or to split the yield path. The final output of your PTB should be the final yield-bearing object, such as a staked token or a liquidity pool share, which is then returned to the user.

5
Validate and submit the PTB

Before broadcasting, verify that all object dependencies are met and that the gas budget covers the parallel execution costs. Submit the PTB using the Sui SDK. The network will execute the block atomically; if any step fails, the entire transaction is rolled back, preserving the integrity of your assets. This atomic guarantee is a core benefit of DeFi primitives on Sui, ensuring that complex strategies remain safe and efficient.

Test parallel execution and gas costs

Before deploying to mainnet, you must prove that your DeFi primitive handles concurrent transactions without contention and remains cost-effective under load. Sui’s object-centric model allows independent objects to be processed in parallel, but shared state creates bottlenecks. Your testing strategy should focus on verifying that your code leverages this parallelism rather than serializing through a single locked object.

Verify parallel transaction processing

The core differentiator of Sui is that transactions only need to lock the objects they directly interact with. If your DeFi protocol involves multiple users interacting with distinct liquidity pools or positions, these transactions should execute in parallel. To test this, simulate high-concurrency scenarios using the Sui CLI or Move test framework.

Create a test suite that submits multiple transactions simultaneously. Each transaction should target a different object instance. If your gas report shows that these transactions are executed sequentially, you likely have a hidden shared state dependency causing contention. For example, if a global registry object is updated in every trade, you serialize the entire protocol. Refactor to use per-pool or per-user objects to restore parallelism.

Analyze gas costs under load

Gas efficiency is critical for DeFi viability. Use the sui client gas command to inspect the gas budget for your functions. Move compiles code to bytecode, and the Sui VM charges gas based on computational steps and storage costs. You want to minimize storage footprint by using compact structs and avoiding unnecessary object transfers.

Run your test suite with gas profiling enabled. Look for functions that spike in gas usage due to large vector iterations or excessive object cloning. If your protocol involves frequent state updates, ensure you are using transfer and freeze_object efficiently. High gas costs during peak times can deter users, so aim for consistent, low-cost execution regardless of network load.

Practical testing checklist

  • Submit concurrent transactions targeting different objects to confirm parallel execution.
  • Check gas reports for sequential execution penalties indicating shared state bottlenecks.
  • Profile gas usage for core functions to identify optimization opportunities.
  • Simulate peak load conditions to ensure stability and cost predictability.

Common Sui DeFi development mistakes

Move’s object-centric model and parallel transaction processing (PTBs) offer unmatched throughput, but they introduce unique pitfalls for developers migrating from EVM-style chains. The most frequent error is misunderstanding object ownership and transfer semantics. In Move, objects are distinct entities with explicit ownership; treating them like mutable storage slots leads to runtime panics or logic errors.

Another critical mistake is improper gas estimation in Parallel Transaction Blocks. Because Sui processes transactions in parallel, the gas limit must account for the most expensive branch of execution. Underestimating this leads to failed PTBs that waste user time and erode trust.

MOVE
// Mistake: Assuming standard transfer semantics apply to unique objects
transfer::transfer(object, recipient); // Panics if object is not owned by sender

// Fix: Ensure explicit ownership transfer or use public objects
assert!(object.owner == sender, Error::EUnauthorized);

Finally, developers often ignore the immutability of certain object types. Attempting to mutate an Object<T> that should remain immutable breaks composability with other DeFi primitives. Always verify the object’s type constraints before attempting any state changes within a PTB.

Frequently asked questions about Sui DeFi

What is a DeFi primitive?

DeFi primitives are the foundational building blocks—such as atomic swaps, lending pools, or liquidity markets—that developers combine to create complex applications. On Sui, these primitives leverage the object-centric model, where assets are distinct, owned objects rather than shared account balances. This structure allows for parallel transaction processing, enabling multiple primitives to interact simultaneously without the bottlenecks common in account-based chains.

What is the DeFi protocol on Sui?

Sui hosts a variety of decentralized exchanges (DEXs) and lending platforms that utilize concentrated liquidity protocols. By allowing liquidity providers to allocate capital within specific price ranges, these protocols enhance capital efficiency and provide deep liquidity. This enables users to execute large trades with minimal slippage, a critical feature for high-frequency DeFi strategies.

Is Sui centralized or decentralized?

Sui is designed as a fully integrated, modular tech stack built for decentralized coordination. While it uses a unique consensus mechanism involving a committee of validators, the network ensures that composable primitives remain open and permissionless. Developers can build and deploy smart contracts without centralized approval, maintaining the core ethos of decentralized finance.

Is SUI a DeFi coin?

SUI is the native utility token of the Sui Network, serving as the primary asset for transaction fees, staking, and governance. The network has seen rapid growth in its DeFi ecosystem, with Total Value Locked (TVL) reaching significant milestones in 2025. Its design supports high-throughput DeFi applications, making SUI a central component of the network’s economic activity.