ERC-8424 abre debate por transferencias forzadas y saldos privados en Ethereum

Un borrador de Ethereum propone ampliar las herramientas para tokens confidenciales de activos del mundo real con una función de transferencia forzada. Un participante de la revisión alertó que dos consultas podrían exponer información sobre saldos cifrados.
***

• ERC-8424 extiende ERC-7984 y plantea transferencias forzadas que, según el borrador, solo podrían ejecutar partes autorizadas.
• Un participante de Ethereum Magicians advirtió que ciertas funciones pueden consultarse sin restricción de llamador y podrían filtrar información sobre saldos.
• El borrador también contempla congelamientos, bloqueos, vesting y montos comprometidos al calcular cuánto saldo puede gastarse.

 

---

Un borrador de estándar para Ethereum propone habilitar transferencias forzadas de activos tokenizados cuyos montos permanecen cifrados. La iniciativa, identificada como ERC-8424, amplía las herramientas previstas para tokens confidenciales y busca atender casos en los que un emisor necesite mover activos sin el consentimiento de su titular.

La propuesta, sin embargo, abrió una discusión sobre cuánto pueden averiguar terceros acerca de esos saldos. Un participante del foro Ethereum Magicians señaló que dos funciones no restringen quién puede consultarlas y sostuvo que, bajo determinadas condiciones, las respuestas podrían permitir reconstruir información que debería permanecer oculta.

Una extensión para tokens confidenciales de activos reales

ERC-8424 se construye sobre ERC-7984, un estándar de Ethereum para tokens privados que representa los montos mediante punteros cifrados. El nuevo borrador busca sumar capacidades relacionadas con activos del mundo real tokenizados, conocidos como RWA, sin abandonar la premisa de que sus cantidades no aparezcan directamente como saldos públicos.

La propuesta agrega dos verificaciones de elegibilidad en texto plano y tres funciones privadas. Entre estas últimas figuran una comprobación confidencial para determinar si una transferencia está permitida, una cifra confidencial que indica cuánto saldo puede gastarse y un mecanismo para transferir activos de manera forzada, reservado a las partes autorizadas.

El diseño no trata como disponible todo el monto que un titular pudiera tener. Al calcular la cantidad gastable, plantea considerar congelamientos aplicados por el emisor, períodos de bloqueo, calendarios de vesting y montos comprometidos, factores que pueden reducir lo que queda habilitado para una transferencia en un momento determinado.

El borrador también aborda operaciones administrativas como acuñar, quemar, detener y congelar tokens, aunque establece límites sin especificar cómo deben implementarse. Según la descripción de la propuesta, las reglas buscan definir quién puede transferir y cuánto puede enviar, mientras que ERC-3643 y ERC-7943 ya atienden tareas similares para tokens cuyos saldos son públicos.

La alerta sobre consultas que podrían revelar saldos

La preocupación de seguridad surgió en el hilo de Ethereum Magicians, donde el participante identificado como zexoverz revisó el borrador y cuestionó el acceso a la comprobación de transferencias y a la función que calcula el saldo gastable. Según su observación, ninguna de las dos limita qué personas pueden llamar a esas funciones, por lo que un tercero podría investigar la cuenta de otro usuario.

La advertencia sobre la comprobación de transferencias depende de cómo se interpreten y descifren sus respuestas. Zexoverz indicó que una búsqueda binaria podría encontrar un saldo cifrado de 64 bits en un máximo de 64 llamadas, pero añadió una condición importante: quien consulta también tendría que poder descifrar la respuesta para obtener esa información.

El participante planteó un riesgo más directo para la función que informa cuánto puede gastarse: afirmó que esta podría revelar el saldo en una sola llamada. En su análisis, el problema no se limita a exponer una cifra, porque conocer el monto disponible también puede ofrecer pistas sobre las restricciones que afectan a una cuenta.

La diferencia entre ambas advertencias importa para evaluar el alcance del riesgo señalado. Una consulta repetida no equivale por sí sola a una revelación si su resultado no puede descifrarse, mientras que una función que devuelve directamente un valor utilizable podría requerir otro tipo de protección, de acuerdo con el planteamiento presentado en el foro.

El reto de proteger datos sin impedir controles del emisor

Zexoverz comparó la propuesta con ERC7984Freezable, un código actual de OpenZeppelin que, según su observación, solo permite al titular de una cuenta ver su propia cifra. Por ello pidió incorporar una regla equivalente a la especificación de ERC-8424, de manera que el acceso a información sensible no quede abierto a cualquier llamador.

El revisor también relacionó el posible filtrado con los límites de saldo y los calendarios de vesting. Si una transferencia falla porque el monto supera lo permitido por alguna de esas restricciones, la respuesta podría revelar información sobre el saldo, incluso sin descifrarlo directamente, explicó al remitirse a la sección del borrador denominada “Divulgación mediante reverts”.

Ese punto refleja una tensión central del diseño: los emisores necesitan aplicar restricciones y, en ciertos casos, ejecutar movimientos obligatorios, pero los titulares pueden esperar que las cantidades de sus tokens sigan siendo confidenciales. El texto intenta contemplar controles como congelamientos y montos comprometidos, aunque la alerta de zexoverz se enfoca en que las consultas asociadas también podrían convertirse en una vía de exposición.

La transferencia forzada es una capacidad especialmente sensible porque, según el borrador, permitiría al emisor mover activos sin contar con el consentimiento del titular. La propuesta limita esa operación a partes autorizadas, pero el debate no se reduce a quién puede ejecutarla: también incluye qué información pueden obtener quienes consultan las condiciones de una cuenta.

Un borrador aún sujeto a revisión

Según la publicación de Cryptopolitan, ERC-8424 seguía en etapa de borrador y requería otra revisión por parte de un editor de Ethereum. La publicación atribuye la apertura del pull request a Aryeh Greenberg, desarrollador de OpenZeppelin que participa en el repositorio ethereum/ERCs con el nombre arr00.

La misma publicación indica que el pull request se abrió el 25 de septiembre de 2026 y que el número 8424 se asignó ese viernes. También señala que abcoathup renombró el hilo del foro para que coincidiera con la numeración del borrador, mientras la propuesta seguía pendiente de revisión editorial.

Entre los editores que podrían realizar esa revisión, el texto menciona a g11tech, jochem-brouwer, samwilsn y xinbenlv. La existencia de esos nombres en la lista no significa que alguno haya aprobado ya el estándar; el estado descrito por la publicación es el de una propuesta que aún debía recibir otra revisión.

En esta fase, la observación de zexoverz funciona como una solicitud concreta para modificar la especificación y no como una confirmación de que el riesgo se haya materializado en un sistema desplegado. El desarrollo del borrador deberá aclarar quién puede consultar las funciones, cómo se protegen sus respuestas y de qué manera se concilian la confidencialidad de los saldos y la capacidad de los emisores para administrar activos tokenizados.

---

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.