Docs

Visão geral

O XCP-69 é um padrão de lançamento de tokens com parâmetros fixos, construído sobre os pools de fairmint do Counterparty. Não há contrato fábrica, nem chave de administrador, nem custódia da plataforma em momento algum: o protocolo é a plataforma. Toda ação — criar um lançamento, mintar, fazer swap — é uma transação que você assina na sua própria carteira e transmite para o Bitcoin. Este site é uma interface sobre dados públicos on-chain; se ele sumisse amanhã, cada lançamento, reembolso e pool continuaria funcionando exatamente como antes.

Todo lançamento XCP-69 é idêntico: 100M de fornecimento, venda pública de 69M a 0.01 XCP por lote de 1,000 tokens, 31M reservados para o pool de liquidez, limite de 10 XCP por endereço, um anúncio prévio on-chain antes de o mint abrir e uma janela de 1,000 blocos. Não há letras miúdas para ler porque não há letras miúdas. O conjunto completo de parâmetros está na página de Como funciona.

Mecanismo de lançamento

Um lançamento passa por quatro fases:

1. Anunciar. Todo lançamento é confirmado on-chain antes do seu start_block. Até esse bloco chegar, o fairminter fica pending e o consenso rejeita todo mint — ninguém, nem o criador, consegue mintar antes da hora. Não existe lançamento furtivo: os termos completos ficam on-chain, à vista de todos, antes que o primeiro lote possa ser comprado.
2. Mintar. Uma janela de 1,000 blocos (~7 dias) a partir de start_block. Qualquer um pode mintar lotes inteiros de 1,000 tokens a 0.01 XCP por lote, até 1,000,000 de tokens (10 XCP) por endereço. Tanto o XCP pago quanto os tokens mintados ficam em custódia no endereço não gastável — ninguém segura nada até o lançamento se resolver. A duração da janela só adia o fracasso: se esgotar, liquida no momento em que preenche; se não chegar lá, o XCP de cada minter é liberado em cerca de uma semana.
3. Resolver. Tudo ou nada no soft cap de 69M. O soft cap equivale à venda pública inteira, então alcançá-lo é esgotar — não existe sucesso parcial. Esgotou, o pool é criado; perdeu o prazo, o protocolo reembolsa cada minter automaticamente e destrói o fornecimento em custódia. A resolução acontece no fim do bloco mesmo quando o hard cap é preenchido, então ninguém consegue negociar no pool dentro da transação que o cria.
4. Negociar. Os 690 XCP arrecadados mais os 31M de tokens reservados criam um pool AMM TOKEN/XCP. Os tokens LP são mintados direto no endereço não gastável — a liquidez fica travada por consenso, permanentemente. Fornecimento e descrição travam no mesmo bloco, e a negociação começa na hora.

Negociação e preços

Tokens graduados são negociados contra um pool TOKEN/XCP de produto constante. O preço é simplesmente a razão entre as reservas do pool; cada swap o move. Uma taxa fixa de 50 bps em cada swap é paga ao próprio pool — e como o LP está queimado, as taxas engrossam a liquidez travada em vez de pagar alguém.

O pool abre com 690 XCP contra 31M de tokens: 69/31 ≈ 2.23× o preço de mint. Todo minter está estruturalmente no lucro na abertura, e o pool — não os compradores posteriores — absorve as saídas antecipadas.

A ordem da DEX do Counterparty é a única primitiva de negociação: o casamento passa pelo pool sempre que o preço do pool supera o livro de ofertas. Uma ordem a mercado é uma ordem no valor de saída cotado pelo roteador — ela executa na hora contra o pool e o livro ao melhor preço. Uma ordem limite fica no livro, e o pool a executa automaticamente se o preço dele um dia cruzar o seu.

Preço

Reserva de XCP ÷ reserva de tokens. Move a cada swap; não há livro de ofertas nem formador de mercado.

Cap. de mercado

Preço do pool × fornecimento em circulação (emitido menos queimado). Uma convenção, não uma promessa — o pool não conseguiria pagar isso.

Impacto no preço

Quanto o seu próprio swap move o preço. Swaps maiores contra as reservas fixas conseguem um preço médio pior.

Slippage

A diferença entre o preço cotado e o que executa, se o pool se mover entre a sua cotação e a sua confirmação.

Graduação

Em outras launchpads, a graduação é um limiar dentro de um mercado ao vivo: o token é negociado numa curva enquanto todo mundo torce para ele chegar ao número mágico. A graduação no XCP-69 é binária e acontece antes de existir qualquer negociação. Esgote a venda de 69M em 1,000 blocos e o lançamento gradua — pool criado, LP queimado, fornecimento travado, negociação ativa na fase de resolução do mesmo bloco. Não chegou lá, o lançamento nunca é negociado.

Reembolsos não são um processo de suporte. São comportamento automático do protocolo: no prazo final, o XCP de cada minter é devolvido e o fornecimento em custódia é destruído no mesmo bloco. Lançamentos fracassados vão para o cemitério, onde a história deles é preservada — a fita de mints, o número de participantes e a prova on-chain: um registro de destruição marcado como "soft cap not reached".

Taxas

Não existe tabela de divisão de taxas porque não há taxas para dividir. Cada satoshi de XCP pago pelos minters vai para o pool. Os únicos custos em todo o sistema são as taxas de transação do Bitcoin, a taxa de registro de nome de 0.5 XCP para ativos nomeados e a taxa de gas do pooldeposit do protocolo, debitada na criação — custos pagos à rede, não a nós nem ao criador.

Avisos de risco

O padrão elimina o rug pull e a pré-mineração. Ele não elimina o risco, e não vamos fingir o contrário:

• O limite por endereço é resistente a Sybil só no custo, não no princípio. O limite é por endereço, não por pessoa. Ele encarece fingir uma multidão de 69; não consegue impedir.
• Reembolsos devolvem quantidade de XCP, não valor em fiat. Se o preço do XCP se mover durante a janela de ~7 dias, o reembolso te deixa como estava apenas em termos de XCP.
• O prêmio de abertura de 2.23× é estrutural, não uma garantia de preço. O piso do pool cai conforme as pessoas vendem nele. Nada impede que um token seja negociado abaixo do preço de mint.
• A mídia do token só fica on-chain se o criador quiser. Por padrão, a chain guarda para sempre a URL do JSON com as informações do ativo (via lock_description), enquanto a imagem e as informações ficam hospedadas off-chain, editáveis apenas pelo dono on-chain atual do ativo, com uma mensagem assinada pela carteira. Se essa hospedagem sumisse, a economia do token — fornecimento, pool, reembolsos — ficaria intacta; só a arte seria afetada. Criadores que lançam de uma carteira Taproot podem eliminar a dependência por completo inscrevendo a imagem on-chain como descrição permanente.

Rede

• Chain: Counterparty na mainnet do Bitcoin. Lançamentos XCP-69 são transações comuns do Bitcoin carregando mensagens do Counterparty.
• Base da API: https://api.counterparty.io:4000/v2 — ou rode seu próprio nó counterparty-core para leituras sem depender de terceiros.
• Recurso do protocolo: fairmint_pool, ativado na mainnet no bloco 961,100 (2026-08-05). Requer core v11.2.0 ou superior.

Formato da mensagem

Lançamentos usam a mensagem fairminter (ID 90) com os campos de pool pool_quantity e lp_asset definidos. Mints são mensagens fairmint comuns em múltiplos de lotes inteiros de quantity_by_price.

Uma pegadinha de integração que vale conhecer: o Counterparty Core 11.3+ retorna pool_quantity_normalized e max_mint_per_address_normalized com verbose=true. Use-os para exibição, mas mantenha a matemática de conformidade com o padrão em inteiros brutos em satoshis (×10⁸), para que as comparações continuem exatas e batam com os dados de eventos e mempool sem verbose.

Compondo transações

A API de compose retorna uma transação bruta do Bitcoin não assinada — o nó nunca vê uma chave. Assine com sua própria carteira, transmita, pronto. Adicione verbose=true para receber um PSBT e os parâmetros de volta; toda quantidade é um inteiro 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"

O consenso impõe a coerência do padrão na hora de interpretar a mensagem: soft_cap precisa ser igual a hard_cap − premint − pool_quantity sempre que pool_quantity > 0 — o tudo ou nada é regra do protocolo, não política do site. O endereço do emissor precisa ter no ledger a taxa de registro de nome de 0.5 XCP mais a taxa de gas do pooldeposit; as duas são debitadas na confirmação, então a liquidação depois não custa nada. Escolha lp_asset com aleatoriedade de verdade: a emissão numérica é gratuita, e um nome previsível permite que qualquer um o registre antes, entre a transmissão e a confirmação, invalidando o lançamento.

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

Mints precisam ser múltiplos de lotes inteiros de quantity_by_price, dentro do limite por transação e dentro da cota restante do endereço — um limite usado parcialmente pode ser completado em várias transações. O minter precisa do XCP no saldo Counterparty deles; uma carteira com BTC mas sem XCP vai falhar na composição com "insufficient XCP balance".

Conformidade

O Core não tem nenhum marcador do padrão on-chain, então a conformidade é um predicado: igualdade exata com os valores brutos fixos do padrão. Esta é a função real que este site roda — um lançamento passa por ela ou não é 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)
  );
}

A cláusula de comissão é a que verificações ingênuas deixam passar. O protocolo permite que um fairminter desvie até 99% de cada mint de volta para o criador — uma pré-mineração com passos extras — e nenhum outro campo pega isso. O XCP-69 exige que seja exatamente 0.

As cláusulas de tempo são as duas desigualdades deliberadas. O consenso não exige um início futuro — um lançamento que confirma tarde simplesmente abre na hora — então a garantia do anúncio prévio mora aqui: start_block precisa ser maior que o bloco de confirmação. Sem essa cláusula, um criador poderia transmitir tarde uma venda nominal de 1,000 blocos, confirmar pouco antes do próprio prazo e rodar um mint interno quase instantâneo escondido atrás de metadados de mil blocos. E na linha do fairminter a verificação da janela relaxa para ≤ depois de fechado, porque o core reescreve o prazo quando esgota antes da hora — para lançamentos fechados este site restaura a igualdade exata a partir do evento imutável NEW_FAIRMINTER (veja a pegadinha em Lendo o estado). Todo o resto é igualdade exata na linha.

Eventos on-chain

O ciclo de vida completo pode ser observado como eventos do Counterparty via GET /v2/events/<EVENT>:

Lendo o estado

Tudo dá para consultar com curl. Lançamentos e 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, preços e cotações:

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

Receita para detectar o ciclo de vida. Sucesso e fracasso terminam ambos com o fairminter no status closed, então é a linha do pool que os distingue:

• pending → agendado
• open → mintando
• closed + /v2/pools/<ASSET>/XCP retorna um pool → graduado
• closed sem linha de pool → reembolsado (confirme com a destruição marcada como "soft cap not reached")

Segunda pegadinha de integração: soft_cap_deadline_block é reescrito quando um lançamento esgota antes da hora — o core o adianta para o bloco em que preencheu, para que o pool seja criado na fase de fim de bloco desse mesmo bloco. Em um registro fechado, o campo é o bloco de liquidação, não o prazo original. Contagens regressivas só fazem sentido enquanto o status é open. O valor original sobrevive no histórico de eventos, que só aceita acréscimos: GET /v2/transactions/<tx_hash>/events/NEW_FAIRMINTER retorna os valores originais (a reescrita é um evento FAIRMINTER_UPDATE separado), e é assim que este site verifica a janela exata dos lançamentos fechados.

Lançamento de referência

Suporte e termos

Todos os dados exibidos neste site são dados públicos on-chain; tudo o que você vê aqui pode ser verificado por você mesmo em um nó do Counterparty. O site é uma interface, não uma contraparte de nenhuma transação — ele nunca guarda fundos e não consegue reverter, acelerar nem reembolsar nada (o protocolo cuida dos reembolsos sozinho). Nada aqui é recomendação de investimento; tokens lançados via XCP-69 podem perder valor e vão perder. Leia os avisos de risco antes de mintar.