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 (p. ej., Ownables, mensajes)
Una capa de anclaje pública para marcar 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 Prueba de Participación optimizada para el anclaje.
Sin embargo, el contexto operativo ha cambiado significativamente.
Por qué LTO Layer 1 debe ser desactivado
1. La seguridad económica ha colapsado
LTO actualmente tiene una capitalización de mercado inferior a $5M, con solo ~20% de tokens apostados.
Esto significa que el presupuesto de seguridad efectivo (es decir, el valor total que asegura el consenso) es de < $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 económicamente viables.
Los nodos que terminan el servicio podrían llevar a un pequeño conjunto de nodos que poseen 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 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 (p. ej., 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 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) agrega 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 cercanas a cero con finalización rápida
Cercana alineación con la capa de activos y liquidez de EQTY, que también vive en Base
Anclar a Base elimina la carga de mantener una Capa 1 personalizada mientras aumenta la auditabilidad, la composabilidad y la confianza.
Motivación estratégica
El valor de EQTY no está en consenso — está en su capa privada, modelo de activos y arquitectura de cumplimiento.
Mantener una Capa 1 ofrece poco ventaja estratégica a un alto costo.
Moverse a Base permite a EQTY enfocarse completamente en la adopción del producto, integración legal y tokenización de activos, sin ser ralentizado por la infraestructura de Capa 1.
2. Nuevo Token ERC-20 $EQTY
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 anclaje y gobernanza.
El contrato de token comienza con una oferta cero. $EQTY se acuña a demanda cuando los usuarios intercambian sus tokens LTO durante un período limitado de migración. 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 EQTY, y la oferta final de $EQTY será menor que la oferta original de LTO.
El contrato de token es deliberadamente mínimo. Sigue la interfaz estándar ERC-20, sin lógica de transferencia especial, funciones de airdrop o cronogramas de vesting.
El token $EQTY se utilizará para pagar tarifas de anclaje, participar en la gobernanza del protocolo y potencialmente respaldar roles de utilidad adicionales a medida que la plataforma evoluciona. La utilidad requiere que los tokens sean quemados, reduciendo la oferta total.
3. Contrato de Anclaje en Base
El anclaje se realizará a través de un contrato inteligente liviano 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 ancla mapea una clave a un valor, donde:
Para cadenas de eventos: clave = stateHash, valor = eventHash
Para mensajes: clave = messageHash, valor = 0x0
Interfaz
struct Anchor {
clave bytes32;
valor bytes32;
}
función anchor(Anchor[] calldata anchors) external;
evento Anclado(
clave indexed bytes32,
valor bytes32,
dirección indexed remitente,
uint64 timestamp
);
Comportamiento
El contrato emite un evento Anclado por cada par (clave, valor).
El current block.timestamp se incluye en el evento como un campo separado para conveniencia y audibilidad.
No se almacena estado en el contrato. Todos los datos de anclaje se registran solo a través de logs.
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, incluidos 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 ancla 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 controlado por gobernanza separado
El anclaje no usará 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 ancla 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 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 se mantenga liviano y sin estado más allá de la aplicació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 soportar 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 relay. 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 en entornos de navegador (p. ej., MetaMask, WalletConnect) y herramientas del lado del servidor.
Alcance y contenidos
Solo se incluirán los componentes relevantes de la capa privada LTO:
eventos/ Incluye Evento, Cadena de Eventos, Conflicto de Fusión y lógica de serialización relacionada.
mensaje/ Incluye Mensaje y Relay, utilizado para comunicación encriptada fuera de cadena.
Código de soporte Incluye clases utilitarias como Binario.
La biblioteca no tendrá dependencia de LTO Network:
No API de nodo LTO
Sin lógica de transacciones
Sin herramientas de generación de pares de claves
Sin codificación de direcciones específica de LTO
Soportará el anclaje a través de contratos inteligentes en Base, e integrará limpiamente con ethers.js para firmar y enviar anclajes.
Modelo de firma de eventos
El método Event.signWith() se hará asincrónico para soportar 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 abstracta ISigner:
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 los 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 ancla mapea un stateHash (clave) a un lastEventHash (valor), listo para ser enviado al contrato inteligente Base. Para mensajes de relay, el hash del mensaje en sí se usa como clave de anclaje, y el valor se establece en cero (0x0).
El anclaje puede realizarse llamando directamente al contrato inteligente a través de ethers.Contract.anchor(Anchor[]). Esto evita depender de cualquier servicio de backend o infraestructura propietaria.
Firma de mensajes
La biblioteca también incluye clases de Mensaje y Relay para comunicación fuera de cadena. Al igual que los eventos, los mensajes se firman de forma asincrónica utilizando la interfaz ISigner. Las firmas son sobre el hash del mensaje, y no se incluye clave pública — solo se utiliza la dirección derivada para 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 con tiempo y verificados públicamente sin revelar su contenido. El anclaje puede ser realizado por el remitente o el servicio de relay.
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 firma de eventos y mensajes)
El servicio de relay (para cálculo de hash y análisis de mensajes)
El SDK de Ownables (para construcción y presentación de eventos)
Cualquier frontend o verificador de terceros
6. Indexación oBridge
El servicio oBridge reemplazará su lógica de indexación basada en LTO con un nuevo indexador que procesa eventos Anclados emitidos por el contrato de anclaje Base.
Este indexador escucha los logs de anclaje en Base y mantiene una base de datos local del ancla más reciente por clave, que puede representar el estado de una cadena de eventos o un hash de mensaje de relay. Cada entrada incluye:
clave: el estado anclado o el hash del mensaje
valor: el hash de evento correspondiente o 0x0
txHash, blockNumber, logIndex y remitente
Estos registros se exponen a través de una API HTTP pública. La estructura y comportamiento de esta API seguirán siendo compatibles con el indexador de anclaje LTO existente, incluyendo el punto final GET /hash/verify, permitiendo a los componentes existentes de EQTY transitar con cambios mínimos.
El indexador oBridge cumple dos roles:
Como una dependencia interna para el servicio de relay, que debe verificar que los mensajes hayan sido anclados antes de liberarlos.
Como un servicio de verificación pública para clientes externos y billeteras que deseen verificar el estado de anclaje sin consultar directamente a Base.
Todos los datos permanecen verificables en cadena, y los clientes pueden eludir oBridge si lo desean usando eth_getLogs o su propio indexador.
7. Servicio de Relay
El servicio de relay maneja la entrega segura de mensajes encriptados entre partes. Para asegurar que los mensajes sean auténticos, sellados con tiempo y controlados en su acceso, el servicio se actualizará para soportar tanto la validación de anclaje en cadena como la autenticación moderna nativa de billetera usando Sign-In with Ethereum (SIWE).
Autenticación de Mensajes con SIWE
En lugar de depender de 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:
El cliente solicita un mensaje SIWE del backend de relay: GET /auth/siwe-message?address=0x...
El servidor devuelve un mensaje SIWE estándar que incluye:
Dominio (p. ej., relay.eqty.network)
Nonce
Timestamp de expiración
Campo de recursos opcional limitado a /messages?to=...
Declaración: p. ej., “Inicie sesión para acceder a sus mensajes EQTY.”
El cliente firma el mensaje usando personal_sign
El cliente envía el mensaje firmado y la firma a POST /auth/verify
El servidor verifica la firma y emite:
Un token de acceso JWT (de corta duración, p. ej., 15 minutos)
Un token de actualización (de mayor duración, p. ej., 24 horas)
Todas las solicitudes de recuperación de mensajes posteriores (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 volver a firmar.
Este modelo es completamente 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 SIWE existentes.
Anclaje y verificación de mensajes
Además de la autenticación, el servicio de relay validará que cada mensaje ha 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 liviano para el contrato de anclaje en Base. Escucha eventos Anclados y registra:
clave = messageHash
valor = 0x0
remitente
blockNumber, txHash, timestamp
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 ancla de cadena de eventos)
El remitente coincide con el firmante del mensaje (es decir, desde la dirección)
Solo después del anclaje exitoso el mensaje es liberado al destinatario. Esto asegura que todos los mensajes sean verificables públicamente, sellados con tiempo 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 desactivación de la firma de eventos basada en clave pública, los contratos Ownable deben ser actualizados para soportar la autorización basada en dirección usando 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 autorizada.
Esto afecta todos los puntos de entrada donde se requiere autorización:
try_transfer: el remitente debe coincidir con la dirección actual del propietario
try_release: el remitente debe coincidir con la dirección del propietario bloqueado anterior
try_register_lock: verifica que el campo propietario del evento coincide con el firmante
En lugar de convertir claves públicas a direcciones LTO, el contrato simplemente almacena y compara valores Addr (p. ej., 0xabc123...).
Coincidencia de CAIP-2 y red
El contrato sigue validando el origen de 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:
El 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() pueden ser eliminadas, ya que no se necesita traducción hacia o desde direcciones LTO.
Impacto
Este cambio hace que el contrato Ownable:
Totalmente compatible con la firma e identidad nativas de Ethereum
Independiente de la infraestructura de claves LTO
Compatible con cualquier cadena que soporte recuperación basada en dirección (p. ej., EVM)
Los Ownables existentes, que dependen de la firma y anclaje específicos 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 ser actualizado para reflejar el cambio de la firma de clave pública basada en LTO a la autorización basada en dirección al estilo Ethereum y el anclaje en Base.
Actualizaciones clave
Firma de eventos
Actualizar la creación de eventos para usar la nueva biblioteca de capa privada (@eqty-core/events)
Usar implementaciones de ISigner compatibles con MetaMask, WalletConnect o signatarios basados en ethers
Asegurar que signWith() ya no dependa de una clave pública; solo se utiliza la dirección recuperable
Anclaje
Reemplace la lógica de anclaje de nodos LTO con la presentación de contratos inteligentes en Base
Use getAnchorMap() para recoger pares (clave, valor) y enviarlos a través de ethers.Contract.anchor()
Asegúrese de que el anclaje de mensajes use (clave = messageHash, valor = 0x0)
Verificación
Actualizar la lógica de verificación para usar la API /hash/verify compatible con oBridge o una consulta de log directa
Confirmar que el valor del anclaje coincide con el hash de evento esperado y que el remitente coincide con la dirección de Ethereum del firmante
Uso de direcciones
Reemplace cualquier lógica que compare o genere direcciones LTO
Utilice direcciones de Ethereum simples (0x...) en todos los flujos de eventos y mensajes
Compatibilidad
El SDK actualizado permanece estructuralmente similar pero ya no está vinculado a la biblioteca @ltonetwork/lto-api.js o servicios de nodos LTO. Es compatible con la nueva biblioteca de capa privada y el anclaje Base, y funcionará con los contratos Ownable actualizados y el servicio de relay.
10. Actualización de la Billetera Universal
La billetera universal debe ser actualizada para reflejar la migración a Base y la nueva arquitectura de EQTY. Ya no interactúa con nodos LTO.
Actualizaciones clave
Conexión de billetera
Reemplace el manejo de pares de claves LTO con una biblioteca compatible con Ethereum (ethers.js)
Utilice interfaces de proveedor EIP-1193 para habilitar la firma y recuperación de direcciones
Soporte de tokens
Agregar soporte para mostrar y gestionar saldos del nuevo token ERC-20 $EQTY en Base
Incluir metadatos del token, historial y seguimiento de saldos a través de puntos finales RPC públicos
Firma de eventos y mensajes
Integre la nueva biblioteca de capa privada para permitir a los usuarios crear y firmar cadenas de eventos y mensajes
Use personal_sign a través de la billetera conectada; ya no se requieren claves públicas
Anclaje
Enviar mapas de anclaje directamente al contrato de anclaje de Base usando ethers.js
Manejar la presentación en cadena, confirmación y retroalimentación opcional de la UI para el costo de anclaje en $EQTY
Integración de relay
Autenticarse a través de SIWE (Sign-In with Ethereum)
Almacenar y actualizar tokens de acceso según sea necesario
Utilizar solicitudes autenticadas para obtener mensajes encriptados del servicio de relay
Características eliminadas
Interfaz de leasing 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 desactivació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 LTO — incluidos anclas, cadenas de eventos y mensajes — ya no serán válidos.
Lo que se vuelve inválido
Las cadenas de eventos firmadas usando 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 o consultados en el futuro.
Los Ownables vinculados a identidades basadas en LTO o cadenas ancladas deben ser reemplazados.
Los mensajes no anclados en Base serán rechazados por el servicio de relay.
Acciones requeridas
Migración de tokensLos 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 apagará y la función de acuñación se desactivará permanentemente. Los tokens LTO no intercambiados se volverán inútiles.
Reemitar Activos Ownables.Los emisores Ownable deben emitir nuevos ownables vinculados a la red BASE. Instrucciones seguirán sobre cómo intercambiar Ownables heredados por nuevos Ownables
Transición de billetera Los usuarios necesitará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 ser restablecido en Base a través de las interfaces adecuadas. El nuevo protocolo es limpio por diseño y no preserva lazos con LTO L1.