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 (e.g. Ownables, mensagens)

  • Uma camada de ancoragem pública para carimbar 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 Prova de Participação otimizada para ancoragem.

No entanto, o contexto operacional mudou significativamente.

Por que a LTO Layer 1 deve ser descontinuada

1. A segurança econômica entrou em colapso

  • A LTO atualmente tem um valor de mercado inferior a $5M, com apenas ~20% dos tokens em stake.

  • Isso significa que o orçamento de segurança efetivo (ou seja, o valor total que garante o consenso) é de < $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 a EQTY — que ancla registros de ativos legalmente aplicáveis — isso é inaceitável.

2. Centralização de validadores e baixos incentivos

  • Nós comunitários não são mais economicamente viáveis.

  • Nós encerrando serviços poderiam levar a um pequeno conjunto de nós mantendo controle desproporcional sobre o consenso.

  • Isso mina as garantias de descentralização que a ancoragem deve fornecer.

3. Fricção de adoção

  • Está 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 a EQTY ancore em redes públicas amplamente adotadas e credíveis (e.g. Ethereum, Base).

  • A percepção de “ancorar em uma Layer 1 de $5M” enfraquece a confiança na infraestrutura central da EQTY.

4. Fragilidade da infraestrutura

  • Se mesmo alguns validadores chave ficarem offline, a LTO se tornará instável ou parará completamente.

  • A manutenção contínua (exploradores, indexadores, infraestrutura de nós) adiciona sobrecarga com valor decrescente.

Por que a Base é a camada de ancoragem correta

A Base oferece:

  • Compatibilidade total com EVM

  • Segurança econômica e técnica herdada do Ethereum

  • Ampla compatibilidade de ferramentas (MetaMask, WalletConnect, The Graph, etc.)

  • Taxas quase zero com finalização rápida

  • Alinhamento próximo com a camada de ativos e liquidez da EQTY, que também reside na Base

Ancorar na Base remove o fardo de manter uma Layer 1 personalizada enquanto aumenta a auditabilidade, composabilidade e confiança.

Motivação estratégica

  • O valor da EQTY não está no consenso — está em sua camada privada, modelo de ativos e arquitetura de conformidade.

  • Manter uma Layer 1 oferece pouca vantagem estratégica a um alto custo.

  • Mover para a Base permite que a EQTY se concentre inteiramente na adoção do produto, integração legal e tokenização de ativos, sem ser arrastada pela infraestrutura da 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 de protocolo, incluindo ancoragem e governança.

O contrato do token começa com zero suprimento. $EQTY é cunhado sob demanda quando os usuários trocam seus tokens LTO durante um período de migração limitado. Esta janela é aplicada em cadeia: após uma altura de bloco pré-definida, a função de cunhagem torna-se permanentemente desativada. Qualquer token LTO não convertido antes deste corte é excluído do ecossistema EQTY, e o suprimento final de $EQTY será menor que o suprimento 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 suportar papéis de utilidade adicionais à medida que a plataforma evolui. A utilidade exige que os tokens sejam queimados, reduzindo o suprimento 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 qualquer estado em cadeia.

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 {

bytes32 chave;

valor bytes32;

}

function anchor(Anchor[] calldata anchors) external;

evento Ancorado(

bytes32 chave indexada,

valor bytes32,

endereço remetente indexado,

uint64 timestamp

);

Comportamento

  • O contrato emite um evento Ancorado por par (chave, valor).

  • O timestamp do bloco atual é 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ão — qualquer pessoa pode ancorar.

Esses eventos são projetados para ser 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 acarreta uma queima de $EQTY, aplicada na função anchor()

  • A quantidade da taxa é lida de um contrato de configuração controlado por governança separado

  • A ancoragem não usará approve() mas queimará 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, a EQTY usará um modelo de governança em cadeia para controlar este 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 atrelada ao token $EQTY. Os votos serão lançados com base nos saldos $EQTY usando a lógica padrão ERC20Votes.

O contrato de ancoragem lê a taxa atual do contrato de configuração toda vez que anchor() é chamado. Ele então 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 aplicação da taxa.

O modelo de governança permite que a comunidade ajuste taxas ao longo do tempo em resposta a condições de mercado, flutuações de preço do token 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 a ancoragem na Base e a assinatura nativa de carteira, uma nova biblioteca TypeScript independente será criada para lidar com a lógica da camada privada — incluindo cadeias de eventos, assinatura de eventos, ancoragem e estruturas de mensagens de retransmissão. Esta biblioteca substitui a biblioteca específica da LTO @ltonetwork/lto-api.js para todos os casos de uso da EQTY.

A nova biblioteca é projetada para ser usada em ambientes de navegador (e.g. MetaMask, WalletConnect) e ferramentas do lado do servidor.

Escopo e conteúdos

Apenas os componentes relevantes da camada privada LTO serão incluídos:

  • events/ Inclui Event, EventChain, MergeConflict e lógica de serialização relacionada.

  • message/ Inclui Message e Relay, usados para comunicação criptografada fora da cadeia.

  • Código de suporte Inclui classes utilitárias, como Binário.

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 pares de chaves

  • 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 eventos

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 abstrata ISigner:

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 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) para um lastEventHash (valor), pronto para ser submetido ao contrato inteligente da Base. Para mensagens de retransmissão, o hash da mensagem em si é usado como a chave de â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 Message e Relay para comunicação fora da cadeia. Assim como eventos, mensagens são assinadas assíncronamente usando a interface ISigner. As 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 em cadeia via o mesmo contrato Anchor. O formato é:

  • chave = messageHash

  • valor = 0x0

Isso garante que mensagens fora da cadeia possam ser carimbadas e verificadas publicamente sem revelar seu conteúdo. A ancoragem pode ser feita pelo remetente ou pelo serviço de retransmissão.

Implantação e uso

A biblioteca será publicada como um pacote NPM separado. Destina-se a ser o núcleo compartilhado usado por:

  • A carteira EQTY (para assinatura de eventos e mensagens)

  • O serviço de retransmissão (para cálculo de hash e análise de mensagens)

  • O SDK Ownables (para construção e submissão de eventos)

  • Qualquer frontend ou verificador de terceiros

6. Indexação do 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 logs de ancoragem na Base e mantém um banco de dados local do âncora mais recente por chave, que pode representar tanto um estado de cadeia de evento quanto um hash de mensagem de retransmissão. Cada entrada inclui:

  • chave: o estado ancorado ou hash da 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 desta API permanecerão compatíveis com o indexador de ancoragem LTO existente, incluindo o endpoint GET /hash/verify, permitindo que os componentes EQTY existentes transitem com mudanças mínimas.

O indexador oBridge desempenha dois papéis:

  1. Como uma dependência interna para o serviço de retransmissão, que deve verificar se as mensagens foram ancoradas antes de liberá-las.

  2. Como um serviço de verificação pública para clientes externos e carteiras que desejam verificar o status de ancoragem sem consultar a Base diretamente.

Todos os dados permanecem verificáveis em cadeia, e os clientes podem ignorar o oBridge se desejarem, usando eth_getLogs ou seu próprio indexador.

7. Serviço de retransmissão

O serviço de retransmissão lida com a entrega segura de mensagens criptografadas entre as partes. Para garantir que as mensagens sejam autênticas, com carimbo de data/hora e controladas por acesso, o serviço será atualizado para suportar tanto a validação de ancoragem em cadeia quanto a autenticação moderna, nativa de carteira, usando Sign-In com Ethereum (SIWE).

Autenticação de Mensagem com SIWE

Em vez de depender de assinaturas de mensagens HTTP ou desafios personalizados, o serviço de retransmissão 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:

  1. O cliente solicita uma mensagem SIWE do backend de retransmissão: GET /auth/siwe-message?address=0x...

  2. O servidor retorna uma mensagem padrão SIWE incluindo:

  • Domínio (e.g. relay.eqty.network)

  • Nonce

  • Timestamp de expiração

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

  • Declaração: e.g. “Faça login para acessar suas mensagens EQTY.”

  1. O cliente assina a mensagem usando personal_sign

  2. O cliente envia a mensagem assinada e a assinatura para POST /auth/verify

  3. O servidor verifica a assinatura e emite:

  • Um token de acesso JWT (de curta duração, e.g. 15 minutos)

  • Um token de atualização (de duração mais longa, e.g. 24 horas)

Todas as solicitações subsequentes de recuperação de mensagem (GET /messages?to=...) devem incluir o token de acesso no cabeçalho de Autorização.

Quando o token expirar, o cliente poderá 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 Mensagens

Além da autenticação, o serviço de retransmissão validará que cada mensagem foi ancorada em cadeia antes de entregá-la. A ancoragem proporciona imutabilidade, carimbo de data/hora e previne ataques de spam ou replay.

O serviço de retransmissão mantém seu próprio indexador leve para o contrato de ancoragem na Base. Ele escuta eventos Ancorados e registra:

  • chave = messageHash

  • valor = 0x0

  • remetente

  • blockNumber, txHash, timestamp

Para verificar uma mensagem antes da entrega, a retransmissão 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 de origem)

Somente após a ancoragem bem-sucedida é que a mensagem é liberada para o destinatário. Isso garante que todas as mensagens sejam publicamente verificáveis, carimbadas com data/hora na Base e ancoradas pela identidade correta.

O serviço de retransmissão realiza essa verificação usando seu próprio indexador interno e não depende do oBridge.

8. Mudanças no Contrato Ownable (CosmWasm)

Com a migração da LTO Layer 1 e a descontinuaçã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 de contrato atualizada 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 anterior bloqueado

  • 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 (e.g. 0xabc123...).

Correspondência CAIP-2 e de rede

O contrato continua a validar a origem de eventos interchain usando o identificador de rede CAIP-2. Para mensagens baseadas em Ethereum, o namespace é eip155:<chainId>. O contrato verifica que:

  • A event.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 fazer tradução para ou de endereços LTO.

Impacto

Essa mudança torna o contrato Ownable:

  • Completamente compatível com a assinatura e identidade nativas do Ethereum

  • Independente da infraestrutura de chave LTO

  • Compatível com qualquer cadeia que suporte recuperação baseada em endereço (e.g., EVM)

Os Ownables existentes, que dependem de assinatura e ancoragem específicas da LTO, se tornarão inviáveis sob o novo modelo e devem ser reemitidos (veja a Seção 11).

9. Atualização do SDK Ownables

O SDK Ownables deve ser atualizado para refletir a mudança da assinatura de chave pública baseada em LTO para autorização baseada em endereço estilo Ethereum e ancoragem na Base.

Atualizações de chave

  1. Assinatura de evento

  • Atualize a criação de eventos para usar a nova biblioteca de camada privada (@eqty-core/events)

  • Use implementações ISigner compatíveis com MetaMask, WalletConnect ou signatários baseados em ethers

  • Garanta que signWith() não dependa mais de uma chave pública; apenas o endereço recuperável é usado

  1. Ancoragem

  • Substitua a lógica de ancoragem de nós LTO pela submissão de contrato inteligente na Base

  • Use getAnchorMap() para coletar pares (chave, valor) e submetê-los via ethers.Contract.anchor()

  • Garanta que a ancoragem de mensagens use (chave = messageHash, valor = 0x0)

  1. Verificação

  • Atualize a lógica de verificação para usar a API /hash/verify compatível com o oBridge ou uma consulta de log direta

  • Confirme que o valor do âncora corresponde ao hash de evento esperado e que o remetente corresponde ao endereço Ethereum do signatário

  1. Uso de endereço

  • Substitua qualquer lógica que compare ou gere endereços LTO

  • Use endereços Ethereum simples (0x...) em todo o fluxo 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ós LTO. É compatível com a nova biblioteca de camada privada e ancoragem na Base, e interoperará com os contratos Ownable atualizados e o serviço de retransmissão.

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 de núcleo

  1. Conexão de carteira

  • Substitua o manuseio de pares de chaves LTO pela biblioteca compatível com Ethereum (ethers.js)

  • Use interfaces de provedor EIP-1193 para permitir a assinatura e recuperação de endereços

  1. Suporte a tokens

  • Adicione suporte para exibir e gerenciar saldos do novo token $EQTY ERC-20 na Base

  • Inclua metadados do token, histórico e rastreamento de saldo via endpoints RPC públicos

  1. Assinatura de eventos e mensagens

  • Integre a nova biblioteca de camada privada para permitir que os usuários criem e assinem cadeias de eventos e mensagens

  • Use personal_sign via a carteira conectada; chaves públicas não são mais necessárias

  1. Ancoragem

  • Envie mapas de âncoras diretamente para o contrato de ancoragem da Base usando ethers.js

  • Lide com a submissão em cadeia, confirmação e feedback opcional da interface do usuário para o custo de ancoragem em $EQTY

  1. Integração de retransmissão

  • Autentique via SIWE (Sign-In com Ethereum)

  • Armazene e atualize tokens de acesso conforme necessário

  • Use solicitações autenticadas para buscar mensagens criptografadas do serviço de retransmissão

Recursos removidos

  • Interface de leasing LTO

  • Seleção de nó e visualização de cadeia

  • Gerenciamento de identidade em cadeia vinculado à LTO

11. Plano de Migração

Com a descontinuação da 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 atrelados à 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 das assinaturas baseadas em Ethereum.

  • Âncoras registradas na LTO L1 não podem ser confiáveis ou consultadas a partir de agora.

  • Propriedades ligadas a identidades ou cadeias ancoradas baseadas em LTO devem ser substituídas.

  • Mensagens não ancoradas na Base serão rejeitadas pelo serviço de retransmissão.

Ações necessárias

  1. Migração de tokenOs usuários devem trocar manualmente seus tokens LTO por $EQTY usando a ponte. A cunhagem só é possível até uma altura de bloco específica na Base. Após este bloco, a ponte será fechada e a função de cunhagem desativada permanentemente. Tokens LTO não trocados tornam-se sem valor.

  2. Reemissão de Ativos Ownables.Os emissários Ownable devem emitir novos ownables atrelados à rede BASE. Instruções seguirão sobre como trocar Ownables legados por novos Ownables

  3. 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 LTO L1.

#ETH