Errors transferring buffer to program on mainnet deployment action

[CryptoKiddies]

Issue: My program deploys fine on localnet fork and on devnet in interactive mode with web wallet. However on FIRST run, the same web wallet deployment on mainnet gives me an error when attempting to transfer data from buffer to program account. I had 0.9 more sol than the estimated requirement.

Versions:
anchor 0.31.1
solana libraries are v2 across the board

Steps to reproduce:

On first run, the initial error:

! error at runbooks/deployment/main.tx:10:1
!       error: unable to send and confirm transaction (RPC response error -32002: Transaction simulation failed: Error processing Instruction 1: invalid account data for instruction; 7 log messages:
!   Program 11111111111111111111111111111111 invoke [1]
!   Program 11111111111111111111111111111111 success
!   Program BPFLoaderUpgradeab1e11111111111111111111111 invoke [1]
!   Program 11111111111111111111111111111111 invoke [2]
!   Program 11111111111111111111111111111111 success
!   Relocation failed, invalid referenced virtual address 0x0
!   Program BPFLoaderUpgradeab1e11111111111111111111111 failed: invalid account data for instruction
! )
⠇ x Failed: Failed to broadcast transaction  

Then add buffer_account_pubkey and ephemeral_authority_secret_key in my runbook action config. Second deploy/continuation attempt failed.

Somehow on the third run, I get successful program creation, but no sol transfer back from ephemeral key:

[2025-11-04--19-54-05 INFO txtx::svm::deploy_program] Pending - Sending transaction 1/3
[2025-11-04--19-54-07 INFO txtx::svm::deploy_program] Program Created - Program 12345678XHe987654321xxxxxxxxxxxxxxxxxxx has been deployed
[2025-11-04--19-54-09 INFO actix_server::worker] shutting down idle worker
[2025-11-04--19-54-09 INFO actix_server::accept] accept thread stopped
[2025-11-04--19-54-09 INFO actix_server::worker] shutting down idle worker
[2025-11-04--19-54-09 INFO actix_server::worker] shutting down idle worker
[2025-11-04--19-54-09 INFO actix_server::worker] graceful worker shutdown; finishing 1 connections
[2025-11-04--19-54-09 INFO actix_server::worker] shutting down idle worker
[2025-11-04--19-54-09 ERROR txtx::svm::send_transaction] Failed - Failed to broadcast transaction
[2025-11-04--19-54-10 ERROR txtx::svm::send_transaction] Failed - error: unable to send and confirm transaction (RPC response error -32002: Transaction simulation failed: Error processing Instruction 0: custom program error: 0x1; 3 log messages:
  Program 11111111111111111111111111111111 invoke [1]
  Transfer: insufficient lamports 533147396, need 533152396
  Program 11111111111111111111111111111111 failed: custom program error: 0x1
)

I then use solana cli transfer ephemeral account remaining sol back into web wallet.

Do you recommend against using Surfpool for mainnet production usage? Is there a certain procedure that triggers this bug?

(Side issue: in interactive mode, I had to switch from the public solana api to a paid provider to submit on mainnet as public api blocks localhost header it seems.)

[MicaiahReid]

Hi @CryptoKiddies! Thanks for the issue!

Sorry this happened to you on mainnet, that can be nerve-racking!

This issue happens because on mainnet, sometimes transactions are processed but not confirmed. It's not super common, but if you're deploying a program, you're sending many transactions, so there's a chance on of them is not confirmed.

When this happens, the buffer account has some missing data, so it's not a valid program, leading to your error.

This will be fixed in the next release! (txtx/txtx#362). We now check the buffer account for missing data and retry to make sure the buffer account is valid before deploying!

Do you recommend against using Surfpool for mainnet production usage?
Definitely, but you're one of the first so there are some small hiccups to work out :) Thanks for using this and reporting!

[CryptoKiddies]

Thanks @MicaiahReid looks like you're on top of it! I just want to clarify when you say it's not a valid program... on retry it seems to eventually create the program successfully, so with the current version it should deploy eventually when retrying.