Tiempo estimado: 4 minutos de lectura

Análisis técnico del cumplimiento de royalties en contratos NFT mediante Payment Processor y Transfer Validator v5. Incluye listas autorizadas, niveles de seguridad, configuración de rulesets y ejemplos prácticos con marketplaces compatibles para la validación on-chain de transferencias ERC-721.

¿Cómo Garantizar los derechos de autor en un contrato de NFT?

En uno de mis anteriores artículos se describe en qué consisten los derechos de autor en un contrato de NFT y de qué formas se pueden establecer.

Es necesario sin embargo dar solución a la cuestión principal: cómo garantizar que el beneficiario de los derechos de autor percibirá la cantidad estipulada después de una transacción comercial.

El esquema más sencillo delega en el buen hacer del marketplace en que ocurre la transacción. Casos como OpenSea y Rarible figuran entre las plataformas que garantizan de forma fehaciente el cumplimiento estricto de las condiciones fijadas en los derechos.

Se observa en la siguiente captura de pantalla como se muestran con claridad las royalties de una colección de NFT particular a través del portal Rarible.

Derechos de autor en el marketplace Rarible

Sin embargo otros marketplaces pueden considerar los derechos de autor como algo opcional en función de las preferencias del comprador (por ejemplo así ocurre en Magic Eden) o incluso prescindir completamente de la gestión de derechos de autor.

Para forzar el cumplimiento de los derechos de autor ha surgido el protocolo Payment Processor de LimitBreak. Se trata de un smart contract que gestiona on-chain el cumplimiento de las royalties.

¿Cómo funciona el Payment Processor?

Los creadores de colecciones de NFTs puden interactuar con un registro externo (smart contract) de validación para permitir o bloquear las transferencias de sus NTFs basándose en el llamante, el ‘from’ y el ‘to’ de la transacción.

La versión 5 del Transfer Validator, incorpora numerosas mejoras con el objetivo de recoger la experiencia de uso de las versiones anteriores y aprovechar las últimas mejoras de Ethereum debidas a la actualización Pectra.

En esta nueva versión se trabaja con el concepto de lista y de nivel de seguridad.

La lista define que operadores están autorizados a efectuar transferencias de tokens en nombre del usuario. La lista por defecto, la 0, está configurada con aquellos smart contracts que han probado su cumplimiento riguroso de los derechos de autor. Entre ellos figuran principalmente los de OpenSea.

Por otra parte el nivel de seguridad se declara con un «rulesetId» para escoger entre varias opciones preconfiguradas como pueden ser whitelist, blacklist, soulbound o vanilla. La lista por defecto trabaja con el rulesetId=0 (tipo whitelist) configurado con una serie de opciones adicionales que definen el comportamiento básico.

Para garantizar el cumplimiento de los derechos de autor usando la configuración por defecto del Payment Processor sólo es preciso asegurar que la llamada «transferFrom» del contrato de NFT invoca internamente la función validateTransfer del TransferValidator.

/**
* @notice Apply the collection ruleset and options to a transfer operation of a creator token.
*
* @dev Modular rulesets with options determine the logic governing transfers.
*
* @dev Throws when the ruleset returns a non-zero error selector.
*
* @dev <h4>Postconditions:</h4>
*      1. Transfer is allowed or denied based on the ruleset.
*
* @param caller      The address initiating the transfer.
* @param from        The address of the token owner.
* @param to          The address of the token receiver.
*/
function validateTransfer(address caller, address from, address to) external view;

El smart contract del TransferValidator está desplegado en la misma dirección en las blockchain más extendidas.

¿Cómo añadir otros marketplaces confiables?

Hemos visto que la configuración por defecto admite las transferencias efectuadas desde OpenSea. Existen sin embargo otras plataformas igualmente respetuosas con los derechos de autor, como podría ser Rarible.

El procotolo del Payment Processor admite expandir la lista de smart contracts autorizados mediante varias configuraciones. En el caso que nos ocupa primero es necesario crear una lista ad-hoc distinta a la lista por defecto (listId=0). La forma más sencilla es utilizar la DApp de apptokens. Se conecta el wallet deseado en la blockchain objetivo y se accede a «Manage my collections» para invocar el método «createList» del TransferValidator y conseguir el correspondiente listId. La opción se encuentra en la pestaña de «Transfer Lists», en el botón «Create New List».

dapp apptokens

A partir de ahí es preciso configurar la nueva lista creada. Se puede efectuar con sencillez desde la misma DApp. La opción sería agregar al «allowlist» la lista de direcciones de los smart contracts que queremos autorizar para llevar a cabo tranferencias de NTFs. Para este ejemplo sería la dirección del Transfer Proxy de Rarible en la dirección 0xd47e14DD9b98411754f722B4c4074e14752Ada7C.

Añadir direcciones a la lista blanca

Para habilitar la nueva lista de smart contracts autorizados en una transferencia de tokens para una colección de NFTs en particular, hay que invocar los siguientes métodos del TransferValidator:

/**
* @notice Set the token type setting of a collection.
*
* @dev Throws when the caller is neither collection contract, nor the owner or admin 
* of the specified collection.
*
* @dev <h4>Postconditions:</h4>
*      1. The token type of the specified collection is set to the new value.
*      2. A `SetTokenType` event is emitted.
*
* @param collection  The address of the collection.
* @param tokenType   The token type, ie: 721.
*/
function setTokenTypeOfCollection(
    address collection, 
    uint16 tokenType
) external;

/**
* @notice Applies the specified list to a collection.
* 
* @dev Throws when the caller is neither collection contract, nor the owner or admin 
* of the specified collection.
* @dev Throws when the specified list id does not exist.
*
* @dev <h4>Postconditions:</h4>
*      1. The list of the specified collection is set to the new value.
*      2. An `AppliedListToCollection` event is emitted.
*
* @param collection The address of the collection.
* @param id         The id of the newly created list
*/
function applyListToCollection(address collection, uint48 id) external;


/**
* @notice Set the ruleset id, global / ruleset options, fixed / custom ruleset for a collection.
*
* @dev Throws when the caller is neither collection contract, nor the owner or admin 
* of the specified collection.
* @dev Throws when setting a custom ruleset to an unregistered ruleset address.
* @dev Throws when setting a ruleset id that is not bound to a ruleset address.
* @dev Throws when setting a custom ruleset with a managed ruleset id.
*
* @dev <h4>Postconditions:</h4>
*      1. The ruleset of the specified collection is set
*      to the new value.
*      2. Global options and ruleset-specific options of the specified collection
       are set to the new value.
*      3. A `SetCollectionRuleset` event is emitted.
*      4. A `SetCollectionSecurityPolicyOptions` event is emitted.
*
* @param collection The address of the collection.
* @param rulesetId The new ruleset id to apply. For whitelist type, set rulesetId=0
* @param customRuleset The address of the custom ruleset to apply. Must be address(0) unless 
         rulesetId is RULESET_ID_FIXED_OR_CUSTOM (255).
* @param globalOptions The global options to apply. Set a value of 8 so that default list extension 
         mode is enabled.
* @param rulesetOptions The ruleset-specific options to apply. Usually a 0 value.
*/
function setRulesetOfCollection(
    address collection, 
    uint8 rulesetId,
    address customRuleset,
    uint8 globalOptions,
    uint16 rulesetOptions
) external;

En esta página se detallan las opciones de configuración de un «Ruleset»

Lo más versátil y seguro es llamar estos métodos del TransferValidator directamente después de invocar al constructor del smart contract de la colección de NFTs, desde el mismo address propietario. Lo más cómodo es definir una interfaz Solidity con la declaración de los métodos e instanciarla en la dirección conocida del smart contract del TransferValidator.

Conclusión: forzando los derechos de autor on-chain

En los últimos artículos se ha detallado de qué forma se pueden definir las royalties por la transferencia de tokens en un contrato de NFT.

Si bien siempre es posible delegar y confiar en los distintos actores que toman parte en la compra-venta de tokens, por ejemplo en un determinado Marketplace que permita configurar off-chain la gestión de los derechos, dado el carácter descentralizado de la web3, parece más acorde gestionarlos sin intermediarios en la propia blockchain (on-chain).

La inciativa de LimitBreak se alinea con esta filosofía y permite a los creadores de contenido salvaguardar sus derechos por encima de los intereses particulares de los exchanges y plataformas de venta, todo ello de forma descentralizada


¿Has tenido que garantizar el cumplimiento de los derechos de autor en algún smart contrat? ¿Has optado por procolos on-chain o has utilizado algún servicio confiable fuera de la cadena?

Si eres un creador y quieres percibir los derechos de autor sin intermediarios, puedo ayudarte. Contáctame y hablemos de las opciones disponibles. ¡Muchas gracias!