Setup

Ondo setup: SIWE, deposit-address provisioning, terms, trading key, and referral

Ondo setup steps are ordered by sequence. The user-facing flow is coordinated by checkSetup() and executeProviderSetupAction(); the plugin keeps the session and trading credential client-side. Ondo has no choice step and no revocable step.

Every Ondo setup step has relay: CLIENT. The SDK sends each step to the Ondo venue itself with the session credential, and nothing reaches LI.FI. If you call the API without the SDK, see Integrating without the SDK.

Sequence	Step	signer	relay	What it does
10	siweLogin	USER	CLIENT	Sign in with the wallet and establish a venue session.
20	createDepositAddress	USER	CLIENT	Provision the user’s Ethereum USDC margin-wallet destination.
30	acceptProviderTerms	USER	CLIENT	Accept the venue terms.
40	registerApiKey	USER	CLIENT	Create the client-held trading key.
50	setReferrer	SDK	CLIENT	Apply LI.FI’s referral through the session (conditional; the SDK applies it).

const provider = 'ondo';
let required = await perps.checkSetup({ provider, address: userAddress });

while (!required.isReady) {
  // Ondo has no choice step, so the first staged step is the first unsatisfied step.
  const step = required.setup[0];
  if (!step) break;
  await perps.executeProviderSetupAction({
    provider,
    address: userAddress,
    step,
    checklist: required.checklist,
  });

  // The checklist is a snapshot. Read it again after each step.
  required = await perps.checkSetup({ provider, address: userAddress });
}

checkSetup() runs SDK-signed setup such as setReferrer inline, without a wallet prompt. It returns steps that need the user in sequence order, with SIWE prioritized so later session steps can run. executeProviderSetupAction() refuses a step while a lower sequence step on the checklist is unsatisfied. The checklist does not change when a step runs, so the snippet runs one step and then calls checkSetup() again.

​

Setup descriptors

​

siweLogin

The user wallet signs the exact backend-issued ERC-4361 challenge. The resulting venue session remains client-side.

Signer	USER
Relay	CLIENT
Signing method	siwe
Sequence	10

The resulting session credential has no refresh flow — it expires client-side, or is evicted after a server-side revocation, and both cases fall back to a logged-out account state that re-stages this step. See Signing Model — The session credential’s lifecycle.

​

createDepositAddress

A client-only session step that provisions the user’s provider-managed deposit address. Its public SessionActionStep marker carries policy, not credentials or a venue request:

import { ActionType, type SessionActionStep } from '@lifi/perps-sdk';

const step: SessionActionStep = {
  action: ActionType.CREATE_DEPOSIT_ADDRESS,
  session: {
    network: 'ethereum',
    symbol: 'USDC',
    depositDestination: { wallet: 'margin' },
  },
};

Signer	USER
Relay	CLIENT
Signing method	session
Sequence	20
Params	none; the policy is fixed by the provider

getDepositFlow() returns setupRequired with siweLogin and createDepositAddress while logged out, only createDepositAddress while signed in but unprovisioned, and then lifiSwap to Ethereum USDC with the provisioned toAddress.

​

acceptProviderTerms

Records acceptance through the client-held session. No backend-bound signed step is produced.

Signer	USER
Relay	CLIENT
Signing method	session
Sequence	30

​

registerApiKey

Creates the venue trading key through the session. The credential remains client-side and later signs HMAC trading requests.

Signer	USER
Relay	CLIENT
Signing method	session
Sequence	40

The venue registers the key under the name lifi-perps with scopes ['trade', 'transfer']. The trade scope signs trading requests. The transfer scope signs the POST /v1/withdraw request for a withdrawal. The venue caps an account at 10 keys. At the cap, the SDK reclaims its own oldest lifi-perps key before it creates a new one. The SDK also re-creates the key if the venue rejects it as unauthorized.

A key that a previous SDK version created holds only the trade scope. The SDK replaces such a key when the next HMAC-signed request needs it. The SDK revokes the old key, creates a new key with both scopes, and stores the new key. The replacement uses the stored session token only. It needs no wallet signature and no action from the user. See Signing Model — The API key.

​

setReferrer

Applies LI.FI’s configured referral through the userland session token. The venue endpoint does not accept API-key authentication, so this is a session step rather than HMAC. It is omitted when no referral code is configured. checkSetup() applies it when pending, without a wallet prompt. Tell your users that a referral code is applied.

Signer	SDK
Relay	CLIENT
Signing method	session
Sequence	50