ERC-6551: Cómo los NFTs pueden poseer billeteras

Los tokens no fungibles (NFTs) están evolucionando de coleccionables estáticos a identidades programables que pueden poseer activos, realizar transacciones e interactuar con aplicaciones descentralizadas. ERC‑6551, también conocido como Cuentas Vinculadas a Tokens (TBAs), es el estándar que hace esto posible al otorgar a cada NFT su propia cuenta inteligente. Este artículo explica cómo funciona ERC‑6551, por qué es importante y qué considerar en cuanto a seguridad y experiencia de usuario (UX), con referencias prácticas para constructores y usuarios.

Qué es ERC‑6551, en una frase

ERC‑6551 define un registro y una interfaz de cuenta que vincula una billetera de contrato inteligente a un NFT ERC‑721, permitiendo que el NFT posea tokens, NFTs y permisos, y ejecute transacciones independientemente del propietario humano, mientras que el control sigue automáticamente al propietario actual de ese NFT. Consulte la especificación para obtener detalles en el EIP oficial: EIP‑6551: Cuentas Vinculadas a Tokens.

Los bloques de construcción

• NFTs ERC‑721: ERC‑6551 está diseñado para ERC‑721, el estándar canónico de NFT en Ethereum y cadenas EVM. Si necesita un repaso sobre la semántica de propiedad de ERC‑721, consulte la documentación de Ethereum: Estándar de Token No Fungible ERC‑721.
• El Registro: Un único contrato de registro expone las funciones createAccount y account para desplegar o calcular la dirección de una TBA para cualquier NFT dado (chainId, tokenContract, tokenId). Permite direcciones deterministas a través de CREATE2, por lo que una TBA puede conocerse antes de ser desplegada. Referencia: EIP‑1014 (CREATE2).
• La Cuenta: Una TBA es un contrato de billetera inteligente que implementa la interfaz de cuenta ERC‑6551 (por ejemplo, executeCall, owner, isValidSignature). Puede poseer ERC‑20, otros NFTs y metadatos. Las comprobaciones de control se resuelven al propietario actual del NFT.

Visión general para desarrolladores y ejemplos: Documentación de TokenBound. Para una introducción accesible, consulte la descripción general de Alchemy: ¿Qué es ERC‑6551? y la explicación de thirdweb: ERC‑6551: Cuentas Vinculadas a Tokens.

Cómo los NFTs pueden poseer billeteras (mecánica)

1. Derivación de dirección: La dirección de la TBA se deriva de forma determinista de las entradas: chainId, contrato NFT, tokenId, implementación y salt a través de CREATE2. Puede calcularla sin desplegar la cuenta.
2. Despliegue de cuenta: Cuando es necesario, el registro despliega la cuenta. La identidad del NFT ahora tiene una billetera de contrato inteligente.
3. Flujo de control: La función owner() de la cuenta lee al poseedor actual del NFT. Cuando el NFT se transfiere, el control de la TBA sigue automáticamente al nuevo propietario, sin necesidad de mover claves o firmas.
4. Ejecución: El propietario (o los operadores permitidos) pueden activar executeCall para interactuar con DeFi, acuñar activos o gestionar permisos desde la identidad de la TBA en lugar de una cuenta externa (EOA) humana.
5. Componibilidad: La TBA puede poseer sus propios ERC‑20, otros ERC‑721 y permisos en cadena. El NFT se convierte en una "cápsula" autocontenida de activos y capacidades.

Por qué es importante

• Avatares componibles: El NFT de un personaje de juego puede poseer NFTs de equipamiento, pociones (ERC‑20) y logros. Al intercambiar el personaje, se intercambia toda la carga, no solo el token base. Arquitectura de ejemplo: Documentación de TokenBound.
• Identidad portable: Un único NFT puede representar una identidad multiplataforma con historial de billetera, insignias de reputación y credenciales de acceso que posee directamente.
• Paquetes líquidos: Los creadores pueden vender una colección de activos transfiriendo un único NFT; el comprador recibe todo el inventario que posee su TBA.
• Delegaciones más seguras: En lugar de delegar desde su EOA personal, puede delegar acceso desde la TBA del NFT con ámbitos controlados.
• Sinergia de abstracción de cuenta: Las TBAs se pueden implementar como cuentas inteligentes compatibles con flujos avanzados como claves de sesión y pagadores de gas. Para obtener información de fondo, consulte EIP‑4337: Abstracción de Cuenta.

Señales del ecosistema actual

• Estandarización: ERC‑6551 es un EIP aceptado con un registro de referencia y una interfaz de cuenta, lo que permite un soporte coherente entre proyectos. Especificación: EIP‑6551.
• Bibliotecas y herramientas: Los SDKs y las direcciones de registro de TokenBound facilitan la integración de TBAs en dApps. Documentación: Documentación de TokenBound.
• Educación para desarrolladores: Las principales plataformas para desarrolladores ahora ofrecen guías y plantillas para ERC‑6551, lo que indica una creciente adopción y experimentación. Referencias: Descripción general de Alchemy y explicación de thirdweb.

Como ocurre con la mayoría de los estándares, el soporte de UI en billeteras y mercados varía según la cadena y el proyecto. Espere un progreso continuo hasta 2025 a medida que los juegos, los protocolos sociales y los proveedores de infraestructura de NFT añadan interacciones nativas con TBAs.

Patrones centrales de UX

• NFTs de inventario: Permita que la TBA del personaje posea los elementos que el jugador adquiere en el juego. Listar el personaje transfiere todo el inventario.
• Preajustes de permisos: Almacene claves de sesión o delegados con ámbitos en la TBA para una jugabilidad o acciones sociales fluidas, en lugar de aprobaciones globales desde una EOA personal.
• Divulgación progresiva: En la interfaz de usuario, presente "Propiedad del NFT" como el actor principal al interactuar con una dApp, minimizando la confusión entre la EOA de un usuario y la TBA del NFT.
• Paquetes portátiles: Habilite las políticas definidas por el creador como "transferir con contenido" o "eliminar contenido al transferir" para equilibrar la seguridad y la utilidad.

Modelo de seguridad y mejores prácticas

Las TBAs mejoran la componibilidad pero introducen nuevos riesgos operativos. Considere:

• Propagación de aprobaciones: Si la TBA tiene aprobaciones pendientes (concesiones de ERC‑20 o aprobaciones de NFT), la transferencia del NFT otorga esas aprobaciones al comprador. Esto puede ser peligroso si se aprobó a un gastador malicioso. Patrones más seguros:
  • Borrar concesiones al transferir o al listar para la venta.
  • Utilizar límites de gasto en lugar de aprobaciones ilimitadas.
  • Mostrar advertencias de concesión en la interfaz de usuario antes de la transferencia.
• Comprobaciones de propiedad: Asegúrese de que la cuenta imponga owner() de manera consistente con el poseedor actual de ERC‑721 en el momento de la ejecución. Siga las interfaces definidas en la especificación: EIP‑6551.
• Alcance de replay y firma: Si su TBA admite firmas fuera de cadena (isValidSignature), protéjase contra replay en diferentes cadenas y contratos; utilice estructuras EIP‑712 separadas por dominio.
• Riesgos de actualizabilidad: Si utiliza TBAs actualizables, proteja la lógica de administrador y actualización; prefiera implementaciones mínimas y auditadas.
• Recuperación y guardianes: Considere flujos de respaldo (por ejemplo, recuperación social) a nivel de TBA o a través de la cuenta propietaria controladora para casos de uso de consumidores.
• Coordinación de mercado: Si el contenido afecta materialmente el valor, los mercados deben reflejar las posesiones y aprobaciones de la TBA. Los constructores pueden exponer los inventarios de TBA a través de indexadores.

Para obtener orientación sobre la implementación y notas de seguridad, comience con la documentación oficial: Documentación de TokenBound.

Inicio rápido para desarrolladores (conceptual)

• Calcule la dirección de una TBA para un NFT dado utilizando la función account del registro (determinista, no se requiere despliegue).
• Despliegue la TBA a través de createAccount cuando necesite actuar por primera vez.
• Implemente flujos de usuario para:
  • Enviar ERC‑20 y ERC‑721 a la dirección de la TBA.
  • Aprobar operadores con ámbitos desde la TBA para acciones de dApp.
  • Ejecutar llamadas de dApp a través de executeCall de la TBA.
• Opcional: Utilice funciones de abstracción de cuenta para patrocinio de gas y claves de sesión. Información de fondo: EIP‑4337.

Consideraciones multichain y de gas

• Cuentas específicas de cadena: El mismo NFT en la cadena A y su representación puenteada en la cadena B tendrán TBAs diferentes. Evite la confusión entre cadenas etiquetando el contexto de la cadena en la UI.
• Economía de gas: Las TBAs son cuentas inteligentes, por lo que desplegarlas y ejecutar a través de ellas cuesta más gas que una simple EOA. Abstraiga el gas para los usuarios con pagadores de gas o meta-transacciones donde sea apropiado. Consulte EIP‑4337 para patrones de transacciones patrocinadas.
• Precomputación: Gracias al determinismo de CREATE2, las dApps pueden hacer referencia a una dirección de TBA incluso antes del despliegue y financiarla o establecer concesiones con antelación. Referencia: EIP‑1014.

Cuándo usar ERC‑6551

Utilice TBAs cuando el NFT en sí mismo deba ser el actor o contenedor de activos:

• Identidades y cargas de juegos
• NFTs de membresía con credenciales y cuotas
• Paquetes de creadores y colecciones curadas
• Identidades sociales con insignias de reputación

Evite las TBAs para coleccionables simples que no necesiten transaccionar o poseer activos adicionales, o donde la complejidad del usuario supere los beneficios.

Cómo OneKey encaja en las billeteras poseídas por NFTs

Controlar una TBA en última instancia depende de la seguridad de la cuenta que posee el NFT subyacente. Si su EOA se ve comprometida, el control del NFT, y por lo tanto de su TBA, está en riesgo. Una billetera de hardware ayuda a mitigar esto al mantener las claves privadas sin conexión.

OneKey está diseñado para un uso web3 multichain y de alta frecuencia, manteniendo al mismo tiempo una sólida seguridad y transparencia de código abierto. Para flujos ERC‑6551, OneKey puede:

• Proteger la EOA que posee y transfiere sus NFTs, asegurando que el control de la TBA permanezca en sus manos.
• Firmar mensajes EIP‑712 y transacciones de cuentas inteligentes de forma limpia para dApps que integran TBAs.
• Proporcionar una experiencia multichain coherente en los ecosistemas de Ethereum y EVM, lo cual es vital cuando las TBAs existen por cadena.

Si planea utilizar NFTs como identidades activas con inventarios y aprobaciones en cadena, anclar la propiedad en una billetera de hardware como OneKey reduce la posibilidad de que las billeteras calientes comprometidas secuestren el control de la TBA.

Conclusión

ERC‑6551 convierte los NFTs en actores de primera clase en cadena con sus propias billeteras, desbloqueando personajes de juegos componibles, paquetes de identidad portátiles y delegaciones más seguras y con ámbitos definidos. El registro y las interfaces de cuenta del estándar facilitan a los constructores la adición de soporte para TBAs, mientras que los usuarios obtienen una mayor utilidad de sus NFTs. A medida que la adopción crezca a lo largo de 2025, preste mucha atención a las aprobaciones, la experiencia de usuario del mercado y las integraciones de abstracción de cuentas.

Para participar de forma segura, utilice una billetera de hardware robusta para controlar los NFTs que respaldan sus TBAs. OneKey ofrece la combinación de seguridad y usabilidad que mantiene seguras sus billeteras poseídas por NFTs mientras explora esta nueva frontera.