Setup

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

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

1. siweLogin — sign in with the wallet and establish a venue session.
2. createDepositAddress — provision the user’s Ethereum USDC margin-wallet destination.
3. acceptProviderTerms — accept the venue terms.
4. registerApiKey — create the client-held trading key.
5. setReferrer — apply LI.FI’s referral through the session (conditional and SDK-only).

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

for (const step of required.setup) {
  await perps.executeProviderSetupAction({
    provider: 'ondo',
    address: userAddress,
    step,
  });
}

checkSetup() completes SDK-only internal setup such as setReferrer inline. It returns actions that need the user in sequence order, with SIWE prioritized so later session steps can run.

Setup descriptors

siweLogin

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

Signer	USER
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:

{
  action: ActionType.CREATE_DEPOSIT_ADDRESS,
  session: {
    network: 'ethereum',
    symbol: 'USDC',
    depositDestination: { wallet: 'margin' },
  },
}

Signer	USER
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
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
Signing method	session
Sequence	40

The venue registers the key under the name lifi-perps with scopes ['trade'] and caps an account at 10 keys — the SDK reclaims its own oldest lifi-perps key before creating a new one at the cap, and re-creates the key automatically if the venue ever rejects it as unauthorized. 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 and executed internally by checkSetup() when pending.

Signer	SDK
Signing method	session
Sequence	50