ERC-1155

ERC-1155 es el estándar multitoken de Ethereum: un contrato puede registrar muchos tipos de tokens fungibles, no fungibles o mixtos por ID y transferir varios ID en un solo lote.

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

ERC-1155 es el estándar multitoken de Ethereum. Un solo contrato puede mantener muchos tipos de tokens, y cada token ID puede representar un saldo fungible, un objeto no fungible u otro diseño de oferta elegido por la implementación. Por tanto, la clave del activo es contract address + token ID, no solo el ID del token.

El estándar define consultas de saldo individuales y por lotes, transferencias seguras individuales y por lotes, aprobación global para operadores, llamadas de retorno del receptor, eventos de transferencia y un comportamiento opcional para el URI de metadatos. No define quién puede acuñar, si la oferta tiene un límite, si los metadatos son permanentes, qué derechos legales confiere un token ni cuánto vale. Esas propiedades deben verificarse en el contrato concreto, sus roles y sus dependencias externas.

Cómo funciona

Identificar el saldo. balanceOf(account, id) devuelve la cantidad que una cuenta posee de un ID. balanceOfBatch(accounts, ids) consulta pares de cuenta e ID. Dos contratos pueden usar el ID 1 para activos no relacionados, por lo que la identidad completa sigue siendo la cadena, la dirección del contrato y el ID.
Autorizar al invocador. Un titular puede transferir su propio saldo o llamar a setApprovalForAll(operator, true). Esa aprobación abarca todos los ID ERC-1155 que el titular posee en ese contrato; isApprovedForAll(owner, operator) informa de su estado. ERC-1155 no incluye una aprobación nativa limitada a un solo ID o importe.
Aplicar una transferencia individual o por lotes. safeTransferFrom mueve un ID y una cantidad. safeBatchTransferFrom mueve los arrays paralelos ids y values, cuyas longitudes y orden deben coincidir. Agrupar operaciones puede reducir costes de transacción repetidos, pero no se garantiza que sea más barato para todas las implementaciones o cargas de trabajo.
Comprobar un contrato receptor. Después de actualizar los saldos y emitir el evento pertinente, una transferencia conforme a un contrato llama a onERC1155Received o onERC1155BatchReceived. Una llamada de retorno no compatible, un valor de retorno incorrecto o un rechazo suelen revertir la transferencia. Esta comprobación reduce los bloqueos accidentales; no demuestra que el contrato receptor sea fiable ni que ofrezca una vía de retirada.
Reconstruir el estado a partir de eventos. Toda acuñación, transferencia y quema debe quedar reflejada mediante TransferSingle o TransferBatch. La acuñación usa la dirección cero como from; la quema la usa como to. Los indexadores pueden derivar de estos registros los saldos y la oferta neta acuñada por ID, pero deben procesar correctamente todo el historial, las reorganizaciones de la cadena y las migraciones de contratos.
Resolver los metadatos. La extensión opcional de URI puede devolver una plantilla compartida que contenga {id}. El cliente la sustituye por el ID de token hexadecimal en minúsculas, rellenado con ceros hasta 64 caracteres y sin el prefijo 0x. Los metadatos aún pueden ser modificables, no estar disponibles o resultar engañosos, salvo que la implementación y las garantías de almacenamiento indiquen lo contrario.

Ejemplo práctico

Un contrato de videojuego asigna el ID 1 a monedas de oro, el ID 7 a pases de acceso y el ID 42 a una espada única. Alice posee balanceOf(Alice, 1) = 500, balanceOf(Alice, 7) = 3 y balanceOf(Alice, 42) = 1.

Alice llama a safeBatchTransferFrom con ids = [1, 7, 42] y values = [120, 1, 1]. Si la validación tiene éxito, sus nuevos saldos son 500 - 120 = 380, 3 - 1 = 2 y 1 - 1 = 0; el receptor obtiene las cantidades correspondientes.
El contrato emite TransferBatch. Si el receptor es un contrato, debe aceptar el lote mediante onERC1155BatchReceived; de lo contrario, se revierte toda la transacción y no se conserva ninguno de los tres cambios de saldo.
El ID 42 se comporta como no fungible solo porque su lógica de emisión y transferencia mantiene la oferta en 1. ERC-1155 no impone esa regla. El mismo contrato puede acuñar más unidades del ID 1 posteriormente, sujeto a su propio control de acceso.

Riesgos y controles

Amplia autoridad del operador. Un operador malicioso o comprometido aprobado mediante setApprovalForAll puede mover todos los ID que el titular posea en ese contrato. Verifica la dirección y el contrato del operador, usa una cartera independiente cuando corresponda y revoca las aprobaciones obsoletas.
Facultades de acuñación, pausa y actualización. Son características de la implementación, no garantías del estándar. Examina los titulares de roles, los administradores de proxies, los bloqueos temporales, las extensiones de oferta y si una actualización puede cambiar los saldos o las reglas de transferencia.
Discordancia entre metadatos y activo. Un URI o un archivo JSON alojado puede cambiar mientras el ID en la cadena permanece igual. Verifica los hashes del contenido, la persistencia del almacenamiento, los compromisos del emisor y los derechos representados fuera del contrato del token.
Errores de integración. Las carteras y los indexadores pueden emparejar incorrectamente los arrays de un lote, omitir eventos históricos, gestionar mal las reorganizaciones o confundir el mismo ID entre contratos y cadenas. Concilia las llamadas al contrato, los registros y los saldos finales.
Riesgo del receptor y de reentrada. Las llamadas de retorno del receptor ejecutan código externo durante el flujo de transferencia. Las implementaciones y los protocolos integradores necesitan un orden de estado adecuado y defensas contra la reentrada; la compatibilidad con la llamada de retorno no constituye por sí sola una auditoría de seguridad.
Riesgo de costes y liquidez. Las transferencias por lotes siguen consumiendo gas y se revierten atómicamente si falla una condición obligatoria. La liquidez del mercado, la fijación de precios, las regalías, los puentes, el reembolso y el cumplimiento fuera de la cadena quedan fuera de ERC-1155.

Errores comunes

«Cada ID es un NFT». Un ID puede tener cualquier cantidad; la no fungibilidad depende de la oferta y la semántica de la implementación.
«Un contrato equivale a una colección». Un contrato puede contener muchos tipos de tokens no relacionados, y el mismo ID numérico en otro contrato identifica un activo distinto.
«Transferencia segura significa que el activo es seguro». La llamada de retorno comprueba la compatibilidad del receptor, no la calidad del contrato, el precio, los metadatos ni la posibilidad de recuperación.
«Agrupar siempre ahorra gas». A menudo evita costes repetidos, pero el resultado real depende de la implementación, el número de ID, los cambios de almacenamiento, los datos de llamada y el modelo de comisiones de la red.