How to create or cancel orders

Tip (faster confirmations): ethers' default provider polling interval is 4000ms, so every tx.wait() the SDK does internally (in setApprovals, runApprovals, cancelOrders, redeemPositions, etc.) can take up to ~4s to notice a mined transaction. On a fast chain like BNB, lower it to ~300ms so confirmations feel near-instant:

The interval lives on the provider, so set it on whatever provider you pass in, including a BrowserProvider (e.g. MetaMask): provider.pollingInterval = 300.

Predict Account

Predict supports interacting with the protocol using either a traditional Externally Owned Account (EOA) or a Smart Wallet ("Predict Account"). If you use the web app, a Smart Wallet is automatically created for you. To interact with your Smart Wallet programmatically using the SDK, follow the example shown in How to use a Predict account.

How to set approvals

Before trading, you need to set approvals for ERC-1155 (ConditionalTokens) and ERC-20 (USDT). This can be achieved by sending a transaction to the respective contracts (see the Contracts section) and approving both the CTF_EXCHANGE and the NEG_RISK_CTF_EXCHANGE or via the SDK utils.

Contracts: The current deployed contracts can be found either in the Constants.ts file or in the Deployed Contracts documentation.

The following example demonstrates how to set the necessary approvals using the SDK utils.

How to set scoped approvals (per-operation)

setApprovals() sets every approval for every market type in a single call. For most apps the scoped-approvals API is the better fit, and is the recommended approach whenever you build an approval UI. It returns only the approvals a given operation needs, as a list of plain, self-describing steps you can render as a checklist, pre-check, run with live progress, and gate on user confirmation.

The mental model is simple: everything produces steps, and one runner runs steps.

Describe what the user is about to do with an ApprovalScope (operation, plus isNegRisk / isYieldBearing, and an optional side to narrow a TRADE).

Turn it into an ordered ApprovalStep[] with getApprovalSteps (one operation) or getAllApprovalSteps (everything). Both are pure (no signer, no network access), so you can render the checklist before the wallet is connected.

Run the steps with runApprovals, or drive them yourself with checkApprovals / setApproval.

isNegRisk and isYieldBearing describe the market and can be fetched from the GET /markets (or GET /categories) endpoint.

getApprovalSteps returns the minimal, ordered set for the operation. The labels below are the SDK's default copy (they match the Predict web app). Operations that need no approval return an empty array. |

A TRADE scope covers both order directions by default. Pass side: Side.BUY for just the collateral allowance, or side: Side.SELL for just the ERC-1155 approval. CONVERT is neg-risk only and throws InvalidApprovalOperationError for a standard market.

The `ApprovalStep` shape

Each step is plain data, safe to render and serialize:

The label/description are sensible English defaults. For custom wording or i18n, key your own copy off the stable id and ignore them.

Build the steps

You'll typically build the steps from the same signer-backed OrderBuilder you use to check and run them.

getApprovalSteps and getAllApprovalSteps don't touch the chain, so you can also call them on a signer-less builder (OrderBuilder.make(ChainId.BnbMainnet)) to render the checklist before the wallet is connected. You'll need a signer for everything after (checkApprovals, setApproval, runApprovals).

Run them with progress reporting

runApprovals(steps, opts) runs the steps in order, deduplicating by id (so you can safely pass a union of scopes or a curated subset). Options:

skipSatisfied (default true): pre-check each step on-chain and skip the ones already in place.

stopOnError (default true): stop after the first failed step.

onProgress: a callback invoked as each step transitions, receiving { step, status, transaction? }.

onProgress reports each step through this lifecycle:

Status	Meaning
`checking`	reading on-chain whether it's already approved (only when `skipSatisfied`)
`skipped`	already in place, nothing sent
`submitting`	transaction sent, awaiting confirmation
`confirmed`	the transaction succeeded
`failed`	the transaction reverted or failed

The returned report is { success, steps }, where each entry is { step, status: "skipped" | "confirmed" | "failed", transaction? } (the transaction carries the receipt for submitted steps):

Render a live checklist (the typical UI flow)

This is the flow behind an in-app "Approvals" modal: render the steps, mark the ones already done, then run the rest with live updates.

For first-time onboarding, swap getApprovalSteps(scope) for getAllApprovalSteps() to approve everything the protocol could need in one pass. That is the per-step, progress-reportable equivalent of setApprovals() (and a slight superset, since it also includes the split allowances).

Or drive each step yourself

For full control (e.g. gating each step on a user confirmation), use the per-step primitives. checkApprovals batches the on-chain reads (via multicall) so you can render the initial state in one round-trip.

Notes

Compose freely. Union step lists to cover several operations at once, e.g. to make a market both trade-ready and splittable: runApprovals([...tradeSteps, ...splitSteps]) (duplicates are removed automatically).

Predict accounts (smart wallets) are supported transparently: every step routes through Kernel.execute when a predictAccount is configured.

Signer requirements. getApprovalSteps and getAllApprovalSteps are pure and need no signer. checkApproval / checkApprovals, setApproval, and runApprovals require one and throw MissingSignerError otherwise.

setApprovals() still exists for the fire-and-forget "approve everything" case where you don't need per-step control or reporting.

How to use a Predict account

Here's an example of how to use a Predict account to create/cancel orders and set approvals.

Initiate the Privy Wallet: The wallet is needed to sign orders. Can be found in the account settings.

Ensure the Privy Wallet has funds: You will need to add some ETH to be able to set approvals and cancel orders, if needed.

Initialize OrderBuilder: Instantiate the OrderBuilder class by calling OrderBuilder.make.

NOTE: Include the predictAccount address, which is also known as the deposit address.

Set Approvals: Ensure the necessary approvals are set (refer to Set Approvals).

Determine Order Amounts: Use getLimitOrderAmounts to calculate order amounts.

Build Order: Use buildOrder to generate a LIMIT strategy order.

NOTE: Fetch the feeRateBps via the GET /markets endpoint on the REST API

NOTE: Set the signer and maker to the predictAccount address, NOT the signer/privy wallet address.

Generate Typed Data: Call buildTypedData to generate typed data for the order.

Sign Order: Obtain a SignedOrder object by calling signTypedDataOrder.

Compute Order Hash: Compute the order hash using buildTypedDataHash.

This will allow you to perform operations via your Predict Account (via the smart wallet).

How to create a LIMIT order (recommended)

Here's an example of how to use the OrderBuilder to create and sign a LIMIT strategy buy order:

Create Wallet: The wallet is needed to sign orders.