---
title: "Überprüfung eines nach dem Bridging erhaltenen Tokens"
description: "Zu prüfen sind Identität, Herkunft, Deckungsmodell, Befugnisse, In-flight-Buchung, Einlösung und ausführbarer Exit-Wert."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Überprüfung eines nach dem Bridging erhaltenen Tokens
> 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.
## 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
- [Kanonische, native und Wrapped Token](/de/crypto/canonical-vs-wrapped-token/)
- [Kanonische Bridge](/de/crypto/canonical-bridge/)
- [Cross-Chain-Bridge](/de/crypto/cross-chain-bridge/)
## Quellen
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Developers (abgerufen: 2026-08-13)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (abgerufen: 2026-08-13)
- [Routes](https://docs.wormhole.com/products/connect/concepts/routes/) - Wormhole Docs (abgerufen: 2026-08-13)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (abgerufen: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (abgerufen: 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (abgerufen: 2026-08-13)
- [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) - Uniswap (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/bridge-token-verification/index.mdx