Compatibility Policy

Zink is designed to stay operationally and programmatically compatible with upstream Agave / Solana releases while sequencing upgrades on its own release timeline.

What compatibility means here

Compatibility covers the parts developers and operators depend on most:

• SVM execution model
• account model and ownership rules
• transaction format
• JSON-RPC surface
• Solana CLI and common SDK workflows
• standard program deployment and upgrade flows

Upstream-compatible

If a program compiles and behaves correctly on a compatible Agave release, expect the same behavior on Zink after you point the client, deployment scripts, and tests at Zink endpoints and Zink state.

What can differ

Zink may diverge from Solana mainnet in ways that do not break the developer model but do affect operations:

• validator-set membership
• genesis configuration
• cluster topology and entrypoints
• fee parameters and resource economics
• rollout timing for new runtime versions
• support policy for specific operator configurations

Zink-specific

The goal is runtime compatibility, not bit-for-bit sameness with Solana mainnet at every moment in time.

Release model

Use upstream Agave release semantics as the baseline mental model:

• major releases can remove deprecated behavior or introduce breaking changes
• minor releases add features and runtime improvements
• patch releases typically deliver fixes, security updates, or lower-risk maintenance work

Zink will evaluate those upstream releases before cluster rollout rather than adopting them blindly.

Operator expectations

Before validator or RPC changes:

1. check the running cluster version
2. align local tooling with that version
3. review release notes and any Zink-specific operator guidance
4. avoid ad hoc upgrades during active incidents

Useful commands:

solana cluster-version
solana --version
agave-validator --version

Developer expectations

For application and program teams:

• pin dependencies deliberately
• validate deployment flows against the currently running cluster version
• test version-sensitive behavior before production rollouts
• treat new runtime features as cluster-dependent until confirmed on Zink

Breaking-change handling

If upstream introduces a change that affects Zink operators materially, Zink may:

• delay rollout
• document migration requirements first
• publish operator guidance before adoption
• keep cluster-specific restrictions in place longer than Solana mainnet

Where to check current status

Use the following sources together:

• Release Notes
• RPC Endpoints
• solana cluster-version

Zink recommendation

Do not assume that “latest upstream” equals “currently live on Zink.” Confirm the live cluster version before deploying programs, changing validator binaries, or debugging version-sensitive behavior.