Priority fee Compute Budget instructions inserted before AdvanceNonceAccount, breaking durable-nonce transactions

[gopinath-yl]

Summary

When Phantom adds priority fee instructions to a durable-nonce transaction, it inserts the Compute Budget instructions at index 0, ahead of AdvanceNonceAccount. That breaks the transaction: the Solana runtime only treats a transaction as a durable-nonce transaction when AdvanceNonceAccount is instruction 0, so the modified transaction can never land.

Flow

1. The dapp builds a transaction whose instruction 0 is SystemProgram.nonceAdvance, with the nonce value as recentBlockhash. The dapp's fee payer is the nonce authority.
2. The user signs it in Phantom via signTransaction (injected provider). At that point the transaction has no signatures and no Compute Budget instructions.
3. The dapp's backend co-signs as fee payer and submits it.

Expected

AdvanceNonceAccount stays at instruction 0. If Phantom adds Compute Budget instructions, they go after it:

[0] System - AdvanceNonceAccount
[1] ComputeBudget - SetComputeUnitLimit
[2] ComputeBudget - SetComputeUnitPrice
[3] ...dapp instructions

Actual

The signed transaction Phantom returns starts with the Compute Budget instructions, and AdvanceNonceAccount is pushed down:

[0] ComputeBudget - ...
[1] ComputeBudget - ...
[2] System - AdvanceNonceAccount
[3] ...dapp instructions

Request

When instruction 0 of a transaction is AdvanceNonceAccount, please insert Compute Budget instructions after it rather than before it, so durable-nonce transactions stay valid.

Related: the priority fee docs describe when priority fees are added, but not where the instructions are placed.

Environment: Phantom browser extension (injected provider), Solana devnet, @solana/web3.js legacy Transaction, signTransaction.

[Th3Ya0vi]

Thanks for reporting this. Please reach out to our support team at help.phantom.com with these details so they can route the durable-nonce transaction issue to the appropriate team for investigation.