Strategies

Strategies

Account strategies combine borrowing, withdrawal, swaps, repayment, and supply in one transaction. They let an account change exposure before its final collateral and debt are checked together. A failed route, receipt check, listing rule, or final risk check rolls back the transaction.

Start with Managing Positions and Health Factor and Collateral before using these flows. A cash loan that must be repaid within the callback is covered separately in Flash Loans.

Choose a flow

Flow	Use it to	Debt-opening fee
Multiply	Borrow and convert proceeds into collateral to open or increase leverage	Market flash-loan fee on new principal
Swap debt	Borrow a new debt asset, convert it into the existing debt asset, and repay	Market flash-loan fee on new principal
Swap collateral	Withdraw collateral, convert it, and supply the replacement	No new debt is opened
Repay with collateral	Use supplied collateral to reduce debt, optionally closing the account	No new debt is opened
Blend migration	Replace selected debt from an approved Blend pool and move its selected supplied assets	No origination fee
Flash position	Open debt, call a receiver, and supply its returned collateral	No origination fee

Position legs identify a hub market by hub ID and token address. Blend migration pairs its token-address lists with one selected hub ID; flash-position refund lists contain token addresses. Two markets can hold the same token under different hubs.

Every flow requires caller authorization and the applicable account-owner or delegate authority. A new account is created only on flows that support it; an existing account keeps its spoke. Global pause blocks these strategy entry points. Each leg retains its relevant listing flags, position limits, caps, and pool checks.

Open or increase leverage

Multiply opens or extends a Multiply, Long, or Short account. It draws the requested debt principal, withholds the market fee, converts the proceeds into collateral, and supplies the result.

Optional initial capital joins the flow according to its token:

• Collateral-token payment joins the eventual collateral deposit.
• Debt-token payment joins the main conversion input.
• Another token requires a separate conversion route into collateral.

Receipts are measured before being used. Multiply requires different collateral and debt markets; Long and Short also require different underlying tokens. The same token across different hubs can pass through without a router swap where the mode permits it.

The new debt includes the full borrowed principal even though the available proceeds are principal less the fee. Cash, liquidation-buffer, utilization, and debt-cap checks apply to the full debt opening. Multiply uses the configured router and does not require the market's cash-flash-loan enable flag.

Change debt or collateral

Swap debt takes the amount of new debt to open. Its converted proceeds repay the chosen existing debt. This can leave both old and new debt outstanding if the output is insufficient to close the old leg. Repayment excess is refunded from this operation's funds.

The new debt opens before the old debt is repaid. A refinance can therefore fail a cap or liquidity check even when the intended final exposure would fit.

Swap collateral withdraws the requested existing collateral, measures the receipt, converts it, and supplies the replacement. The destination must be eligible for supply before the withdrawal starts. Remaining old collateral and newly supplied collateral are evaluated together at finalization.

When only the hub changes and the underlying token stays the same, these flows require empty swap bytes and pass the tokens through without routing.

Repay debt with collateral

For the exact same hub market, the protocol offsets supplied value against debt with no token transfer. Swap bytes must be empty. Settlement is limited by the request, conservative supply value, and debt owed; rounding can leave a small remainder.

For different markets, collateral is withdrawn and converted into the debt token, then the pool's measured receipt funds repayment. Matching underlying tokens across hubs pass through with an empty route.

The optional close flag requires all account debt to be cleared before remaining collateral is withdrawn to the caller. A shortfall on any debt leg fails the entire close. Ordinary partial repayment can leave a position open, subject to final risk checks.

Router boundary and slippage

Swap routes arrive as opaque bytes built off-chain. The configured swap aggregator validates the route encoding and token indices, executes venues, and applies its payload's slippage and fee rules. The lending controller selects the input and output tokens and binds the call to its own committed input amount.

At the router boundary, the controller:

1. Snapshots its input and output token balances.
2. Authorizes one exact input-token transfer to the configured router and calls it inside the flash guard.
3. Rejects an increase in its input balance or spending above the committed input.
4. Refunds this swap's unused input to the caller.
5. Requires a positive measured increase in the selected output token.

The controller credits observed output; a router-reported amount does not establish settlement. Input increases or overspend reject with RouterOverspend; no positive output rejects with NoSwapOutput.

The controller does not independently enforce the route's minimum output. The aggregator checks its minimum after router fees and before the output payout; final lending health is a separate constraint. A route can leave an account healthy while executing at an unattractive price. Configure the route's minimum output accordingly, and account for the tokens' actual transfer behavior.

The swap aggregator contract is a separate contract and authority boundary. Measured settlement limits the amounts lending accepts; it does not make every router, venue, or token trustworthy.

Migrate from Blend

Migration targets a governance-approved Blend pool and identifies selected collateral assets, ordinary supply assets, and maximum amounts for each debt asset. The request must be nonempty, debt assets must be unique, and every debt cap must be positive.

The controller opens the capped XOXNO debt amounts without an origination fee, uses them to repay Blend debt, and applies remaining funds from that operation to reduce the new XOXNO debt. It then withdraws the selected Blend collateral and supply balances and deposits only measured receipts as XOXNO supply. Existing controller balances are not used as migration refunds or collateral.

Both kinds of withdrawn Blend balance become supply in the selected XOXNO hub. Destination listings and final account risk still apply. A new migration account uses Normal mode; an existing destination retains its account rules. Blend calls require the caller's appropriate authorization.

The debt caps bound temporary funding, not a promise of the final debt amount or migration success. Inadequate caps, unavailable liquidity, failed external calls, or insufficient resulting collateral revert the transaction.

Open a flash position

A flash position creates fee-free debt and forwards tokens to a caller-selected Wasm receiver. The receiver returns collateral to the controller during its callback. Success must leave supply and positive debt in the declared debt market open, with the account passing final risk checks.

This flow supports Multiply, Long, and Short modes. The receiver cannot be the controller or pool, and the debt market must have flash loans enabled.

Collateral declarations must be nonempty, fit the configured supply-position limit, and use unique underlying tokens even across different hubs. Every minimum receipt must be nonnegative and at least one must be positive. Each measured controller receipt must meet its declared minimum; deposit into the pool measures delivery again and applies supply caps and position rules.

The callback ABI is:

execute_flash_position(
    initiator: Address,
    account_id: u64,
    asset: Address,
    amount: i128,
    fee: i128,
    amount_received: i128,
    controller: Address,
    data: Bytes,
)

The fee argument is zero. amount is the principal recorded as debt; amount_received is what the receiver actually received. Callback logic must distinguish them if transfer behavior causes a difference.

Optional refund tokens must be unique, listed in the debt hub and account spoke, disjoint from collateral declarations, and within the configured list limit. Only positive balance changes above the callback baseline return to the caller. Refunding debt tokens does not repay the newly opened debt.

Undeclared callback tokens receive neither collateral credit nor refunds. The controller has no sweep endpoint for them. Receivers must return intended collateral in the declared tokens and send other proceeds through the explicit refund list.

Pricing and final risk

Account strategies fetch their portfolio and required flow prices before funding or external callbacks. They can therefore fail during an oracle outage even when a proposed flow would end debt-free. Callback output is evaluated using the operation's fetched prices.

After the position changes, finalization refreshes applicable collateral LTV values and enforces debt within LTV capacity, health factor at least 1, and the minimum collateral floor when debt remains. A flash position additionally requires its supply and declared debt to survive finalization.

These account checks do not replace market cash, listing, cap, or router checks. See Oracle System, Central Pool, and the endpoint reference for their exact boundaries.

Vault supply through DeFindex is an independent integration described in Vault Integration.