La página de acuñación dijo «éxito». El explorador muestra una marca verde junto a la comisión que pagaste. La galería de la billetera está vacía. Aquí hay tres sistemas respondiendo a tres preguntas distintas, y solo uno de ellos es la cadena. Antes de decidir que algo salió mal, separa la pregunta de si existe un token de la pregunta de si una aplicación está dispuesta a dibujarlo.
Qué certifica una transacción de acuñación con éxito
Una transacción confirmada te dice que tu llamada llegó a un bloque y que la parte más externa de la ejecución no revirtió. Eso es todo. Un estado del recibo de éxito es una afirmación sobre la llamada, no un inventario de lo que la llamada produjo.
Una acuñación es una función de contrato como cualquier otra. Puede terminar sin revertir y aun así no haber creado nada para ti: un bucle por lotes que se saltó tu entrada, una llamada interna que el contrato absorbió a propósito, una función de pago que cobró la comisión y anotó el token en otra dirección. El recibo no separa esos casos de una acuñación corriente, porque nunca se le pidió que lo hiciera.
Así que la pregunta no es si la transacción funcionó. Es si ahora existe un token con tu dirección escrita a su nombre. Ese hecho queda registrado en otro sitio, y queda registrado dos veces: una como evento en el momento de la creación y otra como valor con el que el contrato responderá cuando se le pregunte.
El evento que dice que se creó un token
En el estándar de tokens ERC-721 la acuñación no es una operación aparte. Es una transferencia sin remitente. El estándar define un único evento Transfer que se emite cuando la propiedad de cualquier NFT cambia por cualquier mecanismo, y establece que ese evento se emite cuando los tokens se crean y cuando se destruyen: en el primer caso el campo del remitente queda en cero y en el segundo queda en cero el campo del destinatario.
Eso te da algo exacto que buscar. Un evento de transferencia en la transacción de acuñación, desde la dirección cero, hacia tu dirección, con un identificador de token, es la cadena diciendo que se creó un token y se te asignó. Su ausencia informa igual de bien.
ERC-1155 mantiene la misma convención en sus propios eventos: al acuñar tokens, el argumento del remitente debe fijarse en la dirección cero. La forma de la prueba no cambia, por tanto, entre los dos estándares, aunque el soporte de las billeteras a su alrededor sí puede cambiar.
La lectura que zanja de quién es
El evento es el registro de un momento. La propiedad ahora es una lectura aparte, y ERC-721 la responde directamente. Llama a ownerOf con un identificador de token y el contrato devuelve la dirección que tiene anotada como propietaria. El estándar añade que los tokens asignados a la dirección cero se consideran inválidos y que las consultas sobre ellos lanzan un error, de modo que una llamada que falla en vez de devolver una dirección es en sí misma una respuesta: ningún token con ese identificador está asignado ahora mismo a nadie.
Junto a ella, balanceOf cuenta los tokens que una dirección tiene en ese único contrato. En una colección de 10.000 identificadores, ownerOf responde por exactamente el identificador que nombras, y balanceOf responde cuántos tokens de ese contrato hay en tu dirección sin que tengas que adivinar identificadores. Ninguna de las dos lecturas depende de que haya un marketplace, una galería o una imagen disponible.
| La pregunta que estás haciendo | Dónde queda registrada la respuesta |
|---|---|
| Si la transacción llegó a un bloque | El número de bloque del recibo |
| Si la llamada más externa evitó revertir | El estado del recibo |
| Si se creó un token para mí | Un evento de transferencia cuyo campo de remitente es la dirección cero |
| De quién es ese identificador ahora | La dirección que ownerOf devuelve para él |
| Cuántos de la colección tengo | El número que balanceOf devuelve para mi dirección |
| Si mi billetera lo dibujará | Nada en la cadena registra eso |
La última fila es la que resuelve toda esta situación. No hay un campo en la cadena para si una aplicación muestra tu token, y por eso una galería vacía nunca es por sí sola una prueba sobre la propiedad.
Por qué el token puede ser tuyo y la billetera no mostrar nada
Una galería de billetera no es una lectura en vivo de la cadena. Nada en ninguno de los dos estándares te permite pedirle a una cadena todos los tokens que una dirección tiene en todos los contratos, así que las billeteras y los marketplaces operan indexadores: vigilan los eventos de transferencia, anotan lo que ven y te sirven ese registro. Lo que recorres es su tabla, no el contrato.
Cuatro cosas de esa tabla pueden dejarla vacía mientras el contrato dice otra cosa. El indexador puede no haber procesado todavía tu bloque, y en ese caso la galería se rellena sola. La colección puede estar filtrada como spam o como no verificada, que es una regla de visualización que aplica la billetera y que se puede desactivar. La billetera puede indexar un estándar y no el otro, de modo que un token acuñado bajo ERC-1155 no muestra nada en una vista construida solo para ERC-721. Y una billetera que exige añadir la colección a mano no muestra nada de ella hasta que eso se hace.
Ninguna de esas cosas se arregla reenviando nada a la cadena. Mandar una segunda transacción porque una galería parece vacía arriesga acuñar otra vez y pagar otra vez por un token que ya tienes.
Cuando el token se fue a otro sitio
La otra familia de causas es que la acuñación funcionó exactamente como está escrita y el token no está en la dirección que estás mirando.
El destinatario de una acuñación lo decide el contrato, no la interfaz. Una función que acuña a quien la llama anota el token en la dirección que firmó la transacción, es decir, en la cuenta que estaba conectada en ese momento y no en la seleccionada ahora en la billetera. Una billetera derivada de una frase semilla tiene más de una dirección, y la que estás viendo puede no ser la que acuñó.
Las cuentas de contrato inteligente añaden una segunda versión del mismo desajuste. ERC-721 exige que una transferencia segura compruebe si el destinatario es un contrato inteligente y, si lo es, llame al hook de recepción sobre él y lance un error cuando no llegue el valor de retorno esperado. Una cuenta de contrato que implementa ese hook recibe el token con normalidad, y el token pasa a vivir en la dirección del contrato. Cualquier vista apuntada a la clave que firma en lugar de a la cuenta no mostrará nada mientras el token descansa a salvo donde fue enviado.
Luego está la red. La misma dirección existe en todas las cadenas que usan el mismo formato de dirección, así que una billetera puesta en una red dibuja una galería vacía para un token acuñado en otra. El token no falta. La vista está filtrada a una cadena en la que el token nunca estuvo.
Cuando el token está y solo falta la imagen
Un síntoma distinto es una casilla que está presente pero en blanco, gris o etiquetada con un nombre provisional. Aquí la propiedad no está en cuestión en absoluto: la billetera dibujó el token, lo que significa que indexó el evento de transferencia y el identificador.
Detrás de la casilla está el documento de metadatos y no el token, y el instrumento para eso es una actualización de metadatos, que le dice a la plataforma que vuelva a leer el puntero y el documento. Una actualización no mueve nada en la cadena ni crea propiedad, así que es la herramienta adecuada para una imagen desfasada y la equivocada para un token que no aparece en absoluto. Separar estos dos casos antes de actuar ahorra las horas que se van en actualizar un token que la billetera nunca iba a dibujar.
| Lo que estás viendo | Lo que es cierto por debajo | Qué lo cambia |
|---|---|---|
| Galería vacía, existe un evento de transferencia a tu dirección | El indexador va por detrás o filtra la colección | Esperar, un ajuste de la billetera o añadir el contrato a mano |
| Galería vacía, no hay evento de transferencia en la transacción | No se creó nada para tu dirección | Leer el contrato antes de hacer nada en la cadena |
| Token visible con imagen provisional o sin arte | La copia guardada de los metadatos va por detrás de la actual | Una actualización de metadatos |
| Token visible en un explorador, ausente en la billetera | La billetera no indexa ese estándar o esa colección | Un ajuste de la billetera, o un visor distinto |
| ownerOf devuelve una dirección que no es tuya | El token se acuñó o se envió a otra cuenta | Mirar esa dirección en su lugar |
Qué comprobar, y en qué orden
Abre la transacción en un explorador de bloques y lee sus registros en vez de su titular. Un evento de transferencia desde la dirección cero, con un identificador de token, te dice que se creó un token. La dirección en el campo del destinatario te dice de quién es. Si esa sección está vacía, el resto de la búsqueda va sobre el contrato, no sobre tu billetera.
Después llama a ownerOf en el contrato con ese identificador de token. Los exploradores exponen lecturas de contrato sin firma ni comisión, así que esto no cuesta nada y devuelve la respuesta propia de la cadena en lugar de la copia de un indexador. Si la dirección que vuelve es una de las tuyas, el token es tuyo y todo lo que queda es una cuestión de visualización.
Después comprueba lo que estás mirando: la dirección seleccionada en la billetera, la red en la que está puesta y si la colección está oculta. Esos tres ajustes explican la distancia entre un contrato que te nombra propietario y una galería que no muestra nada.
En resumen
Una acuñación que se confirma demuestra que una llamada no revirtió. No demuestra que exista un token, y no nombra a un propietario. Esos dos hechos viven en el evento de transferencia de la transacción y en lo que ownerOf devuelve después, y ambos se pueden leer sin que ninguna aplicación coopere.
Una galería vacía es una afirmación sobre un indexador. Lee el evento, lee ownerOf y comprueba después la dirección, la red y el filtro de colecciones. Si el contrato te nombra propietario, no hace falta enviar, firmar ni pagar nada otra vez. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Propiedad fraccionada de un token no fungible y dónde está el riesgo
- El proceso de revelado de un NFT: qué cambia y cuándo
- Regalías opcionales de NFT, explicadas
- The DATA Foundation, antes Story Protocol: la migración del token IP a DATA
- Carteras ómnibus y segregadas y riesgo de rehypotecación
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[1] Ethereum Improvement Proposals, EIP-721: Non-Fungible Token Standard, sección de especificación eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-1155: Multi Token Standard, sección de especificación eips.ethereum.org
