> ## Documentation index > Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt > Use it to discover every available page before exploring further. # Accounts & funding > Capability-qualified account reads, local owner credentials, and non-custodial funding helpers. 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. :::note[Hosted routes are capability-qualified] Hosted account and funding routes fail explicitly when a resource or destination is unavailable. Predictefy does not substitute invented data for an unsupported resource. ::: ## `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. ```ts 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 These read-scoped, `live`-metered routes are available: ```text 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. | ```ts // 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 The adjacent `client.funding` surface combines hosted requirements and provider-dispatched bridge reads with local, unsigned builders: ```ts // 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`. ```ts // 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: ```http 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 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.