> ## Documentation Index
> Fetch the complete documentation index at: https://docs.counsel.markets/llms.txt
> Use this file to discover all available pages before exploring further.
# Types de marchés, phases du cycle de vie et structure du pool
> Une référence complète des deux familles de marchés de counsel, des cinq phases du cycle de vie, de la structure du compte de pool, des conditions d'annulation et des plafonds de mise par marché.
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)
```
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.
`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.
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`.
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.
Le résultat gagnant a été déterminé et les payouts ont été distribués. Un enregistrement `status: "final"` est on-chain.
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](#void-conditions) 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 :
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.
À `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.
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.