Zum Inhalt springen
Financial Context Wiki

Überprüfung eines nach dem Bridging erhaltenen Tokens

Zu prüfen sind Identität, Herkunft, Deckungsmodell, Befugnisse, In-flight-Buchung, Einlösung und ausführbarer Exit-Wert.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Name, Symbol, Icon, angezeigter Preis oder Transfer-Event verifizieren keinen nach dem Bridging erhaltenen Token. Identität beginnt mit Chain/Domain und Token-Vertrag oder Native-Asset-Marker und umfasst aktuelle Proxy-Implementation oder Beacon, Issuer oder Bridge, Route und Version, Origin Asset und Block-Snapshot.

Dann ist der Claim zu klassifizieren: Issuer-native Supply, protokolldefinierte Bridge-Repräsentation, Wrapped Token eines Dritten, Liquidity-/Intent-Receipt oder Fälschung. Sie haben verschiedene Issuer, Assets, Einlösungsrechte und Fehler. Eine kanonische Bridge-Repräsentation ist nicht automatisch issuer-native; eine Issuer-Liste beweist keine Drittbridge-Reserven.

Vier Bücher sind nötig: Identität/Befugnisse; Reserven/Claims; In-flight-Nachrichten; ausführbare Einlösung oder Markt-Exit. Ein Wallet-Saldo kann echter Vertragszustand sein und dennoch falsches Asset, unterdeckten Claim, eingefrorenen Token oder eine nicht zum angezeigten Preis verkäufliche Position darstellen.

Überprüfung von Bridge-Token
0 / 5
0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Funktionsweise

Symbol, Name und Decimals sind ERC-20-Metadaten, keine Issuer-Authentifizierung. Eine Fälschung kann sie kopieren, normale Events emittieren, verifizierten Source veröffentlichen und einen Pool ausstatten. Source-Verifikation verbindet nur angezeigten Code mit Bytecode einer Address. Beim Proxy liegen Interaktion und Salden am Proxy, Implementation/Beacon liefert Logik; Admin und Upgrade Path bleiben getrennt.

Klassifizieren Sie das Buchungsmodell vor Coverage. Lock-and-Mint gleicht Eligible Escrow mit allen gestützten Repräsentationen und gültigen In-flight Claims ab. Issuer-Burn-and-Mint verschiebt Supply zwischen Domains und hat eventuell kein permanentes Escrow. Liquidity Bridge streckt Inventory vor oder erzeugt Solver-/LP-Claim; ihr Pool ist nicht automatisch Deckung. Shared Reserves werden über Chains/Versionen einmal gezählt.

Für definiertes Lock-and-Mint gilt diagnostisch coverage = eligible reserves / supported outstanding claims. Eligible Reserves müssen richtiges Asset, unter zugesagter Custody, unbelastet und nicht erneut verpfändet sein. Claims umfassen Multi-Chain/-Version-Circulation plus finalisierte, noch nicht gemintete Locks minus bereits in Supply reflektierte Burns. Ratio über eins beweist weder Code, Admins, Finality, Einlösungszugang noch Depth.

Prüfen Sie Mint-/Burn-Rollen, Remote-Token-Mappings, Validators/Attesters, Proxy Admin, Implementation, Timelock, Caps, Pause, Freeze, Denylist und Migration Powers. Decimals, Fee-on-transfer, Rebase, Hooks/Callbacks, nicht standardisierte Returns und Upgradeable Logic können Sollbetrag und tatsächlich empfangenes Escrow/Balance unterscheiden.

Einlösung und Verkauf sind getrennte Exits. Direkte Einlösung kann Eligible Account, unterstützte Direction, Limits, Queue, Proof/Attestation, Finality, Gas, Fee und aktive Verträge verlangen. DEX-Exit braucht größenbezogene ausführbare Route, Fee, Depth, Price Impact, Minimum Output und Timestamp. Ein kleiner Dollar-Quote beweist weder Deckung noch großen Exit.

Migration kann Identität und Liquidität teilen. Deprecated Representation kann nach einem Replacement weiter handeln; Conversion kann gecappt, einseitig, verzögert oder geschlossen sein. Prüfen Sie offizielle Old-to-new-Mappings, Ratio, Deadline und Redemption Status; tauschen Sie nicht nur wegen Support-Nachricht oder Upgrade-Symbol.

Verwenden Sie diesen Ablauf:

  1. Fixieren Sie Chain/Domain, Proxy/Native Marker, Implementation/Beacon, Admin, Decimals, Block/Zeit, Issuer/Bridge, Route/Version und Origin Asset.
  2. Prüfen Sie Issuer-/Bridge-Registries beidseitig; Remote-Token Mapping, Deployment, Replacement/Deprecation und Issuer-native oder Bridge-only Rights.
  3. Klassifizieren Sie Issuer Burn-and-Mint, Lock-and-Mint, Shared Reserve, Third-party Wrapper, Liquidity-/Intent-Receipt oder anderes Modell.
  4. Rekonstruieren Sie Raw-unit Reserves, Supply aller Chains/Versionen, finalisierte In-flight Claims, Pending Burns/Releases und Fees; verhindern Sie Doppelzählung.
  5. Prüfen Sie Mint/Burn/Pause/Freeze/Denylist/Cap, Validator/Attester, Proxy Admin, Implementation/Upgrades und Transfer/Rebase/Hook-Verhalten.
  6. Testen Sie tatsächliche Einlösung und größenbezogenen Exit: Eligibility, Limits, Queue, Proof, Finality, Gas, Fees, Route, Depth, Minimum Output und erhaltenes Asset.
  7. Gleichen Sie Source Receipt, Escrow-Delta/Burn, Nachricht, Destination Receipt, Token Balance, Supply, Fees und Netto-Exit ab; überwachen Sie Migration und stoppen Sie bei Abweichungen.

Beispiele

  • Metadaten bestimmen weder Einheit noch Identität. Der Rohbetrag 123,456,789 ergibt als Anzeige 123.456789 bei 6 decimals, aber 0.000000000123456789 bei 18 decimals: ein Skalierungsunterschied von 10^12. Dasselbe Symbol macht die Verträge nicht identisch.
  • Fee-on-transfer erzeugt sofortige Unterdeckung. Lock 1,000-token; Fee 1% entfernt 10, Escrow erhält 990; Bridge berechnet 2-token. Korrekter Mint 1,000 - 10 - 2 = 988. Mint von 998 gegen 990 Escrow erzeugt 8-token Unterdeckung.
  • Shared Reserves brauchen System-Denominator. Escrow 12.0 million; B 10.5 million, C 0.4 million, In-flight Claim 0.6 million. Claims 10.5 + 0.4 + 0.6 = 11.5 million; Coverage 12 / 11.5 = 1.0434782609 oder 104.34782609%. Nur B meldet 12 / 10.5 = 1.1428571429 und überzeichnet.
  • Redemption Capacity und DEX-Wert unterscheiden sich. Holder besitzt 100,000 tokens; offiziell jetzt 60,000 bei 0.20% Fee: 60,000 * (1 - 0.002) = 59,880 Underlying, 40,000 in Queue. DEX bei 0.972 vor 0.30%: Gross 97,200, Fee 291.60, Net 96,908.40, vor Gas/MEV. $1-Icon beweist nichts.

Risiken

  • Gleiche Address auf falscher Chain/Domain wird verwechselt.
  • Kopiertes Symbol/Name/Icon verbirgt anderen Vertrag.
  • Proxy, Implementation oder Beacon werden verwechselt.
  • Verified Source wird für Issuer-Endorsement gehalten.
  • Implementation/Admin/Upgrade History wird nicht geprüft.
  • Deprecated Version bleibt in Gebrauch.
  • Fälschung erzeugt normale Events und künstliche Liquidität.
  • Third-party Wrapped/LP Receipt wird für Issuer-native gehalten.
  • Falsches Lock/Burn/Mint/Reserve/Liquidity-Modell.
  • Eligible Reserves enthalten Frozen/Borrowed/Pledged/Mismatched Assets.
  • Gleiche Reserve wird je Chain gezählt.
  • Other-chain/Legacy/In-flight Claims fehlen.
  • Burns/Mints/Snapshots nutzen inkonsistente Zeiten.
  • Mint/Burn/Attester/Validator/Upgrade Authority kompromittiert.
  • Pause/Freeze/Denylist/Rate Limit blockiert Transfer/Exit.
  • Decimals/Raw Units/Fee-on-transfer/Rebase/Hooks brechen Accounting.
  • Reorg oder unzureichende Finality invalidiert Backing-Nachweis.
  • Eligibility/Cap/Queue/Deadline/Finality/Fee ignoriert.
  • Depth/State Drift/Slippage/MEV/Fees macht Quote unausführbar.
  • Migration/Replacement/Refund/Receipts falsch abgeglichen oder Phishing.

Häufige Irrtümer

  • Gleicher Name/Icon bedeutet gleiches Asset. Identität beginnt bei Chain/Domain und exaktem Vertrag.
  • Official/Canonical Bridge Token ist immer issuer-native. Bridge-Bezeichnung und Issuer-Rechte sind getrennt.
  • Coverage über eins beweist Sicherheit/Einlösung. Es beweist nicht Code, Authority, Finality, Liquidity oder Eligibility.
  • Verified im Explorer beweist Endorsement und Unveränderlichkeit. Nicht Issuer, Reserves, Proxy Admin oder Upgrades.
  • DEX-Anzeige von einem Dollar garantiert Dollar-Exit. Erlös hängt von Direction, Size, Route, Depth, Fees, Gas, MEV und Timing ab.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...