Famille A : résolution par oracle
Les marchés de la Famille A se résolvent automatiquement àresolutionTime en lisant une entrée d’oracle de prix XLS-47 sur le XRPL. Aucune intervention humaine n’est requise pour une résolution propre.
Ce qui se passe au moment de la résolution
Lire l'oracle
Le moteur de règlement interroge l’oracle XLS-47 à
oracleAccount / oracleDocumentId pour la paire baseAsset/quoteAsset.Vérifier la fraîcheur
Le La période de grâce de 120 secondes après la clôture absorbe la cadence de publication : une valeur publiée juste après
lastUpdateTime de la valeur de l’oracle doit satisfaire :resolutionTime est toujours acceptée. La fraîcheur est mesurée par rapport à resolutionTime, et non à l’horloge murale au moment où le moteur s’exécute, de sorte qu’un règlement tardif ne peut pas utiliser un prix qui n’existait pas à la clôture.Évaluer la condition
Le moteur compare le prix rapporté par l’oracle à
strike en utilisant comparison :>= strike, l’issue 0 (Yes) gagne siprice >= strike<= strike, l’issue 0 (Yes) gagne siprice <= strike
Publier l'enregistrement de résolution
L’opérateur écrit un mémo
ResolutionRecord signé sur le compte du pool avec status: "final", l’index winningOutcome, la valeur brute oracleValue et l’horodatage oracleLastUpdateMs. Cet enregistrement constitue la preuve on-chain faisant autorité pour la résolution.Annulation pour défaut de fraîcheur
Si l’âge de la valeur de l’oracle par rapport àresolutionTime se situe en dehors de la fenêtre de fraîcheur (en tenant compte de la période de grâce de 120 secondes), le marché est annulé immédiatement. Toutes les mises sont remboursées. Voir Politique d’annulation ci-dessous.
Famille B : résolution manuelle (optimiste)
Les marchés de la Famille B utilisent un modèle de résolution optimiste adapté de l’Optimistic Oracle d’UMA, reconstruit sur les primitives natives du XRPL, sans contrat intelligent ni vote par token. L’opérateur propose une issue et dépose un bond, une fenêtre de contestation s’ouvre, puis le comité multisig finalise. counsel dit clairement où réside la confiance : il s’agit d’un modèle custodial transparent, un conseil divulgué, et non d’un oracle sans confiance. La conception complète se trouve dans optimistic-oracle.md.Ce qui se passe au moment de la résolution
L'opérateur propose et dépose un bond
Après
resolutionTime, le proposeur publie un ResolutionRecord signé on-chain avec status: "proposed" sur le compte du pool, incluant winningOutcome, une URL de source de preuve et un hash de preuve. Le proposeur dépose le bond symétrique dont la taille est pré-engagée dans la définition du marché (bondXrp), de sorte que le bond est fixe et non négociable.La fenêtre de contestation s'ouvre
La fenêtre dure
disputeWindowHours (48 par défaut). N’importe quel compte peut ouvrir une contestation en déposant un bond équivalent sur le pool, en ancrant sa propre preuve (une URL de source et un hash de contenu) on-chain, de sorte que la contestation référence le même enregistrement canonique que la proposition. Une proposition non contestée est correcte par défaut.Sans contestation : le comité signe
Si la fenêtre se ferme sans contestation, le comité multisig cosigne l’issue proposée. Le règlement se déroule à l’identique de la Famille A : un
ResolutionRecord final est écrit on-chain, puis les payouts sont distribués, et le proposeur récupère son bond.Avec contestation : le comité finalise et règle les bonds
Si un ou plusieurs bonds sont déposés, le comité examine la preuve de manière indépendante et signe l’issue finale, qui peut concorder ou non avec la proposition. L’enregistrement final
status: "final" remplace la proposition. Le comité règle ensuite les bonds (voir ci-dessous).Un enregistrement
proposed est visible dans l’historique des transactions du compte du pool mais ne déclenche pas la distribution des payouts. Seul un enregistrement status: "final" initie le règlement. Une annulation (l’issue « trop tôt » ou ambiguë) est un résultat à part entière qui rembourse chaque mise sans frais, l’analogue de la réponse 50-50 d’UMA, de sorte qu’un marché sans réponse possible ne se résout jamais de travers.Bonds et frais finaux
Les bonds sont symétriques et pré-engagés : le proposeur déposebondXrp et un contestataire doit le faire correspondre exactement, de sorte qu’aucune des deux parties ne peut prendre une position moins coûteuse. Le mauvais côté perd son bond au profit du bon côté, ce qui transforme une proposition erronée en argent gratuit pour le premier contestataire honnête, et constitue toute la sécurité économique du modèle.
counsel implémente également les frais finaux d’UMA. Une fraction configurable du bond confisqué, finalFeeBps (en points de base), est prélevée au profit du trésor du conseil avant que le gagnant ne soit payé ; le bond propre du gagnant est toujours restitué intégralement. Ces frais financent l’arbitre et font qu’un bond frivole coûte réellement de l’argent, même lorsque vous gagnez. Le calcul des bonds est exclusivement entier et arrondit vers le bas, de sorte que les frais ajoutés aux gains ne peuvent jamais dépasser le bond confisqué, et l’ensemble du chemin est piloté par les tests.
| Issue | Proposeur | Contestataire | Conseil |
|---|---|---|---|
| Non contestée | bond restitué | — | — |
| Maintenue (la contestation échoue) | bond restitué + bond du contestataire moins les frais | perd son bond | frais finaux |
| Renversée (la contestation l’emporte) | perd son bond | bond restitué + bond du proposeur moins les frais (réparti) | frais finaux |
Politique d’annulation
Les conditions suivantes entraînent un remboursement intégral sans frais déduits :| Condition | Déclencheur |
|---|---|
| Valeur d’oracle non fraîche | Aucune valeur d’oracle n’existe dans freshnessSeconds + 120s de grâce par rapport à resolutionTime (Famille A uniquement) |
| Pool à sens unique | Toutes les mises publiques portent sur une seule issue ; il n’y a pas de pool opposé à répartir entre les gagnants |
| Événement annulé ou non mappable | L’événement sous-jacent est annulé, reporté indéfiniment, ou produit un résultat qui ne correspond à aucune des issues définies |
| Aucune mise publique | Le pool brut se compose entièrement des mises d’amorçage du market-maker ; aucun véritable parieur n’a participé |
Ce qui se passe en cas d’annulation
Une annulation n’est pas un état d’erreur, c’est une issue de contrat définie. En cas d’annulation :- Le
ResolutionRecordest écrit on-chain avecvoid: trueetwinningOutcome: null. - Chaque mise hors amorçage est remboursée à sa valeur faciale (drops entrés = drops sortis).
- Aucun frais n’est déduit d’aucun remboursement.
- Le solde restant du compte du pool (amorçages + poussière) reste sous le contrôle de l’opérateur.
Modèle de confiance
Les comptes de pool sont sécurisés de sorte qu’aucune partie unique, y compris l’opérateur, ne puisse déplacer les fonds de manière unilatérale :Clé maître désactivée
Une fois le compte du pool créé, la clé maître est désactivée on-chain. Il n’existe aucune clé de signature pouvant autoriser un Payment unilatéral.
SignerList n-of-m
Un
SignerList multisig est défini sur le compte du pool. Un seuil de membres du comité doit cosigner toute transaction sortante avant que le XRPL ne la traite.