Skip to main content
The SDK normalizes the calls, not the venues. An order placed through the same method can be rejected on one venue and accepted on another, because the constraints underneath are the venue’s own. This page covers the differences that reach your interface.

​
At a glance

​
Hyperliquid

An order-book perpetuals exchange on its own chain. The user approves an agent once, and the SDK signs trades with it after that, so there is no wallet popup per order. Cross margin is the default when you do not specify one. Some markets are isolated-only, and the market data says which, so check that before you render a margin-mode toggle rather than after a user has used it. Order type and price are required on every order.
Withdrawals and asset transfers are signed by the user’s own wallet every time. The agent cannot move funds, which is deliberate and is what makes an SDK-held credential an acceptable thing to have.
Funding an account means getting collateral onto the venue, which is a cross-chain movement like any other and can be done through LI.FI’s own routing. Withdrawals return to the chain the venue settles on.

​
Lighter

Lighter is exposed as two separate deployments behind one normalized contract: the mainnet deployment, and a deployment on Robinhood Chain. They differ in settlement chain, collateral asset, and endpoints.
The two keep separate endpoints, caches, credentials, and asset registries. A user set up on one is not set up on the other, and they are registered as two providers on the client rather than one with a flag.
Signing is owned entirely by the plugin. It generates the key, persists it, registers it on-chain, and signs with it. Your application does not construct a signer or hand one in.

​
Ondo

A session-backed venue. The user signs in once, and the SDK then holds a session credential and a venue key on the client. Trading requests are signed with that key before being relayed. Its constraints are the tightest of the three and are worth reading before you design an order ticket against it:
  • Cross margin only. Passing isolated is rejected rather than coerced.
  • Limit and market orders only. A limit order needs a price, and both price and size are validated against the market’s grid.
  • Time in force covers good-til-cancelled, immediate-or-cancel, and post-only.
  • Order expiry is not supported at all, so an expiry field has to be left off.
  • Take-profit and stop-loss legs execute at market. A limit price on a trigger is rejected.
  • Maximum leverage is 10x on most markets and 20x on index, commodity, and equity markets.
Deposits work differently too: the venue provisions a per-user margin-wallet address behind the session, and you route funds to the address it returns rather than to a shared contract.

​
Choosing what to support

Supporting a second venue costs one more package and one more setup flow, not a second integration. What it does cost is interface work, because the constraints above are not the same and a single order form that assumes the loosest venue will produce rejections on the strictest. The cheapest version is to read the venue’s own capability data at runtime and render from it, rather than encoding the table above into your interface where it will drift.

​
Next steps

Concepts

Why the credential differs per venue, and who signs what.

Quickstart

Registering a provider and running setup.

Per-venue reference

Setup, trading, deposits, withdrawals, and streaming for each venue.

Funding a perps account

Moving collateral onto a venue with LI.FI routing.