LayerZero OFT (Omnichain Fungible Token) ist ein Standard, um Token-Werte über verschiedene Chains hinweg zu bewegen und dabei ein beabsichtigtes globales Token-Angebot zu erhalten. Ein Transfer bucht Token auf der Quell-Chain ab (Debit) und gutschreibt sie dem Empfänger auf der Ziel-Chain (Credit). Direkte OFTs und Adapter setzen diese Buchführung durch unterschiedliche Vertrags- und Custody-Arrangements um.
Die Details entscheiden darüber, wie viel Vertrauen dieses Versprechen erfordert. Ein direkter OFT und eine Adapter-basierte Bereitstellung können ähnliche Ergebnisse durch unterschiedliche Custody- und Minting-Arrangements erzielen. Keines von beiden bietet jedem Netzwerk automatisch die gleiche Marktliquidität.
Der Quell-Debit kommt zuerst
Bei einem direkten Burn-and-Mint OFT verbrennt ein Cross-Chain-Transfer den übertragbaren Betrag an der Quelle. Eine verifizierte Nachricht ermöglicht dem vertrauenswürdigen Ziel-Vertrag dann, den entsprechenden Betrag für den Empfänger zu minten.
Während der Zustellung befindet sich ein Teil des Wertes im Transit. Wenn man zu diesem Zeitpunkt nur die aktiven Wallet-Bestände zählt, kann das Token-Angebot niedriger erscheinen als das beabsichtigte Gesamtangebot. Nach erfolgreicher Gutschrift ist der auszugebende Betrag an das Ziel gelangt. OFT technische Referenz.
In einem hypothetischen Transfer beginnt Chain A mit 700 Token und Chain B mit 300. Das Verbrennen von 100 auf A lässt 600 dort und 100 im Transit zurück. Wenn B den Transfer gutschreibt, wird sein Bestand 400 und der im Flug befindliche Betrag kehrt auf Null zurück. Das beabsichtigte Gesamtangebot bleibt während des gesamten Prozesses bei 1.000, wenn man den Wert im Transit mitzählt.
Die realen Verträge müssen diese Buchführung bei Wiederholungsversuchen, Fehlern und Administrator-Aktionen beibehalten. Ein schönes Diagramm setzt eine korrekte Implementierung voraus. Eine Sicherheitsüberprüfung muss diese Annahmen testen.
Debit hier, Credit dort
Die OFT-Buchführung zielt darauf ab, das wirtschaftliche Angebot über verschiedene Chains hinweg zu bewegen, ohne eine unabhängige zusätzliche Allokation zu erstellen.
Adapter behalten einen bestehenden Token
Ein Issuer kann bereits einen Token-Vertrag haben, den er nicht ersetzen möchte. Ein OFT-Adapter kann diesen Token mit dem Messaging-Flow verbinden. In einer gängigen Anordnung werden die ursprünglichen Token im Adapter gesperrt, während das Ziel eine Repräsentation gutschreibt. Die Rückkehr über die Route verbrennt diese Repräsentation und setzt das gesperrte Guthaben frei.
Das Escrow führt einen Custody-Punkt in das Token-System ein. Du musst wissen, welcher Vertrag das ursprüngliche Asset hält, wer darauf Einfluss nehmen kann und wie sich das Remote-Angebot auf diese Reserve bezieht. Die gesperrten Originale und Remote-Repräsentationen als separates wirtschaftliches Token-Angebot zu zählen, würde denselben Wert doppelt zählen. OFT-Muster und Erweiterungen.
Ein Adapter kann auch Mint- und Burn-Berechtigungen halten, anstatt Escrow zu verwenden. „Verwendet OFT“ sagt dir die Familie des Transfer-Musters. Es identifiziert nicht das Custody-Modell, daher verdient ein Adapter seine eigene Beschreibung in einem Asset-Vergleich.
Achte auf die genaue Deployment-Architektur. Die offizielle Contract-Liste eines Issuers und die konfigurierten Gegenpart-Verträge helfen dabei festzustellen, welchen Token du hältst. Ein Name oder Ticker kann von einem nicht verwandten Contract kopiert werden.
Ein Peer definiert, wer Wert gutschreiben kann
Token-Deployments müssen ihre vertrauenswürdigen Gegenstücke erkennen. Wenn ein Zielort Nachrichten von einem nicht beabsichtigten entfernten Sender akzeptiert, können gültige Protokoll-Nachrichten immer noch die falsche Anwendungsautorität erreichen.
Der Issuer legt zudem die Verifizierungs- und Ausführungs-Einstellungen auf Routenebene fest. Diese Entscheidungen können je nach Richtung oder Chain variieren. Ein gut geprüftes Deployment auf einem Netzwerk stellt nicht die Sicherheit jeder späteren Route sicher. OApp technische Referenz.
Prüfe bei einem Asset, das du halten möchtest, wer diese Einstellungen kontrolliert. Ein Multisig-Verfahren, Verzögerungen und Überwachungsprozesse können einige operationelle Risiken einschränken, aber sie müssen im tatsächlichen Deployment existieren. Architekturdiagramme sind kein Beweis für die Verwahrung von Schlüsseln.
Der DVN- und Executor-Leitfaden erklärt die Verifizierungswahlen. Die LayerZero-Einführung bietet einen breiteren Überblick über den Nachrichtenfluss, falls du zum ersten Mal auf Peers und Endpunkte stößt.
Dezimale Präzision ist Teil des Transfers
Blockchains können Token-Beträge mit unterschiedlicher Dezimalpräzision darstellen. Ein Cross-Chain-Token benötigt eine gemeinsame Recheneinheit, damit ein Deployment den von einem anderen gesendeten Betrag nicht falsch liest.
Das OFT-Design normalisiert übertragbare Beträge durch gemeinsame Dezimalstellen. Beträge, die kleiner als diese gemeinsame Präzision sind, können beim Sender als Rundungsrest verbleiben, oft als „Dust“ bezeichnet. OFT-Dezimalbuchhaltung.
Beispielsweise wird bei sechs gemeinsamen Dezimalstellen und einem Quelltoken, der eine höhere Präzision unterstützt, eine Anfrage für 1,123456789 Token zu einem übertragbaren Betrag von 1,123456. Die restlichen 0,000000789 bleiben beim Sender. Dies ist eine illustrative Arithmetik, keine Gebühr, die von der Bridge erhoben wird.
Dies ist ein gutes Beispiel für ein kleines technisches Detail mit einer direkten finanziellen Konsequenz. Das System muss den wirtschaftlichen Wert erhalten, während es zwischen verschiedenen Darstellungen übersetzt. Das Ziel sollte keinen größeren Saldo erhalten, nur weil der Vertrag die Einheit falsch interpretiert hat.
Gemeinsames Token-Angebot verlässt getrennte Märkte
Angenommen, dasselbe Asset existiert auf zwei Netzwerken. Die Buchhaltung kann konsistent bleiben, während ein Netzwerk tiefe Märkte hat und das andere kaum Handelsaktivität aufweist. Der Transfer-Mechanismus schafft an sich keine Gebote, Market-Maker oder Collateral-Nachfrage.
Eine Preislücke kann bestehen bleiben, wenn Arbitrage teuer, langsam oder eingeschränkt ist. Cross-Chain-Gebühren, Transfer-Verzögerungen und Investoren-Berechtigungen beeinflussen die Kosten, um diese Lücke zu schließen. Dass eine Route technisch verfügbar ist, garantiert nicht, dass ein Trader sie in der erforderlichen Größe nutzen kann.
Ein Emittent kann ebenfalls Limits nutzen, um die Auswirkungen abnormaler Transfer-Aktivitäten zu reduzieren. Diese Limits können die Risikokontrolle verbessern, während sie einen sofortigen großen Arbitrage-Handel unmöglich machen. Das finanzielle und operative Design muss zusammen bewertet werden.
Diese Unterscheidung ist besonders nützlich für RWA-Produkte. Fondsvolumen, das globale Token-Angebot und die Liquidität in einem bestimmten Pool beantworten unterschiedliche Fragen. Der Treasury-Vergleich hält sie getrennt, wenn ein Exit in Betracht gezogen wird.
Emittenten-Kontrollen begleiten das Asset
Ein OFT-Deployment kann benutzerdefinierte Transfer-Kontrollen enthalten. Für ein tokenisiertes Finanzprodukt muss der Emittent möglicherweise die Teilnahmeberechtigung, sanktionsbezogene Einschränkungen oder andere Regeln für Inhaber über die unterstützten Chains hinweg beibehalten.
Dies erfordert Richtlinien auf Anwendungsebene. Eine Nachricht kann gültig sein, während der beabsichtigte Empfänger die Teilnahmeberechtigung des Emittenten nicht besteht. Das System muss definieren, was dann passiert, einschließlich des Recovery-Pfads und wer intervenieren kann.
Ondos Beschreibung der institutionellen Bridge liefert einen konkreten Fall, in dem ein Emittent mehrere erforderliche Verifizierungsanbieter spezifiziert. Diese Struktur veranschaulicht, wie eine asset-spezifische Bridge Entscheidungen über den grundlegenden Token-Standard hinaus treffen kann. Ondo institutionelle Bridging.
Lies die aktuelle Konfiguration, bevor du dich auf das historische Beispiel verlässt. Ein veröffentlichtes Launch-Design beschreibt diesen Launch, und die Produktions-Einstellungen können sich ändern. Ondo vs. Centrifuge stellt Distributions-Tools in den breiteren Geschäftsvergleich.
Ein Transfer gefolgt von einer weiteren Aktion
OFT kann zusätzliche Anweisungen für eine Zielanwendung mitführen. Das Empfangen eines Tokens und dessen Verwendung in einem anderen Vertrag führt eine weitere Stufe ein, die ihre eigene Fehleranfälligkeit hat. Omnichain-Composers.
Stell dir vor, ein RWA-Token kommt bei einer Lending-Anwendung an. Der Token-Transfer könnte abgeschlossen sein, während die Einzahlung fehlschlägt, weil der Markt diesen Vermögenswert nicht mehr akzeptiert. Der Empfänger benötigt einen klaren Status und eine Route, um das erhaltene Guthaben zurückzuholen oder zu verwenden.
Die Schnittstelle sollte diese Unterscheidung offenlegen. Die gesamte Erfahrung als einen Erfolg oder ein Scheitern zu behandeln, verbirgt nützliche Informationen und kann dazu führen, dass Nutzer eine Aktion wiederholen, die bereits teilweise abgeschlossen wurde.
Rebasing und Transfer-Gebühren benötigen eine andere Buchführung
Ein Yield-Token kann sein Halter-Guthaben durch Rebasing ändern. Ein Fee-on-Transfer-Token liefert weniger als der Absender überträgt. Die Standard-OFT-Buchführung von LayerZero unterstützt diese Verhaltensweisen ohne Änderungen nicht: Die Debit- und Credit-Logik geht von verlustfreien Transfers aus. Die Implementierung muss die tatsächlichen Guthabenänderungen abstimmen.
Identifiziere bei einem ertragstragenden Vermögenswert den Wrapper und die verwendete Buchführung, bevor du eine OFT-Integration als kompatibel betrachtest. OFT technische Referenz.
Bevor du einem neuen Deployment vertraust
Überprüfe die offiziellen Verträge, die Peer-Beziehung und das Custody-Muster. Untersuche dann die Verifizierungskonfiguration, die Transfer-Limits und die Administrator-Rechte. Teste schließlich die Route, die du für die Einlösung oder weitere Anwendungsaktivitäten verwenden möchtest.
OFT bietet ein gemeinsames Muster für den Transfer von Token-Werten zwischen Netzwerken. Das Deployment entscheidet, wie dieses Muster einem bestimmten Vermögenswert dient. Für einen anderen Ansatz zur Cross-Chain-Token-Infrastruktur lies weiter in LayerZero vs. Chainlink CCIP.