Docs

Vue d'ensemble

XCP-69 est un standard de lancement de tokens à paramètres fixes, construit sur les pools de fairmint de Counterparty. Il n'y a ni contrat usine, ni clé d'administration, ni garde par la plateforme à aucun moment : le protocole est la plateforme. Chaque action — créer un lancement, minter, swapper — est une transaction que vous signez dans votre propre portefeuille et diffusez sur Bitcoin. Ce site est une interface sur des données publiques on-chain ; s'il disparaissait demain, chaque lancement, remboursement et pool continuerait de fonctionner exactement comme avant.

Chaque lancement XCP-69 est identique : 100M d'offre, vente publique de 69M à 0.01 XCP par lot de 1,000 tokens, 31M réservés au pool de liquidité, plafond de 10 XCP par adresse, une annonce préalable on-chain avant l'ouverture du mint, et une fenêtre de 1,000 blocs. Il n'y a pas de petites lignes à lire parce qu'il n'y a pas de petites lignes. Le jeu complet de paramètres se trouve sur la page Comment ça marche.

Mécanisme de lancement

Un lancement passe par quatre phases :

1. Annoncer. Chaque lancement se confirme on-chain avant son start_block. Tant que ce bloc n'est pas arrivé, le fairminter est pending et le consensus rejette chaque mint — personne, créateur compris, ne peut minter en avance. Il n'y a pas de lancement furtif : les conditions complètes sont on-chain, vérifiables, avant que le premier lot puisse être acheté.
2. Minter. Une fenêtre de 1,000 blocs (~7 jours) à partir de start_block. N'importe qui peut minter des lots entiers de 1,000 tokens à 0.01 XCP le lot, jusqu'à 1,000,000 de tokens (10 XCP) par adresse. Les XCP payés comme les tokens mintés restent sous séquestre à l'adresse indépensable — personne ne détient rien tant que le lancement n'est pas résolu. La durée de la fenêtre ne fait que retarder l'échec : une vente complète se règle à l'instant où elle se remplit, tandis qu'un échec libère les XCP de chaque minteur en une semaine environ.
3. Résoudre. Tout ou rien au soft cap de 69M. Le soft cap égale toute la vente publique, donc l'atteindre est tout vendre — il n'y a pas de succès partiel. Si tout est vendu, le pool est créé ; si l'échéance est manquée, le protocole rembourse automatiquement chaque minteur et détruit l'offre sous séquestre. La résolution a lieu en fin de bloc même lorsque le hard cap est atteint, personne ne peut donc trader sur le pool dans la transaction qui le crée.
4. Trader. Les 690 XCP levés plus les 31M de tokens réservés créent un pool AMM TOKEN/XCP. Les tokens LP sont mintés directement à l'adresse indépensable — la liquidité est verrouillée par le consensus, définitivement. L'offre et la description se verrouillent dans le même bloc, et le trading démarre immédiatement.

Trading et formation du prix

Les tokens gradués s'échangent contre un pool TOKEN/XCP à produit constant. Le prix est simplement le rapport des réserves du pool ; chaque swap le déplace. Des frais fixes de 50 bps sur chaque swap sont versés au pool lui-même — et comme la LP est brûlée, les frais épaississent la liquidité verrouillée au lieu de payer qui que ce soit.

Le pool ouvre avec 690 XCP contre 31M de tokens : 69/31 ≈ 2.23× le prix de mint. Chaque minteur est structurellement en profit à l'ouverture, et c'est le pool — pas les acheteurs suivants — qui absorbe les sorties précoces.

L'ordre DEX de Counterparty est l'unique primitive de trading : l'appariement passe par le pool dès que le prix du pool bat le carnet d'ordres. Un ordre au marché est un ordre au montant de sortie coté par le routeur — il s'exécute immédiatement contre le pool et le carnet, au meilleur prix. Un ordre limite attend dans le carnet, et le pool l'exécute automatiquement si son prix vient à croiser le vôtre.

Prix

Réserve de XCP ÷ réserve de tokens. Bouge à chaque swap ; il n'y a ni carnet d'ordres ni teneur de marché.

Cap.

Prix du pool × offre en circulation (émise moins brûlée). Une convention, pas une promesse — le pool ne pourrait pas la payer.

Impact sur le prix

De combien votre propre swap déplace le prix. Les swaps plus importants contre des réserves fixes obtiennent un prix moyen moins bon.

Slippage

La différence entre le prix coté et celui qui s'exécute, si le pool bouge entre votre cotation et votre confirmation.

Graduation

Sur les autres launchpads, la graduation est un seuil à l'intérieur d'un marché en direct : le token s'échange sur une courbe pendant que tout le monde espère qu'il atteigne le nombre magique. La graduation XCP-69 est binaire et a lieu avant tout trading. Vendez les 69M en 1,000 blocs et le lancement est gradué — pool créé, LP brûlée, offre verrouillée, trading actif dans la phase de résolution du même bloc. Manquez-le et le lancement ne s'échange jamais.

Les remboursements ne sont pas une démarche auprès du support. C'est le comportement automatique du protocole : à l'échéance, les XCP de chaque minteur sont rendus et l'offre sous séquestre est détruite dans le même bloc. Les lancements ratés passent au cimetière, où leur histoire est conservée — l'historique des mints, le nombre de participants et la preuve on-chain : un enregistrement de destruction étiqueté "soft cap not reached".

Frais

Il n'y a pas de tableau de partage des frais parce qu'il n'y a pas de frais à partager. Chaque satoshi de XCP payé par les minteurs va dans le pool. Les seuls coûts dans tout le système sont les frais de transaction Bitcoin, les frais d'enregistrement de nom d'actif de 0.5 XCP pour les actifs nommés, et les frais de gas du pooldeposit du protocole, débités à la création — des coûts payés au réseau, pas à nous ni au créateur.

Avertissements sur les risques

Le standard supprime le rug pull et la prémine. Il ne supprime pas le risque, et nous ne ferons pas semblant du contraire :

• Le plafond par adresse résiste aux Sybil par le coût seulement, pas par principe. Le plafond est par adresse, pas par personne. Il renchérit la simulation d'une foule de 69 ; il ne peut pas l'empêcher.
• Les remboursements rendent une quantité de XCP, pas une valeur en fiat. Si le prix du XCP bouge pendant la fenêtre d'environ 7 jours, le remboursement vous rend votre mise en XCP seulement.
• La prime d'ouverture de 2.23× est structurelle, pas une garantie de prix. Le plancher du pool s'érode à mesure que les gens lui vendent. Rien n'empêche un token de s'échanger sous le prix de mint.
• Le visuel du token n'est on-chain que si le créateur le décide. Par défaut, la chaîne conserve définitivement l'URL du JSON d'informations de l'actif (via lock_description), tandis que l'image et les informations sont hébergées hors chaîne et ne peuvent être modifiées que par le propriétaire on-chain actuel de l'actif, avec un message signé depuis son portefeuille. Si cet hébergement disparaissait, l'économie du token — offre, pool, remboursements — resterait intacte ; seule l'illustration serait perdue. Les créateurs qui lancent depuis un portefeuille Taproot peuvent supprimer entièrement cette dépendance en inscrivant l'image on-chain comme description permanente.

Réseau

• Chaîne : Counterparty sur le mainnet Bitcoin. Les lancements XCP-69 sont des transactions Bitcoin ordinaires qui transportent des messages Counterparty.
• Base de l'API : https://api.counterparty.io:4000/v2 — ou faites tourner votre propre nœud counterparty-core pour des lectures sans tiers de confiance.
• Fonctionnalité du protocole : fairmint_pool, activée sur le mainnet au bloc 961,100 (2026-08-05). Nécessite core v11.2.0 ou plus.

Format du message

Les lancements utilisent le message fairminter (ID 90) avec les champs de pool pool_quantity et lp_asset renseignés. Les mints sont des messages fairmint ordinaires, en multiples de lots entiers de quantity_by_price.

Un piège d'intégration à connaître : Counterparty Core 11.3+ renvoie pool_quantity_normalized et max_mint_per_address_normalized avec verbose=true. Utilisez-les pour l'affichage, mais gardez les calculs de conformité au standard en entiers bruts en satoshis (×10⁸) pour que les comparaisons restent exactes et concordent avec les données d'événements et de mempool sans verbose.

Composer des transactions

L'API compose renvoie une transaction Bitcoin brute non signée — le nœud ne voit jamais de clé. Signez avec votre propre portefeuille, diffusez, c'est fait. Ajoutez verbose=true pour obtenir un PSBT et le rappel des paramètres ; chaque quantité est un entier brut.

# Compose an XCP-69 launch (unsigned tx back; sign + broadcast yourself).
# START = a future block: the pre-announcement window. The launch must
# CONFIRM before START or it opens instantly and fails conformance.
curl -G "https://api.counterparty.io:4000/v2/addresses/$ISSUER/compose/fairminter" \
  --data-urlencode "asset=MYTOKEN" \
  --data-urlencode "price=1000000" \
  --data-urlencode "quantity_by_price=100000000000" \
  --data-urlencode "hard_cap=10000000000000000" \
  --data-urlencode "soft_cap=6900000000000000" \
  --data-urlencode "pool_quantity=3100000000000000" \
  --data-urlencode "lp_asset=$LP_NAME" \  # any unissued numeric; house style: 69…69, ≡69 (mod 97)
  --data-urlencode "max_mint_per_address=100000000000000" \
  --data-urlencode "max_mint_per_tx=100000000000000" \
  --data-urlencode "start_block=$START" \
  --data-urlencode "soft_cap_deadline_block=$((START + 1000))" \
  --data-urlencode "end_block=0" \
  --data-urlencode "premint_quantity=0" \
  --data-urlencode "minted_asset_commission=0" \
  --data-urlencode "burn_payment=false" \
  --data-urlencode "lock_quantity=true" \
  --data-urlencode "lock_description=true" \
  --data-urlencode "divisible=true" \
  --data-urlencode "description=https://…/MYTOKEN.json" \
  --data-urlencode "sat_per_vbyte=$FEE_RATE" \
  --data-urlencode "verbose=true"

Le consensus impose la cohérence du standard dès l'analyse du message : soft_cap doit être égal à hard_cap − premint − pool_quantity dès que pool_quantity > 0 — le tout ou rien est une règle du protocole, pas une politique du site. L'adresse de l'émetteur doit détenir sur le registre les frais d'enregistrement du nom de 0.5 XCP plus les frais de gas du pooldeposit ; les deux sont débités à la confirmation, le règlement ultérieur ne coûte donc rien. Choisissez lp_asset avec un vrai aléa : l'émission numérique est gratuite, et un nom prévisible permet à n'importe qui de l'enregistrer avant vous, entre la diffusion et la confirmation, ce qui invalide le lancement.

# Compose a mint. quantity is the TOKEN amount (raw, whole lots) —
# the XCP price is computed by consensus and debited from the minter's
# on-ledger XCP balance; nothing rides in the Bitcoin outputs.
curl -G "https://api.counterparty.io:4000/v2/addresses/$MINTER/compose/fairmint" \
  --data-urlencode "asset=MYTOKEN" \
  --data-urlencode "quantity=100000000000000" \
  --data-urlencode "sat_per_vbyte=$FEE_RATE"

# Issuer-side XCP cost of the pool settlement (prepaid at creation):
curl "https://api.counterparty.io:4000/v2/addresses/$ISSUER/compose/pooldeposit/estimatexcpfees"

Les mints doivent être des multiples de lots entiers de quantity_by_price, dans la limite du plafond par transaction et du reliquat de l'adresse — un plafond partiellement utilisé peut être complété sur plusieurs transactions. Le minteur a besoin des XCP sur leur solde Counterparty ; un portefeuille approvisionné en BTC mais sans XCP échouera à la composition avec "insufficient XCP balance".

Conformité

Core n'a aucun marqueur du standard on-chain, la conformité est donc un prédicat : l'égalité exacte avec les valeurs brutes fixes du standard. C'est la fonction réelle que ce site exécute — un lancement la passe, ou n'est pas XCP-69.

export const XCP69 = {
  /** 100M supply */
  HARD_CAP: 10_000_000_000_000_000,
  /** 69M public sale — reaching it IS selling out (all-or-nothing) */
  SOFT_CAP: 6_900_000_000_000_000,
  /** 31M seeded into the TOKEN/XCP pool at close, LP burned */
  POOL_QUANTITY: 3_100_000_000_000_000,
  /** 1,000-token lots */
  QUANTITY_BY_PRICE: 100_000_000_000,
  /** 0.01 XCP per lot */
  PRICE: 1_000_000,
  /** 1M tokens = 10 XCP per address; 69M ÷ 1M = 69 participants */
  MAX_MINT_PER_ADDRESS: 100_000_000_000_000,
  MAX_MINT_PER_TX: 100_000_000_000_000,
  /** Mint window: soft_cap_deadline_block − start_block, exactly (~7 days) */
  DEADLINE_BLOCKS: 1_000,
} as const;

/** core's block_index sentinel for unconfirmed transactions */
const MEMPOOL_BLOCK_INDEX = 9_999_999;

export function isXcp69(fm: Fairminter): boolean {
  return (
    (fm.status === "pending" || fm.status === "open" || fm.status === "closed") &&
    fm.pool_quantity === XCP69.POOL_QUANTITY &&
    fm.soft_cap === XCP69.SOFT_CAP &&
    fm.hard_cap === XCP69.HARD_CAP &&
    fm.quantity_by_price === XCP69.QUANTITY_BY_PRICE &&
    fm.price === XCP69.PRICE &&
    fm.max_mint_per_address === XCP69.MAX_MINT_PER_ADDRESS &&
    fm.max_mint_per_tx === XCP69.MAX_MINT_PER_TX &&
    fm.premint_quantity === 0 &&
    (fm.minted_asset_commission_int ?? 0) === 0 &&
    fm.lock_quantity &&
    fm.lock_description &&
    fm.divisible &&
    !fm.burn_payment &&
    !fm.asset.startsWith("A") && // named assets only
    // timing: scheduled start, fixed window, no end_block
    fm.start_block > 0 &&
    fm.end_block === 0 &&
    (fm.confirmed === false ||
      fm.block_index >= MEMPOOL_BLOCK_INDEX || // unconfirmed sentinel
      fm.start_block > fm.block_index) &&      // confirmed before start
    (fm.status === "closed"
      // core rewrites the deadline to the fill block on early sell-out
      ? fm.soft_cap_deadline_block <= fm.start_block + XCP69.DEADLINE_BLOCKS
      : fm.soft_cap_deadline_block === fm.start_block + XCP69.DEADLINE_BLOCKS)
  );
}

La clause de commission est celle que les vérifications naïves ratent. Le protocole permet à un fairminter de reverser jusqu'à 99% de chaque mint au créateur — une prémine avec des étapes en plus — et aucun autre champ ne le détecte. XCP-69 exige qu'elle soit exactement 0.

Les clauses de calendrier sont les deux inégalités délibérées. Le consensus n'exige pas un début futur — un lancement confirmé en retard ouvre simplement sur-le-champ — la garantie d'annonce préalable vit donc ici : start_block doit dépasser le bloc de confirmation. Sans cette clause, un créateur pourrait diffuser en retard une vente nominale de 1,000 blocs, la confirmer juste avant sa propre échéance et exécuter un mint d'initié quasi instantané derrière des métadonnées à mille blocs. Et sur la ligne du fairminter, la vérification de la fenêtre se relâche en ≤ une fois fermé, parce que core réécrit l'échéance en cas de vente anticipée — pour les lancements fermés, ce site rétablit l'égalité exacte à partir de l'événement immuable NEW_FAIRMINTER (voir le piège dans Lire l'état). Tout le reste est une égalité exacte sur la ligne.

Événements on-chain

Le cycle de vie complet s'observe sous forme d'événements Counterparty via GET /v2/events/<EVENT> :

Lire l'état

Tout s'interroge avec curl. Lancements et mints :

# All fairminters currently minting (filter with isXcp69 client-side)
curl "https://api.counterparty.io:4000/v2/fairminters?status=open&verbose=true"

# Every mint into one launch
curl "https://api.counterparty.io:4000/v2/fairminters/<TX_HASH>/fairmints"

Pools, prix et cotations :

# Pool state (reserves) — a row here means the launch graduated
curl "https://api.counterparty.io:4000/v2/pools/<ASSET>/XCP"

# Price series: one row per reserve mutation
curl "https://api.counterparty.io:4000/v2/pools/<ASSET>/XCP/price_history"

# Swap quote for a given input quantity (raw integer)
curl "https://api.counterparty.io:4000/v2/pools/<ASSET>/XCP/quote?quantity=100000000"

Détenteurs :

# Holders — the unspendable address appears holding the burned LP
curl "https://api.counterparty.io:4000/v2/assets/<ASSET>/holders"

Recette pour détecter le cycle de vie. Succès et échec se terminent tous deux avec le fairminter en statut closed, c'est donc la ligne du pool qui les distingue :

• pending → programmé
• open → mint en cours
• closed + /v2/pools/<ASSET>/XCP renvoie un pool → gradué
• closed sans ligne de pool → remboursé (à corroborer avec la destruction étiquetée "soft cap not reached")

Second piège d'intégration : soft_cap_deadline_block est réécrit lorsqu'un lancement se vend en avance — core l'avance au bloc de remplissage pour que le pool soit créé dans la phase de fin de ce bloc. Sur un enregistrement fermé, le champ est le bloc de règlement, pas l'échéance d'origine. Les comptes à rebours n'ont de sens que tant que le statut est open. La valeur d'origine survit dans l'historique d'événements, en ajout seul : GET /v2/transactions/<tx_hash>/events/NEW_FAIRMINTER renvoie les valeurs d'origine (la réécriture est un événement FAIRMINTER_UPDATE distinct), et c'est ainsi que ce site vérifie la fenêtre exacte des lancements fermés.

Lancement de référence

Support et conditions

Toutes les données affichées sur ce site sont des données publiques on-chain ; tout ce que vous voyez ici, vous pouvez le vérifier vous-même auprès d'un nœud Counterparty. Le site est une interface, pas une contrepartie à une quelconque transaction — il ne détient jamais de fonds et ne peut rien annuler, accélérer ou rembourser (le protocole gère les remboursements tout seul). Rien ici n'est un conseil en investissement ; les tokens lancés via XCP-69 peuvent perdre de la valeur, et en perdront. Lisez les avertissements sur les risques avant de minter.