Appearance
Program Development on Zink
Program development on Zink is SVM development for an independent network. Programs compile to sBPF, use the familiar account and transaction model, and work with the standard Solana ecosystem clients and frameworks by changing the RPC endpoint. If you have already shipped an SVM program, the same artifact can target Zink without source changes.
This section covers the core concepts you need to write, test, and deploy on-chain programs targeting Zink.
Upstream-compatible
Zink runs the standard SVM execution model. Existing programs built for compatible Solana/Agave runtimes can run on Zink with no source changes and no recompilation — the same .so artifact deploys to the target cluster.
Zink-specific
Zink is configured independently from Solana mainnet. Cluster endpoints, fee schedules, epoch length, and governance policies can differ, and those differences are called out throughout the docs where they apply.
Zink recommendation
Coordinate with the relevant maintainers on program deployment schedules and ecosystem integration requirements before deploying to Zink mainnet. Programs that interact with existing infrastructure may need review for compatibility with live on-chain state.
How Zink relates to Solana
| Aspect | Relationship to Solana |
|---|---|
| Runtime | Identical — the SVM executes sBPF bytecode the same way |
| Account model | Identical — same fields, same ownership rules, same rent mechanics |
| Transaction format | Identical — legacy and versioned transactions, same serialization |
| Toolchain | Identical — cargo build-sbf, Starframe, Solana CLI, all work unchanged |
| RPC API | Identical — same JSON-RPC and WebSocket methods |
| Cluster endpoints | Different — Zink has its own RPC URLs (see Local Setup) |
| Fee parameters | May differ — base fees and compute pricing are configured per-cluster |
| Native programs | Identical — System Program, BPF Loader, Token Program, etc. are present |
| Governance | Different — Zink has its own upgrade authority and governance process |
In practice, the only thing you change to move from Solana to Zink is the --url flag on your CLI or the endpoint in your client code.
What you will find here
| Page | What you will learn |
|---|---|
| Quickstart | Build, test, and deploy your first program end-to-end |
| Local Setup | Install the toolchain and configure the CLI for Zink clusters |
| Starframe | Use Starframe as a high-performance, type-safe framework for Zink programs |
| Accounts | The account model — structure, ownership, rent, and size limits |
| Transactions | Transaction anatomy, signing, lifecycle, versioned transactions, and address lookup tables |
| Fees | Base fees, prioritization fees, compute units, and the compute budget |
| Programs | Executable accounts, the sBPF runtime, upgradability, and native programs |
| PDAs | Program Derived Addresses — derivation, bump seeds, and common patterns |
| CPI | Cross-Program Invocation — invoke, invoke_signed, and composability |
| Tokens | SPL Token Program, Token-2022, mint/token accounts, ATAs, and authorities |
| Frontend Integration | Connecting web apps and wallets to Zink |
| SDKs | Client libraries for TypeScript, Rust, Python, and more |
| Testing & Localnet | Local validator, test strategies, and CI patterns |
| Deployment | Deploying and upgrading programs on Zink clusters |
Key mental model
Three ideas underpin everything else:
Accounts hold all state. Programs are stateless functions. Every piece of persistent data — balances, records, program bytecode itself — lives in an account. See Accounts.
Transactions are atomic batches of instructions. Each instruction targets one program and passes it a set of accounts. If any instruction fails, the entire transaction rolls back. See Transactions.
Programs are composable via CPI. Any program can call any other program's instructions within the same transaction, enabling the deep composability the Solana ecosystem is known for. See CPI.