Permissões de emissão e queima

Fonte mestra EN · P08-L03 · 45 minutos estimados · needs_review

“Emissão desabilitada” e “queima habilitada” parecem simples, mas descrevem operações específicas sob regras específicas de autorização. Um detentor queimando suas próprias unidades é diferente de um administrador afetando o saldo de outro detentor. Um limite restringe quantidade somente se o caminho relevante realmente o aplica.

Sua tarefa é enumerar capacidades, condições e escopo de alteração da oferta. Você avalia permissões, não ensina emissão de tokens nem prevê se uma autoridade agirá.

Pergunte quem pode fazer o quê a qual saldo

Um registro de permissão deve nomear operação, conta ou papel controlador, escopo do destino, restrições de quantidade e possibilidade de mudança. “Administrador presente” omite a informação mais útil. Emitir para um destinatário, queimar o próprio saldo e queimar saldo de terceiro são capacidades distintas.

Para cada caminho, pergunte se a verificação diz respeito ao chamador, a uma allowance, a um papel ou a uma condição mediada por programa. Registre a condição com literalidade suficiente para reproduzir o raciocínio. Um nome de função não é sua implementação: um método chamado burn pode transferir unidades internamente, e um método chamado distribute pode emiti-las.

Use uma tabela de capacidades com referências de evidência. Se uma operação foi observada historicamente, isso sustenta aquele evento; não prova sozinho toda permissão atual. Se uma permissão existe em um retrato, isso sustenta disponibilidade sob condições; não prova que tenha sido exercida.

Distinga caminhos padrão de queima

A queima padrão da Solana reduz saldo da conta e oferta do mint. A autorização pode vir do proprietário da conta de token ou de delegado aprovado; delegação permanente do Token Extension Program acrescenta um caminho no nível do mint [S08-BURN]. Uma aprovação comum tem escopo da conta e quantidade relevantes, portanto não a descreva como propriedade administrativa geral.

A extensão PermanentDelegate pode autorizar transferências e queimas entre contas de seu mint; proprietários de contas de token não podem revogá-la localmente [S08-DELEGATE]. Essa é uma razão concreta para inspecionar estado de extensões em vez de concluir que toda autoridade desaparece quando a autoridade de emissão está ausente. Não infira que a extensão existe apenas porque o token usa um programa compatível com extensões.

OpenZeppelin ERC20Burnable distingue destruição do próprio saldo de burnFrom baseado em allowance. O comportamento Capped restringe emissão sob aquela implementação [S08-OZERC20]. Documentação da biblioteca sustenta esses padrões, não uma conclusão de que qualquer contrato implantado específico os inclui. Inspecione código e estado reais.

Trate limites de oferta como afirmações condicionais

Um limite tem unidade e contexto. Um máximo de 1,200 tokens exibidos com seis casas decimais representa 1,200,000,000 unidades brutas. Comparar total atual exibido com limite bruto pode criar estimativa falsa de margem.

O limite só tem significado para caminhos que o aplicam. Se outros caminhos contornam a verificação, ou se uma atualização pode mudar a regra, relate esses limites. Neste conjunto de dados, a regra fornecida cobre todas as chamadas de emissão listadas sob a implementação atual. Implementações futuras estão explicitamente fora da premissa de caminhos completos.

Queimas podem reduzir oferta total e criar margem sob um limite do total existente. Um limite de emissão ao longo da vida é uma política diferente. Nunca suponha um a partir da palavra “limite”. Declare se a regra conta oferta existente, emissão cumulativa, orçamento de uma época ou outra coisa.

Inspecione administração de papéis

Participação em um papel e administração do papel são distintas. Uma conta capaz de conceder papel de emissor pode criar indiretamente emissores futuros, mesmo que não possa emitir sob sua participação atual. OpenZeppelin AccessControl usa verificações e administração específicas de papéis; Ownable é outro padrão [S08-ACCESS]. Um campo genérico owner não pode resumir todos os caminhos de autorização.

Siga a cadeia suficientemente para descrever quem pode alterar a permissão. Se um administrador é um contrato, seus signatários, limiar e atraso precisam de evidência separada. Um rótulo multisig não prova limiar. Se esses detalhes estão indisponíveis, preserve o papel do contrato e marque sua estrutura de controle como desconhecida.

Autoridade que altera oferta e autoridade de atualização são relacionadas, mas separadas. Esta lição identifica uma lacuna de atualização fornecida; P08-L04 a analisa diretamente. Uma conclusão “fixa sob regras atuais” não pode se tornar silenciosamente “fixa para sempre” quando a lógica pode mudar.

Separe comportamento potencial de eventos concluídos

Uma operação bem-sucedida que altera oferta exige mais que transação submetida ou rótulo semelhante a evento. Verifique resultado de execução, ativo afetado, variação contábil e contexto. Tentativas malsucedidas não devem ser adicionadas à oferta. Transferências para um endereço inacessível podem reduzir estoque acessível sem reduzir oferta total do protocolo.

Mesmo uma queima verificada nada diz sobre valorização. Quantidade e execução de mercado são medições distintas. Da mesma forma, privilégio de emissão disponível não prova intenção maliciosa. Uma conclusão profissional declara escopo e condições e depois pergunta qual evidência resolveria as lacunas.

Escreva uma conclusão delimitada de permissão

Prefira “Em S0, M pode aumentar oferta até o limite do total existente sob a regra atual fornecida; G pode conceder esse papel” a “o token é inflacionário e inseguro”. A primeira é reproduzível; a segunda combina classificação econômica indefinida com recomendação sem suporte.

Quando revogação é fornecida, nomeie o papel exato. A remoção de autoridade Solana é específica do papel [S08-SET]. Remover papel de emissão não remove logicamente delegado independente, papel de congelamento ou caminho de alteração da implementação.

• Permissão de emissão: capacidade de aumentar oferta contábil.
• Permissão de queima: capacidade de reduzir saldos e oferta sob uma regra.
• Allowance: permissão delimitada por quantidade associada a detentor e gastador.
• Delegado permanente: autoridade do Token Extension Program no nível do mint.
• Limite do total existente: oferta presente máxima sob a regra fornecida.
• Administrador de papel: conta capaz de mudar participação.

ILLUSTRATIVE — FIX-P08-03. Dois ativos fictícios separados em S0; rótulos são inválidos e não são instruções de execução.

A queima hipotética de 40 em E3 precede emissão hipotética de 220. H tem saldo suficiente e ambas as operações têm sucesso sob regras fornecidas. Nenhuma outra mudança de oferta ocorre.

OBSERVED no conjunto de dados: MINT-P não tem autoridade de emissão, mas tem D; TOKEN-C tem caminho restrito de emissão e administrador de papel.

INFERRED: TOKEN-C tem margem inicial de 200; após queimar 40 tem 240, portanto emitir 220 cabe e deixa total 1,180.

UNKNOWN: Humano que controla D, comportamento de extensões omitido, controle de atualização de TOKEN-C e futuras mudanças de regras.

INSUFFICIENT EVIDENCE: Autoridade de emissão ausente não prova que saldos MINT-P não possam ser queimados. Um limite não estabelece política imutável de oferta nem resultado de preço.

Igualar revogação de emissão à remoção de todo privilégio; tratar queima própria como queima arbitrária de terceiros; ignorar caminhos de concessão de papéis; misturar limites brutos/exibidos; supor que queimas garantem valorização.

Escreva tabela de capacidades para S1/S2 e E1–E4. Calcule margem inicial, margem após queima e oferta final. Avalie se G pode afetar emissão futura e se J pode queimar 100 de H sob a allowance fornecida.

• Nomeie operação, destino e condição.
• Verifique unidades da quantidade e total atual.
• Distinga papel atual de administração de papel.
• Inspecione extensões relevantes.
• Separe mudanças de oferta concluídas de poderes disponíveis.
• Declare caminhos de mudança de implementação não resolvidos.

Permissões são capacidades condicionais. Uma revisão útil distingue criação de oferta, destruição de saldo e poder de mudar quem pode agir.

Ausência de papel de emissão não significa ausência de outros controles. Um limite precisa de definição e escopo de aplicação. Disponibilidade de autoridade não é evidência de intenção.

Crie duas matrizes de permissão separadas para MINT-P e TOKEN-C com ator,operação,destino,condição e linha de evidência. Adicione aritmética atual do limite200→240→20 de margem restante. Mostre a lacuna de atualização como desconhecida, não ausente.

Escopo de autoridade e limite da oferta existente ilustrativos; nenhuma conclusão sobre token implantado.

Use SVG/HTML determinístico ou gráficos com alternativas textuais, azul-marinho escuro/preto e ciano, azul elétrico e violeta discretos. Rotule cada quantidade e incerteza. Em 390px empilhe painéis; a verificação em 768px/desktop e RTL árabe permanece trabalho futuro dos recursos visuais. Mantenha identificadores em LTR e eixos factuais/direções das arestas inalterados. Use apenas a marca oficial BlockAssay fornecida se identidade visual for adicionada. Ambos os registros são especificações, não recursos entregues.

Use RADAR para o propósito educacional delimitado da lição somente se suporte à rede, identidade exata, campos e procedência forem verificados. Nenhum endpoint de runtime ou capacidade de provedor é afirmado por este conteúdo. Use o conjunto de dados offline incorporado sem acesso pago. Dados ausentes permanecem desconhecidos; nenhuma conexão de carteira, assinatura de transação, lançamento de token ou operação ao vivo é necessária. Progresso na Academy, pagamentos e indicações nunca mudam evidências do Radar. Um Passaporte Diagnóstico preserva observações e limites, não uma previsão de preço ou certificado de segurança.

• Queimar tokens na Solana — Autorização de queima padrão e efeito sobre o saldo da conta e a oferta do mint. Verificada em 2026-09-30.
• Delegado permanente da Solana — Autoridade de transferência/queima no nível do mint no Token Extension Program. Verificada em 2026-09-30.
• OpenZeppelin 5.x ERC20 — Extensões de queima, limite e pausa; comportamento da biblioteca não é prova do código implantado. Verificada em 2026-09-30.
• Controle de acesso OpenZeppelin 5.x — Padrões Ownable e de privilégios baseados em papéis; inspecionar a autorização realmente implantada. Verificada em 2026-09-30.
• Definir autoridade na Solana — Mudanças e revogação específicas de cada papel; não é veredito global de segurança. Verificada em 2026-09-30.

A documentação apoia mecanismos, não valores fictícios do conjunto de dados. Todos os exemplos e registros dos exercícios são material ILLUSTRATIVE original, fixado neste arquivo. S0/S1 são rótulos de contexto sintéticos; observedAt é null porque nenhuma medição de registro ao vivo ou histórico foi coletada. Revise novamente a documentação e o comportamento realmente implantado antes de qualquer publicação ou integração.

P08-L04 após o exercício resolvido e a revisão do quiz.