1. Introducción y motivación

Fondo

La plataforma EQTY se basa en una arquitectura de doble capa:

  • Una capa privada para gestionar cadenas de eventos verificables (por ejemplo, Ownables, mensajes)

  • Una capa de anclaje pública para sellar y verificar esas cadenas de eventos en una blockchain inmutable

Históricamente, esta capa pública fue proporcionada por LTO Network Layer 1, una blockchain dedicada de Proof-of-Stake optimizada para el anclaje.

Sin embargo, el contexto operativo ha cambiado significativamente.

Por qué LTO Layer 1 debe ser deprecado

1. La seguridad económica ha colapsado

  • LTO actualmente tiene una capitalización de mercado inferior a $5M, con solo ~20% de los tokens apostados.

  • Esto significa que el presupuesto de seguridad efectivo (es decir, el valor total que asegura el consenso) es < $1M.

  • A estos niveles, es financieramente viable para un actor malicioso comprometer el consenso, censurar transacciones de anclaje o reescribir la historia.

  • Para una plataforma como EQTY — que ancla registros de activos legalmente exigibles — esto es inaceptable.

2. Centralización de validadores e incentivos bajos

  • Los nodos comunitarios ya no son viables económicamente.

  • Los nodos que terminan el servicio podrían llevar a un pequeño conjunto de nodos a tener un control desproporcionado sobre el consenso.

  • Esto socava las garantías de descentralización que el anclaje está destinado a proporcionar.

3. Fricción de adopción

  • Es cada vez más difícil justificar a LTO como una capa de anclaje segura en conversaciones de ventas o auditoría.

  • Los clientes y socios esperan que EQTY ancle en redes públicas ampliamente adoptadas y creíbles (por ejemplo, Ethereum, Base).

  • La percepción de “anclar a una Capa 1 de $5M” debilita la confianza en la infraestructura central de EQTY.

4. Fragilidad de la infraestructura

  • Si incluso unos pocos validadores clave se desconectan, LTO se vuelve inestable o se detiene por completo.

  • El mantenimiento continuo (exploradores, indexadores, infraestructura de nodos) añade sobrecarga con valor decreciente.

Por qué Base es la capa de anclaje adecuada

Base ofrece:

  • Compatibilidad total con EVM

  • Seguridad económica y técnica heredada de Ethereum

  • Amplio soporte de herramientas (MetaMask, WalletConnect, The Graph, etc.)

  • Tarifas casi nulas con rápida finalización

  • Cercana alineación con la capa de activos y liquidez de EQTY, que también reside en Base

El anclaje a Base elimina la carga de mantener una Capa 1 personalizada al tiempo que aumenta la auditabilidad, composabilidad y confianza.

Motivación estratégica

  • El valor de EQTY no está en el consenso — está en su capa privada, modelo de activos y arquitectura de cumplimiento.

  • Mantener una Capa 1 ofrece poco beneficio estratégico a alto costo.

  • Pasar a Base permite a EQTY centrarse completamente en la adopción del producto, la integración legal y la tokenización de activos, sin ser arrastrado por la infraestructura de Capa 1.

2. Nuevo token $EQTY ERC-20

La plataforma EQTY introducirá un nuevo token ERC-20, $EQTY, desplegado en la red Base. Este token reemplaza al token LTO y sirve como la moneda nativa para las operaciones del protocolo, incluyendo el anclaje y la gobernanza.

El contrato de token comienza con suministro cero. $EQTY se acuña bajo demanda cuando los usuarios intercambian sus tokens LTO durante un período de migración limitado. Esta ventana se aplica en cadena: después de una altura de bloque predefinida, la función de acuñación se desactiva permanentemente. Cualquier token LTO no convertido antes de este corte queda excluido del ecosistema de EQTY, y el suministro final de $EQTY será menor que el suministro original de LTO.

El contrato de token es deliberadamente mínimo. Sigue la interfaz estándar de ERC-20, sin lógica de transferencia especial, características de airdrop o cronogramas de vesting.

El token $EQTY se utilizará para pagar tarifas de anclaje, participar en la gobernanza del protocolo y potencialmente apoyar roles de utilidad adicionales a medida que la plataforma evoluciona. La utilidad requiere que los tokens sean quemados, reduciendo el suministro total.

3. Contrato de anclaje en Base

El anclaje se realizará a través de un contrato inteligente ligero desplegado en la red Base. Este contrato emite eventos que registran públicamente el hash de cadenas de eventos o mensajes, sin almacenar ningún estado en cadena.

Cada anclaje mapea una clave a un valor, donde:

  • Para cadenas de eventos: clave = stateHash, valor = eventHash

  • Para mensajes: clave = messageHash, valor = 0x0

Interfaz

struct Anchor {

bytes32 clave;

valor bytes32;

}

function anchor(Anchor[] calldata anchors) external;

evento Anclado(

bytes32 clave indexada,

valor bytes32,

dirección remitente indexada,

uint64 selloTiempo

);

Comportamiento

  • El contrato emite un evento Anclado por cada par (clave, valor).

  • El timestamp actual del bloque se incluye en el evento como un campo separado por conveniencia y auditabilidad.

  • No se almacena estado en el contrato. Todos los datos de anclaje se registran solo a través de registros.

  • El contrato es sin permisos: cualquiera puede anclar.

Estos eventos están diseñados para ser indexables y accesibles por:

  • Componentes internos, como el indexador oBridge y la plataforma EQTY

  • Servicios externos, incluyendo The Graph, Infura o verificadores personalizados

Al mantener el anclaje sin estado y emitir eventos completos, este diseño asegura que el anclaje sea verificable, eficiente e independiente de la infraestructura.

Mecanismo de tarifas

  • Los clientes necesitan llamar a approve() en el contrato ERC20 para habilitar el anclaje

  • Cada anclaje incurre en una quema de $EQTY, impuesta en la función anchor()

  • La cantidad de la tarifa se lee de un contrato de configuración separado controlado por la gobernanza

  • El anclaje no utilizará approve() sino que quemará a través de eqtyToken.burnFrom(msg.sender, fee * n)

4. Gobernanza de tarifas

Para mantener el anclaje económicamente sostenible y justo a lo largo del tiempo, la tarifa pagada en $EQTY por anclaje debe ser ajustable. En lugar de codificar una tarifa estática o depender de oráculos de precios, EQTY utilizará un modelo de gobernanza en cadena para controlar este parámetro de manera transparente y descentralizada.

Un contrato de configuración dedicado almacenará la tarifa de anclaje actual. Este valor solo puede ser actualizado por un contrato de gobernanza: específicamente, una instancia del Gobernador de OpenZeppelin vinculada al token $EQTY. Los votos se emitirán en función de los saldos de $EQTY utilizando la lógica estándar de ERC20Votes.

El contrato de anclaje lee la tarifa actual del contrato de configuración controlado por la gobernanza cada vez que se llama a anchor(). Luego quema la cantidad apropiada de $EQTY directamente del saldo del remitente. Este enfoque evita la necesidad de transacciones approve() y asegura que el contrato de anclaje permanezca ligero y sin estado más allá de la imposición de tarifas.

El modelo de gobernanza permite a la comunidad ajustar las tarifas a lo largo del tiempo en respuesta a las condiciones del mercado, fluctuaciones de precios de tokens o cambios en la demanda de anclaje, sin depender de fuentes de datos externas o control centralizado.

5. Nueva biblioteca de capa privada

Para apoyar el anclaje en Base y la firma nativa de billetera, se creará una nueva biblioteca independiente de TypeScript para manejar la lógica de la capa privada, incluyendo cadenas de eventos, firma de eventos, anclaje y estructuras de mensajes de retransmisión. Esta biblioteca reemplaza la @ltonetwork/lto-api.js específica de LTO para todos los casos de uso de EQTY.

La nueva biblioteca está diseñada para ser utilizada tanto en entornos de navegador (por ejemplo, MetaMask, WalletConnect) como en herramientas del lado del servidor.

Alcance y contenidos

Solo se incluirán los componentes relevantes de la capa privada LTO:

  • eventos/ Incluye Event, EventChain, MergeConflict y lógica de serialización relacionada.

  • mensaje/ Incluye Message y Relay, utilizados para comunicación cifrada fuera de cadena.

  • Código de soporte Incluye clases de utilidad como Binary.

La biblioteca no tendrá dependencia de LTO Network:

  • Sin API de nodo LTO

  • Sin lógica de transacción

  • Sin herramientas de generación de pares de claves

  • Sin codificación de dirección específica de LTO

Apoyará el anclaje a través de contratos inteligentes en Base, e integrará cleanly con ethers.js para firmar y enviar anclajes.

Modelo de firma de eventos

El método Event.signWith() se hará asincrónico para admitir la firma basada en navegador a través de MetaMask, WalletConnect o cualquier firmante externo, además de firmar directamente con ethers. Utiliza una interfaz ISigner abstracta:

interfaz ISigner {

sign(data: Uint8Array): Promise<Uint8Array>;

}

El evento firmado ya no requiere una clave pública; solo incluye la firma y la dirección derivada. Esto lo hace compatible con flujos de firma de Ethereum (personal_sign) y elimina la necesidad de extraer claves públicas, lo cual no es posible en la mayoría de los entornos de billetera.

Integración de anclaje

La biblioteca incluye un método para generar mapas de anclaje:

const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();

Cada anclaje mapea un stateHash (clave) a un lastEventHash (valor), listo para ser enviado al contrato inteligente de Base. Para mensajes de retransmisión, el hash del mensaje en sí se utiliza como la clave de anclaje, y el valor se establece en cero (0x0).

El anclaje se puede realizar llamando directamente al contrato inteligente a través de ethers.Contract.anchor(Anchor[]). Esto evita la dependencia de cualquier servicio backend o infraestructura propietaria.

Firma de mensajes

La biblioteca también incluye clases Message y Relay para comunicación fuera de cadena. Al igual que los eventos, los mensajes se firman de forma asíncrona utilizando la interfaz ISigner. Las firmas son sobre el hash del mensaje, y no se incluye clave pública alguna: solo se utiliza la dirección derivada para la verificación.

Después de firmar, el hash del mensaje se ancla en cadena a través del mismo contrato Anchor. El formato es:

  • clave = messageHash

  • valor = 0x0

Esto asegura que los mensajes fuera de cadena puedan ser sellados públicamente y verificados sin revelar su contenido. El anclaje puede ser realizado por el remitente o el servicio de retransmisión.

Despliegue y uso

La biblioteca se publicará como un paquete NPM separado. Está destinada a ser el núcleo compartido utilizado por:

  • La billetera EQTY (para la firma de eventos y mensajes)

  • El servicio de retransmisión (para cálculo de hash y análisis de mensajes)

  • El SDK de Ownables (para la construcción y presentación de eventos)

  • Cualquier frontend o verificador de terceros

6. Indexación oBridge

El servicio de oBridge reemplazará su lógica actual de indexación basada en LTO con un nuevo indexador que procesa eventos Anclados emitidos por el contrato de anclaje de Base.

Este indexador escucha los registros de anclaje en Base y mantiene una base de datos local del anclaje más reciente por clave, que puede representar ya sea un estado de cadena de eventos o un hash de mensaje de retransmisión. Cada entrada incluye:

  • clave: el estado anclado o hash del mensaje

  • valor: el hash del evento correspondiente o 0x0

  • txHash, númeroBloque, logIndex y remitente

Estos registros se exponen a través de una API HTTP pública. La estructura y el comportamiento de esta API seguirán siendo compatibles con el indexador de anclaje LTO existente, incluyendo el endpoint GET /hash/verify, permitiendo que los componentes EQTY existentes se transicionen con cambios mínimos.

El indexador oBridge cumple dos roles:

  1. Como una dependencia interna para el servicio de retransmisión, que debe verificar que los mensajes han sido anclados antes de liberarlos.

  2. Como un servicio de verificación pública para clientes externos y billeteras que desean comprobar el estado de anclaje sin consultar a Base directamente.

Todos los datos permanecen verificables en cadena, y los clientes pueden eludir oBridge si lo desean utilizando eth_getLogs o su propio indexador.

7. Servicio de retransmisión

El servicio de retransmisión maneja la entrega segura de mensajes cifrados entre partes. Para garantizar que los mensajes sean auténticos, con sello de tiempo y controlados por acceso, el servicio se actualizará para admitir tanto la validación de anclaje en cadena como la autenticación moderna y nativa de billetera usando Sign-In with Ethereum (SIWE).

Autenticación de mensajes con SIWE

En lugar de confiar en firmas de mensajes HTTP o desafíos personalizados, el relay implementará el estándar SIWE (EIP-4361). Este enfoque permite a los usuarios autenticarse firmando un mensaje de texto estándar con su billetera de Ethereum, produciendo una firma recuperable que los vincula a una sesión.

Flujo de inicio de sesión:

  1. El cliente solicita un mensaje SIWE del backend de retransmisión: GET /auth/siwe-message?address=0x...

  2. El servidor devuelve un mensaje estándar SIWE que incluye:

  • Dominio (por ejemplo, relay.eqty.network)

  • Nonce

  • Sello de tiempo de expiración

  • Campo de recursos opcional limitado a /messages?to=...

  • Declaración: por ejemplo, “Inicia sesión para acceder a tus mensajes EQTY.”

  1. El cliente firma el mensaje utilizando personal_sign

  2. El cliente envía el mensaje firmado y la firma a POST /auth/verify

  3. El servidor verifica la firma y emite:

  • Un token de acceso JWT (de corta duración, por ejemplo, 15 minutos)

  • Un token de actualización (de mayor duración, por ejemplo, 24 horas)

Todas las solicitudes de recuperación de mensajes subsiguientes (GET /messages?to=...) deben incluir el token de acceso en el encabezado de autorización.

Cuando el token expire, el cliente puede usar el token de actualización para obtener un nuevo token de acceso sin necesidad de volver a firmar.

Este modelo es totalmente compatible con MetaMask, WalletConnect y otras billeteras EIP-1193, y sigue patrones de seguridad ampliamente adoptados. No se requiere lógica o infraestructura personalizada más allá de las bibliotecas existentes de SIWE.

Anclaje y verificación de mensajes

Además de la autenticación, el servicio de retransmisión validará que cada mensaje haya sido anclado en cadena antes de entregarlo. El anclaje proporciona inmutabilidad, sellado de tiempo y previene ataques de spam o repetición.

El relay mantiene su propio indexador ligero para el contrato de anclaje en Base. Escucha eventos Anclados y registra:

  • clave = messageHash

  • valor = 0x0

  • remitente

  • númeroBloque, txHash, selloTiempo

Para verificar un mensaje antes de la entrega, el relay verifica que:

  • Un evento Anclado existe con clave = messageHash

  • El valor es exactamente 0x0 (es decir, no es un anclaje de cadena de eventos)

  • El remitente coincide con el firmante del mensaje (es decir, dirección de origen)

Solo después de un anclaje exitoso se libera el mensaje al destinatario. Esto asegura que todos los mensajes sean públicamente verificables, sellados temporalmente en Base y anclados por la identidad correcta.

El relay realiza esta verificación utilizando su propio indexador interno y no depende de oBridge.

8. Cambios en el contrato Ownable (CosmWasm)

Con la migración lejos de LTO Layer 1 y la deprecación de la firma de eventos basada en clave pública, los contratos Ownable deben actualizarse para admitir la autorización basada en dirección utilizando direcciones estándar de Ethereum.

Autorización basada en dirección

Anteriormente, la verificación de propiedad dependía de recuperar y comparar claves públicas extraídas de eventos firmados. Dado que las billeteras de Ethereum no exponen claves públicas, y las firmas ahora utilizan personal_sign (recuperable a una dirección), el modelo de verificación debe cambiar a comparar direcciones directamente.

La lógica de contrato actualizada utiliza info.sender: la dirección que firmó y presentó el evento como la identidad autoritativa.

Esto afecta todos los puntos de entrada donde se requiere autorización:

  • try_transfer: el remitente debe coincidir con la dirección del propietario actual

  • try_release: el remitente debe coincidir con la dirección del propietario bloqueado anterior

  • try_register_lock: verifica que el campo propietario del evento coincida con el firmante

En lugar de convertir claves públicas en direcciones LTO, el contrato simplemente almacena y compara valores Addr (por ejemplo, 0xabc123...).

CAIP-2 y coincidencia de red

El contrato continúa validando el origen de los eventos de cadena cruzada utilizando el identificador de red CAIP-2. Para mensajes basados en Ethereum, el espacio de nombres es eip155:<chainId>. El contrato verifica que:

  • La event.network coincide con la red esperada

  • El campo propietario en el evento coincide con el firmante (info.sender) bajo el espacio de nombres CAIP dado

Las funciones de conversión address_lto() y address_eip155() se pueden eliminar, ya que ya no se necesita traducción hacia o desde direcciones LTO.

Impacto

Este cambio hace que el contrato Ownable sea:

  • Totalmente compatible con la firma y la identidad nativas de Ethereum

  • Independiente de la infraestructura de claves LTO

  • Compatible con cualquier cadena que soporte recuperación basada en dirección (por ejemplo, EVM)

Los Ownables existentes, que dependen de la firma y anclaje específicas de LTO, se volverán no verificables bajo el nuevo modelo y deben ser reemitidos (ver Sección 11).

9. Actualización del SDK de Ownables

El SDK de Ownables debe actualizarse para reflejar el cambio de la firma de clave pública basada en LTO a la autorización basada en dirección de estilo Ethereum y anclaje en Base.

Actualizaciones clave

  1. Firma de eventos

  • Actualizar la creación de eventos para utilizar la nueva biblioteca de capa privada (@eqty-core/events)

  • Utilizar implementaciones de ISigner compatibles con MetaMask, WalletConnect o firmantes basados en ethers

  • Asegúrate de que signWith() ya no dependa de una clave pública; solo se utiliza la dirección recuperable

  1. Anclaje

  • Reemplazar la lógica de anclaje de nodo LTO con presentación de contrato inteligente en Base

  • Utilizar getAnchorMap() para recopilar pares (clave, valor) y enviarlos a través de ethers.Contract.anchor()

  • Asegurar que el anclaje de mensajes use (clave = messageHash, valor = 0x0)

  1. Verificación

  • Actualizar la lógica de verificación para usar la API compatible con oBridge /hash/verify o una consulta directa de registros

  • Confirma que el valor del ancla coincida con el hash del evento esperado y que el remitente coincida con la dirección de Ethereum del firmante

  1. Uso de direcciones

  • Reemplaza cualquier lógica que compare o genere direcciones LTO

  • Utiliza direcciones Ethereum simples (0x...) en todo el flujo de eventos y mensajes

Compatibilidad

El SDK actualizado permanece estructuralmente similar pero ya no está vinculado a la biblioteca @ltonetwork/lto-api.js o los servicios de nodos LTO. Es compatible con la nueva biblioteca de capa privada y el anclaje en Base, y funcionará en conjunto con los contratos Ownable actualizados y el servicio de retransmisión.

10. Actualización de la Billetera Universal

La billetera universal debe actualizarse para reflejar la migración a Base y la nueva arquitectura EQTY. Ya no interactúa con nodos LTO.

Actualizaciones centrales

  1. Conexión de billetera

  • Reemplazar el manejo de pares de claves LTO con una biblioteca compatible con Ethereum (ethers.js)

  • Utilizar interfaces de proveedor EIP-1193 para habilitar la firma y recuperación de direcciones

  1. Soporte de token

  • Agregar soporte para mostrar y administrar saldos del nuevo token $EQTY ERC-20 en Base

  • Incluir metadatos del token, historial y seguimiento de saldos a través de puntos finales RPC públicos

  1. Firma de eventos y mensajes

  • Integra la nueva biblioteca de capa privada para permitir a los usuarios crear y firmar cadenas de eventos y mensajes

  • Utiliza personal_sign a través de la billetera conectada; ya no se requieren claves públicas

  1. Anclaje

  • Enviar mapas de anclaje directamente al contrato de anclaje de Base utilizando ethers.js

  • Manejar la presentación en cadena, confirmación y retroalimentación de UI opcional para el costo de anclaje en $EQTY

  1. Integración de relay

  • Autenticarse a través de SIWE (Iniciar sesión con Ethereum)

  • Almacenar y actualizar tokens de acceso según sea necesario

  • Utilizar solicitudes autenticadas para obtener mensajes cifrados del servicio de retransmisión

Características eliminadas

  • Interfaz de arrendamiento LTO

  • Selección de nodos y vista de cadena

  • Gestión de identidad en cadena vinculada a LTO

11. Plan de migración

Con la deprecación de LTO Layer 1 y la introducción de un nuevo sistema de anclaje en Base, todos los componentes centrales del protocolo deben migrar. Los datos heredados vinculados a la infraestructura de LTO, incluyendo anclajes, cadenas de eventos y mensajes, ya no serán válidos.

Lo que se vuelve inválido

  • Las cadenas de eventos firmadas utilizando pares de claves LTO no pueden ser verificadas, ya que la clave pública ya no es extraíble de las firmas basadas en Ethereum.

  • Los anclajes registrados en LTO L1 no pueden ser confiables ni consultados en el futuro.

  • Los elementos propiedad de identidades basadas en LTO o cadenas ancladas deben ser reemplazados.

  • Los mensajes no anclados en Base serán rechazados por el servicio de retransmisión.

Acciones requeridas

  1. Migración de tokenLos usuarios deben intercambiar manualmente sus tokens LTO por $EQTY utilizando el puente. La acuñación solo es posible hasta una altura de bloque específica en Base. Después de este bloque, el puente se cerrará y la función de acuñación se desactivará permanentemente. Los tokens LTO no intercambiados se vuelven inútiles.

  2. Reemitir activos Ownables.Los emisores Ownable deben emitir nuevos ownables vinculados a la red BASE. Se seguirán instrucciones sobre cómo intercambiar los Ownables heredados por nuevos Ownables

  3. Transición de billetera Los usuarios deberán actualizar la Billetera Universal.

Sin instantánea

No habrá instantánea, migración automática o capa de compatibilidad hacia atrás. Cada componente (eventos, mensajes, saldos de tokens) debe restablecerse en Base a través de las interfaces adecuadas. El nuevo protocolo es limpio por diseño y no preserva lazos con LTO L1.

#ETH