La billetera dice confirmada. La página del explorador muestra una marca verde. Y los tokens no están en la cuenta. Nada está atascado y nada hay que reenviar: el campo de estado respondió a una pregunta más estrecha que la que estás haciendo. Aquí está lo que ese campo certifica, lo que deja fuera y dónde queda registrada la respuesta que de verdad buscas.
Qué certifica realmente un estado de éxito
EIP-658 colocó un código de estado en el recibo de la transacción y definió sus dos valores en una línea: 0 indica fallo, debido a cualquier operación que pueda revertir la transacción o la llamada de nivel superior, y 1 indica éxito. Un explorador de bloques convierte ese 1 en una marca.
Lo que importa es el alcance de esa definición. El código describe la llamada de nivel superior. Informa de que la parte más externa de la ejecución terminó sin revertir, y no informa de nada más: ni de que haya cambiado el saldo de un token concreto, ni de que se haya movido el importe que tenías en mente, ni de que el contrato que llamaste hiciera aquello que le pediste. Un recibo con estado 0 es lo que un explorador etiqueta como reverted. Un recibo con estado 1 descarta ese caso y se detiene ahí.
Cada caso de los que siguen vive en ese hueco. La cadena registró por completo lo que ocurrió. El resumen de una sola palabra en lo alto de la página respondía a otra pregunta.
| La pregunta que estás haciendo | Dónde queda registrada la respuesta |
|---|---|
| Llegó a un bloque | El número de bloque del recibo |
| Evitó revertir la llamada más externa | El código de estado del recibo |
| Cambió el saldo de este token | Los eventos de transferencia en los registros |
| Hizo su trabajo mi operación de usuario | La bandera de éxito en su propio evento |
Por qué una transferencia de tokens puede fallar sin revertir
El estándar del token ERC-20 declara transfer como una función que devuelve un valor booleano, y es tajante sobre la consecuencia: quien llama debe manejar false de returns bool success, y quien llama no debe suponer que false nunca se devuelve. Al fallo se le permite llegar como valor de retorno en lugar de como reversión.
Cuando un token informa del fallo de esa manera, el desenlace depende del contrato que lo llamó. Quien llama y revisa el booleano puede revertir ante false, y el recibo vuelve con estado 0. Quien llama y descarta el booleano sigue adelante, la llamada más externa se completa, el recibo dice éxito y el saldo nunca se movió.
Los valores de retorno difieren además de una segunda manera. La biblioteca SafeERC20 de OpenZeppelin se describe a sí misma como envoltorios de operaciones ERC-20 que lanzan una excepción ante el fallo cuando el contrato del token devuelve false, y añade que también se admiten los tokens que no devuelven ningún valor, dando por exitosas las llamadas que no revierten. Una biblioteca escrita para uniformar esos valores de retorno es prueba directa de que no son uniformes.
Fallos que un contrato se traga a propósito
Un contrato puede llamar a otro contrato y decidir de antemano no caer junto con él. La construcción try y catch de Solidity, y la llamada de bajo nivel que devuelve una bandera de éxito en lugar de propagar la reversión, existen precisamente para que la ejecución pueda continuar más allá de un fallo interno. Los enrutadores, los agrupadores y los retransmisores lo usan a propósito: una pata del lote falla, las patas restantes se liquidan y la transacción en conjunto es un éxito.
Vista desde el recibo, esta situación es indistinguible del caso anterior. Una llamada interna falló, la llamada externa absorbió el fallo y el campo de estado registra el resultado externo. El fallo interno sigue en la cadena, pero está en la traza de ejecución y en lo que los registros no contienen, no en el campo de estado.
Un límite de gasto insuficiente es una vía hacia esta forma. Un contrato que mueve tus tokens con transferFrom gasta dentro del límite que fijaste con una aprobación de tokens. Cuando ese límite es menor que el importe que se retira, la llamada interna falla, y que la transacción entera caiga con ella lo decide quien llama, no el token.
Cuando llega menos de lo que se envió
En un tercer caso no hay fallo alguno y la aritmética sigue sin cuadrar. Un contrato de token puede descontar algo dentro de su propia función transfer, acreditando al receptor menos de lo que entregó el remitente. Envía 5.000 unidades de un token que toma 3 % en cada transferencia y llegan 4.850. El recibo dice éxito, el evento de transferencia existe, y el número que hay dentro no es el número que se tecleó.
Los tokens con rebase producen un desajuste emparentado desde el lado contrario. Sus saldos los reescribe el contrato en lugar de moverlos con una transferencia, así que un saldo puede cambiar sin ningún evento de transferencia detrás. Conciliar lo que muestra una billetera con los importes del historial de transacciones no cuadra para un token así, y ninguna de las dos lecturas es defectuosa.
Qué significa un mensaje de transacción fallida con paymaster
Bajo la abstracción de cuentas lo que envías no es una transacción. ERC-4337 define un objeto UserOperation con un mempool propio y un bundler que empaqueta esos objetos en una transacción ordinaria dirigida a un contrato EntryPoint. Un paymaster es un contrato que acepta pagar la transacción en lugar del remitente. Un mensaje de error que nombra al paymaster cubre dos situaciones que no comparten nada salvo la palabra fallido.
La primera es el rechazo durante la validación. ERC-4337 exige que, si falla cualquier llamada a validateUserOp, handleOps omita la ejecución de al menos esa operación de usuario, y exige a los bundlers rechazar las operaciones inválidas de su mempool en lugar de ponerlas en la cadena. Un paymaster que se niega a patrocinar la llamada, al que le queda demasiado poco depósito o que no supera su propia validación mete la operación en esta rama. No se incluyó nada, no se cobró nada y no hay hash que consultar, porque el fallo ocurrió antes de que la cadena viera la operación.
La segunda ocurre después de la inclusión, y es la que produce la marca verde. Una vez superada la validación, la especificación afirma que la ejecución sucederá y sucederá una sola vez, y además garantiza el pago de la comisión. El EntryPoint emite entonces, por cada operación de usuario, un evento con una bandera de éxito, documentada como true si la transacción del remitente tuvo éxito y false si revirtió, junto al importe realmente pagado por la cuenta o por el paymaster. La transacción del lote tiene éxito, al paymaster se le cobra y la bandera de tu operación es false. Las tres cosas se sostienen a la vez.
| Dónde falló | Llegó a un bloque | Quién pagó | Qué hay que consultar |
|---|---|---|---|
| Validación, antes de la inclusión | No | Nadie | Un error del bundler o de la billetera, y ningún registro en la cadena |
| Ejecución, después de la inclusión | Sí | La cuenta o el paymaster | Una transacción con éxito cuyo evento de operación de usuario lleva una bandera de éxito en false |
Dónde mirar en lugar del campo de estado
Los movimientos de tokens quedan registrados como eventos en los registros. La vista de transferencias de tokens de un explorador es una representación de esos eventos, así que si tu dirección no aparece en ninguno de ellos, ese token no se movió, diga lo que diga el estado. Lo que se comprueba son los registros; el estado es el resumen.
Tres preguntas hacen el trabajo. ¿Existe siquiera un evento de transferencia con tu dirección, o esa sección de la página está vacía? Si existe, ¿su importe es el importe que se envió? Y ¿el contrato que lo emite es el contrato del token que tenías en mente, en la red que tenías en mente?
Una cuarta posibilidad sobrevive a las tres comprobaciones: la transferencia ocurrió exactamente como se indicó y se está buscando en el lugar equivocado. Una segunda dirección derivada de la misma frase semilla, la misma dirección en otra red y un token que una billetera no muestra hasta que se añade su contrato a mano producen todos una pantalla vacía junto a un recibo perfectamente correcto.
En resumen
El estado de un recibo es una afirmación sobre la llamada más externa y sobre nada más. Éxito significa que la transacción no revirtió. Nunca ha significado que un token se moviera, que se moviera el importe correcto o que el contrato hiciera con él lo que se quería. Esos hechos viven en los registros de eventos y, bajo ERC-4337, en una bandera de éxito que se mantiene separada del estado de la transacción que la transporta.
Cuando una transferencia desaparece detrás de una marca verde, recorre las capas en orden: un evento de transferencia, después su importe, después el contrato del token y la red. Para seguir aprendiendo los fundamentos, sigue más contenidos de Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Cómo cambiar de endpoint RPC de forma segura
- Comisión máxima de transacción superada: qué significa ese aviso de la billetera
- Límite de solicitudes RPC excedido y cómo evitarlo
- ¿Qué es un código QR de cripto?
- Liquidez global, M2 y Bitcoin: una guía de medició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-20: Token Standard (la función transfer y su valor de retorno booleano) eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-658: Embedding transaction status code in receipts (el campo de estado del recibo de la transacción) eips.ethereum.org
[3] Ethereum Improvement Proposals, ERC-4337: Account Abstraction Using Alt Mempool (validación, bundlers y paymasters) eips.ethereum.org
[4] eth-infinitism, account-abstraction, contracts/interfaces/IEntryPoint.sol, etiqueta v0.7.0 (la declaración de UserOperationEvent) raw.githubusercontent.com
[5] OpenZeppelin, openzeppelin-contracts, contracts/token/ERC20/utils/SafeERC20.sol, etiqueta v5.1.0 (el comentario de documentación de la biblioteca) raw.githubusercontent.com
