1. Introduzione & Motivazione
Sfondo
La piattaforma EQTY si basa su un'architettura a doppio strato:
Un layer privato per gestire catene di eventi verificabili (ad es. Ownables, messaggi)
Un layer di ancoraggio pubblico per datare e verificare quelle catene di eventi su una blockchain immutabile
Storicamente, questo layer pubblico era fornito da LTO Network Layer 1, una blockchain dedicata al Proof-of-Stake ottimizzata per l'ancoraggio.
Tuttavia, il contesto operativo è cambiato significativamente.
Perché LTO Layer 1 deve essere deprecato
1. La sicurezza economica è crollata
LTO ha attualmente una capitalizzazione di mercato inferiore ai 5 milioni di dollari, con solo ~20% di token staked.
Questo significa che il budget di sicurezza effettivo (cioè il valore totale che garantisce il consenso) è di < 1M USD.
A questi livelli, è finanziariamente sostenibile per un attore malevolo compromettere il consenso, censurare le transazioni di ancoraggio o riscrivere la storia.
Per una piattaforma come EQTY — che ancorano registrazioni di asset legalmente vincolanti — questo è inaccettabile.
2. Centralizzazione dei validatori e bassi incentivi
I nodi della comunità non sono più economicamente sostenibili.
I nodi che concludono il servizio potrebbero portare a un piccolo gruppo di nodi che detiene un controllo sproporzionato sul consenso.
Questo mina le garanzie di decentralizzazione che l'ancoraggio è destinato a fornire.
3. Attrito di adozione
È sempre più difficile giustificare LTO come un layer di ancoraggio sicuro nelle vendite o nelle conversazioni di audit.
Clienti e partner si aspettano che EQTY ancorino su reti pubbliche ampiamente adottate e credibili (ad es. Ethereum, Base).
La percezione di “ancorare a un Layer 1 da 5 milioni di dollari” indebolisce la fiducia nell'infrastruttura centrale di EQTY.
4. Fragilità dell'infrastruttura
Se anche solo pochi validatori chiave vanno offline, LTO diventa instabile o si ferma completamente.
La manutenzione continua (esploratori, indicizzatori, infrastruttura dei nodi) aggiunge overhead con valore decrescente.
Perché Base è il layer di ancoraggio giusto
Base offre:
Compatibilità totale con EVM
Sicurezza economica e tecnica ereditata da Ethereum
Ampio supporto per gli strumenti (MetaMask, WalletConnect, The Graph, ecc.)
Commissioni quasi nulle con finalità rapida
Allineamento stretto con il layer di asset e liquidità di EQTY, che vive anche su Base
L'ancoraggio a Base rimuove l'onere di mantenere un Layer 1 personalizzato aumentando auditabilità, composabilità e fiducia.
Motivazione strategica
Il valore di EQTY non è nel consenso: è nel suo layer privato, modello di asset e architettura di conformità.
Mantenere un Layer 1 offre poco vantaggio strategico a un costo elevato.
Passare a Base consente a EQTY di concentrarsi interamente sull'adozione del prodotto, sull'integrazione legale e sulla tokenizzazione degli asset, senza essere appesantito dall'infrastruttura di Layer 1.
2. Nuovo token $EQTY ERC-20
La piattaforma EQTY introdurrà un nuovo token ERC-20, $EQTY, distribuito sulla rete Base. Questo token sostituisce il token LTO e funge da valuta nativa per le operazioni del protocollo, inclusi ancoraggio e governance.
Il contratto del token inizia con una fornitura zero. $EQTY viene coniato su richiesta quando gli utenti scambiano i loro token LTO durante un periodo di migrazione limitato. Questa finestra è applicata on-chain: dopo un'altezza di blocco predefinita, la funzione di conia diventa permanentemente disabilitata. Qualsiasi token LTO non convertito prima di questo termine è escluso dall'ecosistema EQTY e la fornitura finale di $EQTY sarà inferiore alla fornitura originale di LTO.
Il contratto del token è deliberatamente minimale. Segue l'interfaccia standard ERC-20, senza logica di trasferimento speciale, funzioni di airdrop o piani di vesting.
Il token $EQTY sarà utilizzato per pagare le commissioni di ancoraggio, partecipare alla governance del protocollo e potenzialmente supportare ulteriori ruoli di utilità man mano che la piattaforma evolve. L'utilizzo richiede che i token vengano bruciati, riducendo l'offerta totale.
3. Contratto di ancoraggio su Base
L'ancoraggio sarà eseguito tramite un contratto intelligente leggero distribuito sulla rete Base. Questo contratto emette eventi che registrano pubblicamente l'hash delle catene di eventi o dei messaggi, senza memorizzare alcuno stato on-chain.
Ogni ancoraggio mappa una chiave a un valore, dove:
Per le catene di eventi: chiave = stateHash, valore = eventHash
Per i messaggi: chiave = messageHash, valore = 0x0
Interfaccia
struct Anchor {
bytes32 chiave;
valore bytes32;
}
function anchor(Anchor[] calldata anchors) external;
evento Ancorato(
bytes32 chiave indicizzata,
valore bytes32,
indirizzo mittente indicizzato,
uint64 timestamp
);
Comportamento
Il contratto emette un evento Ancorato per ogni coppia (chiave, valore).
L'attuale block.timestamp è incluso nell'evento come campo separato per comodità e auditabilità.
Nessuno stato è memorizzato nel contratto. Tutti i dati di ancoraggio sono registrati solo tramite log.
Il contratto è senza autorizzazione: chiunque può ancorare.
Questi eventi sono progettati per essere indicizzabili e accessibili da:
Componenti interni, come l'indicizzatore oBridge e la piattaforma EQTY
Servizi esterni, inclusi The Graph, Infura o verificatori personalizzati
Mantenendo l'ancoraggio senza stato e emettendo eventi completi, questo design garantisce che l'ancoraggio sia verificabile, efficiente e indipendente dall'infrastruttura.
Meccanismo delle commissioni
I clienti devono chiamare approve() sul contratto ERC20 per abilitare l'ancoraggio
Ogni ancoraggio comporta una bruciatura di $EQTY, applicata nella funzione anchor()
L'importo della commissione è letto da un contratto di configurazione controllato dalla governance separata
L'ancoraggio non utilizzerà approve() ma brucerà tramite eqtyToken.burnFrom(msg.sender, fee * n)
4. Governance delle commissioni
Per mantenere l'ancoraggio economicamente sostenibile e equo nel tempo, la commissione pagata in $EQTY per ancoraggio deve essere regolabile. Invece di codificare una commissione statica o fare affidamento su oracoli di prezzo, EQTY utilizzerà un modello di governance on-chain per controllare questo parametro in modo trasparente e decentralizzato.
Un contratto di configurazione dedicato memorizzerà la tariffa di ancoraggio attuale. Questo valore può essere aggiornato solo da un contratto di governance: specificamente, un'istanza del Governatore di OpenZeppelin legata al token $EQTY. I voti saranno espressi in base ai saldi di $EQTY utilizzando la logica standard ERC20Votes.
Il contratto di ancoraggio legge la tariffa attuale dal contratto di configurazione ogni volta che viene chiamato anchor(). Brucia quindi l'importo appropriato di $EQTY direttamente dal saldo del mittente. Questo approccio evita la necessità di transazioni approve() e garantisce che il contratto di ancoraggio rimanga leggero e senza stato oltre l'applicazione delle commissioni.
Il modello di governance consente alla comunità di regolare le commissioni nel tempo in risposta alle condizioni di mercato, alle fluttuazioni dei prezzi dei token o ai cambiamenti nella domanda di ancoraggio — senza fare affidamento su fonti di dati esterne o controllo centralizzato.
5. Nuova libreria del layer privato
Per supportare l'ancoraggio su Base e la firma nativa del portafoglio, verrà creata una nuova libreria TypeScript autonoma per gestire la logica del layer privato — inclusi catene di eventi, firma di eventi, ancoraggio e strutture di messaggio di relay. Questa libreria sostituisce la @ltonetwork/lto-api.js specifica di LTO per tutti i casi d'uso EQTY.
La nuova libreria è progettata per essere utilizzata sia in ambienti browser (ad es. MetaMask, WalletConnect) sia in strumenti server-side.
Ambito e contenuti
Solo i componenti rilevanti del layer privato LTO saranno inclusi:
events/ Include Event, EventChain, MergeConflict e logica di serializzazione correlata.
message/ Include Message e Relay, utilizzati per la comunicazione crittografata off-chain.
Codice di supporto Include classi di utilità come Binary.
La libreria non avrà dipendenze dalla Rete LTO:
Nessuna API dei nodi LTO
Nessuna logica di transazione
Nessuno strumento di generazione delle chiavi
Nessuna codifica degli indirizzi specifica di LTO
Supporterà l'ancoraggio tramite contratti intelligenti su Base e si integrerà perfettamente con ethers.js per la firma e l'invio di ancore.
Modello di firma degli eventi
Il metodo Event.signWith() sarà reso asincrono per supportare la firma basata su browser tramite MetaMask, WalletConnect o qualsiasi firmatario esterno, oltre a firmare direttamente con ethers. Utilizza un'interfaccia astratta ISigner:
interfaccia ISigner {
sign(data: Uint8Array): Promise<Uint8Array>;
}
L'evento firmato non richiede più una chiave pubblica; include solo la firma e l'indirizzo derivato. Questo lo rende compatibile con i flussi di firma Ethereum (personal_sign) e rimuove la necessità di estrarre chiavi pubbliche, il che non è possibile nella maggior parte degli ambienti di portafoglio.
Integrazione dell'ancoraggio
La libreria include un metodo per generare mappe di ancoraggio:
const anchors = chain.from(lastKnownEvent.hash).getAnchorMap();
Ogni ancoraggio mappa un stateHash (chiave) a un lastEventHash (valore), pronto per essere inviato al contratto intelligente Base. Per i messaggi di relay, l'hash del messaggio stesso viene utilizzato come chiave di ancoraggio, e il valore è impostato su zero (0x0).
L'ancoraggio può essere eseguito chiamando direttamente il contratto intelligente tramite ethers.Contract.anchor(Anchor[]). Questo evita la dipendenza da qualsiasi servizio backend o infrastruttura proprietaria.
Firma di messaggi
La libreria include anche classi Message e Relay per la comunicazione off-chain. Come gli eventi, i messaggi vengono firmati in modo asincrono utilizzando l'interfaccia ISigner. Le firme sono sull'hash del messaggio e non è inclusa alcuna chiave pubblica: viene utilizzato solo l'indirizzo derivato per la verifica.
Dopo la firma, l'hash del messaggio viene ancorato on-chain tramite lo stesso contratto Anchor. Il formato è:
chiave = messageHash
valore = 0x0
Questo assicura che i messaggi off-chain possano essere datati e verificati pubblicamente senza rivelare i loro contenuti. L'ancoraggio può essere effettuato dal mittente o dal servizio di relay.
Distribuzione e utilizzo
La libreria sarà pubblicata come un pacchetto NPM separato. È destinata a essere il core condiviso utilizzato da:
Il portafoglio EQTY (per la firma di eventi e messaggi)
Il servizio di relay (per il calcolo degli hash e il parsing dei messaggi)
L'SDK Ownables (per la costruzione e l'invio di eventi)
Qualsiasi frontend o verificatore di terze parti
6. Indicizzazione oBridge
Il servizio oBridge sostituirà la sua attuale logica di indicizzazione basata su LTO con un nuovo indicizzatore che elabora eventi Ancorati emessi dal contratto di ancoraggio Base.
Questo indicizzatore ascolta i log di ancoraggio su Base e mantiene un database locale dell'ancora più recente per chiave, che può rappresentare sia uno stato di catena di eventi che un hash di messaggio di relay. Ogni voce include:
chiave: lo stato ancorato o l'hash del messaggio
valore: l'hash dell'evento corrispondente o 0x0
txHash, blockNumber, logIndex e mittente
Questi registri sono esposti tramite una API HTTP pubblica. La struttura e il comportamento di questa API rimarranno compatibili con l'indicizzatore di ancoraggio LTO esistente, inclusi l'endpoint GET /hash/verify, consentendo ai componenti EQTY esistenti di transitare con minime modifiche.
L'indicizzatore oBridge svolge due ruoli:
Come dipendenza interna per il servizio di relay, che deve verificare che i messaggi siano stati ancorati prima di rilasciarli.
Come servizio di verifica pubblica per clienti e portafogli esterni che desiderano controllare lo stato di ancoraggio senza interrogare direttamente Base.
Tutti i dati rimangono verificabili on-chain, e i clienti possono bypassare oBridge se desiderato utilizzando eth_getLogs o il proprio indicizzatore.
7. Servizio Relay
Il servizio di relay gestisce la consegna sicura di messaggi crittografati tra le parti. Per garantire che i messaggi siano autentici, datati e controllati nell'accesso, il servizio verrà aggiornato per supportare sia la validazione del'ancoraggio on-chain che l'autenticazione moderna, nativa del portafoglio, utilizzando il Sign-In con Ethereum (SIWE).
Autenticazione dei messaggi con SIWE
Invece di fare affidamento sulle firme di messaggi HTTP o sfide personalizzate, il relay implementerà lo standard SIWE (EIP-4361). Questo approccio consente agli utenti di autenticarsi firmando un messaggio di testo standard con il proprio portafoglio Ethereum, producendo una firma recuperabile che li vincola a una sessione.
Flusso di accesso:
Il cliente richiede un messaggio SIWE dal backend del relay: GET /auth/siwe-message?address=0x...
Il server restituisce un messaggio SIWE standard che include:
Dominio (ad es. relay.eqty.network)
Nonce
Timestamp di scadenza
Campo risorse opzionale limitato a /messages?to=...
Dichiarazione: ad es. “Accedi per accedere ai tuoi messaggi EQTY.”
Il cliente firma il messaggio utilizzando personal_sign
Il cliente invia il messaggio firmato e la firma a POST /auth/verify
Il server verifica la firma e rilascia:
Un token di accesso JWT (a breve termine, ad es. 15 minuti)
Un token di aggiornamento (a lungo termine, ad es. 24 ore)
Tutte le richieste di recupero messaggi successive (GET /messages?to=...) devono includere il token di accesso nell'intestazione di autorizzazione.
Quando il token scade, il cliente può utilizzare il token di aggiornamento per ottenere un nuovo token di accesso senza dover ri-firmare.
Questo modello è pienamente compatibile con MetaMask, WalletConnect e altri portafogli EIP-1193, e segue schemi di sicurezza ampiamente adottati. Non è necessaria alcuna logica personalizzata o infrastruttura oltre le librerie SIWE esistenti.
Ancoraggio e verifica dei messaggi
Oltre all'autenticazione, il servizio di relay verificherà che ogni messaggio sia stato ancorato on-chain prima di consegnarlo. L'ancoraggio fornisce immutabilità, timestamping e previene attacchi di spam o replay.
Il relay mantiene il proprio indicizzatore leggero per il contratto di ancoraggio su Base. Ascolta gli eventi Ancorati e registra:
chiave = messageHash
valore = 0x0
mittente
blockNumber, txHash, timestamp
Per verificare un messaggio prima della consegna, il relay controlla che:
Esiste un evento Ancorato con chiave = messageHash
Il valore è esattamente 0x0 (cioè, non è un'ancora di catena di eventi)
Il mittente corrisponde al firmatario del messaggio (cioè, dall'indirizzo)
Solo dopo un ancoraggio riuscito, il messaggio viene rilasciato al destinatario. Questo garantisce che tutti i messaggi siano pubblicamente verificabili, datati su Base e ancorati dalla corretta identità.
Il relay esegue questa verifica utilizzando il proprio indicizzatore interno e non si basa su oBridge.
8. Modifiche al contratto Ownable (CosmWasm)
Con la migrazione da LTO Layer 1 e la deprecazione della firma degli eventi basata su chiave pubblica, i contratti Ownable devono essere aggiornati per supportare l'autorizzazione basata su indirizzo utilizzando indirizzi Ethereum standard.
Autorizzazione basata su indirizzo
In precedenza, la verifica della proprietà si basava sul recupero e sul confronto delle chiavi pubbliche estratte dagli eventi firmati. Poiché i portafogli Ethereum non espongono chiavi pubbliche e le firme ora utilizzano personal_sign (recuperabili a un indirizzo), il modello di verifica deve passare a confrontare direttamente gli indirizzi.
La logica contrattuale aggiornata utilizza info.sender — l'indirizzo che ha firmato e inviato l'evento — come identità autorevole.
Questo influisce su tutti i punti di accesso in cui è richiesta l'autorizzazione:
try_transfer: il mittente deve corrispondere all'indirizzo del proprietario attuale
try_release: il mittente deve corrispondere all'indirizzo del proprietario precedentemente bloccato
try_register_lock: verifica che il campo proprietario dell'evento corrisponda al firmatario
Invece di convertire le chiavi pubbliche in indirizzi LTO, il contratto memorizza semplicemente e confronta i valori Addr (ad es. 0xabc123...).
CAIP-2 e corrispondenza di rete
Il contratto continua a convalidare l'origine degli eventi cross-chain utilizzando l'identificatore di rete CAIP-2. Per i messaggi basati su Ethereum, lo spazio dei nomi è eip155:<chainId>. Il contratto verifica che:
L'evento.network corrisponde alla rete prevista
Il campo proprietario nell'evento corrisponde al firmatario (info.sender) sotto il dato spazio dei nomi CAIP
Le funzioni di conversione address_lto() e address_eip155() possono essere rimosse, poiché non è più necessaria alcuna traduzione verso o da indirizzi LTO.
Impatto
Questa modifica rende il contratto Ownable:
Pienamente compatibile con la firma e l'identità native di Ethereum
Indipendente dall'infrastruttura delle chiavi LTO
Compatibile con qualsiasi catena che supporti il recupero basato su indirizzo (ad es., EVM)
Gli Ownables esistenti, che si basano su firme e ancoraggi specifici di LTO, diventeranno non verificabili nel nuovo modello e devono essere riemessi (vedi Sezione 11).
9. Aggiornamento SDK Ownables
L'SDK Ownables deve essere aggiornato per riflettere il passaggio dalla firma della chiave pubblica basata su LTO all'autorizzazione basata su indirizzo in stile Ethereum e all'ancoraggio su Base.
Aggiornamenti chiave
Firma degli eventi
Aggiorna la creazione di eventi per utilizzare la nuova libreria del layer privato (@eqty-core/events)
Utilizzare implementazioni ISigner compatibili con MetaMask, WalletConnect o firmatari basati su ethers
Assicurati che signWith() non si basi più su una chiave pubblica; viene utilizzato solo l'indirizzo recuperabile
Ancoraggio
Sostituisci la logica di ancoraggio dei nodi LTO con l'invio di contratti intelligenti su Base
Utilizza getAnchorMap() per raccogliere coppie (chiave, valore) e inviarle tramite ethers.Contract.anchor()
Assicurati che l'ancoraggio dei messaggi utilizzi (chiave = messageHash, valore = 0x0)
Verifica
Aggiorna la logica di verifica per utilizzare l'API oBridge compatibile /hash/verify o una query di log diretta
Conferma che il valore dell'ancora corrisponda all'hash dell'evento previsto e che il mittente corrisponda all'indirizzo Ethereum del firmatario
Utilizzo degli indirizzi
Sostituire qualsiasi logica che confronta o genera indirizzi LTO
Utilizzare indirizzi Ethereum semplici (0x...) in tutto il flusso di eventi e messaggi
Compatibilità
L'SDK aggiornato rimane strutturalmente simile ma non è più legato alla libreria @ltonetwork/lto-api.js o ai servizi dei nodi LTO. È compatibile con la nuova libreria del layer privato e l'ancoraggio Base, e interagirà con i contratti Ownable aggiornati e il servizio di relay.
10. Aggiornamento del Portafoglio Universale
Il portafoglio universale deve essere aggiornato per riflettere la migrazione a Base e la nuova architettura EQTY. Non interagisce più con i nodi LTO.
Aggiornamenti core
Connessione del portafoglio
Sostituisci la gestione delle coppie di chiavi LTO con una libreria compatibile con Ethereum (ethers.js)
Utilizza interfacce del provider EIP-1193 per abilitare la firma e il recupero degli indirizzi
Supporto per i token
Aggiungi supporto per visualizzare e gestire i saldi del nuovo token $EQTY ERC-20 su Base
Inclusi metadati dei token, cronologia e tracciamento dei saldi tramite endpoint RPC pubblici
Firma di eventi e messaggi
Integra la nuova libreria del layer privato per consentire agli utenti di creare e firmare catene di eventi e messaggi
Utilizza personal_sign tramite il portafoglio connesso; le chiavi pubbliche non sono più richieste
Ancoraggio
Invia le mappe di ancoraggio direttamente al contratto di ancoraggio Base utilizzando ethers.js
Gestisci l'invio on-chain, la conferma e il feedback UI opzionale per il costo di ancoraggio in $EQTY
Integrazione del relay
Autenticati tramite SIWE (Sign-In with Ethereum)
Memorizza e aggiorna i token di accesso secondo necessità
Utilizza richieste autenticate per recuperare messaggi crittografati dal servizio di relay
Funzionalità rimosse
Interfaccia utente di leasing LTO
Selezione nodo e vista catena
Gestione dell'identità on-chain legata a LTO
11. Piano di migrazione
Con la deprecazione di LTO Layer 1 e l'introduzione di un nuovo sistema di ancoraggio su Base, tutti i componenti core del protocollo devono migrare. I dati legacy legati all'infrastruttura LTO — inclusi ancore, catene di eventi e messaggi — non saranno più validi.
Cosa diventa non valido
Le catene di eventi firmate utilizzando coppie di chiavi LTO non possono essere verificate, poiché la chiave pubblica non è più estraibile dalle firme basate su Ethereum.
Le ancore registrate su LTO L1 non possono essere fidate o interrogate in seguito.
I proprietari legati a identità basate su LTO o catene ancorate devono essere sostituiti.
I messaggi non ancorati su Base saranno rifiutati dal servizio di relay.
Azioni richieste
Migrazione dei tokenGli utenti devono scambiare manualmente i loro token LTO per $EQTY utilizzando il bridge. Il conio è possibile solo fino a un'altezza di blocco specifica su Base. Dopo questo blocco, il bridge verrà chiuso e la funzione di conia disabilitata permanentemente. I token LTO non scambiati diventano privi di valore.
Riemissione dell'asset Ownables.I soggetti emittenti devono emettere nuovi ownables legati alla rete BASE. Seguiranno istruzioni su come scambiare i legacy Ownables con i nuovi Ownables
Transizione del portafoglio Gli utenti dovranno aggiornare il Portafoglio Universale.
Nessuno snapshot
Non ci sarà alcuno snapshot, migrazione automatica o layer di compatibilità retroattiva. Ogni componente (eventi, messaggi, saldi dei token) deve essere ristabilito su Base attraverso le interfacce appropriate. Il nuovo protocollo è pulito per design e non conserva legami con LTO L1.