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 Verankerungsschicht zur Zeitstempelung und Verifizierung dieser Ereignisketten auf einer unveränderlichen Blockchain

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

Der Betriebskontext hat sich jedoch erheblich geändert.

Warum LTO Layer 1 abgewertet werden muss

1. Wirtschaftliche Sicherheit ist zusammengebrochen

  • LTO hat derzeit eine Marktkapitalisierung von unter 5 Millionen Dollar, mit nur ~20% der Token, die gestakt sind.

  • Das bedeutet, dass das effektive Sicherheitsbudget (d.h. der gesamte Wert, der den Konsens sichert) bei etwa 1 Million Dollar liegt.

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

  • Für eine Plattform wie EQTY - die rechtlich durchsetzbare Vermögensaufzeichnungen verankert - ist dies inakzeptabel.

2. Zentralisierung von Validatoren und geringe Anreize

  • Gemeinschaftsknoten sind wirtschaftlich nicht mehr tragfähig.

  • Das Ende des Dienstes von Knoten könnte dazu führen, dass eine kleine Gruppe von Knoten übermäßige Kontrolle über den Konsens hat.

  • Dies untergräbt die Dezentralisierungszusicherungen, die die Verankerung bieten soll.

3. Adoptionsfriktionen

  • Es wird zunehmend schwieriger zu rechtfertigen, dass LTO eine sichere Verankerungsschicht in Verkaufs- oder Prüfgesprächen ist.

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

  • Die Wahrnehmung von "Verankerung an einem Layer-1 von 5 Millionen Dollar" schwächt das Vertrauen in die Kerninfrastruktur von EQTY.

4. Infrastrukturfragilität

  • Wenn auch nur einige Schlüsselvalidatoren offline gehen, wird LTO instabil oder stoppt vollständig.

  • Die fortgesetzte Wartung (Explorer, Indexer, Knoten-Infrastruktur) verursacht Überkopfkosten mit abnehmendem Wert.

Warum Base die richtige Verankerungsschicht ist

Base bietet:

  • Vollständige EVM-Kompatibilität

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

  • Breite Werkzeugunterstützung (MetaMask, WalletConnect, The Graph usw.)

  • Nahezu null Gebühren bei schneller Finalität

  • Enge Abstimmung mit EQTYs Vermögens- und Liquiditätsschicht, die ebenfalls auf Base lebt

Die Verankerung an Base entfernt die Last, eine benutzerdefinierte Layer 1 aufrechtzuerhalten, während sie die Überprüfbarkeit, Komponierbarkeit 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 Beibehaltung einer Layer-1 bietet bei hohen Kosten wenig strategischen Vorteil.

  • Der Wechsel zu Base ermöglicht es EQTY, sich vollständig auf Produkteinführung, rechtliche Integration und Tokenisierung von Vermögenswerten zu konzentrieren, ohne durch Layer-1-Infrastruktur behindert zu werden.

2. Neuer $EQTY ERC-20 Token

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

Der Token-Vertrag beginnt mit null Angebot. $EQTY wird auf Anfrage mintiert, wenn Benutzer ihre LTO-Token während eines begrenzten Migrationszeitraums tauschen. Dieses Fenster wird on-chain durchgesetzt: nach einer vordefinierten Blockhöhe wird die Mint-Funktion dauerhaft deaktiviert. Alle LTO-Token, die vor diesem Stichtag nicht umgetauscht werden, sind vom EQTY-Ökosystem ausgeschlossen, und das endgültige $EQTY-Angebot wird niedriger sein als das ursprüngliche LTO-Angebot.

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

Der $EQTY-Token wird verwendet, um Verankerungsgebühren zu zahlen, an der Protokollgovernance teilzunehmen und möglicherweise zusätzliche Nutzungsrollen zu unterstützen, während sich die Plattform weiterentwickelt. Die Nutzung erfordert das Verbrennen von Tokens, wodurch das Gesamtangebot verringert wird.

3. Ankervertrag auf Base

Die Verankerung wird über einen leichten Smart Contract durchgeführt, der im Base-Netzwerk bereitgestellt wird. Dieser Vertrag gibt Ereignisse aus, die öffentlich den Hash von Ereignisketten oder Nachrichten aufzeichnen, ohne einen Zustand on-chain zu speichern.

Jede Ankerpunkte mappt einen Schlüssel zu einem Wert, wobei:

  • Für Ereignisketten: key = stateHash, value = eventHash

  • Für Nachrichten: key = messageHash, value = 0x0

Schnittstelle

struct Anchor {

bytes32 Schlüssel;

bytes32 Wert;

}

Funktion anchor(Anchor[] calldata anchors) extern;

Ereignis verankert(

bytes32 indexierter Schlüssel,

bytes32 Wert,

Adresse indexierter Absender,

uint64 timestamp

);

Verhalten

  • Der Vertrag gibt ein verankertes Ereignis pro (Schlüssel, Wert)-Paar aus.

  • Der aktuelle block.timestamp ist im Ereignis als separates Feld zur Bequemlichkeit und Überprüfbarkeit enthalten.

  • Es wird kein Zustand im Vertrag gespeichert. Alle Verankerungsdaten werden nur über Protokolle aufgezeichnet.

  • Der Vertrag ist genehmigungsfrei - jeder kann verankern.

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

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

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

Durch die Beibehaltung der Verankerung als zustandslos und das Ausgeben vollständiger Ereignisse stellt dieses Design sicher, dass die Verankerung verifizierbar, effizient und infrastrukturell unabhängig ist.

Gebührenmechanismus

  • Die Clients müssen approve() auf dem ERC20-Vertrag aufrufen, um die Verankerung zu aktivieren

  • Jeder Anker bringt ein Verbrennen von $EQTY mit sich, das in der Funktion anchor() durchgesetzt wird

  • Der Gebührenbetrag wird aus einem separaten, von der Governance gesteuerten Konfigurationsvertrag gelesen

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

4. Gebühren-Governance

Um die Verankerung über die Zeit wirtschaftlich nachhaltig und fair zu gestalten, muss die Gebühr, die pro Anker in $EQTY gezahlt wird, anpassbar sein. Anstatt eine statische Gebühr festzulegen oder sich auf Preisorakel zu verlassen, wird EQTY ein On-Chain-Governance-Modell verwenden, um diesen Parameter auf transparente und dezentrale Weise zu steuern.

Ein dedizierter Konfigurationsvertrag wird die aktuelle Verankerungsgebühr speichern. Dieser Wert kann nur durch einen Governance-Vertrag aktualisiert werden - spezifisch durch eine Instanz von OpenZeppelin’s Governor, die an den $EQTY-Token gebunden ist. Stimmen werden basierend auf $EQTY-Bilanzen unter Verwendung der Standard-ERC20Votes-Logik abgegeben.

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

Das Governance-Modell ermöglicht es der Gemeinschaft, die Gebühren im Laufe der Zeit als Reaktion auf Marktbedingungen, Preisschwankungen des Tokens oder Änderungen in der Verankerungsnachfrage anzupassen - ohne sich auf externe Datenquellen oder zentrale Kontrolle zu verlassen.

5. Neue Private Layer-Bibliothek

Um die Verankerung auf Base und das brieftaschen-native Signieren zu unterstützen, wird eine neue eigenständige TypeScript-Bibliothek erstellt, um die Logik der privaten Schicht zu behandeln - einschließlich Ereignisketten, Ereignisunterzeichnung, Verankerung und Strukturen von Relay-Nachrichten. Diese Bibliothek ersetzt die LTO-spezifische @ltonetwork/lto-api.js für alle EQTY-Anwendungsfälle.

Die neue Bibliothek ist für die Verwendung in Browserumgebungen (z.B. MetaMask, WalletConnect) und serverseitigen Tools konzipiert.

Umfang und Inhalte

Nur die relevanten Komponenten der LTO-privaten Schicht werden einbezogen:

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

  • Nachricht/ Beinhaltet Nachricht und Relay, die für verschlüsselte off-chain Kommunikation verwendet werden.

  • Unterstützende Code Beinhaltet Hilfsklassen wie Binary.

Die Bibliothek hat keine Abhängigkeit von LTO Network:

  • Kein LTO-Knoten-API

  • Keine Transaktionslogik

  • Keine Tools zur Schlüsselpaargenerierung

  • Keine LTO-spezifische Adresscodierung

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

Ereignisunterzeichnungsmodell

Die Methode Event.signWith() wird asynchron gestaltet, um browserbasiertes Signieren über MetaMask, WalletConnect oder einen anderen externen Unterzeichner neben dem direkten Signieren mit ethers zu unterstützen. Sie verwendet eine abstrakte ISigner-Schnittstelle:

interface ISigner {

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

}

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

Verankerungsintegration

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

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

Jeder Anker mappt einen stateHash (Schlüssel) zu einem lastEventHash (Wert), bereit zur Einreichung an den Smart Contract auf Base. Für Relay-Nachrichten wird der Nachrichten-Hash selbst als Anker-Schlüssel verwendet, und der Wert wird auf null (0x0) gesetzt.

Verankerung kann durch direkten Aufruf des Smart Contracts über ethers.Contract.anchor(Anchor[]). durchgeführt werden. Dies vermeidet die Abhängigkeit von einem Backend-Service oder proprietärer Infrastruktur.

Nachrichtenunterzeichnung

Die Bibliothek umfasst auch Klassen für Nachrichten und Relay für die off-chain Kommunikation. Wie Ereignisse werden Nachrichten asynchron unter Verwendung der ISigner-Schnittstelle signiert. Signaturen sind über den Nachrichten-Hash, und es wird kein öffentlicher Schlüssel einbezogen - nur die abgeleitete Adresse wird zur Verifizierung verwendet.

Nach der Unterzeichnung wird der Nachrichten-Hash ü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 ihre Inhalte offenzulegen. Die Verankerung 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 Ereignisbau und Einreichung)

  • Jedes Frontend oder jeder Verifier von Dritten

6. oBridge-Indizierung

Der oBridge-Service wird seine derzeitige LTO-basierte Indizierungslogik durch einen neuen Indexer ersetzen, der verankerte Ereignisse verarbeitet, die vom Verankerungsvertrag auf Base ausgegeben werden.

Dieser Indexer hört auf Verankerungsprotokolle auf Base und pflegt eine lokale Datenbank des aktuellsten Ankers pro Schlüssel, der entweder einen Zustand von Ereignisketten oder einen Hash von Relay-Nachrichten darstellen kann. Jeder Eintrag umfasst:

  • Schlüssel: der verankerte Zustand oder Nachrichtenhash

  • Wert: der entsprechende Ereignishash oder 0x0

  • txHash, blockNumber, logIndex und sender

Diese Aufzeichnungen werden über eine öffentliche HTTP-API bereitgestellt. Die Struktur und das Verhalten dieser API bleibt mit dem bestehenden LTO-Verankerungs-Indexer kompatibel, einschließlich des GET /hash/verify-Endpunkts, sodass bestehende EQTY-Komponenten mit minimalen Änderungen übergehen können.

Der oBridge-Indexer hat 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 Clients und Brieftaschen, die den Verankerungsstatus überprüfen möchten, ohne Base direkt zu befragen.

Alle Daten bleiben on-chain verifizierbar, und die Clients können oBridge bei Bedarf umgehen, indem sie eth_getLogs oder ihren eigenen Indexer verwenden.

7. Relay-Dienst

Der Relay-Dienst kümmert sich um die sichere Übertragung von verschlüsselten Nachrichten zwischen Parteien. Um sicherzustellen, dass Nachrichten authentisch, zeitgestempelt und zugangskontrolliert sind, wird der Dienst aktualisiert, um sowohl die Validierung der On-Chain-Verankerung als auch die moderne, brieftaschen-native Authentifizierung mit Sign-In with Ethereum (SIWE) zu unterstützen.

Nachrichtenauthentifizierung mit SIWE

Anstatt auf HTTP-Nachrichtensignaturen oder benutzerdefinierte Herausforderungen angewiesen zu sein, wird der Relay 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-Brieftasche signieren, wodurch eine wiederherstellbare Signatur erzeugt wird, die sie an eine Sitzung bindet.

Anmeldefluss:

  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 aus, die Folgendes enthält:

  • Domain (z.B. relay.eqty.network)

  • Nonce

  • Ablaufzeitstempel

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

  • Aussage: z.B. "Melden Sie sich an, um auf Ihre EQTY-Nachrichten zuzugreifen."

  1. Der Client signiert die Nachricht mit personal_sign

  2. Der Client reicht die signierte Nachricht und die Signatur an POST /auth/verify ein

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

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

  • Ein Erneuerungstoken (längerlebig, z.B. 24 Stunden)

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

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

Dieses Modell ist vollständig kompatibel mit MetaMask, WalletConnect und anderen EIP-1193-Brieftaschen und folgt weit verbreiteten Sicherheitsmustern. Es sind keine benutzerdefinierten Logik oder Infrastruktur über bestehende SIWE-Bibliotheken hinweg erforderlich.

Nachrichtenverankerung und -verifizierung

Zusätzlich zur Authentifizierung wird der Relay-Dienst bestätigen, dass jede Nachricht on-chain verankert wurde, bevor sie geliefert wird. Verankerung bietet Unveränderlichkeit, Zeitstempelung und verhindert Spam- oder Replay-Angriffe.

Der Relay hält seinen eigenen leichten Indexer für den Verankerungsvertrag auf Base. Er hört auf verankerte Ereignisse und zeichnet auf:

  • key = messageHash

  • value = 0x0

  • sender

  • blockNumber, txHash, timestamp

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

  • Ein verankertes Ereignis existiert mit key = messageHash

  • Der Wert ist genau 0x0 (d.h. kein Verankerungspunkt für Ereignisketten)

  • Der Absender stimmt mit dem Nachrichtenunterzeichner überein (d.h. von Adresse)

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

Der Relay führt diese Überprüfung mit seinem eigenen internen Indexer durch und verlässt sich nicht auf oBridge.

8. Änderungen am Ownable-Vertrag (CosmWasm)

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

Adressenbasierte Autorisierung

Früher basierte die Eigentumsverifikation auf dem Wiederherstellen und Vergleichen öffentlicher Schlüssel, die aus unterzeichneten Ereignissen extrahiert wurden. Da Ethereum-Brieftaschen keine öffentlichen Schlüssel offenlegen und Signaturen jetzt personal_sign (wiederherstellbar zu einer Adresse) verwenden, muss sich das Verifikationsmodell auf den direkten Vergleich von Adressen verschieben.

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

Dies betrifft alle Einstiegspunkte, an denen Autorisierung erforderlich ist:

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

  • try_release: 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 umzuwandeln, speichert der Vertrag einfach Addr-Werte (z.B. 0xabc123...) und vergleicht sie.

CAIP-2 und Netzwerkabgleich

Der Vertrag validiert weiterhin den Ursprung von Cross-Chain-Ereignissen unter Verwendung des CAIP-2-Netzwerknamens. Für Ethereum-basierte Nachrichten ist der Namespace 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-Namespace

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

Auswirkung

Diese Änderung macht den Ownable-Vertrag:

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

  • Unabhängig von der LTO-Schlüsselinfrastruktur

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

Bestehende Ownables, die sich auf LTO-spezifische Unterzeichnung und Verankerung stützen, werden unter dem neuen Modell unverifizierbar und müssen neu ausgegeben werden (siehe Abschnitt 11).

9. Aktualisierung des Ownables SDK

Das Ownables SDK muss aktualisiert werden, um den Übergang von LTO-basierter öffentlicher Schlüsselunterzeichnung zu Ethereum-stiliger adressenbasierter Autorisierung und Base-Verankerung widerzuspiegeln.

Wichtige Aktualisierungen

  1. Ereignisunterzeichnung

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

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

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

  1. Verankerung

  • Ersetzen Sie die LTO-Knotenverankerungslogik 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 die Nachrichtenverankerung (key = messageHash, value = 0x0) verwendet

  1. Verifizierung

  • Aktualisieren Sie die Verifizierungslogik, um die mit 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. Adressennutzung

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

  • Verwenden Sie einfache Ethereum-Adressen (0x...) in allen 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 mit der neuen privaten Layer-Bibliothek und der Base-Verankerung kompatibel und wird mit den aktualisierten Ownable-Verträgen und dem Relay-Dienst interagieren.

10. Aktualisierung der universellen Brieftasche

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

Kernaktualisierungen

  1. Brieftaschenverbindung

  • Ersetzen Sie die LTO-Keypair-Behandlung durch eine Ethereum-kompatible Bibliothek (ethers.js)

  • Verwenden Sie EIP-1193-Provider-Schnittstellen, um das Signieren und Abrufen von Adressen 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 Layer-Bibliothek, um Benutzern die Erstellung und Unterzeichnung von Ereignisketten und Nachrichten zu ermöglichen

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

  1. Verankerung

  • Reichen Sie Ankerkarten direkt beim Basenankervertrag unter Verwendung von ethers.js ein

  • Verwalten Sie die On-Chain-Einreichung, Bestätigung und optionale UI-Rückmeldungen zu den Verankerungskosten in $EQTY

  1. Relay-Integration

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

  • Zugriffstoken nach Bedarf speichern und erneuern

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

Entfernte Funktionen

  • LTO-Leasing-UI

  • Knotenauswahl und Kettenansicht

  • On-Chain-Identitätsmanagement, das an LTO gebunden ist

11. Migrationsplan

Mit der Abwertung von LTO Layer 1 und der Einführung eines neuen Verankerungssystems auf Base müssen alle Kernkomponenten des Protokolls migrieren. Veraltete Daten, die an die LTO-Infrastruktur gebunden sind - einschließlich Anker, Ereignisketten und Nachrichten - sind nicht mehr gültig.

Was ungültig wird

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

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

  • Ownables, die an LTO-basierte Identitäten oder verankerte Ketten gebunden sind, müssen ersetzt werden.

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

Erforderliche Maßnahmen

  1. Token-MigrationBenutzer müssen manuell ihre LTO-Token gegen $EQTY über die Brücke tauschen. Die Prägung 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 Asset wieder ausgeben.Eigenständige Herausgeber müssen neue Ownables ausgeben, die an das BASE-Netzwerk gebunden sind. Anleitungen werden folgen, wie veraltete Ownables gegen neue Ownables getauscht werden.

  3. Brieftaschenübergang Benutzer müssen die Universelle Brieftasche aktualisieren.

Kein Snapshot

Es wird keinen Snapshot, keine automatische Migration oder Kompatibilitätsschicht geben. Jede Komponente (Ereignisse, Nachrichten, Tokenbilanzen) muss über die richtigen Schnittstellen auf Base neu etabliert werden. Das neue Protokoll ist aus Designgründen sauber und bewahrt keine Bindungen an LTO L1.

#ETH