Logo Oficial MASTR MASTR
Menú

Solana: de la cotización a la liquidación

Solana priority fees: the compute limit is part of the price

Separate the base network fee, prioritisation, Jito tips and application charges.

Actualizado el 30 de septiembre de 2026 · MASTR Labs

Los artículos y gráficos técnicos están en inglés. La navegación está disponible en 7 idiomas.

Guías de referencia
  1. Compute is a budget
  2. Be specific about transaction versions
  3. Why a larger budget can waste money
  4. How to read a trade ticket
  5. Ejemplo concreto
  6. Fuentes y originales

Compute is a budget

Solana measures execution work in compute units. A transaction’s compute limit caps the work it can request; the compute-unit price expresses a prioritisation bid. In the compute-budget model used by legacy and v0 messages, the prioritisation fee is the requested limit multiplied by the micro-lamport price, divided by 1,000,000 and rounded up to lamports. It is not simply a bill for the units ultimately consumed. 1

Be specific about transaction versions

Solana’s current fee documentation distinguishes the V1 format, where the prioritisation fee is an absolute lamport amount in message configuration. A reader should therefore verify the transaction format before applying a formula copied from an older tutorial. The base network fee, prioritisation fee and application-level charges are different line items. A Jito tip is another distinct payment, not another name for compute pricing.

Why a larger budget can waste money

In the compute-unit-price model, increasing the requested limit increases the prioritisation fee at an unchanged unit price. Too small a limit can cause execution to fail; too large a limit can pay for headroom the transaction never uses. Simulation can inform an estimate, but it is a preview under observed conditions rather than a guarantee of future execution.

How to read a trade ticket

Compare the transaction’s expected output with the complete cost breakdown. Distinguish fees from token-account deposits that may be recoverable, and from token-specific transfer fees. A higher priority setting can improve inclusion chances without improving the swap’s exchange rate or guaranteeing success. Interfaces should show the final amounts before authorisation, not ask users to infer them from labels such as ‘Turbo’.

Read each cost separately
Diagrama explicativo. Abrir a tamaño completo. Credits ↗ Legacy/v0 example: 200,000 × 1,000 / 1,000,000 = 200 lamports.

Ejemplo concreto

Under the compute-unit-price model, a 200,000-CU limit at 1,000 micro-lamports per CU costs 200 lamports in prioritisation fees. A 400,000-CU limit at the same price costs 400 lamports, even if execution only uses 180,000 CU. Base and other costs are separate.

Fuentes y originales

  1. Solana: fee structure and version differences
  2. Solana: transactions

Seguir leyendo

Solana: de la cotización a la liquidación →

MASTR

Apoya la investigación independiente

Las investigaciones, las pruebas originales y las guías son de acceso libre. Las donaciones voluntarias ayudan a financiar la investigación y a mantener disponibles las herramientas de MASTR.

Abrir billetera