Solana SIMD 547: Una Tarifa Base Basada en Recursos que se Quema Completamente — Potencialmente Añadiendo Más de 1,500 SOL en Quemas Diarias
Solana SIMD 547: Una Tarifa Base Basada en Recursos que se Quema Completamente — Potencialmente Añadiendo Más de 1,500 SOL en Quemas Diarias
El diseño de Solana de "tarifas bajas, alto rendimiento" le ha ayudado a convertirse en un lugar principal para el trading en cadena, aplicaciones de consumo y pagos en tiempo real. Pero a medida que la actividad económica de la red escala, una pregunta recurrente surge en el mercado de criptomonedas en general: ¿debería SOL capturar más valor del uso intensivo en recursos, sin dañar la experiencia de usuario que hizo a Solana competitiva en primer lugar?
Una nueva propuesta comunitaria, SIMD 547, explora una posible respuesta: introducir una tarifa base basada en recursos, valorada por "unidades de costo", y quemar esa tarifa por completo. La idea está ganando atención porque se dirige directamente a la tokenomía de SOL — específicamente a la brecha entre la quema de tarifas relativamente pequeña de hoy y la emisión continua de la red.
A continuación, se presenta lo que propone la propuesta, por qué es importante y qué podría significar para los desarrolladores, traders y usuarios comunes.
1) Por Qué la Quema de Tarifas de Solana Se Siente "Demasiado Pequeña" Hoy
Bajo el modelo de tarifas actual de Solana, el costo de la transacción es en general:
- Tarifa base (basada en firmas; actualmente 5,000 lamports por firma), más
- Tarifa de priorización (opcional; establecida a través de instrucciones de presupuesto de cómputo). Todavía pagas tarifas incluso si una transacción falla. Ver la Documentación de la estructura de tarifas de Solana. (solana.com)
Crucial para la tokenomía:
- El 50% de la tarifa base se quema, y el otro 50% va al validador que produce el bloque.
- El 100% de la tarifa de priorización va a los validadores (no se quema nada). Los detalles también se resumen en la misma documentación de la estructura de tarifas. (solana.com)
En la discusión de SIMD 547, el proponente argumenta que la quema actual de tarifas base es económicamente minúscula, estimando aproximadamente 648 SOL/día quemados por el mecanismo de tarifa base con supuestos de alto rendimiento — insignificante frente a un ritmo de inflación citado de ~60,000 SOL/día. (github.com)
Esta brecha es la motivación: si SOL está destinado a reflejar la actividad de la red, algunos miembros de la comunidad quieren que la dinámica de quema del protocolo escale más con el consumo real de recursos, no solo con las firmas.
2) Qué Propone SIMD 547 (En Lenguaje Sencillo)
La sugerencia central de SIMD 547 es sencilla:
- A cada transacción ya se le asigna un "costo" estimado basado en múltiples dimensiones de recursos (no solo cómputo).
- Añadir una nueva tarifa base calculada a partir de ese costo, fijada en: 0.1 lamport por unidad de costo solicitada, y quemar el 100% de ella. (github.com)
Si necesitas un rápido recordatorio, un lamport es la unidad más pequeña de SOL (1 lamport = 0.000000001 SOL). Ver la referencia de terminología de Solana para lamport. (solana.com)
"Unidades de Costo" vs "Unidades de Cómputo"
Muchos usuarios están familiarizados con las unidades de cómputo porque aparecen en la ajuste de las tarifas de prioridad. Pero el "costo" en el programador de Solana es más amplio: tiene en cuenta elementos como bloqueos de escritura y el tamaño de los datos de las cuentas cargadas, no solo el cómputo. Esto se refleja en la explicación de tarifas y programación del protocolo en la documentación de la estructura de tarifas (ver cómo se usa "costo" en la programación de transacciones). (solana.com)
En el hilo de SIMD 547, el autor también enfatiza que las unidades de costo incluyen el cómputo más otros recursos solicitados implícitamente (datos cargados, heap, bloqueos de escritura y más). (github.com)
3) Impacto Esperado de la Quema: "Significativo, Pero No Mágico"
Uno de los puntos más discutidos es cuánto SOL adicional se quemaría realmente.
En el hilo, un miembro de la comunidad compartió agregados recientes de límites de unidades de cómputo solicitadas por día, concluyendo que —al nivel de uso actual— el mecanismo probablemente resultaría en una quema adicional de alrededor de 1,500–1,800 SOL/día, con la posibilidad de más durante la demanda máxima. (github.com)
Esto es materialmente mayor que la quema actual de tarifas base, pero aún no es suficiente por sí solo para "convertir" a Solana en un activo confiablemente deflacionario en condiciones normales — especialmente si las tarifas más altas reducen la demanda. Esa compensación es central en el debate.
4) ¿Quién Paga Más? Creadores vs. Usuarios Minoristas (Y Por Qué le Importa la Propuesta)
Un objetivo clave de diseño es evitar romper la estructura del mercado de alta frecuencia mientras se sigue cobrando más por las transacciones intensivas en recursos.
En el documento de SIMD 547, el proponente argumenta que muchas actualizaciones de alta frecuencia (a menudo asociadas con creadores/actualizaciones de oráculos) tienden a solicitar relativamente pocas unidades de costo, por lo que la tarifa adicional podría limitarse a un aumento porcentual de un solo dígito bajo en esos flujos de trabajo. (github.com)
Sin embargo, para usuarios comunes que actualmente envían transacciones con tarifas de prioridad bajas o nulas, el aumento relativo puede parecer dramático. El hilo incluye ejemplos que muestran saltos porcentuales de tres dígitos, incluido un escenario con un aumento de +639% al pasar de una transacción con tarifa mínima a una que también paga la nueva tarifa de quema basada en recursos. (github.com)
Conclusión práctica
- Si ya dependes de tarifas de prioridad (por ejemplo, trading competitivo), el impacto incremental puede ser modesto en términos porcentuales.
- Si típicamente envías transacciones "baratas" (especialmente en contextos de baja urgencia), tu sensibilidad al costo podría ser mayor.
Es por esto que la propuesta es controvertida: mejora la acumulación de valor para los tenedores de SOL a través de la quema, pero también podría remodelar la experiencia de usuario "por defecto barata" que muchos usuarios asocian con Solana.
5) La Dependencia de Alpenglow: Por Qué el Momento Importa
SIMD 547 no está planteado como algo que se pueda activar inmediatamente.
La discusión señala explícitamente que los costos de votación de los validadores importan hasta que se active Alpenglow, y se asume que el mecanismo se activará después de Alpenglow. (github.com)
Alpenglow en sí mismo es una propuesta importante de rediseño de consenso, formalizada como SIMD 0326, que reemplaza el consenso actual basado en Proof-of-History + TowerBFT con Alpenglow (Votor) para un mejor rendimiento y resiliencia. Ver el documento SIMD 0326. (github.com)
Así que, en la práctica, SIMD 547 se lee mejor como parte de una hoja de ruta más amplia: primero cambiar el consenso y las mecánicas de voto, luego revisar las perillas de tokenomía que serían dolorosas bajo las suposiciones actuales.
6) Preguntas Abiertas Que Probablemente Debatirará la Comunidad
Incluso los partidarios suelen estar de acuerdo en que los detalles importan. Basándose en el hilo y las mecánicas de tarifas actuales de Solana, esperen debates sobre:
- Recursos solicitados vs. utilizados: cobrar por el "costo solicitado" es simple y predecible, pero puede sobrecobrar a transacciones mal configuradas (similar a cómo las tarifas de prioridad dependen del límite de unidades de cómputo solicitadas). (solana.com)
- Experiencia de usuario a nivel de aplicación: las billeteras y dApps pueden necesitar una mejor estimación de tarifas y desglose más claro ("cuánto es para quema, cuánto para propina, cuánto para base").
- Economía de spam y DoS: una quema más fuerte podría disuadir ciertos patrones abusivos, pero también puede penalizar casos de uso legítimos de alta complejidad (enrutamiento DeFi, interacciones avanzadas de programas).
- Tokenomía vs adopción: en 2025-2026, la tendencia de la industria ha sido hacia mercados de tarifas más sostenibles y una captura de valor más clara — pero las redes que se exceden pueden empujar la actividad hacia alternativas.
Para los lectores que desean la discusión principal, el mejor punto de partida es el hilo comunitario original de SIMD 547. (github.com)
7) Qué Pueden Hacer Ahora los Usuarios y Constructores
Aunque SIMD 547 todavía está en discusión y no está activo, es un buen momento para prepararse:
Para equipos de dApp
- Auditen transacciones que habitualmente solicitan límites altos "por si acaso". La documentación de Solana explica cómo las tarifas de prioridad dependen de los límites de unidades de cómputo solicitadas en la documentación de la estructura de tarifas. (solana.com)
- Rastrear con qué frecuencia sus usuarios dependen de flujos de "sin tarifa de prioridad"; estos son los más expuestos a un nuevo componente de quema obligatoria.
Para traders y usuarios avanzados
- Si ejecutan automatizaciones, comiencen a modelar las tarifas como (tarifa base de firma + tarifa de prioridad + posible quema basada en recursos), en lugar de tratar la quema como un error de redondeo.
- Si agrupan acciones, consideren si transacciones menos pero más pesadas se volverían menos atractivas que interacciones más granulares.
Para todos: la autocustodia sigue siendo importante
Los debates sobre mecánicas de tarifas y tokenomía tienden a aumentar la experimentación en cadena (nuevos enrutamientos, nuevas estrategias de MEV, nuevos bots). Es también cuando aumentan las estafas de phishing y las aprobaciones maliciosas.
Si conservas SOL a largo plazo o interactúas frecuentemente con DeFi de Solana, una billetera de hardware como OneKey puede ayudar manteniendo las claves privadas fuera de línea y requiriendo aprobaciones explícitas de transacciones — útil cuando la composición de transacciones (y los desglose de tarifas) se vuelven más complejas.
Conclusión
SIMD 547 es una propuesta centrada en la tokenomía que intenta navegar una aguja difícil: aumentar la quema de SOL de una manera que escale con el consumo de recursos, evitando al mismo tiempo un aumento de tarifas contundente que podría alterar a los validadores y la provisión de liquidez de alta frecuencia.
Si se implementa como se propone, las estimaciones de la comunidad sugieren que podría añadir aproximadamente 1,500–1,800 SOL/día de quema adicional a los niveles de uso actuales — todavía modesto en relación con la emisión, pero ya no insignificante. (github.com)
Por ahora, el punto más importante no es el número exacto — es la dirección: Solana está explorando activamente cómo alinear los recursos de la red, los mercados de tarifas y la captura de valor de SOL, probablemente en conjunto con cambios de protocolo más grandes como Alpenglow. (github.com)
