What is the Solana System Program ID?

11111111111111111111111111111111. The all-ones base58 address. It's one of Solana's native runtime programs, installed at genesis, not deployed via BPF. It implements account creation, lamport transfers, durable-nonce accounts, and account-data allocation. Every Solana transaction touches it directly or transitively.

What are all the System Program instructions?

14 SystemInstruction variants: CreateAccount, Assign, Transfer, CreateAccountWithSeed, AdvanceNonceAccount, WithdrawNonceAccount, InitializeNonceAccount, AuthorizeNonceAccount, Allocate, AllocateWithSeed, AssignWithSeed, TransferWithSeed, UpgradeNonceAccount, and the newer CreateAccountAllowPrefund. The full enum lives in the solana-system-interface Rust crate; Web3.js exposes equivalents via SystemInstruction.decodeInstructionType.

How do I detect SOL transfers in real time on Solana?

Subscribe to the System Program over gRPC with a transactions filter on 11111111111111111111111111111111. Decode each SystemInstruction payload with bincode (Rust) or @solana/web3.js (TypeScript). Route the Transfer variant to your handler. You get fromPubkey, toPubkey, and lamports. We pre-decode that for you, so the parsed Transfer event arrives ready to use. logsSubscribe with mentions on the System Program also works at low volume, but it's firehose-y at production scale.

How do I monitor new account creation on Solana?

Filter on CreateAccount and CreateAccountWithSeed (and CreateAccountAllowPrefund where supported). The instruction payload carries the new account address, funding amount, allocated byte length, and owner program. That's enough to detect freshly minted token accounts, stake accounts, governance accounts, or PDAs the moment they're initialized. CreateAccountAllowPrefund additionally surfaces accounts that received SOL before being formally created.

What's the difference between Solana logs and Solana events?

Logs are arbitrary text frames a program writes during execution: 'Program log:' messages, 'Program data:' emit! payloads, and the runtime's own invoke / consumed / success frames. Events are a higher-level Anchor concept: a structured payload encoded against the program's IDL, written via emit! to a 'Program data:' frame, decoded back to a typed object on the client. Native programs like the System Program don't use Anchor, so they don't emit events. They emit logs only. The richer signal lives in the parsed instruction stream.

How can I get historical System Program activity for an address?

getSignaturesForAddress on any RPC lists every signature that touched a wallet. Hydrate with getTransaction to inspect the System Program instructions inside. For volume work, the parsed-stream historical archive avoids the per-signature round-trip. Pair us with the historic-blocks product for bulk access.

Is logsSubscribe filtering on the System Program a good idea?

Only for prototypes. The System Program is invoked in nearly every Solana transaction (token sends, ATA creates, swaps, mints all use it indirectly), so logsSubscribe filtered on its program ID returns roughly 20% of all program logs on mainnet. JSON framing caps practical throughput around a few hundred messages per second per WebSocket. For production, the right tool is gRPC with a transactions filter on the System Program ID plus a discriminator side-filter for Transfer or CreateAccount.

Enhanced Stream

Solana System Program events: what they are, what they aren't, and how to listen

Search "Solana System Program events" and you get a wall of confusion. Half the results are about Anchor events. The System Program is not an Anchor program. It does not call emit!. It does not have an IDL. What it has is 14 typed instructions, the standard program-log frames every Solana transaction emits, and the on-chain side effects of running them. That is the actual answer to the question, and this page is the long version. We also ship a parsed real-time stream of every Transfer, CreateAccount, Assign, and nonce instruction over gRPC so you can stop trying to parse logsSubscribe by hand.

All 14 instructions decodedSOL transfers + account createsSub-50ms latencySkip the firehoseFree RPC tier

On-chain programs

Solana System Program11111111111111111111111111111111, The all-zeros base58 program ID, the most-invoked program on Solana mainnet

Try it live: System Program streams

decoded solana events over grpc · click Run to see live data

2 streamslive

SOL & Token Transfers

All native SOL and SPL token transfers network-wide

1grpcurl -H "x-api-key: YOUR_API_KEY" \
2  -d '{"topic":"prod.rpc.solana.system.transfers","format":"JSON"}' \
3  stream-1.nln.clr3.org:443 nln.stream.v1.StreamService/Subscribe

Live Output

See real data

Click Run to stream 5 live SOL & Token Transfers messages

Pro: 2 streams $49/mo · Ultra: 20 streams $199/mo · pre-parsed, zero infra

The 14 System Program instructions you can stream

every variant of SystemInstruction, decoded and ready to consume

Event	Type	Description	Frequency	Latency
CreateAccount	instruction	Creates a new account funded with lamports, allocated bytes, and an owner program. The on-chain handshake every wallet, ATA, and PDA derives from.	Very high	12ms
Assign	instruction	Reassigns an existing account to a new owner program. Used when initializing accounts that were created with seed and need to be owned by a downstream program.	Medium	12ms
Transfer	instruction	Transfers SOL (lamports) between two accounts. Decoded with from / to / lamports, this is the canonical SOL transfer signal.	Very high	12ms
CreateAccountWithSeed	instruction	Deterministic account creation, derives the new address from base + seed + owner. Used by stake accounts, governance vesting, and durable nonces.	Medium	12ms
AdvanceNonceAccount	instruction	Rotates a durable-nonce account to its next blockhash. Required by every wallet using durable nonces for offline transaction signing.	Medium	12ms
WithdrawNonceAccount	instruction	Withdraws lamports from a durable-nonce account, optionally closing it. Surfaces nonce-account lifecycle changes.	Low	12ms
InitializeNonceAccount	instruction	Marks an account as a durable-nonce account and seeds the first nonce. The setup step before AdvanceNonceAccount can run.	Low	12ms
AuthorizeNonceAccount	instruction	Changes the authority that can advance or withdraw a durable-nonce account.	Low	12ms
Allocate	instruction	Sets the data byte length of an existing account. Used together with Assign when bootstrapping accounts in two phases.	Medium	12ms
AllocateWithSeed	instruction	Allocate bytes for a derived account. Deterministic counterpart to Allocate.	Low	12ms
AssignWithSeed	instruction	Reassigns a derived account to a new owner. Pairs with AllocateWithSeed.	Low	12ms
TransferWithSeed	instruction	Transfers lamports out of a derived account. The deterministic counterpart to Transfer for accounts created with seeds.	Medium	12ms
UpgradeNonceAccount	instruction	Upgrades a legacy nonce account to the modern format. Largely historical, runs once per old nonce account.	Low	12ms
CreateAccountAllowPrefund	instruction	Newer variant of CreateAccount that tolerates the destination already holding lamports. Useful for ATAs derived to addresses that have received SOL airdrops.	Low	12ms

System Program at-a-glance

last reviewed 2026-04-28

Daily invocations

50-150M

Estimated System Program instructions per day across mainnet, most-invoked program on Solana

Verified 2026-04-28

Transfer latency

12ms

p50 from slot landing to your socket; parsed Transfer event over gRPC

Verified 2026-04-28

Discriminator filter savings

~80%

Volume reduction when subscribing to Transfer-only vs all System Program logs

Stream uptime SLO

99.95%

Pro and Ultra plans, monthly rolling

Does the System Program emit events? A clarification.

Short answer: no. Not in the way most Solana developers mean when they say “event.” Anchor programs emit events with the emit! macro. Under the hood that calls sol_log_data and writes a base64-encoded payload to the program logs. That payload is decodable against the program's IDL, and it's what most people parse when they say they're “listening to events.”

The System Program is native. Not deployed as BPF. No Anchor IDL. Never calls sol_log_data. What it emits is two things:

Program-log frames. The standard Program 11111111111111111111111111111111 invoke [1] and success lines that mark every System Program invocation. Observable through logsSubscribe, but they carry no instruction payload.
On-chain instruction effects. The actual lamport transfers, ownership changes, and new accounts. Observable through any parsed instruction stream that filters on the program ID and decodes the bincode-serialized SystemInstruction enum.

So when someone asks for “Solana System Program events,” the right tool is the second category: a parsed instruction stream. The rest of this page is exactly that. What the 14 instruction variants are, how they map to real activity (SOL transfers, account creation, durable nonces), and how to subscribe to them with us.

All 14 System Program instructions

The complete enum is in solana_system_interface::instruction::SystemInstruction. Each variant has a fixed bincode discriminator that lets you filter the stream to just the activity you care about. The events table above lists each one with frequency and decoding shape. Below is the same set, grouped by what they actually do on chain.

Account lifecycle

CreateAccount, CreateAccountWithSeed, CreateAccountAllowPrefund, Allocate, AllocateWithSeed, Assign, AssignWithSeed. Every fresh account on Solana passes through one of these: wallets, ATAs, stake accounts, PDAs, governance accounts.

Lamport movement

Transfer and TransferWithSeed. Decoded with from / to / lamports, these are the canonical SOL transfer signals. The right primitives for exchange deposit detection, balance dashboards, and on-chain payment rails.

Durable nonces

InitializeNonceAccount, AdvanceNonceAccount, WithdrawNonceAccount, AuthorizeNonceAccount, UpgradeNonceAccount. The mechanism behind offline transaction signing. Every wallet doing durable transactions (Ledger, hardware-wallet flows) rotates these on a schedule.

Logs vs events vs instructions: pick the right surface

The three terms get used interchangeably and the choice you make here directly affects throughput and parsing cost. Here's the precise version.

Term	Source	System Program?	Subscribe via
Logs	Free-form text + sol_log_data	Yes (frames only, no payload)	logsSubscribe
Events	Anchor emit!: IDL-typed payload in logs	No	logsSubscribe + IDL decoder
Instructions	Bincode SystemInstruction	Yes, the right surface	gRPC transactions filter

For the System Program, only one row is the right answer: instructions over gRPC. logsSubscribe will fire on roughly one in five logs on Solana mainnet because nearly every transaction touches the System Program at some point, and most of those frames carry no useful payload. Subscribing to events doesn't work at all because there are none. Filtering instructions over gRPC, with an optional discriminator side-filter for Transfer or CreateAccount, gives you a manageable, fully-typed feed.

Three ways to monitor System Program activity

The choice is between throughput, latency, and operational complexity. Here's how each one lines up.

RPC pubsub

logsSubscribe with mentions: ["1111…"] over a WebSocket. Easiest to set up. JSON framing caps throughput in the low hundreds of messages per second per connection. Fine for a prototype, painful at production scale.

Yellowstone gRPC

The production answer. One HTTP/2 stream multiplexes account / transaction / slot subscriptions. Payloads are binary protobuf. We pre-decode System Program instructions, so what you receive is a typed Transfer with from / to / lamports, not a raw bincode buffer.

Webhooks

Some providers ingest the firehose for you and POST System Program events to your URL. Easy to consume. Adds an outbound HTTP hop (typically 50-150ms) and is only as reliable as your endpoint. Best for low-volume operational alerts, not MEV or sniping.

See the Yellowstone gRPC nodes page for transport details, and the wallet-transfers stream for a higher-level feed that combines System Program transfers with SPL Token transfers in one event shape.

What teams build on the System Program stream

Exchange deposit detection

CEXs and on-ramps subscribe to Transfer filtered by destination wallet, then credit user accounts the moment a deposit confirms. Same stream covers SOL deposits to user-specific sub-accounts derived via CreateAccountWithSeed.

Wallet onboarding signals

Filter CreateAccount by owner = SystemProgram and lamports above the rent-exempt threshold to count fresh user wallets being initialized. A leading indicator of new active addresses on chain.

Anti-fraud & forensics

Real-time SOL fan-out detection. A hot wallet draining lamports to many fresh accounts inside a few slots is the canonical money-laundering pattern. Subscribing to Transfer with a sliding-window aggregator surfaces it in seconds.

On-chain analytics

Aggregating Transfer and CreateAccount per slot produces leading indicators for active addresses, network usage, and rent consumed. Cleaner signal than top-level transaction counts because it filters out vote transactions automatically.

Frequently asked questions

No, not in the Anchor sense. Anchor programs emit events using the emit! macro, which compiles to a sol_log_data syscall and writes a base64-encoded payload into the program logs. The System Program is a native, pre-Anchor runtime program written in Rust against solana-system-interface. It does not call sol_log_data. What it does emit is two things: standard program-log frames like 'Program 11111111111111111111111111111111 invoke [1]' and 'success', and the on-chain side effects of its instructions (lamports change, ownership changes, new accounts appear). 'Listen for System Program events' in practice means subscribing to its instructions, not parsing emit! payloads.