Permisos de emisión y quema

Máster de origen EN · P08-L03 · 45 minutos estimados · needs_review

«Emisión deshabilitada» y «quema habilitada» suenan simples, pero describen operaciones específicas bajo reglas específicas de autorización. Un tenedor que quema sus propias unidades es distinto de un administrador que afecta el saldo de otro tenedor. Un límite restringe la cantidad solo si la vía relevante lo aplica realmente.

Su tarea es enumerar capacidades, condiciones y alcance de cambios de suministro. Está evaluando permisos, no enseñando emisión de tokens ni prediciendo si una autoridad actuará.

Pregunte quién puede hacer qué y a qué saldo

Un registro de permiso debe nombrar operación, cuenta o rol controlador, alcance objetivo, restricciones de cantidad y posibilidad de cambio. «Administrador presente» omite la información más útil. Emitir para un destinatario, quemar el saldo propio y quemar el saldo de terceros son capacidades diferentes.

Para cada vía pregunte si la comprobación se refiere al llamante, a una autorización de gasto, a un rol o a una condición mediada por programa. Registre la condición con suficiente literalidad para reproducir el razonamiento. Un nombre de función no es su implementación: un método llamado burn podría transferir unidades internamente, y uno llamado distribute podría emitirlas.

Use una tabla de capacidades con referencias de evidencia. Si una operación se observó históricamente, respalda ese evento; por sí sola no prueba todos los permisos presentes. Si un permiso existe en una instantánea, respalda disponibilidad bajo condiciones; no prueba que se haya ejercido.

Distinga vías estándar de quema

La quema estándar de Solana reduce el saldo de cuenta y el suministro del mint. La autorización puede proceder del propietario de la cuenta de tokens o de un delegado aprobado; la delegación permanente del Token Extension Program añade una vía a nivel de mint [S08-BURN]. Una aprobación ordinaria está acotada a la cuenta y cantidad relevantes, así que no la describa como propiedad administrativa general.

La extensión PermanentDelegate puede autorizar transferencias y quemas entre cuentas de su mint; los propietarios de cuentas de tokens no pueden revocarla localmente [S08-DELEGATE]. Esta es una razón concreta para inspeccionar el estado de extensiones en lugar de concluir que desaparece toda autoridad cuando no hay autoridad de emisión. No infiera que la extensión existe solo porque el token usa un programa capaz de admitir extensiones.

OpenZeppelin ERC20Burnable distingue destrucción del saldo propio y burnFrom basado en autorización de gasto. El comportamiento con límite restringe la emisión bajo esa implementación [S08-OZERC20]. La documentación de la biblioteca respalda estos patrones, no un hallazgo de que algún contrato desplegado concreto los incluya. Inspeccione el código y estado reales.

Trate los límites de suministro como afirmaciones condicionales

Un límite tiene unidad y contexto. Un máximo de 1,200 tokens mostrados con seis decimales representa 1,200,000,000 unidades brutas. Comparar un total actual mostrado con un límite bruto puede crear una estimación falsa de capacidad restante.

El límite tiene significado solo para vías que lo aplican. Si otras vías eluden la comprobación, o una actualización puede cambiar la regla, informe de esos límites de alcance. En este conjunto de datos la regla suministrada cubre todas las llamadas de emisión listadas bajo la implementación actual. Las implementaciones futuras están explícitamente fuera del supuesto de vías completas.

Las quemas pueden reducir el suministro total y crear capacidad bajo un límite de total pendiente. Un límite de emisión acumulada de por vida es una política diferente. Nunca asuma uno por la palabra «límite». Indique si la regla cuenta suministro pendiente, emisión acumulada, un presupuesto por época o algo más.

Inspeccione la administración de roles

La pertenencia a un rol y su administración son distintas. Una cuenta capaz de otorgar un rol de emisor puede crear indirectamente futuros emisores aunque no pueda emitir bajo su pertenencia actual. OpenZeppelin AccessControl usa comprobaciones y administración específicas de roles; Ownable es otro patrón [S08-ACCESS]. Un campo genérico de propietario no puede resumir todas las vías de autorización.

Siga la cadena lo suficiente para describir quién puede alterar el permiso. Si un administrador es un contrato, sus firmantes, umbral y demora necesitan evidencia separada. Una etiqueta que dice multifirma no prueba el umbral. Si no están disponibles esos detalles, conserve el rol del contrato y marque su configuración de control como desconocida.

La autoridad que cambia suministro y la autoridad de actualización están relacionadas, pero son separadas. Esta lección identifica una laguna suministrada de actualización; P08-L04 la analiza directamente. Una conclusión de «fijo bajo reglas actuales» no puede convertirse silenciosamente en «fijo para siempre» cuando la lógica puede cambiar.

Separe comportamiento potencial y eventos completados

Una operación exitosa que cambia suministro requiere más que una transacción enviada o una etiqueta parecida a un evento. Compruebe resultado de ejecución, activo afectado, variación contable y contexto. Los intentos fallidos no deben sumarse al suministro. Las transferencias a una dirección inaccesible pueden reducir inventario accesible sin reducir el suministro total del protocolo.

Incluso una quema verificada no dice nada sobre apreciación del precio. Cantidad y ejecución de mercado son mediciones diferentes. Asimismo, un privilegio disponible de emisión no prueba intención maliciosa. Un hallazgo profesional declara alcance y condiciones y luego pregunta qué evidencia resolvería las lagunas.

Escriba un hallazgo acotado de permisos

Prefiera «En S0, M puede aumentar suministro hasta el límite de total pendiente bajo la regla actual suministrada; G puede otorgar ese rol» a «el token es inflacionario e inseguro». Lo primero es reproducible; lo segundo mezcla una clasificación económica indefinida con una recomendación no respaldada.

Cuando se suministre revocación, nombre el rol exacto. La eliminación de autoridad de Solana es específica de rol [S08-SET]. Eliminar un rol de emisión no elimina lógicamente un delegado independiente, un rol de congelación ni una vía de cambio de implementación.

• Permiso de emisión: capacidad de aumentar suministro contable.
• Permiso de quema: capacidad de reducir saldos y suministro bajo una regla.
• Autorización de gasto: permiso acotado por cantidad asociado a tenedor y gastador.
• Delegado permanente: autoridad a nivel de mint del Token Extension Program.
• Límite de suministro pendiente: máximo suministro presente bajo la regla suministrada.
• Administrador de rol: cuenta capaz de cambiar la pertenencia.

ILLUSTRATIVE — FIX-P08-03. Dos activos ficticios separados en S0; las etiquetas son inválidas y no son instrucciones de ejecución.

La quema hipotética de 40 de E3 precede a una emisión hipotética de 220. H tiene saldo suficiente y ambas operaciones tienen éxito bajo las reglas suministradas. No ocurren otros cambios de suministro.

OBSERVED en el conjunto de datos: MINT-P no tiene autoridad de emisión, pero tiene D; TOKEN-C tiene una vía restringida de emisión y administrador de rol.

INFERRED: TOKEN-C tiene 200 de capacidad inicial bajo el límite; tras quemar 40 tiene 240, por lo que emitir 220 cabe y deja total 1,180.

UNKNOWN: El humano que controla D, comportamiento de extensiones omitido, control de actualización de TOKEN-C y cambios futuros de reglas.

INSUFFICIENT EVIDENCE: La ausencia de autoridad de emisión no prueba que los saldos MINT-P no puedan quemarse. Un límite no establece política inmutable de suministro ni resultado de precio.

Equiparar revocación de emisión con eliminación de todo privilegio; tratar quema propia como quema arbitraria de terceros; ignorar vías de otorgamiento de roles; mezclar límites brutos/mostrados; y asumir que las quemas garantizan apreciación.

Escriba una tabla de capacidades para S1/S2 y E1–E4. Calcule capacidad inicial y posterior a quema y suministro final. Evalúe si G puede afectar emisiones futuras y si J puede quemar 100 de H bajo la autorización suministrada.

• Nombre operación, objetivo y condición.
• Verifique unidades de cantidad y total actual.
• Distinga rol actual de administración del rol.
• Inspeccione extensiones relevantes.
• Separe cambios completados de suministro de poderes disponibles.
• Declare vías de cambio de implementación sin resolver.

Los permisos son capacidades condicionales. Una revisión útil distingue creación de suministro, destrucción de saldo y poder de cambiar quién puede actuar.

No tener rol de emisión no significa no tener otros controles. Un límite necesita definición y alcance de aplicación. La disponibilidad de autoridad no es evidencia de intención.

Cree dos matrices separadas de permisos para MINT-P y TOKEN-C con actor, operación, objetivo, condición y fila de evidencia. Añada la aritmética del límite actual200→240→20 de capacidad restante. Muestre la laguna de actualización como desconocida, no ausente.

Alcance de autoridad y límite de suministro pendiente ilustrativos; sin hallazgo de token desplegado.

Use SVG/HTML deterministas o gráficos con alternativas textuales, azul marino oscuro/negro y cian, azul eléctrico y violeta moderados. Etiquete cada cantidad e incertidumbre. A 390px apile los paneles; la verificación a 768px/escritorio y RTL en árabe sigue siendo trabajo futuro de los recursos. Mantenga los identificadores LTR y los ejes/direcciones de aristas factuales sin cambios. Use solo la marca oficial BlockAssay proporcionada si se añade identidad de marca. Ambos registros son especificaciones, no recursos entregados.

Use RADAR para el propósito educativo acotado de la lección solo si se verifican la compatibilidad de la red, la identidad exacta, los campos y la procedencia. Este contenido no afirma ningún endpoint de runtime ni capacidad de proveedor. Use el conjunto de datos sin conexión incorporado sin acceso de pago. Los datos ausentes siguen siendo desconocidos; no se requiere conexión de cartera, firma de transacción, lanzamiento de tokens ni operación en vivo. El progreso, los pagos y las referencias de Academy nunca cambian la evidencia de Radar. Un Pasaporte de Diagnóstico conserva observaciones y límites, no una predicción de precios ni un certificado de seguridad.

• Solana: quemar tokens — Autorización de quema estándar y efecto sobre el saldo de cuenta y el suministro del mint. Revisado 2026-09-30.
• Solana: delegado permanente — Autoridad de transferencia/quema a nivel de mint del Token Extension Program. Revisado 2026-09-30.
• OpenZeppelin 5.x ERC20 — Extensiones de quema, límite y pausa; el comportamiento de la biblioteca no prueba el código desplegado. Revisado 2026-09-30.
• OpenZeppelin 5.x: control de acceso — Patrones de privilegios Ownable y basados en roles; inspeccionar la autorización efectivamente desplegada. Revisado 2026-09-30.
• Solana: establecer autoridad — Cambios y revocación específicos de roles; no un veredicto global de seguridad. Revisado 2026-09-30.

La documentación respalda mecanismos, no valores de conjuntos ficticios. Todos los ejemplos y registros de ejercicios son material original ILLUSTRATIVE, congelado en este archivo. S0/S1 son etiquetas de contexto sintéticas; observedAt es null porque no se recopiló ninguna medición de un registro de cadena en vivo ni histórico. Vuelva a revisar la documentación y el comportamiento efectivamente desplegado antes de cualquier publicación o integración.

P08-L04 después de revisar el ejercicio resuelto y el cuestionario.