ERC-2981: Como as royalties de NFTs são definidas e implementadas

As royalties de NFTs começaram como um contrato social entre criadores e marketplaces. À medida que o comércio amadureceu e os modelos de taxas evoluíram, a indústria precisou de uma maneira consistente e on-chain para descrever informações de royalties que qualquer marketplace pudesse ler. É exatamente isso que o ERC-2981 fornece: uma interface mínima e interoperável para consultar quanto royalty é devido e a quem para qualquer venda de NFT. Este artigo explica o que é o ERC-2981, como funciona internamente, considerações para implementação e o cenário atual de aplicação por marketplaces e monetização de criadores.

O que o ERC-2981 realmente padroniza

O ERC-2981 é um padrão Ethereum que define uma única função para tokens não fungíveis:

• royaltyInfo(tokenId, salePrice) → (receiver, royaltyAmount)

Marketplaces que honram royalties chamam royaltyInfo no momento da venda para calcular o pagamento. O padrão não impõe o pagamento — ele apenas descreve a interface. A imposição é uma questão de política do marketplace.

Principais escolhas de design:

• Baseado em percentual: royalties são calculados como uma função do preço de venda, tipicamente usando uma fração como basis points (por exemplo, 500 = 5%).
• Flexibilidade do recebedor: o recebedor do royalty pode ser o endereço de um criador, um multisig, um contrato de divisão ou um endereço de pagamento atualizável.
• Funciona com ERC-721 e ERC-1155: O ERC-2981 é compatível com padrões comuns de NFT e depende do ERC-165 para detecção de interface.

Para uma implementação pronta para produção, muitas equipes se baseiam no ERC2981 da OpenZeppelin.

Por que isso importa agora

A partir de 2023, vários marketplaces líderes mudaram para a aplicação opcional de royalties. A mudança mais notável foi a decisão da OpenSea de descontinuar seu Operator Filter, que anteriormente permitia que os criadores restringissem o comércio a locais que aplicavam royalties; veja o anúncio da OpenSea. Como resultado, padrões on-chain como o ERC-2981 se tornaram a maneira padrão de apresentar dados de royalties em todas as plataformas, mesmo que a aplicação varie.

Desde então, o ecossistema respondeu com:

• Infraestrutura de registro para que os marketplaces possam resolver a lógica de royalties de forma unificada, por exemplo, o Royalty Registry e a especificação associada spec.
• Padrões programáveis para aplicação ou restrições on-chain, notavelmente o ERC-721C (Creator Token Standards).
• Modelos de ganhos alternativos, como recompensas no nível do protocolo e incentivos para criadores, por exemplo, o Creator Rewards da Zora.

Em 2024-2025, a adoção do ERC-2981 permanece generalizada em redes L1 e L2, e os marketplaces que optam por honrar royalties geralmente consultarão essa interface ao liquidar negociações.

Como a interface funciona (sem surpresas)

No momento da venda, um marketplace compatível executa:

1. Verifica se o token suporta IERC2981 via ERC-165 (interface ID 0x2a55205a).
2. Chama royaltyInfo(tokenId, salePrice) para obter:
   • receiver: Endereço para receber o pagamento.
   • royaltyAmount: Valor a pagar, calculado a partir de salePrice.

Criadores ou proprietários de coleções geralmente definem um "royalty padrão" e, opcionalmente, um "royalty por token". Muitas implementações usam um denominador de 10.000 para basis points. A contabilidade do marketplace, então, divide a receita da venda entre vendedor, taxas de protocolo e destinatário do royalty.

Dicas de implementação:

• Evite reverter em royaltyInfo — os marketplaces podem pular pagamentos se sua chamada falhar.
• Mantenha o recebedor do royalty atualizável (por exemplo, via Ownable ou controles de administrador) para rotacionar chaves ou migrar para um contrato de divisão.
• Limite os royalties a um máximo razoável (muitos projetos ficam ≤10%) para incentivar a liquidez do mercado secundário.

Exemplo mínimo em Solidity

Abaixo está um padrão simplificado usando OpenZeppelin. Ele mostra como definir um royalty padrão e substituir o suporte para ERC-165. Em produção, você deve adicionar controle de acesso, guarda de inicialização e lógica de minting robusta.

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

import "@openzeppelin/contracts/token/ERC721/ERC721.[sol](https://onekey.so/blog/pt/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/token/common/ERC2981.[sol](https://onekey.so/blog/pt/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";
import "@openzeppelin/contracts/access/Ownable.[sol](https://onekey.so/blog/pt/ecosystem/best-sol-wallets-in-2025-ultimate-guide-to-software-hardware-options/)";

[contract](https://onekey.so/blog/pt/ecosystem/what-is-a-smart-contract/) MyNFT is ERC721, ERC2981, Ownable {
    uint256 private _nextTokenId;

    constructor([address](https://onekey.so/blog/pt/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // Define o royalty padrão (ex: 500 = 5%)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

    function mint([address](https://onekey.so/blog/pt/ecosystem/what-is-a-crypto-wallet-address/) to) external onlyOwner {
        _safeMint(to, _nextTokenId);
        _nextTokenId++;
    }

    // Opcional: define royalty por token para itens especiais
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/pt/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

    // Necessário: ERC-165 supportsInterface
    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721, ERC2981)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

Para documentação mais aprofundada, consulte o guia ERC-2981 da OpenZeppelin.

Lidando com divisões, atualizações e casos extremos

Fluxos de royalties no mundo real raramente têm um único destinatário. Considere:

• Contratos de divisão: roteiam a receita para várias partes em proporções fixas usando infraestrutura bem testada como 0xSplits.
• Consultas ao registro: alguns marketplaces consultam um registro para obter os dados de royalties mais recentes (Royalty Registry).
• Recebedores atualizáveis: mantenha a capacidade de atualizar o endereço de recebimento em caso de rotação de chaves ou mudanças organizacionais.
• Substituições por token: edições especiais podem ter taxas de royalty exclusivas em relação ao padrão.

Notas técnicas:

• Denominador consistente: mantenha basis points (10.000) para clareza em integrações off-chain.
• Consciência do tipo de token: implementações ERC-1155 devem calcular o royalty sobre o preço de venda por token, não o preço do pacote.
• Fallback gracioso: se o recebedor do royalty não estiver configurado, retorne zero para evitar falhas nas chamadas do marketplace.

Realidade do Marketplace: sinalização vs. aplicação

O ERC-2981 sinaliza a intenção do criador; ele não força o pagamento. Diferentes locais:

• Podem honrar totalmente o ERC-2981.
• Podem limitar ou reduzir royalties sob certas condições.
• Podem ignorar royalties completamente.

Dada essa variabilidade, muitos criadores experimentam modelos híbridos:

• Restrições on-chain via ERC-721C para limitar transferências a operadores que respeitam royalties.
• Recompensas no nível do protocolo como Creator Rewards da Zora.
• Normas comunitárias e pressão social em torno de honrar os ganhos dos criadores.

A decisão da OpenSea em 2023 de encerrar a filtragem de operadores reflete a tendência mais ampla de escolha de mercado em detrimento da aplicação no nível do protocolo, detalhada em seu anúncio. Em 2024-2025, esse equilíbrio continua: o ERC-2981 permanece a interface canônica para metadados de royalties, enquanto a aplicação é fragmentada.

Testando, verificando e monitorando

Para garantir um comportamento confiável de royalties:

• Verifique o suporte à interface: confirme se seu contrato relata supportsInterface(0x2a55205a) == true de acordo com o ERC-165.
• Simule chamadas: teste royaltyInfo em preços de venda e tokens extremos.
• Compatibilidade de indexação: registre seu contrato em registradores relevantes como o Royalty Registry se seus parceiros de marketplace dependerem dele.
• Documente claramente: publique sua política de royalties, limites e lógica do recebedor para minimizar surpresas para compradores e marketplaces.
• Aprenda o padrão: se você é novo no ERC-2981, esta visão geral da Alchemy é um guia útil: O que é ERC-2981?.

Segurança e gerenciamento de chaves para criadores

Configurações de royalties são controladas pelo administrador. Se um invasor obtiver acesso às suas chaves de deployer ou administrador, eles poderão redirecionar ou desativar os royalties. Melhores práticas:

• Use uma carteira de hardware para ações de alta privilégio, como definir royalty padrão, atualizar recebedores ou implantar contratos de divisão.
• Prefira configurações multisig para coleções gerenciadas por equipe.
• Mantenha fluxos de assinatura transparentes e auditáveis.

Para criadores e estúdios que desejam assinaturas seguras e portáteis sem comprometer a experiência do usuário, as carteiras de hardware OneKey oferecem:

• Armazenamento de chave privada offline com firmware de código aberto e práticas de segurança transparentes.
• Integração suave com ferramentas Ethereum comuns para implantação de contratos e operações administrativas.
• Suporte cross-chain, útil se seus NFTs forem mintados em L2s ou em várias redes EVM.

Usar uma carteira de hardware para gerenciar configurações de royalties garante que seus sinais de receita on-chain não possam ser adulterados por dispositivos comprometidos ou carteiras quentes.

Conclusão

O ERC-2981 é a camada fundamental para royalties de NFTs: uma interface simples e universal que os marketplaces podem ler para determinar os pagamentos aos criadores. Ele não garante a aplicação — as políticas de mercado o fazem — mas padroniza o sinal. Em um mundo onde a aplicação é opcional e está em evolução, combinar o ERC-2981 com registradores, contratos de divisão e restrições programáveis como o ERC-721C dá aos criadores ferramentas práticas para sustentar seu trabalho.

Se você gerencia coleções de NFT ou infraestrutura de criador, implemente o ERC-2981 de forma limpa, teste-o completamente e proteja suas chaves administrativas com uma carteira de hardware. Essa combinação maximiza a interoperabilidade entre marketplaces, ao mesmo tempo em que protege os fluxos de receita dos quais seu projeto depende.