BEP20

BEP-20 (spesso scritto BEP20) è uno standard tecnico per gli smart contract di token fungibili su BNB Smart Chain (BSC). «BEP» significa BNB Evolution Proposal e BEP-20 è una proposta di standard abilitata nel repository delle proposte di BNB Chain. Derivata dallo standard ERC-20 di Ethereum, la sua interfaccia definisce metodi ed eventi comuni per saldi, trasferimenti e spese delegate.

La fungibilità significa che le unità registrate da un singolo contratto di token sono intercambiabili, anziché essere individualmente distinte. Il contratto registra i saldi assegnati agli indirizzi e applica a ogni unità le stesse regole di trasferimento. BEP-20 specifica come i contratti compatibili espongono tali operazioni a portafogli, piattaforme di scambio, altri contratti e software di indicizzazione. Non prescrive la politica monetaria, la copertura, la governance, i privilegi amministrativi, il valore di mercato o la sicurezza di un token.

Interfaccia

Lo standard definisce i seguenti metodi pubblici:

Metodo	Funzione	Stato BEP-20
name()	Restituisce un nome del token leggibile	Facoltativo
symbol()	Restituisce il simbolo del token, simile a un ticker	Obbligatorio
decimals()	Restituisce la precisione decimale usata per la visualizzazione	Obbligatorio
totalSupply()	Restituisce l'offerta totale indicata dal contratto	Obbligatorio
balanceOf(address)	Restituisce il saldo assegnato a un indirizzo	Obbligatorio
transfer(address, uint256)	Trasferisce token dal chiamante a un altro indirizzo	Obbligatorio
approve(address, uint256)	Imposta l'importo che un soggetto autorizzato può utilizzare	Obbligatorio
allowance(address, address)	Restituisce l'importo autorizzato rimanente	Obbligatorio
transferFrom(address, address, uint256)	Trasferisce token mediante un'autorizzazione concessa in precedenza	Obbligatorio

I contratti compatibili emettono un evento Transfer per i trasferimenti e un evento Approval quando un'autorizzazione va a buon fine. I trasferimenti di valore zero sono validi ed emettono anch'essi Transfer. La specifica richiede che i chiamanti gestiscano un risultato booleano false, anziché presumere che ogni chiamata terminata normalmente sia riuscita.

Saldi, offerta e visualizzazione decimale

L'interfaccia contabilizza le quantità di token come numeri interi senza segno. Il valore decimals indica alle interfacce utente come ridimensionare tali unità di base per la visualizzazione. Se, per esempio, un contratto dichiara otto decimali, un saldo intero di 100.000.000 unità di base viene visualizzato come una unità di token. L'impostazione non crea frazioni nella memoria del contratto e non determina il valore di mercato del token.

totalSupply indica la quantità esistente secondo le regole del contratto, mentre balanceOf indica la quantità assegnata a un determinato indirizzo. Nessuno dei due metodi stabilisce come sia stata creata l'offerta. Un contratto può assegnare un'offerta iniziale fissa al momento della distribuzione oppure implementare ulteriore logica di conio o distruzione; tali politiche non fanno parte dell'interfaccia principale. La specifica afferma che la creazione di nuove unità dovrebbe emettere Transfer con l'indirizzo zero come origine, ma non richiede una funzione pubblica di conio.

Trasferimenti e autorizzazioni

Una richiesta diretta di transfer sposta un importo dal saldo del chiamante a un destinatario. Il contratto controlla e aggiorna il proprio stato ed emette l'evento standard. Un trasferimento di token è quindi una chiamata al contratto del token; è diverso dal trasferimento di BNB, l'asset nativo della rete.

La spesa delegata usa tre metodi. Per prima cosa, un proprietario chiama approve per impostare l'importo massimo utilizzabile da un soggetto autorizzato. Il software può leggere l'importo residuo con allowance. Il soggetto autorizzato chiama quindi transferFrom per spostare token dal saldo del proprietario, nei limiti dell'autorizzazione. Questo modello consente a un altro smart contract di agire con l'autorizzazione del titolare dei token senza ricevere il controllo dell'intero saldo.

Una nuova chiamata a approve sostituisce l'autorizzazione corrente; non vi si aggiunge. Le specifiche BEP-20 ed ERC-20 avvertono gli sviluppatori di client dei rischi del passaggio diretto da un'autorizzazione diversa da zero a un'altra, perché l'ordine delle transazioni può consentire l'uso di entrambi i valori. Raccomandano interfacce che impostino prima l'autorizzazione a zero e poi un nuovo valore diverso da zero. Un'autorizzazione concede facoltà di spesa; non trasferisce di per sé i token.

Eventi e interoperabilità

Le firme dei metodi, i tipi restituiti e gli eventi standard offrono alle applicazioni un modo comune di interagire con contratti di token diversi. Un'applicazione può usare l'Application Binary Interface (ABI) di un contratto per interrogare metadati, saldi, offerta e autorizzazioni o inviare chiamate standard di trasferimento e approvazione senza dipendere dalla struttura di archiviazione interna del contratto.

Gli eventi Transfer e Approval consentono a explorer, portafogli e indicizzatori di osservare le operazioni standard nei log delle transazioni. Gli eventi aiutano a ricostruire l'attività, ma saldi e autorizzazioni correnti possono comunque dipendere dall'implementazione e dallo stato esatti del contratto. Il software non dovrebbe presumere che metadati familiari o un evento emesso dimostrino l'identità o la qualità di un token.

Rapporto con ERC-20

BEP-20 conserva l'interfaccia principale di trasferimento e autorizzazione di ERC-20, permettendo al software compatibile con l'EVM di interagire in modo familiare. Una differenza nelle attuali specifiche scritte riguarda i metadati: ERC-20 considera facoltativi name, symbol e decimals, mentre BEP-20 richiede symbol e decimals ma mantiene facoltativo name.

Gli standard non definiscono il consenso, la capacità, le commissioni di transazione o il comportamento di conferma e finalità delle rispettive reti. Si tratta di proprietà delle blockchain sottostanti e delle loro configurazioni correnti. BSC è compatibile con l'EVM e il suo token nativo BNB viene usato per pagare le commissioni di transazione di BSC. La compatibilità EVM permette di riutilizzare molti strumenti e modelli di contratto orientati a Ethereum, ma non condivide automaticamente un contratto di token o i relativi saldi tra BSC ed Ethereum.

Usi e rappresentazione

I contratti BEP-20 possono contabilizzare unità intercambiabili di un'applicazione, peso di voto, unità di incentivo o accesso, diritti concepiti per seguire un altro asset o altre quantità fungibili. Sono ruoli scelti dall'implementazione e dall'applicazione circostante, non capacità distinte conferite dallo standard.

In particolare, l'interfaccia non verifica che un token sia coperto da un altro asset, rimborsabile, stabile nel prezzo, controllato da un processo decentralizzato o accettato da un servizio. Anche una rappresentazione wrapped o bridged dipende da meccanismi esterni a BEP-20 che la emettono e la riscattano. Lo standard rende riconoscibili soltanto le operazioni comuni del contratto del token.

Storia di BNB Beacon Chain

I primi materiali su BEP-20 includevano il collegamento cross-chain con asset BEP-2 su BNB Beacon Chain. BNB Chain ha ritirato Beacon Chain tramite il processo BNB Chain Fusion del 2024, con l'ultimo fork di dismissione a novembre e l'arresto dei validatori programmato per dicembre.

L'interfaccia precedente conteneva anche getOwner(), usato per collegare token BEP-20 e BEP-2. BNB Chain lo ha rimosso dall'attuale specifica BEP-20 con una modifica integrata il 12 febbraio 2025, poiché Beacon Chain non esisteva più. La documentazione o i modelli di contratto che definiscono ancora getOwner() un requisito BEP-20 descrivono il flusso ritirato, non l'interfaccia corrente.

Identità del token e selezione della rete

Un token BEP-20 distribuito è identificato da BNB Smart Chain e dall'indirizzo del suo contratto. Nomi e simboli sono metadati di visualizzazione e possono essere duplicati, perciò non bastano a stabilire che un contratto rappresenti l'asset desiderato. Il software di un portafoglio può richiedere all'utente di selezionare BSC e importare l'indirizzo esatto del contratto prima di mostrare un token.

BSC ed Ethereum usano formati di indirizzo compatibili, ma i saldi dei token esistono nei contratti di una rete specifica. L'invio tramite una rete non prevista non ha un unico esito: il recupero dipende dal fatto che il mittente o il destinatario controlli l'indirizzo di destinazione e dalla possibilità che un custode fornisca assistenza.

Estensioni e limiti di sicurezza

La conformità a BEP-20 non implica che ogni contratto di token si comporti nello stesso modo. Le implementazioni possono aggiungere conio, distruzione, sospensione, commissioni di trasferimento, liste di blocco, aggiornabilità o funzioni amministrative privilegiate. Nessuna di queste è richiesta dall'interfaccia BEP-20 principale e ciascuna modifica le ipotesi di sicurezza e fiducia del contratto.

L'interfaccia ereditata non prevede inoltre una callback obbligatoria con cui il contratto ricevente confermi di poter contabilizzare i token in arrivo. Un trasferimento standard all'indirizzo di un contratto può quindi riuscire anche quando il contratto ricevente non dispone di un meccanismo per usare o restituire tali token. Le applicazioni che accettano depositi di token necessitano di una gestione progettata esplicitamente, anziché presumere che ogni contratto destinatario sia compatibile.

La conformità non dimostra che il codice sorgente sia stato esaminato, che i metadati visualizzati siano veritieri, che le dichiarazioni sull'offerta o sulla copertura siano accurate, che le chiavi privilegiate siano sicure o che un'applicazione sia priva di rischi. Il contratto distribuito esatto, il suo bytecode e la sua configurazione, le facoltà degli amministratori e l'applicazione che vi interagisce devono essere valutati separatamente. BEP-20 standardizza l'interoperabilità a livello di interfaccia; non certifica un asset o un emittente.