Blend migration

migrate_from_blend moves selected parts of a Blend V2 position into XOXNO in one transaction. It repays selected Blend debt, withdraws selected collateral and supply, and supplies the received assets as XOXNO collateral. Any failed step reverts both protocols’ changes.

Prepare the migration

The caller owns the Blend position and authorizes its migration. The XOXNO protocol must be unpaused, and the Blend pool must be governance-approved; check is_blend_pool_approved(blend_pool) before building the call. Pass account_id = 0 to create a XOXNO account on spoke_id. For an existing account, the caller must be its owner or active delegate and the stored spoke must match. Existing XOXNO positions remain part of the resulting account. Check that each asset is eligible on the selected XOXNO hub and spoke. Selected Blend non-collateral supply also becomes XOXNO collateral. Final account valuation requires valid prices. While debt remains, the account must pass LTV coverage, health factor, and the configured USD collateral floor. Each collateral position with fewer than three decimals must also retain at least two base units after floor conversion.

Select assets and debt caps

migrate_from_blend(
    caller: Address,
    account_id: u64,
    spoke_id: u32,
    hub_id: u32,
    blend_pool: Address,
    collateral_assets: Vec<Address>,
    supply_assets: Vec<Address>,
    debt_caps: Vec<(Address, i128)>,
) -> u64

Input	Behavior
`collateral_assets`	Selected Blend collateral tokens, withdrawn in full with `WithdrawCollateral`.
`supply_assets`	Selected Blend non-collateral supply tokens, withdrawn in full with `Withdraw`.
`debt_caps`	`(token, positive cap)` in token-native units. The controller borrows each full cap from XOXNO to fund Blend repayment.

At least one of these lists must be nonempty. A debt asset cannot repeat in debt_caps. The same token can appear in a withdrawal list and in debt_caps, including a looped Blend position with collateral and debt in one token. For a full migration, size each cap slightly above that token’s accrued Blend debt. The margin covers interest before execution. Blend returns unused funds; the controller measures that refund and repays it into XOXNO. This reduces the new debt, subject to share rounding. Existing XOXNO debt remains.

Each full cap must fit XOXNO pool cash, utilization limits, borrow-position limits, and spoke borrow-cap headroom before refunds are reconciled. An oversized cap can fail even when final debt would fit. An undersized cap can leave Blend debt behind; requested withdrawals succeed only if Blend health checks permit them. The controller does not require all Blend debt to be cleared.

Understand transaction settlement

Migration borrows strategy debt at zero fee. The debt remains on the XOXNO account after measured refunds are repaid; no receiver contract or swap route is required. When both repayment and withdrawals are selected, the controller makes two Blend submissions within the same transaction:

Repay debt and measure unused-fund refunds.
Take a separate balance snapshot, then withdraw collateral and supply.

Separate snapshots distinguish refunds from withdrawn collateral, including when both use the same token. Selected withdrawals use Blend’s full-withdrawal amount (i128::MAX). The controller supplies measured withdrawal receipts and checks the resulting XOXNO account.

Build and authorize the call

stellar contract invoke --id <controller> --network <network> \
  --source-account caller \
  -- migrate_from_blend \
  --caller <G_WALLET_PUBLIC_KEY> \
  --account-id 0 \
  --spoke-id 1 \
  --hub-id 1 \
  --blend-pool <approved_blend_pool> \
  --collateral-assets '["<XLM>"]' \
  --supply-assets '[]' \
  --debt-caps '[["<USDC>", "1000000000"]]'

The CLI alias caller must resolve to the G… wallet passed as --caller. CLI invocation can submit the transaction. For a wallet application, this complete function returns prepared, unsigned XDR with the published @xoxno/sdk-js 1.0.228 builder:

import { rpc } from "@stellar/stellar-sdk";
import {
  assertStellarPreparedTxAuth,
  buildStellarMigrateFromBlendTx,
  getStellarDeployment,
  parseStellarTokenAmount,
  prepareStellarBuiltTx,
  type StellarNetwork,
} from "@xoxno/sdk-js/stellar-lending";

export async function prepareBlendMigration(input: {
  network: StellarNetwork;
  caller: string;
  accountId: string;
  spokeId: number;
  hubId: number;
  blendPool: string;
  collateralTokens: readonly string[];
  supplyTokens: readonly string[];
  debtCaps: readonly {
    token: string; amount: string; decimals: number | null;
  }[];
}): Promise<string> {
  const deployment = getStellarDeployment(input.network);
  const server = new rpc.Server(deployment.sorobanRpcUrl);
  const rpcNetwork = await server.getNetwork();
  if (rpcNetwork.passphrase !== deployment.passphrase) {
    throw new Error("RPC network mismatch");
  }
  const account = await server.getAccount(input.caller);
  const built = buildStellarMigrateFromBlendTx({
    network: input.network,
    caller: input.caller,
    sourceSequence: account.sequenceNumber(),
    controllerAddress: deployment.lendingController,
  }, {
    accountId: input.accountId,
    spokeId: input.spokeId,
    hubId: input.hubId,
    blendPool: input.blendPool,
    collateralTokens: input.collateralTokens,
    supplyTokens: input.supplyTokens,
    debtCaps: input.debtCaps.map(({ token, amount, decimals }) => ({
      token, cap: parseStellarTokenAmount(amount, decimals),
    })),
  });
  const prepared = await prepareStellarBuiltTx(server, built, {
    network: input.network,
    invokedContractId: deployment.lendingController,
  });
  assertStellarPreparedTxAuth(prepared, {
    network: input.network, caller: input.caller, builtXdr: built.xdr,
    deployment,
  });
  return prepared;
}

The caller authorizes migrate_from_blend and each Blend submit(from=caller) in the transaction’s authorization tree. The controller authorizes its own token transfers to the Blend pool. Blend calls run under FlashLoanOngoing. Guarded financial controller operations reject reentry with #400 FlashLoanOngoing. See the security model.

Simulate and verify

Read accrued Blend debt, the target account’s existing positions, and XOXNO borrowing headroom before simulating the entire transaction. Check the prepared authorization tree against your locally built invocation, then sign its required authorizations. Follow Wallet integration to persist the original network, signed XDR, and hash before submission. An unknown submission outcome requires a lookup of that hash on the same network; do not repeat or replace the migration automatically. Persist the returned XOXNO account id. Check its collateral and debt balances and health factor, then read the Blend position to confirm that the selected assets moved and any intended liabilities are cleared. The controller emits BlendMigrationEvent at ["strategy", "blend_migration"] with account_id, blend_pool, collateral_count, supply_count, and debt_count. Use position and pool-market events plus balance reads to reconcile actual amounts; the migration event contains counts.

Common errors

Condition	Error
All three of `collateral_assets`, `supply_assets`, and `debt_caps` are empty	`#16 InvalidPayments`
Unapproved `blend_pool`	`#42 BlendPoolNotApproved`
Duplicate debt asset in `debt_caps`	`#7 AssetsAreTheSame`
Partial repayment leaves a requested Blend withdrawal unhealthy	Blend health check reverts; everything rolls back
Full cap exceeds cash, utilization, or spoke borrow-cap headroom	`#112 InsufficientLiquidity`, `#127 UtilizationAboveMax`, or `#312 SpokeBorrowCapReached`
End state fails health or LTV	`#100 InsufficientCollateral` at finalize
Collateral fails the USD floor or the low-decimal two-base-unit floor while debt remains	`#126 MinBorrowCollateralNotMet` at finalize
Caller does not own or is not delegated on the target account	`#44 NotAuthorized`
Target account is on a different spoke	`#310 SpokeMismatch`
A flash loan is in flight	`#400 FlashLoanOngoing`

See governance operations for Blend-pool approval and Strategies for adjusting the resulting XOXNO position.

Start here

Core concepts

Lending actions

Strategies and integrations

System behavior

Reference

Operations

Prepare the migration

Select assets and debt caps

Understand transaction settlement

Build and authorize the call

Simulate and verify

Common errors

​Prepare the migration

​Select assets and debt caps

​Understand transaction settlement

​Build and authorize the call

​Simulate and verify

​Common errors

Prepare the migration

Select assets and debt caps

Understand transaction settlement

Build and authorize the call

Simulate and verify

Common errors