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.
- 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
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/SubscribeSee 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 |
|---|---|---|---|
| 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 |
| 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 |
| Transfer | instruction | Transfers SOL (lamports) between two accounts. Decoded with from / to / lamports, this is the canonical SOL transfer signal. | Very high |
| CreateAccountWithSeed | instruction | Deterministic account creation, derives the new address from base + seed + owner. Used by stake accounts, governance vesting, and durable nonces. | Medium |
| AdvanceNonceAccount | instruction | Rotates a durable-nonce account to its next blockhash. Required by every wallet using durable nonces for offline transaction signing. | Medium |
| WithdrawNonceAccount | instruction | Withdraws lamports from a durable-nonce account, optionally closing it. Surfaces nonce-account lifecycle changes. | Low |
| InitializeNonceAccount | instruction | Marks an account as a durable-nonce account and seeds the first nonce. The setup step before AdvanceNonceAccount can run. | Low |
| AuthorizeNonceAccount | instruction | Changes the authority that can advance or withdraw a durable-nonce account. | Low |
| Allocate | instruction | Sets the data byte length of an existing account. Used together with Assign when bootstrapping accounts in two phases. | Medium |
| AllocateWithSeed | instruction | Allocate bytes for a derived account. Deterministic counterpart to Allocate. | Low |
| AssignWithSeed | instruction | Reassigns a derived account to a new owner. Pairs with AllocateWithSeed. | Low |
| TransferWithSeed | instruction | Transfers lamports out of a derived account. The deterministic counterpart to Transfer for accounts created with seeds. | Medium |
| UpgradeNonceAccount | instruction | Upgrades a legacy nonce account to the modern format. Largely historical, runs once per old nonce account. | Low |
| 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 |
System Program at-a-glance
last reviewed 2026-04-28
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]andsuccesslines that mark every System Program invocation. Observable throughlogsSubscribe, 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
SystemInstructionenum.
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.
CreateAccount, CreateAccountWithSeed, CreateAccountAllowPrefund, Allocate, AllocateWithSeed, Assign, AssignWithSeed. Every fresh account on Solana passes through one of these: wallets, ATAs, stake accounts, PDAs, governance accounts.
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.
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.
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.
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.
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
Related products
Higher-level wallet-transfer feed combining System Program Transfer with SPL Token transfers in one stream.
Browse every curated, server-decoded Enhanced Stream we ship.
The transport behind every NoLimitNodes parsed-event stream.
Full-breadth, as-is feeds across 1,074 topics on 37 programs, including the System Program.
Bonding curve creates, trades, and graduations decoded in real time.
Post-graduation memecoin AMM swaps with full mint resolution.
Stream every SOL transfer in under 60 seconds
Pro plan from $49/mo includes 2 parsed streams. The System Program stream covers Transfer, CreateAccount, durable nonces, and every other variant.