Solana Transaction V1 lands September 9 — what changes for merchants accepting stablecoin payments

What activates on September 9 — and what it actually is

Solana Transaction V1 is a new transaction format, not a new chain, a new token standard or a new fee model. Its headline change is size: the maximum serialized transaction goes from 1,232 bytes to 4,096 bytes. The old ceiling was inherited from the IPv6 minimum MTU of 1,280 bytes; the network moved to QUIC, which imposes no fixed ceiling on a stream, and the new number was picked to line up with the standard 4 KiB memory page on validator hardware.

Two Solana improvement documents carry it: SIMD-0296 raises the size ceiling and SIMD-0385 defines the v1 message format, both authored by Solana engineers Jacob Creech and Andrew Fitzgerald. The full set of accepted proposals lives in the public Solana Improvement Documents repository, which is the primary source worth reading if you want the spec rather than the summary.

The rollout has been unusually legible. Local testing opened on August 24 with Solana CLI v4.2 and later. The mainnet date was confirmed on August 29. Transaction V1 activated on testnet at epoch 1025 on September 1, and reporting at the end of August pinned mainnet to September 9. That gave RPC providers, indexers, wallets, SDKs and analytics platforms about ten days to confirm support — a short window, deliberately.

Inside the format, three things moved. The version discriminator (0x81 for v1) sits at position zero. Signatures were relocated to the tail of the message. And a 32-bit TransactionConfigMask at a fixed offset now encodes priority fees, compute unit limits, loaded accounts data size and heap size directly in the header, replacing the ComputeBudgetProgram instructions that used to carry them.

One thing was deliberately removed: address lookup tables. Under v0, lookup tables let a transaction reference up to 64 accounts using one-byte indices, because 64 inline 32-byte addresses would have blown through a 1,232-byte budget. At 4,096 bytes, those same 64 addresses take 2,048 bytes and fit comfortably inline. So v1 drops the indirection and requires every account address to appear in full.

Three upgrades to the same rail in six weeks

Transaction V1 is not arriving alone, and the cluster is the story. Three changes to Solana's payment-relevant behaviour land inside about six weeks:

• Rent reduction (SIMD-0437, step 1) — began the week of August 31, the first of five steps toward a targeted 90% cut in token account storage costs. Every stablecoin balance on Solana lives in a token account, and every token account carries a rent-exempt deposit. Cutting that cost by an order of magnitude changes the economics of creating accounts at scale — for airdrops, for payouts, for wallets that spin up an account per user.
• Transaction V1 — September 9, described above.
• Alpenglow — targeted for October with Agave 4.3. It replaces Proof-of-History and TowerBFT with two new components, Votor and Rotor, collapsing a 32-round confirmation process into one or two and taking finality from 12.8 seconds to roughly 150 milliseconds. Validators approved the underlying proposal, SIMD-0326, with 98.27% support back in September 2025, and Anza has run a security competition offering up to 50,000 SOL ahead of activation.

Read together, that is a rail being rebuilt in public, on a schedule, with the receipts posted. It is also worth being precise about what Alpenglow changes, because the number is easy to oversell. Finality is not first confirmation. A payment on Solana today is visible and confirmed in well under a second — the practical number Payzum quotes for Solana confirmations is around 0.4 seconds. What takes 12.8 seconds is the point at which the chain's state is cryptographically settled beyond reorganisation. Alpenglow shrinks the second number, not the first. For a coffee shop, the experience at the counter barely moves. For a treasury desk deciding when a transfer is irreversible, it moves a great deal.

Now ask who each upgrade is for

This is where the analysis gets uncomfortable, and it is the same pattern we have written about with bank consortium stablecoins and with agentic payment standards.

Take the list of things Transaction V1 unlocks and name the beneficiary of each:

• Zero-knowledge proofs that no longer have to be split across transactions → the beneficiary is whoever is proving something privately. In stablecoin terms, that is confidential balances (more on this below), and today the people building on it are institutions and wallets, not shops.
• BLS signature aggregation for cross-chain bridge attestations → the beneficiary is the bridge operator.
• Large and nested multisig in a single atomic transaction → the beneficiary is the treasury, the DAO, the custodian. The stated primary motivation for the size increase was nested multisig.
• Config values in the message header instead of separate instructions → the beneficiary is the developer writing the transaction.
• Cheaper token accounts → the beneficiary is whoever creates a lot of accounts. That is issuers, wallets and payout operators, not a business receiving one payment at a time.

None of those is the merchant. That is not a criticism of the roadmap — protocols should fix protocol problems, and these are real ones. It is an observation about where the gap in this market keeps showing up. Issuance gets funded. Settlement gets funded. Consensus gets rebuilt. The business standing behind a counter, trying to take a stablecoin from a customer and end up with it in an account it controls, keeps being the last participant anyone designs for.

The one merchant-shaped thing in this release: confidential balances

There is a genuine exception worth naming, and it is the most interesting part of the upgrade for anyone who runs a business on a public chain.

The zero-knowledge proofs that Transaction V1 makes easier to fit are the ones behind Confidential Balances, a Token-2022 extension that encrypts balances and hides transfer amounts while still verifying them on-chain. Token account addresses stay public; the amounts do not. And the design includes an optional global auditor key: a mint can be configured so every transfer encrypts the amount for sender, recipient and auditor, with the proof confirming all three ciphertexts contain the same value. The public cannot read the amount. The auditor can.

That combination speaks directly to the single most common objection we hear from businesses evaluating on-chain payments: "I don't want my revenue readable by anyone with a block explorer." It is a fair objection. A static receiving address on a public chain is a live revenue feed for competitors, suppliers and anyone negotiating with you.

Be clear-eyed about the state of it, though. Confidential balances are a chain-level capability with real tooling behind them, but they are not something a merchant-facing checkout hands you as a toggle today, on Solana or anywhere else. It is a capability the ecosystem now has room to build on — which is precisely why Transaction V1 matters more than a byte count suggests.

Until that arrives at the checkout layer, the practical mitigation is much simpler and available now: don't reuse one address for everything. Payzum's POS issues a fresh QR per sale rather than a single static address on the wall, which is basic hygiene rather than cryptography, but it is the difference between a public revenue feed and a set of unlinked payment requests.

The breaking change is the real lesson for merchants

The part of this upgrade that should register for business owners is not the byte count. It is what had to happen in the ten days before September 9.

RPC calls that read blocks and transactions — getTransaction, getBlock — fail on a V1 transaction unless the caller passes maxSupportedTransactionVersion: 1, returning error -32015. A WebSocket blockSubscribe that hasn't been updated emits block: null and stops advancing. Minimum SDK versions moved: @solana/kit 8.0.0, @solana/web3.js 1.99.0-beta.0, the solana-* Rust crates at 4.2.x.

Translate that out of engineering. A payment-watching service that fell behind on a client library version could, on September 9, stop seeing a category of transactions — not because the money didn't arrive, but because its indexer stopped advancing. The chain would be fine. The dashboard would be wrong.

This is the ordinary cost of building on public infrastructure that moves, and it is a cost somebody has to carry. The question is who. If you are a restaurant, a gym or an online store, the correct answer is emphatically not you. You should never be the person tracking maxSupportedTransactionVersion flags, epoch numbers or Agave release channels. That is what a payment processor is for — and it is a fair thing to ask any provider before you sign: who at your company is responsible for keeping up with chain upgrades, and what happened on September 9?

Why none of this answers the merchant's actual question

Here is the thing a faster chain cannot fix.

When a customer pays you in stablecoins, the money moves in one hop on-chain. Whether that hop settles in 400 milliseconds or 150 is a rounding error next to the question of where it lands. If it lands in a processor's pooled wallet, you now hold a claim on a company, not a balance on a chain — and your actual settlement time is that company's payout schedule, not Solana's finality. If the company freezes your account, gets acquired, changes its risk policy or shuts down, the chain's performance is irrelevant to you.

That is counterparty risk, and it is not a protocol problem. No SIMD addresses it. Alpenglow does not address it. It is a product decision made by whoever built the acceptance layer, and it is the single decision that determines whether the speed of the underlying rail reaches you at all.

Solana's roadmap is genuinely impressive and genuinely relevant: the chain is getting bigger transactions, cheaper accounts and faster finality, and it already carries a serious share of real stablecoin payment volume. But a merchant gets exactly none of that if the last hop of the payment ends in someone else's balance sheet.

How Payzum fits — the acceptance side, unchanged on September 9

Payzum is a non-custodial, crypto-only payment processor. Funds go directly to wallets the merchant controls; Payzum never holds, pools or controls the money. The settlement is the payment.

Concretely, against everything above:

• Solana is a supported network today, alongside Bitcoin, Ethereum, Base, Polygon, Arbitrum, Optimism, BNB Chain and Avalanche. Typical confirmation times: Solana ~0.4s, Base ~2s, Polygon ~2s. You are already on the rail this upgrade improves.
• Nothing in your setup changes on September 9. Legacy and v0 transaction formats remain valid; V1 is opt-in for whoever constructs the transaction. There is no migration for you to run and no deadline for you to miss.
• Volatility is handled at the acceptance layer, not the consensus layer. Optional auto-conversion to USDC or USDT means you can accept crypto and hold dollars, independent of anything on the chain roadmap.
• Finality is already your friend. On-chain payments do not reverse. There are no chargebacks, no acquirer, no card network fees — the property that matters most to a merchant was there before this upgrade and is not what the upgrade is about.
• Chain upgrades are our problem, not yours. You get paid; we track the release channels.

How it works, step by step

1. Connect your wallet. You provide the Solana (and/or EVM) addresses where you want money to arrive. Payzum never takes custody of the keys — there is no Payzum balance holding your funds.
2. Pick how you get paid. Online: hosted checkout, payment links and buttons, invoices with expiry and overpayment detection, subscriptions, or a drop-in plugin. In person: POS with a fresh QR per sale, physical terminals and PIN-protected cashier accounts with per-cashier and per-terminal analytics.
3. Choose your settlement asset. Accept what the customer holds; optionally auto-convert to USDC or USDT so your books stay in dollars.
4. Reconcile. Signed webhooks and a REST API push confirmations into your systems as they land on-chain. The on-chain record is the receipt — the same transaction anyone can verify.

What this looks like for three real businesses

The abstraction only earns its keep if it changes something concrete. Three cases:

• A café that takes USDC at the counter. Sub-second Solana confirmation already makes this work at card-tap speed; Alpenglow's finality improvement in October is mostly invisible here. What matters to the owner is that the QR is new for every sale, the cashier has a PIN, the sale cannot be charged back, and the USDC arrives in a wallet the owner controls before the customer has put their phone away. See turning a phone into a crypto POS.
• An online store selling into ten countries. The relevant upgrade is not V1 — it is that the store never has to think about V1. Hosted checkout takes USDC or USDT on Solana, Base or Polygon, auto-converts if the buyer paid in something volatile, fires a signed webhook, and settles directly to the store's wallet with no acquirer in the middle and no 120-day reversal window.
• An agency invoicing overseas clients. Invoices with expiry and overpayment detection replace a wire that takes days and loses percent to FX. Finality means the invoice is settled when the chain says so, not when a correspondent bank agrees. The chain upgrade that actually helps here is the boring one — cheaper token accounts — and it helps the client's wallet, not the agency's invoice.

A faster chain vs a custodial processor — where the speed actually goes

Fair objections

"If the chain keeps changing, isn't building on it risky for my business?"

The change here is additive and opt-in. Legacy and v0 transactions stay valid with their original size ceiling; nothing that worked on September 8 stopped working on September 9. What did require attention was tooling — indexers, RPC clients, SDK versions — which is exactly the layer you pay a processor to own. The risk is real; it just isn't yours to carry, and the fact that the schedule was published weeks in advance with testnet activation first is what a well-run rail upgrade looks like.

"Everyone can see what I earn on a public chain. Isn't that worse than a bank?"

Partly true, and the honest answer has two halves. Today: use a fresh payment request per sale rather than one static address, which is what Payzum's POS does by default, and treat your receiving addresses the way you'd treat an account number. Tomorrow: confidential balances on Token-2022 hide transfer amounts while keeping them verifiable, with an optional auditor key — and Transaction V1 is part of what makes those proofs practical to fit in one transaction. That capability is real but not yet a merchant-facing toggle; we'd rather say so than promise it.

"Should I wait for Alpenglow before I start accepting stablecoins?"

No, and the reason is in the numbers. Alpenglow targets finality, not first confirmation. Your customer's payment already confirms in well under a second on Solana. Waiting for October buys you a stronger settlement guarantee for treasury-scale decisions and changes essentially nothing about a $6 coffee or a $400 online order.