Understand Sui object-centric design

Sui DeFi primitives rely on a fundamental shift in how data lives on-chain. Unlike EVM blockchains that group assets into shared account balances, Sui treats every asset as a distinct, independent object. This object-centric model allows for parallel processing, meaning transactions that touch different objects can execute simultaneously without waiting for others to clear.

Why this matters for DeFi

In traditional EVM models, two users swapping tokens on the same exchange often block each other because they interact with the same liquidity pool account. Sui removes this bottleneck. Because each token instance is an object with its own unique ID, the network can process multiple swaps in parallel as long as the specific objects involved are different.

This parallelism is the engine behind Sui DeFi primitives. It enables higher throughput and lower latency, which is critical for applications like decentralized exchanges (DEXs) and lending protocols where timing and capital efficiency are paramount. Developers can build complex financial instruments that react instantly to market changes without the congestion typical of account-based chains.

Sui DeFi primitives

The Move advantage

Sui’s object model is powered by the Move programming language. Move enforces strict ownership rules: an object can only be transferred, mutated, or destroyed by its current owner. This eliminates common smart contract vulnerabilities like reentrancy attacks, where malicious code exploits shared state to drain funds.

For DeFi developers, this means safer composability. You can build primitives that interact with other contracts or assets with greater confidence, knowing that the underlying objects are securely encapsulated. This security foundation allows for more innovative financial products that were previously too risky on account-based chains.

Set up the Move development environment

Before building Sui DeFi primitives, you need a local development environment that mirrors the Sui Mainnet. The official sui CLI handles package management, compilation, and local network testing. This section walks you through installing the toolchain and initializing your first project.

Sui DeFi primitives
1
Install the Sui CLI

The Sui CLI is the core interface for interacting with the Sui blockchain. Install it using the recommended shell script to ensure you get the latest stable version. This single binary manages your local node, package compilation, and transaction signing.

Shell
Shell
curl https://get.sui.io -sSf | sh

After installation, verify the setup by checking the version. This confirms the binary is in your system path and ready for use.

Shell
Shell
sui --version
Sui DeFi primitives
2
Initialize a new Move package

Create a new directory for your DeFi primitive. Use the sui move new command to scaffold the project. This command generates the standard Move package structure, including the sources directory for your Move modules and the Move.toml configuration file.

Shell
Shell
sui move new my_defi_primitive
cd my_defi_primitive

The Move.toml file defines your package dependencies. For most DeFi primitives, you will need to import the sui standard library, which provides essential types like Coin<T> and Balance<T>.

Sui DeFi primitives
3
Configure local dependencies

Open Move.toml and ensure the sui package is listed under [dependencies]. If you are building complex primitives, you may also need to import other community packages like sui-fungible-assets or sui-bridge for interoperability features.

TOMLN
TOMLN
Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework", rev = "framework/mainnet" }

Run sui move build to download dependencies and compile your code. This step catches syntax errors and type mismatches before you attempt to publish to the network.

Sui DeFi primitives
4
Start a local Sui node

To test your DeFi primitive, you need a local blockchain state. Run sui start to launch a local instance that mimics the Mainnet environment. This node stores all objects and accounts locally, allowing you to simulate transactions without spending real SUI tokens.

Shell
Shell
sui start

Keep this terminal open. It will serve as the backend for your local testing client.

DeFi Primitives on Sui
5
Fund your local test accounts

Your local node comes with pre-generated test accounts. Use the sui client to view these accounts and transfer SUI tokens to yourself for testing.

Shell
Shell
sui client addresses
sui client faucet

The faucet command mints test SUI to your active address. You can now deploy your compiled Move bytecode and interact with your DeFi primitive as if it were live on Mainnet.

Implement core DeFi primitives

Building on-chain financial logic requires more than just moving tokens; it requires structuring data so that value cannot be lost or duplicated. Sui DeFi primitives rely on the Move type system to enforce ownership and state transitions at the compiler level. This approach eliminates entire classes of bugs common in EVM-based smart contracts, such as reentrancy attacks, by ensuring that only the designated owner can modify an object's state.

Define the token structure

The foundation of any DeFi primitive is the token itself. In Move, tokens are represented as objects with unique IDs and typed fields. To create a standard fungible token, you define a TreasuryCap that allows minting and burning, ensuring that the total supply is strictly controlled by the protocol rather than arbitrary functions.

MOVE
module sui_defi::token {
    use std::option;
    use sui::object::{Self, UID};
    use sui::transfer;
    use sui::table::{Self, Table};

    struct SToken has key, store {
        id: UID,
        decimals: u8,
        supply: u64,
    }

    struct TreasuryCap has key {
        id: UID,
        total_supply: u64,
    }

    public entry fun mint(
        treasury: &mut TreasuryCap,
        recipient: address,
        amount: u64
    ) {
        // Mint logic ensures supply matches token balance
    }
}

Build the liquidity pool

Liquidity pools require a mechanism to track user deposits and withdrawals while maintaining price ratios. Sui’s object model allows you to represent the pool itself as a single object with a balance field that updates atomically. This atomicity ensures that a trade execution and the corresponding token transfer happen in the same transaction, preventing partial fills or state inconsistency.

When implementing the pool, use the Swap struct to define the exchange rate between two assets. The pool object holds these assets in its fields, and the swap function validates that the input tokens are transferred from the user to the pool before updating the internal balances.

Enforce type safety

The Move type system prevents invalid states by requiring explicit type conversions. For example, you cannot accidentally pass a SToken where a USD token is expected. By tagging assets with specific types, the compiler catches mismatches before the code is deployed. This strict typing is essential for DeFi primitives, where a single type error can lead to the loss of locked funds.

Use the assert! macro to validate preconditions before executing financial logic. For instance, check that the pool has sufficient liquidity before allowing a swap, or verify that the user owns the liquidity position before permitting a withdrawal. These checks are not just runtime safeguards; they are part of the contract’s interface, documented and enforced by the type system.

Test with formal verification

Sui supports formal verification tools that can mathematically prove the correctness of your smart contracts. By writing specifications for your functions, you can verify that invariants—such as "total supply equals sum of all balances"—hold true under all possible execution paths. This is particularly valuable for DeFi primitives, where the cost of failure is high.

Focus your testing on edge cases: what happens if a user swaps zero tokens? What if the pool is empty? Formal verification helps you identify these scenarios and ensure your code handles them gracefully without reverting or losing data.

FeatureEVM ApproachSui Object Model
OwnershipImplicit via account addressExplicit via Object ID
State UpdatesStorage slots (SSTORE)Object fields (mutable)
SafetyRuntime checks (require/assert)Compile-time type system
ParallelismSequential executionParallel transaction processing

Structure Sui DeFi Primitives for Parallel Execution

Sui’s object-centric model allows transactions to execute in parallel, but only when they touch distinct assets. To build high-performance Sui DeFi primitives, you must design your smart contracts to respect object boundaries. If two transactions attempt to modify the same object simultaneously, Sui halts one to maintain consistency. This serialization kills throughput. The goal is to maximize concurrency by isolating state changes.

Design for Object Isolation

Structure your Sui DeFi primitives so that each user interaction modifies a unique object. For example, in a lending protocol, isolate each borrower’s position into its own object rather than updating a single global ledger entry. When users deposit or withdraw, they interact only with their specific position object. This allows hundreds of users to transact simultaneously without blocking each other. Think of it like a library where each reader has their own desk; they can work at the same time without waiting for the previous person to finish.

Minimize Shared State Dependencies

Avoid creating bottlenecks by reducing reliance on shared mutable state. If your DeFi primitive requires a global counter or a shared liquidity pool snapshot, consider batching updates or using a separate accumulator object that is updated less frequently. Frequent access to shared objects forces Sui to serialize transactions, turning parallel potential into sequential processing. By decoupling user actions from global state, you ensure that your Sui DeFi primitives remain responsive even during peak network congestion.

Validate Object Ownership

Ensure that only the rightful owner can modify specific objects. Use Sui’s ownership model to enforce strict access controls. This prevents unauthorized state changes and reduces the need for complex locking mechanisms that can hinder parallel execution. Clear ownership rules simplify the concurrency logic and make your Sui DeFi primitives more secure and efficient.

13th
Sui ranks by TVL among DeFi platforms in 2026

Test and deploy Sui DeFi primitives

Deploying high-stakes financial code on Sui requires a disciplined verification sequence. Because Sui DeFi primitives handle real value, you must treat testing not as a final checkbox, but as the primary defense against logic errors and external exploits.

Sui DeFi primitives
1
Run local unit and integration tests

Validate core logic using Move’s built-in testing framework. Write unit tests for individual functions and integration tests for multi-step flows, such as depositing assets and calculating yields. Ensure your local environment mirrors the mainnet configuration to catch environment-specific bugs early.

Sui DeFi primitives
2
Execute formal verification and fuzzing

Sui’s Move language is designed for safety, but you must still prove invariants. Use formal verification tools to mathematically prove that your smart contracts cannot enter invalid states, such as negative balances or unauthorized token transfers. Fuzz testing helps find edge cases that standard unit tests might miss.

3
Conduct a third-party security audit

Never launch un-audited financial code. Engage a reputable security firm to review your smart contracts. The audit report should identify vulnerabilities, gas optimizations, and logic flaws. Address every finding before proceeding to deployment, as Sui DeFi primitives are immutable once deployed on mainnet.

4
Deploy to testnet for final validation

Push your verified contracts to the Sui testnet. This stage allows you to simulate real-world usage with testnet SUI tokens. Monitor transaction success rates, gas costs, and state changes. This final validation step ensures that your code behaves as expected in a live, albeit non-financial, environment.

5
Launch on mainnet with caution

Deploy to mainnet only after all testnet validations pass and the audit is complete. Start with a limited launch or a small treasury allocation to monitor initial performance. Watch for unexpected gas spikes or failed transactions, which may indicate issues not caught in earlier testing phases.

Before going live, ensure every item on your security checklist is complete. A single oversight in a DeFi primitive can lead to significant financial loss.

  • Unit tests cover all public functions
  • Integration tests verify multi-step workflows
  • Formal verification proves critical invariants
  • Third-party audit report reviewed and issues fixed
  • Testnet deployment validated with real-world scenarios

Frequently asked: what to check next