Buy Crypto
Markets
Spot
FuturesBTC
Earn
Event Center
More
0-Fee Fest
Interfaz ERC-721: ¿Qué es la interfaz ERC-721?La interfaz ERC-721 es un conjunto estandarizado de funciones y eventos de contratos inteligentes que se utiliza para representar y transferir tokens no fungibles en EthereInterfaz ERC-721: ¿Qué es la interfaz ERC-721?La interfaz ERC-721 es un conjunto estandarizado de funciones y eventos de contratos inteligentes que se utiliza para representar y transferir tokens no fungibles en Ethere

Interfaz ERC-721

2026/10/13 15:31
#Advanced
Humanity
H$0.05397-10.05%
Lagrange
LA$0.06307-5.41%
PX
PX$0.0125-4.58%
TokenFi
TOKEN$0.001992-6.52%
o1.exchange
O$0.4753-0.35%

¿Qué es la interfaz ERC-721?

La interfaz ERC-721 es un conjunto estandarizado de funciones y eventos de contratos inteligentes que se utiliza para representar y transferir tokens no fungibles en Ethereum y en redes blockchain compatibles.

Un token no fungible, o NFT, representa un token identificado de forma única, en lugar de una cantidad intercambiable de unidades idénticas.

La especificación oficial de ERC-721 define cómo las wallets, aplicaciones, contratos inteligentes y herramientas blockchain pueden comprobar la titularidad de los NFT y realizar transferencias estandarizadas.

La interfaz no determina qué representa un NFT, cuánto vale ni si el contenido vinculado es auténtico.

Define un lenguaje técnico común que pueden utilizar distintas aplicaciones cripto para interactuar con contratos de NFT.

El estándar ERC-721 alcanzó el estado Final en el proceso de propuestas de mejora de Ethereum y sigue siendo uno de los principales estándares para los activos únicos en blockchain.

ERC-721 se puede utilizar para coleccionables digitales, objetos de videojuegos, credenciales de membresía, terrenos virtuales, entradas para eventos, activos similares a dominios, posiciones financieras y registros tokenizados.

¿Por qué es importante una interfaz?

Una interfaz de contrato inteligente describe las funciones y los eventos externos que se espera que ofrezca un contrato compatible.

Sin una interfaz común, cada proyecto de NFT podría utilizar nombres de funciones y reglas de transferencia diferentes.

En ese caso, las wallets y aplicaciones descentralizadas necesitarían código personalizado para cada colección.

La interfaz ERC-721 permite al software llamar a funciones conocidas como

ownerOf
,
balanceOf
,
approve
y
safeTransferFrom
.

También estandariza eventos que permiten a los sistemas off-chain realizar un seguimiento de las transferencias y aprobaciones de NFT.

Un contrato puede añadir funciones adicionales a ERC-721 y seguir siendo compatible con el estándar básico.

La compatibilidad con la interfaz mejora la interoperabilidad, pero no garantiza que el contrato sea seguro ni que todas las aplicaciones admitan sus funciones personalizadas.

¿Qué hace que un token ERC-721 sea no fungible?

Cada token ERC-721 tiene un identificador entero único sin signo llamado ID de token.

El token queda identificado por completo mediante la combinación de la red blockchain, la dirección del contrato y el ID de token.

El ID de token 100 de un contrato no está relacionado con el ID de token 100 de otro contrato.

El estándar no exige que los ID de token empiecen en cero, aumenten en orden ni sigan un patrón predecible.

Las aplicaciones deben tratar cada ID de token como un identificador opaco, en lugar de deducir qué ID existen.

Según el modelo básico de titularidad de ERC-721, cada ID de token válido tiene un único titular en cada momento.

Un NFT se puede transferir como un token completo; la titularidad fraccionada requiere un contrato o una estructura de token aparte, fuera de la interfaz básica.

ID de la interfaz básica ERC-721

La interfaz básica ERC-721 se identifica mediante ERC-165 con el valor

0x80ac58cd
.

Un contrato compatible debe devolver

true
cuando se llama a
supportsInterface
con este identificador.

El estándar de detección de interfaces ERC-165 calcula un identificador de interfaz aplicando XOR a los selectores de las funciones que incluye dicha interfaz.

ERC-165 permite que una aplicación pregunte a un contrato qué interfaces estandarizadas afirma admitir antes de intentar interactuar con él.

Una respuesta afirmativa resulta útil para comprobar la compatibilidad, pero no demuestra por sí sola que todas las funciones estén implementadas correctamente.

Las aplicaciones que gestionan activos valiosos también pueden necesitar revisar el código, realizar pruebas y simular transacciones.

Funciones principales de ERC-721

La interfaz ERC-721 obligatoria incluye consultas de titularidad, funciones de transferencia y funciones de gestión de aprobaciones.

Las funciones principales son

balanceOf
,
ownerOf
,
safeTransferFrom
,
transferFrom
,
approve
,
setApprovalForAll
,
getApproved
e
isApprovedForAll
.

Una implementación compatible debe respetar el comportamiento exigido por el estándar, incluidas las comprobaciones de autorización y las condiciones de error.

La acuñación, la quema, los royalties, los límites de oferta, los precios y la administración de colecciones no están definidos por completo en la interfaz básica.

Los proyectos suelen añadir lógica independiente para esas funciones.

La función balanceOf

La función

balanceOf
devuelve el número de NFT que posee una dirección dentro de un contrato ERC-721.

No devuelve una cantidad de tokens divisible ni el valor financiero de los NFT.

Si una dirección posee los ID de token 4, 19 y 83 de la misma colección, su saldo es tres.

El estándar exige que falle una consulta para la dirección cero.

La función no indica qué ID de token concretos posee la dirección.

Para encontrar esos ID puede ser necesario indexar los eventos de transferencia o utilizar la interfaz enumerable opcional.

La función ownerOf

La función

ownerOf
devuelve el titular actual de un ID de token concreto.

Para un token existente, el titular devuelto no puede ser la dirección cero.

Según el estándar, una consulta sobre un token no válido o inexistente debe fallar.

La titularidad registrada por el contrato controla los derechos de transferencia básicos asociados al NFT.

No demuestra necesariamente la titularidad de los derechos de autor, las marcas, los bienes físicos u otros derechos legales.

Esos derechos dependen del acuerdo del proyecto, la legislación aplicable y los registros externos.

La función transferFrom

La función

transferFrom
transfiere un NFT de una dirección a otra después de comprobar la autorización y la titularidad.

Quien llama a la función debe ser el titular, la dirección específicamente aprobada o un operador autorizado por el titular.

La dirección

from
debe coincidir con el titular actual del NFT.

El destinatario no puede ser la dirección cero.

Esta función no exige que un contrato inteligente receptor confirme que puede gestionar NFT.

Un NFT enviado con

transferFrom
a un contrato incompatible puede quedar inaccesible permanentemente.

Por lo general, los usuarios y desarrolladores deben preferir una transferencia segura al enviar un NFT a un contrato desconocido.

Las funciones safeTransferFrom

ERC-721 define dos versiones sobrecargadas de

safeTransferFrom
.

Una versión incluye el emisor, el destinatario y el ID de token.

La otra añade un campo de bytes que puede contener datos específicos de la aplicación.

Ambas funciones realizan las comprobaciones habituales de titularidad y autorización.

Si el destinatario es un contrato inteligente, el proceso de transferencia llama a

onERC721Received
en ese contrato.

El destinatario debe devolver el selector esperado o se revierte toda la transferencia.

Esta comprobación reduce el riesgo de enviar un NFT a un contrato que no pueda gestionarlo.

No demuestra que el contrato receptor sea fiable ni que permita retirar el NFT más adelante.

¿Qué es IERC721Receiver?

IERC721Receiver
es la interfaz que implementa un contrato inteligente cuando quiere aceptar NFT mediante
safeTransferFrom
.

Su función obligatoria es

onERC721Received
.

La función recibe el operador, el titular anterior, el ID de token y los datos opcionales.

Un receptor que acepta la transferencia devuelve el selector de su función, normalmente representado como

0x150b7a02
.

Un valor de retorno incorrecto o una llamada revertida hacen que falle la transferencia segura.

La documentación actual de implementación de ERC-721 incluye una interfaz de receptor y una utilidad básica de custodia para los contratos que necesitan aceptar transferencias seguras.

Antes de utilizar la devolución de llamada para actualizar datos contables importantes, el receptor debe verificar qué contrato de NFT la ha llamado.

Riesgo de devolución de llamada del receptor ERC-721

Una transferencia segura a un contrato genera una llamada externa a ese destinatario.

El destinatario puede ejecutar código adicional antes de que finalice la transacción original.

Esto crea una posible vía de reentrancia si la aplicación emisora no ha completado sus actualizaciones de estado internas.

Un receptor malicioso puede intentar llamar a otra función del contrato original durante la devolución de llamada.

Las directrices de seguridad de contratos inteligentes de Solidity recomiendan completar las comprobaciones y los cambios de estado importantes antes de realizar interacciones externas, siempre que el diseño previsto lo permita.

Los desarrolladores deben probar las transferencias seguras de NFT con contratos receptores maliciosos, en lugar de dar por sentado que la devolución de llamada es inocua.

La función approve

La función

approve
concede a una dirección permiso para transferir un NFT concreto.

Normalmente, el titular del token o un operador autorizado puede conceder esta aprobación.

La dirección aprobada no se convierte en titular.

Recibe autorización para transferir el ID de token especificado.

Por lo general, la aprobación específica de un token se elimina cuando se transfiere el NFT.

Una llamada a

approve
con la dirección cero puede revocar una aprobación existente.

Los usuarios deben verificar la dirección aprobada, ya que un atacante con una aprobación válida puede transferir el NFT sin que el titular tenga que firmar otra autorización.

La función getApproved

La función

getApproved
devuelve la dirección que tiene actualmente la aprobación de un ID de token concreto.

Si no hay ninguna dirección con aprobación específica para el token, normalmente devuelve la dirección cero.

La función solo se aplica a un NFT existente válido.

No informa de las aprobaciones de operador que abarcan el saldo completo de una colección del titular.

Para determinar si otra dirección puede transferir el token, las aplicaciones también deben comprobar

isApprovedForAll
.

La función setApprovalForAll

La función

setApprovalForAll
autoriza a un operador para todos los tokens ERC-721 que posea quien la llama dentro de ese contrato, o revoca dicha autorización.

Un operador aprobado puede transferir los NFT existentes y los que el titular reciba posteriormente de la misma colección.

Este permiso es más amplio que una aprobación para un único ID de token.

Se suele utilizar cuando una aplicación necesita gestionar varios NFT sin solicitar una aprobación independiente para cada uno.

Un operador malicioso puede transferir todos los NFT afectados mientras el permiso siga activo.

Las wallets deben mostrar claramente la dirección de la colección y el alcance de la aprobación del operador.

La función isApprovedForAll

La función

isApprovedForAll
indica si un operador tiene autoridad sobre toda la colección para un titular concreto.

Devuelve un valor booleano, no una cantidad de tokens.

La autoridad del operador solo se aplica dentro del contrato ERC-721 que la concedió.

Una aprobación en una colección de NFT no se aplica automáticamente a otra.

Los usuarios deben revisar periódicamente los permisos activos de los operadores y revocar los que ya no necesiten.

Eventos ERC-721

La interfaz básica ERC-721 define los eventos

Transfer
,
Approval
y
ApprovalForAll
.

Estos registros de eventos permiten a las wallets, los indexadores, los sistemas de análisis y los exploradores de blockchain realizar un seguimiento de la actividad estandarizada de los NFT.

Los eventos ayudan al software off-chain a reconstruir el historial de titularidad y permisos.

Un evento de contrato demuestra lo que este emitió durante la ejecución, pero las aplicaciones deben confirmar igualmente que la transacción se completó correctamente y procedía del contrato esperado.

El evento Transfer

El evento

Transfer
registra al titular anterior, al nuevo titular y el ID de token.

Las transferencias normales incluyen direcciones de emisor y destinatario distintas de cero.

La acuñación suele representarse mediante una transferencia desde la dirección cero al primer titular.

La quema suele representarse mediante una transferencia del titular a la dirección cero.

La interfaz ERC-721 no define funciones públicas de acuñación o quema, aunque estos patrones de eventos permiten seguir el ciclo de vida del token.

Un evento que indique que se ha acuñado un NFT no demuestra que la colección tenga una oferta fija o una autoridad de acuñación restringida.

El evento Approval

El evento

Approval
registra una aprobación para un ID de token.

Identifica al titular, la dirección aprobada y el ID de token.

Las aplicaciones pueden utilizarlo para realizar un seguimiento de los cambios en la autoridad de transferencia específica de un token.

El evento no debe confundirse con una transferencia de titularidad, ya que el titular no cambia.

El evento ApprovalForAll

El evento

ApprovalForAll
registra si un titular ha habilitado o deshabilitado a un operador.

Incluye al titular, al operador y el estado de aprobación.

Es importante supervisar este evento, ya que la aprobación de un operador puede afectar a todos los NFT que el titular tenga en esa colección.

Un evento de revocación no revierte las transferencias que se hayan realizado mientras la autorización estaba activa.

Interfaz opcional de metadatos ERC-721

La extensión de metadatos añade

name
,
symbol
y
tokenURI
.

Su ID de interfaz ERC-165 es

0x5b5e139f
.

La extensión es opcional según la especificación oficial, aunque muchos contratos de NFT la implementan.

La función

name
devuelve el nombre descriptivo de la colección.

La función

symbol
devuelve un identificador breve elegido por el desarrollador del contrato.

La función

tokenURI
devuelve un URI asociado a un ID de token concreto.

Los nombres y símbolos de las colecciones no son únicos, por lo que no deben utilizarse como único método para verificar la autenticidad.

Cómo funciona tokenURI

La función

tokenURI
suele apuntar a un documento de metadatos JSON.

El documento puede incluir campos como un nombre para mostrar, una descripción, la ubicación de una imagen, una animación y atributos específicos del proyecto.

El URI puede ser una dirección HTTPS, un identificador de contenido descentralizado o un URI de datos on-chain.

El estándar oficial ERC-721 permite que los metadatos sean modificables.

Esto significa que el contenido que se muestra para un NFT puede cambiar después de su acuñación, a menos que el contrato o el proyecto ofrezcan garantías de inmutabilidad más sólidas.

La guía actual de desarrollo de ERC-721 señala que la parte que controla la ubicación de almacenamiento puede modificar los metadatos off-chain.

La titularidad del token no garantiza automáticamente que una imagen o un archivo externo siga estando disponible de forma permanente.

Interfaz enumerable opcional ERC-721

La extensión enumerable permite a las aplicaciones descubrir ID de token mediante consultas on-chain.

Su ID de interfaz ERC-165 es

0x780e9d63
.

Añade

totalSupply
,
tokenByIndex
y
tokenOfOwnerByIndex
.

La función

totalSupply
devuelve el número de tokens actualmente válidos que registra el contrato.

Las funciones de índice permiten consultar los ID de token de toda la oferta o de las tenencias de un titular.

La enumeración es opcional porque mantener índices adicionales de titularidad aumenta las escrituras de almacenamiento y el consumo de gas.

En su lugar, muchas aplicaciones reconstruyen las tenencias de NFT a partir de los eventos

Transfer
mediante indexación off-chain.

Acuñación y quema

La interfaz básica ERC-721 no exige una función pública de acuñación.

Cada proyecto decide si la acuñación es abierta, restringida, programada, limitada o está deshabilitada permanentemente.

El estándar tampoco exige una función pública de quema.

Una quema elimina un token de los registros de titularidad válida conforme a la implementación del contrato.

Los usuarios deben examinar quién puede acuñar o quemar NFT y si un administrador puede afectar a tokens que tengan otras cuentas.

Una interfaz de transferencia compatible no demuestra que la oferta del token sea fija.

Interfaz ERC-721 e implementación ERC-721

La interfaz define el comportamiento externo necesario para la compatibilidad.

La implementación contiene la lógica real de almacenamiento, autorización, transferencia, acuñación, metadatos y administración.

Dos contratos pueden admitir la misma interfaz ERC-721 y utilizar diseños internos muy distintos.

Una implementación puede ser inmutable y otra funcionar mediante un proxy actualizable.

Una puede tener una oferta fija, mientras que otra permite a un administrador acuñar tokens indefinidamente.

Una puede almacenar los metadatos on-chain y otra apuntar a un servidor modificable.

Los usuarios deben revisar la implementación, en lugar de considerar que la compatibilidad con la interfaz equivale a una evaluación de seguridad completa.

ERC-721 frente a ERC-20

ERC-20 representa saldos fungibles, mientras que ERC-721 representa tokens identificados individualmente.

Una cuenta ERC-20 puede tener una cantidad divisible, como 250 unidades.

Una cuenta ERC-721 posee un número de ID de token distintos.

La función ERC-721

balanceOf
indica cuántos NFT posee una cuenta, no la cantidad de un único ID de token.

ERC-721 no requiere un campo de decimales, ya que normalmente cada token se transfiere como una unidad completa.

Las aprobaciones también difieren, porque ERC-721 permite aprobar un token concreto o conceder a un operador el control de una colección.

ERC-721 frente a ERC-1155

ERC-721 se centra en tokens no fungibles identificados individualmente.

ERC-1155 permite que un contrato gestione muchos ID de token, incluidos activos fungibles, semifungibles y no fungibles.

Una cuenta ERC-1155 puede tener varias unidades de un mismo ID de token.

Un ID de token ERC-721 tiene un único titular y no mantiene un saldo por cantidad para cada cuenta.

El estándar más adecuado depende del modelo del activo, los patrones de transferencia, la necesidad de operaciones por lotes y los requisitos de la aplicación.

Royalties e interfaz ERC-721

La interfaz básica ERC-721 no define royalties para los creadores.

Una interfaz de royalties independiente puede comunicar un destinatario y una cantidad de pago sugeridos.

La información de royalties no obliga automáticamente a todos los sistemas de transferencia a realizar el pago.

Una colección que anuncie royalties debe explicar cómo se calculan y si pueden cambiar.

Los usuarios no deben suponer que un NFT ERC-721 incluye derechos de royalties permanentes o exigibles.

Riesgos de seguridad de las aprobaciones ERC-721

El phishing de aprobaciones es uno de los riesgos más importantes para los titulares de NFT.

Un sitio web malicioso puede solicitar

setApprovalForAll
y presentar la firma como una verificación de cuenta o un permiso para acceder a la colección.

Una vez concedida la aprobación, el operador puede transferir todos los NFT afectados sin otra autorización del titular.

Una aprobación específica para un token también puede permitir el robo del NFT identificado.

Antes de firmar, los usuarios deben inspeccionar la dirección del operador, el contrato del NFT, el tipo de permiso y la red.

Desconectar una wallet de un sitio web no revoca una aprobación que ya esté registrada on-chain.

Riesgo de transferencia insegura

La función

transferFrom
puede enviar un NFT a un contrato que carezca de un mecanismo de recuperación.

La transacción puede completarse aunque nadie pueda hacer que el contrato receptor vuelva a transferir el NFT.

Por este motivo se prefiere

safeTransferFrom
para las transferencias a contratos.

Sin embargo, la recepción segura solo demuestra que el contrato devolvió el valor esperado en la devolución de llamada.

No garantiza que el destinatario disponga de una vía legítima para retirar el NFT.

Riesgos de los metadatos y la autenticidad

Cualquiera puede desplegar un contrato ERC-721 con el nombre o el símbolo de una colección conocida.

La dirección del contrato es el identificador técnico más importante de una colección.

Los metadatos también pueden contener nombres engañosos, obras copiadas, enlaces externos inseguros o archivos que no están disponibles.

Un URI de token controlado por el administrador del proyecto puede apuntar posteriormente a otro contenido.

La titularidad on-chain no verifica por sí sola la identidad del creador ni los derechos de propiedad intelectual.

Los usuarios deben confirmar la dirección de la colección y la información del proyecto mediante fuentes autorizadas.

Riesgo de contratos actualizables

Una implementación ERC-721 puede funcionar detrás de un proxy actualizable.

Un administrador autorizado puede cambiar las reglas de transferencia, la lógica de los metadatos, los derechos de acuñación u otros comportamientos después de que los usuarios adquieran NFT.

Las actualizaciones pueden corregir errores, pero también generan riesgos de gobernanza y de compromiso de claves.

Los usuarios deben revisar los permisos de actualización, los retrasos temporales, los controles multifirma y los roles de administrador.

La compatibilidad con la interfaz ERC-721 no revela todas las funciones privilegiadas de la implementación.

Cómo deben implementar ERC-721 los desarrolladores

Los desarrolladores deben partir de una implementación revisada y mantenida activamente, en lugar de reescribir sin una razón de peso la lógica sensible de titularidad.

La API ERC-721 actual de OpenZeppelin ofrece componentes básicos, de metadatos, enumerables, pausables, quemables, de royalties, de votación y relacionados con receptores.

El acceso a la acuñación debe restringirse conforme a la política de oferta documentada de la colección.

Conviene considerar la acuñación segura cuando los NFT puedan acuñarse directamente en contratos inteligentes.

Las devoluciones de llamada de receptores deben tratarse como llamadas externas con posible comportamiento de reentrancia.

Las pruebas deben abarcar la titularidad, las aprobaciones, los permisos de operadores, los receptores seguros y maliciosos, las quemas, los ID de token no válidos y las transferencias no autorizadas.

Los desarrolladores también deben probar que la detección de interfaces devuelve los valores correctos para cada extensión implementada.

Cómo pueden detectar las aplicaciones la compatibilidad con ERC-721

Una aplicación puede llamar a

supportsInterface
con el ID de la interfaz básica ERC-721.

Un valor de retorno

true
indica que el contrato afirma implementar la interfaz.

La aplicación puede comprobar por separado los ID de las interfaces de metadatos o enumeración.

La detección de interfaces es más fiable que deducir la compatibilidad solo por los nombres de las funciones.

Sin embargo, los contratos mal escritos o engañosos pueden devolver información incorrecta.

Las aplicaciones deben gestionar de forma segura las llamadas fallidas y los comportamientos inesperados, en lugar de dar por sentado que todos los contratos cumplen el estándar.

Ejemplo de transferencia ERC-721

Supongamos que Alice posee el ID de token 42 de un contrato ERC-721.

La función

ownerOf
del contrato devuelve la dirección de Alice para el ID de token 42.

Alice decide enviar el NFT a un contrato inteligente.

Su wallet llama a

safeTransferFrom
con la dirección de Alice, el contrato receptor y el ID de token 42.

El contrato del NFT verifica que Alice es la titular y está autorizada para transferirlo.

Actualiza la titularidad y llama a

onERC721Received
en el destinatario.

El destinatario comprueba el contrato del NFT, el operador, el titular anterior y el ID de token.

Si el destinatario devuelve el selector correcto, la transferencia se completa y se emite un evento

Transfer
.

Si el destinatario rechaza la devolución de llamada, toda la transacción se revierte y Alice sigue siendo la titular.

Errores habituales con la interfaz ERC-721

Un error habitual es suponer que el nombre de una colección identifica de manera exclusiva un contrato de NFT.

Otro es tratar

balanceOf
como la cantidad de un único ID de token.

Un tercer error es utilizar

transferFrom
para enviar NFT a un contrato inteligente desconocido.

Un cuarto error es conceder a un operador una aprobación para toda la colección sin revisar su dirección.

Un quinto error es suponer que desconectar una wallet revoca las aprobaciones on-chain.

Un sexto error es dar por sentado que los metadatos están almacenados permanentemente on-chain sin comprobar el URI del token.

Un séptimo error es asumir que ERC-721 incluye royalties obligatorios.

Un octavo error es suponer que todos los contratos ERC-721 admiten la enumeración.

Un noveno error es ignorar el riesgo de reentrancia durante la devolución de llamada del receptor.

Un décimo error es considerar que la compatibilidad con ERC-165 demuestra que la implementación es segura o auténtica.

Preguntas frecuentes

¿Qué es la interfaz ERC-721?

La interfaz ERC-721 es un conjunto estandarizado de funciones y eventos para registrar la titularidad, las aprobaciones y las transferencias de tokens no fungibles.

¿Cuál es el ID de la interfaz ERC-721?

El ID de la interfaz básica ERC-721 es

0x80ac58cd
.

¿Qué devuelve balanceOf en un contrato ERC-721?

Devuelve el número de NFT distintos de ese contrato que posee una dirección.

¿Qué hace ownerOf?

Devuelve el titular actual de un ID de token válido.

¿Cuál es la diferencia entre transferFrom y safeTransferFrom?

safeTransferFrom
comprueba si el contrato receptor admite la devolución de llamada del receptor ERC-721, mientras que
transferFrom
no lo hace.

¿Qué es onERC721Received?

Es la función de devolución de llamada que implementa un contrato inteligente para confirmar que puede aceptar un NFT mediante una transferencia segura.

¿Puede fallar una transferencia segura de NFT?

Sí. Falla si no se superan las comprobaciones de autorización o si el contrato receptor no devuelve el selector de devolución de llamada esperado.

¿Qué hace approve?

Autoriza a una dirección a transferir un NFT concreto.

¿Qué hace setApprovalForAll?

Concede a un operador autoridad sobre todos los NFT que quien llama posea en ese contrato ERC-721.

¿Caduca automáticamente la aprobación de un operador?

No. Una aprobación estándar para toda la colección permanece activa hasta que el titular la revoca o el contrato aplica otras reglas personalizadas.

¿Se elimina la aprobación específica de un NFT al transferirlo?

Sí. Una implementación ERC-721 normal elimina durante la transferencia la aprobación asociada a ese token.

¿ERC-721 exige metadatos?

No. La interfaz de metadatos es opcional, aunque la mayoría de las colecciones de NFT la implementan.

¿Cuál es el ID de la interfaz de metadatos ERC-721?

La extensión de metadatos utiliza el ID de interfaz

0x5b5e139f
.

¿Cuál es el ID de la interfaz enumerable ERC-721?

La extensión enumerable utiliza el ID de interfaz

0x780e9d63
.

¿Todos los contratos ERC-721 admiten totalSupply?

No.

totalSupply
forma parte de la extensión enumerable opcional.

¿ERC-721 exige una función de acuñación?

No. La interfaz básica no define cómo los usuarios o administradores acuñan NFT.

¿ERC-721 exige una función de quema?

No. La quema es una función de la implementación, no una función básica obligatoria.

¿ERC-721 impone royalties?

No. Los royalties quedan fuera de la interfaz básica ERC-721 y requieren lógica o estándares independientes.

¿Pueden cambiar los metadatos ERC-721?

Sí. El estándar permite que el URI del token sea modificable, salvo que la implementación ofrezca garantías de inmutabilidad más sólidas.

¿Cumplir ERC-721 demuestra que un NFT es auténtico?

No. Cualquiera puede desplegar un contrato compatible, por lo que los usuarios deben verificar por separado la dirección del contrato y el emisor.

Conclusión

La interfaz ERC-721 proporciona las reglas comunes de titularidad, aprobación, transferencia y eventos que utilizan los tokens no fungibles en aplicaciones compatibles con Ethereum.

Su ID de interfaz básica es

0x80ac58cd
, que los contratos publican mediante la detección de interfaces ERC-165.

Las funciones obligatorias permiten a las aplicaciones consultar saldos y titulares, aprobar permisos de transferencia y mover ID de token únicos.

Las funciones de transferencia segura reducen el riesgo de envíos accidentales a contratos incompatibles al exigir una devolución de llamada del receptor ERC-721.

Esa devolución de llamada también genera un riesgo de llamada externa y reentrancia que los desarrolladores deben gestionar con cuidado.

Las interfaces de metadatos y enumeración son opcionales y tienen identificadores independientes, además de consideraciones adicionales de gas y confianza.

El estándar no define los permisos de acuñación, los derechos de quema, los royalties, los límites de oferta, la permanencia de los metadatos, la titularidad legal ni la autenticidad de una colección.

Antes de interactuar con un NFT, los usuarios deben verificar las direcciones de los contratos, revisar las aprobaciones de operadores, inspeccionar el almacenamiento de los metadatos y entender los permisos de actualización.

Los desarrolladores deben utilizar implementaciones mantenidas, probar todas las rutas de autorización y tratar las devoluciones de llamada de receptores de NFT como código potencialmente hostil.

Entender la interfaz ERC-721 ayuda a los usuarios de criptomonedas a distinguir la compatibilidad estandarizada de NFT de las propiedades económicas, legales y de seguridad más amplias de cada colección.
¿Retroceso u oportunidad?
¿Retroceso u oportunidad?¿Retroceso u oportunidad?
$2400M en entradas a ETF de BTC pese a liquidaciones