Permessi di mint e burn

EN fonte principale · P08-L03 · 45 minuti stimati · needs_review

«Mint disabilitato» e «burn abilitato» sembrano semplici, ma descrivono operazioni specifiche secondo regole specifiche di autorizzazione. Un detentore che distrugge le proprie unità è diverso da un amministratore che influenza il saldo di un altro detentore. Un limite massimo vincola la quantità soltanto se il percorso pertinente lo applica effettivamente.

Il compito è enumerare capacità che cambiano l’offerta, condizioni e ambito. Valuti permessi, non insegni emissione di token né prevedi se un’autorità agirà.

Chiedere chi può fare cosa a quale saldo

Un record di permesso dovrebbe nominare operazione, account o ruolo di controllo, ambito obiettivo, vincoli di quantità e modificabilità. «Amministratore presente» omette le informazioni più utili. Emettere a un destinatario, distruggere il proprio saldo e distruggere il saldo di un terzo sono capacità diverse.

Per ogni percorso chiedere se il controllo riguardi chiamante, allowance, ruolo o condizione mediata dal programma. Registrare la condizione abbastanza letteralmente da riprodurre il ragionamento. Un nome di funzione non è la sua implementazione: un metodo chiamato burn potrebbe trasferire internamente unità e un metodo chiamato distribute potrebbe emetterle.

Usare una tabella di capacità con riferimenti probatori. Se un’operazione è stata osservata storicamente, sostiene quell’evento; non dimostra da sola ogni permesso presente. Se un permesso esiste in un’istantanea, sostiene disponibilità secondo condizioni; non dimostra che sia stato esercitato.

Distinguere percorsi standard di burn

Il burn standard Solana riduce saldo dell’account e offerta del mint. L’autorizzazione può provenire dal proprietario dell’account token o da un delegato approvato; la delega permanente del Token Extension Program aggiunge un percorso a livello di mint [S08-BURN]. Un’approvazione ordinaria è limitata all’account e importo pertinenti, quindi non descriverla come proprietà amministrativa generale.

L’estensione PermanentDelegate può autorizzare trasferimenti e burn tra account del suo mint; i proprietari degli account token non possono revocarla localmente [S08-DELEGATE]. Questo è un motivo concreto per esaminare lo stato delle estensioni anziché concludere che ogni autorità scompaia quando manca l’autorità di mint. Non inferire che l’estensione esista soltanto perché il token usa un programma capace di estensioni.

OpenZeppelin ERC20Burnable distingue distruzione del proprio saldo e burnFrom basato su allowance. Il comportamento con limite massimo vincola l’emissione secondo quell’implementazione [S08-OZERC20]. La documentazione della libreria sostiene questi schemi, non un risultato che un contratto distribuito particolare li includa. Esaminare codice e stato effettivi.

Trattare i limiti d’offerta come affermazioni condizionali

Un limite massimo ha unità e contesto. Un massimo di 1,200 token visualizzati con sei decimali rappresenta 1,200,000,000 unità grezze. Confrontare un totale corrente visualizzato con un limite grezzo può creare una stima falsa del margine residuo.

Il limite è significativo soltanto per percorsi che lo applicano. Se altri percorsi aggirano il controllo, o se un aggiornamento può cambiare la regola, riportare quei limiti. In questo materiale la regola fornita copre tutte le chiamate mint elencate secondo l’implementazione corrente. Le implementazioni future sono esplicitamente fuori dall’ipotesi di completezza dei percorsi.

I burn possono ridurre l’offerta totale e creare margine secondo un limite del totale esistente. Un limite d’emissione cumulativa è una policy diversa. Non presumere mai l’una dalla parola «limite». Dichiarare se la regola conti offerta esistente, emissione cumulativa, budget per epoca o altro.

Esaminare amministrazione dei ruoli

Appartenenza ai ruoli e amministrazione dei ruoli sono distinte. Un account capace di assegnare un ruolo di minter può creare indirettamente minter futuri anche se non può emettere con la propria appartenenza corrente. OpenZeppelin AccessControl usa controlli e amministrazione specifici del ruolo; Ownable è uno schema diverso [S08-ACCESS]. Un campo proprietario generico non può riassumere ogni percorso di autorizzazione.

Seguire la catena abbastanza da descrivere chi possa modificare il permesso. Se un amministratore è un contratto, firmatari, soglia e ritardo richiedono prove separate. Un’etichetta multisig non è prova della soglia. Se quei dettagli non sono disponibili, mantenere il ruolo del contratto e indicare sconosciuto il suo assetto di controllo.

Autorità che cambia l’offerta e autorità di aggiornamento sono correlate ma separate. Questa lezione identifica una lacuna fornita sull’aggiornamento; P08-L04 la analizza direttamente. Una conclusione «fisso secondo le regole correnti» non può diventare silenziosamente «fisso per sempre» quando la logica può cambiare.

Separare comportamento potenziale ed eventi completati

Un’operazione riuscita che cambia l’offerta richiede più di una transazione inviata o un’etichetta simile a un evento. Verificare risultato dell’esecuzione, asset interessato, variazione contabile e contesto. Tentativi falliti non vanno aggiunti all’offerta. Trasferimenti a un indirizzo inaccessibile possono ridurre inventario accessibile senza ridurre l’offerta totale del protocollo.

Nemmeno un burn verificato dice nulla sull’apprezzamento del prezzo. Quantità ed esecuzione di mercato sono misurazioni diverse. Analogamente, un privilegio disponibile di mint non è prova di intenzioni malevole. Un risultato professionale dichiara ambito e condizioni, poi chiede quali prove risolverebbero le lacune.

Scrivere un risultato circoscritto sui permessi

Preferire «A S0, M può aumentare l’offerta fino al limite del totale esistente secondo la regola corrente fornita; G può assegnare quel ruolo» a «il token è inflazionistico e insicuro». La prima è riproducibile; la seconda combina una classificazione economica indefinita con una raccomandazione priva di supporto.

Quando è fornita revoca, nominare il ruolo esatto. La rimozione dell’autorità Solana è specifica del ruolo [S08-SET]. Rimuovere un ruolo di mint non rimuove logicamente un delegato indipendente, ruolo di congelamento o percorso di cambiamento dell’implementazione.

• Permesso di mint: capacità di aumentare l’offerta contabile.
• Permesso di burn: capacità di ridurre saldi e offerta secondo una regola.
• Allowance: permesso limitato a un importo associato a detentore e soggetto spendente.
• Delegato permanente: autorità del Token Extension Program a livello di mint.
• Limite del totale esistente: offerta presente massima secondo la regola fornita.
• Amministratore del ruolo: account capace di cambiare l’appartenenza.

ILLUSTRATIVE — FIX-P08-03. Due asset fittizi separati a S0; le etichette sono invalide e non istruzioni d’esecuzione.

Il burn ipotetico di 40 di E3 precede un mint ipotetico di 220. H ha saldo sufficiente ed entrambe le operazioni riescono secondo le regole fornite. Non avvengono altri cambiamenti d’offerta.

OBSERVED nel materiale: MINT-P non ha autorità di mint ma ha D; TOKEN-C ha un percorso mint vincolato e amministratore del ruolo.

INFERRED: TOKEN-C ha margine iniziale del limite 200; dopo burn 40 ha 240, quindi mint 220 rientra e lascia totale 1,180.

UNKNOWN: L’umano che controlla D, comportamento omesso delle estensioni, controllo degli aggiornamenti TOKEN-C e cambiamenti futuri delle regole.

INSUFFICIENT EVIDENCE: Autorità di mint assente non dimostra che i saldi MINT-P non possano essere distrutti. Un limite non stabilisce policy d’offerta immutabile o un risultato di prezzo.

Equiparare revoca del mint e rimozione di tutti i privilegi; trattare burn proprio come burn arbitrario di terzi; ignorare percorsi di assegnazione dei ruoli; mescolare limiti grezzi/visualizzati; e presumere che i burn garantiscano apprezzamento.

Scrivere una tabella di capacità per S1/S2 ed E1–E4. Calcolare margine iniziale e dopo il burn e offerta finale. Valutare se G possa influenzare l’emissione futura e se J possa distruggere 100 da H secondo l’allowance fornita.

• Nominare operazione, obiettivo e condizione.
• Verificare unità degli importi e totale corrente.
• Distinguere ruolo corrente e amministrazione del ruolo.
• Esaminare estensioni pertinenti.
• Separare cambiamenti completati dell’offerta e poteri disponibili.
• Dichiarare percorsi irrisolti di cambiamento dell’implementazione.

I permessi sono capacità condizionali. Una revisione utile distingue creazione dell’offerta, distruzione dei saldi e potere di cambiare chi può agire.

Nessun ruolo mint non significa nessun altro controllo. Un limite richiede definizione e ambito di applicazione. Disponibilità dell’autorità non è prova di intenzione.

Creare due matrici separate dei permessi per MINT-P e TOKEN-C con attore,operazione,obiettivo,condizione e riga probatoria. Aggiungere aritmetica del limite corrente200→240→20 di margine residuo. Mostrare la lacuna degli aggiornamenti come sconosciuta, non assente.

Ambito illustrativo dell’autorità e limite dell’offerta esistente; nessun risultato su token distribuiti.

Usare SVG/HTML deterministici o grafici con alternative testuali, blu navy scuro/nero e accenti sobri ciano, blu elettrico e viola. Etichettare ogni quantità e incertezza. A 390px impilare i pannelli; verifica a 768px/desktop e RTL arabo restano lavoro futuro sulle risorse. Tenere gli identificatori in LTR e invariati assi fattuali/direzioni degli archi. Usare soltanto il marchio ufficiale BlockAssay fornito se viene aggiunto il marchio. Entrambi i record sono specifiche, non risorse consegnate.

Usare RADAR per lo scopo educativo circoscritto della lezione soltanto se sono verificati supporto della rete, identità esatta, campi e provenienza. Questo contenuto non afferma alcun endpoint runtime o capacità del fornitore. Usare il materiale offline incorporato senza accesso a pagamento. I dati mancanti restano sconosciuti; non sono necessari collegamento a wallet, firma di transazioni, lancio di token o operazioni dal vivo. Progressi nell’Academy, pagamenti e referral non cambiano mai le prove di Radar. Un Diagnostic Passport preserva osservazioni e limiti, non una previsione di prezzo o un certificato di sicurezza.

• Solana: distruggere token — Autorizzazione standard al burn ed effetto su saldo dell’account e offerta del mint. Verificato 2026-09-30.
• Delegato permanente Solana — Autorità di trasferimento/burn a livello di mint del Token Extension Program. Verificato 2026-09-30.
• OpenZeppelin 5.x ERC20 — Estensioni per burn, limite massimo e pausa; il comportamento della libreria non è prova del codice distribuito. Verificato 2026-09-30.
• Controllo degli accessi OpenZeppelin 5.x — Schemi di privilegi Ownable e basati su ruoli; esaminare l’autorizzazione effettivamente distribuita. Verificato 2026-09-30.
• Solana: impostare l’autorità — Cambiamenti e revoca specifici del ruolo; non un verdetto globale di sicurezza. Verificato 2026-09-30.

La documentazione sostiene meccanismi, non valori dei dataset fittizi. Tutti gli esempi e i record degli esercizi sono materiale originale ILLUSTRATIVE, fissato in questo file. S0/S1 sono etichette di contesto sintetiche; observedAt è null perché non è stata raccolta alcuna misurazione di un registro dal vivo o storico. Riesaminare documentazione e comportamento effettivamente distribuito prima di qualsiasi pubblicazione o integrazione.

P08-L04 dopo l’esercizio svolto e la revisione del quiz.