> ## Documentation index
> Fetch the complete documentation index at: https://docs.predictefy.com/llms.txt
> Use it to discover every available page before exploring further.

# Predict.fun

> The build request schema, signing scheme, and bounds for Predict.fun.

## Step zero — from nothing to your first trade

1. **Create the account.** Open [predict.fun](https://predict.fun), connect the EOA you will trade
   from, and follow the current prompts; the repo sources do not document the identity-check
   sequence.
2. **Set up credentials.** Create a wallet and secure its seed phrase; never share the private key,
   which Predictefy never sees. Get the API key in your venue account's API settings. There is no
   session token to copy: the SDK has your wallet sign Predict.fun's dynamic auth message locally
   and exchanges it directly for the JWT.
3. **Fund and approve.** A practical first test is about $10–$25 of USDT on BNB Smart Chain (`56`),
   plus a little BNB for approval or on-chain cancellation gas—not a venue minimum. If funds start
   elsewhere, use `GET /v1/bridge/quote` before signing and broadcasting its transaction request.
4. **Allow time.** Budget 1–2 hours for a first wallet, bridge, and approval; less if already funded.

The hosted region is blocked; the direct path still requires your connection to be venue-eligible.

## What you need first

- **Production status:** Armed for build, submit, and cancel as verified on 2026-08-15, but the
  deployed hosted route remains region-blocked by the venue. The venue-direct SDK path is
  source-ready and still awaits one eligible submit-to-status live pass.
- **Wallet and chain:** An EOA on BNB Smart Chain (`56`); Safe and proxy identities are rejected.
- **Venue account:** Yes. The working direct path needs a Predict.fun API key and a wallet-authenticated
  venue session.
- **Credentials:** `client.accounts.predictfun` keeps the API key and wallet private key in-process,
  creates the JWT directly with Predict.fun, and sends neither to Predictefy. The hosted path instead
  accepts the caller's session bearer transiently for submit, cancel, or refresh.
- **Funding:** BSC USDT in the EOA, with approval to the exchange selected by the market's exact
  NegRisk/yield-bearing type. The LI.FI helper can fund the wallet.

Predict.fun is also server-built by default, using the same plain selector and order fields. It is
strictly EOA-only: signature type `0`, with `maker == signer == owner`; any Safe/proxy request is a
typed `400 VALIDATION_ERROR`. The lane fetches the exact catalog market from Predict.fun, requires
the selected on-chain outcome token to occur exactly once, reads its current `feeRateBps`, and
resolves the exchange from the exact `(isNegRisk, isYieldBearing)` pair. Missing type truth or any
catalog/API/exchange disagreement fails closed with nothing persisted.

LIMIT amounts follow the pinned 1.3.8 SDK: 18-decimal price/size inputs are truncated to three and
five significant digits respectively, and size must be at least `0.01` shares. Omitted `expiresAt`
uses the SDK's `2100-01-01` no-expiry sentinel; an explicit Unix timestamp must be in the future and
is carried verbatim. The server uses a full-width 256-bit cryptographic salt because Predict.fun's
relay also preserves salt as a decimal string. The response includes the venue-shaped unsigned
payload, `buildVersion: 1`, and complete EIP-712 fields. An active session bearer is needed only
when submitting, cancelling, or refreshing; it is never accepted in this build body. The legacy
echoed `buildResult` remains accepted unchanged.

## Client-side submit route

Predict.fun rejects order traffic from restricted regions, and hosted submits now route through
Predictefy's eligible regional egress relay (venue reads and order requests verified to reach the
venue through it, 2026-08-22 — a live credentialed submit has not yet been verified on that path).
The client-side route below stays fully supported for callers who prefer their own eligible
connection: it builds at Predictefy, signs in the caller's wallet, and submits under the caller's
own API key and in-process JWT:

```ts
const client = new Predictefy({
  apiKey: process.env.PREDICTEFY_API_KEY,
  execBaseUrl: PREDICTEFY_EXEC_BASE_URL,
  venueCredentials: {
    predictfun: {
      apiKey: process.env.PREDICTFUN_API_KEY!,
      privateKey: process.env.PREDICTFUN_WALLET_KEY!,
    },
  },
});

const placed = await client.accounts.predictfun.createOrder(
  {
    idempotencyKey: 'your-stable-build-key',
    outcome: 12345,
    outcomeSide: 'YES',
    isBuy: true,
    price: 0.4,
    size: 10,
    owner: wallet.address,
  },
  wallet,
);
const status = await client.accounts.predictfun.fetchOrder(placed.orderHash);
```

Before asking the wallet to sign, the SDK independently reconstructs the exact Predict.fun EIP-712
order, then reads the market's authoritative record from the fixed `api.predict.fun` origin and
refuses to sign unless everything agrees: the signed token must be the named outcome the caller
requested (outcomes are matched by the venue's own outcome names — non-binary shapes refuse rather
than guess), the EIP-712 `domain.verifyingContract` must be the exact exchange contract selected by
the market's authoritative `isNegRisk`/`isYieldBearing` flags among the four known contracts, and
the signed `feeRateBps` must equal the market's authoritative fee. A failed or malformed venue read
refuses before signing, and the immutable mapping is cached per client per market. Intent binding
is mandatory: the exported signing helper requires the original order intent and a trusted market
mapping at both the type and runtime level — there is no structural-only signing path for this
venue. String prices and sizes are parsed losslessly (plain decimals up to 18 fractional digits;
anything else refuses), so precision drift can never smuggle different economics past the amount
check.

Submission sends the exact server-lane wire body under the caller's `x-api-key` and an in-process
JWT (the dynamic auth message is signed by the caller's wallet and exchanged directly with the
venue). Every credentialed call goes only to the fixed venue origin and refuses redirects; failures
are typed and generic. A successful create requires only the documented `orderId` and `orderHash`;
a missing status field is treated as acknowledged, never as a failure — a placed order is never
reported as failed.

Cancellation is the one verb where this SDK path is narrower than the hosted lane. **On this
venue-direct path**, `client.accounts.predictfun.cancelOrder` is honestly refused as unsupported:
the venue's `/v1/orders/remove` only removes the book entry while the signed order remains valid,
and full invalidation requires an on-chain `CTFExchange.cancelOrders` transaction this SDK client
does not send. **The hosted lane does both** — its registry row is `cancelOrder: true`, and
`POST /v1/exec/predictfun/orders/{executionId}/cancel` takes a `mode`:

- `mode: "book"` (the default) relays the venue's own `POST /orders/remove` under your transient
  session bearer — the book removal, with the same residual the venue itself warns about.
- `mode: "onchain"` returns an unsigned BSC transaction encoding
  `CTFExchange.cancelOrders([order])`, built from the stored order struct and its stored signature.
  You sign and broadcast it yourself; Predictefy verifies chain, recovered maker, and byte-equal
  `{to, data, value}`, then records `signed` without claiming a broadcast. A target that was never
  submitted has no stored signature and fails closed.

So the honest summary is: no single call fully invalidates a Predict.fun order, but both halves are
implemented — one on each hosted cancel mode — and only the venue-direct SDK client refuses.

This implementation is source-ready. One eligible submit → status pass remains pending.