BEP20

BEP-20 (häufig BEP20 geschrieben) ist ein technischer Standard für Smart Contracts fungibler Token auf der BNB Smart Chain (BSC). „BEP“ steht für BNB Evolution Proposal; BEP-20 ist ein aktivierter Standardvorschlag im Proposal-Repository der BNB Chain. Seine von Ethereums ERC-20-Standard abgeleitete Schnittstelle legt gemeinsame Methoden und Ereignisse für Guthaben, Übertragungen und delegierte Ausgaben fest.

Fungibilität bedeutet, dass die von einem Token-Contract erfassten Einheiten untereinander austauschbar und nicht individuell verschieden sind. Der Contract speichert den Adressen zugeordnete Guthaben und wendet auf jede Einheit dieselben Übertragungsregeln an. BEP-20 legt fest, wie kompatible Contracts diese Operationen für Wallets, Börsen, andere Contracts und Indexierungssoftware bereitstellen. Der Standard schreibt weder Geldpolitik, Deckung, Governance, Administratorrechte, Marktwert noch Sicherheit eines Tokens vor.

Schnittstelle

Der Standard definiert folgende öffentliche Methoden:

Methode	Zweck	BEP-20-Status
name()	Gibt einen menschenlesbaren Tokennamen zurück	Optional
symbol()	Gibt das tickerähnliche Symbol des Tokens zurück	Erforderlich
decimals()	Gibt die für die Anzeige verwendete Dezimalpräzision zurück	Erforderlich
totalSupply()	Gibt den vom Contract gemeldeten Gesamtbestand zurück	Erforderlich
balanceOf(address)	Gibt das einer Adresse zugeordnete Guthaben zurück	Erforderlich
transfer(address, uint256)	Überträgt Token vom Aufrufer an eine andere Adresse	Erforderlich
approve(address, uint256)	Legt den Betrag fest, über den ein Berechtigter verfügen darf	Erforderlich
allowance(address, address)	Gibt den verbleibenden genehmigten Betrag zurück	Erforderlich
transferFrom(address, address, uint256)	Überträgt Token auf Grundlage einer zuvor erteilten Berechtigung	Erforderlich

Kompatible Contracts geben bei Übertragungen ein Transfer-Ereignis und nach erfolgreicher Genehmigung ein Approval-Ereignis aus. Übertragungen mit dem Wert null sind gültig und lösen ebenfalls Transfer aus. Die Spezifikation verlangt, dass Aufrufer einen booleschen Rückgabewert false verarbeiten, statt anzunehmen, jeder normal beendete Aufruf sei erfolgreich gewesen.

Guthaben, Bestand und Dezimalanzeige

Die Schnittstelle führt Tokenbeträge als vorzeichenlose Ganzzahlen. Der Wert decimals teilt Benutzeroberflächen mit, wie diese Basiseinheiten für die Anzeige zu skalieren sind. Meldet ein Contract beispielsweise acht Dezimalstellen, werden 100.000.000 Basiseinheiten als eine Tokeneinheit angezeigt. Die Einstellung erzeugt keine Bruchteile im Contract-Speicher und bestimmt nicht den Marktwert des Tokens.

totalSupply meldet die nach den Contract-Regeln existierende Menge, während balanceOf die einer bestimmten Adresse zugeordnete Menge zurückgibt. Keine der beiden Methoden legt fest, wie der Bestand entstanden ist. Ein Contract kann bei der Bereitstellung einen festen Anfangsbestand zuweisen oder zusätzliche Präge- und Verbrennungslogik implementieren; diese Regeln liegen außerhalb der Kern-Schnittstelle. Laut Spezifikation soll die Erzeugung neuer Einheiten ein Transfer-Ereignis mit der Nulladresse als Quelle auslösen, eine öffentliche Mint-Funktion ist jedoch nicht vorgeschrieben.

Übertragungen und Berechtigungen

Eine direkte transfer-Anforderung verschiebt einen Betrag vom Guthaben des Aufrufers zu einem Empfänger. Der Contract prüft und aktualisiert seinen eigenen Zustand und gibt das Standardereignis aus. Eine Tokenübertragung ist daher ein Aufruf des Token-Contracts; sie unterscheidet sich von der Übertragung von BNB, dem nativen Vermögenswert des Netzwerks.

Delegierte Ausgaben verwenden drei Methoden. Zunächst ruft ein Eigentümer approve auf, um den Höchstbetrag festzulegen, den ein Berechtigter verwenden darf. Software kann den verbleibenden Betrag mit allowance abfragen. Anschließend ruft der Berechtigte transferFrom auf, um innerhalb dieser Genehmigung Token aus dem Guthaben des Eigentümers zu übertragen. Dieses Muster ermöglicht es einem anderen Smart Contract, im Rahmen der Genehmigung eines Tokeninhabers zu handeln, ohne die Kontrolle über dessen gesamtes Guthaben zu erhalten.

Ein erneuter Aufruf von approve ersetzt die bestehende Berechtigung; er erhöht sie nicht. Die BEP-20- und ERC-20-Spezifikationen warnen Client-Entwickler davor, einen von null verschiedenen Wert unmittelbar in einen anderen zu ändern, weil die Transaktionsreihenfolge die Nutzung beider Werte ermöglichen kann. Sie empfehlen Benutzeroberflächen, die die Berechtigung zunächst auf null und erst danach auf einen neuen Wert ungleich null setzen. Eine Genehmigung erteilt eine Ausgabebefugnis; sie überträgt selbst keine Token.

Ereignisse und Interoperabilität

Die standardisierten Methodensignaturen, Rückgabetypen und Ereignisse bieten Anwendungen eine gemeinsame Art der Interaktion mit unterschiedlichen Token-Contracts. Über die Application Binary Interface (ABI) eines Contracts kann eine Anwendung Metadaten, Guthaben, Bestand und Berechtigungen abfragen oder standardisierte Übertragungs- und Genehmigungsaufrufe senden, ohne vom internen Speicheraufbau des Contracts abhängig zu sein.

Die Ereignisse Transfer und Approval ermöglichen Explorern, Wallets und Indexern, Standardoperationen in Transaktionsprotokollen zu beobachten. Ereignisse helfen bei der Rekonstruktion von Aktivitäten; aktuelle Guthaben und Berechtigungen können jedoch weiterhin von der genauen Implementierung und dem Zustand des Contracts abhängen. Software sollte nicht davon ausgehen, dass vertraute Metadaten oder ein ausgegebenes Ereignis die Identität oder Qualität eines Tokens belegen.

Verhältnis zu ERC-20

BEP-20 übernimmt die grundlegende Übertragungs- und Berechtigungsschnittstelle von ERC-20, sodass EVM-kompatible Software auf vertraute Weise damit interagieren kann. Ein Unterschied in den derzeitigen schriftlichen Spezifikationen betrifft Metadaten: ERC-20 behandelt name, symbol und decimals als optional, während BEP-20 symbol und decimals verlangt, name jedoch optional lässt.

Die Standards definieren weder Konsens, Kapazität, Transaktionsgebühren noch Bestätigungs- und Finalitätsverhalten ihrer Netzwerke. Dies sind Eigenschaften der zugrunde liegenden Blockchains und ihrer jeweiligen Konfiguration. BSC ist EVM-kompatibel; der native BNB-Token wird zur Zahlung der BSC-Transaktionsgebühren verwendet. Die EVM-Kompatibilität erlaubt die Wiederverwendung vieler auf Ethereum ausgerichteter Werkzeuge und Contract-Muster, führt jedoch nicht automatisch dazu, dass ein Token-Contract oder seine Guthaben von BSC und Ethereum gemeinsam genutzt werden.

Verwendungen und Repräsentation

BEP-20-Contracts können austauschbare Anwendungseinheiten, Stimmgewicht, Anreiz- oder Zugangseinheiten, Ansprüche zur Abbildung eines anderen Vermögenswerts oder andere fungible Größen verbuchen. Diese Rollen werden von der Implementierung und der sie umgebenden Anwendung bestimmt; es handelt sich nicht um eigenständige Fähigkeiten des Standards.

Insbesondere prüft die Schnittstelle nicht, ob ein Token durch einen anderen Vermögenswert gedeckt, einlösbar, wertstabil, dezentral gesteuert oder von einem Dienst akzeptiert wird. Auch eine Wrapped- oder Bridged-Repräsentation hängt von Mechanismen außerhalb von BEP-20 ab, die sie ausgeben und einlösen. Der Standard macht lediglich die gemeinsamen Operationen des Token-Contracts erkennbar.

Geschichte der BNB Beacon Chain

Frühes BEP-20-Material umfasste die kettenübergreifende Bindung an BEP-2-Vermögenswerte auf der BNB Beacon Chain. BNB Chain stellte die Beacon Chain im Rahmen des BNB-Chain-Fusion-Prozesses von 2024 ein; der letzte Sunset-Fork erfolgte im November, die Abschaltung der Validatoren war für Dezember vorgesehen.

Die frühere Schnittstelle enthielt außerdem getOwner(), das zur Bindung von BEP-20- und BEP-2-Token diente. BNB Chain entfernte es aus der aktuellen BEP-20-Spezifikation durch eine am 12. Februar 2025 zusammengeführte Änderung, weil die Beacon Chain nicht mehr existierte. Dokumentation oder Contract-Vorlagen, die getOwner() weiterhin als BEP-20-Anforderung bezeichnen, beschreiben den eingestellten Ablauf und nicht die aktuelle Schnittstelle.

Tokenidentität und Netzwerkauswahl

Ein bereitgestellter BEP-20-Token wird durch die BNB Smart Chain und seine Contract-Adresse identifiziert. Namen und Symbole sind Anzeigemetadaten und können mehrfach vorkommen; daher reichen sie nicht aus, um zu belegen, dass ein Contract den beabsichtigten Vermögenswert darstellt. Bei Wallet-Software kann es erforderlich sein, BSC auszuwählen und die genaue Contract-Adresse zu importieren, bevor ein Token angezeigt wird.

BSC und Ethereum verwenden kompatible Adressformate, Token-Guthaben bestehen jedoch in Contracts eines bestimmten Netzwerks. Das Senden über ein unbeabsichtigtes Netzwerk hat kein allgemeingültiges Ergebnis: Eine Wiederherstellung hängt davon ab, ob Absender oder Empfänger die Zieladresse kontrollieren und ob eine Verwahrstelle helfen kann.

Erweiterungen und Sicherheitsgrenzen

Die BEP-20-Konformität bedeutet nicht, dass sich jeder Token-Contract gleich verhält. Implementierungen können Prägung, Verbrennung, Pausierung, Übertragungsgebühren, Sperrlisten, Aufrüstbarkeit oder privilegierte Administratorfunktionen ergänzen. Keine davon ist für die BEP-20-Kernschnittstelle vorgeschrieben; jede verändert die Sicherheits- und Vertrauensannahmen des Contracts.

Die übernommene Schnittstelle besitzt außerdem keinen obligatorischen Callback, mit dem ein empfangender Contract bestätigt, dass er eingehende Token verbuchen kann. Eine Standardübertragung an eine Contract-Adresse kann daher erfolgreich sein, obwohl der empfangende Contract über keinen Mechanismus verfügt, um die Token zu verwenden oder zurückzugeben. Anwendungen, die Tokeneinzahlungen annehmen, benötigen ein ausdrücklich vorgesehenes Verfahren und dürfen nicht voraussetzen, dass jeder Contract-Empfänger kompatibel ist.

Konformität belegt weder, dass der Quellcode geprüft wurde, noch dass angezeigte Metadaten wahrheitsgemäß, Angaben zu Bestand oder Deckung zutreffend, privilegierte Schlüssel sicher oder eine Anwendung gefahrlos sind. Der genaue bereitgestellte Contract, sein Bytecode und seine Konfiguration, Administratorbefugnisse und die interagierende Anwendung müssen separat beurteilt werden. BEP-20 standardisiert die Interoperabilität auf Schnittstellenebene; es ist keine Zertifizierung eines Vermögenswerts oder Emittenten.