Appearance
What is Zink?
Zink is an independent SVM network for builders who want familiar Solana tooling with dedicated execution, configurable infrastructure, and direct control over network policy. It executes SVM bytecode, uses the same Ed25519 account model, and speaks the same JSON-RPC protocol as Solana mainnet — while operating with its own genesis, validator set, and governance.
If you have shipped code on Solana, you already know how to ship code on Zink. The difference is operational, not architectural: a separate cluster URL, a separate token supply, and a validator set managed by the Zink network operators rather than Solana's open staking market.
Why a dedicated network?
Running applications on an independent SVM network gives builders and operators control over several dimensions that a shared L1 cannot provide:
- Validator set composition — the operator group is curated rather than permissionless, allowing tighter SLAs and coordinated upgrades.
- Upgrade cadence — new Agave releases are adopted on the Zink team's schedule after internal testing, not on the broader Solana governance timeline.
- Fee and resource parameters — compute unit pricing, account rent, and priority fee floors can be tuned for high-throughput application workloads.
- Isolation — application-critical state is not competing for block space with unrelated DeFi or NFT activity.
Zink-specific
Zink's native token, validator economics, and governance structure are independent of Solana mainnet. Tokens must be moved between the two networks via the Zink Bridge. There is no automatic asset equivalence between chains.
What stays the same
| Concept | Compatible? |
|---|---|
| Account model (owner, lamports, data, executable) | Yes |
| Transaction format (versioned transactions, address lookup tables) | Yes |
| Program deployment (BPF/SBF bytecode via the loader) | Yes |
Solana CLI (solana config, solana transfer, etc.) | Yes |
| Starframe framework | Yes |
web3.js / @solana/web3.js | Yes |
| Wallet adapters (Phantom, Solflare, Backpack, etc.) | Yes |
| SPL Token program and Associated Token Accounts | Yes |
Upstream-compatible
Point standard Solana tooling at a Zink RPC URL and the workflow remains familiar: deploy, simulate, sign, and query through the same commands and SDKs. The required change is configuration, not a Zink-specific fork.
What differs
- Cluster endpoints — Zink has its own RPC and WebSocket URLs. See Clusters & Environments.
- Validator set — currently permissioned. You cannot self-stake and join; participation requires coordination with network operators.
- Genesis and epoch schedule — independent from Solana mainnet.
- Bridge requirement — assets originating on Solana must be bridged in; assets on Zink must be bridged out. See Bridge Overview.
Zink recommendation
Always verify your wallet and tooling are pointed at the correct Zink cluster before interacting with live on-chain state. Sending a transaction to Solana mainnet by mistake will not reach Zink, and vice versa.
How this documentation is organized
The Network section covers infrastructure and operations:
| Page | What it covers |
|---|---|
| Clusters & Environments | Available clusters, RPC URLs, and how to choose an environment |
| Validator vs RPC Node | Role differences and when to run each |
| System Requirements | Hardware, OS, and networking specs |
| CLI & Tooling | Configuring standard Solana tools for Zink |
| Wallets & Keypairs | Key generation, wallet setup, and security practices |
| Run a Validator | End-to-end validator setup and operation |
| Run an RPC Node | Standing up an RPC node for application use |
| Monitoring & Observability | Metrics, dashboards, and alerting |
| Compatibility Policy | How Zink tracks upstream Agave releases |
| Troubleshooting | Common issues and diagnostic steps |
For program development, see Program Development on Zink. For bridging assets, see Bridge Overview.