Repository navigation
Anchor v1: send every test transaction as a v1 transaction - #198
Merged
Merged
Conversation
…hain Solana's v1 transaction format (SIMD-0385) raises the transaction size limit from 1,232 to 4,096 bytes and moves the compute budget into the message. Programs need no change for it; tests and clients do. basics/transaction-v1/, in Anchor v2, Anchor v1, Pinocchio and native Rust: a program that stores a 3,000 byte document in one instruction, which only fits in a v1 transaction. Its LiteSVM 0.16 tests build the v1 transactions by hand, measure them against both size limits, and show the config fields that replace ComputeBudget instructions, including that an unset field means zero rather than the default. The four directories are standalone workspaces: the root workspace pins LiteSVM 0.13.1 through anchor-v2-testing and solana-kite, and 0.13.1 and 0.16.0 cannot share a lockfile. docs/transaction-v1.md records what v1 changes, where it is live, and which of the tools the examples build on can send it, checked against the pinned versions. README, CHANGELOG and llms.txt link to it. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj
Main moved the Anchor v1 examples to Anchor 1.2.0, LiteSVM 0.16 and solana-kite 0.5.0 while this branch was open, which retires one of the three blockers the docs listed. Transaction v1 also activated on mainnet beta at epoch 1035 (15 September 2026) and is live on devnet. - The example's Anchor v1 copy moves to anchor-lang 1.2.0 like the rest. - Both Anchor copies go back to solana_version 3.1.8 like every other example. CI installs 3.1.14, and a 4.2.2 pin would make anchor try to install another CLI mid-build. The LiteSVM tests bring their own v1-capable runtime, so the CLI version does not matter to them. - docs/transaction-v1.md, the READMEs and the changelog report mainnet activation, kite 0.5.0 and the current example counts. Only anchor-v2-testing (still litesvm =0.13.1) and quasar-svm (still 0.1.0) remain as blockers. - The README catalog and FAQ entries are restored on top of main's rewritten intro. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj
…tion-v1-lw43l0 # Conflicts: # CHANGELOG.md # llms.txt
Solana's v1 transaction format (SIMD-0385) activated on mainnet beta at epoch 1035. Programs need no change for it; the client that builds the transaction does, and in these examples that is the tests. Each Anchor v1 test directory gains a transaction_v1 module, the same file in all 57 examples. Its send_transaction_from_instructions has the same arguments and error type as solana-kite's, which builds a legacy transaction, so each test file swaps one import and no call site changes. A v1 transaction's unset limits are zero, so the module asks for what a legacy transaction gets by default: 200,000 compute units per instruction up to 1,400,000, and 64 MiB of loaded account data. The six tests that build a transaction by hand use the module's v1_transaction instead. This change is Anchor v1 only. The Anchor v2, Pinocchio and native copies of basics/transaction-v1 and docs/transaction-v1.md leave the branch; they remain in commit 8bec3dc. Anchor v2 and Quasar tests cannot send v1 yet: anchor-v2-testing pins LiteSVM 0.13.1 and quasar-svm is on a solana-message without the v1 module. Kite's token helpers still send their setup transactions as legacy ones, through kite's own sender. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj
kite 0.6.0 builds every transaction as v1, including the setup transactions its token, Token Extensions and transfer hook helpers send. The 57 copies of the tests/transaction_v1 module, which stood in for kite's legacy sender, are gone, and each test file imports from kite again. kite 0.6's senders and helpers take a new last argument, compute_unit_limit: Option<u32>. Every call passes None, so kite simulates the transaction and sends it with the compute units the simulation used. The six tests that read a transaction's metadata (logs, compute units, a program error code) build it with kite's build_transaction_from_instructions and get_transaction_config, with solana-compute-budget's MAX_COMPUTE_UNIT_LIMIT, and send it through LiteSVM. They no longer use solana-message or solana-transaction directly. In the transaction v1 example, v1_transaction becomes build_v1_transaction, and the sample document's pattern length is a named constant. Claude-Session: https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj
…tests anchor build failed for compression/cnft-vault: the IDL build links the test binary, and both cnft_vault and spl-token 9 defined `entrypoint`. spl-token came in through solana-kite 0.6.0, which depends on spl-token 9 and spl-associated-token-account 8 without their `no-entrypoint` feature. The three compression test manifests now name both crates with `no-entrypoint`, which Cargo's feature unification applies to kite's copies too. A TODO says to delete them once kite turns the feature on itself. Claude-Session: https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj
This was referenced Oct 15, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Every Anchor v1 example's tests now send v1 transactions (SIMD-0385), the 4,096-byte format live on mainnet since epoch 1035 (15 September 2026). They send them through solana-kite 0.6.0, which builds every transaction as v1, including the setup transactions its token, Token Extensions and transfer hook helpers send. No program changes: a program sees the same accounts and instruction data whichever format carried them.
This PR touches Anchor v1 only. Anchor v2 and Quasar cannot follow yet; see Not in this PR.
How
compute_unit_limit: Option<u32>. All 554 calls here passNone, so kite simulates each transaction and sends it with the compute units the simulation used.hello-solana, the threecompressionexamples,optionsandorder-book. They now build with kite'sbuild_transaction_from_instructionsandget_transaction_config, usingsolana-compute-budget'sMAX_COMPUTE_UNIT_LIMIT, and send through LiteSVM. The compression examples add kite for this. All six dropsolana-messageandsolana-transactionfrom their manifests.basics/transaction-v1/anchor-v1stores a 3,000-byte document in one instruction, which only fits in a v1 transaction. It builds its transactions without kite, to show each config field. Its tests measure the transaction against both size limits and show that an unset field means zero: an empty config fails withMaxLoadedAccountsDataSizeExceededbefore the program runs, and a missing compute limit fails on the first instruction.An earlier commit on this branch carried a copy of a v1 sender module in each example while kite still built legacy transactions. kite 0.6.0 replaces it, and all 57 copies are gone.
Testing
All 57 Anchor v1 projects pass with kite 0.6.0 resolved: 437 tests, the same count as before the switch. They ran against program binaries built with Solana 3.1.14, as CI installs it, and platform-tools v1.57 with SBPF v3, the build
anchor-cli1.2.0 runs. No program source changed in this PR or in the merge frommain. The nine projects whose program or test crate shares a name with another example's ran in their own target directories.Not in this PR
anchor-v2-testingonotter-sec/anchor'sanchor-next, pinslitesvm = "=0.13.1", which predates v1. LiteSVM 0.16 is the first release that runs v1. otter-sec/anchor#5123, which would have moved it, was closed unmerged on 1 October. Once the pin moves, the 56 Anchor v2 examples need kite 0.6 too, and so do the root workspace's native and Pinocchio tests, which share its lockfile.quasar-svm0.1.0 is its only release and is onsolana-message3.x. It never runs a transaction: it compiles each instruction chain into a legacy message under a fixed compute budget, so there is nowhere to ask for v1. It needssolana-message4.2+, a v1 message path with aTransactionConfig, and a release. Thenquasar-testneeds a way for#[quasar_test]to choose the format.🤖 Generated with Claude Code
https://claude.ai/code/session_014EotgxjmAGtATDFVnBtjXj