cryptosnifSolana (SOL)
solana-mainnet · Activo nativo · pilot-1Sin puntuación · 0% Cobertura de las pruebas
Promesa documentada. Verificación independiente pendiente.
Las pruebas disponibles son insuficientes para asignar una puntuación global. El mecanismo descrito requiere verificar su funcionamiento actual.
Consultar las pruebasLa revisión de las fuentes explica los mecanismos documentados. Los controles independientes de la red siguen pendientes.
Promesa y Alcance
Este dossier examina SOL nativo en la red solana-mainnet. El enfoque se limita estrictamente a los mecanismos documentados: ejecución de instrucciones, cálculos de comisiones vinculados a versiones, parámetros predeterminados de inflación y la interfaz de línea de comandos (CLI) de activación de funciones de Agave. Analizamos cómo estos componentes están definidos en el código y la documentación. Esta revisión no evalúa el rendimiento actual de la red, la disponibilidad actual de los validadores ni los costes de transacción en tiempo real. También excluye cualquier evaluación de seguridad operativa independiente o estado de auditoría.
Ejecución de Instrucciones y Atomicidad
Las transacciones de Solana consisten en instrucciones, que son las operaciones individuales que ejecutan los programas. Una propiedad técnica clave descrita en la documentación es la atomicidad. Esto significa que dentro de una sola transacción, todas las instrucciones tienen éxito y sus cambios de estado se aplican, o fallan y sus cambios de estado de instrucción se revierten. Si bien este mecanismo garantiza la coherencia interna para una transacción específica, no demuestra que las aplicaciones estén libres de errores, ni garantiza la fiabilidad general de la red. Las auditorías independientes de contratos inteligentes específicos quedan fuera del alcance de esta observación.
Mecánica de Comisiones y Cálculos Vinculados a Versiones
Las comisiones en Solana se pagan en SOL y comprenden una comisión base y una comisión de priorización opcional. La documentación establece que la comisión base se divide equitativamente, con un 50% quemado y un 50% asignado al validador. La comisión de priorización va íntegramente al validador. Estas reglas describen la lógica de distribución prevista, pero no miden los costes actuales ni la emisión neta. En el cliente Agave v4.3.0, la quema de la comisión base se calcula utilizando aritmética entera al 50%. La parte no quemada y toda la comisión de prioridad se añaden a un depósito de recaudador. Si este depósito falla, la cantidad total se quema. Dependiendo de una bandera de función, el destinatario puede ser la identidad del líder o un recaudador permitido asociado con la cuenta de voto del líder.
Ejemplo Hipotético de Cálculo de Comisiones
Para ilustrar la aritmética sin implicar valores reales de la red, presentamos un escenario hipotético basado en los cálculos originales de Cryptosnif. Suponga una comisión base de 5000 lamports (la unidad de comisión entera en este ejemplo) y una comisión de prioridad de 1000 lamports. La comisión total es de 6000 lamports. Bajo condiciones normales con un depósito aceptado, se queman 2500 lamports (el 50% de la base), y 3500 lamports van al recaudador (2500 restantes de la base más 1000 de prioridad). Si el depósito del recaudador falla, todos los 6000 lamports se queman. En un caso con una comisión base impar de 5001 lamports y una comisión de prioridad de 1000 lamports, el cálculo de quema utiliza división entera por defecto: floor(5001 * 50 / 100) equivale a 2500 lamports quemados. El recaudador recibe 3501 lamports. Estos datos de entrada son solo ilustrativos y no establecen comisiones reales en la mainnet ni proporcionan una base para la comparación de costes frente a otras redes como Ethereum.
Parámetros Predeterminados de Inflación
El paquete solana-inflation versión 3.2.0 define una fórmula predeterminada de tasa anual total de inflación: max(0.015, 0.08*(1-0.15)^year). Este modelo admite configuraciones de inflación deshabilitada, fija y completa. Es crucial distinguir estos valores predeterminados del código de la configuración observada en la mainnet. La fórmula representa un calendario teórico, no la emisión realizada, fechas de calendario o cambios netos en la oferta. Además, la inflación total difiere del rendimiento de un titular de staking. Un año de modelo en este contexto no tiene un origen de calendario establecido en esta revisión.
Ilustración de la Tasa de Inflación
Aplicar la fórmula predeterminada produce tasas específicas para años de modelo hipotéticos. En el año de modelo 0, la tasa es del 8%. En el año de modelo 1, baja al 6.8%. En el año de modelo 2, es del 5.78%. La reducción es del 15% de la tasa anterior cada año hasta alcanzar el suelo del 1.5%. El porcentaje se aplica a la tasa precedente cada año de modelo. Estas cifras ilustran el comportamiento matemático de la configuración predeterminada. No predicen la inflación futura, la oferta circulante ni los rendimientos para los apostantes en la red activa.
CLI de Activación de Funciones y Verificaciones de Preparación
La CLI de funciones de Agave v4.3.0 verifica la identidad génesis de un clúster y consulta el estado de la cuenta antes de construir una transacción firmada de activación de funciones. Su verificación ordinaria de preparación compara los conjuntos de funciones de software reportados contra estadísticas que muestran que al menos el 95% del stake y el 95% de los nodos RPC (servidores de interfaz de consulta) reportan el mismo conjunto de funciones que la CLI. La CLI expone una ruta de fuerza explícita que omite esta comprobación local de sensatez. Sin embargo, esta anulación no demuestra que usuarios arbitrarios puedan activar funciones o obligar a cada validador a adoptar una regla. La autorización de transacciones, cuentas de funciones, firmas y el comportamiento del cliente desplegado requieren verificación separada. Esta observación identifica un mecanismo de control de cambios, pero no confirma quién posee las claves de activación ni qué funciones están actualmente activas.
Desconocidos y Limitaciones
Varios elementos críticos permanecen sin verificar en esta revisión piloto. La concentración actual de propiedad, los poderes de control privilegiados, el uso medido independientemente, el historial de remediación de incidentes y la liquidez ejecutable localmente son desconocidos. La presencia de una anulación forzada en la CLI no equivale a un poder administrativo sin restricciones, ya que las reglas de consenso y la adopción de validadores son capas distintas. De manera similar, las divisiones de comisiones documentadas no reflejan resultados económicos actuales. Ninguna transacción de red o activación fue realizada por Cryptosnif durante este análisis.
Consecuencias y Veredicto
La cobertura de evidencia es insuficiente para una puntuación global. Un mecanismo documentado por sí solo no puede establecer la resiliencia actual, la seguridad o los rendimientos esperados. La distinción entre los valores predeterminados del código y el despliegue actual es significativa; inferir la oferta neta o el rendimiento de staking a partir de fórmulas es inválido. Para comparaciones, diferentes entradas de comisiones no pueden establecer un ganador de coste sin datos normalizados y medidos. El veredicto permanece pendiente de verificación independiente. Observaciones reproducibles de la red, mapas de control actuales, reglas de oferta documentadas y registros de incidentes independientes permitirían evaluar las comprobaciones pendientes.
Hechos documentados
El documento primario enlazado está disponible y describe la promesa del proyecto. Las verificaciones independientes del funcionamiento siguen pendientes.
The Solana documentation presents a network for applications and transactions. Documentation describes the proposed mechanisms; current operation requires independent observation. [1]
Lo que queda por verificar
La concentración de titulares, los poderes de control, el uso actual, los incidentes y la liquidez local quedan por verificar.
Las pruebas disponibles son insuficientes para asignar una puntuación global. El mecanismo descrito requiere verificar su funcionamiento actual.
Cada control exige pruebas.
| Control | Peso | Resultado |
|---|---|---|
| Identidad exacta del activoEsencial | 3% | Verificación pendiente |
| Uso observable | 15% | Verificación pendiente |
| Papel económico del token | 10% | Verificación pendiente |
| Mecanismos de ofertaEsencial | 10% | Verificación pendiente |
| Concentración de titulares | 8% | Verificación pendiente |
| Captación de valor | 7% | Verificación pendiente |
| Poderes de controlEsencial | 10% | Verificación pendiente |
| Verificación de seguridad | 7% | Verificación pendiente |
| Proceso de decisión | 8% | Verificación pendiente |
| Responsabilidades | 7% | Verificación pendiente |
| Historial de incidentes | 6% | Verificación pendiente |
| Continuidad operativa | 4% | Verificación pendiente |
| Condiciones de ejecución | 5% | Verificación pendiente |
Controles específicos de la familia: Independencia de validadores, actualizaciones, ejecución y tarifas.
Consultar las pruebas
Fuentes de este análisis
Los títulos y resúmenes de las fuentes están en inglés.
Agave v4.3.0: pinned feature activation CLI
The Agave v4.3.0 feature CLI checks a cluster's genesis identity and queries account state before constructing a signed feature-activation transaction. Its ordinary readiness check compares reported software feature sets with 95% of stake and 95% of RPC nodes in the collected version statistics. The CLI exposes an explicit force path that bypasses this local sanity check. That override does not prove that arbitrary users can activate arbitrary features or compel every validator to adopt a rule: transaction authorization, feature accounts, signatures and deployed client behavior require separate checks. This code observation identifies a change-control mechanism. The present holders of activation keys, actual activated features, network adoption and independence of operators remain unverified. No network transaction or activation was performed by Cryptosnif.
Consultar la fuente primaria ↗Solana documentation: transaction fees
Solana documentation describes fees paid in SOL with a base fee and an optional prioritization fee. It states that the base fee is divided 50% burned and 50% to the validator, while the prioritization fee goes entirely to the validator. These documented rules do not measure live costs, utilization or net issuance.
Consultar la fuente primaria ↗Solana documentation: transactions
Solana documentation describes transactions containing instructions, the individual operations that programs execute. Execution is atomic: all instructions succeed or their state changes revert. This technical property does not prove independent audits of applications, absence of bugs, or present network reliability.
Consultar la fuente primaria ↗Solana SDK 3.2.0: pinned inflation model
The solana-inflation 3.2.0 source, matched to its package commit, defines a default total annual rate of max(0.015, 0.08*(1-0.15)^year). It also supports disabled, fixed and full inflation configurations. The default total model differs from the separate validator/foundation allocation functions. These are code parameters, not observed mainnet configuration, realized issuance, calendar dates, net supply change or a staking holder's yield. A model year has no calendar origin established in this review. Original Cryptosnif calculation (platform-mechanisms-1) gives default total annual inflation rates 8%, 6.8% and 5.78% at model years 0, 1 and 2, with a 1.5% floor. The reduction is 15% of the rate each model year until the floor, not a reduction of 15 percentage points. This illustrates defaults only, not today's mainnet inflation, a future dated forecast, circulating supply or staking returns.
Consultar la fuente primaria ↗Agave v4.3.0: pinned transaction fee distribution
Agave v4.3.0 computes the ordinary base-fee burn with integer arithmetic at 50%, adds the unburned base portion and the entire priority fee to a collector deposit, then attempts that deposit. A failed deposit is also burned. Depending on a feature flag, the recipient is the leader identity or a permitted collector associated with the leader's vote account. This reviewed client version does not establish current feature activation, deployed versions, live transaction cost, total issuance or beneficial control. Illustrative inputs stay within non-overflowing fee amounts. Original Cryptosnif arithmetic (platform-mechanisms-1) assumes a hypothetical base fee 5000 lamports and priority fee 1000 lamports with accepted deposit: total 6000, burned 2500, collector 3500 lamports. With a failed collector deposit, all 6000 lamports are burned. With odd base fee 5001 and priority 1000 the accepted-deposit burn is floor(5001*50/100)=2500 and collector 3501. These hypothetical inputs do not establish fees on the live network or a comparison of cost against Ethereum.
Consultar la fuente primaria ↗[1] Solana documentación primariaAfirmación del proyecto
The project publishes the mechanism described above.
Observación 2026-10-03 · Válido hasta 2026-11-02
Consultar la fuente primaria ↗Solo se distribuyen resúmenes originales. Los datos de mercado brutos bajo licencia permanecen privados.
Lo que cambiaría este veredicto
Observaciones reproducibles de la red, un mapa de los poderes y la verificación de las reglas de emisión permitirían completar las pruebas.
Ninguna corrección registrada para pilot-1. Las revisiones conservan sus fuentes y los veredictos anteriores.