Feita para quem emite ativos, a rede Stellar tem um processo simples de criar e gerenciar um ativo. Por padrão, ela entrega um conjunto de recursos prontos que funcionam como blocos de construção, permitindo gerenciar todo o ciclo de vida de um ativo diretamente por operações nativas, também conhecidas como “Stellar Classic”.
No centro desse processo está a gestão da oferta em circulação de um ativo, feita por emissão e queima. Isso pode ser alcançado de formas diferentes, combinando essas operações nativas e abrindo espaço para vários casos de uso.
Com a nova plataforma Soroban, os recursos da rede serão ampliados ainda mais por smart contracts e uma camada extra de programabilidade. Neste artigo, o foco são as diferentes formas de gerenciar a oferta em circulação de um ativo usando apenas operações nativas do Stellar Classic.
Em fevereiro de 2024, a Stellar lançou o Protocol 20, que ativou o Soroban, a plataforma de smart contracts da rede. O Soroban não substitui as operações do Classic. Ele adiciona uma camada programável sobre elas, o que permite a emissores regulados, protocolos de DeFi e infraestrutura de stablecoin embutir lógica de compliance, controles multi-sig e hooks de composabilidade direto no processo de emissão e queima. Em 2026, quem emite ativos na Stellar tem dois conjuntos de ferramentas distintos.
O modelo de ativos da Stellar: trustlines e a conta emissora
Antes de entrar na mecânica de emissão e queima, vale estabelecer como funciona o modelo de ativos da Stellar, porque tudo que vem depois depende dele. Quando você cria um ativo na Stellar, duas coisas o definem: um código de ativo (por exemplo, USDX) e o endereço da conta emissora. A combinação desses dois identificadores é a impressão digital única do ativo. Duas contas não podem emitir ativos com o mesmo código, o token de cada emissor é distinto.
Qualquer conta que queira guardar ou transacionar o ativo precisa antes criar uma trustline, uma declaração explícita de que confia na conta emissora como autoridade por trás do ativo. Essa trustline cria um espaço na entrada de ledger da conta para aquele ativo e define um limite de saldo. Sem trustline, uma conta não consegue receber o ativo.
A própria conta emissora não pode criar uma trustline para o ativo dela. Essa é a restrição de design que faz o modelo de oferta funcionar: a conta emissora é a origem e o destino final. Unidades enviadas a partir dela são criadas. Unidades enviadas para ela são destruídas.
Boa prática: a conta de distribuição
A maioria dos emissores opera com uma segunda conta entre o emissor e os usuários finais: a conta de distribuição. O emissor emite para a conta de distribuição, que cuida de todas as operações voltadas ao usuário.
Essa separação tem dois benefícios: a chave privada da conta emissora pode ficar em cold storage, já que ela só precisa assinar transações de emissão, e erros operacionais na camada de distribuição não comprometem diretamente o mecanismo de emissão.
Leia mais: Tokenomics: descubra como emitir um token digital para resolver as necessidades do seu negócio
Cinco formas de emitir e queimar no Stellar Classic
1. Operações de pagamento
A abordagem mais simples e mais usada. Para emitir, a conta emissora envia um pagamento para qualquer conta que tenha trustline. Para queimar, qualquer conta envia um pagamento de volta para a conta emissora.
Source: Issuing Account → Destination: Distribution Account
Amount: 1,000,000 USDX
Operation: Payment
Effect: 1,000,000 USDX added to circulating supplyCode language: HTTP (http)Source: Any Account → Destination: Issuing Account
Amount: 500,000 USDX
Operation: Payment
Effect: 500,000 USDX removed from circulating supplyCode language: HTTP (http)Esse é o ponto de partida certo para a maioria dos emissores. É auditável, direto de implementar em qualquer SDK da Stellar e bem documentado nos guias oficiais para desenvolvedores da Stellar. A grande maioria dos ativos na Stellar usa operações de pagamento como mecanismo principal de gestão da oferta.
2. Claimable Balances
Claimable Balances quebram o processo de pagamento em duas etapas distintas e introduzem pré-condições antes de a transferência ser finalizada.
Quem envia, em cenários de emissão a conta emissora, aloca reservas criando um claimable balance e especificando as condições em que ele pode ser resgatado. As reservas ficam em escrow no ledger: elas existem, mas ainda não estão no saldo de quem recebe. Quando as condições são atendidas, o destinatário executa uma operação Claim Claimable Balance para receber os fundos.
As condições podem ser baseadas em tempo (CLAIM_PREDICATE_BEFORE_ABSOLUTE_TIME, CLAIM_PREDICATE_AFTER_ABSOLUTE_TIME), compostas (CLAIM_PREDICATE_AND, CLAIM_PREDICATE_OR) ou incondicionais (CLAIM_PREDICATE_UNCONDITIONAL).
Casos de uso em que Claimable Balances agregam valor em relação a pagamentos simples:
- Vesting de tokens: aloque oferta para pessoas do time ou investidores com condições de desbloqueio por tempo. Os tokens existem on-chain e são auditáveis, mas não podem ser resgatados antes da data de vesting.
- Airdrops regulados: emita tokens para um claimable balance com prazo de validade. Quem não resgatar antes da data de expiração perde a alocação, e o emissor pode reaver as reservas.
- Distribuições condicionais: qualquer cenário em que você precisa confirmar elegibilidade antes de o destinatário acessar os fundos, sem depender de coordenação off-chain para acertar o momento do pagamento.
3. Ordens na SDEX
A exchange descentralizada nativa da Stellar (SDEX) permite que quaisquer dois ativos do ledger sejam negociados entre si. Ao colocar ordens de compra e venda na SDEX usando a conta emissora, emissão e queima ficam atreladas diretamente à atividade de mercado.
A conta emissora coloca uma ordem de venda do próprio ativo, vendendo o ativo X por um ativo Y. Quando outra conta executa essa ordem, o montante de ativo X que sai da conta emissora é emitido em circulação. No caminho inverso, a conta emissora coloca uma ordem de compra do próprio ativo, comprando o ativo X com o ativo Y. Quando essa ordem é executada, o ativo X recebido pela conta emissora é queimado.
Essa abordagem é menos comum que as operações de pagamento, mas viabiliza casos de uso em que a expansão ou a contração da oferta fica atrelada à demanda de mercado, e não à decisão do emissor. Um token lastreado em commodity, por exemplo, pode usar ordens na SDEX para deixar o mercado governar naturalmente a oferta em circulação contra um ativo de reserva.
Todas as flags de autorização configuradas pelo emissor valem também para ordens na SDEX: ativos que exigem autorização para transferências continuam aplicando esses requisitos quando as negociações são executadas.
4. Pools de liquidez (AMMs)
A funcionalidade de automated market maker da Stellar permite reunir quaisquer dois ativos em um pool para negociação, com provedores de liquidez depositando os dois ativos em troca de cotas do pool.
Para emissores, as operações de pool de liquidez podem servir como mais um mecanismo de gestão da oferta: quando a conta emissora deposita o próprio ativo em um pool de liquidez ao lado de um ativo de reserva, essas unidades são emitidas em circulação e colocadas no pool. Quando a conta emissora retira a cota dela do pool, as unidades do próprio ativo que voltam são queimadas.
Isso é relevante para emissores que constroem produtos próximos de DeFi, stablecoins que precisam de profundidade de negociação na exchange nativa da Stellar ou ativos tokenizados que querem oferecer liquidez on-chain sem passar por um livro de ordens centralizado.
5. Clawbacks
Clawbacks são uma operação especial que precisa ser habilitada no momento da criação do ativo, por meio de uma flag de autorização (AUTHORIZATION_CLAWBACK_ENABLED). Uma vez habilitada, a conta emissora pode recuperar e queimar unidades do ativo de qualquer conta ou claimable balance pendente, sem o consentimento de quem detém a conta.
Issuer enables: AUTHORIZATION_CLAWBACK_ENABLED at asset creation
Operation: Clawback
Source: Issuing Account
From: Any account holding the asset
Amount: Specified amount
Effect: Amount burned from the target account, removed from supplyCode language: JavaScript (javascript)Clawbacks são um instrumento de compliance. Os casos de uso são explicitamente regulatórios:
- Cumprimento de sanções: se um detentor for identificado como entidade sancionada, o emissor pode recuperar os fundos.
- Correção de erros: se tokens foram enviados para o endereço errado por falha operacional, o emissor pode recuperá-los e emiti-los de novo.
- Cumprimento de ordem regulatória: em jurisdições onde reguladores podem determinar bloqueio ou apreensão de ativos, os clawbacks são o mecanismo técnico para cumprir a ordem.
O tradeoff é real: habilitar clawbacks em um ativo muda o modelo de confiança dele. Quem valoriza autocustódia total precisa saber que ativos com clawback habilitado podem ser recuperados pelo emissor. Para stablecoins reguladas e security tokens, essa capacidade costuma ser obrigatória. Para ativos descentralizados ou comunitários, ela destruiria o modelo de confiança por completo.
Qual abordagem usar?
Comece pelas operações de pagamento do Classic se você está emitindo um ativo simples, seus requisitos de compliance são tratados off-chain e você quer o caminho mais rápido até produção. A grande maioria dos ativos na Stellar é emitida assim, e a infraestrutura é madura.
Adicione Claimable Balances quando seu modelo de distribuição exigir pré-condições: vesting, checagem de elegibilidade, airdrops com trava de tempo.
Habilite Clawbacks se você está emitindo um ativo regulado em uma jurisdição que exige capacidade de execução. Tome essa decisão no momento da emissão, e ela não pode ser adicionada depois.
Use smart contracts do Soroban quando precisar de lógica de emissão programável: emissão com multi-sig, reservas verificadas por oráculo, hooks de compliance on-chain ou composabilidade com protocolos de DeFi. O fundo de adoção do Soroban, de US$ 100 milhões, já apoiou mais de 160 projetos, incluindo documentação, SDKs e suporte da comunidade bem desenvolvidos.
Use SACs se você já tem um ativo no Classic e quer torná-lo composável com contratos Soroban sem reemiti-lo.
Na Cheesecake Labs, somos parceiros da Stellar Development Foundation com implantações em produção em infraestrutura de stablecoin, plataformas de anchor e sistemas de ativos tokenizados, incluindo trabalhos com a MoneyGram International em infraestrutura de pagamentos internacionais baseada na Stellar. Fale com nosso time de blockchain sobre construir na Stellar.
