Solana Protocol Specification

Mainnet reference epoch: E = 1072

Table of contents

1. Scope and conformance
2. Normative language and conventions
3. Terminology and system model
4. Account state
5. Common types, cryptography, and serialization
6. Validator wire protocols
7. Transactions and messages
8. Proof of History and entries
9. Shreds, erasure coding, and block reconstruction
10. Slot and block validity
11. Deterministic state transition
12. SVM, loaders, syscalls, and precompiles
13. Protocol-owned programs and sysvars
14. Consensus hashes and commitments
15. Consensus, voting, and finality
16. Epochs, leader schedule, stake, fees, and rewards
17. Feature activation, versioning, and hard forks
18. Security and adversarial considerations

Appendices:

• Appendix A — Constants, identifiers, and limits
• Appendix B — Wire-layout and disposition index
• Appendix C — Mainnet feature manifest
• Appendix D — Source references

Revision history

Informative table.

1. Scope and conformance

1.1 Scope

This specification defines the observable protocol rules needed to decode and produce interoperable Mainnet data, decide validity, reconstruct ordered blocks, execute deterministic state transitions, calculate consensus commitments, and participate safely in consensus under the protocol configuration active in reference epoch E.

The scope is forward conformance only. An implementation starts from a trusted epoch-E snapshot or another state authenticated to an epoch-E root and continues under this specification. It need not ingest, replay, emit, or preserve encodings and rule branches that ceased to be accepted before E. Activation epochs remain in Appendix C only to identify how the epoch-E configuration was selected; they do not re-enable historical behavior. A later Mainnet activation requires a revised specification whose affected normative sections describe the new behavior directly.

The specification applies to banks whose derived epoch is E. If the trusted starting root is the last bank before E, child-bank construction applies the epoch-E boundary transition exactly once before that child’s transactions. If the trusted starting state is already within E, that state already includes the boundary transition and it must not be applied again. This specification does not define the first bank of E+1.

This specification does not standardize process architecture, stages, channels, databases, caches, thread scheduling, host execution strategy, or operator interfaces.

1.2 Conformance roles

The following codes identify independently referenceable protocol roles and the rules applicable to each component.

Normative table.

When this specification gives an exact byte representation, SOL-CNF-0002 emits that canonical representation and SOL-CNF-0001 applies the specified accepted domain. Chapter 6 requirements define minimum codec, authentication, and peer-interaction interoperability. Its explicitly informative active-liveness profiles document deployed operating parameters but are not additional conformance roles.

1.3 Explicit exclusions

JSON-RPC schemas, CLI output, explorers, telemetry, local blockstore and account-index layouts, snapshot archive compression, bootstrap convenience flows, operating-system configuration, hardware sizing, performance tuning, peer-scoring heuristics, transaction-selection policy, and arbitrary application-program semantics are outside scope except when a specific rule demonstrably changes protocol interoperability, validity, deterministic state, a consensus commitment, voting, consensus selection, finality, or necessary liveness.

2. Normative language and conventions

2.1 Requirement force

The uppercase terms MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY carry normative force only inside a paragraph bearing a requirement identifier. “Must” indicates an absolute condition; “should” indicates a condition for which a documented, interoperability-safe exception can exist; “may” grants an option. Lowercase forms and “shall” have no normative force in this specification.

2.2 Numeric conventions

u8, u16, u32, u64, and u128 denote unsigned integers of the stated width. i64 denotes a two’s-complement signed 64-bit integer. LE(x,n) and BE(x,n) denote the n-byte little- and big-endian encodings of integer x. Byte intervals use half-open notation [start,end). Unless a requirement states otherwise, mathematical pseudocode uses unbounded integers; conversion to a fixed-width type is permitted only after its stated range check.

Arithmetic that contributes to validity, state, scheduling, or a commitment uses the checked, saturating, wrapping, or truncating behavior named by the applicable algorithm; host-language default overflow behavior never determines a protocol result.

Byte strings concatenate with ||. len(x) is a nonnegative mathematical integer. Array indices are zero-based. A public-key comparison is lexicographic comparison of its 32 raw bytes unless stated otherwise.

2.3 Ordering and ties

When a threshold is written as a/b > p, equality does not pass. When written a/b >= p, equality passes. Implementations use the exact integer cross-multiplication form where one is specified; a floating-point expression quoted as implementation evidence is not itself permission to substitute a numerically different comparison.

2.4 Diagrams, examples, and evidence

Tables and pseudocode labeled Normative are authoritative. Diagrams, rationale, examples, source anchors, and implementation notes are informative unless an identified requirement incorporates a value or relation they contain. The sources in Appendix D and the SIMDs in Appendix C do not silently extend the numbered requirements.

3. Terminology and system model

3.1 Terms

Normative table.

3.2 System model

A protocol configuration contains immutable chain identity, the feature state active in reference epoch E, and the parameters needed to interpret blocks. A parent state contains all accounts and consensus metadata committed at its slot. A candidate block supplies its parent relation, leader, shreds, entries, and ordered transactions. The protocol validates representation and block structure, applies the deterministic state transition, freezes commitments, and exposes the resulting bank state to consensus.

Informative diagram.

@startuml
left to right direction
rectangle Packets as P
rectangle "Authenticated messages\nand shreds" as A
rectangle Reconstruction as R
rectangle "Candidate block" as C
rectangle "Parent state" as S
rectangle "Protocol configuration" as G
rectangle ApplyBlock as B
rectangle "Results, post-state,\nand commitments" as O
rectangle "Vote eligibility" as V
rectangle "Consensus selection" as F
rectangle "Root and finality" as T
P --> A
A --> R
R --> C
S --> B
G --> B
C --> B
B --> O
O --> V
V --> F
F --> T
@enduml

3.3 Determinism boundary

Determinism applies at four different boundaries:

Normative table.

Accepted byte domains, ordered block content, committed account state, capitalization, consensus hashes, stake weight, leader assignment, consensus selection for a given observation set, safe Alpenglow votes, roots, and finality may not vary for equal applicable protocol inputs. Storage layout, execution strategy, and local retention policy do not enter any commitment.

4. Account state

4.1 Account map and value

Protocol state is a map from a 32-byte account address to a nonzero-lamport account value. The address is the map key and is not repeated inside the account value. A committed zero-lamport value is logical deletion: later transactions in that bank and all descendants load the address as absent. An executor may retain a transient zero-lamport record while committing or rolling back a transaction, but that record is not a distinct protocol account state.

Normative table.

There is no universal wire serialization for an account value. Transactions name accounts by address, protocol-owned programs define the byte grammar of their data, the SBF program-input representation is defined in Section 12.8.6, and account hashing is defined in Section 14.4. A database record layout is not a protocol encoding.

[SOL-ACC-0001] A bank MUST reject any state transition that would produce account data longer than 10,485,760 bytes, a lamport value outside u64, or an account value lacking exactly one 32-byte owner.

[SOL-ACC-0002] Every account replacement MUST be keyed by the account’s 32-byte address and MUST update capitalization and account-state commitments according to Chapters 11 and 14.

4.2 Ownership and mutation limits

An instruction may change an account only through the privileges and ownership rules established by the transaction and invocation context. SBF ABI v1 reserves 10,240 bytes after each account’s original data for growth during one instruction. Across a transaction, the aggregate positive data-length change is at most 20,971,520 bytes, while every individual account remains bounded by 10,485,760 bytes.

[SOL-ACC-0003] An instruction MUST NOT increase one account’s data length by more than 10,240 bytes relative to that instruction’s entry length, and a transaction MUST NOT produce aggregate positive account-data growth greater than 20,971,520 bytes.

[SOL-ACC-0004] Only the account owner MAY modify account data or change its length, except for an explicit protocol-program transition; only a writable account MAY have lamports, data, owner, or executable state changed.

[SOL-ACC-0005] An instruction MUST conserve the sum of lamports across its instruction accounts, may debit lamports only from accounts owned by the executing program, and MUST treat any account that commits with zero lamports as logical deletion regardless of its transient data, owner, or executable fields.

4.3 Account lifecycle

Informative diagram.

@startuml
[*] --> Absent
Absent --> Present : allocate or credit
Present --> Present : authorized mutation
Present --> Executable : loader finalizes program
Executable --> Executable : authorized upgrade
Present --> Absent : zero lamports and reclaim
Executable --> Absent : loader closes program
@enduml

[SOL-ACC-0006] Creation, allocation, assignment, executable transition, truncation, and closure MUST occur only through the protocol-program rule authorizing that transition. A committed account with zero lamports MUST be removed from the logical account map before the next transaction is loaded; just writing a field-shaped byte sequence does not create protocol state.

4.4 Bank metadata

Consensus metadata associated with the account map includes slot and epoch data, recent blockhashes, replay-protection ancestry, transaction/signature/compute counters, capitalization, reward and fee accumulators, the accounts-state accumulator, and the bank hash. These values are bank state even when they are not represented by ordinary accounts.

5. Common types, cryptography, and serialization

5.1 Scope and notation

This chapter defines the byte-level primitives used by the validator wire and ledger chapters. It is intentionally a small, protocol-specific subset of the libraries from which the behavior was recovered. Presentation encodings such as base58 are not wire encodings unless another chapter explicitly says so.

5.2 SHA-256 and Ed25519

SHA256(x) below means FIPS 180-4 SHA-256 over the exact byte string x. It does not include a length, terminator, or serialization wrapper.

[SOL-GEN-0003] A protocol hash written SHA256(x1 || ... || xn) MUST feed the listed byte strings to one SHA-256 invocation in the listed order and MUST NOT hash a textual rendering of any operand.

[SOL-GEN-0004] Verification of a signed gossip value, gossip ping or pong, signed repair request, or leader-signed shred MUST reject a malformed public key or signature, an S scalar greater than or equal to the Ed25519 group order, a small-order public key or R point, or a signature that fails the Ed25519 verification equation. A receiver MUST NOT broaden this strict Mainnet rule just because its cryptographic library accepts additional noncanonical compressed Edwards encodings.

[SOL-GEN-0005] A signature MUST be verified against the signer, message bytes, and domain construction named by the enclosing protocol; a valid signature for a different field serialization or domain MUST NOT authenticate the object.

5.3 Codec registry and canonical fixed-integer serialization

A reference to a serialization library, including “bincode” or “wincode,” is not sufficiently precise for a protocol boundary. This specification therefore assigns a named codec to every reusable protocol-object family with a byte grammar and defines the accepted bytes directly. An implementation may use any serializer that produces and accepts exactly these bytes; a library name, version, default configuration, or host-language data layout never overrides this section or an enclosing type table.

A codec may compose another codec. For example, a repair response can contain one raw shred, and a ledger component can contain transactions inside Entries. Transport state machines, erasure-code mathematics, cryptographic preimage recipes, and raw fixed-size keys, signatures, or hashes are not separate codecs just because their algorithms consume bytes. Their enclosing section remains authoritative.

Normative table. Codec registry.

[SOL-GEN-0006] A protocol object belonging to a registered surface MUST be encoded with the assigned enclosing codec and every nested codec it names. A receiver MUST NOT retry a failed decode with another serializer configuration, accept a variable-integer substitute for a fixed integer, or derive field order from reflection metadata.

[SOL-GEN-0007] A value described as using canonical fixed-integer serialization MUST use the applicable layout below. Fields are serialized in the order in which the enclosing table lists them, with no alignment, padding, field names, or end marker unless that table explicitly includes one.

Normative table. FIXINT-LE primitive layouts.

An enclosing byte-layout table may deliberately specify a different tag, length width, compact integer, conditional field, padding region, or trailing capacity. That more specific table controls that type. A map without an enclosing key order has no canonical protocol encoding; hash-table iteration order is never an encoding rule.

[SOL-GEN-0008] A decoder for a datagram or a complete QUIC application message MUST consume the entire application byte string and MUST reject a truncated field, an impossible length, integer overflow, or trailing bytes not assigned by that message format.

The exception to exact consumption is an enclosing format that gives an explicit length or expressly permits unused capacity or trailing bytes, such as a data shred’s size field, the four-byte repair nonce after a shred, a Vote account, or a program instruction whose section says that its decoder permits a suffix.

5.4 ShortU16 and compact integers

ShortU16 is an unsigned, least-significant-group-first base-128 integer. The low seven bits of each byte carry data and bit 7 indicates another byte.

Normative table. SHORT-U16 canonical ranges.

[SOL-GEN-0009] A canonical ShortU16 MUST encode values 0 through 127 in one byte, 128 through 16383 in two bytes, and 16384 through 65535 in three bytes; a sender MUST use the shortest form.

[SOL-GEN-0010] A ShortU16 receiver MUST reject a fourth byte, continuation on the third byte, nonzero bits above bit 15, and an overlong encoding whose last seven-bit group is zero.

The ContactInfo version and wallclock fields use the same unsigned base-128 rule at their stated u16 or u64 width rather than the three-byte ShortU16 cap.

[SOL-GEN-0011] An unsigned LEB128 field MUST terminate within the number of seven-bit groups required by its declared width and MUST reject overflow and a non-minimal final zero group.

5.5 Program-derived addresses

Although program-derived addresses are most visible during execution, they are a common 32-byte identity primitive and are fixed here once.

[SOL-GEN-0012] create_program_address(seeds, program_id) MUST reject more than 16 seeds or any seed longer than 32 bytes, then compute SHA256(seed[0] || ... || seed[n-1] || program_id || "ProgramDerivedAddress"), where the marker is the 21 ASCII bytes and program_id is 32 raw bytes.

[SOL-GEN-0013] The digest from create_program_address MUST be rejected if it decompresses as an Ed25519 curve point and otherwise MUST be returned as the 32-byte address.

[SOL-GEN-0014] find_program_address MUST append a one-byte bump seed to the caller’s seed list, try bump values from 255 down through 1, and return the first address accepted by create_program_address together with that bump. If none of those 255 values succeeds, the search has no result; bump zero is not tested by the active search operation. Because the appended bump counts as a seed, a caller list of 16 seeds cannot produce a result under the 16-seed create_program_address ceiling.

5.6 Resource-safe decoding

[SOL-GEN-0015] Before allocating or advancing by a peer-supplied count or length, a receiver MUST prove that the operation fits both the remaining input and the protocol-specific bound; allocation failure or host-width conversion MUST NOT change acceptance into partial decoding.

6. Validator wire protocols

6.1 Datagram boundary and dispatch

[SOL-WIR-0001] A gossip, repair, TPU-vote, or TVU receiver MUST treat one UDP datagram as one complete application message, enforce the 1,232-byte limit, and reject a message if its grammar does not consume the datagram exactly.

6.2 Gossip envelope and CRDS pull filter

Every gossip datagram begins with a u32 little-endian Protocol discriminant. A Vec<T> below is the Chapter 5 sequence form: an eight-byte little-endian count followed by that many T values.

Normative table.

[SOL-WIR-0002] A gossip decoder MUST reject a discriminant outside 0..=5, an invalid nested value, a payload larger than 1,232 bytes, or trailing bytes. The combined serialized CrdsValue bytes in a push or pull response MUST NOT exceed 1,188 bytes.

CrdsFilter is serialized in the following order. BitVec<u64> bit number i is bit (i mod 64)—least significant bit first—of block floor(i/64).

Normative table.

The Bloom phantom type has zero bytes. For a CRDS identity hash h[32], let hu = LE_decode(h[0..8]), low = (!0u64) >> mask_bits when mask_bits < 64 and 0 otherwise, and canonical_mask = mask | low. The hash belongs to the filter’s partition exactly when (hu | low) == canonical_mask.

For every Bloom seed k, calculate a seeded FNV-1a state over all 32 bytes of h: initialize state = k; for each byte b, set state = (state XOR b) * 0x00000100000001b3 mod 2^64. Its Bloom position is state mod bit_length. Membership is true only if the partition comparison passes, the keys and bit vector are both nonempty, and every seeded position is set.

[SOL-WIR-0003] An accepted pull filter MUST have mask_bits >= 6; its bit length MUST NOT exceed the capacity of its serialized blocks. A sender MUST set every low bit of mask selected by low, while a receiver MUST ignore those low bits by using canonical_mask as defined above.

[SOL-WIR-0004] In answering a PullRequest, a validator MUST consider only CRDS values whose identity hash belongs to the requested mask partition and is absent from the Bloom filter; a Bloom false positive may omit a value but MUST NOT make an out-of-partition value eligible.

6.3 CRDS values and payload grammars

A CrdsValue is a 64-byte Ed25519 signature followed by a CrdsData: a four-byte little-endian discriminant and its payload. Its cached identity is not serialized.

Normative table. CRDS discriminants and independent processing status.

For discriminants 0, 3, 4, 6, 7, and 8, “known tag” means only that the enum discriminant is assigned. The epoch-E decoder deliberately returns an error while decoding its zero-sized deprecated payload, before signature verification, sanitation, label derivation, or insertion. In particular, deprecated NodeInstance values are never compared as duplicates or retained in the CRDS table.

All wallclock and slot values identified as bounded in this section must be strictly less than 10^15. The exact non-ContactInfo payload layouts are:

Normative table.

A CompressedSlots starts with a u32 discriminant and has one of these layouts. BitVec<u8> uses the same option/count/bit-length grammar as the Bloom bit vector, except its blocks are bytes and bits within a byte are least-significant-bit first.

Normative table.

The compressed form is RFC 1951 DEFLATE without a zlib header. Inflation must terminate successfully; the output bytes form the BitVec blocks. For either form, first_slot < 10^15, num < 16,384, and selected bit i denotes slot first_slot + i for 0 <= i < num. An uncompressed vector’s bit length must be a multiple of eight and equal its block capacity.

SlotsOffsets starts with u32 discriminant 0 for run-length encoding or 1 for raw offsets. Run-length encoding is a u64 element count followed by canonical unsigned-LEB128 u16 run lengths; runs alternate selected, unselected, selected, beginning with selected. Raw offsets is BitVec<u8>. In either form selected offset i denotes last_voted_slot - i; an underflow does not denote a slot.

[SOL-WIR-0005] A CRDS Vote transaction MUST satisfy Chapter 7 transaction sanitation and decode as a vote instruction; LowestSlot MUST have zero root, empty slots, empty stash, and bounded lowest and wallclock. Every SnapshotHashes incremental slot MUST be bounded and strictly greater than the full-snapshot slot; a sender MUST NOT publish more than 25 incremental hashes in one value.

[SOL-WIR-0006] A CRDS-valid DuplicateShred chunk MUST have num_chunks > 0 and chunk_index < num_chunks; insertion does not impose the assembly limit. A duplicate-proof consumer MUST discard a chunk from assembly when num_chunks > 3. Assembly state is keyed by (from,slot), not by the outer CRDS index. Receiving an assembly-eligible chunk replaces the buffered chunk at its chunk_index; when the number of occupied indices equals the received num_chunks, every buffered chunk MUST agree on slot and num_chunks. Concatenating chunk bytes in index order 0..num_chunks-1 then yields exactly u64 length || shred1 || u64 length || shred2. Both nested shreds MUST pass Chapter 9 and constitute a valid same-slot duplicate proof. The outer index is only the CRDS table label and MUST NOT partition assembly state.

[SOL-WIR-0007] A CrdsValue signature MUST verify under the from or ContactInfo public key contained in its payload over the exact bytes beginning with the CrdsData discriminant. Its identity MUST be SHA256(signature[64] || serialized_CrdsData). A PullRequest’s embedded value MUST be discriminant 11 ContactInfo; every pushed or returned value MUST pass its payload constraints and strict signature verification.

6.3.1 CRDS replicated-table transition

Normative table. CRDS label derivation.

For a label already present, new replaces old according to this total order. ContactInfo first compares (outset, wallclock) lexicographically when the public keys agree. If those tuples differ, the larger tuple wins. For all other cases, and for equal ContactInfo tuples, larger wallclock wins; equal wallclocks are broken by the lexicographically larger 32-byte CRDS identity hash. Replacing a value records the displaced hash in the recently-purged set. An unequal losing value records its own hash there. An equal hash is a duplicate: it leaves table bytes and insertion order unchanged; a push-route duplicate increments only its saturating local duplicate count.

[SOL-WIR-0008] A CRDS table MUST derive labels and apply replacement in the order above. An implementation MUST NOT merge two values sharing an origin but having different indexed labels. In particular, EpochSlots is a logical union only when consumed: decode each surviving indexed value, union selected slots for the origin, remove duplicates, and order the resulting slots ascending.

Push accepts a signed value only when its wallclock is in the inclusive window [now-15,000 ms, now+15,000 ms]. Pull accepts a caller ContactInfo only when its wallclock is in the half-open window [now-15,000 ms, now+15,000 ms). One responder-wide random jitter j in 0..3,750 ms is added to the caller wallclock; a pull response selects, in table insertion order, nondeprecated values matching the requested partition, absent from the Bloom filter, satisfying value.wallclock <= caller+j, and fitting the response byte budget. A receiver inserts an otherwise-new pull value if now <= value.wallclock + timeout(origin); an expired value may be retained only when ContactInfo for its origin already exists, so it can assist replacement and purge decisions.

The default origin timeout is 15,000 ms. The local identity never expires. An identity with positive epoch stake uses max(15,000 ms, epoch_duration_ms); when every supplied stake is zero, all identities use that extended timeout. If an origin’s ContactInfo has min(value.wallclock, local_receive_time)+timeout > now, every label of that origin is retained. Otherwise each label expires when the same expression is <= now. Displaced and rejected-outdated hashes remain in pull Bloom filters for 20,000 ms.

The preceding windows, insertion-order response selection, retention timeouts, and Bloom-filter retention describe the active network’s liveness profile. They are informative: local time and peer observation are not replicated state, and a different safe retention or selection policy does not make a bank invalid. Signed-value constraints, labels, replacement order, filter partitioning, response byte grammar, and receiver-side revalidation remain normative.

[SOL-WIR-0009] Push duplicate suppression, pull selection, expiration, and purge MAY vary without changing protocol state. A pull response MUST contain only individually valid values in the requested partition and MUST NOT knowingly include a value selected by the requester’s Bloom filter. The receiver MUST independently apply SOL-WIR-0007 and SOL-WIR-0008. Completed DuplicateShred evidence MUST follow SOL-WIR-0006; incomplete assembly may be evicted at any time and has no consensus effect.

The push active set contains 12 peers per stake bucket and sends each eligible new value to the first nine unpruned peers. There are 25 buckets. For stake s lamports define b(s)=min(24, bit_length(floor(s/1,000,000,000))); a value owned by o uses bucket min(b(local_stake),b(stake(o))). Peer sampling is without replacement with weight (min(peer_bucket,bucket)+1)^2; zero-weight peers follow positive-weight peers. A valid Prune applies only at its named destination, only within 500 ms of local time, and marks each named origin as suppressed for pushes to the prune sender in the applicable bucket. A node’s own values are never suppressed by a prune false positive.

[SOL-WIR-0010] A sender MUST honor authenticated, timely prune state. Active-set size, stake buckets, sampling, rotation timing, and fanout cap are informative liveness policy. A sender MUST NOT send a value to a peer for which the applicable prune filter positively contains that origin, except its own origin as stated above.

6.4 Ping, pong, and prune

Normative table.

[SOL-WIR-0011] A Ping signature MUST verify under from over the 32 token bytes. Its expected Pong hash MUST be SHA256("SOLANA_PING_PONG" || token), where the prefix is the 16 ASCII bytes. A Pong signature MUST verify under its from key over the hash, and a Pong used as reachability evidence MUST match an outstanding Ping.

Normative table.

[SOL-WIR-0012] A PruneMessage MUST have an outer key equal to PruneData.pubkey, no more than 32 pruned keys, and wallclock < 10^15. The signature MUST verify over the serialization of (pubkey, pruned keys, destination, wallclock), either directly or preceded by the byte string ff 53 4f 4c 41 4e 41 5f 50 52 55 4e 45 5f 44 41 54 41; the prefixed form includes LE(18,8) before those 18 prefix bytes.

6.5 ContactInfo

Mainnet uses shred version 50093 in epoch E. ContactInfo discriminant 11 has this exact field order:

Normative table.

The low 14 bits of packed minor are the minor version. Bits 14–15 select stable (0), release candidate (1), beta (2), or alpha (3). For stable, the next value is the semantic patch; otherwise the semantic patch is zero and the next value is the prerelease number.

Normative table.

The socket port accumulator begins at zero. For each entry in encoded order, add its offset with checked u16 arithmetic; that accumulated port and the indexed address form the endpoint.

Normative table. ContactInfo socket-key registry.

[SOL-WIR-0013] A valid ContactInfo MUST contain only unique IPv4 addresses and unique socket keys, every socket index MUST be in range, and every address MUST be referenced. Port addition MUST NOT overflow; port zero, unspecified, multicast, and IPv6 endpoints MUST be rejected.

[SOL-WIR-0014] ContactInfo wallclock MUST be less than 10^15. A peer used for Turbine or repair MUST advertise shred version 50093. Unknown extension types MUST be skipped by their declared length and unknown socket keys MUST NOT be assigned a known service meaning.

6.6 TPU QUIC, TPU-vote UDP, and TLS

[SOL-WIR-0015] Ordinary TPU and TPU-forward ingestion MUST use QUIC and MUST NOT accept transaction application data through ContactInfo keys 5 or 6. A TPU-vote UDP datagram contains exactly one Chapter 7 transaction with no application framing. A TPU, TPU-forward, or TPU-vote QUIC connection MUST negotiate the ten-byte ALPN solana-tpu, and each completed requester-initiated unidirectional stream MUST contain exactly one transaction. The stream is nonempty, consumes all bytes, and is at most 4,096 bytes. Chapter 7 then applies the format-specific transaction limit: 1,232 bytes for legacy and version 0, or 4,096 bytes for version 1. The UDP form remains limited to 1,232 bytes by Section 6.1.

[SOL-WIR-0016] A TPU receiver MUST pass only QUIC’s ordered, reassembled bytes from one completed unidirectional stream to the transaction decoder. It MUST reject a bidirectional stream, QUIC datagram application data, or bytes concatenated across streams. A packet gap leaves the stream incomplete until QUIC retransmission or timeout; it is not an application decode error. Transport certificates do not authorize a transaction; Chapter 7 signatures do.

Informative table. Active QUIC liveness and resource profile.

Let peer_stake and total_stake be unsigned epoch-stake lamports and let rtt_ms = min(floor(measured_RTT_in_microseconds / 1000),350). Compute the post-handshake unidirectional-stream limit with unsigned floor arithmetic:

Normative algorithm.

if peer is unstaked:
    base = 128
else if total_stake == 0 or peer_stake > total_stake:
    base = 128
else:
    base = clamp(floor(binary64(peer_stake) / binary64(total_stake) * 99872)
                 + 128,
                 128, 512)

stream_limit = floor(base * clamp(rtt_ms,50,350) / 50)

The two integer stake values are converted separately to IEEE-754 binary64; the quotient and multiplication are binary64 round-to-nearest-ties-to-even, and conversion to u32 truncates toward zero before adding 128. The final multiply saturates in u32 before integer division.

The canonical active sender profile presents one Ed25519 end-entity certificate. Its DER certificate is 249 bytes: the fixed X.509 template has Ed25519 OID 1.3.101.112, serial 01 repeated eight times, issuer CN Solana node, validity 1970-01-01 through 4096-01-01, empty subject, a critical DNS SAN localhost, critical empty basic constraints, and a deliberately invalid 64-byte all-ff certificate signature. The only variable certificate bytes are the 32-byte Ed25519 SubjectPublicKeyInfo. The corresponding PKCS#8 private key is the 16-byte prefix 30 2e 02 01 00 30 05 06 03 2b 65 70 04 22 04 20 followed by the 32-byte Ed25519 secret scalar.

Informative table. Canonical dummy-certificate byte construction.

Certificate-chain, issuer, time, SAN, SNI and certificate-signature validation are deliberately not trust anchors. The TLS 1.3 CertificateVerify signature under the certificate public key is mandatory. A server extracts a peer identity for stake QoS only from a one-certificate chain whose SPKI is exactly 32 Ed25519 bytes; failure to extract it classifies the peer as unstaked rather than authenticating a transaction. A requester supplies SNI <decimal-IP>.<decimal-port>.sol; the responder does not match it to the SAN.

[SOL-WIR-0017] Both endpoints MUST verify TLS handshake signatures and MUST require client authentication at the handshake, while ignoring PKI chain, name, time, and dummy-certificate-signature validation as described above. A transport identity MUST NOT replace transaction signatures.

[SOL-WIR-0018] A requester MUST finish each transaction stream. EOF after 1..=4,096 bytes delivers one packet to the Chapter 7 decoder; reset, stop, timeout, zero bytes, 4,097 bytes, a second transaction in the stream, or a transaction split between streams discards that stream without an application response. A responder MAY close or reset throttled streams or connections; the sender then retries by opening a new stream or connection and MUST NOT infer transaction acceptance from transport completion.

Informative table. QUIC application close codes in the active liveness profile.

Repair and TVU use UDP in epoch E; their recognized QUIC socket keys do not select this TPU ALPN or transaction stream grammar. TPU, TPU-forward, and TPU-vote QUIC differ only in advertised endpoint and downstream transaction classification. TPU-vote additionally accepts the UDP form above.

6.6.1 Alpenglow votor QUIC datagrams

The ContactInfo key-13 endpoint carries Alpenglow votes and certificates. This service is independent of TPU transaction ingestion.

Normative table. Alpenglow transport profile.

Certificate construction and acceptance use the identity-certificate rules in Section 6.6. The TLS CertificateVerify signature binds possession of the advertised node identity. A certificate whose Ed25519 public key cannot be extracted, or whose identity is not in the admitted staked-node set, does not create an unstaked Alpenglow peer; the connection is rejected. Vote verification maps that node identity to its vote-account rank, effective stake, and BLS public key for the target slot’s epoch.

[SOL-WIR-0019] An Alpenglow endpoint MUST negotiate the transport profile above, MUST NOT accept consensus messages on a QUIC stream, and MUST NOT accept early data. It MUST discard a datagram that is truncated, has trailing bytes, has another shred version, has an unknown version or kind, or exceeds the negotiated datagram size. Transport receipt is not a vote: Chapter 15 signature, rank, and stake checks remain mandatory.

The datagram payload uses the ALPENGLOW-WIRE-E1072 codec in Section 15.2. QUIC connection counts, handshake-rate governors, send retry intervals, and queue capacities beyond the interoperability values above are local liveness policy rather than consensus or ledger validity rules.

6.7 Repair

Repair requests use a u32 little-endian top-level discriminant. Variants 0..=6 are obsolete unsigned forms and are rejected. Variant 7 is a Pong; variants 8..=11 begin with this signed header:

Normative table.

Normative table.

[SOL-WIR-0020] The signature for variants 8..=11 MUST verify under the header sender over LE(discriminant,4) || bytes[68..end]; the signature field itself is omitted. The recipient MUST be the receiving identity and the timestamp MUST be within 600,000 milliseconds of current Unix time.

Ordinary shred responses are one raw Chapter 9 shred followed by the request nonce as u32 little-endian. Repair ping challenges use discriminant 0, then the 128-byte Ping layout from Section 6.4, for a total of 132 bytes.

Normative table.

[SOL-WIR-0021] A repair response MUST end in the outstanding request’s nonce and match its request: WindowIndex requires the exact slot and index; HighestWindowIndex requires the exact slot and an index not below the request; Orphan permits at most 11 responses with shred slot not above the request; AncestorHashes permits at most 30 pairs. Every returned shred MUST pass Chapter 9 before use.

6.8 Turbine carriage

[SOL-WIR-0022] A TVU UDP datagram MUST carry exactly one raw Chapter 9 shred without an application header. Before reconstruction, the receiver MUST validate the shred’s version, byte layout, Merkle proof, and leader signature.

[SOL-WIR-0023] Forwarding MUST NOT alter bytes covered by the leader-signed Merkle root. A retransmitter signature, when present in its Chapter 9 trailer, is carried unchanged by subsequent forwarding and does not replace leader authentication.

6.8.1 Epoch-E Turbine topology

This subsection is the minimum network-liveness profile for a validator wire sender. Its permutation and forwarding requirements promote interoperable delivery, but a peer’s fanout choice is not ledger data and does not make an otherwise valid shred or block invalid.

For one shred identity (slot,index,type) and scheduled leader L, form the 32-byte seed SHA256(LE(slot,8) || type_u8 || LE(index,4) || L[32]), where type_u8 is 0xa5 for data and 0x5a for coding shreds. Initialize ChaCha8 with this seed, counter zero, stream zero, the RFC 8439 constants, and four column/diagonal double rounds per 64-byte block. The RNG exposes each block as consecutive little-endian u32 words; next_u64 concatenates the next two words with the first as the low half.

Construct the candidate node vector from every positive-stake identity in the slot’s epoch stake map, every current gossip identity with a valid key-10 TVU UDP address, and the local identity. Sort by descending (stake,pubkey) and deduplicate by pubkey, preferring the record with ContactInfo. Then traverse that order and retain only the first usable key-10 endpoint for each exact (UDP,socket-address) and only the first usable key-10 endpoint for each IP address. For a later duplicate, remove its endpoint: retain the identity if its stake is positive, but drop it when its stake is zero and it has no other active TVU endpoint. This address deduplication is part of the permutation input, not just a send-time filter. The leader is removed. Give node i weight equal to its epoch stake in lamports. To sample from total positive weight T, set zone=(T << leading_zeros(T))-1; repeatedly draw RNG x, compute p=x*T as u128, hi=p>>64, lo=p mod 2^64, and accept hi when lo<=zone. Select the least index whose cumulative remaining weight exceeds hi, remove that weight, and repeat. After positive weights are exhausted, select zero-weight indices uniformly by the same multiply-high method and swap-remove each selected index. This produces the per-shred permutation P.

Normative algorithm. Turbine fanout tree (F=200).

leader sends the shred to P[0]
for a node at permutation index i:
    offset = saturating_sub(i, 1) mod F
    anchor = i - offset
    step = 1 if i == 0 else F
    child indices are the first F in
        anchor*F + offset + 1, +step, +step, ...
        that are less than len(P)
parent(i):
    none when i == 0
    offset = (i-1) mod F
    q = floor((i-1)/F)
    base = q - saturating_sub(q,1) mod F
    parent index = base if base == 0 else base + offset

[SOL-WIR-0024] A leader MUST originate each valid shred to P[0]. A TVU participant receiving a newly accepted broadcast shred MUST forward it to the available key-10 UDP addresses at its child indices, in tree order, with at most 200 children and at most four hops. It MUST NOT retransmit a shred received as a repair response. Missing, stale, duplicate-IP, or invalid TVU addresses are skipped; repair under Section 6.7 is the fallback for the resulting holes.

[SOL-WIR-0025] Turbine membership is evaluated from the participant’s current authenticated gossip view, so two participants may omit different unreachable addresses without changing shred or block validity. The stake weights, seed, ChaCha8 word stream, sampling rule, and index-to-child mapping MUST NOT be replaced by an implementation-dependent shuffle.

7. Transactions and messages

7.1 Scope and notation

This chapter specifies the three Mainnet message formats in epoch E: legacy, version 0, and version 1. It defines their envelopes, sanitation, address resolution, signature checks, compute-budget interpretation, fee-payer validation, and account loading.

Every compact-u16 in this chapter is the single authoritative ShortU16 codec in Section 5.4; this chapter does not define a second compact-integer encoding.

[SOL-TXN-0001] A transaction decoder MUST apply the complete Section 5.4 canonicality and range checks to every compact-u16 field before using its value as a count or length.

Unless a rule names a later disposition, failure of envelope parsing or message sanitation makes the transaction unprocessable: it consumes no fee, executes no instruction, and creates no replay-cache entry.

7.2 Transaction envelope and message encodings

The legacy and version-0 transaction envelope is:

Normative table.

The bytes from the first byte of message through the end of the transaction are the signed message bytes.

Normative table.

Normative table.

Version 1 replaces the preceding envelope and vector codecs with a bounded layout. Its signatures follow the message rather than preceding it, and it does not carry a signature-count field. The header’s required_signature_count determines their count.

Normative table. Version-1 transaction layout.

The signed message is every byte from the 0x81 version byte through the final byte of the concatenated instruction data. Signatures are not included in the signed message.

Normative table. Version-1 configuration mask.

Bits 0 and 1 are one u64 little-endian priority fee and MUST either both be set or both be clear. Bits 5 through 31 are invalid.

Normative table. Version-1 instruction header.

For each instruction, the declared account indices occur in the shared account-index region and the declared data bytes occur in the shared data region. Both regions preserve instruction order.

Normative table.

Normative table.

Normative table.

[SOL-TXN-0002] An accepted legacy or version-0 transaction MUST be at most 1,232 bytes, contain between 1 and 12 signatures inclusive, and have signature_count == required_signature_count.

[SOL-TXN-0003] A decoder MUST interpret a message first byte with its high bit clear as the legacy header’s required_signature_count. In the legacy/version-0 envelope it MUST accept a high-bit-set message byte only when it is 0x80. An entire transaction whose first byte is 0x81 selects the version-1 grammar instead.

[SOL-TXN-0004] A decoder MUST consume every byte of the transaction according to the selected grammar and MUST reject truncation, integer overflow, a vector extending past the envelope, or trailing bytes.

[SOL-TXN-0035] A version-1 transaction MUST be at most 4,096 bytes, contain 1..=12 signatures, 1..=64 addresses, and at most 64 top-level instructions. Each instruction MUST reference at most 255 accounts, every account and program index MUST be less than the address count, the program index MUST be nonzero, and all account keys MUST be distinct. Version 1 MUST NOT contain address-table lookups.

[SOL-TXN-0036] A version-1 heap request MUST be a multiple of 1,024 bytes in [32,768,262,144]. The decoder MUST reject an unknown configuration bit, only one priority-fee word, an overflowing concatenated region, or trailing bytes. Compute Budget program instructions remain executable successful no-ops for version-1 configuration; the header configuration is authoritative, and those instructions still incur their ordinary instruction and execution cost.

7.3 Header and account-key sanitation

Let S be the ordered static account keys. For version 0, let LW be addresses selected by writable lookup indices in lookup-entry order and let LR be addresses selected by readonly lookup indices in lookup-entry order. The complete account-key vector is K = S || LW || LR.

[SOL-TXN-0005] The static-key count MUST be at least required_signature_count, readonly_signed_count MUST be less than required_signature_count, and readonly_unsigned_count MUST be no greater than |S| - required_signature_count.

Static keys are classified in four consecutive ranges: writable signed, readonly signed, writable unsigned, and readonly unsigned. Version-0 loaded writable keys follow every static key and are writable unsigned; loaded readonly keys follow them and are readonly unsigned.

[SOL-TXN-0006] Account-key resolution MUST preserve the order S || LW || LR, and every instruction account index MUST be less than |K|.

[SOL-TXN-0007] Every compiled instruction’s program_id_index MUST be nonzero and less than |S|; a program identifier MUST NOT be supplied by an address-table lookup.

[SOL-TXN-0008] Only after every version-0 address lookup has resolved, the runtime MUST first reject |K| > 128 as TransactionError::TooManyAccountLocks, then scan K in order and reject its first duplicate public key as TransactionError::AccountLoadedTwice. A duplicate among static and loaded addresses is detected by this same scan; the implementation MUST NOT report the duplicate before an excessive resolved lock count.

[SOL-TXN-0009] The runtime MUST apply the reserved-key set in Section 13.7 when deriving writability, and a reserved key MUST NOT remain writable when the transaction reaches account locking or execution.

The transaction signature vector is not part of K. The first required_signature_count static keys identify the signature-verification public keys in order.

7.4 Version-0 address-table resolution

An address-lookup-table account has length 56 + 32*N, where 0 <= N <= 256. Address i is the 32 raw bytes at [56+32*i, 88+32*i). Its first 56 bytes are:

Normative table.

The bytes after the conditional metadata decoder through offset 56 are not addresses. A nonmultiple-of-32 address region, more than 256 protocol-state addresses, or an unknown state/option discriminant makes the table invalid. Canonical program writes zero the padding and reserved region; resolution does not interpret those bytes as fields or addresses.

[SOL-TXN-0010] Each version-0 lookup entry MUST contain at least one writable or readonly table index.

[SOL-TXN-0011] A lookup-table account MUST exist, be owned by the address-lookup-table program, deserialize as a valid lookup table, and be usable at the bank slot under the bank’s SlotHashes ancestry; otherwise address loading MUST fail before fees are charged.

[SOL-TXN-0012] Every selected table index MUST address an entry visible at the bank slot, and addresses MUST be appended first from all writable selections and then from all readonly selections while retaining lookup-entry and within-entry index order.

If deactivation_slot == u64::MAX, the table is active. Otherwise it remains usable only at the deactivation slot or while that slot occurs in the current SlotHashes history. When bank_slot > last_extended_slot, all N addresses are visible; otherwise only indices below last_extended_slot_start_index are visible.

7.5 Signatures, age, and replay checks

A durable-nonce account is system-owned and has exactly 80 data bytes. Its current initialized form is:

Normative table.

For an uninitialized state, the remaining account-data bytes are zero padding. Given the bank’s latest registered blockhash H, its next durable nonce is SHA256("DURABLE_NONCE" || H), where the domain is the 13 ASCII bytes. Instruction zero marks a durable transaction only when its program ID is the System program, its data begins 04 00 00 00, and its first account index selects the nonce account; bytes after that four-byte discriminant do not affect marker recognition.

[SOL-TXN-0013] For signature index i, the runtime MUST verify the 64-byte Ed25519 signature against the exact serialized message bytes using static key S[i], and any failed required signature MUST make the transaction unprocessable.

The transaction message hash used by replay protection is specified in Chapter 14.

The recent-blockhash queue retains at most 300 registered blockhashes. Its newest value has age zero, the next-newest age one, and so on. Ordinary transaction processing accepts an age through 150 inclusive; older retained values remain available for non-admission lookups but do not satisfy transaction age.

[SOL-TXN-0014] Before charging a fee, the runtime MUST require either that recent_blockhash is present in the bank’s recent-blockhash queue with age at most 150, or that instruction zero and the referenced nonce account form a valid durable-nonce transaction for that bank.

[SOL-TXN-0015] A durable-nonce transaction MUST identify the nonce account through the instruction-zero marker above, find an exactly 80-byte system-owned Current/Initialized nonce state whose stored durable nonce equals the transaction’s recent_blockhash, require the stored authority among instruction zero’s signers, and require the bank’s next durable nonce to differ from the stored value.

[SOL-TXN-0016] The runtime MUST reject a transaction already present in the applicable replay-protection relation for the same message hash and recent blockhash before account execution.

7.6 Compute-budget instructions and fees

The compute-budget program recognizes one setting of each of these parameters: requested heap bytes, compute-unit limit, compute-unit price in micro-lamports per compute unit, and loaded-account-data byte limit. Recognition occurs while scanning top-level instructions before account loading.

Compute-budget instruction data is the following little-endian enum. The decoder reads the discriminant and payload shown; trailing bytes are ignored. Discriminant 0 is reserved and is rejected.

Normative table.

[SOL-TXN-0017] A duplicate recognized compute-budget setting or a malformed recognized compute-budget instruction MUST make the transaction unprocessable.

[SOL-TXN-0018] An explicit heap request MUST be a multiple of 1,024 in the inclusive range 32,768 through 262,144 bytes; the default is 32,768 bytes.

Normative table. Default requested compute units per top-level instruction.

This table classifies only the default transaction request when no explicit limit exists. It does not replace the actual native instruction costs or SBF metering in Section 12.8.8.

[SOL-TXN-0019] An explicit compute-unit limit MUST be capped at 1,400,000. Without one, assign 3,000 units to each top-level instruction whose program is System, Compute Budget, Upgradeable BPF Loader, deprecated BPF Loader, BPF Loader, the reserved Loader-v4 address, secp256k1, or Ed25519; assign 200,000 units to every other top-level instruction, including Vote; add with saturating u32 arithmetic and cap the result at 1,400,000.

[SOL-TXN-0020] The loaded-account-data byte limit MUST be nonzero and capped at 67,108,864 bytes; an absent request selects 67,108,864 bytes.

[SOL-TXN-0021] The prioritization fee in lamports MUST be ceil(compute_unit_price_micro_lamports * compute_unit_limit / 1,000,000), calculated in a width that cannot overflow the product and saturated to u64::MAX.

[SOL-TXN-0022] The signature fee MUST count the transaction’s required signatures plus the signature operations declared by each active signature-verification precompile, and MUST multiply that count by the lamports-per-signature value associated with the accepted recent blockhash, or by the nonce account’s stored fee rate for a durable-nonce transaction, using saturating u64 arithmetic.

[SOL-TXN-0023] The charged transaction fee MUST be the saturating sum of the signature fee and prioritization fee; its collection and later distribution MUST follow Chapters 11 and 15.

7.7 Fee payer and account loading

[SOL-TXN-0024] The fee payer MUST be the first static account key, MUST be writable and signed, and MUST hold either a system account or an initialized system nonce account.

[SOL-TXN-0025] Fee validation MUST reject a payer that cannot pay the full fee while retaining the rent-exempt reserve required by its post-fee account state, and it MUST reject a post-fee rent-paying state reached from a rent-exempt pre-fee state.

[SOL-TXN-0026] After fee validation succeeds, the runtime MUST deduct the fee before program execution; an instruction failure MUST NOT refund that deduction.

[SOL-TXN-0027] Account loading MUST load resolved transaction accounts from the bank state, synthesize an absent ordinary account as a zero-lamport default account, and synthesize the instructions sysvar rather than read a persistent instructions-sysvar account.

[SOL-TXN-0028] The loaded-data meter MUST apply the byte-exact algorithm below; exceeding the transaction’s loaded-account-data limit MUST stop loading with TransactionError::MaxLoadedAccountsDataSizeExceeded.

[SOL-TXN-0029] A top-level program account MUST exist and be owned by an active native or SBF loader accepted by the protocol configuration. The account’s legacy executable Boolean is not an invocation gate in epoch E and MUST NOT by itself cause AccountNotExecutable or InvalidProgramForExecution. A missing program account is TransactionError::ProgramAccountNotFound; an unsupported owner or invalid loader state is TransactionError::InvalidProgramForExecution during loading, or TransactionError::InstructionError(i, InstructionError::UnsupportedProgramId) when program resolution first occurs for instruction i.

[SOL-TXN-0030] If failure occurs only after fee-payer deduction, including a post-deduction account-loading failure, the transaction MUST produce the fee-only rollback state defined by Chapter 11 and MUST NOT expose partial loaded-account changes.

[SOL-TXN-0031] A legacy or version-0 message MUST NOT contain more than 64 top-level instructions or more than 255 account indices in one compiled instruction.

7.7.1 Loaded-account-data meter

Let limit be the sanitized nonzero requested limit from Section 7.6 and total=0u32. Additions are checked after each item. If an item length cannot convert to u32, or if total + item overflows u32, set the observable meter to u32::MAX and fail. Otherwise set total=total+item and fail when total > limit; equality succeeds.

Normative table. Loaded-account-data byte charges and order.

The 64 bytes are account-loading overhead and are not part of account data. The set used to deduplicate extra ProgramData addresses is initialized with all of K, so an explicitly named ProgramData account is charged exactly once at its position in K. ProgramData deduplication is across every referencing Program. Failure to find the referenced ProgramData does not add bytes; the later program-state/owner check returns the applicable program-loading error.

[SOL-TXN-0032] The meter MUST add lookup overhead before the fee payer, then load the fee payer, then remaining keys in K order, adding an eligible extra ProgramData account immediately after the Program that refers to it. It MUST check the limit after every addition and MUST NOT count account data twice just because the key is referenced by multiple instructions.

[SOL-TXN-0033] A meter failure after successful fee deduction MUST be a fee-only committed transaction. It charges the complete fee; commits durable nonce advancement when the transaction used one; records the transaction identity in replay protection; executes no instruction; consumes 0 execution compute units; records loaded bytes as min(total,limit) when total is representable and limit after overflow; and is a transaction-level result. During block replay it is not by itself block-fatal.

7.8 Error disposition summary

The following four outcome classes are authoritative wherever another section names an exact error but does not repeat every observable effect.

Normative table. Error outcome classes.

For P1 and P2, fee-payer and durable-nonce rollback accounts are committed as Section 11.4 specifies. Logs, return-data snapshots, diagnostic strings, and persistent transaction metadata are not consensus state. They may be retained or discarded after the execution path has used them.

Normative table. Complete TransactionError domain and default outcome.

[SOL-TXN-0034] A failure MUST expose the exact TransactionError variant and outcome in the table above. When multiple conditions are false, the phase order in Section 11.3 and the within-phase order in this table select one error; an implementation MUST NOT choose a later or more convenient error.

Account contention, maintenance mode, a stale locally prepared transaction, executable-preparation capacity, and scheduling cancellation are local admission or retry conditions. They are not protocol transaction results, consume no protocol resources, and cannot be committed as the status of a transaction in an accepted block. Serializable TransactionError compatibility variants such as AccountInUse, CallChainTooDeep, MissingSignatureForFee, ClusterMaintenance, AccountBorrowOutstanding, InvalidWritableAccount, WouldExceedAccountDataTotalLimit, ResanitizationNeeded, ProgramExecutionTemporarilyRestricted, ProgramCacheHitMaxLimit, and CommitCancelled therefore do not belong to the epoch-E protocol error domain.

The signature-verification precompile byte formats and counting rules are specified in Section 12.6.

8. Proof of History and entries

8.1 PoH operations

Let H be the current 32-byte PoH state and M a 32-byte mixin.

[SOL-POH-0001] A PoH append step MUST replace H with SHA256(H), and append(n) MUST apply exactly n such sequential steps.

[SOL-POH-0002] A PoH mixin step MUST replace H with SHA256(H || M) and count as one PoH hash; it MUST NOT first hash M again.

8.2 Transaction-signature mixin

For an entry, flatten transaction signatures in transaction order and, within each transaction, signature-array order. Define this Merkle tree:

• leaf i = SHA256(0x00 || signature[i]);
• parent = SHA256(0x01 || left[32] || right[32]);
• duplicate the last node when a level has an odd node count;
• the empty-list root is 32 zero bytes.

[SOL-POH-0003] A transaction-bearing entry’s mixin MUST be the Merkle root defined above over all of its flattened 64-byte signatures.

This signature tree is distinct from the shred Merkle tree: its prefixes are single bytes, its parent inputs are full 32-byte hashes, and its leaves are signatures only.

8.3 Entry bytes and hash transition

An Entry has this canonical fixed-integer layout:

Normative table.

A batch of entries uses this outer layout; transaction encoding is specified in Chapter 7.

Normative table.

[SOL-POH-0004] An Entry sender MUST encode the fields and sequence counts above without alignment bytes, and an Entry receiver MUST preserve entry and transaction order.

Given previous state P, count n, and transaction vector T, the expected entry hash is:

Normative algorithm.

if n == 0 and len(T) == 0: P
otherwise let Q = append(P, saturating_sub(n, 1))
if len(T) == 0:            SHA256(Q)
else:                      SHA256(Q || signature_merkle_root(T))

[SOL-POH-0005] An Entry MUST be accepted in the PoH chain only when its stored hash equals the expected hash above using the preceding Entry hash, or the parent block’s final Entry hash for the first Entry.

[SOL-POH-0006] An Entry with an empty transaction vector MUST be classified as a tick; an Entry with one or more transactions MUST be classified as a record even if a malformed transaction would later fail validation.

[SOL-POH-0007] Entry PoH verification MUST be sequential across every reconstructed batch in ledger order; parallel computation MUST NOT change which preceding hash is supplied to an Entry.

8.4 Tick accounting

Alpenglow uses low-power PoH. An active bank has no hashes_per_tick target and a block contains one terminal tick, called the alpentick. Every Entry advances the hash chain by one hash regardless of whether it contains transactions. The alpentick is the only empty transaction Entry permitted as a tick and is the final ledger component after the footer.

Normative table. Epoch-E PoH and tick parameters.

The inherited 64-tick interval remains part of bank tick-height arithmetic. Alpenglow does not serialize 64 tick Entries: replay initializes the bank one tick below its maximum, and the single alpentick reaches that maximum.

[SOL-POH-0008] Every Entry in an epoch-E block MUST have num_hashes == 1 and MUST satisfy the sequential hash transition in Section 8.3. Absence of a hashes_per_tick target disables only the legacy accumulated-hash-count comparison; it does not disable Entry hashing.

[SOL-POH-0009] A valid block MUST contain exactly one tick Entry. It MUST have an empty transaction vector, follow the BlockFooter component immediately, and be the last Entry and last component in the block. A transaction Entry, footer, marker, or additional tick after it is block-fatal.

[SOL-POH-0010] Replay MUST increment the bank tick height exactly once for the terminal alpentick and require the resulting height to equal the bank maximum tick height. It MUST NOT synthesize legacy ticks or substitute a local PoH profile.

9. Shreds, erasure coding, and block reconstruction

9.1 Mainnet shred family

[SOL-SHD-0001] A Mainnet receiver MUST accept only the structurally valid chained-Merkle data and coding variants in this chapter and MUST reject every other shred variant byte.

Mainnet FEC sets contain exactly 32 data shreds and 32 coding shreds.

[SOL-SHD-0002] Every FEC set MUST contain logical positions 0 through 31 for data shreds and 32 through 63 for coding shreds; its fec_set_index MUST be a multiple of 32 and a data shred’s index MUST lie in [fec_set_index,fec_set_index+32).

9.2 Header layout

Every shred starts with this 83-byte common header:

Normative table.

The data-header suffix is:

Normative table.

The coding-header suffix is:

Normative table.

[SOL-SHD-0003] A shred encoder and decoder MUST use the offsets above; all multi-byte header integers MUST be little-endian.

[SOL-SHD-0004] The active fixed-set coding header MUST have data_count == 32, code_count == 32, and position in [0,32); its logical leaf position MUST be 32 + position.

The low six data-flag bits are reference_tick. Bit 0x40 is DATA_COMPLETE. The LAST_IN_SLOT value is 0xc0 and therefore includes DATA_COMPLETE; 0x80 without 0x40 is invalid.

[SOL-SHD-0005] A data shred marked LAST_IN_SLOT MUST also be marked DATA_COMPLETE, and a DATA_COMPLETE index MUST equal fec_set_index + 31; a LAST_IN_SLOT index plus one MUST be divisible by 32.

[SOL-SHD-0006] Except for (slot,parent) == (0,0), a data-shred parent MUST equal slot - parent_offset, parent_offset MUST be nonzero, and the resulting parent MUST be less than the slot and not less than the receiver’s rooted slot. In epoch E, both data- and coding-shred indices MUST be less than 16,384; consequently a slot contains at most 512 32+32 FEC sets.

9.3 Payload and active variants

The fixed 64-leaf tree has six 20-byte proof entries. Active bytes are:

Normative table.

[SOL-SHD-0007] The variant’s low nibble MUST equal the Merkle-proof entry count, and for the 32+32 set it MUST equal 6; a Turbine payload MUST have the exact length shown in the table.

For proof count p and r equal to 64 for a retransmitter trailer or zero otherwise, a data shred uses these regions:

Normative table.

The coding shred uses header size 89 and total size 1228 in the same formulas. At p=6, data capacity is 963 bytes without a trailer and 899 with one; the Reed-Solomon shard size is respectively 987 or 923 bytes.

[SOL-SHD-0008] A data shred’s size MUST be in [88,88+capacity], and its ledger-data bytes MUST be exactly [88,size); bytes from size to the chain root are padding and MUST NOT enter reconstructed ledger data.

[SOL-SHD-0009] The 32 bytes at chain_offset MUST be the preceding FEC set’s full Merkle root in the chain selected for the slot; the first set’s incoming root MUST be the terminal chained root accepted for the parent block. Conflicting roots identify distinct candidate versions and MUST NOT be combined.

9.4 Shred Merkle authentication

For each shred, define:

Normative algorithm.

leaf = SHA256(0x00 || "SOLANA_MERKLE_SHREDS_LEAF" || payload[64:proof_offset])
node = SHA256(0x01 || "SOLANA_MERKLE_SHREDS_NODE" || left[0:20] || right[0:20])

The ASCII suffixes contain 25 bytes after their one-byte domain prefix. At an odd tree level the last node is paired with itself. A proof entry is the first 20 bytes of the sibling hash, from leaf level upward.

[SOL-SHD-0010] A receiver MUST derive the leaf index as data.index - fec_set_index for data or 32 + coding.position for coding, fold the six proof entries according to the index bits, and reject unless the fold ends at one root with no remaining high index bits.

[SOL-SHD-0011] The 64-byte common-header signature MUST verify under the scheduled leader key for the shred’s slot over the 32 raw bytes of the reconstructed full Merkle root.

[SOL-SHD-0012] All shreds combined into one FEC set MUST agree on slot, FEC-set index, leader signature, variant family, counts, proof depth, chain root, and reconstructed Merkle root; a receiver MUST NOT combine shards from inconsistent sets.

[SOL-SHD-0013] In a resigned variant, the final 64 bytes MUST be excluded from the leader Merkle leaf and Reed-Solomon shard and carried as the retransmitter-signature trailer. The trailer is not an acceptance predicate in epoch E and MUST NOT replace the leader-signature check.

9.5 Reed-Solomon recovery

The erasure inputs are 64 equal-length byte columns over GF(2^8). Field addition is XOR. Multiplication is polynomial multiplication modulo x^8 + x^4 + x^3 + x^2 + 1 (0x11d), with 2 as the generator of the 255 nonzero elements. Data shard i is payload [64,chain_offset) from data shred fec_set_index+i. Coding shard j is payload [89,chain_offset) from coding position j. Thus data common/data headers after the leader signature are protected; coding headers and all Merkle proofs are not.

Define a 64 x 32 Vandermonde matrix V by V[r,c] = r^c in that field, including 0^0 = 1. Let T = V[0..32,0..32] and let the systematic generator matrix be G = V * inverse(T). Thus rows 0..31 of G are the identity and row 32+j produces coding shard j. Each output byte position is the field dot product of its generator row with the 32 data bytes at that position.

[SOL-SHD-0014] Encoding and recovery MUST use generator matrix G, with data positions followed by coding positions in the order above. Recovery MUST fail with fewer than 32 valid, mutually consistent shards; otherwise it MUST invert the 32-row submatrix selected by any 32 available logical positions to recover the original 32 data shards. Shard ordering MUST NOT vary.

[SOL-SHD-0015] After Reed-Solomon recovery, each recovered data header MUST be decoded and sanitized, and every recovered shard’s leaf, proof, root, and leader signature MUST be regenerated or verified before its ledger bytes are used.

9.6 Deshredding

[SOL-SHD-0016] To deshred one ledger component, a receiver MUST order data shreds by increasing index, require consecutive indices, append only each shred’s [88,size) bytes, stop at the first DATA_COMPLETE shred, and reject a missing DATA_COMPLETE marker or any trailing shred in that component.

[SOL-SHD-0017] A slot MUST be considered shred-complete only when data indices begin at zero, are consecutive through a unique LAST_IN_SLOT shred, and every component boundary needed to decode the concatenated Entry batches is present. A zero-entry component or unconsumed bytes after a decoded entry batch MUST invalidate the candidate; padding outside each data shred’s declared size never enters the deshredded component.

An ordinary DATA_COMPLETE component is independently framed as exactly one ENTRY-E1072 outer sequence:

Normative table. Deshredded component framing.

The active fixed-FEC rule permits DATA_COMPLETE only on the final data shred of each 32-data-shred FEC set; LAST_IN_SLOT implies DATA_COMPLETE. Therefore a slot has at most 512 components. Entry and transaction fields cannot continue into another component. The combined serialized Entry batches in a slot MUST NOT exceed 10,485,760 bytes.

An eight-byte zero count selects a block marker rather than an empty Entry batch. Every marker has the following exact preamble:

Normative table. Block-marker preamble.

The first body byte is the selected marker’s version and is exactly 1. Header and update-parent bodies are each 41 bytes: the version byte, a u64 little-endian parent slot, and a 32-byte parent block ID. The footer body is:

Normative table. BlockFooterV1 body.

Normative table. Footer certificate records.

A signer bitmap is version byte 0, bit count as u16 little-endian, then exactly ceil(bit_count/8) bytes. Bits are packed least-significant bit first and identify validators by the epoch rank map. Unused high bits in the last byte are zero.

[SOL-SHD-0018] The component sequence MUST be one header, zero or more nonempty Entry batches, one footer, and one terminal alpentick Entry batch, in that order. The header is the first component; the footer is followed immediately by a batch containing exactly the one tick described in Section 8.4; and that batch is the last component. No component may follow it. Each component MUST consume its bytes exactly.

[SOL-SHD-0019] The header parent slot MUST equal the selected bank parent and its parent block ID MUST equal that parent’s Section 14.5 block ID. The footer timestamp must fit i64 and lie inclusively in [parent_time_nanos + 1, parent_time_nanos + 2*elapsed_slot_duration_nanos], using saturating arithmetic. The footer bank hash MUST equal the hash of the frozen bank. An update-parent or genesis-certificate marker is structurally decodable but invalid in the epoch-E steady-state profile.

[SOL-SHD-0020] Framing precedence MUST validate shred/FEC structure and a DATA_COMPLETE boundary first. At a present boundary, decode the u64 count; zero enters the marker grammar and nonzero enters the Entry grammar. Then require exact consumption. A truncated count, field crossing the boundary, mismatched marker length, empty ordinary batch, or leftover byte is block-fatal. A receiver MUST NOT concatenate components to repair a truncated field. Any data shred after LAST_IN_SLOT, more than 512 components, or more than 10,485,760 Entry bytes is block-fatal.

The InvalidBlock::* names in this section are specification disposition codes. They are not ledger bytes, network error codes, or names imported from any validator implementation.

10. Slot and block validity

10.1 Candidate, incomplete, invalid, and duplicate states

A candidate block is the ordered ledger-data result for one slot and one parent. Network arrival order, local database layout, and replay-stage thread boundaries do not define candidate order.

Informative diagram.

@startuml
[*] --> Incomplete
Incomplete --> Candidate : all required shreds reconstructed
Incomplete --> Incomplete : more valid shreds arrive
Candidate --> Invalid : any Chapter 9-14 check fails
Candidate --> Replayed : all Chapter 9-14 checks pass
Replayed --> Votable : Chapter 15 safety predicate passes
Replayed --> Conflicting : another block ID exists for the slot
Conflicting --> Votable : exact block gains required certificate
Conflicting --> Rejected : conflicting block gains required certificate
@enduml

[SOL-BLK-0001] A validator MUST keep “incomplete” distinct from “invalid”: absence of required data or parity is incomplete, while a failed structural, authentication, PoH, transaction, execution, or commitment rule is invalid.

[SOL-BLK-0002] Two different authenticated byte strings with the same (slot,index,shred-type) identity MUST be treated as duplicate/equivocation evidence and MUST NOT be spliced into one candidate block.

The same slot participates in several typed identities. They are not interchangeable:

Normative table. Candidate and duplicate identity keys.

[SOL-BLK-0003] Conflicting blocks in one slot MUST remain separate by block ID. Votes for different block IDs MUST NOT be combined into a threshold, and a certificate for one block ID MUST NOT make another candidate valid. A participant that has emitted its first Notar or Skip vote for the slot MUST NOT emit a conflicting first vote after discovering a duplicate.

[SOL-BLK-0004] A participant that has not yet cast its first slot vote MUST apply the Chapter 15 safe-to-vote predicate independently to each valid, replayed candidate. An authenticated duplicate is not itself permission to vote. After a Notar certificate for one exact candidate is observed, descendants and finalization decisions MUST use that certified block and its committed ancestry; an uncertified conflicting candidate is not votable just because it was received first.

[SOL-BLK-0005] A certificate never repairs a structurally invalid or unreplayed block. If the certified block is absent, incomplete, dead, has the wrong block ID, or freezes to another bank hash, the participant MUST abstain, obtain the exact certified version through repair, and rerun Chapters 9 through 14 before voting for it or a descendant.

10.2 Structural completeness

[SOL-BLK-0006] A candidate block MUST use data shreds for one slot, one shred version, one scheduled leader, one parent slot, and one consistent chain of FEC Merkle roots; all indices from zero through the LAST_IN_SLOT index MUST be present or validly reconstructed exactly once.

[SOL-BLK-0007] Every FEC set contributing to a candidate MUST satisfy Chapter 9, every DATA_COMPLETE boundary MUST terminate exactly one deshredded component, and the unique LAST_IN_SLOT shred MUST terminate the last component.

[SOL-BLK-0008] Each deshredded component MUST decode as its declared sequence of Entries and transactions with all counts in bounds; malformed or unconsumed ledger bytes MUST invalidate the candidate rather than be ignored as another component.

10.3 Cryptographic and temporal validity

[SOL-BLK-0009] Every shred in a candidate MUST have a valid scheduled-leader signature and Merkle proof, and every reconstructed Entry MUST extend the parent block’s final Entry hash through the sequential Chapter 8 PoH transition.

[SOL-BLK-0010] A full candidate MUST contain exactly the tick progress required to reach the bank’s maximum tick height, MUST end in a tick, and MUST NOT contain an Entry after that final tick.

[SOL-BLK-0011] The tick-hash accumulator MUST satisfy the rule in Chapter 8 across component boundaries; a component boundary MUST NOT reset PoH state or the partial tick-hash count.

10.4 Transaction and state-transition validity

[SOL-BLK-0012] Transactions MUST be validated in reconstructed ledger order under Chapter 7, and every transaction signature and message hash that the protocol configuration requires MUST be checked before the block is accepted.

[SOL-BLK-0013] Starting from the selected parent state, the validator MUST apply the ordered transactions and system transitions under Chapters 11 through 13 and MUST reject the candidate if replay returns a block-fatal error or the resulting commitments fail Chapter 14. Chapter 15 separately determines whether the valid, replayed candidate is eligible for a local vote or consensus transition.

Transaction-level failure represented as a deterministic transaction result is not automatically a block-fatal error; the runtime chapters define that boundary.

10.4.1 Transaction cost calculation

Cost units used for block admission are not just execution compute units. Let:

Normative table. Every epoch-E cost-model constant factor.

No omitted coefficient, floating-point conversion, or implementation-specific cost is part of the epoch-E transaction cost. All products and sums below use saturating u64 arithmetic unless an earlier syntax bound makes overflow impossible.

• n_tx be the required transaction-signature count, and n_k1, n_ed, and n_r1 be the sums of the first instruction-data byte of each top-level instruction addressed to the respective active secp256k1, Ed25519, and secp256r1 precompile; an empty instruction contributes zero, while later precompile validation remains a separate execution check;
• W be the number of message-requested writable accounts before any writability demotion;
• D be the sum of all top-level instruction-data lengths in bytes;
• X be program-execution compute units; and
• L be loaded-account data bytes.

Define pages(0) = 0 and pages(L) = 1 + floor((L - 1) / 32768) for L > 0. The transaction cost is:

Normative algorithm.

C_fixed = 720*n_tx + 6690*n_k1 + 2400*n_ed + 4800*n_r1
        + 300*W + floor(D/4)

C_tx = C_fixed + X + 8*pages(L)

Thus loaded account data costs exactly 8 cost units for each started 32-KiB page: zero bytes cost zero, bytes 1..32768 cost 8, and bytes 32769..65536 cost 16. This admission charge is distinct from the SBF heap charge in Section 12.8.8, although both use an eight-unit page coefficient.

For final block validity, use actual executed compute units as X and actual metered loaded-account bytes as L; the fixed terms do not change. Add the resulting full C_tx once to the block counter and once to the counter of every account that remains writable after sanitation and writability demotion. A producer may reserve against requested limits while choosing transactions, but reservation, refund, queue order, and selection strategy are not ledger rules. A transaction omitted before recording contributes nothing.

The allocated-data counter is separate from C_tx. Scan top-level System program instructions and sum the requested space of CreateAccount, CreateAccountWithSeed, Allocate, AllocateWithSeed, and CreateAccountAllowPrefund. If any scanned System instruction cannot be decoded or requests more than 10,485,760 bytes, its transaction contributes zero to this static counter. Otherwise clamp the transaction sum to 20,971,520 bytes before adding it to the block counter. CPI and non-System instructions do not add a static allocation estimate.

[SOL-BLK-0014] Replay MUST calculate and attribute every committed transaction’s actual cost and statically requested allocation by the formulas above. It MUST charge the complete transaction cost to every account that remains writable after demotion and round loaded-account bytes up to 32-KiB pages rather than truncate them.

10.4.2 Per-slot production and ledger-envelope limits

The epoch-E block budgets are distinct from each transaction’s requested compute limit. The same cost limits are enforced during production admission and again while replaying the committed transaction results:

Normative table.

The ledger envelope independently permits indices 0..16383 for data shreds and 0..16383 for coding shreds. Because every epoch-E FEC set is exactly 32 data plus 32 coding shreds, a slot contains at most 512 FEC sets. The exact shred lengths, payload capacities, fixed-set rules, and reconstruction threshold are in Chapter 9. There is no separate epoch-E numeric limit on transactions per block or signatures per block: the transaction envelope, shred envelope, cost counters, and per-transaction limits bound them. These are all active epoch-E per-slot production counters and shred/FEC count envelopes. Queue capacities, batching targets, cache bounds, retention limits, and rate limits that only govern a validator’s local work are not block or shred validity limits and therefore are not included.

[SOL-BLK-0015] A block producer MUST NOT select a transaction that would make one of the three epoch-E counters exceed the table above. Replay MUST independently recompute actual transaction costs in ledger order for every committed result and apply the aggregate, per-writable-account, and allocated-data limits. WouldExceedMaxBlockCostLimit, WouldExceedMaxAccountCostLimit, or WouldExceedAccountDataBlockLimit encountered in production excludes the transaction; the same result during replay is block-fatal. The Chapter 9 shred/FEC envelope is the independent byte-framing bound, including the 10-MiB Entry-byte ceiling. None of these limits substitutes for the per-transaction execution meter in Chapter 12.

10.5 Acceptance and local disposition

[SOL-BLK-0016] A slot MUST NOT become a votable valid block until requirements SOL-BLK-0006 through SOL-BLK-0015 have all succeeded for the same candidate and parent, and Chapter 15 permits a vote for that exact block ID under the participant’s persisted safety state.

[SOL-BLK-0017] A validator MUST derive block identity, bank hash, vote target, and consensus eligibility only from the single accepted ordered candidate; local arrival timing or the first conflicting shred observed MUST NOT alter those commitments.

[SOL-BLK-0018] Marking a slot dead in a local store MAY suppress repeated local replay work, but it MUST NOT be serialized or interpreted as a network proof that every competing duplicate candidate for that slot is invalid.

11. Deterministic state transition

11.1 State and function boundary

The consensus transition is modeled as:

Normative algorithm.

ApplyBlock(parent_bank, ordered_block, protocol_configuration) -> child_bank | InvalidBlock

The parent bank contains the account state and consensus metadata defined in Chapter 4 and fixed by earlier slots. The ordered block contains the slot identity, leader identity, entry/transaction order, ticks, and terminal PoH value defined by Chapters 8 through 10. The protocol configuration contains the genesis identity and parameters; every mutable selector comes from the parent-derived bank state.

Informative diagram.

@startuml
rectangle "Frozen parent bank" as P
rectangle "Construct child bank" as C
rectangle "Ordered candidate block" as O
rectangle "Validate entries, ticks,\nand transactions" as V
rectangle "Execute transactions\nin ledger order" as T
rectangle "Apply fees, sysvars, rewards,\nand freeze hooks" as F
rectangle "Compute account and\nbank commitments" as H
rectangle "Frozen child bank" as B
rectangle "Invalid block" as I
rectangle "Per-transaction rollback" as R
P --> C
O --> V
C --> V
V --> T
T --> F
F --> H
H --> B
V --> I : block-fatal error
T --> R : transaction error
R --> T
@enduml

[SOL-STA-0001] ApplyBlock MUST be a deterministic function of the parent bank, the byte-identical ordered block, and the protocol configuration; scheduling, thread count, caches, host time, filesystem order, and network arrival order MUST NOT change its result.

[SOL-STA-0002] ApplyBlock MUST create a child bank for the candidate slot without modifying the frozen parent bank.

[SOL-STA-0003] A block that fails any block-wide validity condition MUST produce InvalidBlock and MUST NOT expose a partially frozen child bank as a valid fork state.

11.2 Child-bank construction and pre-transaction phase

[SOL-STA-0004] Child-bank construction MUST derive the child’s slot, epoch, parent hash, block height, tick bounds, feature set, epoch schedule, recent-blockhash queue, replay-protection ancestry, program environment, capitalization, and inherited account state from the frozen parent and protocol configuration using checked arithmetic where the specified domain can overflow.

[SOL-STA-0005] At an epoch boundary, ApplyBlock MUST perform feature activation, epoch stake/cache transition, and the applicable epoch-reward initialization before any transaction in the child slot is executed.

[SOL-STA-0006] Before the first transaction, ApplyBlock MUST apply the slot’s scheduled partitioned-reward distribution and update the Clock, SlotHashes, StakeHistory when applicable, LastRestartSlot, and executable sysvar cache in the protocol order specified by Chapters 13 and 16.

[SOL-STA-0007] Every feature-dependent branch used by child-bank construction, transaction processing, or freeze MUST be selected from the parent-derived bank’s activation state at this slot.

Stake-weighted timestamp and reward formulas are owned by Chapters 13 and 16; this chapter fixes their position in the transition.

11.3 Ordered transaction transition

Let B_i be the visible bank state immediately before transaction i in ledger order, including all committed effects of earlier transactions in the slot.

[SOL-STA-0008] Transactions MUST be validated, loaded, executed, and committed in ledger order, and transaction i MUST read B_i rather than a snapshot that omits an earlier transaction’s committed writes.

[SOL-STA-0009] A parallel executor MAY speculate or execute concurrently only when its committed account state, transaction dispositions, counters, fees, and errors are identical to the sequential transition required by SOL-STA-0008.

Normative algorithm. Transaction phase and error precedence.

1  decode envelope and statically sanitize message fields
2  verify every required transaction signature
3  resolve every version-0 lookup table and append LW then LR
4  check resolved key count, then duplicate keys, and derive effective privileges
5  scan compute-budget instructions and derive fee/execution limits
6  validate recent blockhash, else durable nonce
7  query the replay-protection relation
8  load and validate fee payer, validate rent transition, deduct fee,
   and stage durable-nonce advancement
9  meter/load transaction accounts and resolve programs
10 verify precompiles and execute top-level instructions in order
11 validate post-state, then commit success or fee/nonce rollback state
12 update replay protection, signature, compute, fee, and block-cost counters

At every numbered phase, the first failing check in message/account order is the transaction error; later phases are not evaluated for that transaction. Within phase 5, scan top-level instructions in order and report the first malformed or repeated compute-budget setting. Within phase 6, an ordinary recent blockhash takes precedence; durable-nonce recognition is attempted only when the ordinary hash is not valid. Within phase 9, use the exact ordering in Section 7.7.1. Within phase 10, precompile verification follows message order and ordinary instruction execution stops at its first failing index.

[SOL-STA-0010] Each transaction MUST pass through the phase order above. In particular, compute-budget interpretation precedes age/nonce, age/nonce precedes replay-protection lookup, signature verification precedes address-table resolution, resolved account-count failure precedes duplicate-key failure, and all of those checks precede fee deduction. Account contention is not a protocol phase; an implementation that uses locks MUST wait, retry, or serialize without changing the selected error.

[SOL-STA-0011] An unprocessable transaction MUST leave the account map, fee accumulators, processed-signature counter, executed-compute counter, and replay- protection relation unchanged.

For the currently specified transition, a processed transaction has one of three relevant results:

Normative table.

11.4 Instruction success and rollback

[SOL-STA-0012] A successfully executed transaction MUST commit only protocol-permitted changes to its touched writable accounts, including account creation or zero-lamport reclamation, and MUST NOT commit a change to a readonly account.

[SOL-STA-0013] A transaction whose instruction processing fails MUST discard every program-produced account change and MUST commit only the already-deducted fee-payer state and the advanced durable-nonce state when those are distinct rollback accounts.

[SOL-STA-0014] A post-fee account-loading failure MUST use the same fee-payer and durable-nonce rollback rule as a failed execution and MUST NOT invoke any top-level instruction.

[SOL-STA-0015] When the fee payer and durable-nonce address are the same, rollback MUST preserve one account value containing both the nonce advancement and the fee deduction, not two order-dependent overwrites.

[SOL-STA-0016] A valid durable-nonce transaction MUST advance the nonce to the bank-derived next durable nonce before instruction execution, and failed execution or fee-only loading failure MUST NOT roll that advancement back.

[SOL-STA-0017] Top-level instructions MUST execute in message order and processing MUST stop at the first instruction error.

[SOL-STA-0018] At every successfully returned instruction boundary, the sum of lamports across that instruction’s transaction accounts MUST equal the sum on entry, and outstanding account-data borrows MUST be released; violation MUST fail the transaction.

The ownership, executable, data-length, rent, and CPI privilege rules that determine whether a program-produced change is permitted are specified in Chapters 12 and 13.

11.5 Replay protection, counters, and fees

Define the replay-protection relation abstractly over the recent-blockhash window. Its protocol key is (recent_blockhash, message_hash), where message_hash is Section 14.3. A relation entry says that the message has already been processed on this fork; its database representation, truncated index keys, and lookup acceleration are outside scope.

[SOL-STA-0019] Each P1, P2, or successful processed transaction MUST add its (recent_blockhash, message_hash) to the child fork’s replay-protection relation, with the transaction outcome needed by descendants. No signature value is a second protocol replay key.

[SOL-STA-0020] A processed durable-nonce transaction MUST additionally obtain replay protection from the committed nonce advancement specified in Section 11.4.

[SOL-STA-0021] The slot’s processed-signature counter MUST add required_signature_count for every processed transaction, whether execution succeeds, fails, or stops at fee-only loading; precompile signature records affect the fee count but MUST NOT be added to this bank-hash counter.

[SOL-STA-0022] Fee collection MUST add the charged base/signature and prioritization components to the child bank’s fee accumulators using the protocol overflow behavior, and later distribution MUST NOT depend on transaction execution success.

[SOL-STA-0023] Compute consumption and transaction cost counters MUST be updated from the processed result in ledger order using the limits and actual execution measurements selected by Chapters 7 and 12.

11.6 Ticks, freeze, and post-state

[SOL-STA-0024] ApplyBlock MUST verify and register entries and ticks in ledger order, and the final tick at the slot boundary MUST register the terminal PoH hash in the recent-blockhash queue before incrementing the tick height to its complete value.

[SOL-STA-0025] The recent-blockhash and replay-protection age windows used by later transactions and child slots MUST be derived from the protocol queues after the ordered tick registrations, not from wall-clock time.

[SOL-STA-0026] Freeze MUST occur only after the slot is complete and every accepted transaction result has been committed.

[SOL-STA-0027] Freeze MUST distribute the slot’s accumulated fees, update SlotHistory, process the incinerator account, finish all account-state accumulator updates, and compute the bank hash in that order where Chapter 14 requires ordering.

[SOL-STA-0028] Incinerator processing MUST replace a present incinerator account with the default zero-lamport account and subtract its former lamports from capitalization using checked protocol arithmetic.

[SOL-STA-0029] Every protocol-owned account update performed outside a transaction, including sysvar, reward, fee, and incinerator writes, MUST update capitalization and the accounts-state accumulator by the same observable rules as an equivalent account replacement.

[SOL-STA-0030] A successfully frozen child bank MUST expose the terminal recent blockhash, complete tick height, final account map, capitalization, replay-protection additions, accounts-state commitment, and bank hash as the post-state consumed by its descendants.

11.7 Dependencies

This chapter establishes deterministic phase order and transaction commit/rollback behavior. It relies on Chapters 8 through 10 for entry and tick validity, Chapter 12 for executable semantics, Chapter 13 for protocol-owned state, Chapter 14 for hashes, and Chapter 16 for epoch, reward, and fee arithmetic.

12. SVM, loaders, syscalls, and precompiles

12.1 Execution boundary

This chapter fixes the consensus-visible execution environment supplied to native programs and Solana BPF (SBF) programs. Section 12.8 defines the entire active SBF instruction set and the Solana-specific loader, memory, syscall, input, compute, and state rules; no external ISA document is normative.

[SOL-SVM-0001] For every executable program and input state accepted by this specification, an SVM implementation MUST produce the same instruction result, compute-unit consumption, account changes, return data, and consensus-visible error.

[SOL-SVM-0002] The runtime MUST select the accepted SBF versions, VM configuration, loader behavior, syscall registry, precompile set, compute schedule, stack-depth rule, and feature branches from the bank in which the instruction executes.

12.2 Program resolution and loading

A program account is resolved through the transaction key vector. A native builtin is owned by the Native Loader. An SBF program is owned by a supported BPF loader. Under the upgradeable loader, executable Program state refers to a distinct ProgramData account containing deployment metadata and program bytes.

Program selection is the pure protocol relation:

Normative algorithm.

ResolveProgram(bank_state, program_id, invoking_slot)
    -> Builtin(program_id, behavior)
     | Sbf(loader_id, program_bytes, deployment_slot,
           ProgramEnvironment(execution, loader_id, deployment_slot,
                              invoking_slot, feature_activation_history))
     | ProgramAccountNotFound
     | InvalidProgramForExecution
     | UnsupportedProgramId

ProgramEnvironment(mode, loader_id, deployment_slot, invoking_slot, feature_activation_history) is the pure selection of the accepted SBF versions, verifier rules, memory configuration, syscall set, and compute schedule. Mode is deployment while validating new bytes and execution while invoking stored bytes; the mode-specific and historically retained syscall differences are stated in Sections 12.8.5 and 12.8.7. No compiled artifact, cache generation, eviction event, or host execution engine is an input to either relation.

[SOL-SVM-0003] Before invocation, the runtime MUST require the program identifier to be present in the transaction’s instruction context and MUST reject a missing, unsupported-owner, invalid-state, or unloadable program without entering its code. The stored executable Boolean is passed through the ABI but is not an epoch-E invocation predicate.

[SOL-SVM-0004] A native-loader-owned program MUST dispatch to the builtin registered for that exact program identifier, while a supported BPF-loader-owned program MUST dispatch through its loader and the bank-selected SBF environment.

[SOL-SVM-0005] ResolveProgram MUST depend only on the invoking bank’s account state, program identifier, invoking slot, and feature activation history, and MUST return the same selected bytes, loader, environment, and error for equal inputs.

[SOL-SVM-0006] Loading an upgradeable program MUST validate the Program-to-ProgramData relationship and use the ProgramData version visible in bank state; it MUST NOT substitute a later deployment or a host-local artifact. A deployment, upgrade, or Core-BPF migration at slot d MUST NOT make the new bytes invocable until slot d+1, and MUST NOT use the old bytes during that delay.

A successful deploy or upgrade recorded at slot d sets deployment slot d and effective slot d+1. During the remainder of d, resolution of that program does not fall back to the previous bytes: an attempted invocation fails with InstructionError::UnsupportedProgramId. At slots at or above d+1, resolution uses the new bytes. A checked addition overflow for d+1 makes deployment invalid.

12.3 Instruction execution environment

[SOL-SVM-0007] The runtime MUST execute top-level instructions in message order, initialize each instruction from transaction account privileges and data, and stop the transaction at the first failed instruction.

[SOL-SVM-0008] Each invocation MUST begin with return data reset to empty for the invoked program and MUST expose only return data produced during the current invocation chain.

[SOL-SVM-0009] The compute meter MUST begin at the transaction’s sanitized compute-unit limit, charge native-program work, VM instructions, heap provisioning, memory operations, syscalls, CPI, and loader work according to the active schedule, and fail when a required charge exceeds the remaining units. Epoch-E precompile verification consumes zero execution-meter units; its declared signature count is charged through transaction fees and the Section 10.4.1 block-admission cost.

[SOL-SVM-0010] VM memory translation MUST enforce the address ranges, permissions, alignment, stack layout, heap size, and input mapping in Section 12.8. An invalid guest access MUST produce the specified VM or instruction error without host undefined behavior.

[SOL-SVM-0011] Program return status, VM fault, compute exhaustion, and loader/runtime failure MUST map to the protocol instruction-error domain before Chapter 11 applies transaction rollback.

12.4 Invocation stack and CPI

An instruction context contains ordered instruction accounts, program accounts, instruction data, stack height, and its position in the transaction instruction trace. CPI uses accounts already present in the transaction context; it does not load an arbitrary account by public key.

[SOL-SVM-0012] Invocation push MUST fail when it would exceed the maximum instruction-stack depth of 5.

[SOL-SVM-0013] Invocation push MUST reject reentrancy when the target program already appears earlier in the invocation stack, except that a program MAY directly invoke itself when it is also the immediate caller.

[SOL-SVM-0014] A CPI instruction MUST resolve every account meta and the callee program to accounts already present in the caller’s transaction instruction context, and a missing account or callee MUST fail the caller instruction.

[SOL-SVM-0015] CPI MUST NOT elevate a readonly caller account to writable and MUST NOT elevate a nonsigner caller account to signer unless the caller program derives that account as a valid program-derived address from supplied signer seeds.

[SOL-SVM-0016] Signer seeds MUST be interpreted under the caller program identifier, not the callee identifier, and invalid seed count, seed length, or derived-address construction MUST fail CPI.

[SOL-SVM-0017] A CPI MUST reject more than 255 account metas, more than 255 account-info records, more than 16 signer-seed groups, or instruction data longer than 10,240 bytes. The complete instruction trace, including top-level instructions, MUST NOT exceed 64 entries.

[SOL-SVM-0018] CPI MUST NOT directly target the Native Loader, a BPF loader, an active signature precompile, or an upgradeable-loader management instruction outside the active allowlist.

[SOL-SVM-0019] Before entering a callee and after returning to its caller, the runtime MUST synchronize every shared account’s lamports, data, owner, and permitted length changes without losing aliases or duplicate-account privileges.

[SOL-SVM-0020] Instruction pop MUST fail if an account remains borrowed or if aggregate lamports differ from the aggregate on instruction entry, and the resulting error MUST trigger transaction rollback.

12.5 Syscall dispatch

[SOL-SVM-0021] A syscall MUST resolve only when registered in the runtime environment for the bank and program deployment; an unresolved symbol or static target MUST cause ELF verification or execution failure.

[SOL-SVM-0022] Each syscall MUST translate and bounds-check guest pointers and lengths, enforce required alignment and non-overlap rules, validate selectors and numeric bounds, and charge its specified compute cost before producing an output or error.

[SOL-SVM-0023] A sysvar syscall MUST return the bank-visible value for the current invocation and slot and MUST NOT read host time or stale process-global state.

[SOL-SVM-0024] Hashing and elliptic-curve syscalls MUST operate on the exact guest byte slices and curve/field encodings selected by the syscall’s identifiers, with deterministic rejection of invalid encodings.

[SOL-SVM-0025] sol_memcpy_ MUST reject overlapping source and destination ranges; sol_memmove_ MUST permit overlap; sol_memset_ MUST write the low byte of its fill argument; and sol_memcmp_ MUST write the signed comparison result to its result pointer.

12.6 Signature precompiles

Precompiles are processed in top-level message order during instruction execution and can reference the complete ordered vector of top-level instruction data. They do not run SBF code and cannot be invoked by CPI. A precompile failure is an executed instruction error: the transaction fee remains charged and Chapter 11 rolls back program-produced state.

12.6.1 Ed25519 and secp256r1 record layout

Ed25519 and secp256r1 use a two-byte prefix followed by count consecutive 14-byte records. Every integer in a record is an unaligned little-endian u16.

Normative table.

Normative table.

For either precompile, instruction index 0xffff selects the current precompile instruction data; any other value selects that zero-based top-level instruction’s data.

Normative table.

12.6.2 secp256k1 record layout

The secp256k1 instruction begins with a one-byte count and count consecutive 11-byte records. The u16 fields are little-endian.

Normative table.

Normative table.

The referenced secp256k1 signature value has this layout:

Normative table.

Verification computes Keccak-256 over the referenced message, recovers the public key, serializes its 64-byte uncompressed coordinates without the SEC1 prefix, computes Keccak-256 again, and compares the last 20 bytes with the referenced Ethereum address. A zero count is valid only when the instruction contains exactly the count byte.

[SOL-SVM-0026] A precompile verifier MUST parse the applicable prefix and record table above, require the complete table to be present, bounds-check every referenced range with saturating or checked arithmetic, and apply the program-specific verification rule.

[SOL-SVM-0027] A malformed table, out-of-range instruction reference, invalid key or signature encoding, failed signature, or invalid count/data combination MUST fail that top-level instruction with the corresponding precompile instruction error, stop later instructions, and enter the failed-execution rollback path.

[SOL-SVM-0028] Precompile signature counts used for fee and block-admission cost calculation MUST be read from the same active program identifier and instruction bytes used by verification. Precompile verification itself MUST NOT debit the epoch-E transaction execution meter.

[SOL-SVM-0029] A precompile MUST observe only the ordered top-level instruction-data vector; CPI-created instruction data MUST NOT be substituted into that vector.

12.7 Protocol-visible execution errors

Every instruction failure is returned as TransactionError::InstructionError(i,e), where i is the zero-based top-level message-instruction index even when the failure arose in CPI and e is one exact value from the table below. It is outcome P2: the full fee and any durable-nonce advance commit, replay protection records the message, account writes roll back, consumed CU remains charged, and the failure is transaction-level rather than block-fatal. Logs and the final return-data buffer are not committed protocol outputs.

Normative table. Complete InstructionError domain and first applicable cause.

For an SBF EXIT at outer depth, r0 == 0 means success. A value v with upper 32 bits zero maps to Custom(u32(v)), except zero is success; Custom(0) is encoded by 1<<32. Builtin return codes (n<<32) map as follows.

Normative table. SBF builtin return-code mapping.

Any other value with nonzero upper 32 bits maps to InvalidError. Runtime postconditions are checked in transaction-account order; the first failing account and the first applicable row above determine e. Within a protocol program, instruction decoding precedes account acquisition, which precedes owner/state validation, signer/authority validation, numeric/rent validation, and mutation. Compute charged on entry or before a cryptographic operation is not refunded when a later check fails.

[SOL-SVM-0030] An implementation MUST preserve the protocol distinction among transaction sanitation/loading errors, instruction errors, custom program errors, VM faults, compute exhaustion, privilege escalation, unbalanced lamports, and invalid account-data or ownership transitions wherever that distinction affects replay or transaction status.

[SOL-SVM-0031] Diagnostic strings, host exception types, executable-preparation strategy, and performance metrics MAY differ, but they MUST NOT alter the error code, consumed compute, committed state, fee, or replay outcome. An implementation’s inability to prepare an SBF program that passes the normative verifier is a local failure, not InstructionError::ProgramFailedToCompile.

12.8 SBF abstract machine and runtime ABI

12.8.1 Complete active SBF instruction set

This subsection is the complete normative ISA for SBF V0 through V3 in epoch E. Names from BPF literature are mnemonics only; the byte, arithmetic, and version rules below are authoritative and an implementation does not need an external BPF specification.

[SOL-SVM-0032] An SBF engine MUST implement the SBF opcode, verifier, arithmetic, call, and VM-fault behavior selected by the ELF’s V0–V3 version and MUST NOT accept an instruction rejected by that version’s verifier.

Every ordinary instruction occupies eight bytes:

Normative table. SBF instruction word.

For versions that permit LDDW, it occupies two consecutive eight-byte words: the first word carries the low 32 immediate bits; the second word has opcode zero and carries the high 32 bits. No jump may target the second word.

Let D=r[dst], S=r[src], I=sign_extend_i32(imm), U32(x) be the low 32 bits interpreted unsigned, I32(x) those bits interpreted signed, and EA=r[base]+sign_extend_i16(off) modulo 2^64. Loads zero-extend the little-endian value read at EA; stores write the low 1, 2, 4, or 8 bytes. Every memory access is checked under Section 12.8.4 before it changes a register or byte. In the tables, an I/R opcode pair selects I with the first opcode and S with the second.

Normative table. Load and store opcodes.

All arithmetic wraps at its stated width. The 32-bit result is zero-extended except that in V0, V1, and V3 the results of add32, sub32, and mul32 are sign-extended from bit 31; V2 zero-extends those results. V2 defines immediate subtraction as I-D; every other version and every register subtraction uses D-X. A register shift uses U32(S) mod 32 or S mod 64; an immediate shift must be in 0..31 or 0..63 and otherwise fails verification.

Normative table. ALU opcodes and semantics.

For an immediate-form row, X=I, except V2 unsigned 64-bit PQR immediates use U32(imm). An immediate zero divisor is rejected by the verifier. A zero register divisor raises DivideByZero; signed MIN / -1 and MIN % -1 raise DivideOverflow. No destination is written on either VM fault; externally the transaction records InstructionError::ProgramFailedToComplete at the active instruction index and the ordinary VM-failure depletion rule in Section 12.8.9 applies.

Normative table. V2-only product, quotient, and remainder opcodes.

For a conditional jump, the taken target is pc+1+off; the fall-through is pc+1. Both are instruction-word indices. JA always takes its target. Unsigned and signed rows interpret operands at the width in the table.

Normative table. Control-flow opcodes.

For V0–V2 CALL imm, U32(imm) is the Murmur3-32 symbol key of either a loader-registered syscall or an internal function. For V3, src=0 selects a syscall by the same key, while src=1 selects the internal target pc+1+sign_extend_i32(imm); any other src is unresolved. CALLX takes its virtual target from register number imm in V0/V1, src in V2, and dst in V3; only r0..r9 are legal. A call pushes r6..r9, the frame pointer, and the return PC; EXIT pops that frame or terminates the program when depth is zero.

An unknown opcode, illegal version/opcode combination, invalid register, write to r10, invalid branch/call target, branch into an LDDW continuation, malformed LDDW, immediate zero divisor, invalid shift/endian immediate, or misaligned V1/V2 add64 r10,imm is rejected before execution. V1/V2 alone may write r10 with add64 r10,imm, and its immediate must be a multiple of 64.

Normative table. SBF machine limits.

12.8.2 Registers, calls, and exit

SBF register names use a lowercase r: r0 through r11. Indexed notation such as r[dst] denotes the register selected by an instruction field; uppercase symbols such as D and S denote values read from registers, not register names.

Normative table.

At program entry, all registers are zero except r1, r2, r10, and the internal r11. r1 is 0x0000000400000000, the start of serialized input. r2 is the virtual address of instruction data inside that input. r10 is the version-dependent initial stack pointer, and r11 identifies the ELF entry instruction.

[SOL-SVM-0033] Internal calls MUST preserve r6..r9, enforce call depth 64, and apply the selected version’s static-frame or dynamic-frame rule. A program exit with r0 == 0 is success; any other r0 MUST map through the canonical u64-to-InstructionError conversion.

12.8.3 Active SBF versions

The ELF64 e_flags field selects the SBF version: 0, 1, 2, or 3.

Normative table.

[SOL-SVM-0034] The runtime MUST select one version solely from e_flags, reject a version outside V0–V3, and apply that version consistently to ELF parsing, verification, calls, stack behavior, and execution.

12.8.4 Virtual address space

Virtual addresses use 32 low address bits within each 4-GiB region. Address translation, aligned mapping, version-specific stack-frame gaps, and instruction metering apply. Account data is part of the serialized-input region rather than a separate direct mapping.

Normative table.

The default heap is 32,768 bytes. A compute-budget instruction may select a 1,024-byte multiple from 32,768 through 262,144 bytes. Stack allocation is 64 * 4096 = 262144 bytes before version-specific gaps/mapping.

[SOL-SVM-0035] Every load, store, syscall pointer, and indirect call MUST translate entirely within a mapped region with the required access permission. Overflow, cross-region access, write to read-only memory, and unmapped access MUST fault deterministically.

12.8.5 ELF loading and verification

V0–V2 use the lenient parser and relocation path; V3 uses the strict parser. Common acceptance requires a 64-bit little-endian ELF for machine EM_BPF, an entry aligned to an eight-byte instruction, text length divisible by eight, a supported e_flags version, a resolvable entrypoint, no conflicting function hashes, and bytecode accepted by the requisite verifier.

The V3 strict image has this program-header contract:

Normative table.

The verifier rejects empty or non-eight-byte-multiple text, unknown opcodes, invalid registers, forbidden writes to r10, invalid immediate shift/endian/divisor values, malformed LDDW, jumps outside text or into an LDDW continuation, invalid CALLX registers, and immediate calls that do not resolve under the selected version.

[SOL-SVM-0036] Deployment and loading MUST reject an ELF that violates its version’s header, relocation, symbol, text, entrypoint, syscall-resolution, or bytecode-verification rule before it can execute.

12.8.6 Program input ABI

The deprecated loader uses ABI v0. The supported BPF Loader and Upgradeable BPF Loader use ABI v1. In both cases input begins at 0x400000000 with account_count:u64 in little-endian order. Duplicate account entries contain an index of the first occurrence and alias that occurrence.

ABI v1 nonduplicate account record:

Normative table.

An ABI v1 duplicate record has this layout:

Normative table.

After all account records, the input ends with:

Normative table.

ABI v0 uses this nonduplicate record and a one-byte duplicate record:

Normative table.

Normative table.

[SOL-SVM-0037] On successful VM exit, the runtime MUST deserialize only permitted lamport, owner, data-length, and data changes. ABI v1 growth MUST NOT exceed 10,240 bytes over the entry length or the system maximum account-data length; readonly, ownership, executable, rent, and lamport-conservation rules MUST be enforced before instruction success.

12.8.7 Active syscall ABI

Every SBF syscall receives up to five u64 arguments in r1..r5 and returns a u64 in r0, or raises a VM/syscall error. V0–V2 link external symbols by the 32-bit Murmur3-x86 hash with seed zero over the UTF-8 symbol bytes; V3 encodes the same hash statically in CALL imm with src=0. Every guest pointer and integer in the following structures is an eight-byte little-endian u64; Boolean fields are one byte and accept only 0 or 1. Thus the table’s hash is both the V0–V2 relocation key and the V3 static index.

Normative table. Common syscall guest structures.

For a Rust stable vector, capacity is not an accepted element count; it must be at least length. The address points to length consecutive elements of the applicable element size.

Normative table. Complete epoch-E syscall registry and register ABI.

Every row in this registry is available to a newly deployed V0, V1, V2, or V3 program in epoch E; the SBF version changes only whether the hash is resolved through an ELF relocation or a static call. All feature gates that introduce these rows are active at E, so no row has an additional per-program feature condition. Availability for an already deployed program is derived by ProgramEnvironment from its loader and deployment slot, the invoking slot, and feature activation history, as required by SOL-SVM-0039.

sol_blake3, sol_sha512, sol_big_mod_exp, sol_remaining_compute_units, and sol_get_fees_sysvar are not registered in the epoch-E environment. sol_alloc_free_ is not accepted in a new deployment; a program deployed under a retained historical environment may resolve it only as described below.

Before any dereference, address+length and descriptor-array multiplication are checked for u64/host-size overflow. An output must lie wholly in writable guest memory and every input wholly in readable guest memory. Typed u64, i32, descriptor, point, scalar, CPI, and sysvar pointers have their natural alignment; byte and public-key buffers have alignment one. With the active parameter-address restriction, fixed/generic sysvar destinations may not begin in the serialized-input region. With the active output-overlap rule, cryptographic, PDA, hash, and return-data output intervals must not overlap an input interval to the same call. CPI additionally pins every supplied key, owner, lamport, and data pointer to that account’s ABI address and requires its mutable data-length word to be outside serialized account memory.

The direct fixed-sysvar syscalls copy their in-memory repr(C) objects, not their compact account serializations.

Normative table. Direct-sysvar syscall C layouts.

These writes require natural alignment and are all-or-nothing.

Except for the documented sibling-header capacity update and operations whose purpose is memory copying, no syscall makes a partial output: it charges at the point specified in Section 12.8.8, validates selectors/counts and all input/output mappings, computes into temporary host state, then writes the complete result. An invalid pointer/alignment/overlap or arithmetic overflow raises a syscall-originated instruction error; an ordinary nonzero result in the table does not raise an instruction error.

The curve selectors and fixed operand representations are:

Normative table. Curve selectors and operands.

For group add and subtract, the left and right pointers each address one point. For multiply, the left pointer addresses one scalar and the right pointer one point. Curve25519 MSM addresses consecutive 32-byte scalars and points and accepts 0..=512 pairs. A successful curve operation returns 0; an invalid point or scalar returns 1; an unsupported selector is an invalid attribute. BLS little-endian encodes each 48-byte base-field element least significant byte first and orders each G2 extension element as c0,c1; big-endian reverses each base-field element and orders it as c1,c0.

BN254 sol_alt_bn128_group_op receives (selector,input_address,input_length,result_address). A BN254 G1 point is x[32] || y[32]; a G2 point is four 32-byte base-field elements. Big-endian G2 order is x.c1 || x.c0 || y.c1 || y.c0 as in EIP-197; little-endian order is x.c0 || x.c1 || y.c0 || y.c1. Each coordinate and scalar uses the selector’s byte order.

Normative table.

BN254 compression uses the same endian flag and independent base selectors:

Normative table.

Poseidon accepts only parameter ID 0 (BN254, x-to-the-fifth S-box), endian ID 0 for big-endian or 1 for little-endian, and at most 12 input descriptors. Every nonempty input is exactly 32 bytes and encodes a field element strictly below the BN254 scalar-field modulus; the result is exactly 32 bytes in the selected byte order. A zero-input or invalid-field invocation is charged and returns 1 with output unchanged.

[SOL-SVM-0038] Every active cryptographic syscall MUST enforce the selector, operand length, byte order, point/scalar validity, count limit, and output length in the tables above; it MUST NOT truncate an oversized operand or accept a noncanonical field encoding.

Programs deployed before the active disable_deploy_of_alloc_free_syscall boundary may retain sol_alloc_free_; its arguments are allocation size and free address, and a zero free address allocates from the 32-KiB bump heap.

[SOL-SVM-0039] ProgramEnvironment MUST select the syscall surface above for new deployments and derive the historically compatible surface for an already deployed program from protocol inputs. Only a program deployed before the active disable_deploy_of_alloc_free_syscall boundary may resolve sol_alloc_free_. Any other imported symbol MUST fail loading or resolution.

12.8.8 Compute schedule

The following active cost parameters are in compute units. A syscall consumes its charge with checked depletion before returning its result; any overrun is ComputationalBudgetExceeded. Variable-length operations use saturating arithmetic and the formulas in the syscall contract.

Normative table.

Native dispatch contributes to the same execution term X in Section 10.4.1. The fixed charge is consumed before the native instruction body returns, so an instruction error does not refund it. Any nested CPI, SBF execution, syscall, or explicitly additive operation is charged in addition:

Normative table.

The ZK ElGamal proof program has zero additional dispatch base and consumes the following instruction charge before proof verification or context closure:

Normative table.

Poseidon cost for n inputs is 61*n^2 + 542. MSM cost for positive length n is base + (n-1)*increment. BLS pairing costs 25,445 + 13,023*max(n-1,0). BN254 pairing, where n=floor(input_length/192), costs 36,364 + 12,121*max(n-1,0) + 85 + input_length + 32; a malformed nonmultiple length is still charged by that formula before returning failure. Each generic hash syscall accepts at most 20,000 slices, charges 85 once, then for each slice of length L charges max(10, floor(L/2)). BN254 compression costs 100 plus the applicable 30, 398, 86, or 13,610 row constant.

The byte-dependent and invocation charges are:

Normative table.

For one CPI with m account metas, i account-info records, instruction-data length D, and unique callee account-data lengths A_j, argument translation adds:

Normative algorithm.

floor(D / 250)
+ floor(34*m / 250)
+ floor(80*i / 250)
+ sum(floor(A_j / 250))

The 80-byte account-info term is the active accounting size, independent of whether the guest used the C or Rust descriptor. Duplicate instruction accounts do not repeat the A_j term. Callee instructions, heap provisioning, syscalls, and nested CPI continue to draw from the same meter. All divisions in this subsection are unsigned integer floor; all sums and products saturate unless a named operation requires checked failure.

Normative table. Syscall charge point and failure charging.

No validation failure refunds compute already consumed. A syscall that returns an ordinary nonzero status instead of raising an instruction error consumes the same charge as the corresponding successful selected operation.

[SOL-SVM-0040] The runtime MUST calculate and consume every native dispatch, SBF instruction, heap, syscall, memory, cryptographic, return-data, sysvar, and CPI charge exactly by the tables and formulas above. All such charges MUST draw from the same transaction compute meter, and the remaining units at every protocol-visible boundary MUST follow the same charge sequence.

12.8.9 Completion, deserialization, and failure

On an ordinary VM exception other than a syscall-originated instruction error, the active deplete_cu_meter_on_vm_failure rule consumes all remaining transaction compute. A syscall-originated instruction error retains the compute already charged by that path. Successful VM exit is not instruction success until parameter deserialization, account-change validation, lamport balance, borrow checks, and invocation-pop checks all succeed.

[SOL-SVM-0041] SBF execution MUST follow the abstract machine independently of the host execution strategy. An access fault, arithmetic fault, invalid call, call-depth failure, verifier escape, or compute exhaustion MUST NOT commit program writes; a nonzero exit status or post-execution account-validation failure MUST enter the same Chapter 11 rollback path.

13. Protocol-owned programs and sysvars

13.1 Identity and deployment model

Protocol-owned behavior is selected by public key plus bank state, not by a human-readable program name. A program can be a native builtin, a Core-BPF deployment under an SBF loader, a stateless precompile, or feature-disabled. Migration can retain a public program identifier while changing its execution owner and code source.

[SOL-PRG-0001] Protocol-owned dispatch MUST use the exact program address and form listed in Section 13.2 for epoch E.

[SOL-PRG-0002] For every Core-BPF protocol program, replay MUST resolve and authenticate from the bank the loader, the ProgramData account when applicable, the executable bytes, the deployment slot, and the upgrade-authority state, then execute those bytes under Chapter 12.

[SOL-PRG-0003] A validator MUST select dispatch from the program account and active feature state visible in the bank and MUST NOT substitute a builtin just because the public key is historically associated with one.

[SOL-PRG-0004] A builtin-to-Core-BPF migration MUST update the program and ProgramData accounts, capitalization, program resolution, and execution-cost classification exactly at the activating bank. The migrated bytes MUST have deployment slot d and effective slot d+1, where d is the activating bank’s slot.

13.2 Known protocol identifiers

Normative table.

[SOL-PRG-0005] A program identifier absent from the epoch-E catalog MUST NOT acquire protocol-owned dispatch.

[SOL-PRG-0006] A native builtin MUST follow its normative native transition, while a Core-BPF program MUST follow the authenticated deployed bytes selected by ResolveProgram. A public identifier, historical native behavior, or prose summary MUST NOT override the bank-selected form.

13.3 Protocol program state

System, vote, stake, config, address-lookup-table, loader, feature, and proof-program accounts contain consensus state. Their state tags, byte layouts, authorities, signer/writable requirements, arithmetic, and error codes form part of consensus even when the program is implemented natively.

[SOL-PRG-0007] An active protocol program MUST decode instruction and account-state bytes with the exact bank-selected format and MUST deterministically reject unknown discriminants, truncation, invalid lengths, invalid authorities, missing signatures, and prohibited writable or owner combinations.

[SOL-PRG-0008] A protocol program MUST apply checked or saturating arithmetic exactly where its specified transition requires it and MUST return the specified error without committing partial program changes when a precondition fails.

[SOL-PRG-0009] Address-lookup-table resolution MUST use only lookup-table state produced by the active address-lookup-table program and visible under the bank-slot and SlotHashes rules in Chapter 7.

[SOL-PRG-0010] System durable-nonce initialization, authorization, advancement, withdrawal, and deallocation MUST preserve the nonce state and replay conditions used by Chapters 7 and 11.

13.3.1 System program

System-program instruction data is a Section 5.3 fixed-integer enum. It begins with the u32 little-endian discriminant below. A string is length:u64 || length UTF-8 bytes, has no terminator, and is limited to 32 bytes for a derivation seed. Public keys are 32 raw bytes. The decoder permits trailing instruction-data bytes after a complete variant.

Normative table.

For a seed-derived address, compute SHA256(base[32] || seed_bytes || owner[32]); the result must equal the address being allocated, assigned, created, or debited. Allocation requires a system-owned account with empty data and space <= 10,485,760; assignment requires empty data; a lamport transfer may debit only a system-owned account with empty data. CreateAccount additionally requires the destination balance to be zero. CreateAccountAllowPrefund omits only that zero-balance condition; all allocation, signer, derivation, funding, and assignment checks remain.

Normative table. System Program custom-error domain.

Instruction decode precedes account-list lookup. Thereafter the System Program checks account count and signer privilege in listed-account order, address/seed derivation, ownership and state, data length/allocation, then balances. A named custom error takes precedence at its predicate; otherwise the exact standard InstructionError in Section 12.7 applies.

[SOL-PRG-0011] The System program MUST decode the table above, enforce the listed signer and writable privileges, use checked lamport arithmetic, and perform allocation, assignment, transfer, and durable-nonce transitions atomically. An invalid derivation, owner, data length, balance, signature, or account list MUST fail the instruction without a partial System-program transition.

13.3.2 Upgradeable BPF loader

Upgradeable-loader state begins with a u32 little-endian discriminant. The fixed metadata offsets, rather than the serialized length of an absent option, locate following program bytes.

Normative table.

Management instruction data is another Section 5.3 fixed-integer enum:

Normative table.

Normative table. Upgradeable-loader ordered accounts and transitions.

ProgramData is derived from the Program address by the Section 5.5 PDA algorithm with the Program address as the sole seed and the Upgradeable BPF Loader as program ID. Write ranges must remain within the Buffer data after byte 37. Deploy and upgrade validate the resulting ELF under Section 12.8.5, copy program bytes into ProgramData after byte 45, set the deployment slot, and make the Program account executable. An upgrade or authority change requires the current authority; SetAuthorityChecked also requires the new authority. ExtendProgram adds at least 10,240 bytes unless fewer than 10,240 bytes remain before the 10-MiB account limit, and cannot exceed that limit.

[SOL-PRG-0012] The Upgradeable BPF Loader MUST preserve the state tags, metadata offsets, PDA relationship, authority checks, minimum extension, deployment slot, executable transition, and bank-visible program bytes above. A successful deploy or upgrade at slot d MUST set effective slot d+1; the new bytes are unavailable for invocation in d and become resolvable in the child slot.

13.3.3 Vote program

Vote-account data is a Section 5.3 fixed-integer enum followed by unused account capacity. Its first four bytes are a little-endian state discriminant: 0 Uninitialized, 1 V1_14_11, 2 V3, or 3 V4. The decoder permits unused trailing bytes. Serialization overwrites the encoded prefix but preserves any remaining account bytes, which therefore remain part of the account hash.

The component encodings used below are:

Normative table.

Legacy states remain decodable because an untouched account can retain them. Their exact field sequences after the four-byte state discriminant are:

Normative table.

Every successful epoch-E Vote-program mutation stores V4 and grows a shorter legacy account to 3,762 bytes only if its balance is rent-exempt at that length. The V4 prefix after discriminant 3 is:

Normative table.

Vote instruction data also begins with a u32 little-endian discriminant and permits trailing bytes. Only the following forms execute in epoch E; any other Vote-instruction discriminant is invalid instruction data.

Normative table.

Authority-kind is LE(0,4) for a voter, LE(1,4) for a withdrawer, or LE(2,4) || bls_key[48] || proof_of_possession[96] for a BLS voter. A seed string uses length:u64 || UTF-8 bytes and is at most 32 bytes.

Normative table.

Offsets are accumulated with checked u64 addition and must produce strictly increasing vote slots. The voted-bank hash must equal SlotHashes for the last vote, and the block identifier field is the Chapter 14 terminal FEC root for the same slot. Vote lockouts, roots, authorization, timestamp monotonicity, credit accrual, withdrawals, collector fields, and commission updates are applied to the V4 fields as specified by Chapters 15 and 16.

[SOL-PRG-0013] The Vote program MUST accept only the epoch-E instruction forms above, decode legacy account states exactly, store every successful mutation as V4, and enforce the named authority, tower, SlotHashes, timestamp, rent, credit, withdrawal, and commission rules without partially updating the vote account on failure.

Normative table. Vote Program custom-error domain.

Vote instruction decode and account-count/signature checks precede these semantic errors. For a vote/tower update, test empty/ordered/bounded tower shape, old-slot filtering, SlotHashes membership and bank hash, proposed-root ancestry, lockout consistency, then timestamp monotonicity; the first failing predicate supplies the value above. Authority/owner/account-data failures use the exact standard InstructionError from Section 12.7.

13.3.4 Stake Program v5

A Stake account is exactly 200 bytes, owned by the Stake Program, and decoded with FIXINT-LE. Bytes not occupied by the selected state are retained as zero/unused capacity and remain committed by the account hash.

Normative table. Stake v5 state byte layout.

Stake instructions use FIXINT-LE: a u32 discriminant followed by the payload below. Option<T> is tag byte 0, or 1||T; StakeAuthorize is u32 0 staker or 1 withdrawer. LockupArgs is optional i64, optional u64, optional key; the checked form omits the key and takes a signed new custodian account. A seed string is u64 length || UTF-8 and at most 32 bytes.

Normative table. Stake v5 instructions and ordered accounts.