Skip to main content

Was ist ein nativer Token

Hinweis: Dieses Dokument ist eine automatische Übersetzung des englischen Originals.

Was ist ein nativer Token

Ein nativer Token ist die eingebaute Währung eines Blockchain-Netzwerks – der Token, der auf Protokollebene existiert und nicht als darauf bereitgestellter Smart Contract. Beispiele sind ETH auf Ethereum, SOL auf Solana, BNB auf BNB Smart Chain, TAO auf Bittensor und AVAX auf Avalanche. Jede Blockchain hat genau einen nativen Token, und er spielt eine grundlegende Rolle, die auf Smart Contracts basierende Token (wie ERC-20) nicht vollständig nachbilden können.

Native Token werden verwendet, um Transaktionsgebühren zu bezahlen (Gas), Validatoren oder Miner für die Sicherung des Netzwerks zu belohnen, und in vielen Proof-of-Stake-Netzwerken dienen sie als das Staking-Asset, das Validatoren sperren, um an der Konsensbildung teilzunehmen. Ohne den nativen Token kann das Netzwerk nicht funktionieren – er ist der wirtschaftliche Treibstoff, der die Blockchain betreibt.

Kurz gesagt: Ein nativer Token ist die eigene eingebaute Währung der Chain, die für Gas-Gebühren, Validator-Belohnungen und Staking verwendet wird, und er existiert auf Protokollebene statt als Smart Contract.

Wie sich native Token von Smart-Contract-Token unterscheiden

Die Unterscheidung zwischen nativen Token und Smart-Contract-Token ist grundlegend, wird aber oft übersehen. Beide Arten von Token können in Wallets gehalten, zwischen Adressen übertragen und in dezentralen Anwendungen verwendet werden. Sie unterscheiden sich jedoch in Ursprung, Mechanik und Rolle.

Dimension Nativer Token Smart-Contract-Token (z. B. ERC-20)
Wo er existiert Im Protokoll selbst eingebaut Als Smart Contract auf dem Protokoll bereitgestellt
Erstellt durch Die Protokollregeln des Netzwerks (Genesis-Block, Emissionsplan) Einen Entwickler, der einen Contract bereitstellt
Für Gas benötigt Ja – erforderlich, um Transaktionsgebühren zu bezahlen Nein – Gas wird immer im nativen Token bezahlt
Rolle im Konsens Oft für Staking und Validator-Belohnungen verwendet Nicht am Konsens beteiligt
Kann ohne Smart Contracts existieren Ja – ist älter als die Smart-Contract-Funktionalität Nein – hängt von der Contract-Bereitstellungsplattform ab
Angebot kontrolliert durch Protokollregeln (fest codierte Emission, Burning, Inflation) Contract-Logik (Mint-/Burn-Funktionen, die vom Bereitsteller festgelegt werden)

Ein praktisches Beispiel: Auf Ethereum ist ETH der native Token. Wenn ein Nutzer einen ERC-20-Token (etwa USDC) an eine andere Adresse sendet, muss der Nutzer die Transaktionsgebühr in ETH bezahlen, nicht in USDC. Der ERC-20-Token kann sich nicht bewegen, ohne dass der native Token die Berechnung bezahlt. Diese Abhängigkeit ist in das Protokoll eingebaut und kann nicht umgangen werden.

Gas und Transaktionsgebühren

Die sichtbarste Rolle eines nativen Tokens ist die Bezahlung von Gas-Gebühren. Jede Operation auf einer Blockchain – das Übertragen von Token, die Interaktion mit einem Smart Contract, das Bereitstellen eines neuen Contracts – erfordert Rechenressourcen von Validatoren oder Nodes. Gas-Gebühren, die im nativen Token denominiert sind, vergüten diese Betreiber für ihre Arbeit. Ohne Gas-Gebühren gibt es keinen wirtschaftlichen Anreiz für Validatoren, Transaktionen zu verarbeiten, und das Netzwerk würde stillstehen.

Die Strukturen der Gas-Gebühren variieren je nach Netzwerk. Ethereum verwendet ein dynamisches Gebührenmodell (Basisgebühr + Priority-Tip). Solana verwendet ein festes Niedriggebührenmodell. BNB Smart Chain und andere EVM-Chains haben ihre eigenen Gebührenparameter. Aber in allen Fällen wird die Gebühr im nativen Token der Chain bezahlt.

Staking und Teilnahme am Konsens

In Proof-of-Stake-Netzwerken ist der native Token typischerweise das Staking-Asset. Validatoren müssen eine bestimmte Menge des nativen Tokens sperren, um an der Blockproduktion und -validierung teilzunehmen. Dieser gestakte Betrag dient als wirtschaftliche Sicherheit: Validatoren, die sich ehrlich verhalten, verdienen Belohnungen (im nativen Token ausgezahlt), während Validatoren, die sich fehlverhalten, riskieren, ihren Einsatz durch Slashing zu verlieren.

Dies schafft eine zirkuläre wirtschaftliche Schleife: Der native Token sichert das Netzwerk durch Staking, und das Netzwerk belohnt Staker mit neu geprägten oder aus Gebühren abgeleiteten nativen Token. Die Sicherheit des Netzwerks ist direkt an den Gesamtwert der gestakten nativen Token gebunden.

Validator-Belohnungen und Emission

Die meisten Blockchain-Netzwerke geben neue native Token als Block-Belohnungen aus, um Validatoren zu incentivieren. Diese Emission wird durch die Regeln des Protokolls gesteuert – nicht durch eine einzelne Person oder einen Smart Contract. Einige Netzwerke haben ein begrenztes Gesamtangebot (wie die 21 Millionen BTC von Bitcoin), während andere eine fortlaufende Inflation mit oder ohne Burning-Mechanismen haben (wie das Gebühren-Burning von Ethereum nach dem Merge).

Der Emissionsplan eines nativen Tokens ist ein Kernbestandteil des wirtschaftlichen Designs des Netzwerks. Er bestimmt die langfristige Angebotsdynamik und die Anreizstruktur für Validatoren. Eine Änderung des Emissionsplans erfordert typischerweise ein Upgrade auf Protokollebene (Hard Fork oder Governance-Abstimmung), nicht eine einfache Contract-Modifikation.

Beispiele für native Token

Verschiedene Blockchain-Netzwerke implementieren ihre nativen Token mit unterschiedlichen Angebotsregeln, Gebührenmodellen und Staking-Mechaniken. Das Verständnis dieser Unterschiede hilft zu veranschaulichen, was „nativer Token“ in der Praxis bedeutet:

Netzwerk Nativer Token Schlüsselrollen Angebotsmodell
Ethereum ETH Gas-Gebühren, Validator-Staking, Basiswährung Unbegrenztes Angebot mit Gebühren-Burning (deflationär bei hoher Nutzung)
Solana SOL Transaktionsgebühren, Validator-Staking Inflationär mit abnehmendem Emissionsplan
BNB Smart Chain BNB Gas-Gebühren, Validator-Staking, Governance Begrenztes Angebot mit periodischen Burns
Bittensor TAO Subnet-Registrierung, Miner-/Validator-Belohnungen, Staking Begrenztes Angebot mit Halving-Emission
Avalanche AVAX Gas-Gebühren, Staking, Subnet-Erstellung Begrenztes Angebot mit Gebühren-Burning

In jedem Fall ist der native Token untrennbar mit dem Betrieb des Netzwerks verbunden. ETH von Ethereum oder SOL von Solana zu entfernen, würde die Chain vollständig lahmlegen – keine Transaktionen könnten verarbeitet, keine Validatoren belohnt und keine Smart Contracts ausgeführt werden.

Native Token in Krypto-KI-Projekten

Viele Krypto-KI-Projekte haben ihre eigenen nativen Token, weil sie eigene Blockchain-Netzwerke oder Subnets betreiben. Für diese Projekte spielt der native Token eine doppelte Rolle:

  • Infrastrukturrolle: Bezahlung von Transaktionen, Staking, Validator-Belohnungen – dieselben Funktionen wie der native Token jeder Blockchain.
  • Anwendungsrolle: Der Token kann auch verwendet werden, um KI-spezifische Dienste (Inferenz, Compute, Datenzugriff) zu bezahlen, KI-Compute-Anbieter zu belohnen oder an der Governance KI-bezogener Parameter teilzunehmen.

Wenn der Token eines Projekts nativ und nicht ein Smart-Contract-Token ist, bedeutet das, dass der Token architektonisch untrennbar mit dem Netzwerk verbunden ist. Die Chain kann ohne ihn nicht funktionieren. Dies ist eine stärkere Form von Token necessity als ein Smart-Contract-Token, der theoretisch durch einen beliebigen anderen Token ersetzt werden könnte.

Allerdings bedeutet „nativ“ nicht automatisch „notwendig für KI“. Ein Projekt kann einen nativen Token haben, der sein Netzwerk durch Staking sichert und Gas bezahlt, während die KI-Komponenten des Projekts den Token nicht in nennenswerter Weise zum Funktionieren benötigen. Die Infrastrukturrolle und die KI-Rolle sind getrennte Fragen.

Token necessity und native Token

Bei der Bewertung, ob ein Token für die KI-Pipeline eines Projekts notwendig ist, stellen native Token einen nuancierten Fall dar. Einerseits ist ein nativer Token für den Betrieb des Netzwerks unbestreitbar notwendig – die Chain kann buchstäblich nicht ohne ihn funktionieren. Andererseits ist die Frage der KI-Notwendigkeit getrennt: Erfordert die KI-Pipeline speziell diesen Token, oder würden die KI-Komponenten auf dieselbe Weise funktionieren, wenn sie auf einer anderen Chain mit einem anderen nativen Token bereitgestellt würden?

Ein starkes Argument für Token necessity auf KI-Ebene besteht, wenn der native Token KI-spezifische Aktionen direkt vermittelt: Bezahlung von Inferenz, Belohnung von Compute-Anbietern, Staking als Qualitätsgarantie für Modell-Outputs. Ein schwächeres Argument besteht, wenn der native Token nur generische Infrastrukturfunktionen erfüllt (Gas, Staking), während die KI-Schicht theoretisch auf jeder Chain betrieben werden könnte.

Wo es in DecAIHub-Projektkarten erscheint

In einer DecAIHub-Projektkarte wird der Wert für einen nativen Token im Feld Token standard als native erfasst. Wenn eine Karte Token standard: native zeigt, bedeutet das, dass der Token des Projekts nicht als Smart Contract auf einer anderen Chain bereitgestellt wird, sondern die eingebaute Währung des eigenen Netzwerks des Projekts ist.

Dies unterscheidet das Projekt von solchen, deren Token ERC-20-Contracts auf Ethereum, BEP-20 auf BNB Smart Chain oder SPL auf Solana sind. Ein nativer Token weist darauf hin, dass das Projekt seine eigene Blockchain oder sein eigenes Subnet mit einem eigenen Konsensmechanismus betreibt.

Das Token-Standard-Feld teilt den Lesern das technische Format des Tokens mit. Um die Rolle des Tokens zu verstehen, sollten Leser das Feld Token model (Utility, Governance, Gebührenmechanismus, Staking) und die Evidence-Tabelle auf Tier-1-Artefakte prüfen, die zeigen, wie der Token tatsächlich in der Pipeline des Projekts verwendet wird.

Was „nativer Token“ allein nicht beweist

  • Ein nativer Token beweist keine Dezentralisierung. Ein Projekt kann seine eigene Chain mit einem nativen Token betreiben und dennoch ein kleines, zentralisiertes Validator-Set oder eine zentralisierte Governance haben. Der native Status des Tokens beschreibt seine technische Rolle, nicht das Dezentralisierungsprofil des Netzwerks.
  • Ein nativer Token beweist keine KI-Notwendigkeit. Der Token kann für den Konsens und die Gas-Gebühren der Chain unverzichtbar sein, während er für die KI-Pipeline des Projekts irrelevant ist. Ob die KI-Komponenten den Token benötigen, ist eine getrennte Frage, die durch die Achse Token necessity in DecAI Fit beantwortet wird.
  • Ein nativer Token beweist nicht, dass das Netzwerk ausgereift ist. Ein Projekt kann seine eigene Chain mit einem nativen Token starten, während sich das Netzwerk noch im Testnet oder in einer frühen Beta befindet. Prüfe das Feld Network status für Informationen zur Reife.
  • Ein nativer Token bedeutet nicht, dass das Projekt seine eigene Chain von Grund auf gebaut hat. Viele native Token existieren auf Subnets, anwendungsspezifischen Chains oder geforkten Netzwerken. Der native Token weist auf die Rolle des Tokens auf Protokollebene hin, nicht auf den Engineering-Aufwand des Projekts.
  • Ein nativer Token beweist keine Akzeptanz. Ein nativer Token ohne aktive Validatoren, ohne Nutzertransaktionen und ohne reale Nutzung ist technisch immer noch ein „nativer Token“. Die technische Klassifizierung ist nicht gleichbedeutend mit realem Nutzen.

Nicht verwechseln mit

  • ERC-20 und anderen Smart-Contract-Token – ERC-20-Token werden als Contracts auf einer bestehenden Chain bereitgestellt und sind für Gas vom nativen Token dieser Chain abhängig. Native Token existieren auf Protokollebene und hängen von keinem Smart Contract ab.
  • Token standard – das übergeordnete Konzept, das alle technischen Formate abdeckt (ERC-20, BEP-20, SPL, nativer Token). „Nativer Token“ ist eine Art von Token-Standard – diejenige, bei der der Token in die Chain selbst eingebaut ist.
  • Token model – das Token-Modell beschreibt die Rolle des Tokens (Utility, Governance, Staking, Gebührenmechanismus). Ein nativer Token kann jede dieser Rollen erfüllen. „Nativ“ beschreibt das technische Format; „Utility“ oder „Governance“ beschreibt die Funktion.
  • Wrapped native Token (WETH, WSOL) – einige Ökosysteme erstellen ERC-20-kompatible Wrapper um native Token, damit sie in Smart Contracts verwendet werden können, die die ERC-20-Schnittstelle benötigen. WETH ist eine ERC-20-Darstellung von ETH, nicht ETH selbst. Die Wrapped-Version folgt einem Smart-Contract-Standard; das Original bleibt ein nativer Token.
  • Gas-Token – manchmal werden native Token informell „Gas-Token“ genannt, weil sie zur Bezahlung von Gas verwendet werden. Aber „Gas-Token“ ist kein formaler Standard oder eine Klassifizierung – es ist eine Beschreibung einer der Funktionen des nativen Tokens.

Häufig gestellte Fragen

Warum können Gas-Gebühren nicht in einem beliebigen Token bezahlt werden?

Gas-Gebühren werden auf Protokollebene verarbeitet – von den Validatoren und dem Konsensmechanismus selbst, bevor irgendeine Smart-Contract-Logik ausgeführt wird. Das Protokoll ist so konzipiert, dass es nur den nativen Token für Gas akzeptiert, weil es eine einzige, zuverlässige Recheneinheit benötigt, um die Berechnung zu messen und Spam zu verhindern. Einige Netzwerke und Layer-2-Lösungen experimentieren mit Gebührenabstraktion (die es ermöglicht, Gas in anderen Token zu bezahlen), aber unter der Haube ist der native Token typischerweise immer noch an der endgültigen Abrechnung beteiligt.

Was ist der Unterschied zwischen einem nativen Token und einem Utility-Token?

„Nativer Token“ beschreibt das technische Format: Der Token ist in das Blockchain-Protokoll eingebaut. „Utility-Token“ beschreibt die wirtschaftliche Rolle: Der Token wird verwendet, um auf Dienste zuzugreifen, für die Nutzung zu bezahlen oder an der Funktionalität des Projekts teilzunehmen. Ein nativer Token kann auch ein Utility-Token sein – zum Beispiel ist TAO auf Bittensor sowohl der native Token des Bittensor-Netzwerks als auch ein Utility-Token, der zur Bezahlung von KI-Inferenz und zur Belohnung von Subnet-Teilnehmern verwendet wird. Die beiden Bezeichnungen beschreiben unterschiedliche Dimensionen desselben Tokens.

Kann ein Projekt sowohl einen nativen Token als auch ERC-20-Token haben?

Ja. Ein Projekt, das seine eigene Blockchain betreibt, hat einen nativen Token für diese Chain. Dasselbe Projekt könnte auch ERC-20-Token auf Ethereum für Bridging, Liquidität oder Cross-Chain-Kompatibilität ausgeben. Einige Projekte unterhalten ihren nativen Token auf ihrer eigenen Chain und eine Wrapped- oder Bridged-Version auf Ethereum oder anderen EVM-Chains. Dies sind technisch unterschiedliche Token (nativ vs. Smart Contract), die dasselbe zugrunde liegende Asset über Bridging-Mechanismen darstellen.

Externe Referenzen

Siehe auch

No comments to display

Back to top