1. Introdução & Motivação
Contexto
A plataforma EQTY depende de uma arquitetura de dupla camada:
Uma camada privada para gerenciar cadeias de eventos verificáveis (por exemplo, Ownables, mensagens)
Uma camada de ancoragem pública para timestamp e verificar essas cadeias de eventos em uma blockchain imutável.
Historicamente, esta camada pública foi fornecida pela LTO Network Layer 1, uma blockchain dedicada de Proof-of-Stake otimizada para ancoragem.
No entanto, o contexto operacional mudou significativamente.
Por que a LTO Layer 1 deve ser deprecada
1. A segurança econômica colapsou
A LTO atualmente tem uma capitalização de mercado abaixo de $5M, com apenas ~20% dos tokens apostados.
Isso significa que o orçamento de segurança efetivo (ou seja, o valor total que garante o consenso) é de aproximadamente $1M.
Nesses níveis, é financeiramente viável para um ator malicioso comprometer o consenso, censurar transações de ancoragem ou reescrever a história.
Para uma plataforma como o EQTY — que ancora registros de ativos legalmente exigíveis — isso é inaceitável.
2. Centralização de validadores e baixos incentivos
Nós da comunidade não são mais economicamente viáveis.
Nós que terminam o serviço podem levar a um pequeno conjunto de nós detendo controle desproporcional sobre o consenso.
Isso mina as garantias de descentralização que a ancoragem deve fornecer.
3. Atrito na adoção
Está se tornando cada vez mais difícil justificar a LTO como uma camada de ancoragem segura em conversas de vendas ou auditoria.
Clientes e parceiros esperam que o EQTY ancore em redes públicas amplamente adotadas e credíveis (por exemplo, Ethereum, Base).
A percepção de "ancoragem a um Layer 1 de $5M" enfraquece a confiança na infraestrutura central do EQTY.
4. Fragilidade da infraestrutura
Se mesmo alguns validadores-chave ficarem offline, a LTO se tornará instável ou interromperá completamente.
A manutenção contínua (exploradores, indexadores, infraestrutura de nó) adiciona sobrecarga com valor em declínio.
Por que a Base é a camada de ancoragem certa
Base oferece:
Compatibilidade total com EVM
Segurança econômica e técnica herdada do Ethereum
Amplo suporte a ferramentas (MetaMask, WalletConnect, The Graph, etc.)
Taxas quase zero com finalização rápida
Alinhamento próximo com a camada de ativos e liquidez do EQTY, que também vive na Base
Ancorar na Base remove o fardo de manter um Layer 1 personalizado enquanto aumenta a auditabilidade, composabilidade e confiança.
Motivação estratégica
O valor do EQTY não está no consenso — está em sua camada privada, modelo de ativos e arquitetura de conformidade.
Manter um Layer 1 oferece pouca vantagem estratégica a um alto custo.
Mover para a Base permite que EQTY se concentre totalmente na adoção de produtos, integração legal e tokenização de ativos, sem ser arrastado pela infraestrutura do Layer 1.
2. Novo Token $EQTY ERC-20
A plataforma EQTY apresentará um novo token ERC-20, $EQTY, implantado na rede Base. Este token substitui o token LTO e serve como a moeda nativa para operações do protocolo, incluindo ancoragem e governança.
O contrato do token começa com zero fornecimento. $EQTY é cunhado sob demanda quando os usuários trocam seus tokens LTO durante um período de migração limitado. Esta janela é imposta on-chain: após uma altura de bloco pré-definida, a função de mintagem se torna permanentemente desabilitada. Quaisquer tokens LTO não convertidos antes desse corte são excluídos do ecossistema EQTY, e o fornecimento final de $EQTY será menor que o fornecimento original de LTO.
O contrato do token é deliberadamente minimalista. Ele segue a interface padrão ERC-20, sem lógica de transferência especial, recursos de airdrop ou cronogramas de vesting.
O token $EQTY será usado para pagar taxas de ancoragem, participar da governança do protocolo e potencialmente apoiar papéis de utilidade adicionais à medida que a plataforma evolui. Utilidade exige que tokens sejam queimados, reduzindo a oferta total.
3. Contrato de Ancoragem na Base
A ancoragem será realizada através de um contrato inteligente leve implantado na rede Base. Este contrato emite eventos que registram publicamente o hash de cadeias de eventos ou mensagens, sem armazenar nenhum estado on-chain.
Cada âncora mapeia uma chave a um valor, onde:
Para cadeias de eventos: chave = stateHash, valor = eventHash
Para mensagens: chave = messageHash, valor = 0x0
Interface
struct Anchor {
chave bytes32;
valor bytes32;
}
função anchor(Anchor[] calldata anchors) externo;
evento Ancorado(
chave indexed bytes32,
valor bytes32,
endereço indexed remetente,
uint64 timestamp
);
Comportamento
O contrato emite um evento Ancorado por par (chave, valor).
O current block.timestamp é incluído no evento como um campo separado para conveniência e auditabilidade.
Nenhum estado é armazenado no contrato. Todos os dados de ancoragem são registrados apenas através de logs.
O contrato é sem permissões — qualquer um pode ancorar.
Esses eventos são projetados para serem indexáveis e acessíveis por:
Componentes internos, como o indexador oBridge e a plataforma EQTY
Serviços externos, incluindo The Graph, Infura ou verificadores personalizados
Ao manter a ancoragem sem estado e emitir eventos completos, este design garante que a ancoragem seja verificável, eficiente e independente de infraestrutura.
Mecanismo de taxa
Os clientes precisam chamar approve() no contrato ERC20 para habilitar a ancoragem
Cada âncora incorrerá em uma queima de $EQTY, imposta na função anchor()
O valor da taxa é lido de um contrato de configuração controlado por governança separado
A ancoragem não usará approve() mas sim queima via eqtyToken.burnFrom(msg.sender, fee * n)
4. Governança de Taxas
Para manter a ancoragem economicamente sustentável e justa ao longo do tempo, a taxa paga em $EQTY por âncora deve ser ajustável. Em vez de codificar uma taxa estática ou depender de oráculos de preços, o EQTY usará um modelo de governança on-chain para controlar esse parâmetro de forma transparente e descentralizada.
Um contrato de configuração dedicado armazenará a taxa de ancoragem atual. Este valor só pode ser atualizado por um contrato de governança — especificamente, uma instância do Governador da OpenZeppelin vinculada ao token $EQTY. Os votos serão lançados com base nos saldos $EQTY usando a lógica padrão do ERC20Votes.
O contrato de ancoragem lê a taxa atual do contrato de configuração cada vez que anchor() é chamado. Em seguida, queima a quantidade apropriada de $EQTY diretamente do saldo do remetente. Essa abordagem evita a necessidade de transações approve() e garante que o contrato de ancoragem permaneça leve e sem estado além da imposição de taxas.
O modelo de governança permite que a comunidade ajuste taxas ao longo do tempo em resposta às condições de mercado, flutuações de preços de tokens ou mudanças na demanda de ancoragem — sem depender de fontes de dados externas ou controle centralizado.
5. Nova Biblioteca de Camada Privada
Para suportar ancoragem na Base e assinatura nativa de carteira, uma nova biblioteca TypeScript autônoma será criada para lidar com a lógica da camada privada — incluindo cadeias de eventos, assinatura de eventos, ancoragem e estruturas de mensagens de relay. Esta biblioteca substitui a @ltonetwork/lto-api.js específica da LTO para todos os casos de uso do EQTY.
A nova biblioteca é projetada para ser usada em ambientes de navegador (por exemplo, MetaMask, WalletConnect) e ferramentas do lado do servidor.
Escopo e conteúdos
Somente os componentes relevantes da camada privada da LTO serão incluídos:
events/ Inclui Evento, Cadeia de Eventos, MergeConflict e lógica de serialização relacionada.
message/ Inclui Mensagem e Relay, usado para comunicação criptografada off-chain.
Código de suporte Inclui classes utilitárias como Binary.
A biblioteca não terá dependência da LTO Network:
Sem API de nó LTO
Sem lógica de transação
Sem ferramentas de geração de chave
Sem codificação de endereço específica da LTO
Ele suportará ancoragem via contratos inteligentes na Base e se integrará perfeitamente com ethers.js para assinar e submeter âncoras.
Modelo de assinatura de evento
O método Event.signWith() será tornado assíncrono para suportar a assinatura baseada em navegador via MetaMask, WalletConnect ou qualquer signatário externo, além de assinar diretamente com ethers. Ele usa uma interface ISigner abstrata:
interface ISigner {
sign(data: Uint8Array): Promise<Uint8Array>
}
O evento assinado não requer mais uma chave pública; ele inclui apenas a assinatura e o endereço derivado. Isso o torna compatível com fluxos de assinatura do Ethereum (personal_sign) e remove a necessidade de extrair chaves públicas, o que não é possível na maioria dos ambientes de carteira.
Integração de ancoragem
A biblioteca inclui um método para gerar mapas de âncoras:
const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();
Cada âncora mapeia um stateHash (chave) a um lastEventHash (valor), pronta para ser submetida ao contrato inteligente da Base. Para mensagens de relay, o hash da mensagem em si é usado como a chave âncora, e o valor é definido como zero (0x0).
A ancoragem pode ser realizada chamando o contrato inteligente diretamente via ethers.Contract.anchor(Anchor[]). Isso evita a dependência de qualquer serviço de backend ou infraestrutura proprietária.
Assinatura de Mensagem
A biblioteca também inclui classes de Mensagem e Relay para comunicação off-chain. Como eventos, mensagens são assinadas assíncronamente usando a interface ISigner. Assinaturas são sobre o hash da mensagem, e nenhuma chave pública é incluída — apenas o endereço derivado é usado para verificação.
Após a assinatura, o hash da mensagem é ancorado on-chain via o mesmo contrato Anchor. O formato é:
chave = messageHash
valor = 0x0
Isso garante que mensagens off-chain possam ser timestamped e verificadas publicamente sem revelar seus conteúdos. A ancoragem pode ser feita pelo remetente ou pelo serviço de relay.
Implantação e uso
A biblioteca será publicada como um pacote NPM separado. É destinada a ser o núcleo compartilhado usado por:
A carteira EQTY (para assinatura de eventos e mensagens)
O serviço de relay (para cálculo de hash e análise de mensagens)
O SDK dos Ownables (para construção e submissão de eventos)
Qualquer frontend ou verificador de terceiros
6. Indexação oBridge
O serviço oBridge substituirá sua lógica de indexação baseada em LTO atual por um novo indexador que processa eventos Ancorados emitidos pelo contrato de ancoragem da Base.
Este indexador escuta os logs de ancoragem na Base e mantém um banco de dados local do âncora mais recente por chave, que pode representar o estado de uma cadeia de eventos ou um hash de mensagem de relay. Cada entrada inclui:
chave: o estado ancorado ou hash de mensagem
valor: o hash de evento correspondente ou 0x0
txHash, blockNumber, logIndex e remetente
Esses registros são expostos através de uma API HTTP pública. A estrutura e o comportamento dessa API permanecerão compatíveis com o indexador de ancoragem existente da LTO, incluindo o endpoint GET /hash/verify, permitindo que os componentes existentes do EQTY se transicionem com mudanças mínimas.
O indexador oBridge desempenha dois papéis:
Como uma dependência interna para o serviço de relay, que deve verificar se as mensagens foram ancoradas antes de liberá-las.
Como um serviço público de verificação para clientes externos e carteiras que desejam verificar o status de ancoragem sem consultar a Base diretamente.
Todos os dados permanecem verificáveis on-chain, e os clientes podem ignorar o oBridge se desejado, usando eth_getLogs ou seu próprio indexador.
7. Serviço de Relay
O serviço de relay lida com a entrega segura de mensagens criptografadas entre partes. Para garantir que as mensagens sejam autênticas, timestamped e controladas por acesso, o serviço será atualizado para suportar tanto a validação de ancoragem on-chain quanto a autenticação moderna e nativa de carteiras usando Sign-In with Ethereum (SIWE).
Autenticação de Mensagem com SIWE
Em vez de depender de assinaturas de mensagens HTTP ou desafios personalizados, o relay implementará o padrão SIWE (EIP-4361). Essa abordagem permite que os usuários se autentiquem assinando uma mensagem de texto padrão com sua carteira Ethereum, produzindo uma assinatura recuperável que os vincula a uma sessão.
Fluxo de login:
O cliente solicita uma mensagem SIWE do backend do relay: GET /auth/siwe-message?address=0x...
O servidor retorna uma mensagem SIWE padrão incluindo:
Domínio (por exemplo, relay.eqty.network)
Nonce
Timestamp de expiração
Campo de recursos opcionais limitado a /messages?to=...
Declaração: por exemplo, "Faça login para acessar suas mensagens EQTY."
O cliente assina a mensagem usando personal_sign
O cliente envia a mensagem assinada e a assinatura para POST /auth/verify
O servidor verifica a assinatura e emite:
Um token de acesso JWT (de curta duração, por exemplo, 15 minutos)
Um token de atualização (de mais longa duração, por exemplo, 24 horas)
Todas as solicitações de recuperação de mensagens subsequentes (GET /messages?to=...) devem incluir o token de acesso no cabeçalho Authorization.
Quando o token expirar, o cliente pode usar o token de atualização para obter um novo token de acesso sem re-assinar.
Este modelo é totalmente compatível com MetaMask, WalletConnect e outras carteiras EIP-1193, e segue padrões de segurança amplamente adotados. Nenhuma lógica ou infraestrutura personalizada é necessária além das bibliotecas SIWE existentes.
Ancoragem e Verificação de Mensagem
Além da autenticação, o serviço de relay validará que cada mensagem foi ancorada on-chain antes de entregá-la. A ancoragem fornece imutabilidade, timestamping e previne ataques de spam ou replay.
O relay mantém seu próprio indexador leve para o contrato de ancoragem na Base. Ele escuta por eventos Ancorados e registra:
chave = messageHash
valor = 0x0
remetente
blockNumber, txHash, timestamp
Para verificar uma mensagem antes da entrega, o relay verifica que:
Um evento Ancorado existe com chave = messageHash
O valor é exatamente 0x0 (ou seja, não é um âncora de cadeia de eventos)
O remetente corresponde ao signatário da mensagem (ou seja, do endereço)
Somente após a ancoragem bem-sucedida a mensagem é liberada para o destinatário. Isso garante que todas as mensagens sejam publicamente verificáveis, timestamped na Base e ancoradas pela identidade correta.
O relay realiza essa verificação usando seu próprio indexador interno e não depende do oBridge.
8. Alterações no Contrato Ownable (CosmWasm)
Com a migração da LTO Layer 1 e a depreciação da assinatura de eventos baseada em chave pública, os contratos Ownable devem ser atualizados para suportar a autorização baseada em endereço usando endereços Ethereum padrão.
Autorização baseada em endereço
Anteriormente, a verificação de propriedade dependia da recuperação e comparação de chaves públicas extraídas de eventos assinados. Como as carteiras Ethereum não expõem chaves públicas, e as assinaturas agora usam personal_sign (recuperável para um endereço), o modelo de verificação deve mudar para comparar endereços diretamente.
A lógica do contrato atualizado usa info.sender — o endereço que assinou e submeteu o evento — como a identidade autoritária.
Isso afeta todos os pontos de entrada onde a autorização é necessária:
try_transfer: o remetente deve corresponder ao endereço do proprietário atual
try_release: o remetente deve corresponder ao endereço do proprietário bloqueado anterior
try_register_lock: verifica se o campo proprietário do evento corresponde ao signatário
Em vez de converter chaves públicas em endereços LTO, o contrato simplesmente armazena e compara valores Addr (por exemplo, 0xabc123...).
Correspondência CAIP-2 e de rede
O contrato continua a validar a origem dos eventos intercadeias usando o identificador de rede CAIP-2. Para mensagens baseadas em Ethereum, o namespace é eip155:<chainId>. O contrato verifica que:
O evento.network corresponde à rede esperada
O campo proprietário no evento corresponde ao signatário (info.sender) sob o namespace CAIP dado
As funções de conversão address_lto() e address_eip155() podem ser removidas, pois não é mais necessário traduzir para ou de endereços LTO.
Impacto
Essa mudança torna o contrato Ownable:
Totalmente compatível com assinatura e identidade nativas do Ethereum
Independente da infraestrutura de chave da LTO
Compatível com qualquer cadeia que suporte recuperação baseada em endereço (por exemplo, EVM)
Os Ownables existentes, que dependem da assinatura e ancoragem específicas da LTO, se tornarão não verificáveis sob o novo modelo e devem ser reemitidos (veja a Seção 11).
9. Atualização do SDK dos Ownables
O SDK dos Ownables deve ser atualizado para refletir a mudança da assinatura de chave pública baseada em LTO para a autorização baseada em endereço estilo Ethereum e ancoragem na Base.
Atualizações de chave
Assinatura de eventos
Atualizar a criação de eventos para usar a nova biblioteca de camada privada (@eqty-core/events)
Usar implementações ISigner compatíveis com MetaMask, WalletConnect ou signatários baseados em ethers
Garantir que signWith() não dependa mais de uma chave pública; apenas o endereço recuperável é usado
Ancoragem
Substituir a lógica de ancoragem do nó LTO pela submissão de contrato inteligente na Base
Usar getAnchorMap() para coletar pares (chave, valor) e submetê-los via ethers.Contract.anchor()
Garantir que a ancoragem da mensagem use (chave = messageHash, valor = 0x0)
Verificação
Atualizar a lógica de verificação para usar a API /hash/verify compatível com o oBridge ou uma consulta direta de log
Confirmar que o valor da âncora corresponde ao hash de evento esperado e que o remetente corresponde ao endereço Ethereum do signatário
Uso de endereço
Substituir qualquer lógica que compare ou gere endereços LTO
Usar endereços Ethereum simples (0x...) em todos os fluxos de eventos e mensagens
Compatibilidade
O SDK atualizado permanece estruturalmente semelhante, mas não está mais vinculado à biblioteca @ltonetwork/lto-api.js ou aos serviços de nó LTO. Ele é compatível com a nova biblioteca de camada privada e ancoragem da Base, e irá interagir com os contratos Ownable atualizados e serviço de relay.
10. Atualização da Carteira Universal
A carteira universal deve ser atualizada para refletir a migração para a Base e a nova arquitetura EQTY. Ela não interage mais com nós LTO.
Atualizações principais
Conexão de carteira
Substituir o manuseio de chave LTO por uma biblioteca compatível com Ethereum (ethers.js)
Usar interfaces de provedor EIP-1193 para habilitar a assinatura e a recuperação de endereços
Suporte a tokens
Adicionar suporte para exibir e gerenciar saldos do novo token ERC-20 $EQTY na Base
Incluir metadados do token, histórico e rastreamento de saldos via endpoints RPC públicos
Assinatura de eventos e mensagens
Integrar a nova biblioteca de camada privada para permitir que os usuários criem e assinem cadeias de eventos e mensagens
Usar personal_sign via a carteira conectada; chaves públicas não são mais necessárias
Ancoragem
Submeter mapas de âncoras diretamente ao contrato de âncoras da Base usando ethers.js
Gerenciar submissão on-chain, confirmação e feedback opcional da interface do usuário para o custo de ancoragem em $EQTY
Integração de relay
Autenticar via SIWE (Sign-In with Ethereum)
Armazenar e atualizar tokens de acesso conforme necessário
Usar solicitações autenticadas para buscar mensagens criptografadas do serviço de relay
Recursos removidos
Interface de leasing LTO
Seleção de nó e visualização de cadeia
Gerenciamento de identidade on-chain vinculado à LTO
11. Plano de Migração
Com a depreciação do LTO Layer 1 e a introdução de um novo sistema de ancoragem na Base, todos os componentes principais do protocolo devem migrar. Dados legados vinculados à infraestrutura LTO — incluindo âncoras, cadeias de eventos e mensagens — não serão mais válidos.
O que se torna inválido
Cadeias de eventos assinadas usando pares de chaves LTO não podem ser verificadas, uma vez que a chave pública não pode mais ser extraída de assinaturas baseadas em Ethereum.
Âncoras registradas na LTO L1 não podem ser confiadas ou consultadas daqui para frente.
Ownables vinculados a identidades baseadas em LTO ou cadeias ancoradas devem ser substituídos.
Mensagens não ancoradas na Base serão rejeitadas pelo serviço de relay.
Ações necessárias
Migração de tokensOs usuários devem trocar manualmente seus tokens LTO por $EQTY usando a ponte. A mintagem só é possível até uma altura de bloco específica na Base. Após esse bloco, a ponte será desativada e a função de mintagem permanentemente desabilitada. Tokens LTO não trocados se tornarão sem valor.
Reemitir Ativos Ownables.Os emissários Ownable devem emitir novos ownables vinculados à rede BASE. Instruções seguirão sobre como trocar Ownables legados por novos Ownables
Transição da carteira Os usuários precisarão atualizar a Carteira Universal.
Sem snapshot
Não haverá snapshot, migração automática ou camada de compatibilidade retroativa. Cada componente (eventos, mensagens, saldos de tokens) deve ser restabelecido na Base através das interfaces apropriadas. O novo protocolo é limpo por design e não preserva vínculos com a LTO L1.
