1. Einführung & Motivation

Hintergrund

Die EQTY-Plattform basiert auf einer Dual-Layer-Architektur:

  • Eine private Schicht zur Verwaltung verifizierbarer Ereignisketten (z.B. Ownables, Nachrichten)

  • Eine öffentliche Anker-Schicht, um diese Ereignisketten auf einer unveränderlichen Blockchain zu zeitstempeln und zu verifizieren

Historisch gesehen wurde diese öffentliche Schicht von LTO Network Layer 1 bereitgestellt, einer dedizierten Proof-of-Stake-Blockchain, die für das Ankern optimiert ist.

Der Betriebsrahmen hat sich jedoch erheblich geändert.

Warum LTO Layer 1 veraltet sein muss

1. Ökonomische Sicherheit ist zusammengebrochen

  • LTO hat derzeit eine Marktkapitalisierung von unter 5 Millionen US-Dollar, wobei nur ~20% der Tokens gestaked sind.

  • Das bedeutet, dass das effektive Sicherheitsbudget (d.h. der Gesamtwert, der den Konsens sichert) bei 1 Million US-Dollar liegt.

  • Auf diesen Ebenen ist es für einen böswilligen Akteur finanziell rentabel, den Konsens zu gefährden, Ankertransaktionen zu zensieren oder die Geschichte umzuschreiben.

  • Für eine Plattform wie EQTY – die rechtlich durchsetzbare Vermögensunterlagen ankerte – ist dies inakzeptabel.

2. Zentralisierung der Validatoren und niedrige Anreize

  • Gemeinschaftsknoten sind nicht mehr wirtschaftlich tragfähig.

  • Das Ende des Dienstes durch Knoten könnte dazu führen, dass eine kleine Menge von Knoten überproportionale Kontrolle über den Konsens hat.

  • Dies untergräbt die Dezentralisierungsversprechen, die das Ankern bieten soll.

3. Adoptionsfriktion

  • Es wird immer schwieriger, LTO als sichere Anker-Schicht in Verkaufs- oder Prüfgesprächen zu rechtfertigen.

  • Kunden und Partner erwarten, dass EQTY auf weit verbreiteten und glaubwürdigen öffentlichen Netzwerken (z.B. Ethereum, Base) ankerte.

  • Die Wahrnehmung, dass „an eine 5-Millionen-Dollar-Layer-1 angedockt wird“, schwächt das Vertrauen in die Kerneinfrastruktur von EQTY.

4. Infrastrukturfragilität

  • Wenn sogar einige wichtige Validatoren offline gehen, wird LTO instabil oder stoppt vollständig.

  • Die fortgesetzte Wartung (Explorer, Indexer, Knoten-Infrastruktur) führt zu Überhead mit abnehmendem Wert.

Warum Base die richtige Anker-Schicht ist

Base bietet:

  • Vollständige EVM-Kompatibilität

  • Ökonomische und technische Sicherheit, die von Ethereum geerbt wurde

  • Umfassende Unterstützung von Werkzeugen (MetaMask, WalletConnect, The Graph usw.)

  • Nahezu keine Gebühren mit schneller Finalität

  • Enger Zusammenhang mit der Vermögens- und Liquiditätsschicht von EQTY, die ebenfalls auf Base lebt

Das Ankern auf Base beseitigt die Last, eine benutzerdefinierte Layer 1 zu warten, während es die Prüfbarkeit, Zusammensetzung und das Vertrauen erhöht.

Strategische Motivation

  • Der Wert von EQTY liegt nicht im Konsens – er liegt in seiner privaten Schicht, seinem Vermögensmodell und seiner Compliance-Architektur.

  • Die Aufrechterhaltung einer Layer 1 bietet bei hohen Kosten wenig strategischen Vorteil.

  • Der Umzug zu Base ermöglicht es EQTY, sich vollständig auf Produktadoption, rechtliche Integration und Vermögens-Tokenisierung zu konzentrieren, ohne durch die Layer 1-Infrastruktur belastet zu werden.

2. Neuer $EQTY ERC-20 Token

Die EQTY-Plattform wird einen neuen ERC-20-Token, $EQTY, einführen, der im Base-Netzwerk eingesetzt wird. Dieser Token ersetzt den LTO-Token und dient als die native Währung für Protokolloperationen, einschließlich Ankern und Governance.

Der Token-Vertrag beginnt mit null Versorgung. $EQTY wird bei Bedarf gemintet, wenn Benutzer ihre LTO-Token während eines begrenzten Migrationszeitraums tauschen. Dieses Zeitfenster wird On-Chain durchgesetzt: Nach einer vordefinierten Blockhöhe wird die Mint-Funktion dauerhaft deaktiviert. Alle LTO-Token, die vor diesem Stichtag nicht konvertiert wurden, sind vom EQTY-Ökosystem ausgeschlossen, und die endgültige $EQTY-Versorgung wird niedriger sein als die ursprüngliche LTO-Versorgung.

Der Token-Vertrag ist absichtlich minimal. Er folgt der Standard-ERC-20-Schnittstelle, ohne spezielle Übertragungslogik, Airdrop-Funktionen oder Vesting-Pläne.

Der $EQTY-Token wird verwendet, um Ankergebühren zu zahlen, an der Protokollgovernance teilzunehmen und möglicherweise zusätzliche Utility-Rollen zu unterstützen, während sich die Plattform weiterentwickelt. Nutzen erfordert, dass Tokens verbrannt werden, wodurch das Gesamtangebot verringert wird.

3. Ankervertrag auf Base

Das Ankern erfolgt über einen leichtgewichtigen Smart Contract, der im Base-Netzwerk bereitgestellt wird. Dieser Vertrag gibt Ereignisse aus, die den Hash von Ereignisketten oder Nachrichten öffentlich aufzeichnen, ohne einen On-Chain-Zustand zu speichern.

Jeder Anker mappt einen Schlüssel zu einem Wert, wobei:

  • Für Ereignisketten: Schlüssel = stateHash, Wert = eventHash

  • Für Nachrichten: Schlüssel = messageHash, Wert = 0x0

Schnittstelle

struct Anchor {

bytes32 Schlüssel;

bytes32 Wert;

}

function anchor(Anchor[] calldata anchors) external;

Ereignis Angeschnallt(

bytes32 indexierter Schlüssel,

bytes32 Wert,

Adresse indexierter Absender,

uint64 Zeitstempel

);

Verhalten

  • Der Vertrag emittiert ein Anchored-Ereignis pro (key, value)-Paar.

  • Der aktuelle block.timestamp wird als separates Feld für Bequemlichkeit und Prüfspur in dem Ereignis enthalten.

  • Es wird kein Zustand im Vertrag gespeichert. Alle Ankerdaten werden ausschließlich über Protokolle aufgezeichnet.

  • Der Vertrag ist genehmigungsfrei – jeder kann anknüpfen.

Diese Ereignisse sind so konzipiert, dass sie indexierbar und zugänglich sind durch:

  • Interne Komponenten, wie den oBridge-Indexer und die EQTY-Plattform

  • Externe Dienste, einschließlich The Graph, Infura oder benutzerdefinierte Verifier

Durch die Beibehaltung des Ankers ohne Zustand und das Ausgeben vollständiger Ereignisse stellt dieses Design sicher, dass das Ankern überprüfbar, effizient und infrastrukturenunabhängig ist.

Gebührenmechanismus

  • Die Clients müssen approve() auf dem ERC20-Vertrag aufrufen, um das Ankern zu ermöglichen

  • Jeder Anker verursacht ein Brennen von $EQTY, das in der Funktion anchor() durchgesetzt wird

  • Die Gebührenhöhe wird aus einem separaten, governance-gesteuerten Konfigurationsvertrag gelesen

  • Das Ankern wird approve() nicht verwenden, sondern stattdessen über eqtyToken.burnFrom(msg.sender, fee * n) verbrennen

4. Gebühren-Governance

Um das Ankern wirtschaftlich nachhaltig und fair zu halten, muss die in $EQTY pro Anker gezahlte Gebühr anpassbar sein. Anstatt eine statische Gebühr hart zu kodieren oder sich auf Preisorakel zu verlassen, wird EQTY ein On-Chain-Governance-Modell verwenden, um diesen Parameter transparent und dezentral zu steuern.

Ein spezieller Konfigurationsvertrag speichert die aktuelle Ankergebühr. Dieser Wert kann nur von einem Governance-Vertrag aktualisiert werden – konkret von einer Instanz von OpenZeppelin’s Governor, die an den $EQTY-Token gebunden ist. Stimmen werden basierend auf $EQTY-Beständen mit der Standard-ERC20Votes-Logik abgegeben.

Der Ankervertrag liest die aktuelle Gebühr jedes Mal, wenn anchor() aufgerufen wird, aus dem Konfigurationsvertrag. Dann verbrennt er den entsprechenden Betrag von $EQTY direkt aus dem Guthaben des Absenders. Dieser Ansatz vermeidet die Notwendigkeit von approve()-Transaktionen und stellt sicher, dass der Ankervertrag leichtgewichtig und zustandslos bleibt, abgesehen von der Gebührendurchsetzung.

Das Governance-Modell ermöglicht es der Gemeinschaft, die Gebühren im Laufe der Zeit als Reaktion auf Marktbedingungen, Tokenpreisänderungen oder Änderungen in der Anker-Nachfrage anzupassen – ohne sich auf externe Datenquellen oder zentralisierte Kontrolle zu verlassen.

5. Neue private Schichtbibliothek

Um das Ankern auf Base und wallet-native Signatur zu unterstützen, wird eine neue eigenständige TypeScript-Bibliothek erstellt, die die Logik der privaten Schicht behandelt - einschließlich Ereignisketten, Ereignisunterzeichnung, Ankern und Relay-Nachrichtenstrukturen. Diese Bibliothek ersetzt die LTO-spezifische @ltonetwork/lto-api.js für alle EQTY-Anwendungsfälle.

Die neue Bibliothek ist so konzipiert, dass sie sowohl in Browserumgebungen (z.B. MetaMask, WalletConnect) als auch in serverseitigen Tools verwendet werden kann.

Umfang und Inhalte

Nur die relevanten Komponenten der LTO-Privatschicht werden einbezogen:

  • events/ Beinhaltet Ereignis, Ereigniskette, MergeConflict und verwandte Serialisierungslogik.

  • message/ Beinhaltet Nachricht und Relay, verwendet für verschlüsselte Off-Chain-Kommunikation.

  • Unterstützender Code Beinhaltet Dienstprogrammklauseln wie Binary.

Die Bibliothek hat keine Abhängigkeit von LTO Network:

  • Kein LTO-Knoten-API

  • Keine Transaktionslogik

  • Keine Schlüsselpaargenerierungswerkzeuge

  • Keine LTO-spezifische Adresskodierung

Es wird das Ankern über Smart Contracts auf Base unterstützen und sich sauber mit ethers.js für das Signieren und Einreichen von Ankern integrieren.

Modell zur Ereignisunterzeichnung

Die Methode Event.signWith() wird asynchron gestaltet, um browserbasiertes Signieren über MetaMask, WalletConnect oder einen externen Unterzeichner zu unterstützen, zusätzlich zum direkten Signieren mit ethers. Es verwendet eine abstrakte ISigner-Schnittstelle:

Schnittstelle ISigner {

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

}

Das signierte Ereignis erfordert keinen öffentlichen Schlüssel mehr; es enthält nur die Signatur und die abgeleitete Adresse. Dies macht es kompatibel mit Ethereum-Signierungsflüssen (personal_sign) und entfernt die Notwendigkeit, öffentliche Schlüssel zu extrahieren, was in den meisten Wallet-Umgebungen nicht möglich ist.

Ankerintegration

Die Bibliothek enthält eine Methode zur Erstellung von Ankerkarten:

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

Jeder Anker mappt einen stateHash (Schlüssel) auf einen lastEventHash (Wert), bereit zur Einreichung beim Basis-Smart-Contract. Für Relay-Nachrichten wird der Nachrichtenhash selbst als Anker-Schlüssel verwendet, und der Wert wird auf null (0x0) gesetzt.

Das Ankern kann erfolgen, indem der Smart Contract direkt über ethers.Contract.anchor(Anchor[]). aufgerufen wird. Dies vermeidet die Abhängigkeit von einem Backend-Dienst oder proprietärer Infrastruktur.

Nachrichtenunterzeichnung

Die Bibliothek enthält auch Nachrichten- und Relay-Klassen für die Off-Chain-Kommunikation. Wie Ereignisse werden Nachrichten asynchron mithilfe der ISigner-Schnittstelle signiert. Signaturen beziehen sich auf den Nachrichtenhash, und kein öffentlicher Schlüssel ist enthalten – nur die abgeleitete Adresse wird zur Verifizierung verwendet.

Nach der Unterzeichnung wird der Nachrichtenhash über denselben Ankervertrag On-Chain verankert. Das Format ist:

  • key = messageHash

  • value = 0x0

Dies stellt sicher, dass Off-Chain-Nachrichten öffentlich zeitgestempelt und verifiziert werden können, ohne deren Inhalte offenzulegen. Das Ankern kann vom Absender oder vom Relay-Dienst durchgeführt werden.

Bereitstellung und Nutzung

Die Bibliothek wird als separates NPM-Paket veröffentlicht. Sie soll der gemeinsame Kern sein, der von:

  • Die EQTY-Brieftasche (für Ereignis- und Nachrichtenunterzeichnung)

  • Der Relay-Dienst (für Hash-Berechnung und Nachrichtenanalyse)

  • Das Ownables SDK (für Ereigniskonstruktion und -einreichung)

  • Jede Drittanbieter-Frontend oder Verifier

6. oBridge-Indexierung

Der oBridge-Dienst wird seine aktuelle LTO-basierte Indexierungslogik durch einen neuen Indexer ersetzen, der Angeschnallt-Ereignisse verarbeitet, die vom Basis-Ankervertrag ausgegeben werden.

Dieser Indexer hört auf Ankerprotokolle auf Base und pflegt eine lokale Datenbank des letzten Ankers pro Schlüssel, die entweder einen Zustand einer Ereigniskette oder einen Relay-Nachrichtenhash darstellen kann. Jeder Eintrag umfasst:

  • key: der verankerte Zustand oder Nachrichtenhash

  • value: der entsprechende Ereignishash oder 0x0

  • txHash, blockNumber, logIndex und Absender

Diese Aufzeichnungen werden über eine öffentliche HTTP-API bereitgestellt. Die Struktur und das Verhalten dieser API bleiben mit dem bestehenden LTO-Anker-Indexer kompatibel, einschließlich des Endpunkts GET /hash/verify, was den bestehenden EQTY-Komponenten ermöglicht, mit minimalen Änderungen zu übergehen.

Der oBridge-Indexer erfüllt zwei Rollen:

  1. Als interne Abhängigkeit für den Relay-Dienst, der überprüfen muss, dass Nachrichten verankert wurden, bevor sie freigegeben werden.

  2. Als öffentlicher Verifizierungsdienst für externe Kunden und Brieftaschen, die den Ankerstatus überprüfen möchten, ohne Base direkt abzufragen.

Alle Daten bleiben On-Chain überprüfbar, und die Clients können oBridge umgehen, wenn sie dies wünschen, indem sie eth_getLogs oder ihren eigenen Indexer verwenden.

7. Relay-Dienst

Der Relay-Dienst sorgt für die sichere Zustellung verschlüsselter Nachrichten zwischen den Parteien. Um sicherzustellen, dass Nachrichten authentisch, zeitgestempelt und zugriffskontrolliert sind, wird der Dienst aktualisiert, um sowohl die On-Chain-Ankervalidierung als auch die moderne, wallet-native Authentifizierung über Sign-In mit Ethereum (SIWE) zu unterstützen.

Nachrichtenauthentifizierung mit SIWE

Anstelle der Abhängigkeit von HTTP-Nachrichtensignaturen oder benutzerdefinierten Herausforderungen wird der Relay-Dienst den SIWE-Standard (EIP-4361) implementieren. Dieser Ansatz ermöglicht es den Benutzern, sich zu authentifizieren, indem sie eine standardmäßige Textnachricht mit ihrer Ethereum-Wallet signieren, wodurch eine wiederherstellbare Signatur erzeugt wird, die sie an eine Sitzung bindet.

Login-Flow:

  1. Der Client fordert eine SIWE-Nachricht vom Relay-Backend an: GET /auth/siwe-message?address=0x...

  2. Der Server gibt eine standardmäßige SIWE-Nachricht zurück, die Folgendes enthält:

  • Domäne (z.B. relay.eqty.network)

  • Nonce

  • Ablauf-Zeitstempel

  • Optionales Ressourcenfeld beschränkt auf /messages?to=...

  • Erklärung: z.B. „Melden Sie sich an, um auf Ihre EQTY-Nachrichten zuzugreifen.“

  1. Der Client signiert die Nachricht mit personal_sign

  2. Der Client übermittelt die signierte Nachricht und die Signatur an POST /auth/verify

  3. Der Server überprüft die Signatur und gibt aus:

  • Ein JWT-Zugriffstoken (kurzlebig, z.B. 15 Minuten)

  • Ein Refresh-Token (längerlebig, z.B. 24 Stunden)

Alle nachfolgenden Anfragen zum Abrufen von Nachrichten (GET /messages?to=...) müssen das Zugriffstoken im Authorization-Header enthalten.

Wenn der Token abläuft, kann der Client das Refresh-Token verwenden, um ein neues Zugriffstoken zu erhalten, ohne erneut zu signieren.

Dieses Modell ist vollständig kompatibel mit MetaMask, WalletConnect und anderen EIP-1193-Wallets und folgt weithin akzeptierten Sicherheitsmustern. Es sind keine benutzerdefinierten Logik oder Infrastruktur über vorhandene SIWE-Bibliotheken hinaus erforderlich.

Nachrichtenankern und -verifizierung

Neben der Authentifizierung wird der Relay-Dienst validieren, dass jede Nachricht On-Chain verankert wurde, bevor sie zugestellt wird. Ankern bietet Unveränderlichkeit, Zeitstempelung und verhindert Spam- oder Replay-Angriffe.

Der Relay-Dienst verwaltet seinen eigenen leichtgewichtigen Indexer für den Ankervertrag auf Base. Er hört auf Anchored-Ereignisse und zeichnet auf:

  • key = messageHash

  • value = 0x0

  • Absender

  • blockNumber, txHash, timestamp

Um eine Nachricht vor der Zustellung zu verifizieren, überprüft der Relay, dass:

  • Ein Angeschnallt-Ereignis existiert mit Schlüssel = messageHash

  • Der Wert ist genau 0x0 (d.h. kein Ereigniskettenanker)

  • Der Absender entspricht dem Unterzeichner der Nachricht (d.h. von Adresse)

Nur nach erfolgreichem Ankern wird die Nachricht an den Empfänger freigegeben. Dies stellt sicher, dass alle Nachrichten öffentlich überprüfbar, zeitgestempelt auf Base und von der richtigen Identität verankert sind.

Der Relay-Dienst führt diese Überprüfung mithilfe seines eigenen internen Indexers durch und verlässt sich nicht auf oBridge.

8. Änderungen am Ownable-Vertrag (CosmWasm)

Mit der Migration weg von LTO Layer 1 und der Ablösung der öffentlichen Schlüssel-basierten Ereignisunterzeichnung müssen die Ownable-Verträge aktualisiert werden, um adressenbasierte Autorisierung mithilfe standardmäßiger Ethereum-Adressen zu unterstützen.

Adressenbasierte Autorisierung

Früher basierte die Eigentumsverifizierung auf der Wiederherstellung und dem Vergleich von öffentlichen Schlüsseln, die aus signierten Ereignissen extrahiert wurden. Da Ethereum-Wallets keine öffentlichen Schlüssel offenlegen und Signaturen jetzt personal_sign verwenden (wiederherstellbar zu einer Adresse), muss das Verifizierungsmodell auf den direkten Vergleich von Adressen umschalten.

Die aktualisierte Vertragslogik verwendet info.sender – die Adresse, die das Ereignis unterzeichnet und eingereicht hat – als autoritative Identität.

Dies betrifft alle Einstiegspunkte, bei denen eine Autorisierung erforderlich ist:

  • try_transfer: der Absender muss mit der aktuellen Eigentümeradresse übereinstimmen

  • try_release: der Absender muss mit der vorherigen gesperrten Eigentümeradresse übereinstimmen

  • try_register_lock: überprüft, ob das Eigentümerfeld des Ereignisses mit dem Unterzeichner übereinstimmt

Anstatt öffentliche Schlüssel in LTO-Adressen zu konvertieren, speichert der Vertrag einfach Addr-Werte (z.B. 0xabc123...) und vergleicht diese.

CAIP-2 und Netzwerkabgleich

Der Vertrag validiert weiterhin den Ursprung von Cross-Chain-Ereignissen mithilfe der CAIP-2-Netzwerkkennung. Bei Ethereum-basierten Nachrichten ist der Namensraum eip155:<chainId>. Der Vertrag überprüft, dass:

  • Das event.network entspricht dem erwarteten Netzwerk

  • Das Eigentümerfeld im Ereignis entspricht dem Unterzeichner (info.sender) unter dem gegebenen CAIP-Namensraum

Die Konvertierungsfunktionen address_lto() und address_eip155() können entfernt werden, da keine Übersetzung zu oder von LTO-Adressen mehr erforderlich ist.

Auswirkungen

Diese Änderung macht den Ownable-Vertrag:

  • Vollständig kompatibel mit Ethereum-nativer Signierung und Identität

  • Unabhängig von der LTO-Schlüssel-Infrastruktur

  • Kompatibel mit jeder Kette, die adressenbasierte Wiederherstellung unterstützt (z.B. EVM)

Vorhandene Ownables, die auf LTO-spezifischen Signierungen und Ankern beruhen, werden unter dem neuen Modell unverifizierbar und müssen neu ausgestellt werden (siehe Abschnitt 11).

9. Aktualisierung des Ownables SDK

Das Ownables SDK muss aktualisiert werden, um den Übergang von LTO-basierten öffentlichen Schlüsselsignaturen zu Ethereum-ähnlicher adressenbasierter Autorisierung und Base-Anker zu reflektieren.

Wichtige Aktualisierungen

  1. Ereignisunterschrift

  • Aktualisieren Sie die Ereigniserstellung, um die neue private Schichtbibliothek (@eqty-core/events) zu verwenden

  • Verwenden Sie ISigner-Implementierungen, die mit MetaMask, WalletConnect oder ethers-basierten Signierern kompatibel sind

  • Stellen Sie sicher, dass signWith() nicht mehr von einem öffentlichen Schlüssel abhängt; nur die wiederherstellbare Adresse wird verwendet

  1. Ankern

  • Ersetzen Sie die LTO-Knoten-Ankerlogik durch die Einreichung von Smart Contracts auf Base

  • Verwenden Sie getAnchorMap(), um (Schlüssel, Wert)-Paare zu sammeln und sie über ethers.Contract.anchor() einzureichen

  • Stellen Sie sicher, dass das Nachrichtenankern (Schlüssel = messageHash, Wert = 0x0) verwendet

  1. Verifizierung

  • Aktualisieren Sie die Verifizierungslogik, um die oBridge-kompatible /hash/verify-API oder eine direkte Protokollabfrage zu verwenden

  • Bestätigen Sie, dass der Ankerwert mit dem erwarteten Ereignishash übereinstimmt und dass der Absender mit der Ethereum-Adresse des Unterzeichners übereinstimmt

  1. Adressenverwendung

  • Ersetzen Sie jede Logik, die LTO-Adressen vergleicht oder generiert

  • Verwenden Sie durchgängige Ethereum-Adressen (0x...) in Ereignis- und Nachrichtenflüssen

Kompatibilität

Das aktualisierte SDK bleibt strukturell ähnlich, ist jedoch nicht mehr an die @ltonetwork/lto-api.js-Bibliothek oder LTO-Knotendienste gebunden. Es ist kompatibel mit der neuen privaten Schichtbibliothek und dem Basis-Ankern und wird mit den aktualisierten Ownable-Verträgen und dem Relay-Dienst interoperabel sein.

10. Aktualisierung der universellen Brieftasche

Die universelle Brieftasche muss aktualisiert werden, um den Übergang zu Base und die neue EQTY-Architektur zu reflektieren. Sie interagiert nicht mehr mit LTO-Knoten.

Kernaktualisierungen

  1. Wallet-Verbindung

  • Ersetzen Sie die LTO-Schlüsselpaarverwaltung durch eine Ethereum-kompatible Bibliothek (ethers.js)

  • Verwenden Sie EIP-1193-Anbieter-Schnittstellen, um Signieren und Adressabfragen zu ermöglichen

  1. Token-Unterstützung

  • Fügen Sie Unterstützung hinzu, um die Salden des neuen $EQTY ERC-20 Tokens auf Base anzuzeigen und zu verwalten

  • Fügen Sie Token-Metadaten, Historie und Saldenverfolgung über öffentliche RPC-Endpunkte hinzu

  1. Ereignis- und Nachrichtenunterzeichnung

  • Integrieren Sie die neue private Schichtbibliothek, um Benutzern zu ermöglichen, Ereignisketten und Nachrichten zu erstellen und zu signieren

  • Verwenden Sie personal_sign über die verbundene Brieftasche; öffentliche Schlüssel sind nicht mehr erforderlich

  1. Ankern

  • Reichen Sie Ankerkarten direkt beim Basisanker-Vertrag unter Verwendung von ethers.js ein

  • Verwalten Sie die On-Chain-Einreichung, Bestätigung und optionales UI-Feedback für die Ankerkosten in $EQTY

  1. Relay-Integration

  • Authentifizieren Sie sich über SIWE (Sign-In mit Ethereum)

  • Speichern und aktualisieren Sie Zugriffstoken nach Bedarf

  • Verwenden Sie authentifizierte Anfragen, um verschlüsselte Nachrichten vom Relay-Dienst abzurufen

Entfernte Funktionen

  • LTO-Leasing-UI

  • Knotenauswahl und Kettenansicht

  • On-Chain-Identitätsverwaltung, die an LTO gebunden ist

11. Migrationsplan

Mit der Ablösung von LTO Layer 1 und der Einführung eines neuen Ankersystems auf Base müssen alle Kernkomponenten des Protokolls migrieren. Veraltete Daten, die an die LTO-Infrastruktur gebunden sind – einschließlich Anker, Ereignisketten und Nachrichten – werden ungültig sein.

Was ungültig wird

  • Ereignisketten, die mit LTO-Schlüsselpaaren unterzeichnet sind, können nicht verifiziert werden, da der öffentliche Schlüssel nicht mehr aus Ethereum-basierten Signaturen extrahiert werden kann.

  • Anker, die auf LTO L1 aufgezeichnet wurden, können künftig nicht mehr vertraut oder abgefragt werden.

  • Eigentümer, die an LTO-basierten Identitäten oder verankerten Ketten gebunden sind, müssen ersetzt werden.

  • Nachrichten, die nicht auf Base verankert sind, werden vom Relay-Dienst abgelehnt.

Erforderliche Maßnahmen

  1. Token-MigrationDie Benutzer müssen ihre LTO-Token manuell gegen $EQTY über die Brücke eintauschen. Minting ist nur bis zu einer bestimmten Blockhöhe auf Base möglich. Nach diesem Block wird die Brücke abgeschaltet und die Mint-Funktion dauerhaft deaktiviert. Nicht getauschte LTO-Token werden wertlos.

  2. Eigenes Ownables-Vermögen erneut ausgeben.Herausgeber von Ownables müssen neue Ownables ausgeben, die an das BASE-Netzwerk gebunden sind. Anleitungen werden folgen, wie man alte Ownables gegen neue Ownables eintauscht

  3. Wallet-Übergang Benutzer müssen die universelle Brieftasche aktualisieren.

Kein Snapshot

Es wird kein Snapshot, keine automatische Migration oder Kompatibilitätsschicht geben. Jede Komponente (Ereignisse, Nachrichten, Token-Bestände) muss auf Base über die entsprechenden Schnittstellen wiederhergestellt werden. Das neue Protokoll ist aus designtechnischen Gründen sauber und bewahrt keine Verbindungen zu LTO L1.

#ETH