Cómo se confirman las transacciones cripto: del envío a la confirmación final

¿Qué significa realmente «confirmada»?

La palabra «confirmada» suele sonar binaria: primero no hay nada y después hay certeza. Las blockchains son más matizadas. Una billetera puede saber que una transacción fue firmada, un nodo puede aceptarla en un mempool local, un productor de bloques puede incluirla y un receptor puede seguir esperando más garantías antes de tratar el pago como liquidado. Son eventos distintos.

Una transacción también puede ejecutarse sin éxito. En Ethereum, una transacción incluida cuya llamada a un contrato revierte sigue estando confirmada como transacción: consumió gas, cambió el nonce del emisor y produjo un recibo con estado de fallo, aunque los cambios de estado que pretendía se deshicieran. Por tanto, «confirmada» no significa automáticamente «la acción de la aplicación tuvo éxito».

Idea clave: haga dos preguntas, no una: ¿está la transacción incluida en la cadena canónica y ha alcanzado el nivel de garantía que exige este pago concreto?

¿Qué ocurre antes de que una transacción llegue a un mempool?

Construcción y firma

Una transacción de Bitcoin identifica las salidas no gastadas que va a consumir, crea salidas nuevas, fija importes y scripts, e incluye firmas u otros datos de testigo que satisfacen las condiciones de gasto. Una transacción de Ethereum identifica una cuenta controlada por el emisor, un nonce, un destino, un valor, datos opcionales, un límite de gas y topes de comisión, y lleva una firma que autoriza exactamente esa carga útil.

El envío no es una difusión global

La mayoría de las billeteras envían la transacción firmada a uno de sus propios nodos, a un proveedor de infraestructura o a un par conectado. El primer receptor puede después retransmitirla por la red entre pares. Algunas transacciones van en cambio a un relay privado, a un constructor de bloques, a un servicio de minería o a un endpoint específico de una aplicación. Cuando una billetera dice «enviada», a menudo solo significa que un endpoint aceptó la solicitud de envío.

Reglas de validez frente a política de retransmisión

Las reglas de consenso deciden si una transacción podría aparecer legítimamente en un bloque: autorización válida, ausencia de gasto excesivo prohibido, transición de estado correcta y otras reglas de la cadena. La política del nodo decide si vale la pena almacenar y retransmitir una transacción sin confirmar antes de que un bloque la contenga. La política puede ser más estricta que el consenso y puede variar según la versión del software o la configuración del operador. Una transacción rechazada por un mempool puede seguir siendo válida en un bloque o ser aceptada por otro nodo.

Idea clave: «la red la rechazó» suele ser demasiado vago. Identifique qué nodo la rechazó, si el motivo fue la validez de consenso o la política local, y si existe otra versión u otra vía.

¿Qué es un mempool y por qué no existe uno solo?

El término viene de «memory pool» (reserva de memoria). No es una sala de espera única gestionada por el protocolo. Cada nodo participante elige qué aceptar, retener, desalojar, retransmitir y reemplazar dentro de los límites de la implementación y del operador. Los nodos se conectan en momentos distintos, tienen pares distintos, usan software distinto y pueden asignar cantidades de memoria distintas. Por eso sus conjuntos de transacciones pendientes divergen de forma continua.

Los mempools de Bitcoin

Los nodos de Bitcoin almacenan transacciones sin confirmar y siguen su grafo de dependencias, porque una transacción hija puede gastar una transacción padre sin confirmar. Bitcoin Core 31 introdujo un diseño de mempool por clústeres que evalúa en grupo las transacciones conectadas y ordena los «chunks» por la tasa de comisión a la que se espera que sean minados. Esto es más preciso que el viejo modelo para principiantes en el que cada transacción se sitúa por su cuenta en una única cola ordenada por comisión.

Los pools de transacciones de Ethereum

Los clientes de ejecución de Ethereum suelen distinguir entre transacciones ejecutables o pendientes y transacciones en cola o con hueco de nonce. Una transacción con el siguiente nonce utilizable puede ser ejecutable; un nonce posterior puede quedar a la espera porque faltan uno o varios nonces anteriores. Geth documenta pools separados de pendientes y en cola, y el reemplazo de una transacción del mismo emisor y mismo nonce por una versión con un precio suficientemente superior.

Mempool público frente a flujo de órdenes privado

Un emisor puede enviar una transacción directamente a un constructor de bloques o a un servicio especializado en lugar de difundirla por la red pública. Esto puede reducir la exposición pública al front-running o mejorar el tratamiento de los bundles, pero introduce supuestos de disponibilidad del endpoint, censura y confianza. La propia documentación de Ethereum señala de forma explícita que los usuarios avanzados pueden enviar transacciones a constructores especializados en lugar de al mempool público.

Idea clave: hable del «mempool de un nodo» o de la «difusión pública de transacciones», no de «el mempool» como si fuera una base de datos globalmente coherente.

¿Cómo funcionan las comisiones de Bitcoin y la selección de transacciones?

Comisión absoluta frente a tasa de comisión

La comisión absoluta es la diferencia entre el valor total de las entradas gastadas y el valor total de las salidas nuevas. La tasa de comisión divide esa comisión entre el tamaño virtual y suele expresarse en sat/vB. Una comisión de 1000 satoshis puede ser competitiva en una transacción pequeña e insuficiente en una mucho mayor. Los bytes virtuales incorporan el descuento de peso de SegWit y no son simplemente el tamaño bruto del archivo.

Por qué las dependencias cambian la subasta

Una transacción hija no puede confirmarse antes que su transacción padre sin confirmar, porque la salida que gasta todavía no existe on-chain. Por eso una construcción racional de bloques considera los ingresos y el tamaño combinados de las transacciones que deben minarse juntas. La lógica de mempool por clústeres de Bitcoin Core 31 ordena explícitamente las transacciones conectadas usando los chunks que se espera minar, en lugar de una lista ingenua de una fila por transacción.

Qué optimizan los mineros y los pools

Un pool suele construir una plantilla de bloque válida destinada a maximizar los ingresos dentro de los límites de peso, dependencias, política y operación. La tasa de comisión es central, pero no exclusiva. Los operadores pueden priorizar transacciones localmente, aceptar transacciones por canales privados, incluir sus propias transacciones, respetar acuerdos comerciales u omitir transacciones por motivos de política. Los nodos de consenso aceptarán cualquier bloque cuyo contenido cumpla el consenso, coincida o no con el mempool de otro nodo.

Idea clave: Bitcoin es una subasta por peso de bloque, pero la unidad económica puede ser un grupo de transacciones conectadas y no una transacción aislada.

¿Cómo funcionan las comisiones de gas y el orden de nonce en Ethereum?

Gas usado y límite de gas

El gas mide los recursos de ejecución que requiere una transacción de Ethereum. El límite de gas es el máximo de gas que el emisor autoriza para esa transacción. El emisor paga solo por el gas realmente consumido, hasta ese límite. Una transferencia simple de ETH tiene un costo intrínseco previsible; las interacciones con contratos pueden consumir mucho más y pueden variar según el estado.

Comisión base, comisión de prioridad y comisión máxima

EIP-1559 asigna a cada bloque una comisión base de protocolo que sube cuando los bloques anteriores superan el uso de gas objetivo y baja cuando quedan por debajo, con un cambio máximo del 12,5 por ciento por bloque. Esa comisión base se quema. El emisor fija además una comisión de prioridad máxima y una comisión total máxima por gas. El cargo real por gas queda limitado por la comisión base, la propina permitida y la comisión máxima del emisor; el margen no utilizado no se paga.

Orden de nonce

El nonce de una cuenta de propiedad externa aumenta con cada transacción ejecutada. Una transacción que usa un nonce posterior no puede ejecutarse antes de que se hayan consumido todos los nonces anteriores. Por eso una sola transacción mal pagada o ausente puede bloquear una cola de transacciones posteriores de la misma cuenta, aunque paguen mucho. Los distintos clientes y servicios de billetera pueden describirlas como pendientes, en cola o con hueco de nonce.

La ejecución revertida también cuesta gas

Si una transacción de Ethereum se incluye y la ejecución del contrato revierte, el protocolo descarta los cambios de estado previstos, pero mantiene el incremento del nonce y cobra por el cálculo ya realizado. El estado del recibo indica el fallo. En cambio, una transacción rechazada antes de la inclusión por ser intrínsecamente inválida no consume gas on-chain.

Las comisiones por blobs van aparte

Las transacciones que llevan blobs de EIP-4844, usadas sobre todo por los rollups, participan en un mercado de comisiones por blobs separado, además del gas de ejecución ordinario. Una transferencia normal de ETH no paga comisión por blobs. Esta distinción importa al diagnosticar los costos de un rollup, pero no forma parte del cálculo estándar de una transferencia desde una billetera.

Idea clave: en Ethereum, separe la inclusión de la transacción del éxito de su ejecución, y separe el tope de gas del importe realmente cobrado.

¿Quién construye y propone realmente los bloques?

Bitcoin: pools, construcción de plantillas y prueba de trabajo

Un pool de minería coordina la potencia de hash de los mineros participantes y normalmente les suministra trabajo candidato basado en su plantilla de bloque. El pool o su infraestructura eligen las transacciones y construyen la transacción coinbase; los mineros buscan una cabecera con prueba de trabajo válida. El minero o el pool que encuentra un bloque válido lo difunde. Los nodos independientes de Bitcoin comprueban el bloque entero y lo rechazan si se incumple cualquier regla de consenso.

Ethereum: el proponente y el constructor pueden ser actores distintos

Cada slot de 12 segundos tiene un validador proponente seleccionado. Un proponente puede construir la carga útil de ejecución localmente con las transacciones que conoce, o recurrir al mercado de constructores. La separación entre proponente y constructor ajena al protocolo, implementada habitualmente mediante la Builder API y el ecosistema MEV-Boost, permite que constructores especializados pujen por el derecho a suministrar la carga útil de ejecución. El proponente firma el bloque elegido; otros nodos lo reejecutan y lo verifican. La hoja de ruta de Ethereum plantea incorporar esa separación al protocolo, pero las propuestas de la hoja de ruta no deben describirse como ya activas mientras no estén desplegadas.

Por qué el MEV afecta al orden

El valor máximo extraíble es el beneficio adicional que se puede obtener seleccionando, insertando u ordenando transacciones. Algunos ejemplos son el arbitraje y las liquidaciones. Un constructor puede preferir un bundle con un valor total alto antes que una transacción con una propina pública ligeramente mayor. Por eso «la propina más alta siempre va primero» no describe con exactitud el orden de los bloques de Ethereum.

Compensaciones del flujo de órdenes privado

El envío privado puede reducir la exposición pública al front-running y permitir bundles de todo o nada. También puede concentrar la visibilidad y el poder de censura en constructores, relays u operadores de endpoints. Conviene distinguir privacidad de ausencia de confianza: una transacción oculta al mempool público puede seguir siendo visible para el servicio privado que la recibe.

Idea clave: la entidad que propone un bloque puede no ser la que eligió el orden de sus transacciones, sobre todo en Ethereum. La inclusión es una cuestión de estructura de mercado además de una cuestión de comisiones.

¿Por qué las transacciones se atascan, desaparecen o muestran estados contradictorios?

Descartada no significa olvidada en todas partes

Los nodos desalojan transacciones por presión de memoria local, antigüedad o política. Otro nodo puede conservar la misma transacción y volver a difundirla más tarde. Un emisor no debe dar por hecho que puede reutilizar los fondos con seguridad solo porque un explorador dejó de mostrar la transacción; verifique el estado canónico del UTXO o del nonce de la cuenta y use la gestión de conflictos de la billetera.

Una comisión baja no es la única causa

Una transacción puede pagar una comisión nominal alta y aun así esperar porque depende de una transacción padre con comisión baja, está detrás de un hueco de nonce, incumple una regla de retransmisión local, se envió a un endpoint privado que la retiene, o pierde la preferencia del constructor frente a un bundle más valioso. Un diagnóstico preciso evita intentos de reemplazo innecesarios o inseguros.

Idea clave: parta del estado observable de la cadena y de los nodos. No reenvíe una y otra vez variantes al azar antes de saber si el problema es de prioridad de comisión, de secuencia, de política, de reemplazo o de reorganización.

¿Cómo se puede acelerar o reemplazar una transacción de Bitcoin pendiente?

Replace-by-fee (RBF)

El RBF crea una transacción nueva que gasta al menos una de las mismas entradas que la transacción pendiente y paga comisión adicional suficiente para cumplir la política de reemplazo. Bitcoin Core convirtió el full-RBF en el comportamiento por defecto en la versión 28, y Bitcoin Core 31 revisó de nuevo la evaluación de reemplazos en torno a los diagramas de tasa de comisión por clúster. Para un reemplazo simple de una sola transacción bajo la política actual de Core, el reemplazo necesita una comisión absoluta mayor y una tasa de comisión mayor, además de comisión incremental suficiente para pagar la retransmisión. Otras implementaciones y servicios pueden funcionar de otro modo.

Use el flujo de «aumentar comisión» o «acelerar» que admita la billetera siempre que sea posible. Un reemplazo manual puede alterar por accidente a los destinatarios, cambiar salidas, romper supuestos de la aplicación o crear una transacción que no se propague como se esperaba. Un reemplazo no es definitivo hasta que una de las versiones se confirma.

Child-pays-for-parent (CPFP)

Si el emisor o el receptor controla una salida de la transacción sin confirmar, puede crear una transacción hija que gaste esa salida con comisión suficiente para hacer atractivo el grupo conectado. Esto no cambia la transacción padre; da a los mineros una razón económica para incluir padre e hija juntas. La política actual de paquetes y clústeres de Bitcoin Core es más matizada que el viejo atajo de «promediar las dos tasas de comisión», pero el principio a nivel de usuario se mantiene: la hija puede subvencionar a la transacción padre cuando el paquete es compatible con la política.

Aceleradores de terceros

Algunos servicios de minería ofrecen aceleración de transacciones, a veces gratuita y a veces de pago. No son una función del protocolo y no pueden garantizar la inclusión por parte de mineros que no controlan. Nunca facilite una frase semilla ni una clave privada, y trate cualquier «soporte de acelerador» no solicitado como una estafa. Un servicio legítimo necesita, como mucho, información pública de la transacción y, si es de pago, un acuerdo de pago ordinario.

Idea clave: aumentar la comisión en Bitcoin es gestionar conflictos y paquetes, no activar una bandera mágica de prioridad. Deje que la billetera construya el reemplazo siempre que se pueda.

¿Cómo se puede acelerar o cancelar una transacción de Ethereum pendiente?

Reemplazo para acelerar

Una aceleración mantiene la acción prevista, pero sube maxFeePerGas y, cuando procede, maxPriorityFeePerGas. El reemplazo debe cumplir las reglas de incremento de precio de la billetera, del cliente de ejecución o del proveedor. Como la comisión base puede moverse mientras la transacción está pendiente, subir solo la propina puede no servir de nada si la comisión máxima ya no cubre la comisión base más la propina efectiva.

Intento de cancelación

Una billetera puede enviar una transferencia sencilla a sí misma con el mismo nonce y comisiones más altas. Si ese reemplazo se incluye primero, la original queda inválida porque el nonce ya se consumió. Si la original llega antes a un bloque, la cancelación pierde. Además, una transacción original enviada de forma privada puede ser invisible para el endpoint público que se use para cancelar, lo que complica la carrera.

No se salte el nonce bloqueado

Enviar una transacción con un nonce posterior no cancela ni evita la anterior. Normalmente se une a la cola detrás de ella. Resuelva primero el nonce pendiente o ausente más antiguo y después revise las transacciones posteriores por si parten de supuestos caducados o repiten acciones de la aplicación.

Precaución con contratos y aprobaciones

Una cancelación exitosa impide que esa transacción concreta se ejecute. No revoca aprobaciones, no revierte una llamada a un contrato ya confirmada ni deshace una orden fuera de la cadena enviada en otro lugar. Si la transacción pendiente es sensible desde el punto de vista de la seguridad, revise también el estado de la billetera, de la dapp y de las aprobaciones, en lugar de tratar el reemplazo de nonce como una respuesta completa al incidente.

Idea clave: «cancelar» en Ethereum significa «ganar una carrera con el mismo nonce usando un reemplazo inofensivo». No es un mensaje de deshacer enviado a los validadores.

¿Se puede revertir una transacción confirmada?

Qué es una reorganización

Los nodos pueden recibir durante un breve periodo bloques válidos que compiten entre sí cerca de la cabecera de la cadena. Las reglas de elección de bifurcación determinan qué rama pasa a ser canónica. Cuando un bloque aceptado antes pierde, se desconecta y la rama ganadora lo sustituye. Las transacciones del bloque desconectado se reconsideran: algunas vuelven a los mempools, otras se confirman en la rama nueva y otras quedan inválidas porque ya ganó un gasto en conflicto o un nonce de cuenta.

Bitcoin: finalidad probabilística

Los nodos de Bitcoin eligen la cadena válida con más prueba de trabajo acumulada. La garantía de una transacción aumenta a medida que bloques válidos añaden trabajo por encima de ella, pero el protocolo no marca ninguna profundidad concreta como matemáticamente final. Las seis confirmaciones son una convención antigua para importes altos; no son necesarias para toda transacción ni una garantía absoluta frente a un atacante con potencia de hash sostenida suficiente.

Ethereum: latest, safe y finalized

Las API de ejecución de Ethereum distinguen entre estados recientes. «Latest» es la cabecera canónica actual del cliente y puede sufrir una reorganización durante el funcionamiento normal. «Safe» es un estado del que se espera que no sufra reorganización bajo supuestos de mayoría honesta y sincronía. «Finalized» es el punto de control criptoeconómicamente seguro más reciente; revertirlo exige una intervención manual de la comunidad tras un fallo de consenso y hace que al menos un tercio del total de ETH en staking sea demostrablemente penalizable por slashing, de modo que los validadores responsables pierden y ven quemada al menos esa parte del stake, con una penalización exacta que escala según cuántos validadores sean penalizados a la vez.

La finalidad no es una imposibilidad metafísica

«Finalizado» es una garantía fuerte de protocolo y de economía, no una afirmación de que el software, la gobernanza o la coordinación humana jamás podrían alterar la historia después de un fallo catastrófico. Ethereum documenta la recuperación social como último recurso ante una finalidad deshonesta. Bitcoin también depende de que los usuarios elijan software y reglas de cadena en condiciones excepcionales. Los usuarios corrientes deben tratar esto como contingencias extremas del sistema, no como mecanismos rutinarios de devolución de cargos.

Idea clave: la profundidad de confirmación mide una garantía creciente; la finalidad del protocolo marca un estado más fuerte. Ninguna de las dos crea una vía de reversión por atención al cliente ante un error autorizado.

¿Cuánto tardan las confirmaciones y la finalidad?

El tiempo en Bitcoin es probabilístico

Bitcoin reajusta la dificultad de minado para que los bloques promedien unos diez minutos a lo largo del tiempo. Eso no es un horario para el próximo bloque. El descubrimiento por prueba de trabajo es aleatorio: el siguiente bloque válido puede aparecer de inmediato o después de un intervalo largo. Una estimación de comisión apunta a una probabilidad de confirmación dentro de un número de bloques, a partir de observaciones pasadas del mempool y del minado; no puede prometer una entrega en tiempo real.

El tiempo en Ethereum va por slots

Ethereum divide el tiempo en slots de 12 segundos y épocas de 32 slots. Se selecciona un proponente por slot, pero no se garantiza un bloque en cada slot. Una transacción visible para el proponente o el constructor ganador y que pague comisiones adecuadas puede incluirse rápido; el enrutamiento privado, la estrategia del constructor, los topes de comisión, el orden de nonce o un slot perdido pueden retrasarla.

La finalidad puede detenerse

En condiciones normales, la votación de puntos de control finaliza la historia tras unas dos épocas. Si la participación cae por debajo del umbral exigido de dos tercios, la cadena puede seguir produciendo bloques sin finalizar. La fuga por inactividad de Ethereum reduce de forma gradual el peso de los validadores no disponibles para que el conjunto en línea pueda recuperar la finalidad, pero el retraso no es fijo.

La capa 2 añade más relojes

En un rollup de Ethereum, un usuario puede ver como etapas distintas el acuse de recibo inmediato del secuenciador, la inclusión en un bloque de L2, la publicación de datos en Ethereum, la finalización de la prueba o del periodo de impugnación, y la disponibilidad del retiro. El estándar de liquidación correcto depende del rollup y de la aplicación. No aplique la cifra de unos 13 minutos de finalidad de la red principal de Ethereum a la experiencia de todos los usuarios de L2.

Idea clave: la cadencia de bloques es un dato de entrada para el tiempo de liquidación, no un acuerdo de nivel de servicio. Ofrezca rangos y estados, no promesas exactas.

¿Cuántas confirmaciones debe esperar un receptor?

Un servicio digital de bajo valor puede asumir más riesgo de reorganización que un exchange que acredita un depósito grande o un comercio que entrega bienes físicos de forma irreversible. Un receptor con vigilancia de doble gasto en tiempo real puede decidir de otro modo que uno que depende de un único explorador de terceros. Las políticas de depósito de un servicio son controles de riesgo, no enunciados directos de la ley del consenso.

Por qué las seis confirmaciones de Bitcoin se volvieron habituales

Seis confirmaciones representan el bloque que contiene la transacción más cinco bloques posteriores, aproximadamente una hora en promedio, y llevan mucho tiempo usándose como convención conservadora para importes altos. No están incorporadas como constante de liquidación en el consenso de Bitcoin. Algunos servicios exigen menos; otros exigen más cuando los importes son grandes, la seguridad de la cadena es menor o los incentivos de ataque son inusuales.

Por qué algunos servicios de Ethereum acreditan antes de la finalidad

Las aplicaciones a veces actúan sobre bloques latest o safe porque esperar a la finalidad completa añadiría latencia. Es una decisión de riesgo deliberada. Un sistema robusto registra el hash del bloque, gestiona las reorganizaciones de forma idempotente y retrasa las acciones irreversibles posteriores hasta alcanzar el estado exigido.

Idea clave: use los umbrales de confirmación como controles de riesgo calibrados, no como cifras rituales copiadas de otra cadena o de otro negocio.

¿Cómo se verifica correctamente una transacción?

En Bitcoin

• Confirme el identificador de la transacción y la red.
• Compruebe si la transacción está sin confirmar o incluida en un bloque canónico, y anote el hash del bloque, no solo la altura.
• Verifique todas las salidas relevantes, no solo la primera dirección que se muestre. Las transacciones de Bitcoin pueden tener varios destinatarios y una salida de cambio.
• Compruebe la comisión y el tamaño virtual si está diagnosticando un retraso.
• Revise si las entradas también las gasta una transacción en conflicto y si existen transacciones padre sin confirmar.
• Cuente las confirmaciones tomando como la primera el bloque que la contiene.

En Ethereum

• Confirme el hash de la transacción, el chain ID y la red.
• Compruebe los campos from, to, value, los datos de entrada y los eventos de transferencia de tokens; una transferencia de tokens puede no aparecer reflejada en el valor de ETH del nivel superior.
• Revise el estado del recibo. El estado 1 suele significar que la ejecución tuvo éxito; el estado 0 significa que la llamada incluida revirtió.
• Compruebe el gas usado y el precio efectivo del gas, en lugar de suponer que se cobró íntegramente la comisión máxima firmada.
• Anote el hash del bloque y si su proveedor informa del estado latest, safe o finalized.
• En las interacciones con contratos, verifique la función prevista, los registros y el estado resultante, no solo el «confirmada».

Privacidad y riesgo de los exploradores

Pegar direcciones y hashes de transacciones en un explorador de terceros revela su interés y puede exponer ante ese proveedor su IP o metadatos que vinculen cuentas. Los datos públicos de la cadena ya son visibles, pero su comportamiento de consulta es información adicional. En flujos de trabajo sensibles o institucionales, consulte su propio nodo o un proveedor de infraestructura de confianza y evite los enlaces de buscadores y los «exploradores de soporte» no solicitados.

Idea clave: verificar significa comprobar el objeto exacto de la cadena y su estado canónico, no fiarse de una notificación de la billetera, de una captura de pantalla o de una etiqueta copiada de un explorador.

Lista de comprobación para resolver problemas

• Copie el hash de la transacción desde la billetera. Confirme la red y el chain ID.
• Compruebe si un nodo o explorador de confianza ve la transacción. Use una segunda fuente independiente si el valor es alto.
• Si está sin confirmar, revise los parámetros de comisión, las dependencias y si la transacción se difundió públicamente o se enrutó de forma privada.
• En Bitcoin, revise las transacciones padre sin confirmar, las condiciones actuales de sat/vB y si la billetera admite RBF o CPFP.
• En Ethereum, identifique el nonce de la cuenta, el nonce pendiente más antiguo, la comisión máxima, la comisión de prioridad y la comisión base actual.
• Busque un reemplazo en conflicto: las mismas entradas en Bitcoin, o el mismo emisor y nonce en Ethereum.
• Si la transacción se confirmó y después desapareció, compare el hash de su bloque antiguo con la cadena canónica para detectar una reorganización.
• Si una transacción de Ethereum se confirmó pero la acción falló, revise el estado del recibo, los registros y la información de la reversión.
• Use la función de acelerar o cancelar integrada en la billetera, en lugar de firmar instrucciones arbitrarias procedentes de mensajes de soporte.
• Nunca revele una clave privada ni una frase de recuperación. Diagnosticar una transacción requiere hashes públicos e información local de la billetera, no material de claves.

Idea clave: una comprobación metódica del estado es más rápida y más segura que reenviar una y otra vez, cambiar de red o seguir instrucciones de «recuperación» no solicitadas.

Preguntas frecuentes

¿Qué es una confirmación en cripto?

Una confirmación suele significar que la transacción está incluida en un bloque canónico. En Bitcoin, el bloque que la contiene es la confirmación número uno. En Ethereum, la inclusión es el estado latest; las aplicaciones también pueden esperar al estado safe o finalized.

¿Una comisión más alta garantiza el siguiente bloque?

No. Una comisión competitiva mejora la prioridad esperada, pero también influyen el momento del bloque, las dependencias, el orden de nonce, la política local, el flujo de órdenes privado, el MEV y la decisión del productor. Las estimaciones de comisión son estimaciones de probabilidad, no garantías.

¿Pueden confirmarse dos versiones de la misma transacción?

Dos transacciones de Bitcoin en conflicto que gastan la misma entrada no pueden permanecer las dos en la misma cadena válida. Dos transacciones de Ethereum de una misma cuenta con el mismo nonce no pueden ejecutarse las dos en la misma cadena. Sin embargo, dos pagos que no están en conflicto y solo se parecen sí pueden confirmarse ambos, y por eso reenviar a mano es peligroso.

¿Se puede cancelar una transacción de Bitcoin confirmada?

No existe una cancelación convencional después de la confirmación. Una reorganización superficial puede eliminar un bloque reciente, pero el emisor no puede pedir una devolución del cargo. Antes de la confirmación, una billetera puede intentar RBF o CPFP, según la transacción.

¿Se puede cancelar una transacción de Ethereum?

Solo mientras está pendiente, intentando reemplazarla por una transacción con el mismo nonce que pague lo suficiente para ganar la carrera. Si la original se confirma primero, la cancelación falla. Una transacción confirmada no se puede retirar mediante el reemplazo de nonce.

¿Por qué mi transacción de Ethereum sigue pendiente aunque la propina es alta?

Puede faltar un nonce anterior, la comisión máxima puede no cubrir la comisión base actual más la propina, la transacción puede ser visible solo para un proveedor, o los constructores pueden preferir otros bundles. Resuelva el nonce más antiguo y revise todos los campos de comisión, no solo la propina.

¿Qué ocurre cuando una transacción de Bitcoin se descarta de un mempool?

Ese nodo deja de almacenarla, pero otros nodos pueden conservarla o volver a difundirla. Las entradas siguen sin gastarse on-chain mientras no se confirme una versión. Compruebe si hay conflictos y el estado de la billetera antes de reutilizar los fondos.

¿Por qué una transacción confirmada volvió a estar pendiente?

Lo más probable es que su bloque se desconectara durante una reorganización de la cadena. La transacción puede volver a un mempool y confirmarse de nuevo, o puede quedar inválida si una transacción en conflicto ganó en la nueva historia canónica.

¿Seis confirmaciones son siempre suficientes?

Es una convención conservadora muy usada en Bitcoin, no una garantía universal. La profundidad adecuada depende del valor, de los incentivos de ataque, de las condiciones de la cadena y de la política del receptor. Otras cadenas usan modelos de garantía distintos.

¿Cuánto tarda la finalidad en Ethereum?

Con una participación normal, aproximadamente dos épocas de 32 slots, unos 13 minutos. Puede tardar más si la participación cae por debajo del umbral exigido. La inclusión suele producirse antes y no es lo mismo que la finalidad.

¿Más confirmaciones cuestan más?

No se cobra ninguna comisión adicional al emisor por el hecho de que se acumulen bloques posteriores por encima de la transacción. La comisión de la inclusión original se paga una sola vez. Esperar cuesta tiempo, mientras que las transacciones de reemplazo pueden exigir comisiones adicionales.

¿Un estado correcto en un explorador de bloques demuestra que el receptor obtuvo el token previsto?

Por sí solo no. Verifique la red, el contrato, el destinatario y el importe correctos. En Ethereum, revise los registros de transferencia de tokens y el estado del recibo; en Bitcoin, revise las salidas relevantes y el cambio.

Fuentes y lecturas adicionales

Referencias clave de este artículo, vigentes a julio de 2026.

• Bitcoin Developer Guide - Transactions. https://developer.bitcoin.org/devguide/transactions.html
• Bitcoin Developer Guide - Block Chain. https://developer.bitcoin.org/devguide/block_chain.html
• Notas de la versión Bitcoin Core 31.0. https://bitcoincore.org/en/releases/31.0/
• RPC bumpfee de Bitcoin Core 31.0. https://bitcoincore.org/en/doc/31.0.0/rpc/wallet/bumpfee/
• Política de reemplazo del mempool de Bitcoin Core. https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
• Ethereum.org - Transactions. https://ethereum.org/developers/docs/transactions/
• Ethereum.org - Gas and fees. https://ethereum.org/developers/docs/gas/
• Ethereum.org - Proof of stake. https://ethereum.org/developers/docs/consensus-mechanisms/pos/
• Ethereum Execution APIs - block tags. https://ethereum.github.io/execution-apis/
• Ethereum.org - Maximal extractable value. https://ethereum.org/developers/docs/mev/
• EIP-1559. https://eips.ethereum.org/EIPS/eip-1559
• Documentación de Geth - opciones de línea de comandos. https://geth.ethereum.org/docs/fundamentals/command-line-options
• Ethereum.org - Proof-of-stake attack and defence. https://ethereum.org/developers/docs/consensus-mechanisms/pos/attack-and-defense/
• Google Search Central - Creating helpful, reliable, people-first content. https://developers.google.com/search/docs/fundamentals/creating-helpful-content