Habilitación de regalías NFT con EIP-2981

Con la finalización del , los tokens no fungibles (NFT) comenzaron a recibir una gran atención. Estos activos probablemente únicos se almacenan en la cadena de bloques e introducen una nueva forma de recopilar e intercambiar arte, música, imágenes de perfil (PFP) y más. En el verano de 2021, la creación y venta de NFT se convirtió en una forma rápida de acumular riqueza debido al auge de su popularidad.

Sin embargo, al leer la especificación subyacente, notará que no hay funcionalidad para adquirir y dividir regalías en los estándares ERC721 o ERC1155. Estos estándares solo se ocupan del seguimiento del estado de propiedad, las aprobaciones y las transferencias directas. Si la interfaz no contiene ninguna característica nativa de regalías, como creador, ¿cómo puede hacer NFT que permitan la acumulación de riqueza mucho después de la venta inicial? ¿Y cómo se llevan su parte las plataformas comerciales, como OpenSea? ¿Y si tiene una situación de regalías más complicada, como dividir las regalías?

En este artículo, exploraremos varios aspectos de las regalías con NFT. Veremos formas de implementar regalías, incluidas soluciones propietarias, registros y EIP-2981. También veremos una forma de dividir los pagos. Finalmente, ejecutaremos un proyecto y veremos la división de regalías en acción. ¡Empecemos!

¿Qué son las regalías NFT?

Apenas unos meses después de que los primeros NFT vieran la luz, se crearon contratos de mercado que permitían a los titulares colocar etiquetas de precio en sus artículos, ofertar y pedir por ellos, e intercambiarlos de manera segura con otros. Muchos de estos mercados ni siquiera almacenan las transacciones de ofertas de sus usuarios en la cadena; sus contratos de emparejamiento recopilan firmas fuera de la cadena para intercambios y las almacenan en una infraestructura de servidor centralizada. La idea de poseer algo único en una cadena de bloques ha convertido a OpenSea en uno de los mercados más exitosos del mundo, siendo constantemente el número uno en la .

La verdadera historia de éxito de esos mercados que se descentralizan progresivamente se escribe a partir de las tarifas que cobran por operación. Por ejemplo, por cada Bored Ape negociado a 100 Eth, OpenSea gana constantemente la friolera de 2,5 Eth por cumplir el trato en la cadena. Un incentivo para retener a los creadores en sus plataformas de mercado era brindarles la opción de beneficiarse a largo plazo de las ventas del mercado secundario. Eso se conoce comúnmente como "regalías" en el espacio NFT.

Ganar dinero para los creadores de NFT: tarifas de acuñación y regalías

Cuando alguien lanza una colección básica de NFT mediante la implementación de un contrato ERC721, primero tendrá que pensar en acuñar, o ¿cómo cobran vida los nuevos tokens?

Puede que le sorprenda que ERC721 no define ninguna regla de acuñación predeterminada. Incluso su menciona el término "menta" solo una vez. Sin embargo, se volvió de sentido común que casi todos los contratos NFT coleccionables contienen un método "mint" que se invoca mediante el envío de tarifas. Los tokens recién acuñados se pueden intercambiar instantáneamente en las plataformas del mercado y, según la mecánica del mercado social, los activos recién acuñados pueden venderse por una gran cantidad de su tarifa de acuñación en cuestión de horas.

Las tarifas de acuñación pueden ser rentables para la cuenta del beneficiario de un contrato NFT. Sin embargo, el principal generador de ingresos de las colecciones populares son las regalías, también conocidas como tarifas que los mercados dividen del precio de venta cuando los artículos se comercializan en su plataforma. Dado que ERC721 no se relaciona con conceptos económicos y menos aún con el comercio de NFT, ¿cómo una colección de NFT impone un recorte de regalías para las ventas secundarias? ¿La respuesta sencilla? No puede.

Es importante comprender que las regalías no son un concepto exigible por una colección en sí. Ha habido intentos de construir contratos de cobro que vienen con su propia lógica de mercado y prohíben las transferencias fuera de su entorno controlado, pero nunca llamaron mucho la atención ya que los mercados se hacen en las plataformas dominantes.

Para ellos, los pagos de regalías son un concepto voluntario que cada mercado implementa individualmente. Entonces, cuando los contratos NFT solo se tratan como registros y mercados que administran los pagos de regalías individualmente, ¿cómo puede el propietario de una colección definir su esquema de regalías para que todos los mercados lo admitan?

Soluciones patentadas

La forma más sencilla para que un mercado descubra cuántas tarifas de regalías cobrar y dónde transferirlas es confiar en su propia interfaz patentada que implementa la colección. Un buen ejemplo es el contrato de intercambio de Rarible que intenta admitir todo tipo de interfaces de regalías externas, entre ellas dos que Rarible definió por sí mismo, siendo uno de los primeros jugadores en el espacio NFT:

 interface RoyaltiesV1 { event SecondarySaleFees(uint256 tokenId, address[] recipients, uint[] bps); function getFeeRecipients(uint256 id) external view returns (address payable[] memory); function getFeeBps(uint256 id) external view returns (uint[] memory); } interface RoyaltiesV2 { event RoyaltiesSet(uint256 tokenId, LibPart.Part[] royalties); function getRaribleV2Royalties(uint256 id) external view returns (LibPart.Part[] memory); }

Las colecciones de NFT podrían implementar esas interfaces para devolver la cantidad de regalías y una variedad de receptores. Luego, cuando se lleva a cabo un contrato de comercio en el mercado, el contrato comercial verifica si la colección NFT involucrada implementó una de esas interfaces, lo llama y usa sus valores de retorno para dividir las tarifas en consecuencia.

Tenga en cuenta que el precio de venta real no forma parte de las interfaces de los métodos. En su lugar, están cediendo la participación de regalías como puntos básicos (bps), un término comúnmente utilizado en esquemas de distribución de regalías y generalmente se traduce como 1/10000: una participación de 500 significa que el 5% del valor comercial debe enviarse a la colección. propietario como regalías.

Registros de regalías

Sin embargo, las interfaces propietarias pueden causar problemas. Los autores del contrato de NFT no pueden saber qué interfaces podrían ser obligatorias para implementar, ya que no pueden predecir en qué mercados se negociarán sus tokens. Peor aún, si lanzan un contrato de cobro antes de publicar los contratos de mercado relevantes, generalmente no hay una manera fácil de agregar más tarde el esquema de distribución de regalías respectivo.

Para resolver este problema, un consorcio de los principales mercados de NFT en torno a acordó implementar un contrato de registro en toda la industria que los creadores de colecciones pueden usar para señalar las divisiones de regalías independientemente de sus contratos de token. El de Royalty Registry revela que es compatible con muchas de las interfaces de mercado más importantes.

Por ejemplo, si el propietario de una colección de NFT solo implementó uno de los esquemas de distribución de regalías de Rarible mencionados anteriormente, otro mercado que no conozca esa interfaz puede simplemente llamar a la función getRoyaltyView del registro común. Intenta consultar todas las interfaces de regalías conocidas en el contrato de token y traduce cualquier respuesta a un resultado de uso común.

El registro incluso va un paso más allá. Los propietarios de colecciones que no han incluido ningún esquema de señalización de regalías en su contrato pueden implementar un contrato de “anulación” extendido y registrarlo en el registro común. Este método de registro garantizará que solo los propietarios de la colección (identificados por el miembro público owner ) puedan llamarlo.

EIP-2981: un estándar para la señalización de regalías NFT en los mercados

En 2020, algunas personas ambiciosas comenzaron a definir una interfaz común que sea lo suficientemente flexible para cubrir la mayoría de los casos de uso relacionados con regalías y que sea fácil de entender e implementar: EIP-2981. Define solo un método que los contratos NFT pueden implementar:

 function royaltyInfo(uint256 _tokenId, uint256 _salePrice) external view returns (address receiver, uint256 royaltyAmount);

Nótese su intencional falta de características: no se preocupa por una división entre varios partidos, ni impone ninguna noción de porcentajes o puntos base. Es muy claro para las personas que llaman lo que recibirán como valor de retorno y sencillo para los implementadores cómo lograrlo.

La interfaz también funciona completamente fuera de la cadena, por lo que los mercados que intercambian activos en infraestructura alternativa aún pueden consultar la tarifa del creador sin saber nada más que la firma de la interfaz del método EIP-2981.

La interfaz funciona para montos de venta indicados en Eth, así como en cualquier otra moneda. Un implementador solo tiene que dividir _salePrice por su base de cálculo y multiplicarlo por el porcentaje de regalías sobre la misma base. Si bien los implementadores pueden ejecutar una lógica compleja que calcula una regalía dinámica dependiendo de factores externos, es recomendable mantener la ejecución de este método lo más pequeña posible, ya que se ejecutará durante las transacciones de transferencia de ventas entre las partes comerciales, y se supone que sus tarifas de gas son preferiblemente bajo.

Para darle una idea de cómo podría verse una implementación EIP-2981 no trivial, aquí hay un fragmento que puede encontrar en las colecciones 1/1 NFT que señala la dirección del creador original y su reclamo de regalías a cualquier mercado compatible con el estándar:

 // contracts/Splice.sol // SPDX-License-Identifier: MIT pragma solidity 0.8.10; import '@openzeppelin/contracts/utils/math/SafeMath.sol'; contract OneOnOneNFTMarketPlace { using SafeMath for uint256; struct RoyaltyReceiver { address creator; uint8 royaltyPercent; } mapping(uint256 => RoyaltyReceiver) royalties; function mint( /*...mint args...*/ uint8 _royaltyPercent ) public { //... minting logic ... uint256 token_id = 1; royalties[token_id] = RoyaltyReceiver({ creator: msg.sender, royaltyPercent: _royaltyPercent }); } function royaltyInfo(uint256 tokenId, uint256 salePrice) public view returns (address receiver, uint256 royaltyAmount) { receiver = royalties[tokenId].creator; royaltyAmount = (royalties[tokenId].royaltyPercent * salePrice).div(100); } }

Si está utilizando los contratos base ERC721 de OpenZeppelin para crear contratos NFT, es posible que ya haya notado que recientemente agregaron un contrato base <code> </code> que contiene métodos de administración y miembros privados para simplificar el manejo de regalías de token dedicadas.

Regalías por impresiones ERC1155

Los mercados no son las únicas aplicaciones que permiten a sus usuarios beneficiarse de esquemas de regalías. Por ejemplo, EulerBeats de utiliza el estándar de tokens múltiples en su colección de contratos, que representan NFT que combinan melodías generadas por computadora y obras de arte generativas. Después de acuñar un token de semilla, los usuarios pueden obtener una cantidad limitada de impresiones y el precio de cada impresión aumenta a lo largo de una curva de vinculación definida por el contrato de token.

Cada vez , el contrato transfiere un 50 % de regalías de la tarifa de acuñación al propietario actual de la semilla. Si el lado receptor implementa la interfaz IEulerBeatsRoyaltyReceiver específica de la plataforma, incluso puede reaccionar a los pagos de regalías y ejecutar el código una vez que se haya acuñado una impresión de su semilla.

PaymentSplitters: envío de regalías NFT a más de un receptor.

EIP-2981 se queda corto para un caso de uso que otros enfoques resuelven de forma inmediata. Solo puede señalar una dirección de destinatario para regalías al lado solicitante. Como resultado, las situaciones que requieren que las regalías se dividan entre varios destinatarios deben implementarse individualmente.

Esto puede imponer varios problemas nuevos: en primer lugar, la persona que llama/el mercado no necesariamente tiene que enviar fondos junto con la misma transacción que activó la operación, pero podría decidir hacerlo más tarde, como en una llamada múltiple eficiente en gas desde otra cuenta. . En segundo lugar, las llamadas de pago a las direcciones pueden estar muy restringidas en el uso de gas. Se recomienda encarecidamente que cualquier en Solidity use la menor cantidad de gas posible, ya que es posible que los remitentes no sepan que están transfiriendo fondos a un contrato.

La consideración más importante es que enviar dinero directamente desde las interacciones del contrato impone el riesgo de encontrarse con agujeros de reingreso; por eso es muy recomendable favorecer mecanismos de extracción que permitan a los beneficiarios retirar sus ganancias de vez en cuando en lugar de enviar fondos directamente a direcciones desconocidas para el contrato de llamadas.

Por suerte, los contratos base de OpenZeppelin nos cubren de nuevo. Su primitiva permite establecer contratos divididos individuales que mantienen los fondos seguros hasta que los beneficiarios los reclaman, y su requiere el mínimo de gasolina para funcionar. Los creadores de colecciones de NFT pueden crear un PaymentSplitter en línea que contenga la lista deseada de beneficiarios y sus respectivos montos de acciones y permitir que su implementación EIP-2981 produzca la dirección de ese contrato dividido.

Las ventajas y desventajas de ese enfoque pueden ser despreciables para muchos casos de uso: las implementaciones de PaymentSplitter son comparativamente intensivas en gas y es imposible reemplazar beneficiarios o acciones una vez que se ha inicializado un divisor. En el se puede encontrar una implementación de muestra de cómo reemplazar efectivamente a los participantes del divisor y crear instancias de subcontratos eficientes en gas.

Prueba de pagos de regalías NFT con una bifurcación de Mainnet local

Diseñar mercados que interactúen con un contrato NFT arbitrario no es una tarea sencilla, ya que es impredecible si los contratos en redes activas se comportan de acuerdo con las interfaces de ERC. Sin embargo, puede ser útil probar nuestro código contra estos contratos usando . Esta poderosa herramienta nos permite crear una bifurcación instantánea de la red Ethereum en nuestra máquina local sin configurar nuestro propio nodo de cadena de bloques. En su lugar, se basa en los nodos de para leer el estado actual de los contratos y las cuentas con las que estamos interactuando.

Antes de comenzar nuestra instancia de blockchain, clonemos el repositorio de nuestra prueba de concepto, cambiemos al nuevo directorio e instalemos las dependencias:

 git clone //github.com/elmariachi111/royalty-marketplace.git cd royalty-marketplace npm i

Para ver lo que sucede en este ejemplo de mercado de NFT, echemos un vistazo al código ClosedDesert.sol en la carpeta de contratos .

 // SPDX-License-Identifier: MIT pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/ERC721/IERC721.sol"; import "@openzeppelin/contracts/utils/Address.sol"; import "@openzeppelin/contracts/security/ReentrancyGuard.sol"; import "@openzeppelin/contracts/token/common/ERC2981.sol"; import "@manifoldxyz/royalty-registry-solidity/contracts/IRoyaltyEngineV1.sol"; struct Offer { IERC721 collection; uint256 token_id; uint256 priceInWei; } /** * DO NOT USE IN PRODUCTION! * a fixed reserve price marketplace */ contract ClosedDesert is ReentrancyGuard { mapping(bytes32 => Offer) public offers; // //royaltyregistry.xyz/lookup IRoyaltyEngineV1 royaltyEngineMainnet = IRoyaltyEngineV1(0x0385603ab55642cb4Dd5De3aE9e306809991804f); event OnSale(bytes32 offerHash, address indexed collection, uint256 token_id, address indexed owner); event Bought(address indexed collection, uint256 token_id, address buyer, uint256 price); function sellNFT(IERC721 collection, uint256 token_id, uint256 priceInWei) public { require(collection.ownerOf(token_id) == msg.sender, "must own the NFT"); require(collection.getApproved(token_id) == address(this), "must approve the marketplace to sell"); bytes32 offerHash = keccak256(abi.encodePacked(collection, token_id)); offers[offerHash] = Offer({ collection: collection, token_id: token_id, priceInWei: priceInWei }); emit OnSale(offerHash, address(collection), token_id, msg.sender); } function buyNft(bytes32 offerHash) public payable nonReentrant { Offer memory offer = offers[offerHash]; require(address(offer.collection) != address(0x0), "no such offer"); require(msg.value >= offer.priceInWei, "reserve price not met"); address payable owner = payable(offer.collection.ownerOf(offer.token_id)); emit Bought(address(offer.collection), offer.token_id, msg.sender, offer.priceInWei); // effect: clear offer delete offers[offerHash]; (address payable[] memory recipients, uint256[] memory amounts) = royaltyEngineMainnet.getRoyalty(address(offer.collection), offer.token_id, msg.value); uint256 payoutToSeller = offer.priceInWei; //transfer royalties for(uint i = 0; i < recipients.length; i++) { payoutToSeller = payoutToSeller - amounts[i]; Address.sendValue(recipients[i], amounts[i]); } //transfer remaining sales revenue to seller Address.sendValue(owner, payoutToSeller); //finally transfer asset offer.collection.safeTransferFrom(owner, msg.sender, offer.token_id); } } }

En nuestro ejemplo, los vendedores pueden publicar sus activos por un precio de venta fijo después de que se aprueben las transferencias. Los compradores pueden estar atentos a los eventos OnSale y responder emitiendo transacciones buyNft y enviando el valor Eth deseado. El contrato de mercado verifica el de la red principal abierta durante una transacción de venta para ver si los propietarios de la colección están solicitando regalías y luego las paga en consecuencia. Como se indicó anteriormente, el registro público de regalías ya tiene en cuenta los contratos compatibles con EIP-2981. Aún así, también es compatible con muchos otros esquemas de distribución patentados.

A continuación, implementaremos nuestra instancia de blockchain local y probaremos nuestro contrato utilizando las cuentas y NFT de usuarios reales.

Para probar el comportamiento del contrato en condiciones de red principal, primero necesitamos acceder a un solicitando una identificación de proyecto e instalando en nuestra máquina. Luego podemos usar nuestro mercado de NFT favorito para buscar una colección y encontrar una cuenta de titular de NFT que desempeñará el papel de vendedor en nuestra prueba. El vendedor debe poseer realmente el NFT que venderemos.

Finalmente, encuentre una cuenta con suficientes fondos de la red principal (al menos 1 Eth) para pagar el precio de venta solicitado por el vendedor. Con estas cuentas y herramientas a mano, podemos activar una instancia local de la red principal de Ganache usando el siguiente comando en una nueva ventana de terminal:

 npx ganache --fork //mainnet.infura.io/v3/<infuraid> --unlock <0xseller-account> --unlock <0xbuyer-account>

Asegúrese de usar su propio punto final de la red principal de Infura para la URL en el comando anterior.

Si tiene problemas para encontrar cuentas para desbloquear, aquí hay un par para probar:

Dirección del vendedor: 0x27b4582d577d024175ed7ffb7008cc2b1ba7e1c2 Dirección del comprador: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

Nota: Debido a que estamos simulando la red principal de Ethereum en nuestra instancia de Ganache, para cuando lea esto, es posible que el vendedor ya no posea el NFT que venderemos o que el comprador ya no tenga suficiente Eth para realizar la compra. Entonces, si estas direcciones no funcionan, tendrá que encontrar una que cumpla con los criterios anteriores.

Usando las direcciones de ejemplo anteriores, nuestro comando se ve así:

 npx ganache --fork //mainnet.infura.io/v3/<infuraid> --unlock 0x27b4582d577d024175ed7ffb7008cc2b1ba7e1c2 --unlock 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

A continuación, en nuestra ventana de terminal original, compilaremos e implementaremos el contrato de mercado desde el repositorio y elegiremos nuestro proveedor de bifurcación de red principal local, que se puede encontrar en truffle-config.js :

 npx truffle compile npx truffle migrate --network mainfork

Ahora podemos probar nuestro contrato de mercado con reconocimiento de regalías en condiciones de red principal sin pagar un centavo por los costos del gas. Todas las próximas transacciones serán ejecutadas por la cadena local Ganache en nombre de las cuentas de usuarios reales.

Echemos un vistazo a la secuencia de comandos testMarketplace.js (que se encuentra en la carpeta de secuencias de comandos ) que usaremos para interactuar con nuestro contrato inteligente de mercado implementado:

 const ClosedDesert = artifacts.require("ClosedDesert"); const IErc721 = require("../build/contracts/IERC721.json"); //Change these constants: const collectionAddress = "0xed5af388653567af2f388e6224dc7c4b3241c544"; // Azuki const tokenId = 9183; let sellerAddress = "0x27b4582d577d024175ed7ffb7008cc2b1ba7e1c2"; const buyerAddress = "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"; module.exports = async function(callback) { try { const marketplace = await ClosedDesert.deployed(); const erc721 = new web3.eth.Contract(IErc721.abi, collectionAddress); const salesPrice = web3.utils.toWei("1", "ether"); //buyerAddress = await web3.utils.toChecksumAddress(buyerAddress); // marketplace needs the seller's approval to transfer their tokens const approval = await erc721.methods.approve(marketplace.address, tokenId).send({from: sellerAddress}); const sellReceipt = await marketplace.sellNFT(collectionAddress, tokenId, salesPrice, { from: sellerAddress }); const { offerHash } = sellReceipt.logs[0].args; const oldOwner = await erc721.methods.ownerOf(tokenId).call(); console.log(`owner of ${collectionAddress} #${tokenId}`, oldOwner); const oldSellerBalance = web3.utils.toBN(await web3.eth.getBalance(sellerAddress)); console.log("Seller Balance (Eth):", web3.utils.fromWei(oldSellerBalance)); // buyer buys the item for a sales price of 1 Eth const buyReceipt = await marketplace.buyNft(offerHash, {from: buyerAddress, value: salesPrice}); const newOwner = await erc721.methods.ownerOf(tokenId).call(); console.log(`owner of ${collectionAddress} #${tokenId}`, newOwner); const newSellerBalance = web3.utils.toBN(await web3.eth.getBalance(sellerAddress)); console.log("Seller Balance (Eth):", web3.utils.fromWei(newSellerBalance)); console.log("Seller Balance Diff (Eth):", web3.utils.fromWei(newSellerBalance.sub(oldSellerBalance))); } catch(e) { console.error(e) } finally { callback(); } }

Nota : Las constantes collectionAddress , sellerAddress y buyerAddress deben ser direcciones de red principales legítimas que cumplan con los criterios mencionados anteriormente, mientras que sellerAddress y buyerAddress deben estar desbloqueadas en su instancia de Ganache. La constante tokenId también debe ser el tokenId real del NFT que posee el vendedor.

En este script auxiliar, estamos configurando referencias a los contratos con los que interactuaremos. Decidimos obtener la compatible con EIP-2981 en el código de muestra, pero podría ser cualquier colección NFT. Ejecutamos el script usando el siguiente comando:

 npx truffle exec scripts/testMarketplace.js --network mainfork

Si todo funcionó correctamente, debería recibir un resultado en su consola como el siguiente:

 owner of Azuki 0xed5af388653567af2f388e6224dc7c4b3241c544 #9183 0x27b4582D577d024175ed7FFB7008cC2B1ba7e1C2 Seller Balance (Eth): 0.5655418 owner of Azuki 0xed5af388653567af2f388e6224dc7c4b3241c544 #9183 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 Seller Balance (Eth): 1.0655418 Seller Balance Diff (Eth): 0.95

Repasemos los pasos que acaban de suceder para que podamos entender cómo funciona. Primero, el guión requiere la aprobación del vendedor para transferir su NFT una vez que se vende, un paso que generalmente manejan los contratos de mercado respectivos. Luego, creamos una oferta de venta llamando a sellNft en nombre del propietario actual. Finalmente, simplemente reutilizamos el hash de oferta contenido en el evento de venta y dejamos que nuestro comprador llame al método buyNft y envíe el precio de venta solicitado de 1 Eth.

Cuando compare el saldo del vendedor antes y después de la transacción, notará que no recibió la cantidad solicitada de 1 Eth, sino solo 0,95. Los fondos restantes se transfirieron a los destinatarios de las regalías de Azuki, tal como lo indicó el contrato de registro de regalías de la red principal.

Conclusión

Las regalías son el principal impulsor del éxito en el espacio NFT. Siendo anteriormente una característica adicional de los mercados propietarios, se han convertido en una propiedad obligatoria de la economía de fichas no fungibles. Extienden la promesa a cualquier creador de colecciones de NFT de obtener ganancias cuando sus creaciones comiencen a atraer a una amplia audiencia. Son un excelente concepto económico para distribuir los ingresos por ventas de una manera que brinda incentivos a los autores del código original o artistas de NFT.

ERC721 no contiene ninguna noción de características económicas; por lo tanto, las regalías NFT no pueden ser aplicadas directamente por los contratos de fichas. En cambio, los creadores del mercado tuvieron que proporcionar interfaces para los contratos de token para señalar su reclamo sobre las tarifas comerciales y dónde enviarlas. La interfaz de señalización de regalías EIP-2981 es un estándar de la industria conciso y poderoso para lograrlo sin agregar más complejidad al lado del implementador. Cada nuevo contrato ERC721 debe considerar la implementación de al menos una señal de regalías básica para que las herramientas de mercado propietarias puedan detectarlo y consultarlo.