How to Build on Sui DeFi Primitives in 2026

Create a new Move project using sui move new <project_name>. This generates a directory structure with a sources folder for your .move files and a tests folder for integration tests. Open the Move.toml file to configure dependencies. For DeFi primitives, you will likely depend on the sui-framework and potentially third-party libraries like deepbook or sui-swap. Ensure your version field in Move.toml matches the current network epoch to avoid compatibility errors with the unified primitive layer.

Before deploying to testnet, spin up a local Sui node to test your primitives in isolation. Run sui start to launch the full node, indexer, and faucet service. The local network provides free SUI tokens for gas, allowing you to iterate quickly. Use sui client to interact with this local instance. This step is critical for debugging object ownership and capability checks, which are central to Sui’s DeFi security model.

Connect your wallet to the local environment by running sui client active-address. Ensure you have received test tokens from the local faucet using sui client faucet. Test your setup by compiling your Move code with sui move build and running the test suite with sui move test. A successful build confirms that your environment can correctly parse and execute the Sui-specific Move types required for DeFi primitives.

Create a public entry function to mint new tokens. This function typically takes a signer (the publisher or admin) and creates a new MyToken object. Use object::new(&mut ctx) to initialize the object ID and attach the initial supply. You can then use transfer::public_transfer to send the newly minted token to a recipient's address.

public entry fun mint(
    signer: &signer,
    recipient: address,
    initial_supply: u64
) {
    let token = MyToken {
        id: object::new(&mut signer),
        amount: initial_supply,
        name: string::utf8(b"MyToken")
    };
    transfer::public_transfer(token, recipient);
}

Define functions to allow users to transfer their tokens or burn them to reduce supply. Since MyToken has store, it can be moved freely. To burn, simply drop the object, which destroys it and removes it from the blockchain state. This explicit control over the asset's lifecycle is a core feature of Sui's object model.

public entry fun burn(token: MyToken) {
    let MyToken { id, amount, name } = token;
    object::delete(id);
}

Instead of manually placing limit orders, you can deploy an Automated Market Maker (AMM) vault that manages liquidity within DeepBook’s order book structure. This vault automatically rebalances positions based on market price, providing continuous depth. The 2026 update introduced "DeepBook Margin," allowing these vaults to offer leveraged liquidity provision, attracting more capital from yield farmers.

Once the vault is live, your dApp can interact with the DeepBook smart contract to execute trades. Users can place market or limit orders directly through your interface. Ensure your frontend queries the latest order book depth from the registry to display accurate pricing. This integration leverages Sui’s parallel execution to ensure trades settle instantly, even during high volatility.

Group operations that access disjoint sets of objects into a single transaction. Sui’s parallel execution engine will then schedule these groups concurrently. For example, if you are claiming yield from three different DeepBook Margin positions, and each position uses a distinct underlying asset object, you can bundle these claims into one transaction. The VM executes them in parallel, saving gas compared to sequential calls.

Before deploying to mainnet, test your transaction structure using the Sui local network. Observe the execution trace to confirm that the VM identified parallelizable segments. If you see serialization points where operations were forced to run sequentially, revisit your object access patterns. Adjusting which objects are passed as arguments can often unlock parallelism.

Simulate user interactions by calling your primitive’s entry functions. Verify that state changes occur as expected and that the object model correctly handles dynamic fields. Check that gas consumption aligns with your estimates, as S2 primitives often introduce new computational patterns that differ from legacy Move contracts.

Run sui move check against your module. This step catches type errors and invariant violations before they reach the network. For DeFi primitives, ensure that access control modifiers (e.g., public entry fun) restrict state mutations to authorized functions only. Fix any warnings related to object ownership or transferability.

Use the Sui Explorer or a local indexer to inspect the published objects. Confirm that the initial state is correctly initialized and that no unexpected capabilities are exposed. If your primitive involves liquidity pools or staking, verify that the balance calculations match your off-chain tests.

Once testnet verification passes, update your Move.toml to point to the mainnet framework version. Re-compile and perform a final dry run. Document the object IDs and any configuration parameters for your mainnet deployment script. Your primitive is now ready for production.