Account Data Direct Mapping

LiteSVM builds its runtime environment when builtins are added, so set the feature set first. See the LiteSVM API docs.

use agave_feature_set::{account_data_direct_mapping, virtual_address_space_adjustments};
use litesvm::LiteSVM;

let mut features = LiteSVM::mainnet_feature_set();
features.activate(&virtual_address_space_adjustments::id(), 0);
features.activate(&account_data_direct_mapping::id(), 0);

let svm = LiteSVM::default()
    .with_feature_set(features)
    .with_builtins()
    .with_sysvars()
    .with_feature_accounts()
    .with_default_programs()
    .with_lamports(1_000_000_000_000_000)
    .with_sigverify(true)
    .with_blockhash_check(true);

Mollusk builds its program cache when the instance is created, so rebuild it after changing the gates, then add your program. See the Mollusk API docs.

use mollusk_svm::{program::ProgramCache, Mollusk};

let mut mollusk = Mollusk::default();
mollusk.feature_set.virtual_address_space_adjustments = false;
mollusk.feature_set.account_data_direct_mapping = false;
mollusk.program_cache = ProgramCache::new(&mollusk.feature_set, &mollusk.compute_budget, false);
mollusk.add_program(&program_id, "my_program");

Pass both gate addresses. See the Surfpool docs.

surfpool start --feature 7VgiehxNxu53KdxgLspGQY8myE6f7UokaWa4jsGcaSz --feature CR3dVN2Yoo95Y96kLSTaziWDAQT2MNEpiWh5cqVq2pNE

Wallets, balances, fees, and confirmation times are unaffected. If an app you use runs a program that still breaks the rules, its transactions can fail after activation until the app team fixes it. A failed transaction changes no account state but still pays the usual fee.

Every program:

Most programs pass without changes. To confirm yours does:

• Run your tests against solana-test-validator, then on devnet. Cover every instruction, including the close, resize, and CPI paths.
• Search your code for unsafe, raw pointer casts, and realloc. If none appear and you are not affected by the Anchor issue below, the risk is low.
• Optional: replay recent mainnet transactions in SVM Scope to cover traffic your tests miss.
• If something fails, redeploy the fix before mainnet activation. Immutable programs cannot be fixed, so they need a new program and a user migration.

If you read, write, or resize account data by hand (details):

• Check data_len() before casting account bytes to a struct.
• Remove writes to read-only accounts and to accounts you no longer own, even if the write restores the old value.
• Replace realloc with resize, which always zero-fills. With Anchor's realloc constraint, upgrade to v0.32 or later, or set realloc::zero = true. With Pinocchio, upgrade to v0.9 or later, where realloc calls resize.

If you access memory in unsafe code or raw syscalls (details):

• Split any load, store, or syscall that crosses a region boundary into one access per region.

If you rely on stack layout (details):

• This can alter behavior without an error. Remove absolute stack addresses, address math across frames, and out-of-bounds stack accesses.

If you use Anchor:

• Anchor writes every mutable typed account back after your handler returns, even if a CPI reassigned the account to another program. Under the new rules that write fails with ExternalAccountDataModified. Affected types: Account, InterfaceAccount, AccountLoader, LazyAccount, and Migration, including inside Box or Option.
• The fix (#5011) ships in Anchor v1.2.2 (milestone). Upgrade to v1.2.2 and rebuild.
• Until you can upgrade, declare an account you reassign through a CPI as UncheckedAccount or AccountInfo. These skip Anchor's owner and discriminator checks, so check the account's owner and type yourself.

• Wallets, frontends, bots, indexers, and tools that build, decode, or simulate transactions need no changes. Transaction format, RPC methods, and account data are unchanged.
• If your app calls another team's program, ask them whether they have tested on devnet. Report failures with the link to the SVM Scope replay (https://svmscope.vercel.app/tx/<signature>).

• Stay at or above the mainnet version floor for Agave and Firedancer. Every release at or above it contains both gates. The Feature Gate Tracker lists the floor and the mainnet epoch.
• There is nothing to configure.

Account data and region violations fail loudly: the instruction returns an error, the transaction fails, and account state does not change. Stack layout changes are the exception (see below).

Breaking Change: Every Account Data Access Is Checked

Every read is checked against the account's current length. Every write is checked against the account's owner and writable flag, and, if it reaches past the end, against the resize limits. Before, a bad access went unnoticed if it stayed inside the reserved address space or if a write was undone before the program returned.

Simulation and getTransaction results carry the bare variant name, for example {"InstructionError": [0, "AccountDataTooSmall"]}. Logs, including solana logs and solana confirm -v, print the sentence, for example Program <id> failed: account data too small for instruction.

Writes inside a writable account your program owns work as before. A write past the end is treated as a resize: it succeeds, and the runtime zero-extends the account, as long as it stays within the growth limits: 10 KiB per instruction, 10 MiB per account, and the transaction's total growth cap. Beyond that padding, or outside any account, you get a generic access violation (Program <id> failed: Access violation ..., reported as ProgramFailedToComplete).

A common cause: a program casts account bytes to a fixed-size struct and the account is shorter than the struct.

Two fixes that do not work. Catching the error in a calling program fails because the error aborts the transaction. Restoring the old bytes after a write fails because the runtime checks the write, not the final value. Remove the write.

AccountInfo::realloc was deprecated in solana-account-info 2.3.0 and removed in 3.0.0. Called with zero_init = false, it grows the length without writing the new bytes, so the first read of them is a read past the real end and fails with InvalidRealloc. Use AccountInfo::resize, which always zero-fills.

Breaking Change: Accesses Cannot Span Memory Regions

The virtual machine gives a program separate address ranges, called regions: its read-only data, the stack, the heap, and, in the input area, each account's metadata, each account's data, and the instruction data. A load, store, or syscall that crosses from one region into the next is an access violation once the gate is active.

For example, the serialized input places each account's 8-byte length field directly before its data. A program that copies both in one go relied on that layout:

// Before: one copy that starts in the account's metadata and ends in its data.
// An access violation once the gate is active.
let data = account.try_borrow_data()?;
let mut header = [0u8; 40];
unsafe {
    core::ptr::copy_nonoverlapping(data.as_ptr().sub(8), header.as_mut_ptr(), 40);
}

Read each part from its own region instead:

// After: one access per region.
let data = account.try_borrow_data()?;
let body = data.get(..32).ok_or(ProgramError::AccountDataTooSmall)?;
let mut header = [0u8; 40];
header[..8].copy_from_slice(&(data.len() as u64).to_le_bytes());
header[8..].copy_from_slice(body);

Slices from the SDK stay inside one region, so this mostly affects unsafe code and hand-written syscalls.

Breaking Change: Stack Frame Gaps Are Removed

SIMD-0460 removes the unmapped gaps between stack frames for every program, including sBPFv0 programs, which still have them. With the gate active, the stack is one contiguous range at lower addresses. For sBPFv0 programs, each call or callx (indirect call) moves the stack pointer 4 KiB instead of 8 KiB, as sBPFv3 already does. The total stack size does not change.

This can break programs that use absolute stack addresses, do address math across frames, or rely on an out-of-bounds access stopping at a frame boundary.

• An access outside the new, smaller range, such as an absolute address into the old upper half, fails with an access violation.
• An access inside it does not fail. An overrun that would have hit a gap reads or writes the neighboring frame instead, and an absolute address that worked before may point at a different frame's bytes. The program keeps running with different data and no error.

Anza's replay found one program that used slightly fewer compute units with the gate on and no other difference. The suspected cause is an out-of-bounds stack access. If a program shows an unexplained compute unit change, check for a stack overrun, and test stack-heavy unsafe code on devnet.