Build, preview, and check

Turn a prepared operation into transaction calldata, assess its projected effect, and check its prerequisites. Continue here from Open, Manage, or Delayed withdrawals.

Use the already-connected sdk and supply the sender's address as owner. No wallet connection or signer is required. The result is a transaction payload; signing and execution are up to you.

Build the transaction

Choose the builder for your operation. Each snippet defines chainId and tx for the shared preview below. If an operation already produced tx, such as a quota update, skip to Preview and check with its chainId and owner.

Open a leveraged position

Use strategy, selectedStrategy, params, and the successful sim from Open. owner is the address funding and owning the new Credit Account.

const chainId = strategy.chainId;
const targetToken = params.targetToken ?? selectedStrategy.data.targetCollateral.address;
const tx = await sdk.opportunities.execute.buildTx({
  kind: "open",
  chainId,
  creditManager: strategy.creditManager,
  wallet: owner,
  collateral: params.collateral,
  ethAmount: 0n,
  targetToken,
  sim,
});

Update a leveraged position

Use the selected position and successful sim from an operation in Manage or from finalizing a delayed withdrawal. For a routed operation, pass the chosen route's result, not the two-route container. Quota updates already produced tx and do not use this builder.

const chainId = position.chainId;
const tx = await sdk.opportunities.execute.buildTx({
  kind: "account",
  chainId,
  creditAccount: position.creditAccount,
  wallet: owner,
  sim,
});

Preview and check

previewOperation() estimates the transaction's effect. checkOperation() checks the operation's prerequisites, including token approvals, balances, market limits, and the chosen HF thresholds. For an opening or reopening, it also checks applicable KYC/registration requirements. Neither call signs or broadcasts a transaction.

const preview = await sdk.preview.previewOperation({
  chainId,
  to: tx.to,
  calldata: tx.callData,
  value: BigInt(tx.value),
  sender: owner,
});
if (!preview.ok) throw preview.error;

const issues = await sdk.preview.checkOperation(
  { chainId, preview: preview.data, sender: owner },
  {
    minHealthFactor: 10_500, // Require HF >= 1.05 at main prices (basis points)
    minSafeHealthFactor: 10_500, // Require HF >= 1.05 at safe prices
  },
);

These thresholds leave a buffer above the liquidation boundary, HF 1.0. Choose the buffer for your risk policy; omitting a threshold disables that check. They are SDK validation settings, not constraints added to the calldata.

Read the preview result

preview.ok means the SDK could produce a preview; it does not mean the operation passed validation. Read preview.data.operation to identify the result's structure. It describes the decoded transaction, so do not infer it solely from the preparation method you called.

For delayed operations, inspect both nested previews. checkOperation() checks only instantPreview; it does not validate the future claim. If no intent was recorded, delayedPreview describes the claim alone. Follow Delayed withdrawals when it matures.

The fields below are on preview.data for immediate operations, or on each nested preview for a delayed operation. Compare them with the current leveraged position, if any, and the outcome you requested. For immediate operations and instantPreview, fields prefixed with est use the minimum swap outputs encoded in calldata; preparation reports expected outputs instead. delayedPreview uses oracle-based estimates for future conversions, so its amounts are not guaranteed swap minimums.

TokenAmount contains token, value (bigint base units), and valueUsd (number or null when unavailable). Format amounts using their token's decimals, except quotas and quotasChange: those use market underlying decimals even though their token metadata identifies collateral. Rates use basis points: 520 means 5.2%.

Resolve validation issues

issues is an OperationValidationError[]. An empty array means no issues were found by the applicable checks, not that a transaction was executed or successfully simulated. Each issue has a machine-readable code and an explanatory message; use code to access its details. For example, insufficientAllowance includes owner, spender, required, and allowed; insufficientCollateral includes healthFactor, healthFactorThreshold, and safePrices. Review the projected outcome even when issues is empty.

Resolve prerequisites, including the approvals described in the action guide. insufficientAllowance is a pre-transaction validation issue, not a failed transaction. Approval execution belongs to your chosen execution flow. After an approval confirms or the inputs change, repeat the action's preparation and build steps, selecting its route if applicable. For a direct quota transaction, repeat the quota update steps. Preview and check the new tx, then resolve any remaining issues.

Transaction payload

The output is tx, to hand to your chosen execution system:

Keep chainId and owner with this payload: they identify the chain and sender used for the checks. Signing and execution are up to you. If execution is delayed, prepare, build, and check again. After execution, use Monitor to read the leveraged position.

Source

• Transaction builder
• Preview result structures
• Operation checks