ERC-2981: Cómo se definen e implementan las regalías de los NFTs

Claro, aquí tienes la traducción al español del artículo, manteniendo el formato Markdown y la estructura original:

Las regalías de los NFTs comenzaron como un contrato social entre creadores y mercados. A medida que el comercio maduró y los modelos de tarifas evolucionaron, la industria necesitó una forma consistente y en la cadena de bloques para describir la información de las regalías que cualquier mercado pudiera leer. Eso es exactamente lo que proporciona ERC-2981: una interfaz mínima e interoperable para consultar cuánta regalía se debe y a quién por cualquier venta de NFT dada. Este artículo explica qué es ERC-2981, cómo funciona internamente, consideraciones para su implementación y el panorama actual de la aplicación por parte de los mercados y la monetización de los creadores.

Lo que ERC-2981 estandariza realmente

ERC-2981 es un estándar de Ethereum que define una única función para tokens no fungibles:

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

Los mercados que respetan las regalías llaman a royaltyInfo en el momento de la venta para calcular el pago. El estándar no impone el pago, solo describe la interfaz. La imposición es una cuestión de política del mercado.

Opciones clave de diseño:

• Basado en porcentaje: Las regalías se calculan como una función del precio de venta, típicamente utilizando una fracción como puntos base (por ejemplo, 500 = 5%).
• Flexibilidad del receptor: El receptor de la regalía puede ser la dirección de un creador, una multisig, un contrato de división o una dirección de pago actualizable.
• Funciona con ERC-721 y ERC-1155: ERC-2981 es compatible con los estándares comunes de NFT y se basa en ERC-165 para la detección de interfaces.

Para una implementación lista para producción, muchos equipos se basan en ERC2981 de OpenZeppelin.

Por qué importa ahora

A partir de 2023, varios mercados líderes cambiaron a la aplicación opcional de regalías. El cambio más notable fue la decisión de OpenSea de descontinuar su Operador Filter, que anteriormente permitía a los creadores restringir las transacciones a lugares que aplicaban regalías; véase el anuncio de OpenSea. Como resultado, los estándares en la cadena como ERC-2981 se convirtieron en la forma predeterminada de mostrar datos de regalías en todas las plataformas, incluso cuando la aplicación varía.

Desde entonces, el ecosistema ha respondido con:

• Infraestructura de registro para que los mercados puedan resolver la lógica de regalías de manera unificada, por ejemplo, Royalty Registry y la especificación asociada.
• Estándares programables para la aplicación o restricciones en la cadena de bloques, especialmente ERC-721C (Creator Token Standards).
• Modelos de ingresos alternativos, como recompensas a nivel de protocolo e incentivos para creadores, por ejemplo, las Creator Rewards de Zora.

En 2024-2025, la adopción de ERC-2981 sigue siendo generalizada en las redes L1 y L2, y los mercados que elijan respetar las regalías generalmente consultarán esta interfaz al liquidar transacciones.

Cómo funciona la interfaz (sin sorpresas)

En el momento de la venta, un mercado compatible realiza:

1. Comprueba si el token admite IERC2981 a través de ERC-165 (ID de interfaz 0x2a55205a).
2. Llama a royaltyInfo(tokenId, salePrice) para obtener:
   • receiver: Dirección para recibir el pago.
   • royaltyAmount: Monto a pagar, calculado a partir de salePrice.

Los creadores o los propietarios de colecciones suelen establecer una "regalía predeterminada" y, opcionalmente, una "regalía por token". Muchas implementaciones utilizan un denominador de 10.000 para los puntos base. La contabilidad del mercado divide entonces los ingresos de la venta entre el vendedor, las tarifas del protocolo y el destinatario de la regalía.

Consejos de implementación:

• Evita reverts en royaltyInfo; los mercados pueden omitir los pagos si tu llamada falla.
• Mantén el receptor de regalías actualizable (por ejemplo, a través de Ownable o controles de administrador) para rotar claves o migrar a un contrato de división.
• Limita las regalías a un máximo razonable (muchos proyectos se mantienen ≤10%) para fomentar la liquidez del mercado secundario.

Ejemplo mínimo de Solidity

A continuación, se presenta un patrón simplificado que utiliza OpenZeppelin. Muestra cómo establecer una regalía predeterminada y anular el soporte para ERC-165. En producción, deberías añadir control de acceso, guardas de inicialización y lógica de acuñación robusta.

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

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

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

    constructor([address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) defaultReceiver, uint96 defaultBps)
        ERC721("MyNFT", "MYN")
    {
        // Establecer regalía predeterminada (por ejemplo, 500 = 5%)
        _setDefaultRoyalty(defaultReceiver, defaultBps);
    }

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

    // Opcional: establecer regalía por token para artículos especiales
    function setTokenRoyalty(uint256 tokenId, [address](https://onekey.so/blog/es/ecosystem/what-is-a-crypto-wallet-address/) receiver, uint96 bps)
        external
        onlyOwner
    {
        _setTokenRoyalty(tokenId, receiver, bps);
    }

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

Para documentación más detallada, consulta la guía ERC2981 de OpenZeppelin.

Manejo de divisiones, actualizaciones y casos límite

Los flujos de regalías del mundo real rara vez son de un solo destinatario. Considera:

• Contratos de división: Dirige los ingresos a múltiples partes en proporciones fijas utilizando infraestructura bien probada como 0xSplits.
• Consultas de registro: Algunos mercados consultan un registro para obtener los datos de regalías más recientes (Royalty Registry).
• Receptores actualizables: Mantén la capacidad de actualizar la dirección receptora en caso de rotación de claves o cambios organizacionales.
• Anulaciones por token: Las ediciones especiales pueden tener tasas de regalías únicas en relación con la predeterminada.

Notas técnicas:

• Denominador consistente: Utiliza puntos base (10.000) para mayor claridad en las integraciones fuera de la cadena.
• Conciencia del tipo de token: Las implementaciones de ERC-1155 deben calcular la regalía sobre el precio de venta de cada token, no sobre el precio del paquete.
• Fallback elegante: Si el receptor de regalías no está configurado, devuelve cero para evitar fallos en las llamadas del mercado.

Realidad del mercado: señalización frente a aplicación

ERC-2981 señala la intención del creador; no garantiza el pago. Diferentes plataformas:

• Pueden respetar completamente ERC-2981.
• Pueden limitar o reducir las regalías bajo ciertas condiciones.
• Pueden ignorar las regalías por completo.

Dada esta variabilidad, muchos creadores experimentan con modelos híbridos:

• Restricciones en la cadena a través de ERC-721C para limitar las transferencias a operadores que respetan las regalías.
• Recompensas a nivel de protocolo como las Creator Rewards de Zora.
• Normas comunitarias y presión social en torno al respeto de los ingresos de los creadores.

La decisión de OpenSea en 2023 de finalizar el filtrado de operadores refleja la tendencia general hacia la elección del mercado sobre la aplicación a nivel de protocolo, detallada en su anuncio. En 2024-2025, este equilibrio continúa: ERC-2981 sigue siendo la interfaz canónica para metadatos de regalías, mientras que la aplicación está fragmentada.

Pruebas, verificación y monitorización

Para garantizar un comportamiento de regalías fiable:

• Verifica el soporte de la interfaz: Confirma que tu contrato informa supportsInterface(0x2a55205a) == true según ERC-165.
• Simula llamadas: Prueba royaltyInfo en precios de venta y tokens de casos límite.
• Compatibilidad de indexación: Registra tu contrato en los registros relevantes como Royalty Registry si tus socios de mercado dependen de él.
• Documenta claramente: Publica tu política de regalías, límites y lógica del receptor para minimizar sorpresas para compradores y mercados.
• Aprende el estándar: Si eres nuevo en ERC-2981, este resumen de Alchemy es un útil introductorio: ¿Qué es ERC-2981?.

Seguridad y gestión de claves para creadores

Las configuraciones de regalías se controlan mediante administración. Si un atacante obtiene acceso a tus claves de implementador o administrador, puede redirigir o deshabilitar las regalías. Mejores prácticas:

• Utiliza una billetera de hardware para acciones de alta privilegios como establecer regalías predeterminadas, actualizar receptores o implementar contratos de división.
• Prefiere configuraciones multisig para colecciones gestionadas por equipos.
• Mantén los flujos de firma transparentes y auditables.

Para creadores y estudios que desean una firma segura y portátil sin comprometer la experiencia del usuario, las billeteras de hardware OneKey ofrecen:

• Almacenamiento de claves privadas sin conexión con firmware de código abierto y prácticas de seguridad transparentes.
• Integración fluida con herramientas comunes de Ethereum para la implementación de contratos y operaciones administrativas.
• Soporte multiplataforma, útil si tus NFTs se acuñan en L2 o en múltiples redes EVM.

Utilizar una billetera de hardware para gestionar la configuración de las regalías garantiza que tus señales de ingresos en la cadena no puedan ser manipuladas por dispositivos comprometidos o billeteras activas.

Conclusión

ERC-2981 es la capa fundamental para las regalías de los NFTs: una interfaz simple y universal que los mercados pueden leer para determinar los pagos a los creadores. No garantiza la aplicación —las políticas de mercado lo hacen— pero estandariza la señal. En un mundo donde la aplicación es opcional y está en evolución, combinar ERC-2981 con registros, contratos de división y restricciones programables como ERC-721C brinda a los creadores herramientas prácticas para sostener su trabajo.

Si administras colecciones de NFTs o infraestructura para creadores, implementa ERC-2981 de manera limpia, pruébalo a fondo y protege tus claves de administrador con una billetera de hardware. Esta combinación maximiza la interoperabilidad entre mercados y, al mismo tiempo, protege los flujos de ingresos de los que depende tu proyecto.