Reader safe
Atomic requests transaction version 1 explicitly, so V1 traffic cannot break or disappear from the read path.
Checking mainnetLive RPC
Solana Transaction V1
See what fits atomically.
The transaction ceiling is now 4 KiB. Atomic inspects a real transaction, plans an exact byte budget before you build one, decodes the raw config mask, diffs legacy against v0 against v1, and tells a sponsor or a wallet exactly what it is agreeing to.
4,096bytes per V1 transaction
3.3xthe legacy payload room
0x81visible at wire byte zero
Flight recorder
Inspect before you sign
Decoding the exact wire transaction...
Decoded format
V1 transaction
Caps explicit
Wire envelope
0 bytes
Legacy wall · 1,232
Signatures0
Inline accounts0
Instructions0
Compute usedNot on-chain
Resource envelope
Transaction config
- Compute unit limit
- Loaded account data
- Heap size
- Priority fee
Co-signing lens
Sponsor assessment
Pump.fun lifecycle
Replay
No pump.fun events in this transaction. Atomic decodes create, trade, graduation, fee-collection, fee-distribution, and GitHub social-fee-claim events from Pump, PumpSwap, and PumpFees. This transaction did not invoke any of them.
Sponsor aware
V1 caps live in transactionConfig. Atomic never pretends a Compute Budget instruction scan still binds them.
Byte exact
The gauge measures signed wire bytes, not an estimate. Transactions above the old MTU wall become immediately visible.
Bit layout
Decode the config mask
Every V1 transaction carries a 4-byte TransactionConfigMask right after the version byte and legacy header. Atomic reads those exact bits and the fixed-width values that follow, SIMD-0385, not an estimate.
Reading the config mask bits...
Decoded format
V1 transaction
Legacy and V0 carry resource limits as Compute Budget instructions, not a config mask. There is no mask to decode on this transaction.
Reserved bits set
u32, little-endian
Mask bits
| Field | Bit(s) | Present | Width | Raw bytes | Value |
|---|
4 known fields
Priority fee (bits 0-1, 8 bytes), compute unit limit (bit 2, 4 bytes), loaded accounts data size (bit 3, 4 bytes), and requested heap size (bit 4, 4 bytes).
Sanitization aware
The priority fee bits must both be set or both cleared. Atomic flags a mask where only one is set as a partial, invalid encoding.
Reserved bits
Bits 5-31 are reserved. Atomic calls out any transaction that sets one, since a future SIMD may assign it a meaning this decoder does not yet know.
Before you co-sign
Sponsor cap view
A paymaster or co-signer reads this before it agrees to pay. It shows the exact fee and resource caps the transaction commits to, and whether its static account list holds a duplicate the v1 sanitizer would reject.
Reading the resource caps this sponsor would agree to...
Decoded format
V1 transaction
Caps explicit
What this sponsor is agreeing to
Fee and resource caps
- Priority fee
- Compute unit limit
- Loaded account data
- Heap size
V1 sanitization rule
Duplicate static accounts
Co-signing lens
Sponsor assessment
Caps, not hopes
On V1, a Compute Budget instruction scan sees nothing. The real caps live in transactionConfig, and this view reads them from there.
Duplicate check
SIMD-0385 makes a duplicate static account a sanitization failure. This view decodes the wire account list and flags one if present.
Zero means zero
An unset V1 compute or data limit resolves to zero, not a legacy default. A sponsor relying on the old default would be wrong to assume otherwise.
Before you build
Size and budget planner
Compiles your instruction set with the same @solana/kit encoder three.ws ships to real callers and reports the exact wire size. Nothing here is signed, simulated, or broadcast.
Compiling the exact wire transaction...
V1
0 bytes
Inline accounts0
Instructions0
Required signers0
Message bytes0
Resolved resource budget
Transaction config
- Compute unit limit
- Loaded account data
- Data size headroom
- Priority fee total
V1 sanitization rule
Duplicate static accounts
Exact, not estimated
Every byte count comes from compiling your instructions with @solana/kit and encoding the result, the same path a real sender would take.
Ceilings both ways
Plan against the 1,232-byte legacy/v0 wall or the 4,096-byte V1 envelope, with the exact headroom or overage reported either way.
Priority fee, computed
Set a µlamports-per-CU price and a compute unit limit; the planner multiplies them into the exact total lamports a V1 sender would commit to.
Same instructions, three envelopes
Legacy vs V0 vs V1
Compiles the same instruction set three ways and reports the byte-exact total for each, side by side.
Compiling legacy, v0, and v1...
| Metric | Legacy | V0 | V1 |
|---|---|---|---|
| Total bytes | |||
| Envelope ceiling | |||
| Headroom | |||
| Fits? |
Same payload, three compiles
One instruction set, compiled once per version with the identical @solana/kit pipeline, so the only variable is the envelope itself.
V1 is not always smaller
A tiny transaction can come out larger on V1 once the config mask and its fixed-width values are counted. The diff shows that honestly instead of assuming V1 always wins.
Legacy wall, both rails
Legacy and V0 share the same 1,232-byte ceiling. The diff flags the first version, if any, that needs V1's room to fit at all.
Before the wallet signs
Wallet V1 capability check
Connects your injected Solana wallet (no linking, no signature request) and reads its real Wallet Standard feature set to see whether it honestly advertises V1 transaction signing.
Reads wallet.features['solana:signTransaction'].supportedTransactionVersions. Never signs or sends anything.
Asking your wallet what it supports...
Connected wallet
Wallet
Wallet Standard, verbatim
Supported transaction versions
No wallet needed to try the lab
Only this tab needs a browser wallet. Every other tab works from a pasted signature or wire transaction.
The existing signer, reused
This check calls the same findV1WalletStandardSigner function three.ws uses before it ever asks a wallet for a real V1 signature.
Honest advertising only
A wallet that does not list version 1 in its signTransaction feature gets reported as unsupported, even if it can technically parse the bytes.