Solana Network Upgrade Changes (October 2026)

​

Timeline

• p-token (SIMD-0266)
• Prefunded accounts (SIMD-0312)
• Commission in basis points (SIMD-0291)
• Custom commission collectors (SIMD-0232)
• Transaction V1 (SIMD-0385): a new Solana transaction format that sets its compute limit and priority fee in the transaction itself, instead of in separate ComputeBudget instructions
• Default compute-limit changes (SIMD-0170)

​

Do I need to change anything?

​

Transfers

• When: new data from 12 October 2026; history backfilled before 28 October (date TBC)
• Tables: solana.raw.token_transfers, solana.assets.transfers, solana.assets.transfers_and_stake

​

What changes

• More value movements get a row. Existing rows keep their amounts and addresses. New rows include:
  • the new p-token and prefund instructions (about 26 million rows since 13 May 2026)
  • nonce withdrawals Added
  • Token-2022 fees Added
  • lookup-table and program closes Added
• Added New column batch_instruction_index. Each member of a p-token batch instruction gets its own row, numbered by its position in the batch.
• Added New transfer_type values:
  • withdraw_excess_lamports, transfer_fee_withheld, transfer_fee_withdrawal
  • in solana.assets.transfers_and_stake only: stake_move, stake_split, stake_merge, vote_withdrawal
• Added token_type changes from SPL-TOKEN to SOL on rows that move native SOL with no token account.

​

What to do

1. Deduplicate on unique_id. Rows inside one batch share instruction_index, inner_instruction_index and pseudo_instruction_order.
2. Review transfer_type filters for the new values above.
3. If you filter on token_type = 'SPL-TOKEN', native SOL rows no longer match.

​

Examples

{
  "type": "unwrapLamports",
  "transfer_type": "account_closure_sol_balance_transfer",
  "mint": "So11111111111111111111111111111111111111112",
  "from_address": "9PCP7gpY8B4oPrL5zr4bGqYZrXuMyeNkM3veHEtv1Ngq",
  "to_address": "3L4YLrxtz8vNk1ZEvCs1X4b3YJNeQKm7rg6snwiCDRn4",
  "token_acc_from": null,
  "token_acc_to": null,
  "raw_amount": 167317512,
  "batch_instruction_index": null,
  "unique_id": "txn_id-121EDchpGQvkpGagoztGseo3hDM4KTFGz1My7KhdAcpigEE96vhEKtLZhTWU4DKSXeYZPLzMye9qGKoSmAqJFQ2C_i_index-2_ii_index-5"
}

{
  "type": "unwrapLamports",
  "transfer_type": "account_closure_sol_balance_transfer",
  "mint": "So11111111111111111111111111111111111111112",
  "from_address": "GTd6sNB1epWQeVk6afzcQrZ6RQrjgke9fLiAnDaeqFYt",
  "to_address": "GTd6sNB1epWQeVk6afzcQrZ6RQrjgke9fLiAnDaeqFYt",
  "token_acc_from": null,
  "token_acc_to": null,
  "raw_amount": 36338315,
  "batch_instruction_index": null,
  "unique_id": "txn_id-2BtbL1tqf4XNKEnZw2KcUHfhWuX6LTgFgJLgkWkfMz1sPnWfDJRXCjGPDrZCfHSFS1ywEKY7rWYdiHkf1TpCm17w_i_index-2_ii_index-null"
}

{
  "type": "transferChecked",
  "transfer_type": "spl_token_transfer",
  "mint": "o6zqqiw7cKpTXCjjjEjAakp7qShGdS9WRFhtSnxUCvD",
  "from_address": "UWVz4w6PrbNe48yAraebk3hUNhMy4CCJbTET7vhGWmq",
  "to_address": "UWVz4w6PrbNe48yAraebk3hUNhMy4CCJbTET7vhGWmq",
  "token_acc_from": "Cg3TBydezGNuQL9fxg2P5WGWh5pR446TCXTH6EfjULmn",
  "token_acc_to": "DcDxPCneAo4aPWibKjYyXJe8FySpN7W2Lmemff3Cqit9",
  "raw_amount": 7963165663461,
  "batch_instruction_index": 0,
  "unique_id": "txn_id-kNPinchsChynYrhzH6GFqFDuW8zMfs5cphBDcVqgBKQEat2d23dQk9rBxpYeFRBfpNvu8jfdeXyD3piLdWPbZAj_i_index-0_ii_index-0_b_index-0"
}

{
  "type": "withdrawFromNonce",
  "transfer_type": "sol_transfer",
  "mint": "So11111111111111111111111111111111111111112",
  "from_address": "HCi4ZHSiE9jkYeoJE7JmV28XPBqCXXK86vsnHLfhwP8p",
  "to_address": "6qwo9vDb4LZc9UJDManiqANbT3Vptk2KZvK34XpTuWQN",
  "raw_amount": 1056640,
  "batch_instruction_index": null,
  "unique_id": "txn_id-129Q8VAQThMeoD94Sn8XgZKmt5qF87m6QJ1JisHciN4whY8Y7Z7ev6vVXNBc97b6nfsekavNduFMJ3kzY5gZy8Zn_i_index-0_ii_index-null"
}

{
  "type": "transferCheckedWithFee",
  "transfer_type": "transfer_fee_withheld",
  "mint": "HcRLc9VDgjLeK154xDawfb1dmVJ98DoSqcwTHGqiDeJR",
  "from_address": "FhRiiVdT5Q2NDb6szFyETdyZK9Ui2e84Mi9qPNhV8tTK",
  "to_address": null,
  "token_acc_from": "Dzo9GFasgPu1TNggmZ88CF5e1fscnGvNNfq8Uns8AqtZ",
  "token_acc_to": null,
  "raw_amount": 54077700000,
  "batch_instruction_index": null,
  "unique_id": "txn_id-1KgG3F3GRhEKB982pNZzaLqkNaE7sUKhFEpsuqL1mP5MSZJ6ifnuXb7k98pYFS552eWhyxHAKHgXh9esTBuCecr_i_index-3_ii_index-null_fee"
}

{
  "type": "createAccountAllowPrefund",
  "transfer_type": "sol_transfer",
  "mint": "So11111111111111111111111111111111111111112",
  "from_address": "sRe1GfB5QaDp7hWrdriN6uakvkKUAaJqPfsiTBTvG41",
  "to_address": "5zMnhoZZkqj9yeyygjSdfm1GaDM854hMRBYd1CU74N8W",
  "raw_amount": 1112520,
  "batch_instruction_index": null,
  "unique_id": "txn_id-2nsgmGeqBBGE6wsCbwsJub3QHHHYVJpQZZ1aLWCCaMrEU76ue37rL6VZ5dLaR8ghu6MWwMhtmgipKcaRhPq4HxPR_i_index-2_ii_index-0"
}

​

Reference

-- Before: keeps one member of each batch
qualify row_number() over (partition by txn_id, instruction_index, inner_instruction_index order by ...) = 1

-- After
qualify row_number() over (partition by txn_id, unique_id order by ...) = 1
-- order within a transaction:
order by pseudo_instruction_order, coalesce(batch_instruction_index, -1)

​

Fees

• When: new data from 12 October 2026; history backfilled before 28 October (date TBC)
• Table: solana.raw.fees, all history

​

What changes

• Changed effective_compute_unit_limit now matches the limit the Solana runtime applied.
  • Includes changes to how the default was calculated since 2022.
  • set_compute_unit_limit still holds the requested value.
• Added Transaction V1 rows added from 15 Sep 2026, about 47 million per day.
  • Transaction V1 is a new Solana transaction format, live since 15 September 2026 and used by a large share of non-vote transactions.
  • It sets the compute limit and priority fee in the transaction itself, instead of in ComputeBudget instructions. These rows take both values from there.
• Added priority_fee and base_fee match the fees paid on chain.

​

What to do

• If you analyse compute headroom or utilisation, re-run it after the history backfill.
• If you count rows, expect about 47 million more per day from 15 Sep 2026.
• Use priority_fee directly rather than deriving it from set_compute_unit_price.

​

Staking commission

• When: 28 October 2026
• Tables: solana.staking.rewards, solana.staking.validator, solana.raw.rewards

• Validators can pay commission to any account.
• The RPC no longer returns a commission rate on rewards.

​

What changes

• Changed solana.staking.rewards is the recommended source:
  • new commission_bps and commission_percent (NUMBER(38,10))
  • validator_vote_account filled for native staking rewards
• solana.staking.validator: last_commission_rate is current again, capped at 100.
• Changed solana.raw.rewards mirrors the RPC:
  • commission is NULL from 16 Jul 2026
  • for 16 Jul – 8 Sep 2026, the RPC’s commissionBps is in _extra_fields
• Added New per-validator commission dataset: each validator’s share of a commission collector’s Voting reward.

​

What to do

1. Read commission from solana.staking.rewards instead of solana.raw.rewards.commission.
2. Don’t treat a Voting reward’s pubkey as a vote account. From 8 Sep 2026 it can be a collector shared by several validators; use the per-validator commission dataset.

​

Reference

select txn_id,
       _extra_fields:"message.transactionConfig":computeUnitLimit::number as compute_unit_limit,
       _extra_fields:"message.transactionConfig":priorityFee::number     as priority_fee
from solana.raw.transactions
where block_timestamp >= '2026-10-08'
  and _extra_fields:"txn.version"::number = 1
limit 10;

​

Support