Types de marchés, phases du cycle de vie et structure du pool

Chaque marché sur counsel est un objet on-chain autonome : une définition JSON signée stockée sous forme de mémo sur le XRP Ledger, un compte de pool dédié qui détient toutes les mises, et une source de résolution qui détermine le résultat gagnant. Comprendre comment ces éléments s’imbriquent vous indique ce qu’un marché peut faire, quand vous pouvez agir, et ce qui se passe en cas de problème.

Familles de marchés

counsel prend en charge deux familles de résolution. La famille est définie à la création du marché et ne peut pas changer.

Famille A, résolue par oracle (prix crypto)

Les marchés de la famille A se résolvent automatiquement par rapport à un oracle de prix XLS-47 on-chain. Aucune intervention humaine n’est requise au moment de la résolution. Ces marchés sont définis par :

Champ	Description
`oracleAccount`	Compte XRPL qui publie l’oracle
`oracleDocumentId`	`OracleDocumentID` XLS-47
`baseAsset`	Actif évalué (par ex. `"XRP"`)
`quoteAsset`	Dénomination (par ex. `"USD"`)
`strike`	Seuil de prix pour la condition binaire
`comparison`	`">="` ou `"<="`, le sens de la condition
`freshnessSeconds`	Âge maximal autorisé (en secondes) de la valeur de l’oracle par rapport à `resolutionTime`

Exemple de condition : XRP/USD >= 0.60 au moment de la résolution. Si l’oracle rapporte 0.62 dans la fenêtre de fraîcheur, le résultat 0 (“Yes”) l’emporte. S’il rapporte 0.58, le résultat 1 (“No”) l’emporte. Si aucune valeur fraîche n’est disponible, le marché est annulé. Les marchés de la famille A ont disputeWindowHours: 0 par défaut, la résolution est entièrement automatique sans période de contestation.

Famille B, manuelle (événements du monde réel)

Les marchés de la famille B couvrent des événements sans source de données on-chain : résultats sportifs, issues politiques, publications de données économiques, et ainsi de suite. La résolution est proposée par l’opérateur et soumise à une fenêtre de contestation.

Champ	Description
`source`	Source faisant autorité, nommée (par ex. `"FIFA official result"`)
`condition`	Texte exact de la condition, engagé à l’avance
`date`	Date ISO à laquelle la condition est évaluée
`evidenceHint`	Indice optionnel vers l’URL de preuve utilisée à la résolution

La fenêtre de contestation par défaut est de 48 heures. Tout compte disposant d’une mise peut contester la proposition de l’opérateur pendant cette fenêtre en déposant un bond.

Cycle de vie d’un marché

Un marché traverse une séquence fixe de phases. La phase actuelle est renvoyée dans le champ phase de GET /api/v1/markets/:id.

open → closed → resolving → resolved
                          ↘ void
         (Family B only: closed → disputable → resolving → resolved)

open

Les paris sont acceptés. Le pool s’accumule. Les cotes évoluent à chaque nouvelle mise. C’est la seule phase pendant laquelle vous pouvez placer un pari.

closed

bet_cutoff est dépassé. Aucun nouveau pari n’est accepté. Le pool est gelé. Le marché attend resolutionTime avant que le règlement ne s’exécute.

disputable (Family B only)

Après resolutionTime, l’opérateur publie une proposition de résolution et la fenêtre de contestation s’ouvre (disputeWindowHours, 48 heures par défaut). Tout compte ayant misé peut déposer un bond de contestation pendant cette période. Cette phase n’apparaît pas pour les marchés de la famille A, qui ont disputeWindowHours: 0.

resolving

La fenêtre de contestation est close (ou ne s’applique pas pour la famille A). Le multisig du comité est en cours. Aucune contestation supplémentaire ne peut être soumise.

resolved

Le résultat gagnant a été déterminé et les payouts ont été distribués. Un enregistrement status: "final" est on-chain.

void

Le marché ne peut pas être résolu équitablement. Toutes les mises sont remboursées à leur valeur nominale. Aucun frais n’est prélevé. Voir Conditions d’annulation ci-dessous.

Le champ status renvoyé par GET /api/v1/markets/:id n’affiche que open, resolved ou void. Le champ phase porte la valeur de phase détaillée (open, closed, disputable, resolving ou resolved).

Structure du pool sur XRPL

Chaque marché possède un poolAccount dédié, une adresse XRPL r qui détient tous les fonds misés sur ce marché. Les résultats sont séparés par DestinationTag :

Résultat 0 → DestinationTag 0
Résultat 1 → DestinationTag 1
Résultat N → DestinationTag N

Lorsque vous placez un pari, vous envoyez un Payment XRP natif vers poolAccount avec le DestinationTag correspondant au résultat que vous avez choisi. La clé maîtresse du compte de pool est désactivée ; les fonds ne peuvent en sortir que via un multisig du comité au moment du règlement. Vous pouvez vérifier le solde du pool de manière indépendante à tout moment en interrogeant le XRPL pour obtenir l’historique des transactions du compte de pool.

Conditions d’annulation

Les conditions suivantes déclenchent une annulation et un remboursement complets :

Pool à sens unique

Si tous les paris portent sur un seul résultat (aucune mise opposée n’existe), il n’y a pas de pool à distribuer à l’autre camp. Le marché est annulé et toutes les mises sont restituées.

Oracle périmé (famille A uniquement)

À resolutionTime, la valeur de l’oracle XLS-47 doit avoir été publiée dans un délai de freshnessSeconds par rapport à cet horodatage (avec une période de grâce de 120 secondes après la clôture). Si aucune valeur fraîche n’est disponible, le marché est annulé automatiquement.

Événement annulé, reporté ou à égalité

Si l’événement sous-jacent est annulé, reporté indéfiniment, ou produit un résultat qui ne correspond pas proprement aux résultats définis (par ex. un match nul sur un marché binaire victoire/défaite), le marché est annulé.

En cas d’annulation, chaque parieur récupère sa mise initiale via un Payment natif. Les mises d’amorçage des market-makers sont neutres pour la maison et ne sont pas remboursées, elles restent dans le pool en tant que résidu.

Plafonds de mise

Les marchés peuvent imposer des limites pour gérer la concentration du pool. Elles sont définies dans l’objet caps :

Champ	Description
`perBettorXrp`	Montant total maximal de XRP qu’un seul compte peut miser sur l’ensemble des résultats de ce marché
`perOutcomeXrp`	Montant total maximal de XRP pouvant s’accumuler sur un seul résultat
`perMarketXrp`	Montant total maximal de XRP que l’ensemble du pool du marché peut détenir

N’importe lequel de ces champs peut être absent, auquel cas aucun plafond ne s’applique. Les plafonds sont appliqués à la soumission du pari ; un pari qui dépasserait un plafond est rejeté avant d’être soumis au ledger.

Identité et déduplication des marchés

Chaque marché possède un id déterministe, calculé comme les 16 premiers caractères hexadécimaux de sha256(question | resolutionTime). Les modèles de marchés récurrents (par ex. les marchés quotidiens sur le prix du XRP) partagent un templateKey ; seule l’instance la plus récemment créée par templateKey apparaît dans la liste par défaut. Les marchés avec hidden: true sont retirés ou remplacés et ne sont pas renvoyés par l’API publique.

​Familles de marchés

​Famille A, résolue par oracle (prix crypto)

​Famille B, manuelle (événements du monde réel)

​Cycle de vie d’un marché

​Structure du pool sur XRPL

​Conditions d’annulation

​Plafonds de mise

​Identité et déduplication des marchés

Familles de marchés

Famille A, résolue par oracle (prix crypto)

Famille B, manuelle (événements du monde réel)

Cycle de vie d’un marché

Structure du pool sur XRPL

Conditions d’annulation

Plafonds de mise

Identité et déduplication des marchés