Chaque résultat, prouvable
Les marchés de prédiction ne fonctionnent que si le résultat est digne de confiance. PredictAsiaX traite chaque règlement comme un registre public : le prix résolu et un proof hash vérifiable sont écrits dans le Trade Explorer pour chaque marché. N'importe qui peut chercher un marché réglé par ID, lire le résultat, et confirmer la preuve indépendamment — sans compte, sans nous demander, sans se fier à notre parole.
C'est la promesse faite sur la page Technology & Security , tenue par les outils Verify publics de la documentation API.
Ce qui est publié pour chaque règlement
- Résultat résolu et prix. Le prix résolu exact, le côté (YES / NO pour marchés binaires) et les horodatages sont attachés à l'enregistrement de règlement du marché.
- Proof hash. Un hash cryptographique des entrées de règlement, publié aux côtés du résultat. N'importe qui peut reconstruire le même hash à partir des mêmes entrées.
- Transactions de paiement USDT on-chain. Les paiements gagnants sont exécutés on-chain et chaque transaction peut être vérifiée sur un explorateur de blocs public, indépendamment de tout tableau de bord PredictAsiaX.
- Inclusion dans l'audit Merkle. Le règlement est inclus dans un batch dont la racine Merkle est périodiquement ancrée sur le stockage R2. N'importe quel client peut appeler les endpoints d'audit pour reconstruire la preuve et confirmer l'inclusion.
Comment fonctionne la vérification, de bout en bout
- Un événement d'exécution ou de règlement se produit. L'événement est écrit dans le registre opérationnel avec tous les champs nécessaires à la reproductibilité ultérieure.
- Batching. Les événements du registre sont regroupés en batches. Chaque batch produit une racine Merkle de manière déterministe à partir de son contenu.
- Ancrage. Les racines Merkle sont ancrées sur le stockage R2 et publiées. Les racines ancrées ne peuvent pas être réécrites silencieusement — tout changement ultérieur du contenu du batch produirait une racine différente.
- Reconstruction côté client. La section Verify de docs.predictasiax.com documente six endpoints de lecture sans authentification sous
/v1/audit/*. N'importe quel client peut interroger une exécution, demander le batch auquel elle appartient, et confirmer le chemin Merkle jusqu'à la racine publiée.
Résultat : toute exécution que vous passez, et tout règlement que vous recevez, peuvent être prouvés indépendamment comme ayant été inclus dans un batch signé. Vous n'avez jamais à faire confiance à nos tableaux de bord.
Revue indépendante avant paiement
Les résultats sont confirmés par notre couche opérationnelle avant qu'un paiement ne soit libéré. C'est un choix de conception délibéré — non pour introduire du pouvoir discrétionnaire, mais pour attraper les ambiguïtés de source de données, les erreurs de feed, et les cas limites que la résolution automatisée seule manquerait. La confirmation est enregistrée dans le même registre de règlement public, donc la revue est auditable.
Une fois le résultat confirmé, les positions gagnantes sont payées instantanément en USDT — pas de file d'attente manuelle, pas d'attente d'approbation.
La fenêtre de contestation formelle
Chaque marché réglé dispose d'une fenêtre de contestation formelle pendant laquelle n'importe quel utilisateur peut soulever une contestation. Les contestations sont décidées contre la preuve de règlement publiée, pas contre des déclarations verbales. Le résultat de toute revue — maintenu, corrigé ou rejeté — est réécrit dans la même piste publique. Parce que les batches Merkle sont ancrés, la réécriture silencieuse d'un règlement décidé est impossible : elle casserait la chaîne d'audit d'une manière que tout client exécutant le flux de vérification peut détecter.
La protection du capital sous-jacente
Le règlement vérifiable n'a d'importance que si l'argent bouge quand il le doit. Deux choix de conception soutiennent cela :
- USDT réel uniquement. Chaque solde est réglé en USDT. Il n'y a pas de solde simulé et pas d'argent fictif — chaque position reflète des fonds réels.
- Fonds d'assurance ségrégué. Un fonds d'assurance dédié, financé par une part fixe de chaque marché réglé, absorbe les résultats extrêmes afin que les paiements ne soient jamais retardés par un écart de liquidité. Dès qu'un marché est résolu, les gagnants sont payés — le fonds existe pour couvrir les obligations de règlement inhabituelles sans délai.
Essayez vous-même
- Ouvrez le Trade Explorer et choisissez n'importe quel marché récemment réglé.
- Notez son ID de marché et le proof hash publié.
- Lisez la section Verify de la documentation API et exécutez la requête d'audit pour ce marché.
- Confirmez que le hash reconstruit correspond à celui publié, et que l'exécution est incluse sous la racine Merkle ancrée de son batch.
Si une étape est en désaccord avec le registre public, c'est un bug et nous voulons en être informés.