SVM execution
ZUL embeds Agave's SVM crate— the same execution pipeline real Solana validators run — inside its own node. This is the "SVM API" approach: the node implements the processor's account-loading callback over its own store, and the SVM does what the SVM does.
How the embedding works
- A transaction batch processorexecutes each block's transactions against a callback that loads accounts from the redb store.
- The node maintains sysvars itself: Clock advances every slot, Rent and friends are populated at genesis.
- Outputs (account writes, fee debits, logs, CU usage) are collected per transaction and committed atomically with the block.
Preloaded programs
Genesis installs the standard program set, so the usual Solana developer surface exists from slot 0:
| PROGRAM | NOTES |
|---|---|
| System Program | Transfers, account creation — native ZUL lamports. |
| SPL Token + Token-2022 | Run as preloaded BPF programs, unmodified. |
| Associated Token | Standard ATA derivation works as on Solana. |
| Memo, Compute Budget | Standard behavior. |
| Shielded Pool | ZUL's own builtin — native Rust, not BPF. See Shielded pool. |
User-deployed BPF programs work the same way they do on Solana — deploy with standard tooling against the L2 RPC.
Why a builtin for privacy
Groth16 verification inside a BPF program fights the compute-unit budget and syscall surface. As a builtin, verification runs as native code on the node's own CPU budget — milliseconds, no CU gymnastics — while still being metered and deterministic. This is the single biggest advantage of being "a chain with privacy enshrined" instead of "a privacy contract on someone else's chain."
The execution spike that validated this design was: run a System transfer and an SPL mint through the embedded SVM in a Rust test, and require balances to change. Everything else grew around that proven core.