Eric Conner propone ERC-8391 para ordenar el estado de las acciones tokenizadas

Una propuesta atribuida a Eric Conner plantea una interfaz común para describir el estado operativo de acciones tokenizadas y otros activos del mundo real. El diseño busca distinguir entre mercados cerrados, suspensiones, interrupciones de valoración y ventanas de canje, aunque su contenido y adopción aún requieren verificación y revisión.

***

• Eric Conner habría presentado una propuesta ERC para estandarizar el estado operativo de acciones tokenizadas y otros RWA.
• El diseño busca diferenciar precios sin actualizar por el cierre del mercado de aquellos afectados por problemas de valoración.
• La iniciativa apunta a facilitar reglas más consistentes para préstamos, liquidaciones, oráculos y canjes en cadena, pero todavía estaría abierta a revisión.

Las acciones tokenizadas pueden negociarse en cadena durante las 24 horas del día, aunque sus mercados de referencia tienen horarios limitados. Esa diferencia expone una limitación de los contratos inteligentes: cuando un precio deja de actualizarse, el código no puede saber por sí solo si el mercado está cerrado durante el fin de semana o si la fuente de datos dejó de funcionar. Ambos escenarios pueden producir datos similares en cadena, pero exigen respuestas completamente distintas.

Según la información disponible, Eric Conner habría anunciado el 24 de agosto que redactó una propuesta de estándar para Ethereum denominada ERC-8391. Su objetivo sería crear una interfaz común de estado de activos para acciones tokenizadas y otros activos del mundo real, conocidos como RWA. La propuesta pretende que los oráculos alimenten información estructurada y que los tokens respondan de forma coherente ante cambios relevantes del mercado.

El problema de los precios que dejan de actualizarse

En un activo financiero tradicional, un precio sin cambios durante varias horas puede tener una explicación normal: el mercado de referencia no está operando. En un entorno de contratos inteligentes, sin embargo, el mismo precio antiguo también puede indicar que el proveedor de datos se cayó, que el activo fue suspendido o que ocurrió un evento corporativo durante el periodo sin negociación. Sin una señal adicional, un protocolo podría tratar una pausa legítima como una emergencia, o asumir que un dato defectuoso sigue siendo válido.

La diferencia tiene consecuencias directas para las aplicaciones de finanzas descentralizadas que aceptan tokens como garantía. Un mercado de préstamos puede necesitar detener nuevas operaciones durante una suspensión, limitar el uso de una valoración antigua o aplazar una liquidación hasta que exista información confiable. Si solo observa el precio y la marca de tiempo de una actualización, carece del contexto necesario para distinguir entre una pausa programada y una interrupción crítica.

La propuesta también busca representar situaciones como suspensiones, bloqueos de precios y ventanas de reembolso. Una compañía podría ser adquirida durante el cierre del mercado, por ejemplo, mientras el token continúa circulando en cadena con la última cotización disponible. Para un contrato inteligente, el valor almacenado podría parecer idéntico al de un domingo normal, aunque la decisión económica apropiada sea diferente.

El riesgo aumenta cuando la lógica depende de automatizaciones que actúan sin intervención humana. Curadores pueden revisar manualmente unos pocos activos, pero los bots de liquidación, los módulos de políticas compatibles con cuentas inteligentes y los agentes que administran carteras tokenizadas necesitan señales programáticas uniformes. Un estándar de este tipo buscaría reducir el trabajo de construir una interpretación distinta para cada emisor y cada listado.

Qué información incorporaría la propuesta

ERC-8391 plantearía normalizar consultas relacionadas con las etapas del mercado, las suspensiones, la actividad de valoración y las ventanas de reembolso. La idea sería que un contrato pueda consultar el estado del activo mediante una interfaz definida, en lugar de depender de métodos propietarios o de servicios externos con estructuras incompatibles. Los oráculos seguirían proporcionando los datos, pero los tokens tendrían una forma común de exponerlos.

El borrador original describe una interfaz obligatoria de estado de activos llamada IAssetStatus, para representar el ciclo de vida del programa y su situación operativa. También contempla una interfaz de estado del mercado de referencia, IReferenceMarketStatus, que separaría la sesión de negociación de las interrupciones. Así, una aplicación podría distinguir entre una sesión regular, extendida, de subasta o cerrada, y entre una operación normal, un precio restringido, una suspensión del activo o una interrupción del mercado.

La propuesta incorporaría además un identificador de mercado denominado marketId, con referencia a un código MIC. No obstante, la evidencia disponible no confirma la mención del borrador a la norma ISO 10380, que corresponde a especificaciones sobre mangueras metálicas corrugadas y no al sistema de códigos MIC. Por ello, no se presenta esa vinculación como un hecho establecido.

Otra interfaz, IReferenceValuationStatus, buscaría diferenciar entre una valoración antigua porque no correspondía una actualización y otra que quedó desactualizada debido a un problema. Esa distinción no puede expresarse adecuadamente con un simple campo updatedAt en el feed de precios.

El diseño también incluiría IAssetPrimaryStatus, orientada a informar sobre la disponibilidad de las ventanas de emisión y de redención, incluidos los cortes relacionados con el valor neto de los activos. Sus enumeraciones reservarían UNKNOWN = 0, de modo que un almacenamiento vacío o una implementación proxy recién desplegada no se interprete como un estado operativo válido. Además, las vistas no deberían revertir, no dependerían de msg.sender y no usarían eventos, porque las transiciones de sesión ocurren por el reloj y no necesariamente por una transacción.

Interoperabilidad frente a diseños propietarios

La necesidad de una interfaz común surgiría porque los emisores ya exponen información parecida de maneras diferentes. El borrador menciona que Ondo utiliza una API externa de estado mediante HTTP, que los tokens de Robinhood Chain cuentan con una función propietaria llamada oraclePaused() y que muchos otros proyectos se limitan a un indicador genérico de pausa. Cada mercado que acepta estos instrumentos debe interpretar manualmente esas señales antes de definir límites de préstamo o reglas de liquidación.

Para los protocolos de crédito, esa fragmentación puede convertirse en un costo operativo y en una fuente de errores. Un curador humano podría estudiar cada implementación antes de incorporar cinco activos, pero el proceso resulta mucho menos práctico cuando los listados crecen y las decisiones pasan a manos de bots. Un estándar no elimina la necesidad de evaluar la calidad del emisor o del oráculo, aunque sí podría establecer un lenguaje compartido para consultar las condiciones relevantes.

El borrador aclara que sus estados tendrían carácter consultivo y que el estándar definiría las preguntas, no la confianza que merece cada respuesta. En otras palabras, una interfaz uniforme no demostraría que un precio es correcto ni convertiría automáticamente a un token en una garantía segura. La decisión final seguiría dependiendo del caso de uso, de la política del protocolo y de la confianza depositada en las fuentes que alimentan la información.

La propuesta buscaría complementar otros estándares en lugar de sustituirlos. El texto indica que no se solapa con ERC-8056, relacionado con multiplicadores de división, ni con ERC-7943 y ERC-3643, vinculados con controles de transferencia y cumplimiento. También podría componerse con productos de estado propios de los feeds, ya que una implementación podría obtener el estado de la sesión a partir de una fuente de valoración.

Una especificación todavía abierta a revisión

Conner habría pedido comentarios a emisores como Robinhood, Superstate, Ondo, Backed, Securitize y Dinari, además de otros participantes que estén creando estos tokens. La pregunta central sería si la interfaz puede implementarse como un adaptador delgado sobre los sistemas de estado que ya controlan, o si entraría en conflicto con sus arquitecturas actuales. También habría invitado a esos equipos a participar como posibles coautores de la especificación.

La revisión también estaría dirigida a curadores y equipos de mercados de préstamos, a quienes se preguntaría si consumirían la interfaz al establecer límites de crédito y reglas de liquidación. El objetivo sería descubrir qué elementos faltarían para que la propuesta resultara útil en producción, donde las decisiones deben considerar latencia, calidad de datos, actualizaciones de contratos y procedimientos de emergencia. Una aprobación formal no garantizaría por sí misma que todos los protocolos adopten el estándar.

El autor habría identificado dos áreas de estructura de mercado que requieren especial discusión: el mapeo del estado de subasta y el alcance de PRICE_CONSTRAINED. En esa categoría podrían entrar bloqueos de límites, cotizaciones especiales y restricciones parciales, por lo que Conner buscaría comentarios sobre mercados con condiciones que no encajen claramente en las enumeraciones propuestas.

La especificación habría sido probada sobre el papel con escenarios que incluyen pausas de almuerzo de HKEX, bloqueos de límites de precio en China continental, interrupciones de volatilidad de Xetra, valores sujetos a subastas periódicas de la Bolsa de Londres, semanas de negociación del Golfo y fondos con horarios de corte para el valor neto de activos. Una revisión teórica no equivale a una implementación productiva; el borrador señalaba además que una segunda compatibilidad de pruebas con Foundry estaba en desarrollo.

El alcance que ERC-8391 deja fuera

La iniciativa excluiría deliberadamente la economía de las acciones corporativas. Según el borrador, las divisiones de acciones corresponden a ERC-8056, mientras que fusiones y uniones de activos podrían requerir otras propuestas. ERC-8391 se concentraría en mostrar el estado del activo, del mercado de referencia, de la valoración y de las ventanas primarias, sin intentar resolver todos los eventos que pueden modificar los derechos económicos del token.

También se descartaría un resultado agregado que clasifique un activo como seguro o inseguro. Esa decisión respondería a que la seguridad depende del contexto del consumidor: el estado necesario para un mercado de préstamos puede no ser el mismo que requiere un sistema de negociación o un agente automatizado. Al exponer datos separados, el estándar pretendería evitar que una etiqueta general oculte matices importantes para cada aplicación.

El debate sobre el identificador de mercado permanecería abierto, especialmente respecto de si un código MIC basado en una representación codificada resulta suficiente. La discusión deberá considerar también listados extrabursátiles y otros entornos donde el activo de referencia no encaje en una sede de negociación tradicional. La respuesta influirá en la capacidad del estándar para comparar estados con calendarios y reglas públicas.

Causas de movimientos recientes

No se aportan datos de mercado ni evidencia suficiente para atribuir a ERC-8391 un movimiento concreto en el precio de ETH, de acciones tokenizadas o de otros activos. Por ahora, cualquier relación temporal entre el anuncio y una variación de mercado debe considerarse una explicación no identificada, no un catalizador confirmado.

La propuesta llega mientras los instrumentos tokenizados intentan combinar la disponibilidad continua de una cadena de bloques con las restricciones de mercados financieros que no operan permanentemente. Esa tensión no se resuelve con una cotización más frecuente, porque los horarios, suspensiones, canjes y fallas de valoración representan dimensiones distintas del riesgo. Si la comunidad adopta una interfaz común, los contratos podrían reaccionar con mayor precisión cuando el precio no cuente toda la historia.

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.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín