Deployment

Once your program is built and tested, you can deploy it to a Zink cluster. This page covers the full deployment lifecycle: initial deploy, upgrades, authority management, and operational practices.

Upstream-compatible

Deploying to Zink uses the same commands and process as deploying to Solana mainnet. The BPF Loader, buffer accounts, and upgrade authority mechanics are identical.

How deployment works

Deploying a program on the SVM is a multi-step process managed by the BPF Loader:

1. The CLI writes your compiled .so file into a temporary buffer account in chunks (each transaction has a size limit).
2. Once the buffer is complete, the CLI issues a deploy instruction that creates (or updates) the program account and points it at the buffer's data.
3. The program account becomes executable and is assigned an upgrade authority — the keypair that controls future upgrades.

The entire process is handled transparently by solana program deploy.

Deploying with the Solana CLI

Initial deployment

# Build the program
cargo build-sbf

# Deploy to the configured cluster
solana program deploy target/deploy/my_program.so

The CLI outputs the program ID on success:

Program Id: 5rFw5d...Hn3ko

Specifying a keypair for the program ID

By default, solana program deploy generates a new program ID on first deploy. To use a specific keypair (recommended for deterministic program addresses):

# Generate a keypair for your program (do this once)
solana-keygen new -o target/deploy/my_program-keypair.json

# Deploy with the specific keypair
solana program deploy \
  target/deploy/my_program.so \
  --program-id target/deploy/my_program-keypair.json

Starframe scaffolds this keypair for you under target/deploy/ and writes the public key into the program declaration. Use that generated keypair when deploying the scaffolded program.

Deploying with a specific authority

solana program deploy target/deploy/my_program.so \
  --upgrade-authority <AUTHORITY_KEYPAIR>

If not specified, the upgrade authority defaults to the keypair configured in solana config get.

Verifying a deployment

After deploying, confirm the program is live and inspect its metadata:

solana program show <PROGRAM_ID>

Example output:

Program Id: 5rFw5d...Hn3ko
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: 3xQ8r...vTm2
Authority: 9aE2k...Bw7qP
Last Deployed In Slot: 12345678
Data Length: 214032 (0x34470) bytes

Key fields to verify:

• Authority — confirms who can upgrade this program
• Data Length — matches your .so file size
• Last Deployed In Slot — confirms the deployment was recent

Upgrading a program

Programs deployed through the BPF Loader are upgradeable by default. The upgrade authority can push a new binary at any time:

# Build the updated program
cargo build-sbf

# Deploy the upgrade
solana program deploy target/deploy/my_program.so \
  --program-id <PROGRAM_ID>

The upgrade is atomic — the program account switches to the new bytecode in a single transaction. There is no downtime.

Upgrade considerations

• Account layout changes must be backwards-compatible. Existing accounts on-chain contain data serialized with the old layout. If you change the struct, ensure the new program can deserialize both old and new formats, or migrate accounts explicitly.
• IDL updates — if you generate a Codama IDL from Starframe, regenerate it after changing the instruction or account surface: cargo test --features idl -- generate_idl.
• Test the upgrade on Zink Testnet first. Deploy the new version to the published non-production cluster and verify it handles existing account state before upgrading mainnet.

Upgrade authority

The upgrade authority is the keypair that has permission to deploy new versions of a program. Managing it carefully is critical to program security.

Checking the current authority

solana program show <PROGRAM_ID>

The Authority field shows the current upgrade authority public key.

Transferring the authority

To transfer the upgrade authority to a different keypair (for example, a multisig):

solana program set-upgrade-authority <PROGRAM_ID> \
  --new-upgrade-authority <NEW_AUTHORITY>

Making a program immutable

To permanently revoke upgrade authority:

solana program set-upgrade-authority <PROGRAM_ID> --final

Irreversible

Setting upgrade authority to None is permanent. Only do this once the program is fully audited and you are certain no future upgrades will be required.

Deployment environments

Local validator

solana config set --url http://127.0.0.1:8899
solana-test-validator
cargo build-sbf
solana program deploy target/deploy/my_program.so

Use local deployments for rapid iteration. Reset state with solana-test-validator --reset.

Zink Testnet

solana config set --url https://testnet-rpc.z.ink
solana balance
solana program deploy target/deploy/my_program.so

Testnet is for integration testing and pre-production validation. The published public endpoint is https://testnet-rpc.z.ink.

Zink Mainnet

Mainnet deployments require operational coordination:

# Point CLI at the mainnet endpoint supplied by your operator/onboarding flow
solana config set --url https://your-operator-provided-zink-mainnet-rpc.example
solana balance
solana program deploy target/deploy/my_program.so

Zink-specific

Mainnet deployment funding and any review requirements are managed by the Zink network operators. See Clusters & Environments for environment details.

Verifiable builds

Verifiable builds allow anyone to confirm that a deployed program binary matches specific source code. This builds trust with users and auditors.

Using solana-verify

# Install the verifier
cargo install solana-verify

# Build reproducibly inside a Docker container
solana-verify build

# Verify a deployed program against source
solana-verify verify-from-repo \
  --program-id <PROGRAM_ID> \
  --url https://testnet-rpc.z.ink \
  https://github.com/your-org/your-repo

The verifier builds your program in a deterministic Docker environment and compares the resulting .so to the on-chain bytecode byte-for-byte.

Monitoring a deployed program

After deployment, monitor your program's health:

Transaction logs

# Stream logs for your program in real time
solana logs <PROGRAM_ID> --url https://testnet-rpc.z.ink

# Fetch logs for a specific transaction
solana confirm -v <TRANSACTION_SIGNATURE> --url https://testnet-rpc.z.ink

Program usage metrics

Track program activity by querying recent transactions:

solana transaction-history <PROGRAM_ID> --url https://testnet-rpc.z.ink --limit 10

For production monitoring, consider indexing program transactions with a dedicated indexer or using the logsSubscribe WebSocket method for real-time alerts.

Buffer account cleanup

Failed or incomplete deployments leave orphaned buffer accounts that hold SOL. Reclaim those funds:

# List buffer accounts owned by your authority
solana program show --buffers

# Close a specific buffer and recover the lamports
solana program close <BUFFER_ADDRESS>

Deployment checklist

Before deploying to Zink mainnet:

• [ ] All tests pass against solana-test-validator
• [ ] Program deployed and tested on Zink Testnet
• [ ] Account layout changes are backwards-compatible
• [ ] Upgrade authority strategy decided (single key, multisig, or immutable)
• [ ] Verifiable build produced and verified
• [ ] IDL regenerated and published if your clients depend on one
• [ ] Buffer accounts from prior deployments cleaned up
• [ ] Monitoring and alerting configured

Next steps

• Testing & Localnet — test strategies before deployment
• Programs — how the BPF Loader manages executable accounts
• Fees — deployment costs and compute pricing
• Clusters & Environments — Zink cluster endpoints