Cetusprotocol
Cetusprotocol suits swaps, automated orders, and vaults when their conditions match your liquidity needs
Cetusprotocol is a strong fit for exchanging supported tokens on Sui when a live quote meets your price and execution requirements. Limit orders suit a target price with flexible timing; DCA suits repeated purchases with fixed scheduled inputs. Direct liquidity positions require range management, while vaults automate reinvestment and rebalancing. These uses become conditional when liquidity, service availability, or redemption timing conflicts with the outcome you need. A need for guaranteed execution or protected principal makes these mechanisms a poor fit.
Bottom line: Vaults automate liquidity upkeep, while limit orders and DCA serve purchase plans whose execution depends on liquidity and service availability.
Should you use a swap, a limit order, or DCA?
Use a swap for a live exchange, a limit order for a chosen price, and DCA for repeated purchases. A swap seeks execution against available liquidity. A limit order holds a price condition open, while dollar-cost averaging, or DCA, records a recurring purchase plan.
A price target can remain unmet, and a schedule can encounter unavailable services. Execution needs available liquidity under either instruction. If completing an exchange promptly matters more than keeping the original target, a live swap quote answers a different requirement.
A live quote fits an immediate token exchange
An immediate exchange fits when the available route, input amount, and quoted output satisfy the trade you're trying to make. The Super Aggregator searches supported Sui liquidity sources, so a swap can use more than the protocol's own pools. The quoted amount describes a proposed exchange, not tokens already received in a wallet.
Routing responds to the selected token types and available liquidity. A thin market can produce a poor quote even when the interface offers the pair.
The cost comparison includes network gas and fees that apply to the selected route or product. Slippage protection limits deterioration relative to a quote; it doesn't eliminate transaction charges.
There's no promise that the aggregator beats every other available route. Another supported venue remains relevant when its executable terms better match the same exchange.
A price target makes limit orders a conditional fit
A limit order is a conditional fit when price matters more than completing the full exchange at a fixed time.
Price direction and expiry
The selected pair fixes what you'll sell and buy. The amount and price set the intended exchange. The price direction determines which token's units express the other's price. Expiry sets how long the order stays eligible for execution; it isn't a completion promise.
The documented web workflow uses a 7-day default expiry and allows customization up to 1 month. Contract-level integration specifies an expiry timestamp. The order's recorded expiry determines its actual execution window. At expiry, the documented web workflow automatically cancels any unfinished order and returns its unfilled input.
Partial fills and changing requirements
Execution also depends on order size and available liquidity at the target price. An open order can fill in portions, leaving a completed purchase alongside an unfilled commitment. The order's filled percentage reveals progress; placement alone doesn't establish completion.
Keeping the order open makes sense while its target and expiry still match the plan. If the requirement changes to an immediate exchange, a fresh swap quote offers a different path. Cancelling returns the remaining input and any purchased amount that hasn't already been claimed.
Scheduled inputs make DCA a different commitment
Fixed input amounts at fixed intervals make DCA suitable for spreading token purchases over time. Cycle frequency describes the intended spacing in seconds; cycle count describes the scheduled number of executions. Multiplying input per cycle by cycle count describes the planned trading allocation. It doesn't establish total purchased output or account for separately applicable charges.
The purchased token quantity can change across cycles as the exchange price changes. The order also specifies per-cycle output bounds and a fee rate. Order creation requires a signature from the quote service before the contract accepts its parameters. Maintaining a recurring purchase instruction fits a different task from deciding afresh before each manual swap.
Direct liquidity requires a range-management decision
A direct concentrated liquidity market maker, or CLMM, position fits a plan to supply trading liquidity within a chosen price range. The position's lower and upper boundaries determine where its assets support swaps. It earns swap fees only while it's active in range. An out-of-range position becomes single-sided as its token composition changes.
That responsibility continues after entry. A range that matched the earlier market can become inactive later, so fee generation differs from simply holding both tokens. The position NFT identifies the specific position and its collection rights. Direct management suits a deliberate choice about those boundaries. Keeping assets outside a liquidity position is the alternative when accepting that exposure or monitoring the range doesn't fit the task.
When does a vault reduce manual liquidity work?
A vault reduces manual upkeep when you want managed liquidity that reinvests fees and rewards and rebalances positions when necessary.
Reinvestment and position management
Deposited assets supply liquidity through positions that the vault holds. Its management process collects earnings, converts rewards into the relevant vault tokens, and reinvests them. Rebalancing can change the positions used. Automation concerns liquidity management; it doesn't turn a deposit into a fixed return or a simple token purchase.
Share accounting and exposure
Vault LP tokens represent the depositor's share of liquidity within the vault. LP means liquidity provider. Share accounting relates those tokens to total vault liquidity, whose value and token mix can change as positions operate. An LP-token balance therefore isn't a fixed cash balance. Choosing a vault delegates parts of position management while retaining exposure to the underlying assets and contracts. A direct position fits when choosing the range yourself matters.
DLMM liquidity, staking, and token launches serve different aims
DLMM fee behavior
The dynamic liquidity market maker, or DLMM, suits liquidity provision that uses discrete price bins and a market-responsive fee. Its swap fee combines a base component with a variable component that responds to volatility and trading conditions. A fixed price inside one bin doesn't fix the entire trade price when the trade crosses bins. This provides a different liquidity model from CLMM, without establishing superior returns.
xCETUS redemption timing
Converting CETUS 1:1 to non-transferable xCETUS fits staking participation when the redemption commitment matches the holding horizon. Redemption offers vesting from 15 to 180 days; the 180-day option returns CETUS at a 1:1 ratio. The 15-day option returns 0.5 CETUS per xCETUS. Redeemed CETUS becomes claimable only after vesting ends, and redemptions below 1:1 forfeit the remaining CETUS when completed. An immediate spending need favors retaining transferable CETUS. Reward amounts depend on protocol trading activity, so staking participation doesn't establish a fixed income.
Token launches
Cetus Launchpad concerns introducing new tokens and projects into the Sui ecosystem. That function fits a token-launch task, while a swap addresses exchange between supported assets. The available launch and its participation terms determine whether that function matches the intended use.
Sui access and integration requirements come first
The main trading interface focuses on Sui, and Cetus also has a separate Aptos version. Network choice comes before comparing an order or liquidity product; a Sui feature doesn't establish identical support on Aptos. Software development kits, or SDKs, and contract interfaces fit applications that need protocol liquidity or automated orders. An integration carries responsibility for version changes and production validation. The web interface fits an individual exchange or position decision when maintaining an integration serves no additional purpose.
Where does automation become a poor fit?
Automation is a poor fit when the task requires guaranteed completion, protected principal, or price information that cannot tolerate service delays. Routing, quotes, and automated orders can depend on off-chain systems alongside blockchain contracts. Congestion, infrastructure failure, or unavailable quotes can disrupt the requested action. A recurring schedule isn't a promise that every cycle executes on time.
Contract exposure remains material for liquidity deposits. The 2025 CLMM exploit drained pool assets through a dependent library vulnerability. The June 7, 2025 recovery plan included patched code and pool refills. Vault deposits retain contract exposure after code fixes and audits. Holding tokens outside these liquidity contracts avoids their position-management commitment, although the tokens retain their own market and custody risks.
Choose the commitment that matches the intended outcome
An acceptable live route makes a swap a strong fit for an immediate exchange. Orders and managed positions remain conditional choices because their commitments continue after placement or deposit.
- Confirm the network and product before comparing the trade. Sui and Aptos have separate interfaces, and feature parity isn't automatic.
- Choose a swap when its executable route fits the exchange, or a limit order when waiting for a target price and accepting partial fills suits the plan.
- Choose DCA when fixed scheduled inputs match the intended purchases. Manual swaps fit when each purchase needs a new timing decision.
- Choose a direct position for control over its range, or a vault for delegated reinvestment and rebalancing, while accepting the underlying liquidity exposure.
- Keep assets outside the relevant position or order when its commitment conflicts with required availability. Neither choice supplies protected principal or guaranteed settlement.
A swap settles an exchange without creating a liquidity position. Direct positions and vaults fit the separate task of supplying assets for ongoing trading.
Cetusprotocol - common questions
-
Can Cetusprotocol quote a swap for a fixed output amount?
- The Aggregator SDK supports fixed-output quotes when byAmountIn is false. In that mode, amount specifies the desired output quantity, and the returned route reports the required input quantity. Setting byAmountIn to true instead fixes the input amount. The quote describes routing terms and doesn't establish completion of a swap.
-
How can an integration limit the liquidity sources used for a swap quote?
- An integration can pass a providers list to the Aggregator SDK to restrict the sources searched. Omitting that list lets the service consider the providers that the installed SDK version supports. A restricted list changes the search universe, so a quote from it doesn't demonstrate the best available price across every supported provider.
-
What does an undefined price deviation mean when deciding whether to swap?
- An undefined deviationRatio means the aggregator has no reference market price for that comparison. It isn't a zero-deviation reading. The route can describe a proposed exchange while the market-price comparison remains unavailable. A decision that requires that comparison lacks a usable input until an applicable reference price exists.
-
Why haven't purchased tokens from a partially filled limit order reached the wallet?
- Purchased tokens from a partially filled limit order can remain in the on-chain order until the owner claims them. The limit-order interface supports manually claiming that completed portion before the entire order finishes. Full completion sends the purchased amount to the wallet automatically. The unfilled input and purchased output are different balances.
-
Will a DCA order keep unused input after cancellation?
- Cancelling a DCA order returns its remaining purchased output and unspent input to the user. Those amounts retain their respective token types, so they don't form one interchangeable balance. The contract interface also supports withdrawing already executed output. Cancellation ends the existing purchase instruction; it doesn't reverse exchanges that have already occurred.
-
When is the full-input SDK swap method suitable?
- In Aggregator SDK v3, routerSwap fits a composable transaction that intentionally uses the entire inputCoin supplied by the caller. The method consumes that coin's full amount even when the earlier quote's amountIn is smaller. Using routerSwapWithMaxAmountIn adds a maxAmountIn cap to the input amount; the transaction aborts if its on-chain validation fails. This rule concerns the supplied coin object, not every asset or balance in the wallet.
-
Does holding CETUS qualify for every activity-based reward?
- Holding CETUS alone doesn't qualify someone for incentives tied to actual protocol usage or contribution. Those incentives depend on participation conditions, which can include liquidity-related activity. xCETUS staking is a separate mechanism with conversion and redemption rules.