Can Your App Reach Sui DeFi Without Deploying on Sui in 2026?

Sui DeFi is the set of lending, trading and liquidity protocols deployed on Sui, a Move-based layer 1 that uses an object-centric state model and parallel execution instead of a single global transaction queue. For a team whose product already runs somewhere else, the useful question is not what Sui DeFi contains but whether reaching it means learning Move and deploying there. It does not, and this article sets out the three access paths, what the SDK actually looks like against a Sui spoke, and which Sui assets are routable today.

Before going further, three things decide this for most teams. Deployment: reaching Sui liquidity does not require Move code or a Sui deployment, and the cheapest path is usually not the obvious one. Coverage: Sui is one of 21 networks SODAX runs on, with 13 Sui assets routable today including six SUI liquid staking derivatives. Behaviour: the SDK is chain-agnostic at the call site but deliberately not at the response, and gas estimation is where you meet that first.

What Sui DeFi actually looks like in 2026

Sui is a layer 1 built around objects rather than accounts. Contracts are written in Move. Transactions that touch unrelated objects can execute in parallel, which is the architectural reason Sui advertises low latency under load.

That design shapes what the DeFi ecosystem on it looks like. Three categories carry most of the activity.

Spot trading sits with Sui-native automated market makers such as Cetus. Lending and borrowing runs through Sui-native money markets. The third category is the one outsiders usually miss: Sui has an unusually crowded liquid staking market. Six distinct SUI staking derivatives are routable through SODAX alone, namely afSUI, mSUI, haSUI, vSUI, yapSUI and trevinSUI. A network with six competing liquid staking tokens has a real yield market, not a placeholder one.

What the ecosystem does not have is a large population of applications that live somewhere else and reach into Sui. That is mostly a tooling artifact rather than a demand signal. Move is a different language with a different audit surface, so the default assumption has been that participating in Sui DeFi means shipping on Sui.

Three ways an app reaches Sui liquidity

There are exactly three, and they differ in cost far more than in capability.

Deploy on Sui. Write Move, audit it, run your own contracts. This gives the most control and the deepest integration with Sui-native venues. It also adds a language, a toolchain, an audit budget and a second production surface to operate. For a team whose core product is elsewhere, this is the most expensive option by a wide margin.

Move the assets across. Use Sui Bridge or Wormhole to get tokens onto Sui, then interact from there. Sui documents the canonical bridging routes in its own bridging guide. This works and it is well trodden, but note what it leaves you holding: a position on Sui, in Sui-denominated assets, which somebody on your team now has to monitor, rebalance and account for.

Route an intent from where you already are. This is what intent based DeFi means in practice. Rather than describing a route, the user or the application states the outcome it wants, and an independent solver commits its own capital to fill it. SODAX routes and settles; solvers fill. The application never holds inventory on Sui and never deploys Move code, because the fill happens on the destination network and settlement is coordinated through the hub.

The third path is also the one that matters for embedded DeFi, meaning swap or yield functionality placed inside a wallet, a game or a consumer app rather than a standalone exchange. Those teams are not optimising for basis points on a single corridor. They are optimising for how many distinct integrations their codebase has to carry, and a Sui deployment is a large fixed cost for one network's worth of liquidity.

What the DeFi SDK looks like against a Sui spoke

The honest version of "chain-agnostic" is that the call site is uniform and the response is not. Sui is a good place to see the difference, because the gas model genuinely differs from an EVM chain rather than differing cosmetically.

Note on code samples These signatures reflect the SODAX SDK as of August 2026. The SDK evolves rapidly. Always verify against the official documentation at docs.sodax.com before integrating in production.

import { ChainKeys } from '@sodax/sdk';

const intentResult = await sodax.swaps.createIntent({
  params: {
    srcChainKey: ChainKeys.SUI_MAINNET,
    // ... other intent params
  },
  raw: true,
});

if (intentResult.ok) {
  const gasResult = await sodax.swaps.estimateGas({
    tx: intentResult.value.tx,
    chainKey: ChainKeys.SUI_MAINNET,
  });

  if (gasResult.ok) {
    // Sui returns a structured estimate, not a single gas number
    const { computationCost, storageCost, storageRebate, nonRefundableStorageFee } = gasResult.value;
    console.log('Sui gas estimate:', { computationCost, storageCost, storageRebate, nonRefundableStorageFee });
  }
}

On an EVM spoke the same estimateGas call returns a single bigint of gas units. On Sui it returns four fields, because Sui prices computation and storage separately and refunds storage when objects are deleted. Sui documents that model in its gas concepts page. If your fee display logic assumes one number, Sui is where it breaks, and the type system will tell you before production does.

Two more Sui-specific details worth knowing before you start.

Wallet construction differs. The SuiWalletProvider in @sodax/wallet-sdk-core takes mnemonics rather than a private key for server-side use, and in the browser it expects a pre-constructed SuiClient, a wallet object and an active WalletAccount. That is more setup than an EVM provider needs.

Approvals mostly disappear. Across the SDK, on-chain approval is required on EVM spokes, the hub and Stellar. Every other non-EVM network, Sui included, needs no approval step at all, so the two-transaction approve-then-act pattern collapses to one call. The full per-network matrix is in the compatible assets reference, and the gas examples for each chain family are in the gas estimation guide.

SODAX, Sui Bridge and Cetus compared

These three are not substitutes, which is exactly why the comparison is useful. Each is the correct answer to a different question.

Consideration	SODAX	Sui Bridge and Wormhole	Cetus
What it is	Cross-network execution layer, intents filled by independent solvers	Asset transfer onto and off Sui	Sui-native automated market maker
Move code required	None	None	None to trade, yes to build on top
Where execution happens	Solver fills on the destination network, settlement coordinated via the Sonic hub	Assets land on Sui, you act from there	On Sui
Do you hold a Sui position	No	Yes	Yes
Beyond swaps	Money market, AMM and staking on the same rails	Transfers only	Sui spot liquidity and pools
Where it is stronger than SODAX	Not applicable	The canonical, most liquid route for moving major assets such as USDC onto Sui, and the right primitive if your product genuinely needs assets resident on Sui	Deepest on-Sui execution for Sui-native pairs, and if your users are already on Sui there is no reason to add a cross-network hop at all

Read the last row first. If your users already hold assets on Sui and trade Sui-native pairs, a Sui-native venue will beat any cross-network path, because the cross-network part is pure overhead. If your product needs assets genuinely resident on Sui, bridge them and be done. The cross-network execution layer earns its place in a narrower case: your application lives on another network, you want Sui liquidity reachable from it, and you are not willing to fund a Move deployment and a Sui treasury to get there.

Which Sui assets are routable today

Thirteen assets on Sui are available for cross-network swaps at the time of writing: SUI, bnUSD, USDC, SODA, the six liquid staking derivatives afSUI, mSUI, haSUI, vSUI, yapSUI and trevinSUI, plus DEEP, WAL and NAVX. USDT is listed as in progress rather than live, which is the kind of detail worth checking against the reference rather than assuming, since a stablecoin you assumed was routable is an unpleasant discovery late in a build.

Sui is one of 21 networks on the same rails. The hub network is Sonic. The EVM networks are Ethereum, Arbitrum, Base, BNB Chain, Optimism, Polygon, Avalanche, Hyperliquid, LightLink, Redbelly and Kaia. The non-EVM networks are Solana, Sui, Stellar, ICON, Injective, NEAR, native Bitcoin, Stacks and Hedera. Across all of them there are 29 money market assets and 28 integration partners.

This is where unified liquidity defi becomes a testable claim rather than a slogan. The test is not whether a provider lists Sui. It is whether one function call can quote from your network into a Sui asset without your code knowing that Sui exists as a special case. On the evidence of the gas response above, the answer is partly: the call is uniform, the response is typed per chain family, and you handle the difference once rather than per integration.

Asset coverage also moves, which is worth building for. NAVX support arrived recently enough to be announced separately, so treat the asset list as a live reference rather than a fixed capability. The swap interface is the fastest way to see routing behaviour into a Sui asset end to end before writing any code.

Frequently Asked Questions

Do I need to write Move code to use Sui DeFi from another network?

No. Writing Move and deploying on Sui is one of three access paths, and it is the most expensive one. If your goal is to let users reach Sui liquidity from wherever they already are, an intent-based route means the fill happens on the destination network and your application never deploys a contract on Sui. Move becomes necessary when you want to build a Sui-native protocol rather than reach Sui liquidity, which is a different project with a different budget.

Does a swap on Sui require an on-chain approval first?

No, and this is a genuine simplification over EVM. On-chain approval is required on EVM spoke chains, on the Sonic hub and on Stellar. Every other non-EVM network, including Sui, requires no approval, so the familiar approve-then-transact pattern collapses into a single call. If you are porting integration code from an EVM chain, the approval branch is dead code on Sui rather than something to adapt.

How does gas estimation on Sui differ from an EVM network?

An EVM spoke returns a single gas figure. Sui returns four values, covering computation cost, storage cost, storage rebate and a non-refundable storage fee, because Sui prices computation and storage as separate resources and refunds storage when objects are deleted. Any code that displays an estimated fee, or that compares estimates across networks, has to handle both shapes rather than assuming a scalar.

Which Sui assets can I route right now?

Thirteen, at the time of writing: SUI, bnUSD, USDC, SODA, six SUI liquid staking derivatives, and the DEEP, WAL and NAVX tokens. USDT is marked in progress rather than live. Because this list changes as assets are added, check the compatible assets reference in the developer documentation at build time rather than relying on a figure quoted in an article.

Where to take this next

The decision here is not really about Sui. It is about whether a network is worth a deployment or worth a route, and that answer changes with how many networks are on your roadmap and how much of your product depends on assets being resident.

Not sure which of the three paths above fits your architecture? The integration planner takes a description of your stack and returns a specific build path, including the modules involved and the networks it touches, rather than a general overview.

If you are evaluating this properly, do the unglamorous test. Quote a corridor into a thin Sui asset in both directions and see what comes back, then decide whether the deployment you were assuming is actually necessary.