Transaction v1

Sending SIMD-0296 (v1) transactions through Nozomi.

Nozomi accepts the new Solana transaction format defined by SIMD-0296 and serialized per SIMD-0385, alongside legacy and v0 transactions. Every submission method recognises it, nothing changes in how you authenticate, tip, or choose an endpoint.

Availability

Nozomi admits v1 transactions only while the SIMD-0296 feature gate is active on mainnet. Before activation every v1 submission is rejected with a specific error (see below), so you can ship v1 support ahead of time and let the network turn it on. Nozomi checks the feature gate itself; there is nothing to enable on your key.

How Nozomi tells v1 apart

A v1 transaction starts with the byte 0x81, followed by the signature count. Its signatures sit at the end of the serialized bytes rather than the front. Nozomi reads the version from the first byte, validates the envelope, and treats the transaction like any other from then on: same tip rules, same priority, same delivery.

Encoding

Use base64 everywhere. JSON-RPC requires "encoding": "base64" for every transaction, and for v1 in particular base58 is not supported beyond legacy sizes. API v2 takes the base64 body as before; Batch Send and Send Bundle take raw bytes.

Size limits

Method	Maximum v1 transaction	Maximum body
JSON-RPC	4,096 bytes	96 KiB (JSON-RPC batch)
API v2	4,096 bytes	5,472 bytes of base64
Batch Send	4,096 bytes per member	65,568 bytes
Send Bundle	1,232 bytes per member	4,936 bytes

v1 transactions may use the full 4,096 bytes the format allows on JSON-RPC, API v2 and Batch Send. Legacy and v0 transactions keep their 1,232-byte limit, and Send Bundle members of every version stay within 1,232 bytes. A transaction over 1,232 bytes must be base64 or raw binary; base58 cannot carry it.

Errors

JSON-RPC returns these as error.code in a 200 response. API v2, Batch Send and Send Bundle return the HTTP status with a one-line body.

Condition	JSON-RPC code	HTTP status	What to do
v1 not yet active on mainnet	-32006	400	Wait for the feature gate; send legacy/v0 meanwhile.
v1 disabled on this endpoint	-32005	400	Temporary operator kill switch; retry later or use another region.
Unknown transaction prefix	-32007	400	The first byte is neither a legacy signature count nor 0x81.
Too large	-32002	400	Over 4,096 bytes, or a legacy/v0 transaction or bundle member over 1,232.
Large v1 has no delivery path right now	-32009	503	Transient on that region; retry, or fall back to a smaller transaction.
Base58 input too long	-32008	n/a	Switch to base64.

Everything else behaves as for legacy transactions: 401 for a bad key, 429 for rate limits, 400 for a missing or insufficient tip.

Building a v1 transaction in Rust

The v1 types live in the solana-message 4.x and solana-transaction 4.x crates, serialized with wincode. This example self-transfers one lamport and tips Nozomi, then posts through API v2.

[dependencies]
solana-message = "4.4"
solana-transaction = { version = "4.1", features = ["wincode"] }
wincode = "0.5"
solana-hash = "3"
solana-keypair = "3"
solana-pubkey = "3"
solana-signer = "3"
solana-system-interface = { version = "2", features = ["bincode"] }
solana-rpc-client = "3"
base64 = "0.22"
reqwest = { version = "0.12", features = ["blocking"] }

use solana_keypair::Keypair;
use solana_message::{v1, VersionedMessage};
use solana_pubkey::pubkey;
use solana_signer::Signer;
use solana_system_interface::instruction::transfer;
use solana_transaction::versioned::VersionedTransaction;

const NOZOMI_TIP: solana_pubkey::Pubkey = pubkey!("TEMPaMeCRFAS9EKF53Jd6KpHxgL47uWLcpFArU1Fanq");
const MIN_TIP_AMOUNT: u64 = 1_000_000;

fn build_v1(signer: &Keypair, blockhash: solana_hash::Hash) -> Vec<u8> {
    let ixs = vec![
        transfer(&signer.pubkey(), &signer.pubkey(), 1),
        transfer(&signer.pubkey(), &NOZOMI_TIP, MIN_TIP_AMOUNT),
    ];
    // Compute limit and priority fee move into the v1 header; no ComputeBudget instructions.
    let config = v1::TransactionConfig::empty()
        .with_compute_unit_limit(20_000)
        .with_priority_fee(0);
    let message = v1::Message::try_compile_with_config(&signer.pubkey(), &ixs, blockhash, config).unwrap();
    let tx = VersionedTransaction::try_new(VersionedMessage::V1(message), &[signer]).unwrap();
    wincode::serialize(&tx).unwrap() // first byte is 0x81
}

fn main() {
    let signer = Keypair::new();
    let rpc = solana_rpc_client::rpc_client::RpcClient::new("https://api.mainnet-beta.solana.com".to_string());
    let blockhash = rpc.get_latest_blockhash().unwrap();
    let bytes = build_v1(&signer, blockhash);

    let body = base64::Engine::encode(&base64::engine::general_purpose::STANDARD, &bytes);
    let response = reqwest::blocking::Client::new()
        .post("https://nozomi.temporal.xyz/api/sendTransaction2?c=<YOUR_API_KEY>")
        .header("content-type", "text/plain")
        .body(body)
        .send()
        .unwrap();
    assert!(response.status().is_success(), "{}", response.text().unwrap_or_default());
}

Points that differ from legacy transactions:

• The compute unit limit and priority fee are fields of TransactionConfig, not ComputeBudget instructions.

• Serialize with wincode, not bincode.

• The signature is the last 64 bytes of the serialized transaction, not the first.

Other SDKs will expose the same format as they add SIMD-0385 support. Nozomi only sees the bytes, so any correctly serialized v1 transaction is accepted.

Mixing versions

A single Batch Send or Send Bundle body may mix legacy, v0 and v1 members; each is checked on its own. Nozomi never rewrites your transaction, so a v1 transaction is delivered to the leader exactly as you signed it.