Docs

Todo sobre XCP-69, en un solo lugar. La primera mitad explica cómo funcionan los lanzamientos, para cualquiera. La segunda es para desarrolladores que quieran leer o construir sobre los mismos datos de la cadena que usa este sitio.

Resumen

XCP-69 es un estándar de lanzamiento de tokens con parámetros fijos, construido sobre los pools de fairmint de Counterparty. No hay contrato fábrica, ni llave de administrador, ni custodia de la plataforma en ningún momento: el protocolo es la plataforma. Cada acción — crear un lanzamiento, acuñar, intercambiar — es una transacción que firmas en tu propia billetera y transmites a Bitcoin. Este sitio es una interfaz sobre datos públicos de la cadena; si desapareciera mañana, cada lanzamiento, reembolso y pool seguiría funcionando exactamente igual.

Todos los lanzamientos XCP-69 son idénticos: 100M de suministro, venta pública de 69M a 0.01 XCP por lote de 1,000 tokens, 31M reservados para el pool de liquidez, tope de 10 XCP por dirección, un anuncio previo en la cadena antes de que abra la acuñación y una ventana de 1,000 bloques. No hay letra chica que leer porque no hay letra chica. El conjunto completo de parámetros está en la página de Cómo funciona.

Mecanismo de lanzamiento

El orden invertido: en la mayoría de las plataformas de lanzamiento, la negociación empieza al instante y la multitud llega después, si es que llega. XCP-69 lo invierte — no se puede negociar hasta que la comunidad haya financiado el lanzamiento por completo. El tope de 10 XCP por dirección hace que la venta de 69M sea inalcanzable sin al menos 69 direcciones distintas. Por construcción, ningún token se negocia antes de que una multitud real lo haya pagado.

Un lanzamiento pasa por cuatro fases:

Anunciar. Cada lanzamiento se confirma en la cadena antes de su start_block. Hasta que llega ese bloque el fairminter está pending y el consenso rechaza cada acuñación — nadie, ni siquiera el creador, puede acuñar antes de tiempo. No hay lanzamientos sigilosos: los términos completos están en la cadena, a la vista, antes de que se pueda comprar el primer lote.
Acuñar. Una ventana de 1,000 bloques (~7 días) desde start_block. Cualquiera puede acuñar lotes enteros de 1,000 tokens a 0.01 XCP por lote, hasta 1,000,000 de tokens (10 XCP) por dirección. Tanto el XCP pagado como los tokens acuñados quedan en custodia en la dirección no gastable — nadie tiene nada hasta que el lanzamiento se resuelve. La duración de la ventana solo retrasa el fracaso: si se agota, se liquida en el momento en que se completa; si no llega, el XCP de cada acuñador queda libre en cuestión de una semana.
Resolver. Todo o nada en el soft cap de 69M. El soft cap equivale a toda la venta pública, así que alcanzarlo es agotarla — no hay éxito parcial. Si se agota, se crea el pool; si vence el plazo, el protocolo reembolsa a cada acuñador automáticamente y destruye el suministro en custodia. La resolución ocurre al final del bloque incluso cuando se llena el hard cap, así que nadie puede negociar en el pool dentro de la transacción que lo crea.
Negociar. Los 690 XCP recaudados más los 31M de tokens reservados crean un pool AMM TOKEN/XCP. Los tokens LP se acuñan directamente en la dirección no gastable — la liquidez queda bloqueada por consenso, para siempre. El suministro y la descripción se bloquean en el mismo bloque, y la negociación arranca de inmediato.

Negociación y precios

Los tokens graduados se negocian contra un pool TOKEN/XCP de producto constante. El precio es simplemente la razón entre las reservas del pool; cada swap lo mueve. Una comisión fija de 50 bps por swap se paga al propio pool — y como el LP está quemado, las comisiones engrosan la liquidez bloqueada en vez de pagarle a alguien.

El pool abre con 690 XCP contra 31M de tokens: 69/31 ≈ 2.23× el precio de acuñación. Cada acuñador está estructuralmente en ganancia al abrir, y el pool — no los compradores posteriores — absorbe las salidas tempranas.

La orden del DEX de Counterparty es la única primitiva de negociación: el emparejamiento pasa por el pool siempre que el precio del pool supere al libro de órdenes. Una orden de mercado es una orden al precio de salida cotizado por el enrutador — se ejecuta de inmediato contra el pool y el libro al mejor precio. Una orden límite espera en el libro, y el pool la ejecuta automáticamente si su precio llega a cruzar el tuyo.

Precio: Reserva de XCP ÷ reserva de tokens. Se mueve con cada swap; no hay libro de órdenes ni creador de mercado.
Cap. de mercado: Precio del pool × suministro en circulación (emitido menos quemado). Una convención, no una promesa — el pool no podría pagarlo.
Impacto en el precio: Cuánto mueve el precio tu propio swap. Los swaps más grandes contra las reservas fijas obtienen un peor precio promedio.
Deslizamiento: La diferencia entre el precio cotizado y el que se ejecuta, si el pool se mueve entre tu cotización y tu confirmación.

Graduación

En otras plataformas de lanzamiento, la graduación es un umbral dentro de un mercado en vivo: el token se negocia sobre una curva mientras todos esperan que llegue al número mágico. La graduación en XCP-69 es binaria y ocurre antes de que exista cualquier negociación. Agota la venta de 69M en 1,000 bloques y el lanzamiento se gradúa — pool creado, LP quemado, suministro bloqueado, negociación activa en la fase de resolución del mismo bloque. Si no llega, el lanzamiento nunca se negocia.

Los reembolsos no son un trámite de soporte. Son comportamiento automático del protocolo: al vencer el plazo, el XCP de cada acuñador se devuelve y el suministro en custodia se destruye en el mismo bloque. Los lanzamientos fallidos pasan al cementerio, donde se conserva su historia — la cinta de acuñaciones, el número de participantes y la prueba en la cadena: un registro de destrucción etiquetado "soft cap not reached".

Comisiones

Creator's share of the 690 XCP raise: 0%
Protocol / platform share of the raise: 0%
Premine or mint commission to the creator: 0
LP tokens: burned at the unspendable address, forever
Swap fee after launch: 50 bps, paid to the pool (the LP is burned, so it deepens locked liquidity)

No hay tabla de reparto de comisiones porque no hay comisiones que repartir. Cada satoshi de XCP que pagan los acuñadores va al pool. Los únicos costos en todo el sistema son las comisiones de transacción de Bitcoin, la comisión de registro de nombre de 0.5 XCP para activos con nombre y la comisión de gas del pooldeposit del protocolo, debitada al crear — costos que se pagan a la red, no a nosotros ni al creador.

Advertencias de riesgo

El estándar elimina el rug pull y el preminado. No elimina el riesgo, y no vamos a fingir lo contrario:

El tope por dirección es resistente a Sybil solo en costo, no en principio. El tope es por dirección, no por persona. Encarece fingir una multitud de 69; no puede impedirla.
Los reembolsos devuelven cantidad de XCP, no valor en moneda fiat. Si el precio de XCP se mueve durante la ventana de ~7 días, el reembolso te deja como estabas solo en términos de XCP.
La prima de apertura de 2.23× es estructural, no una garantía de precio. El piso del pool baja a medida que la gente le vende. Nada impide que un token se negocie por debajo del precio de acuñación.
El arte del token está en la cadena solo si el creador así lo decide. Por defecto la cadena guarda para siempre la URL del JSON con la información del activo (mediante lock_description), mientras que la imagen y la información se alojan fuera de la cadena y solo puede editarlas el dueño actual del activo en la cadena, con un mensaje firmado desde su billetera. Si ese alojamiento desapareciera, la economía del token — suministro, pool, reembolsos — quedaría intacta; solo se perdería el arte. Los creadores que lanzan desde una billetera Taproot pueden eliminar la dependencia por completo inscribiendo la imagen en la cadena como descripción permanente.

Integración

Todo lo que muestra este sitio sale de APIs públicas. Puedes construir tu propia plataforma de lanzamiento, bot o panel con los mismos datos — nada de lo que sigue requiere nuestro permiso.

Red

Cadena: Counterparty en la mainnet de Bitcoin. Los lanzamientos XCP-69 son transacciones normales de Bitcoin que llevan mensajes de Counterparty.
Base de la API: https://api.counterparty.io:4000/v2 — o corre tu propio nodo de counterparty-core para lecturas sin confianza en terceros.
Función del protocolo: fairmint_pool, activados en mainnet en el bloque 961,100 (2026-08-05). Requiere core v11.2.0 o superior.

Formato del mensaje

Los lanzamientos usan el mensaje fairminter (ID 90) con los campos de pool pool_quantity y lp_asset definidos. Las acuñaciones son mensajes fairmint normales en múltiplos de lotes enteros de quantity_by_price.

Una trampa de integración que conviene conocer: Counterparty Core 11.3+ devuelve pool_quantity_normalized y max_mint_per_address_normalized con verbose=true. Úsalos para mostrar, pero mantén los cálculos de conformidad con el estándar en enteros brutos en satoshis (×10⁸), para que las comparaciones sigan siendo exactas y coincidan con los datos de eventos y mempool sin verbose.

Componer transacciones

La API de compose devuelve una transacción de Bitcoin en bruto sin firmar — el nodo nunca ve una llave. Firma con tu propia billetera, transmite, listo. Agrega verbose=true para obtener un PSBT y los parámetros de vuelta; cada cantidad es un entero en bruto.

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

El consenso impone la coherencia del estándar al interpretar el mensaje: soft_cap debe ser igual a hard_cap − premint − pool_quantity siempre que pool_quantity > 0 — el todo o nada es una regla del protocolo, no una política del sitio. La dirección del emisor debe tener en el libro mayor la comisión de registro de nombre de 0.5 XCP más la comisión de gas del pooldeposit; ambas se debitan al confirmar, así que la liquidación posterior no cuesta nada. Elige lp_asset con aleatoriedad real: la emisión numérica es gratis, y un nombre predecible permite que cualquiera lo registre antes, entre la transmisión y la confirmación, invalidando el lanzamiento.

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

Las acuñaciones deben ser múltiplos de lotes enteros de quantity_by_price, dentro del tope por transacción y dentro del cupo restante de la dirección — un tope usado parcialmente se puede completar en varias transacciones. El acuñador necesita el XCP en su saldo de Counterparty; una billetera con BTC pero sin XCP fallará al componer con "insufficient XCP balance".

Conformidad

Core no tiene ningún marcador del estándar en la cadena, así que la conformidad es un predicado: igualdad exacta contra los valores brutos fijos del estándar. Esta es la función real que corre este sitio — un lanzamiento la pasa o no es 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 cláusula de comisión es la que las verificaciones ingenuas pasan por alto. El protocolo permite que un fairminter desvíe hasta el 99% de cada acuñación al creador — un preminado con pasos extra — y ningún otro campo lo detecta. XCP-69 exige que sea exactamente 0.

Las cláusulas de tiempo son las dos desigualdades deliberadas. El consenso no exige un inicio futuro — un lanzamiento que se confirma tarde simplemente abre al instante — así que la garantía del anuncio previo vive aquí: start_block debe ser mayor que el bloque de confirmación. Sin esa cláusula, un creador podría transmitir tarde una venta nominal de 1,000 bloques, confirmarla justo antes de su propio plazo y ejecutar una acuñación interna casi instantánea escondida tras metadatos de mil bloques. Y en la fila del fairminter la verificación de la ventana se relaja a ≤ una vez cerrado, porque core reescribe el plazo cuando se agota antes de tiempo — para los lanzamientos cerrados este sitio restaura la igualdad exacta a partir del evento inmutable NEW_FAIRMINTER (ver la trampa en Leer el estado). Todo lo demás es igualdad exacta sobre la fila.

Eventos en la cadena

El ciclo de vida completo se puede observar como eventos de Counterparty a través de GET /v2/events/<EVENT>:

NEW_FAIRMINTER: a launch is created
NEW_FAIRMINT: someone mints (also visible in the mempool before confirmation)
OPEN_POOL: the launch graduated — the TOKEN/XCP pool was seeded
POOL_MATCH: a swap executed against the pool
ASSET_DESTRUCTION: escrowed supply destroyed — on a missed soft cap, tagged “soft cap not reached”

Leer el estado

Todo se puede consultar con curl. Lanzamientos y acuñaciones:

# 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, precios y cotizaciones:

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

Holders:

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

Receta para detectar el ciclo de vida. Tanto el éxito como el fracaso terminan con el fairminter en estado closed, así que la fila del pool es lo que los distingue:

pending → programado
open → acuñando
closed + /v2/pools/<ASSET>/XCP devuelve un pool → graduado
closed sin fila de pool → reembolsado (corrobóralo con la destrucción etiquetada "soft cap not reached")

Segunda trampa de integración: soft_cap_deadline_block se reescribe cuando un lanzamiento se agota antes de tiempo — core lo adelanta al bloque en que se completó, para que el pool se cree en la fase de fin de bloque de ese mismo bloque. En un registro cerrado, el campo es el bloque de liquidación, no el plazo original. Las cuentas regresivas solo tienen sentido mientras el estado es open. El valor original sobrevive en el historial de eventos, que solo admite anexos: GET /v2/transactions/<tx_hash>/events/NEW_FAIRMINTER devuelve los valores originales (la reescritura es un evento FAIRMINTER_UPDATE aparte), y así es como este sitio verifica la ventana exacta de los lanzamientos cerrados.

Lanzamiento de referencia

Los pools de fairmint se activaron el 2026-08-05 y todavía no existe ningún lanzamiento XCP-69. El primero quedará enlazado aquí como token de referencia — el registro canónico contra el cual validar tu integración: su fila de fairminter debería pasar el predicado de arriba, su cinta de acuñaciones debería mostrar ≥69 direcciones distintas y su fila de pool debería mostrar el LP quemado en la dirección no gastable.

Soporte y términos

Todos los datos que muestra este sitio son datos públicos de la cadena; cualquier cosa que veas aquí puedes verificarla tú mismo contra un nodo de Counterparty. El sitio es una interfaz, no una contraparte de ninguna transacción — nunca custodia fondos y no puede revertir, acelerar ni reembolsar nada (el protocolo se encarga de los reembolsos por sí solo). Nada de esto es asesoría de inversión; los tokens lanzados con XCP-69 pueden perder valor y lo perderán. Lee las advertencias de riesgo antes de acuñar.