Build on PredictAsiaX

A canonical API for Asia's prediction markets — trade, resolve, embed, provide liquidity. Application flow via POST /v1/apply: 18 tracks auto-provision a live sk_live_* key on submit; genesis and institutional route to human review for elevated capabilities.

1. How to become a builder

Submit an application via POST /v1/apply. Provisioning behaviour depends on the track you pick — most tracks return a live sk_live_* API key in the response body immediately. Genesis and institutional tracks route to human review.

2. What you get on approval

import { PaxClient, attachRef } from "@predictasiax/api";
const { headers } = attachRef({ storage: "cookie" });
const pax = new PaxClient({ apiKey: "sk_live_...", defaultHeaders: headers });

3. What you can build

Each category maps to a set of scopes + endpoints. Request only the scopes you need — least-privilege is enforced.

4. Builder tiers & benefits

Every approved builder starts at Verified. Genesis and Partner are earned or negotiated.

5. Grant program (paid in PAX)

🚀 Hackathon — 500 – 2,000 PAX

Weekend hackathon winners, first integrations, tiny experiments. No cliff · 6 months linear vest · 48 h decision · public GitHub + demo required.

🛠 Builder — 5,000 – 50,000 PAX

Independent devs shipping a real product on PAX. 3-month cliff · 12 months linear vest · weekly cohort · requires live URL > 30 days uptime, ≥ 100 users or $10 k routed volume.

🤝 Partner — 100,000 – 500,000 PAX

Exchanges routing flow, market makers, mainstream integrations. 6-month cliff · 24 months linear · 4 milestone gates (25 % each) · monthly decision cohort · co-marketing + dedicated channel.

Budget caps enforced in code: 2 M PAX / month · 5 M PAX / quarter · 15 M PAX / year. Apply beyond cap → GRANT_BUDGET_EXCEEDED immediately.

Claim vested PAX (SDK)

import { PaxClient } from "@predictasiax/api";

const pax = new PaxClient({ apiKey: process.env.PAX_LIVE_KEY });

// List your grants + live vesting calc
const grants = await pax.grants.list();
for (const g of grants) {
  console.log(g.id, g.tier, "claimable:", g.vesting.claimable, "PAX");
}

// Move vested-but-unclaimed into custody
const result = await pax.grants.claim("grant_abc123");
console.log("credited", result.claimed_now, "PAX");

FAQ

Q: How long does application-to-key take?
A: For the 18 auto-provisioning tracks: seconds. The POST /v1/apply response body contains the live sk_live_* key. For the 2 reviewed tracks (genesis, institutional): depends on admin operator throughput and the elevated capability being requested — no automated SLA. Poll status via GET /v1/apply/{ba_id}.

Q: Can I go straight to production without an application?
A: POST /v1/sandbox-keys gives you an anonymous self_serve-tier key in 30 seconds (no application, no email, no signup — see /sandbox). The self_serve tier is capped at $10/order + $100/day. To get to trade_capped / trade_full / genesis, you go through the application flow.

Q: What tier do auto-provisioning tracks start on?
A: self_serve — the same tier as an anonymous sandbox key. This is intentional: the application flow gives you a persistent, org-tagged key with attribution wired in, but the same conservative caps as sandbox. Higher tiers are reached automatically as your 30-day attributed volume grows (see below).

Q: How does tier auto-graduation work?
A: A background cron scans every 15 minutes and auto-graduates builders based on their 30-day attributed CLOB volume (execution_builder_id on clob_trades). Full ladder (TIER_GRADUATE_MIN_USDT, routes/v1AdminBridge.js):

• self_serve → read_live — $100 30d volume
• read_live → trade_capped — $1,000 30d volume
• trade_capped → trade_full — $50,000 30d volume (admin operator sign-off required, hits 14 bps builder combined share)
• trade_full → genesis — $50,000+ 30d volume, capped 20 slots, committee review, 16 bps combined + 10× rate + early API access
• genesis → partner — $1,000,000 30d volume, negotiated contract, dedicated infra, up to 20× rate

Q: How do I independently verify an attributed fill?
A: Every fill routed through your app becomes a hash-chained financial_event row that is periodically Merkle-batched and anchored. To verify: (1) get the audit_seq field from the POST /v1/orders response body (added at the time of the fill), (2) call GET /v1/audit/proof/{seq} which returns { leaf, root, proof: [siblings], anchor } plus a minimal verifier JS snippet, (3) run the snippet locally or in your build to prove leaf → root. No PAX cooperation required — the anchor field points to the batch's off-platform anchor. See /verify for a 4-language interactive verifier + Fee Architecture / financial_event taxonomy for the ledger schema.

Q: What's actually in the "reviewed" track review?
A: Admin operator confirms fit / jurisdiction / intended scope for the elevated capability (genesis = 10× rate multiplier + early access to unreleased endpoints; institutional = negotiated fee splits + dedicated infra). If terms need signing (e.g. institutional SLA), the operator handles that out-of-band via the contact channel or email you provided during application. The code does not itself require any signed document to issue a reviewed-track key.

Q: I'm building for an operator (white-label). What's different?
A: Use the operator or institutional track. operator auto-provisions; use it if you're building ops tooling for an existing PAX-integrated venue. institutional is reviewed if you need a formal operator agreement (custom fee splits, dedicated infra, customer-KYC + treasury-separation terms).

Q: Which contact channel is best for reviewed tracks?
A: Include a Telegram / Signal / Discord / Matrix handle in the description field of your application for fastest response during APAC hours. Email works too — the application accepts both. Signal for anything sensitive.

Q: Grants — see the grant program above for full mechanics. Jump to Grant Program.