Una transacción de Ethereum puede estar firmada correctamente y, aun así, ejecutar una operación financiera que el usuario nunca habría aceptado si hubiera establecido un límite de pérdida relevante. La investigación de la Ethereum Foundation publicada el 5 de octubre analiza cómo las llamadas «afirmaciones» de transacción podrían permitir a las carteras y los protocolos imponer condiciones sobre el resultado final, pero también señala el principal riesgo: que la aplicación o el servicio que construye la operación sea quien fije un umbral demasiado permisivo.
La propuesta está recogida en el EIP-7906, que a 9 de octubre continúa siendo un borrador. El estándar fue creado el 21 de febrero de 2025 y depende de las transacciones por tramas del EIP-8141. El registro de la actualización Hegotá incluye el EIP-8141 entre las propuestas previstas y el EIP-7906 entre las consideradas para su inclusión.
El límite puede existir y seguir siendo insuficiente
Ethereum ya cuenta con mecanismos que imponen ciertos límites financieros. En Uniswap v3, el enrutador rechaza una operación de intercambio con entrada exacta si la cantidad recibida queda por debajo de amountOutMinimum. En una operación con salida exacta, la transacción falla si el importe gastado supera amountInMaximum. En ambos casos, las condiciones se incorporan a los parámetros de la llamada y se comprueban durante la ejecución.
El problema está en el valor elegido para esos parámetros. La propia guía de Uniswap utiliza como ejemplo simplificado un mínimo de salida igual a cero, aunque advierte de que esa configuración es arriesgada en producción y recomienda recurrir a un kit de desarrollo, un oráculo de precios u otra fuente de datos para calcular un valor más seguro.
Un mínimo de recepción expresa una cantidad de tokens, no determina por sí mismo si el intercambio es económicamente razonable. Si quien prepara la transacción fija un suelo que permite recibir una cantidad ínfima, cualquier resultado ligeramente superior pasará el control. Y si ese mínimo se calcula a partir de una cotización ya desfavorable, el sistema puede hacer cumplir correctamente una mala operación.
Qué añadiría el EIP-7906
El EIP-7906 propone revisar de forma más amplia los efectos de una transacción. Sobre las tramas ordenadas del EIP-8141, incorpora al final unas tramas de solo lectura denominadas POST_TX. El código de afirmación examinaría el estado resultante y rechazaría la ejecución si no se cumple la regla definida.
El diseño contempla tres operaciones para realizar esas comprobaciones: TXTRACE, que enumera cambios netos y eventos concretos; TXDIFF, que recupera valores mediante claves; y EVENTDATACOPY, que permite acceder a los datos de los eventos. El alcance incluye saldos de ether, cambios de almacenamiento, contratos desplegados y sus huellas de código. Las comprobaciones sobre saldos de tokens exigirían interpretar el almacenamiento de los contratos correspondientes.
Con ello podrían definirse políticas más amplias que el mínimo recibido en un intercambio. Una cuenta podría exigir que su configuración de control permaneciera intacta, mientras que otra regla podría limitar autorizaciones o revisar los efectos producidos en varios contratos de una misma ruta. Aun así, la visión sería la del resultado neto: varias escrituras sobre una misma posición de almacenamiento quedarían resumidas entre el valor inicial y el final. Si una posición recupera su valor original, no aparecería como cambio neto.
La protección depende de quién impone la regla
El borrador no obliga a que todas las transacciones incluyan una afirmación. Las cuentas que quieran utilizarla deben configurar su lógica de validación para exigir una trama POST_TX concreta y evitar cualquier vía de elusión. Los protocolos tendrían una responsabilidad similar: una función protegida debería rechazar tanto las transacciones normales como las operaciones por tramas que no incluyeran el control exacto.
En liquidaciones en las que un intermediario o «solucionador» elige la ruta de ejecución, la protección del resultado del usuario tendría que quedar vinculada a la orden firmada o al protocolo de liquidación. Además, el código que aplica la afirmación debería ser inmutable y no actualizable. De lo contrario, la propia transacción podría modificarlo después de la validación y antes de la comprobación final.
La referencia utilizada para juzgar el resultado también es determinante. Si la operación cambia el precio empleado para decidir si esa misma operación es aceptable, leer el estado final no resuelve el problema. El EIP-7906 recomienda fijar los valores de referencia al firmar o tomarlos del estado al comienzo de la transacción. Persisten, no obstante, los riesgos habituales de los oráculos y la posibilidad de que otras operaciones del mismo bloque alteren ese estado inicial.
Una afirmación fallida revertiría la parte ejecutable, pero la transacción seguiría incluida en el bloque y el pagador asumiría el gas consumido. También podrían quedar confirmados cambios realizados durante la fase inicial de validación, como una aprobación de pago o la creación de una cuenta. Por eso, las acciones que se quieren proteger deben situarse en la parte que la afirmación pueda revertir y el control debe disponer de gas suficiente para completarse.
La Ethereum Foundation identifica posibles usos en agentes delegados y liquidaciones gestionadas por solucionadores. El estándar Clear Signing, anunciado por el grupo de trabajo de Ethereum el 12 de mayo de 2026, ayudaría a mostrar al usuario una descripción estructurada de la acción, pero no impondría por sí solo un resultado financiero mínimo. La conclusión de la propuesta es, por tanto, menos ambiciosa que automática: Ethereum podría hacer cumplir perfectamente una condición de seguridad y, aun así, aplicar el límite económico equivocado.
