Uma coleção anuncia royalties de criador de 5%. Um token dela é vendido por 10 ETH, então 0,5 ETH é o que cabe ao criador. Se esses 0,5 ETH vão chegar não é decidido pelo contrato do token. Quem decide é quem liquida a negociação, e o padrão que define os royalties diz isso com as próprias palavras.
O que é de fato um royalty on-chain
O ERC-2981 é o padrão de tokens que permite a uma coleção de NFTs publicar um royalty. Seu resumo descreve o mecanismo como uma forma de os contratos sinalizarem um valor de royalty a ser pago ao criador ou titular dos direitos toda vez que o NFT é vendido ou revendido. Sinalizar é a palavra decisiva, e todo o resto decorre dela.
A interface é uma única função somente de leitura. Quem chama passa um identificador de token e um preço de venda, e o contrato devolve dois valores: o endereço que deve receber o royalty e o valor devido. Ela responde a uma pergunta. Não move nada.
Passe o exemplo por ela. Quem chama passa um preço de venda de 10 ETH, a coleção está configurada em 5%, e a função devolve 0,5 ETH junto com um endereço de recebimento. Nesse instante o comprador ainda tem os fundos, o vendedor ainda tem o token e ninguém foi pago.
Por que o padrão torna o pagamento voluntário
A especificação não deixa isso para interpretação. Ela afirma que o pagamento do royalty deve ser voluntário, pois mecanismos de transferência como transferFrom() incluem transferências de NFT entre carteiras, e executá-los nem sempre implica que uma venda ocorreu.
Esse raciocínio se apoia no que a rede consegue ver. No ERC-721, o evento Transfer é emitido quando a propriedade de qualquer NFT muda por qualquer mecanismo, e o mesmo evento cobre criação e destruição. Ele registra que um proprietário mudou. Não carrega preço nem motivo.
Então um contrato que descontasse um royalty a cada transferência descontaria quando você move um token para uma carteira de hardware, quando o envia a um amigo e quando junta duas carteiras em uma. O pagamento voluntário é a consequência dessa ambiguidade, não uma brecha que alguém esqueceu de fechar.
Quem está em posição de pagar
Quem sabe que houve uma venda é quem a liquida. Um contrato inteligente de marketplace recebe o pagamento do comprador, entrega o token a ele e envia o valor ao vendedor. É o único ponto da sequência em que preço e transferência existem ao mesmo tempo.
O ERC-2981 fala diretamente com essa parte, e fala em forma de recomendação: marketplaces que suportam o padrão deveriam implementar algum método de transferir os royalties ao destinatário. Recomendação não é exigência, e de qualquer modo não há caminho de imposição, porque o contrato do token nunca está na rota do pagamento.
Uma instrução do padrão é escrita de forma mais dura, e vale ler o que ela revela. Marketplaces devem pagar o royalty na mesma unidade de troca do preço de venda passado à função de royalty. Mesmo a frase mais firme do documento se dirige a uma parte que o contrato do token não consegue obrigar.
Onde um royalty se perde
Para a mesma venda, quatro rotas de liquidação produzem quatro resultados. Para o criador que olha o saldo da carteira, três delas parecem idênticas, porque em nenhuma chega alguma coisa.
| Rota de liquidação | Quem decide o royalty | O que chega ao criador |
|---|---|---|
| Transferência direta entre carteiras, preço combinado fora | Ninguém; não há contrato de liquidação | Nada |
| Plataforma que nunca lê a função de royalty | A plataforma, por omissão | Nada |
| Plataforma que lê e deixa o pagamento com o trader | O comprador ou o vendedor, a cada negociação | O que eles escolherem |
| Plataforma que lê e repassa o valor integral | A plataforma, conforme sua política | 0,5 ETH |
Só a última linha envolve uma obrigação, e essa obrigação é da plataforma, não do token. Troque de plataforma e o mesmo token sob o mesmo contrato dá outra resposta, e é isso que opcional significa aqui na prática.
Impor no nível do contrato
Como o pagamento não pode ser forçado, algumas coleções passam a forçar a rota. Negociar por um marketplace significa conceder a ele uma aprovação de tokens, que autoriza seu contrato a mover o token em seu nome. Uma coleção pode recusar aprovações a operadores fora de uma lista que ela mantém, e assim as plataformas que pulam o royalty ficam inutilizáveis para ela.
O custo desse desenho é pago pelo detentor. O contrato do token agora decide onde seus detentores podem negociar, alguém precisa manter a lista atualizada, e um token que um operador não aprovado não consegue mover continua podendo ser movido pelo próprio dono. Qualquer rota que não precise de operador algum fica intocada.
Há uma razão mais profunda para essa abordagem continuar desconfortável. A imposição transfere o problema do pagamento para a transferência, e a transferência é justamente o ato ambíguo que a especificação apontou desde o início. Uma regra que não distingue venda de presente ou perde vendas ou cobra de presentes.
O que o padrão de fato resolve
A lista do que o ERC-2981 fixa é curta, e lida como coluna deixa ver o formato do padrão.
| Pergunta | O que o padrão resolve |
|---|---|
| Quanto é devido | A função de royalty devolve um valor para um preço de venda dado |
| Em qual ativo | A mesma unidade de troca do preço de venda passado |
| Como a taxa varia com o preço | O percentual é independente do preço de venda |
| Quem recebe | Um endereço, devolvido pela função |
| Como vários criadores dividem | Não coberto; quem cuida disso é o contrato receptor |
| Se o pagamento acontece | Não coberto; o pagamento é voluntário |
| Quem verifica o pagamento | Ninguém; o contrato do token não enxerga nada disso |
As quatro primeiras linhas descrevem um número. As três últimas dizem respeito à cobrança, e o padrão declina as três. É uma especificação sobre como descrever um royalty, não sobre como cobrá-lo.
A divisão é o exemplo mais claro dessa fronteira. Como a função devolve um único endereço, uma coleção com vários titulares de direitos aponta esse endereço para um contrato que reparte o que entra. A repartição acontece depois que o dinheiro chega, em código que o padrão nunca menciona.
Como ler o número na página de uma coleção
Trate um royalty exibido como um pedido, não como receita. A comparação útil é entre a taxa que a coleção anuncia e o valor que de fato chegou ao destinatário em algum período: são duas leituras separadas e podem divergir muito.
A mesma lacuna explica um padrão que parece evasão e não é. Um dono que move um token entre duas carteiras que controla produz uma transferência sem royalty, exatamente como a especificação pretende, e produz também um registro público que se parece com atividade. Esse é o mecanismo por trás do wash trading em colecionáveis: a rede mostra uma troca de dono e deixa todo mundo adivinhando o que aquilo significou.
Duas perguntas cobrem os casos práticos. Se você é criador, pergunte em quais plataformas sua coleção realmente é negociada e o que cada uma faz com a função de royalty. Se você é comprador, pergunte se o preço mostrado já inclui o royalty ou se ele será somado no fechamento, porque isso também é decidido pela plataforma.
Em resumo
Um royalty on-chain é um número publicado, não um direito sobre dinheiro. O ERC-2981 dá à coleção uma forma de declarar o que quer e ao marketplace uma forma de ler isso, e para por aí de propósito, porque uma transferência na rede não carrega informação suficiente para provar que houve uma venda.
Isso faz do marketplace, e não do contrato, a coisa a observar. Um royalty é pago quando a plataforma que liquida a negociação escolhe pagá-lo, e os desenhos de imposição descritos acima funcionam restringindo onde o token pode ser negociado, não tornando o pagamento automático. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.
Leituras relacionadas
Outros artigos da Bitbase sobre este tema:
- Propriedade fracionada de um token não fungível e onde está o risco
- A cunhagem deu certo, mas o NFT não aparece na carteira
- O processo de revelação de um NFT: o que muda e quando
- Intenções e redes de solvers: como funciona a ponte por intenção
- O que é o halving do Bitcoin?
Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em setembro de 2026; consulte as informações oficiais mais recentes.
Fontes
[1] Ethereum Improvement Proposals, ERC-2981: NFT Royalty Standard (status Final, criado em 15 de setembro de 2020) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-721: Non-Fungible Token Standard (status Final, criado em 24 de janeiro de 2018) eips.ethereum.org
