> ## 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.
# Résolution des marchés : voies de résolution par oracle et manuelle
> Comment counsel résout les marchés oracle de la Famille A et les marchés manuels de la Famille B, ce qui déclenche une annulation, et comment le modèle de confiance multisig protège les fonds du pool.
La résolution est le processus par lequel l'issue gagnante d'un marché est déterminée et les fonds sont distribués aux bons destinataires. counsel propose deux voies de résolution, l'évaluation automatique par oracle pour les marchés de prix crypto et un processus optimiste proposé par l'opérateur pour les événements du monde réel, mais les deux se terminent de la même manière : un multisig de comité libère les fonds depuis le compte du pool, on-chain.
## 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
Le moteur de règlement interroge l'oracle XLS-47 à `oracleAccount` / `oracleDocumentId` pour la paire `baseAsset`/`quoteAsset`.
Le `lastUpdateTime` de la valeur de l'oracle doit satisfaire :
```
-120s ≤ (resolutionTime − oracle.lastUpdateTime) ≤ freshnessSeconds
```
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 `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.
Le moteur compare le prix rapporté par l'oracle à `strike` en utilisant `comparison` :
* `>= strike`, l'issue 0 (Yes) gagne si `price >= strike`
* `<= strike`, l'issue 0 (Yes) gagne si `price <= strike`
Si la condition n'est pas remplie, l'issue 1 (No) gagne.
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.
Le multisig de comité envoie un Payment depuis le compte du pool vers chaque parieur gagnant, étiqueté avec un mémo `payout`. Le règlement est idempotent : le moteur lit les comptes déjà payés depuis le ledger avant chaque exécution et les ignore.
### 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](#void-policy) 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](https://github.com/gamween/counsel/blob/main/docs/optimistic-oracle.md).
### Ce qui se passe au moment de la résolution
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 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.
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.
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épose `bondXrp` 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é |
Lorsqu'une condition est remplie, le moteur de règlement distribue des remboursements au lieu de payouts. Chaque parieur récupère exactement sa mise initiale via un Payment XRP natif. Les amorçages du market-maker sont exclus des remboursements (ils sont neutres pour la maison) et restent en résidu dans le pool.
## 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 :
1. Le `ResolutionRecord` est écrit on-chain avec `void: true` et `winningOutcome: null`.
2. Chaque mise hors amorçage est remboursée à sa valeur faciale (drops entrés = drops sortis).
3. Aucun frais n'est déduit d'aucun remboursement.
4. Le solde restant du compte du pool (amorçages + poussière) reste sous le contrôle de l'opérateur.
Les remboursements sont émis dans la même boucle de Payment idempotente par destinataire utilisée pour les payouts, de sorte qu'un échec partiel en cours d'exécution peut être relancé en toute sécurité.
## 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 :
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.
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.
Chaque pari, proposition, contestation et payout est une transaction on-chain native. Vous pouvez vérifier l'historique complet de n'importe quel compte de pool de manière indépendante en utilisant n'importe quel nœud d'historique complet XRPL ou explorateur de blocs, aucun accès à l'API de counsel n'est requis pour auditer le cycle de vie d'un marché.