Trabajar en infraestructura de stablecoins y banca me ha enseñado que la pregunta más importante casi nunca es si una transacción se envió correctamente.
La pregunta más útil es:
¿Cuándo es seguro que alguien actúe a partir de ella?
Un usuario quiere saber cuándo llegó el dinero. Un comercio necesita saber cuándo entregar un producto. Una wallet debe decidir cuándo actualizar el saldo disponible. Un exchange tiene que determinar cuándo acreditar un depósito. Un bridge debe decidir cuándo puede completar de forma segura una transferencia en otra cadena. Un sistema financiero quizá necesite distinguir entre reconocer un pago entrante, hacer que el saldo pueda gastarse, conciliarlo y mover los fondos subyacentes.
Hoy, la mayoría de las aplicaciones comprimen todas estas decisiones en un único check verde:
Pendiente → ConfirmadaEsa abstracción es fácil de entender, pero oculta la parte más importante de la liquidación: los distintos estados de una blockchain ofrecen garantías diferentes, y esas garantías no autorizan las mismas acciones.
La visión que Ethlabs publicó recientemente sobre Hegotá identifica cuatro prioridades para el protocolo: mayor resistencia a la censura, un Ethereum más rápido, abstracción de cuentas nativa y escalabilidad continua de L1. Ethlabs también describe su papel como un puente entre el uso de Ethereum en el mundo real y el desarrollo del protocolo, partiendo de la idea de que la ingeniería del protocolo debería permitir mejores productos y que los productos deberían ayudar a orientar el rumbo del protocolo.
Creo que esos son los cimientos correctos para una infraestructura global de pagos.
Pero, desde el lado de las aplicaciones, todavía falta una capa.
Una vez que Ethereum ofrezca bloques más rápidos, garantías de inclusión más sólidas, cuentas con más capacidades y una capacidad más predecible, las wallets, los bridges, los exchanges y los procesadores de pagos todavía tendrán que traducir esas propiedades en decisiones operativas.
Llamo a esa capa una Política de Liquidación para Aplicaciones:
Una capa orientada a las aplicaciones que traduce las señales del protocolo en decisiones explícitas, observables y conscientes del riesgo sobre el dinero.
No es una propuesta para redefinir la finalidad de Ethereum ni, por ahora, una propuesta de un nuevo EIP. En este artículo, “política de liquidación” se refiere a las reglas que usa una aplicación para decidir cuándo puede actuar de forma segura sobre una transacción, no a un nuevo mecanismo de consenso.
El protocolo ofrece garantías.
La aplicación debe entender qué significan esas garantías.
El check verde llega demasiado pronto
Pensemos en un pago de 100 USDC por una suscripción. El comercio puede quitar el acceso si algo sale mal, pero preferiría no tener que hacerlo. El usuario, mientras tanto, solo quiere dejar de mirar una pantalla que dice “pendiente”.
La transacción no salta de un estado al otro de golpe. Avanza así:
observed → included → safe → finalizedEn observed, la aplicación vio la transacción. Puede estar en la mempool o haber llegado desde un proveedor RPC, pero todavía puede desaparecer, ser reemplazada o no entrar nunca en un bloque.
En included, ya forma parte de la cadena canónica. Es una señal mucho mejor, aunque el bloque todavía puede sufrir una reorganización.
En safe, el nodo dice que ese bloque está cubierto por su cabecera segura. Aquí la aplicación ya puede plantearse actuar antes de la finalidad, siempre que entienda qué produjo esa señal y compruebe que sigue vigente.
En finalized, Ethereum ofrece su garantía normal más fuerte. Para una operación de alto valor o algo que no pueda revertirse, este sigue siendo el punto de referencia.
No hace falta que todas las aplicaciones tomen la misma decisión. Una suscripción que puede cancelarse no tiene el mismo riesgo que un retiro, un movimiento de tesorería o la entrega de un activo que ya no puede recuperarse.
Lo que sí deberían poder hacer todas es explicar la decisión.
El problema del check verde no es que sea simple. La simplicidad es útil. El problema es que termina significando demasiadas cosas.
Cuando safe deja de moverse
Fast Confirmation Rule, o FCR, hace visible esta diferencia.
FCR está diseñada para confirmar un bloque aproximadamente dentro de un slot, en vez de esperar alrededor de 13 minutos hasta la finalidad. Funciona localmente en los clientes de consenso y puede exponer el resultado mediante la etiqueta safe que ya existe. No necesita un hard fork.
Para un bridge, un depósito o un pago, trece segundos pueden cambiar mucho la experiencia. También pueden reducir el tiempo durante el que una aplicación mantiene capital inmovilizado.
Pero FCR no es finalidad con un reloj más rápido.
Depende de que la red sea síncrona y de que el stake adversarial permanezca por debajo del 25 %. Tampoco tiene la misma seguridad económica respaldada por slashing. Si esas condiciones dejan de cumplirse, la confirmación rápida puede dejar de avanzar y el sistema termina dependiendo nuevamente de la finalidad.
Ahí está el detalle que más me interesa.
El RPC puede responder correctamente. El bloque que devuelve existe. No aparece ninguna excepción. Sin embargo, la cabecera safe puede llevar varios slots sin moverse.
La llamada funcionó
≠
La garantía sigue avanzandoUna aplicación que solo comprueba si el RPC respondió puede tratar una señal vieja como si acabara de llegar.
Antes de mover dinero o entregar algo, necesita saber qué mecanismo produjo safe, cuánto se alejó de latest, si continúa avanzando y si el bloque del pago está realmente cubierto. Para operaciones con más riesgo, también puede comparar más de una fuente.
La blockchain entrega el estado.
La decisión todavía no está ahí.
La capa que falta
La Política de Liquidación para Aplicaciones se ubica justo en ese espacio: entre lo que el nodo sabe y lo que el producto decide hacer.
No necesita comenzar como un sistema enorme. Una respuesta útil podría ser tan pequeña como esta:
{
"status": "safe",
"mechanism": "ethereum_fcr",
"safeHeadLagSlots": 2,
"stalled": false,
"policy": "merchant_subscriptions_v1",
"decision": "activate_subscription"
}El campo importante no es solamente status. Es decision.
Para llegar a esa decisión, la política combina la señal del protocolo con el contexto del pago. Tiene que saber si lo entregado puede recuperarse, cuánto valor está en riesgo, si la aplicación adelanta liquidez, si depende de un único proveedor y qué ocurre si la red deja de avanzar como esperaba.
Una regla como “menos de 100 dólares usa safe; más de 100 espera finalized” puede servir como comienzo. No alcanza para todos los casos. Dos pagos por el mismo monto pueden terminar en pérdidas muy distintas.
La política también necesita un nombre y una versión. Meses después, alguien debería poder revisar el pago y entender por qué la aplicación activó la suscripción:
La cabecera
safeestaba vigente, el desfase era de dos slots y la versión 1 de la política permitía entregar un servicio reversible.
Eso es mucho más útil que descubrir que el frontend mostró un check verde.
Volvamos a los 100 USDC
Primero, la aplicación detecta la transacción y se la muestra al usuario. Todavía no activa la suscripción.
Después, la transacción entra en un bloque. El comercio puede preparar la cuenta, pero espera una garantía más fuerte.
Cuando el bloque queda cubierto por safe, la política revisa la vigencia de la señal. Si todo está funcionando y sus reglas aceptan el riesgo, activa la suscripción. Si safe dejó de avanzar, no intenta adivinar qué ocurre: espera.
Finalmente, Ethereum finaliza el bloque y la aplicación cierra su registro contable.
No desapareció el riesgo. Tampoco desapareció la complejidad.
Lo que cambió es que la decisión dejó de estar escondida.
Lo que Ethereum puede mejorar
Las mejoras del protocolo hacen que este recorrido sea más rápido y más confiable, pero no reemplazan la decisión de la aplicación.
EIP-8198, Quick Slots, propone hacer paramétrica la duración de los slots y reducirla a medida que las pruebas lo permitan. Eso puede acortar el tiempo hasta que una transacción entra en un bloque.
FOCIL, Scheduled for Inclusion en Hegotá, busca fortalecer la inclusión. Es importante porque una transacción que nunca entra tampoco puede liquidarse.
EIP-8141, Frame Transactions, está Considered for Inclusion en Hegotá. Puede acercar al protocolo la validación programable, el batching y otras formas de pagar gas. Eso mejora la manera en que un usuario autoriza un pago.
Quick Slots ayuda a que la transacción llegue antes. FOCIL ayuda a que pueda entrar. Frame Transactions puede hacer más fácil enviarla. FCR puede dar una garantía útil antes de la finalidad.
Ninguna de ellas sabe si el comercio debería activar la suscripción.
Ese último paso sigue perteneciendo a la aplicación.
Lo primero que construiría
No empezaría escribiendo otro estándar.
Empezaría con algo menos emocionante y más fácil de romper: una pequeña librería que observe latest, safe y finalized, aplique una política versionada y devuelva una decisión.
Después intentaría hacerla fallar:
- detenería el avance de
safe; - conectaría dos proveedores que reporten cabeceras distintas;
- probaría una reorganización;
- deshabilitaría FCR;
- cambiaría la política mientras existan pagos pendientes.
También guardaría un registro sencillo de cada decisión. No para llenar un dashboard de gráficas, sino para responder una pregunta cuando algo salga mal:
¿Por qué el sistema actuó en ese momento?
Si el modelo sobrevive a un checkout, un depósito o un bridge real, entonces valdrá la pena discutir esquemas compartidos, webhooks o una estandarización más amplia.
Ethereum no debería decidir cuándo un comercio entrega su producto.
Las aplicaciones tampoco deberían inventar significados opacos para “confirmado”.
Liquidar sin ceder el control
Usar un RPC gestionado, un relayer o un servicio de monitoreo no elimina la autocustodia por sí solo. El problema comienza cuando ese proveedor se convierte en una caja negra que nadie puede inspeccionar ni reemplazar.
Una política de liquidación debería registrar de dónde salió cada señal y permitir que la infraestructura cambie sin cambiar el significado del dinero.
Eso es lo que intento expresar con el título.
Liquidar sin ceder el control no significa esperar la finalidad para absolutamente todo. Tampoco significa actuar rápido y confiar en que nada saldrá mal.
Significa saber qué garantía existe, comprobar que sigue vigente y actuar solo cuando la política permite aceptar ese riesgo.
El check puede seguir siendo verde.
Pero detrás tiene que existir una decisión que alguien pueda explicar.