Una colección anuncia una regalía del creador del 5 %. Un token suyo se vende por 10 ETH, así que al creador le corresponden 0,5 ETH. Que esos 0,5 ETH lleguen alguna vez no lo decide el contrato del token. Lo decide quien liquida la operación, y el estándar que define la regalía lo dice con sus propias palabras.
Qué es realmente una regalía on-chain
ERC-2981 es el estándar de tokens que permite a una colección de NFT publicar una regalía. Su resumen describe el mecanismo como una forma de que los contratos señalen un importe de regalía que debe pagarse al creador o titular de derechos cada vez que el NFT se vende o se revende. Señalar es la palabra operativa, y todo lo demás se deriva de ella.
La interfaz es una sola función de solo lectura. Quien la llama pasa un identificador de token y un precio de venta, y el contrato devuelve dos valores: la dirección que debe recibir la regalía y el importe adeudado. Responde a una pregunta. No mueve nada.
Pasa el ejemplo por ella. Quien llama pasa un precio de venta de 10 ETH, la colección está configurada al 5 %, y la función devuelve 0,5 ETH junto con una dirección receptora. En ese instante el comprador aún tiene los fondos, el vendedor aún tiene el token y no se ha pagado a nadie.
Por qué el estándar hace voluntario el pago
La especificación no lo deja a interpretación. Establece que el pago de la regalía debe ser voluntario, ya que los mecanismos de transferencia como transferFrom() incluyen transferencias de NFT entre monederos, y ejecutarlos no siempre implica que haya ocurrido una venta.
Ese razonamiento se apoya en lo que la cadena puede ver. En ERC-721, el evento Transfer se emite cuando la propiedad de cualquier NFT cambia por cualquier mecanismo, y el mismo evento cubre la creación y la destrucción. Registra que cambió un propietario. No lleva precio y no lleva motivo.
Así que un contrato que descontara una regalía en cada transferencia la descontaría cuando mueves un token a un monedero de hardware, cuando se lo envías a un amigo y cuando fusionas dos monederos en uno. El pago voluntario es la consecuencia de esa ambigüedad, no un hueco que alguien olvidó cerrar.
Quién está en condiciones de pagar
Quien sabe que hubo una venta es quien la liquida. Un contrato inteligente de mercado recibe el pago del comprador, le entrega el token y envía los ingresos al vendedor. Es el único punto de la secuencia donde el precio y la transferencia existen a la vez.
ERC-2981 se dirige a esa parte de forma directa, y lo hace como recomendación: los mercados que admiten el estándar deberían implementar algún método para transferir las regalías al destinatario. Una recomendación no es un requisito, y de todos modos no hay vía de imposición, porque el contrato del token nunca está en la ruta del pago.
Una instrucción del estándar está redactada con más fuerza, y conviene leer lo que revela. Los mercados deben pagar la regalía en la misma unidad de cambio que el precio de venta pasado a la función de regalías. Incluso la frase más firme del documento apunta a una parte que el contrato del token no puede obligar.
Dónde se pierde una regalía
Para la misma venta, cuatro rutas de liquidación producen cuatro resultados. Para el creador que mira el saldo de su monedero, tres de ellas se ven idénticas, porque en ninguna llega nada.
| Ruta de liquidación | Quién decide la regalía | Qué llega al creador |
|---|---|---|
| Transferencia directa entre monederos, precio acordado aparte | Nadie; no hay contrato de liquidación | Nada |
| Plataforma que nunca lee la función de regalías | La plataforma, por omisión | Nada |
| Plataforma que la lee y deja el pago al operador | El comprador o el vendedor, en cada operación | Lo que elijan |
| Plataforma que la lee y transfiere el importe completo | La plataforma, según su política | 0,5 ETH |
Solo la última fila implica una obligación, y esa obligación es de la plataforma, no del token. Cambia de plataforma y el mismo token bajo el mismo contrato da otra respuesta: eso es lo que significa opcional aquí en la práctica.
Imponerlo a nivel de contrato
Como el pago no puede forzarse, algunas colecciones fuerzan la ruta. Operar a través de un mercado implica concederle una aprobación de tokens, que autoriza a su contrato a mover el token en tu nombre. Una colección puede negar aprobaciones a operadores fuera de una lista que ella mantiene, con lo que las plataformas que se saltan la regalía quedan inservibles para esa colección.
El coste de ese diseño lo paga el titular. El contrato del token decide ahora dónde pueden operar sus titulares, alguien tiene que mantener la lista y tenerla al día, y un token que no puede mover un operador no aprobado sí puede moverlo su propietario. Cualquier ruta que no necesite operador queda intacta.
Hay una razón más profunda por la que este enfoque sigue siendo incómodo. La imposición traslada el problema del pago a la transferencia, y la transferencia es justo el acto ambiguo que la especificación señaló desde el principio. Una regla que no distingue una venta de un regalo o bien se pierde ventas o bien cobra por los regalos.
Lo que el estándar sí resuelve
La lista de lo que ERC-2981 fija es corta, y leída como columna deja ver la forma del estándar.
| Pregunta | Qué resuelve el estándar |
|---|---|
| Cuánto se debe | La función de regalías devuelve un importe para un precio de venta dado |
| En qué activo | La misma unidad de cambio que el precio de venta pasado |
| Cómo escala la tasa | El porcentaje es independiente del precio de venta |
| Quién lo recibe | Una dirección, devuelta por la función |
| Cómo reparten varios creadores | No lo cubre; lo gestiona el contrato receptor |
| Si el pago ocurre | No lo cubre; el pago es voluntario |
| Quién verifica el pago | Nadie; el contrato del token no ve nada de eso |
Las primeras cuatro filas describen un número. Las tres últimas tienen que ver con el cobro, y el estándar declina las tres. Es una especificación sobre cómo describir una regalía, no sobre cómo cobrarla.
El reparto es el ejemplo más claro de esa frontera. Como la función devuelve una sola dirección, una colección con varios titulares de derechos apunta esa dirección a un contrato que divide lo que entra. La división ocurre después de que el dinero llega, en código que el estándar nunca menciona.
Cómo leer el número de la página de una colección
Trata una regalía mostrada como una petición, no como un ingreso. La comparación útil es entre la tasa que anuncia una colección y el importe que realmente llegó al destinatario en algún periodo: son dos lecturas separadas y pueden diferir mucho.
La misma brecha explica un patrón que parece evasión y no lo es. Un propietario que mueve un token entre dos monederos que controla produce una transferencia sin regalía, tal como la especificación pretende, y produce además un registro público que se parece a la actividad. Ese es el mecanismo detrás del wash trading en coleccionables: la cadena muestra un cambio de propiedad y deja que todos adivinen qué significaba.
Dos preguntas cubren los casos prácticos. Si eres creador, pregunta en qué plataformas se opera realmente tu colección y qué hace cada una con la función de regalías. Si eres comprador, pregunta si el precio que ves ya incluye la regalía o si se añadirá al pagar, porque eso también lo decide la plataforma.
En resumen
Una regalía on-chain es un número publicado, no un derecho de cobro. ERC-2981 da a una colección una forma de decir lo que quiere y a un mercado una forma de leerlo, y se detiene ahí a propósito, porque una transferencia en cadena no lleva información suficiente para probar que hubo una venta.
Eso convierte al mercado, y no al contrato, en lo que hay que mirar. Una regalía se paga cuando la plataforma que liquida la operación decide pagarla, y los diseños de imposición descritos arriba funcionan restringiendo dónde puede operarse el token, no haciendo automático el pago. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Propiedad fraccionada de un token no fungible y dónde está el riesgo
- Acuñación con éxito, pero el NFT no aparece en la billetera
- El proceso de revelado de un NFT: qué cambia y cuándo
- Intenciones y solvers: cómo funcionan los puentes por intención
- ¿Qué es el halving de Bitcoin?
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[1] Ethereum Improvement Proposals, ERC-2981: NFT Royalty Standard (estado Final, creado el 15 de septiembre de 2020) eips.ethereum.org
[2] Ethereum Improvement Proposals, ERC-721: Non-Fungible Token Standard (estado Final, creado el 24 de enero de 2018) eips.ethereum.org
