NoticiasCriptoContratos inteligentes de mercados NFT: listados, ofertas, subastas y regalías

Contratos inteligentes de mercados NFT: listados, ofertas, subastas y regalías

Autor: NFTENEX·

Puntos clave

  • Los contratos NFT y los contratos del mercado cumplen funciones separadas: el primero define la propiedad del activo y el segundo coordina ventas, tarifas y liquidación.
  • Los listados ERC-721 suelen vender un único token, mientras que los listados ERC-1155 pueden ofrecer múltiples copias, lo que exige manejo de rellenos parciales y control de cantidades durante la liquidación.
  • Los mercados con escrow bloquean el NFT en el contrato al momento del listado, mientras que los lazy listings preservan la custodia del vendedor mediante firmas fuera de cadena pero requieren rutas de invalidación en cadena.
  • EIP-2981 hace que la información de regalías sea legible, pero no aplica el pago de forma universal, por lo que los ingresos reales del creador dependen de la política del mercado y de la lógica de liquidación.
  • Las pruebas de seguridad deben verificar que los contratos fallen de forma cerrada ante condiciones inseguras, cubriendo reentrancia, ataques de repetición, órdenes vencidas, firmas en la cadena incorrecta y rellenos parciales.
Contratos inteligentes de mercados NFT: listados, ofertas, subastas y regalías

Los contratos inteligentes de mercados NFT gestionan listados, ofertas, subastas, liquidación, cancelación, enrutamiento de tarifas, regalías y controles administrativos. Aunque los estándares ERC-721 o ERC-1155 describen el activo en sí, cumplir con un estándar de token no produce automáticamente un mercado seguro.

Los desarrolladores deben comparar los contratos del mercado con el comportamiento de tarifas y órdenes en la reseña del mercado de OpenSea, las capas operativas en la guía de infraestructura de mercado NFT y los disparadores de pago en modelos de ingresos pasivos con NFT, porque los eventos del contrato sirven como datos de origen para los flujos de trabajo de liquidación y soporte.

Explicación de los contratos inteligentes NFT

Un contrato inteligente NFT es código desplegado en una blockchain que crea tokens y gobierna cómo se registra y transfiere la propiedad. Al acuñarse, el contrato asigna un ID de token a una dirección propietaria. Cuando el token se vende o transfiere, el contrato actualiza el registro de propiedad solo después de verificar la autoridad del remitente y las reglas de transferencia aplicables.

Por lo general, el contrato registra el propietario del token, la oferta, las aprobaciones, el historial de transferencias y una referencia de metadatos. No necesariamente almacena la obra en sí. Como señala la explicación de Hedera sobre contratos inteligentes NFT, el ID del token y los metadatos identifican el activo, mientras que la lógica del contrato inteligente maneja la acuñación y los cambios de propiedad. Es importante destacar que un contrato inteligente es código ejecutable: no es automáticamente un acuerdo legal sobre derechos de autor, reembolsos o derechos comerciales.

Contratos NFT frente a contratos de mercado

El contrato NFT y el contrato del mercado cumplen funciones distintas. El contrato NFT define el activo, crea IDs de token, registra la propiedad y aplica aprobaciones y transferencias. El contrato del mercado coordina la venta: valida el listado o la oferta, cobra el pago, transfiere el NFT, enruta las tarifas y cierra o cancela la orden.

Esta separación es importante porque poseer un NFT válido no significa que esté listado activamente, y firmar una orden del mercado no cambia la propiedad hasta que la liquidación se completa. Por lo tanto, el comprador debe verificar ambas direcciones: el contrato de la colección identifica el NFT, mientras que el contrato del mercado o el spender identifica el software que recibe el permiso de transferencia. Para los equipos que integran billeteras, herramientas de soporte o indexadores, esta distinción también determina qué eventos se tratan como fuente de verdad para la disponibilidad del ítem, los reembolsos y el cumplimiento.

Cómo ERC-721 y ERC-1155 influyen en el diseño del mercado

ERC-721 se usa comúnmente cuando cada ID de token representa un único ítem de propiedad independiente. Es adecuado para arte one-of-one, activos únicos de juegos, parcelas de tierra y coleccionables cuya propiedad se verifica token por token. ERC-1155 puede representar varias copias del mismo ID de token, lo que resulta útil para consumibles de juegos, boletos, ediciones o ítems emitidos en cantidad.

El estándar de token cambia lo que una orden debe contener. Un listado ERC-721 normalmente vende un solo ID de token. Un listado ERC-1155 puede ofrecer 20 copias mientras un comprador adquiere solo tres, por lo que el mercado debe actualizar la cantidad restante sin cerrar toda la orden. Una cancelación debe invalidar cualquier cantidad que quede, y el evento de liquidación debe indicar cuántas unidades cambiaron de manos.

Los mecanismos de aprobación también difieren. Una aprobación ERC-721 específica para un token autoriza un solo NFT, mientras que una aprobación de operador puede abarcar todos los tokens de esa colección. ERC-1155 suele usar aprobación de operador para todo el saldo de una billetera bajo el contrato. Un mercado puede requerir permisos más amplios por conveniencia, pero la ventana de la billetera debe mostrar claramente ese alcance y el usuario debe entender cómo revocarlo.

Diseños de escrow y lazy listing

Un mercado con escrow transfiere el NFT al contrato del mercado cuando el vendedor lo lista. Ese enfoque facilita verificar la disponibilidad, pero el vendedor paga más gas y pierde la capacidad de usar el activo mientras está listado. Un lazy listing mantiene el NFT en la billetera del vendedor y registra una firma fuera de cadena que contiene el token, el precio, la cadena, el vencimiento, el nonce y la dirección del mercado. Esto reduce el costo de listado y preserva la custodia, pero el contrato debe validar la firma y el vendedor aún necesita una vía en cadena para invalidarla.

Para un mercado de juegos, esta decisión afecta más que el costo de gas. El escrow puede impedir que un ítem se equipe mientras está listado, mientras que el lazy listing preserva el activo del jugador pero exige que el juego y el mercado manejen un listado que deja de poder cumplirse cuando cambia la propiedad. Esa diferencia operativa también explica por qué los equipos deben probar casos límite como transferencias de billetera, actualizaciones de la colección e invalidación de listados antes del lanzamiento, en lugar de asumir que el modelo de listado los manejará automáticamente.

Ciclo de vida de listados y ofertas

Un listado a precio fijo debe pasar por los estados create, validate, buy, settle y cancel. Las ofertas requieren vencimiento, nonce, chain ID, verificaciones de spender y cancelación. Cada estado debe emitir eventos que un indexador pueda reconciliar.

Las ofertas también necesitan un modelo de pago que el contrato pueda ejecutar de forma fiable. Una oferta en moneda nativa por lo general no puede retirarse más tarde de la billetera del comprador sin una nueva transacción firmada, mientras que un token ERC-20 aprobado como WETH o USDC puede mantenerse en escrow o transferirse cuando el vendedor acepta. El registro de la orden debe incluir la moneda, el monto, el vencimiento, el nonce, el comprador, el vendedor, el ID del token y el estado de cancelación, y no solo un precio principal.

La liquidación de subastas necesita su propia máquina de estados. Una subasta inglesa debe manejar pujas más altas, reembolsos, la hora de cierre y el llamado final de liquidación. Una subasta holandesa debe calcular el precio actual a partir del tiempo transcurrido y rechazar compras obsoletas. Un balance de reembolso basado en pull es más seguro que enviar fondos de inmediato a cada postor superado, porque un callback de reembolso fallido no debe congelar toda la subasta. Una extensión corta del tiempo final también ayuda a reducir el sniping de última hora.

Una venta de NFT de 0.5 ETH desde la firma hasta la liquidación

Considere un NFT ERC-721 listado por 0.5 ETH mediante una orden firmada. El vendedor conserva el NFT en la billetera, pero autoriza al contrato del mercado para transferirlo. El listado firmado identifica el contrato de la colección, el ID del token, el vendedor, el precio, el vencimiento, el nonce, el chain ID y la dirección del mercado. No ocurre ningún cambio de propiedad cuando se crea esa firma.

Cuando el comprador envía la compra, el contrato del mercado verifica que la orden no haya vencido ni sido cancelada, que la firma pertenezca al vendedor, que el vendedor siga siendo propietario del NFT y que la aprobación de transferencia siga siendo válida. Luego marca la orden como completada, procesa el pago, envía el NFT al comprador y emite eventos que el mercado puede usar para actualizar la página del ítem.

La siguiente distribución es ilustrativa, no una declaración sobre las tarifas en vivo de un mercado específico.

Si la transferencia del NFT falla, el pago no debe quedar completado mientras la propiedad permanezca sin cambios. Si el destinatario del pago no puede recibir ETH, la respuesta más segura depende del diseño del contrato: la transacción puede revertirse o el monto puede acreditarse a un saldo retirabile. Por eso el enrutamiento de pagos, el orden de transferencia, las actualizaciones de estado y la protección contra reentrancia deben probarse juntos y no como casillas de verificación de funciones separadas.

Regalías y enrutamiento de tarifas

La información de regalías puede seguir EIP-2981, mientras que bibliotecas de contrato como OpenZeppelin ERC-721 y OpenZeppelin ERC-1155 ayudan con el comportamiento estándar de los activos. Sin embargo, la aplicación por parte del mercado sigue requiriendo una política de producto deliberada.

Un ejemplo concreto ayuda aquí: mostrar qué ocurre con un ítem listado desde el descubrimiento hasta la firma y la liquidación, y luego explicar en qué punto entran las tarifas, las regalías y las aprobaciones.

EIP-2981 hace que la información de regalías sea legible, no universalmente aplicable. Un mercado puede consultar la dirección del creador y el monto de la regalía, pero otra plataforma puede elegir una política diferente o ignorar el resultado. Si los ingresos del creador son esenciales, pruebe la ruta real de transferencia, el mercado seleccionado, el comportamiento del agregador y la lógica de aplicación de la colección en lugar de tratar un campo de regalía como un pago garantizado.

Pruebas de seguridad

Pruebe reentrancia, repetición, órdenes vencidas, firmas en la cadena incorrecta, compromiso de la clave administrativa, comportamiento de pausa y rellenos parciales. El objetivo no es una lista larga de auditoría; es demostrar que el mercado falla de forma cerrada cuando la orden no es segura.

Las pruebas de mayor valor deben modelar los fallos que un comprador o vendedor realmente puede experimentar. Una compra debe rechazar un cambio de precio en lugar de ejecutar un bait-and-switch; una orden firmada debe estar vinculada al chain ID y a la dirección del mercado; y un nonce cancelado o consumido no debe ejecutarse de nuevo. Para el código de liquidación, actualice el estado de la orden antes de las llamadas externas y use una protección contra reentrancia alrededor de las rutas de pago y transferencia.

Un usuario de Polygon que revisó Rarible informó que la experiencia de la red carecía de soporte para contratos personalizados y de congelación de metadatos en esta reseña de contrato específica de la red, recopilada el 11 de agosto de 2026. Eso no es evidencia de que un contrato de mercado sea inseguro, y puede depender de la red y de la versión del producto. Aun así, es un límite de implementación útil: pruebe la cobertura de contratos, la inmutabilidad de metadatos y el comportamiento de actualización en la cadena exacta seleccionada para el lanzamiento.

Conclusión

Un contrato de mercado debe evaluarse por su ciclo de vida de órdenes y su comportamiento ante fallos. Si el artículo ayuda a un desarrollador a probar órdenes vencidas, firmas en la cadena incorrecta, enrutamiento de regalías e indexación de eventos, ha hecho más que repetir estándares de tokens. La siguiente verificación de ingeniería es la prueba del ciclo de vida de la orden. Un camino de contrato seguro maneja creación, vencimiento, cancelación, liquidación, regalías, indexación y comportamiento de pausa sin depender de suposiciones.

Preguntas frecuentes

¿Qué información se almacena en un contrato inteligente NFT?

Por lo general, el contrato registra IDs de token, propiedad, saldos, aprobaciones, reglas de transferencia, oferta y una URI de metadatos. La imagen o el video suelen almacenarse por separado y referenciarse mediante metadatos.

¿El contrato NFT también gestiona listados del mercado?

No necesariamente. El contrato NFT gestiona el token, mientras que un contrato de mercado separado suele gestionar listados, ofertas, subastas, pago, tarifas y liquidación.

¿Puede un mercado transferir un NFT sin permiso?

Necesita permiso a través de la propiedad, una aprobación específica del token o una aprobación de operador reconocida por el contrato NFT. Compradores y vendedores deben revisar el spender aprobado antes de firmar.

¿Un campo de regalías NFT garantiza el pago?

No. Un estándar de regalías puede comunicar el destinatario y el monto, pero el pago real depende de la política del mercado y de la ruta de liquidación.

Descargo de responsabilidad: Este artículo es solo para fines de investigación y comparación editorial. No constituye asesoramiento financiero, de inversión, legal ni fiscal. Las herramientas NFT, los mercados, las tarifas, el soporte de cadenas y la disponibilidad en vivo pueden cambiar rápidamente, por lo que debe verificar las condiciones actuales en la plataforma oficial antes de tomar cualquier decisión que involucre fondos, activos o claves privadas.