Accueil · Apprendre · Programme Builder PredictAsiaX

Programme Builder PredictAsiaX

Publié le 2026-09-07Lecture : 9 minDéveloppeur
TL;DR
Le programme Builder PredictAsiaX a trois paliers — Verified (par défaut à l'approbation), Genesis (20 premières places, mérite, limites de débit 10×), Partner (négocié individuellement, jusqu'à 20×). Les grants sont payés en PAX avec vesting cliff + linéaire sur trois pistes (Hackathon 500-2 000, Builder 5 000-50 000, Partner 100 000-500 000) plafonnés à 2M / 5M / 15M PAX par mois / trimestre / année. La surface API : 38 chemins REST à travers 14 groupes de tags plus un flux WebSocket avec 48 types d'événements plus un serveur MCP à 7 outils. Le sandbox est anonyme, self-service, sur l'hôte de production avec des plafonds $10 / $100 et une clé valide 30 jours.

Pour qui est le programme Builder

Le programme Builder PredictAsiaX s'adresse aux développeurs, agents, desks de market-making et Builders d'interface qui veulent router du flux réel de marché de prédiction via leur propre produit et être payés pour cela. Si vous construisez un bot de trading, un agent IA, un front-end mobile, un tableau de bord d'analyse ou un onramp qui permet à vos utilisateurs de trader sur PredictAsiaX, le programme Builder est où vous obtenez une clé API, l'attribution et un chemin vers les grants.

Trois paliers, une seule voie de promotion

Chaque Builder approuvé commence à Verified. Deux paliers supérieurs se gagnent ou se négocient :

  • Verified — par défaut à l'approbation. Accès API complet, limites de débit de base, éligible aux grants PAX.
  • Genesis — 20 premières places, au mérite. 10× les limites de débit de base (bursts personnalisés négociables), placement mis en avant sur le répertoire /builders avec badge verified, accès anticipé aux API non publiées, canal direct ingénierie avec office hours hebdomadaires, fourchette de grant étendue.
  • Partner — négocié individuellement pour les échanges routant du flux, les market makers et les intégrations mainstream. Jusqu'à 20× de limites de débit (entièrement négociables par contrat), canal de compte dédié, co-marketing, remise fee-tier, et la plus grande fourchette de grant.

La promotion de palier est basée sur le produit livré et la traction, pas sur le paiement. Genesis et Partner se gagnent en démontrant des utilisateurs live et un vrai volume via votre intégration.

Le programme de grants PAX

Les grants sont payés en PAX, le token natif de la plateforme, avec vesting cliff + linéaire. Sémantique pull-claim — les tokens vestés restent sur la plateforme jusqu'à ce que vous appeliez claim() pour les déplacer en custody.

  • Hackathon — 500-2 000 PAX. Gagnants de hackathons de week-end, premières intégrations, petites expérimentations. Pas de cliff · environ 6 mois de vest linéaire · décision 48 heures · GitHub public et démo requis.
  • Builder — 5 000-50 000 PAX. Développeurs indépendants livrant un vrai produit sur PredictAsiaX. Cliff de 3 mois · vest linéaire de 12 mois · cohorte hebdomadaire · exige une URL live avec plus de 30 jours d'uptime et soit ≥100 utilisateurs soit 10 000 $ de volume routé.
  • Partner — 100 000-500 000 PAX. Échanges routant du flux, market makers et intégrations mainstream. Cliff de 6 mois · vest linéaire de 24 mois · quatre milestones à 25 % chacun · cohorte mensuelle · co-marketing et canal dédié.

Plafonds de budget appliqués : 2M PAX par mois, 5M par trimestre, 15M par an. Les candidatures au-delà du plafond retournent GRANT_BUDGET_EXCEEDED immédiatement. L'usage actuel est interrogeable via l'endpoint admin grants budget.

La surface API, en un coup d'œil

  • REST. 38 chemins et 42 opérations à travers 14 groupes de tags : Discovery, Builders, Apps, Attribution, Revenue, Connect, Subaccounts, Composer, Liquidity, Data, Webhooks, Marketplace, Oracle, Sandbox. Format de réponse en enveloppe, Money toujours en chaîne décimale, IDs de marché déterministes de la forme m_.
  • WebSocket. Une seule connexion multiplexée portant 48 types d'événements à travers market data, fast round, account, security et ops. Souscrivez avec la méthode SUBSCRIBE et une liste de canaux.
  • MCP. Sept outils exposés sur mcp.predictasiax.com, quatre en lecture seule (sans auth) et trois qui requièrent une API key. Voir règlement vérifiable pour les endpoints d'audit et le flux d'inclusion Merkle.
  • Auth. Trois schémas : API Key (sk_live_* via X-Api-Key), HMAC (quatre en-têtes POLY_ACCESS_KEY / POLY_TIMESTAMP / POLY_PASSPHRASE / POLY_SIGNATURE), Session Bearer.

Sandbox en 30 secondes

Anonyme, self-service, aucun email :

{`curl -X POST https://api.predictasiax.com/v1/sandbox-keys # → { "api_key": "sk_live_...", "tier": "self_serve", # "limits": { "max_order_usdt": 10, "daily_notional_usdt": 100 }, # "expires_at": "…30 days from now…" }`}

Même hôte de production, exécutions simulées au prix médian, plafonnées à $10 par ordre et $100 de notionnel quotidien, clé valide 30 jours. Démonstration de 5 minutes : mint → liste des marchés → passer un ordre de $1 → lire la répartition des frais résultante → annuler.

Attribution et paiements

L'attribution est capturée dans l'order intent signé — le champ execution_builder_id identifie le Builder dont l'interface a routé le trade spécifique, et le cas échéant, acquisition_builder_id identifie le Builder ayant attribué initialement l'utilisateur trader. Les trades attribués participent à la répartition des frais ; le frais taker est de 50 bps du notionnel. Les paiements sont retenus pour revue anti-abus puis regroupés en USDT vers l'adresse de wallet que vous enregistrez dans le Builder Portal.

Comment postuler

  1. Ouvrez builders.predictasiax.com et soumettez une candidature Builder — description du produit, utilisateurs cibles, volume attendu.
  2. Obtenez l'approbation à Verified et recevez une clé API sk_live_* avec drapeau de palier.
  3. Construisez contre le palier sandbox ($10 max par ordre, $100 de notionnel quotidien, exécutions simulées au prix médian).
  4. Livrez en production. Chaque exécution écrit un enregistrement attribué dans le registre partagé ; les paiements sont regroupés vers votre adresse USDT enregistrée après la rétention anti-abus.
  5. Postulez à Genesis (20 premières places, au mérite) ou Partner (négocié) après avoir démontré du produit livré et de la traction.

PAX Holder Graduation Discount

Long-term PAX holders climb Builder tiers with a discounted graduation deposit. The discount scales with your PAX Holder tier (30-day rolling USD × continuous-days-held).

  • Bronze ($100 for 7 days) — −10% off graduation threshold
  • Silver ($500 for 30 days) — −20% off
  • Gold ($5,000 for 90 days) — −30% off
  • Platinum ($50,000 for 180 days) — −50% off
  • Diamond ($500,000 for 365 days) — −70% off

The discount is applied automatically by the tier graduation cron. Track your progress at the Tier Center.

Questions fréquentes

Qu'est-ce que le programme Builder PredictAsiaX ?

Le programme Builder est la façon dont les développeurs tiers, les agents et les partenaires d'intégration construisent au-dessus de PredictAsiaX. Il fournit une surface API (38 chemins REST à travers 14 groupes de tags plus un flux WebSocket avec 48 types d'événements), l'attribution des trades routés via votre interface, un programme de grants en PAX, et une structure commerciale à trois paliers (Verified / Genesis / Partner) avec des avantages progressifs.

Quels sont les trois paliers Builder ?

Verified est le palier par défaut où tout Builder approuvé commence, avec les limites de débit de base et l'accès API standard. Genesis est un palier au mérite plafonné aux 20 premières places, avec limites de débit 10×, placement mis en avant sur le répertoire /builders, accès anticipé aux API non publiées, et fourchette de grant étendue. Partner est négocié individuellement pour les intégrations à haut débit, les échanges et les market makers, avec jusqu'à 20× de limites de débit, canaux de compte dédiés, co-marketing, et la plus grande fourchette de grant. Détails complets des paliers sur builders.predictasiax.com et docs.predictasiax.com/builders.

Comment fonctionne le programme de grants PAX ?

Les grants sont payés en PAX, le token natif de la plateforme, avec vesting cliff + linéaire. Trois pistes : Hackathon (500-2 000 PAX, pas de cliff, environ 6 mois de vest linéaire, décision en 48 heures, GitHub public et démo requis), Builder (5 000-50 000 PAX, cliff de 3 mois et vest linéaire de 12 mois, cohorte hebdomadaire, exige une URL live avec plus de 30 jours d'uptime et soit ≥100 utilisateurs soit 10 000 $ de volume routé), et Partner (100 000-500 000 PAX, cliff de 6 mois et vest linéaire de 24 mois, quatre milestones à 25 % chacun, cohorte mensuelle). Les plafonds de budget sont 2M PAX par mois, 5M par trimestre, 15M par an — les candidatures au-delà du plafond retournent GRANT_BUDGET_EXCEEDED.

Comment m'authentifier auprès de l'API ?

Trois schémas d'authentification sont supportés. (1) API Key — créez une clé depuis Settings → API Keys ou depuis POST /v1/sandbox-keys, puis envoyez-la dans l'en-tête X-Api-Key. Toutes les clés portent le préfixe sk_live_* ; le sandbox est différencié par tier=self_serve sur la clé, pas par le préfixe. (2) HMAC — signez les requêtes avec quatre en-têtes nommés POLY_ACCESS_KEY, POLY_TIMESTAMP, POLY_PASSPHRASE, et POLY_SIGNATURE, où signature = base64(HMAC-SHA256(secret, timestamp + method + path + body)). (3) Session Bearer pour les applications interactives qui maintiennent une session utilisateur. Détails complets dans le guide d'authentification des docs.

Comment fonctionne le sandbox ?

Anonyme, self-service, aucune adresse email requise. POST sur /v1/sandbox-keys et recevez une clé sk_live_* à tier=self_serve. Le sandbox est sur le même hôte de production — pas d'URL séparée — avec des exécutions simulées au prix médian. Plafonds par clé : $10 max par ordre, $100 de notionnel quotidien, clé valide 30 jours. Une démonstration curl complète (mint → liste des marchés → passer un ordre de $1 → lire la répartition des frais → annuler) prend environ 5 minutes.

Quelle surface API est disponible ?

38 chemins REST et 42 opérations à travers 14 groupes de tags : Discovery, Builders, Apps, Attribution, Revenue, Connect, Subaccounts, Composer, Liquidity, Data, Webhooks, Marketplace, Oracle et Sandbox. Plus une API WebSocket avec une seule connexion multiplexée et 48 types d'événements couvrant market data, fast round, account, security et ops. Principes de conception : format de réponse en enveloppe, Money en chaîne décimale, IDs de marché déterministes (m_<sha256[0:16]>), et en-tête X-PII-Redacted toujours présent.

Qu'est-ce que l'intégration MCP ?

mcp.predictasiax.com expose un serveur Model Context Protocol avec 7 outils que les assistants IA (Claude Desktop, Claude Code et tout client compatible MCP) peuvent invoquer directement. Les outils en lecture seule fonctionnent sans authentification : pax.market_search, pax.probability_movers, pax.resolution_evidence, pax.sandbox_agent_examples. Les outils d'écriture et de compte requièrent une API key : pax.portfolio_read, pax.place_order, pax.cancel_order. Schémas complets des outils sur mcp.predictasiax.com/mcp/manifest.json.

Comment gagne-t-on l'attribution des trades ?

L'attribution est capturée dans l'order intent signé — les champs execution_builder_id et (le cas échéant) acquisition_builder_id identifient quel Builder a routé le trade. Les trades attribués participent à la répartition des frais, et l'attribution réglée alimente le registre financial event visible pour le Builder via le Builder Portal (builders.predictasiax.com). Le frais taker est de 50 bps du notionnel. Les paiements sont retenus pour revue anti-abus puis regroupés vers l'adresse USDT que vous enregistrez.

Comment passer du sandbox à la production ?

Postulez via builders.predictasiax.com au palier Verified. Une fois approuvé, vous recevez une clé API de production sk_live_* avec drapeau de palier. Les mêmes endpoints, les mêmes schémas et la même authentification fonctionnent — seul le drapeau de palier sur la clé change. Depuis Verified, vous pouvez accumuler l'éligibilité à Genesis (20 premières places, au mérite sur produit livré et traction) ou Partner (négocié individuellement).