> ## 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.

# Fonctionnement de counsel : paris, résolution par oracle, payouts multisig

> Présentation technique du cycle de vie d'un marché counsel : paris via Payments taggés, cotes du tableau parimutuel, résolution par oracle XLS-47, fenêtres de contestation et payouts multisig.

Un marché counsel vit entièrement sur le XRP Ledger. Sa définition est un memo, ses mises sont des Payments taggés vers un compte de pool, sa résolution est un memo on-chain référençant une valeur d'oracle ou une décision signée par un comité, et ses payouts sont des Payments natifs renvoyés aux gagnants. Chaque étape est rejouable depuis le ledger. Il n'existe aucune base de données off-chain faisant autorité : le ledger est le registre, le pool et la piste d'audit.

<Note>
  counsel est transparent sur sa custody, mais pas trustless. Les pools résident dans des comptes par marché sécurisés par une SignerList multisig avec la master key désactivée, de sorte qu'aucune clé seule ne peut déplacer les fonds. Tout est on-chain et recalculable de façon indépendante.
</Note>

## 1. Créer un marché (on-chain)

Un opérateur écrit un memo JSON `counsel/market/v1` sur un Payment vers le compte de registre. La définition inclut le compte de pool, les issues, la famille (A ou B), les paramètres de résolution et la politique d'annulation. Il n'y a pas de smart contract ni d'étape de déploiement : un marché est un enregistrement sur le ledger.

Le compte de pool est un compte XRPL propre à chaque marché. Sa master key est désactivée et une `SignerList` multisig le contrôle, de sorte que les mises ne peuvent quitter le pool qu'au travers de Payments signés par le comité.

## 2. Parier via un Payment XRP taggé

Pour placer un pari, vous envoyez un Payment XRP natif vers le compte de pool du marché, avec deux tags renseignés :

<ParamField path="DestinationTag" type="integer">
  L'index entier de l'issue que vous avez choisie (par exemple `0` pour la première issue, `1` pour la seconde). C'est ainsi que le compte de pool sait à quel pool d'issue appartient votre mise.
</ParamField>

<ParamField path="SourceTag" type="integer">
  Le tag d'attribution de counsel, fourni par l'UI ou le SDK. Il crédite le pari à counsel à des fins de classement et d'attribution.
</ParamField>

<ParamField path="Amount" type="string">
  Votre mise en drops XRP (1 XRP = 1 000 000 drops).
</ParamField>

Le Payment porte également un memo JSON (`counsel/bet/v1`) consignant l'ID du marché, l'index de l'issue et le libellé de l'issue, de sorte que chaque pari soit lisible de façon indépendante on-chain.

Vous signez ce Payment dans votre propre wallet (Xaman, GemWallet, Crossmark ou une clé de bot). counsel construit la transaction non signée et la renvoie. Il ne signe jamais à votre place et ne détient jamais de clé. C'est non custodial.

```json theme={null}
{
  "TransactionType": "Payment",
  "Account":         "<your address>",
  "Destination":     "<pool account>",
  "Amount":          "5000000",
  "DestinationTag":  0,
  "SourceTag":       2606220005,
  "Memos": [
    {
      "Memo": {
        "MemoType":   "636F756E73656C2F6265742F7631",
        "MemoFormat": "6170706C69636174696F6E2F6A736F6E",
        "MemoData":   "<hex-encoded JSON payload>"
      }
    }
  ]
}
```

## 3. Le tableau parimutuel en direct

Dès qu'un pari arrive on-chain, counsel le lit depuis le ledger et recalcule les cotes de chaque issue. Le tableau parimutuel se met à jour en temps réel.

Pour chaque issue `k`, les chiffres affichés sont :

| Champ             | Formule                                        |
| ----------------- | ---------------------------------------------- |
| `implied_prob`    | `outcome_drops / total_drops`                  |
| `payout_per_unit` | `total_drops * (1 - fee_rate) / outcome_drops` |

`payout_per_unit` correspond au montant indicatif en XRP renvoyé pour 1 XRP misé si cette issue gagne, après les frais.

Ces chiffres sont **indicatifs** tant que le marché est ouvert. Parce que counsel est un véritable marché parimutuel, chaque mise ultérieure déplace la ligne. La répartition est définitive au `bet_cutoff`, fixée par l'état du pool à la clôture. Il n'existe aucun moyen de verrouiller un prix observé avant la clôture.

## 4. Résoudre

### Famille A : prix crypto (oracle)

Les marchés de prix crypto se résolvent automatiquement contre l'oracle de prix natif XLS-47. Aucun humain n'intervient dans la boucle de règlement.

<Steps>
  <Step title="L'oracle publie un prix">
    Un objet `PriceOracle` XLS-47 sur le XRP Ledger détient le dernier prix publié pour la paire d'actifs.
  </Step>

  <Step title="Les paris ferment au bet_cutoff">
    Au `bet_cutoff`, le pool est gelé. Tout Payment arrivant à ce timestamp ou après n'est pas compté comme une mise. La fermeture est appliquée d'après le timestamp du ledger, pas seulement d'après l'UI.
  </Step>

  <Step title="Valeur de l'oracle lue au moment de la résolution">
    counsel lit la dernière valeur de l'oracle depuis le ledger et vérifie sa fenêtre de fraîcheur. Si la valeur de l'oracle est périmée, le marché est annulé (voir ci-dessous).
  </Step>

  <Step title="Issue publiée on-chain">
    L'issue résolue et la valeur d'oracle lue sont écrites dans un memo `counsel/resolution/v1` sur le registre. C'est l'enregistrement permanent et auditable de la résolution.
  </Step>
</Steps>

### Famille B : monde réel (proposition, contestation, comité)

Les marchés du monde réel (résultats sportifs, issues de gouvernance, événements macro) se résolvent par une issue proposée par un opérateur, une fenêtre de contestation avec bond, et une finalisation par comité multisig.

<Steps>
  <Step title="L'opérateur publie une proposition on-chain">
    Au moment de la résolution, l'opérateur publie un memo `counsel/proposal/v1` nommant l'issue proposée et les preuves à l'appui. Cette transaction lance le compte à rebours de contestation.
  </Step>

  <Step title="La fenêtre de contestation s'ouvre">
    Pendant la fenêtre de contestation avec bond, tout compte XRPL peut contester la proposition en déposant un bond on-chain. Le montant du bond correspond à celui de l'opérateur.
  </Step>

  <Step title="Finalisation par le comité">
    Si la fenêtre de contestation se ferme sans contestation, l'opérateur règle. Si une contestation a été déposée, le comité multisig (une `SignerList` sur le compte de pool) finalise par signature à supermajorité. Chaque signature ainsi que l'issue finale sont publiées on-chain.
  </Step>
</Steps>

## 5. Payer

Les deux familles paient de la même manière. Les frais sont un forfait de 3 % (`fee_rate`, typiquement `0.03`) prélevé sur l'ensemble du pool brut avant la répartition, jamais de façon sélective sur les gagnants. Le pool net est ensuite réparti sur le côté gagnant, au prorata de la mise de chaque gagnant.

```
net_pool = total_drops * (1 - fee_rate)
payout_per_unit = net_pool / winning_outcome_drops
payout_i = floor(stake_i * payout_per_unit)
```

Chaque payout est envoyé comme un Payment XRP natif individuel, multisigné par le comité, avec un memo `counsel/payout/v1` consignant l'ID du marché, l'issue et la répartition. N'importe qui peut recalculer la répartition depuis le ledger et vérifier chaque payout. Le résidu d'arrondi issu de l'arithmétique entière en drops revient à la réserve de l'opérateur plutôt que de gonfler un payout individuel.

## Annulation et remboursement (pools dégénérés)

Un marché est annulé et intégralement remboursé, sans frais, lorsque le pool est dégénéré :

<CardGroup cols={2}>
  <Card title="Pool à sens unique">
    Une seule issue a reçu des mises, il n'y a donc aucun côté adverse à payer.
  </Card>

  <Card title="Aucun gagnant">
    Aucune issue ne peut être déclarée gagnante au regard de la définition du marché.
  </Card>

  <Card title="Événement annulé">
    L'événement sous-jacent a été annulé, reporté ou s'est soldé par une égalité.
  </Card>

  <Card title="Oracle périmé">
    Aucune valeur d'oracle fraîche n'existe dans la fenêtre de fraîcheur (famille A).
  </Card>
</CardGroup>

En cas d'annulation, chaque parieur reçoit un Payment de remboursement intégral. Aucun frais n'est prélevé.

## Cycle de vie complet

<Steps>
  <Step title="Marché créé on-chain">
    L'opérateur écrit un memo `counsel/market/v1` sur un Payment vers le compte de registre, définissant le compte de pool, les issues, la famille, les paramètres de résolution et la politique d'annulation.
  </Step>

  <Step title="Paris ouverts">
    Les utilisateurs envoient des Payments XRP taggés vers le compte de pool. counsel lit l'historique des transactions du compte de pool depuis le ledger et tient à jour en direct les pools d'issues et les cotes.
  </Step>

  <Step title="bet_cutoff atteint">
    Le pool se gèle. Toute mise arrivant au timestamp de fermeture ou après n'est pas comptée. La ligne de cotes finale est désormais fixée.
  </Step>

  <Step title="Résolution">
    Famille A : counsel lit l'oracle XLS-47 et publie l'issue on-chain. Famille B : l'opérateur publie une proposition, la fenêtre de contestation se déroule, et le comité multisigne l'issue finale.
  </Step>

  <Step title="Payouts">
    La répartition au prorata est calculée et envoyée sous forme de Payments XRP individuels multisignés par le comité à chaque gagnant. Les marchés annulés reçoivent à la place des Payments de remboursement intégral, sans frais.
  </Step>
</Steps>