Skip to content

solana-cli: add a Squads vault path to shreds validator-client-rewards claim - #4309

Draft
elitegreg wants to merge 1 commit into
mainfrom
gm/claim-squads-vault-path
Draft

solana-cli: add a Squads vault path to shreds validator-client-rewards claim#4309
elitegreg wants to merge 1 commit into
mainfrom
gm/claim-squads-vault-path

Conversation

@elitegreg

@elitegreg elitegreg commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

Resolves: #4185

Summary of Changes

  • shreds validator-client-rewards claim gains a Squads vault path. With --multisig (and optional --vault-index), the vault stands in for the wallet as manager, no keypair is loaded, and the command prints base58 payloads for import into Squads instead of signing and sending. Each payload carries CheckCliVersion and the claim, and no compute budget instructions, since Squads sets the budget on its execute transaction.
  • The vault path keeps the manager check, against the vault key, so a payload the multisig can never execute is refused before it consumes an approval round. The mismatch message now names whichever actor was checked.
  • The default destination on the vault path is the vault's associated token account. When it is missing, every payload prepends create_idempotent, so each payload stays independently executable, and the output says the vault pays the rent. An explicit --destination-token-account that does not exist is refused. The direct path still requires the destination to exist.
  • MAX_CLAIM_EPOCHS_PER_TX is retired. Each transaction grows one holding at a time while a trial still fits. The direct path measures the v0 transaction the wallet sends, always counting the fee payer and both compute budget instructions so packing does not shift with the flags. The vault path measures the legacy message the base58 string carries against the Squads payload budget. Measured capacities: 19 holdings per direct transaction, 16 with a distinct --fee-payer, 12 per vault payload into an existing destination, 10 when every payload creates it.
  • New --max-transactions N caps how many transactions one invocation produces. The output reports how many were withheld and how to reach them.
  • Vault output is written for a human copying payloads by hand: every payload is numbered, states its holdings, epochs and pre-claim total, keeps the base58 alone on its own line, and the command closes with a recap and the note that payloads are independent and a re-run discovers only what is still outstanding. The destination token account's authority is printed on both paths.
  • solana-client-tools: add squads::try_write_vault_transaction, a writer-taking form that try_print_vault_transaction now delegates to, and Wallet::try_transaction_size, which measures the transaction new_transaction would build with the same signer set.

Diff Breakdown

Category Files Lines (+/-) Net
Core logic 1 +538 / -192 +346
Scaffolding 2 +47 / -23 +24
Tests 3 +299 / -11 +288
Docs 3 +8 / -0 +8
Total 6 +892 / -226 +666

Test and core lines are split by test module within each Rust file, so the per-category numbers are approximate. Roughly half the change is the claim command itself and a third is new tests.

Key files (click to expand)

Testing Verification

  • Unit tests pin the measured packing capacities (19, 16, 12, 10 holdings) and check that every packed batch fits as sent, with and without a compute unit price, while one more holding does not. The vault batches are also run through the checked Squads encoder, which accepts each batch and refuses each batch plus one holding.
  • Tests cover the growth loop itself (grows, splits, refuses a holding that fits nowhere), the --max-transactions withheld note, the create-ATA instruction appearing in every payload, --vault-index requiring --multisig, --max-transactions 0 being rejected, and the manager mismatch message naming the wallet or the vault.
  • A Wallet with a distinct fee payer measures exactly 96 bytes larger than one without, and the writer-taking Squads printer puts the base58 alone on its own line.
  • Manually on Solana devnet, with no keypair available to the command: --multisig pointed at a non-Squads account fails with the "not the Squads v4 program" message before anything is built, and a real devnet multisig gets through the multisig check to the validator client rewards lookup. No devnet client is managed by a Squads vault, so no end-to-end payload was produced against a live multisig.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

solana-cli: add a Squads vault path to shreds validator-client-rewards claim

1 participant