Smart Contract de Royalties para Artistas na Prática

2026-09-18 · 7 min de leitura · atualizado em 2026-09-19

O que é um smart contract de royalties

Um smart contract é um programa que roda na EVM (Ethereum Virtual Machine) e executa sua lógica sem intervenção humana, assim que as condições definidas no código são satisfeitas. Ele não pede permissão a ninguém: se a condição bate, a transação acontece.

Royalties para artistas, nesse contexto, é um percentual sobre o valor de uma venda que é pago automaticamente ao criador original — sem precisar que o comprador ou o marketplace decidam repassar nada manualmente.

A diferença entre um contrato de licenciamento tradicional e um royalty on-chain é estrutural. No modelo tradicional, o pagamento depende de um intermediário (editora, plataforma, distribuidora) que calcula, retém e repassa o valor — com atraso e com margem de erro humano. No royalty on-chain, a distribuição é uma função do próprio smart contract: quando o evento de venda secundária de um NFT dispara, o código transfere a fatia correspondente ao endereço do artista na mesma transação.

Essa lógica de split — quem recebe, quanto recebe, sob qual condição — fica escrita no bytecode do contrato, publicada na blockchain. Qualquer pessoa pode ler o código-fonte verificado (quando o desenvolvedor publica o source no explorador da rede) e confirmar exatamente como a divisão funciona. É esse registro público que torna o mecanismo auditável: não existe "confia em mim", existe "lê o contrato".

Para entender a base de como esse código é escrito e implantado, vale revisar o Guia Definitivo de Smart Contracts para Devs antes de seguir para a parte de royalties especificamente.

Como funciona a distribuição automática de pagamentos

O fluxo típico é assim: um NFT é vendido pela segunda vez em um marketplace. O marketplace, ao processar a venda, consulta o padrão de royalty do contrato do NFT — geralmente o EIP-2981, que define uma interface padrão para consultar o percentual de royalty e o endereço de recebimento. Se o marketplace respeita esse padrão, ele envia a fatia de royalty diretamente para o endereço retornado pela função royaltyInfo.

Quando há mais de um beneficiário — por exemplo, um artista e um produtor dividindo o valor — o contrato usa uma lógica de split percentual: cada endereço tem um número de "shares" e o valor recebido é distribuído proporcionalmente entre eles.

Cada transferência de valor na EVM consome gas fee. Isso significa que toda distribuição de royalty — mesmo que seja de poucos centavos de dólar em criptomoeda — tem um custo fixo de execução que não escala para baixo. Vender um NFT por um valor alto dilui esse custo; vender por um valor baixo pode fazer o gas consumir uma fatia desproporcional do royalty. Para entender como estimar esse custo antes de desenhar a estrutura de pagamentos, veja Gas Fees na EVM: Como Estimar e Reduzir Custos.

Existe uma diferença crítica entre royalty enforced on-chain e royalty apenas sugerido. O EIP-2981 é uma interface de consulta, não uma trava. Ele diz ao marketplace "este é o percentual esperado", mas não impede a transferência do NFT caso o marketplace opte por ignorar essa informação. Enforcement real exige lógica adicional no próprio contrato do NFT, que bloqueia ou reverte transferências que não cumpram a regra de pagamento — e isso tem trade-offs de compatibilidade com marketplaces que não implementam esse tipo de restrição.

Exemplo de estrutura em Solidity

Um padrão testado e amplamente auditado para dividir pagamentos entre múltiplos beneficiários é o PaymentSplitter da OpenZeppelin. Em vez de escrever a lógica de split do zero, a prática recomendada é herdar de um contrato já revisado pela comunidade:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/finance/PaymentSplitter.sol";

contract RoyaltySplitter is PaymentSplitter {
    constructor(address[] memory payees, uint256[] memory shares)
        PaymentSplitter(payees, shares)
    {}
}

Ao implantar esse contrato, payees recebe os endereços dos beneficiários (o artista, o produtor, a plataforma) e shares recebe o peso proporcional de cada um. Qualquer valor enviado ao contrato fica disponível para saque através da função release(address account), que calcula a fatia devida e transfere o valor.

Usar um padrão como esse, em vez de escrever a lógica de transferência manualmente, reduz a superfície de erro. Contratos que lidam com recebimento e envio de valor são o alvo mais comum de bugs de reentrância — quando uma chamada externa (como um .call{value: x}("")) permite que o contrato de destino execute código antes que o estado interno do contrato original seja atualizado, abrindo brecha para saques repetidos.

A regra prática é: sempre atualizar o estado interno (marcar o valor como já distribuído) antes de fazer a chamada externa que envia o valor — o padrão conhecido como checks-effects-interactions. Escrever essa lógica do zero sem testes extensivos é um dos erros mais caros que um contrato de royalties pode cometer, porque o bug só aparece quando já há dinheiro real em trânsito.

Trade-offs e limitações práticas

Nenhum desses mecanismos é gratuito ou infalível. Vale listar os limites antes de decidir construir:

• Gas fee pode inviabilizar micropagamentos. Se o valor do royalty por venda for pequeno e a rede estiver congestionada, o custo de gas pode consumir uma parcela desproporcional — ou até superar — o valor a ser pago.
• Marketplaces podem ignorar o royalty. Como visto acima, o EIP-2981 é uma sugestão de interface, não uma imposição. Um marketplace pode processar a venda e simplesmente não consultar ou não respeitar o percentual informado.
• A rede escolhida importa. Um contrato implantado em uma rede EVM com taxas altas e congestão frequente terá custos de distribuição bem diferentes de um implantado em uma rede com taxas mais baixas. Essa escolha afeta diretamente a viabilidade econômica do modelo de royalty.
• Contratos que recebem valor precisam de auditoria. Qualquer código que manipula transferência de ETH ou tokens é alvo prioritário de análise de segurança antes de ir para produção.

Checklist antes de lançar um contrato de royalties

Antes de colocar um contrato de royalties em mainnet, valem quatro verificações mínimas:

1. Testar em testnet primeiro. Simular vendas, splits e saques em uma rede de teste antes de mover qualquer valor real.
2. Validar os splits com múltiplos cenários. Testar com dois, três e mais beneficiários, incluindo casos-limite como valores muito pequenos que geram arredondamento.
3. Rodar um checklist de segurança específico para DApps. Contratos que recebem valor exigem revisão além do básico — o Checklist Prático de Auditoria de Segurança em DApps cobre os pontos que costumam passar despercebidos.
4. Estimar o custo de gas em diferentes cenários de rede. Simular a distribuição em horários de alta e baixa congestão ajuda a decidir se o modelo de royalty é economicamente viável para o valor médio de venda esperado.

Se o projeto envolve produção de arte digital tokenizada e distribuição de royalty para múltiplos criadores, vale considerar como esse fluxo se conecta ao restante do produto desde o início do desenho técnico — não como um adendo depois que o NFT já foi cunhado.

Se sua operação envolve tokenização de obras e precisa de uma arquitetura de royalties desenhada desde a base, conheça o NeuroArt, o produto da Hack Tech Farm voltado para arte digital e Web3.

Perguntas Frequentes

Smart contract de royalties garante pagamento em qualquer marketplace?

Não. Só é garantido se o marketplace consultar e respeitar o padrão de royalty (como o EIP-2981) ou se o próprio contrato do NFT bloquear transferências sem pagamento. Sem enforcement, o pagamento é apenas uma sugestão.

Qual a diferença entre royalty on-chain e royalty sugerido?

Royalty on-chain enforced bloqueia a transferência do NFT se o pagamento não ocorrer. Royalty sugerido, via EIP-2981, apenas informa o percentual esperado — o marketplace decide se respeita.

Como o gas fee impacta pagamentos pequenos de royalty?

O custo de execução na EVM é fixo por transação, independente do valor transferido. Em vendas de baixo valor, o gas pode consumir uma fatia desproporcional do royalty, ou até inviabilizar a distribuição.

É preciso auditoria para um contrato de royalties?

Sim. Qualquer contrato que recebe e distribui valor é alvo prioritário de bugs de reentrância e erros de cálculo de split. Auditoria antes de ir para mainnet é recomendada, não opcional.

Dá para mudar o percentual de royalty depois do contrato publicado?

Depende de como o contrato foi escrito. Se não houver uma função administrativa para isso, o percentual fica fixo para sempre — mudar exigiria implantar um novo contrato.