Skip to content
PredictefyPredictefy Docs
Get an API key

Accounts & funding

Copy page

Account and funding support is capability-qualified per venue and per resource. The capability response distinguishes what a venue exposes from what Predictefy currently serves; an unavailable resource is returned as unavailable or rejected explicitly, never filled with invented data.

client.account and client.accounts

Section titled “client.account and client.accounts”

The two similarly named SDK surfaces have different jobs:

  • client.account is the unified Account Intelligence facade. Public resources use the hosted API. Supported owner resources route locally through the matching direct client. Local calls require the exact accountId: 'owner' sentinel because credentials select the account; arbitrary account labels are rejected.
  • client.accounts is the existing collection of direct venue clients. It remains the lower-level surface for venue-specific account reads and trading. This includes the venue-direct SX Bet trading integration at client.accounts.sxbet; it is separate from hosted execution.

The credential boundary is per resource. Kalshi RSA credentials, Smarkets login/session data, Polymarket CLOB L2 credentials for open orders, and the Opinion caller key for open orders stay in your process and go directly to the venue. Polymarket’s public address is different: the hosted API receives it as the account id for public balances, positions, and fills. Only Polymarket’s owner-authenticated open-order flow keeps its credentials and order data local.

SX Bet trading has two hard venue preconditions. The trading wallet must have a registered sx.bet account; a key-only wallet is rejected with INSUFFICIENT_KYC. Betting must also be enabled once per token per network through TokenTransferProxy approval or one manual bet in the sx.bet UI. Signing and credentials stay in the caller’s process.

import Predictefy from '@predictefy/sdk';


const client = new Predictefy({
  apiKey: process.env.PREDICTEFY_API_KEY,
  venueCredentials: {
    kalshi: {
      apiKeyId: process.env.KALSHI_API_KEY_ID!,
      privateKeyPem: process.env.KALSHI_PRIVATE_KEY!,
    },
  },
});


// Routes directly to Kalshi because owner credentials are configured locally.
const balance = await client.account.fetchBalances({
  venue: 'kalshi',
  accountId: 'owner',
});

Local owner resources:

Venue Served locally through client.account Important boundary
Kalshi balances, positions, open orders, fills All four resources use caller-held RSA credentials.
Smarkets balances, open orders, fills Positions are not implemented because the venue has no position resource.
Polymarket open orders Balances, positions, and fills use hosted public routes; CLOB L2 credentials stay local for open orders.
Opinion open orders SDK-local /order uses the caller key; hosted positions and fills use Predictefy’s venue key for public wallet reads.
Gemini positions, open orders, fills Balance is unsupported because the Prediction Markets specification exposes no balance endpoint.
Limitless positions, fills Open orders remain per-market on client.accounts.limitless.fetchOpenOrders(slug); balance unsupported.
Predict.fun open orders The caller key and EOA-signed JWT stay local; positions use the hosted public route.

Unsupported owner resources return NotSupportedError instead of falling through to a hosted owner route. Predict.fun and other direct clients send credentials only to the venue’s own origin.

Hosted account surface

Section titled “Hosted account surface”

These read-scoped, live-metered routes are available:

GET /v1/accounts/{venue}/capabilities
GET /v1/accounts/{venue}/{accountId}
GET /v1/accounts/{venue}/{accountId}/balances
GET /v1/accounts/{venue}/{accountId}/positions
GET /v1/accounts/{venue}/{accountId}/open-orders
GET /v1/accounts/{venue}/{accountId}/fills

The combined snapshot always has separate envelopes for balances, positions, open orders, and fills. One upstream failure does not make another resource look successful; each envelope reports available, owner_auth_required, not_supported, or temporarily_unavailable with its own data time and provenance. Balances are explicitly non-paginated: limit bounds the returned rows, totalCount reports the complete pre-slice count, and supplying cursor returns 400 VALIDATION_ERROR.

The hosted account surface covers exactly 24 venue/resource combinations across 8 of the 17 venues. The phase-1 venues (pascal, xo, pred) declare every account resource not_supported. PredictStreet declares its four account resources owner_auth_required and unserved because its portfolio and order endpoints need the caller’s API key. Both are known-venue answers, not an unknown venue:

Venue Hosted resources Important boundary
Hyperliquid balances, positions, open orders, fills Query the master address; agent-wallet open-order queries return empty.
Polymarket balances, positions, fills Balance is positions value, not spendable CLOB cash; open orders use SDK-local L2 owner auth.
Limitless balances, positions Balance is the caller wallet’s Base USDC; owner-auth locked balances stay SDK-local.
Myriad balances, positions, fills Balance is the caller wallet’s BSC USDT; open orders have no per-address list.
SX Bet balances, positions, open orders, fills Balance is wallet SX Network USDC and positions are publicly derived. The separate trading integration remains client-side only.
Opinion balances, positions, fills Balance is the caller wallet’s BSC USDT; the server uses its venue key for wallet reads, while own orders use SDK-local caller auth.
Predict.fun positions Server-keyed positions-by-address is public; account orders remain local owner-auth.
Rain balances, positions, open orders, fills Public or derived Arbitrum evidence is served with explicit chain/derived provenance.
Kalshi none hosted; four local owner resources RSA owner credentials stay in the caller process.
Smarkets none hosted; three local owner resources Full login/session stays local; positions are not implemented.
Polymarket US, Gemini, PredictStreet none Resources are owner-required or not supported as documented for each venue. 
// Hosted examples use the live, capability-qualified account surface.
const capabilities = await client.account.fetchCapabilities({ venue: 'rain' });
const snapshot = await client.account.fetchSnapshot({
  venue: 'rain',
  accountId: '0x...',
});
const positions = await client.account.fetchPositions({
  venue: 'rain',
  accountId: '0x...',
  limit: 50,
});

Unknown venues return 404 VENUE_NOT_AVAILABLE. A dedicated request for a known but unserved resource returns 400 ACCOUNTS_UNSUPPORTED. Use the capabilities response before requesting a dedicated list.

Funding and bridge helpers

Section titled “Funding and bridge helpers”

The adjacent client.funding surface combines hosted requirements and provider-dispatched bridge reads with local, unsigned builders:

// Hosted methods dispatch to each venue's evidence-pinned funding provider.
await client.funding.getRequirements({ venue: 'limitless' });
const quote = await client.funding.getBridgeQuote({
  fromChain: 1,
  fromToken: '0x...',
  fromAmount: '1000000',
  fromAddress: '0x...',
  toVenue: 'limitless',
});


// Review quote.transactionRequest, then sign it in the caller's wallet.

The hosted proxy supports GET /v1/funding/{venue}/requirements, POST /v1/funding/{venue}/steps, GET /v1/funding/transfer-plan, GET /v1/bridge/quote, and GET /v1/bridge/status. The transfer plan composes those same caller-signed legs into one ordered cross-venue route; it reads only the funding registry, holds no state, and moves no funds. LI.FI responses are passed through with an unsigned transactionRequest; Predictefy does not sign or hold funds. LI.FI status is poll-only and preserves provider substates. LI.FI charges 0.25% plus any configured integrator fee; no completion-time promise is made.

getBridgeQuote takes either a toVenue or an explicit toChain + toToken pair, never both. The explicit form is not limited to Predictefy venues: it forwards to LI.FI unrestricted, so any LI.FI-supported chain and token is a valid destination — including a chain’s native gas token, addressed with the zero-address sentinel 0x0000000000000000000000000000000000000000.

// Arbitrum USDC to native POL on Polygon. Verified against production on 2026-08-18.
const gas = await client.funding.getBridgeQuote({
  fromChain: 42161,
  fromToken: '0xaf88d065e77c8cC2239327C5EDb3A432268e5831',
  fromAmount: '10000000',
  fromAddress: '0x...',
  toChain: 137,
  toToken: '0x0000000000000000000000000000000000000000',
});

That sentinel is the answer to a problem this lane creates. A bridge leaves you holding a token on a chain where you may hold no gas at all, and the approval and order that follow need native gas on both the source and destination chains. Quote native gas to the destination chain first, then bridge the collateral you actually intend to trade.

Cross-VM destinations — a Solana toChain, for example — additionally require toAddress, the recipient on the destination chain. Without it LI.FI defaults the recipient to the EVM fromAddress and rejects the quote. toAddress is forwarded untouched and deliberately not address-validated, because valid formats differ per VM.

REST-only Polymarket callers can build the same finite transactions as the local SDK:

POST /v1/funding/polymarket/steps
Content-Type: application/json


{
  "amount": "25.5",
  "sourceAsset": "usdce",
  "exchange": "ctf",
  "recipient": "0x1234567890abcdef1234567890abcdef12345678"
}

The response orders complete unsignedTransaction envelopes as USDC.e approval, pUSD wrap, then pUSD exchange approval. Use sourceAsset: "pusd" after a bridge already delivers pUSD; that form returns only the exchange approval. Set exchange to ctf or neg_risk; arbitrary spenders are rejected. The caller reviews, signs, and broadcasts every step locally.

Hosted Hyperliquid quotes use Glide’s hypercore:mainnet destination and raw REST token address 0x2000000000000000000000000000000000000000 for Hypercore USDC, so toVenue=hyperliquid requests payment options that settle into the caller’s Hypercore spot balance instead of stopping on Arbitrum. Glide reports totalFeeUSD per option; its public docs do not publish a fixed Hypercore fee or min/max. The old LI.FI route is historical context only: it had to target 1337 rather than HyperEVM 999, which does not auto-credit margin. For a Hyperliquid quote, pass the USDC funding amount in six-decimal base units; the hosted lane converts it to Glide’s human-readable transfer amount.

Today’s first-party HIP-4 outcome markets spend from spot USDC directly. After the executable bridge-session flow, call POST /v1/funding/hyperliquid/steps with the owner and optional target. It reports spendable total - hold, any shortfall, and a typed reason with zero transfer steps. Named builder DEX transfers are future-only and require a non-empty server-configured destinationDex; current first-party outcomes expose destinationDex: null.

SX Network is not on LI.FI. Hosted SX Bet quotes also use Glide. If Glide support is unavailable for the account, either Glide venue quote fails closed with 503 BRIDGE_PROVIDER_UNAVAILABLE; available quotes still require client-side signing and do not give Predictefy custody. Kalshi, Gemini, Smarkets, and Polymarket US are fiat_custodied venue properties and are likewise not generic crypto-bridge destinations. Kalshi can accept crypto inside its KYC flow, but those deposits terminate in venue custody.

Local builder rules are deliberately narrow:

  • buildApprovalTx emits finite ERC-20 approvals only and rejects unsafe/max-sized amounts, guarding against the 2024 LI.FI infinite-approval incident class.
  • buildDepositTx supports native Arbitrum USDC into Hyperliquid Bridge2 and rejects amounts below 5 USDC. buildWithdrawRequest builds withdraw3 EIP-712 data, but withdrawal submission remains experimental.
  • Polymarket trades six-decimal pUSD. buildCollateralWrapTxs converts Polygon USDC.e (wrap input only, not trading collateral) to pUSD. Before trading, approve pUSD from the order maker to the V2 CTF Exchange 0xE111180000d2663C0091e4f400237545B87B996B, or to the V2 NegRisk exchange 0xe2222d279d744050d28e00520010520000310F59 for a NegRisk market. The separate buildDepositWalletFundingTx account flow funds an explicitly supplied Polymarket deposit wallet. CREATE2 address derivation is deliberately not implemented. The hosted /v1/funding/polymarket/steps builder emits byte-equivalent transactions for REST-only callers.
  • PredictStreet trades six-decimal USDC.e on ADI Chain 36900 from a caller-specific vault. Resolve that vault through VaultFactory 0xc16B8b190064451c2FeEb2e77c4B2aC4c7009552, approve USDC.e to the vault, then call depositERC20. The execution lane performs only the read-only vaultOf lookup; it does not build or submit the approval or deposit.
  • buildPermitRequest requires the caller to read SX Bet token name and nonce from the live contract. Use version "1" for SX Network USDC: version() does not exist, and the domain separator matches version "1" on chain 4162. The returned /orders/approve body includes the venue-required tokenAddress.
  • createPolymarketWithdrawalRequest and submitPolymarketWithdrawalRequest implement the withdrawal-address request step; the caller then transfers funds to the returned matching address.
  • buildSxOrbitDepositTxs is EXPERIMENTAL. It requires gas inputs from a current reference deposit; validate every returned field before signing.

Every returned transaction or typed-data artifact is unsigned. Validate its chain, token, spender, recipient, amount, and calldata before signing locally.

How funds enter and leave each venue

Section titled “How funds enter and leave each venue”

Everything above describes funds going in. Getting them out is not a Predictefy capability: the API publishes no withdrawal and no bridge-out route, so each venue is a custody island. Funds leave only by that venue’s own rails, and moving a balance from one venue to another means withdrawing to your own wallet first, then funding the next venue as a fresh deposit. That is the deliberate no-escrow posture rather than a gap — Predictefy never holds the funds, so it has nothing to send back — and unified cross-venue funding remains roadmap, not a shipped capability. GET /v1/funding/transfer-plan returns that withdraw-then-fund sequence pre-composed for the pairs it supports, but planning is all it does: every leg is caller-signed, Predictefy submits none of them, and no balance moves through the API.

Which exit applies depends on where the collateral actually sits:

Custody model How funds enter How funds leave
Collateral stays in your wallet — Limitless, Opinion, Predict.fun, Rain, Myriad, Polymarket EOA form Hold the venue’s collateral in your own EOA and approve the exchange. GET /v1/bridge/quote delivers it by toVenue for Limitless, Opinion, Predict.fun, Rain, and Polymarket. Myriad has no toVenue route (bridgeProvider: none), so use the explicit toChain + toToken form. Nothing to withdraw. Collateral and outcome tokens never leave your key; revoke the approval to end the exchange’s spend rights.
Balance sits at the venue — Hyperliquid, PredictStreet, Polymarket deposit-wallet form, SX Bet POST /v1/bridge/session for Hyperliquid; the vault depositERC20 for PredictStreet; the venue’s own deposit flow otherwise. The venue’s own withdrawal, detailed below. Predictefy builds unsigned artifacts for some of these and submits none of them.
No hosted funding path — Pascal, XO, PRED Not classified. The funding registry records these as fundingClass: not_applicable with a null collateral asset, which means Predictefy has verified neither where the collateral sits nor how it gets there. Fund through the venue’s own documented route and treat the deposit path as verify with venue. Whatever the venue’s own rails are. Predictefy publishes no deposit step, no bridge route, and no exit for these three.
Venue-custodied account — Kalshi, Gemini, Polymarket US The venue’s regulated or KYC’d account rails. fiat_custodied venues are not crypto-bridge destinations and reject a toVenue bridge quote. The same venue account rails, entirely outside Predictefy.

Per-venue exits worth knowing before you fund:

  • Hyperliquid withdrawals reach Arbitrum and nowhere else. The venue’s withdraw3 action is Hyperliquid’s Arbitrum bridge, so the destination chain is not a choice the caller makes. buildWithdrawRequest builds the withdraw3 EIP-712 data against the Arbitrum domain (chainId 0xa4b1) and stops there: it is build-only, and you sign and POST it to Hyperliquid yourself. Reaching any other chain is two legs — withdraw to Arbitrum first, then bridge onward with GET /v1/bridge/quote. The $1 flat fee and the venue’s dispute window apply to leg one. GET /v1/funding/transfer-plan returns all three legs in order for Hyperliquid to Polymarket — the withdrawal, the bridge quote, and the destination approval — with every amount after leg one already net of that fee.
  • Polymarket uses the venue’s own two-step withdrawal. createPolymarketWithdrawalRequest/submitPolymarketWithdrawalRequest ask bridge.polymarket.com for a destination-specific address; you then send funds from your Polymarket wallet on Polygon to the address it returns.
  • SX Bet publishes no withdrawal endpoint at all. withdrawFromProxy() throws NOT_SUPPORTED by design; withdrawals and proxy-to-proxy transfers are Safe-authorised in the sx.bet app, and this lane will not emulate a route the venue does not offer.
  • PredictStreet funds leave through the caller-specific vault on ADI Chain. The execution lane performs only the read-only vaultOf lookup and builds neither the deposit nor the exit.