Appearance

Wallets & Keypairs ​

Zink uses the same Ed25519 keypair format and wallet connection model as Solana. If a wallet, signer, or key-management workflow works with Solana, it will work with Zink once you point it at the correct cluster endpoint.

Upstream-compatible

solana-keygen, filesystem JSON keypairs, hardware wallets, browser wallets, mobile wallets, and standard wallet-adapter flows all carry over to Zink unchanged.

Wallet compatibility ​

Most Solana-facing wallets can connect to Zink as long as they support custom RPC or custom network configuration.

Typical examples include:

  • Phantom
  • Solflare
  • Backpack
  • hardware-wallet flows surfaced through Solana tooling
  • server-side signers using raw keypair files or HSM-backed implementations

Zink-specific

Whether a specific wallet exposes Zink in its default network picker depends on that wallet. If it does not, use a custom RPC configuration or a dApp flow that injects the Zink endpoint explicitly.

Filesystem keypairs ​

For operators and backend services, the most common key format is the standard Solana JSON array keypair.

Create a new keypair:

bash
solana-keygen new --outfile ~/.config/solana/id.json

Display the public key:

bash
solana-keygen pubkey ~/.config/solana/id.json

Create a keypair without passphrase prompt:

bash
solana-keygen new --no-bip39-passphrase --outfile ~/.config/solana/id.json

If you want the CLI to use that key by default:

bash
solana config set --keypair ~/.config/solana/id.json

Verify:

bash
solana config get
solana address

Operator key separation ​

Node operators should not treat “the validator key” as a single thing. Separate roles matter.

Identity keypair ​

Used by the validator process to identify the node on the network.

  • passed to agave-validator --identity
  • hot key by necessity
  • should live only on the node that runs the validator

Vote account ​

The vote account is the on-chain account that receives vote credits and stake delegation.

  • created separately from the identity key
  • referenced by agave-validator --vote-account
  • inspected with solana vote-account <VOTE_ACCOUNT_PUBKEY>

Authorized withdrawer ​

The authorized withdrawer is the most sensitive validator-related key.

  • controls withdrawal authority over the vote account
  • should be treated as a cold or tightly controlled key
  • should not live on the validator host in normal operation

Zink recommendation

For any validator participating in Zink consensus, keep the identity key hot, but keep the withdrawer authority offline or under stronger custody controls. A compromised validator host should not automatically imply loss of withdraw authority.

Generate an identity keypair:

bash
solana-keygen new --outfile ~/zink-validator/identity.json

Generate a vote-account keypair:

bash
solana-keygen new --outfile ~/zink-validator/vote-account.json

Generate a withdrawer keypair:

bash
solana-keygen new --outfile ~/zink-validator/withdrawer.json

Display all public keys for recordkeeping:

bash
solana-keygen pubkey ~/zink-validator/identity.json
solana-keygen pubkey ~/zink-validator/vote-account.json
solana-keygen pubkey ~/zink-validator/withdrawer.json

Wallet usage for developers ​

For normal developer workflows, a single deployer wallet is usually enough.

Common uses:

  • paying deployment costs
  • funding test accounts
  • signing upgrade transactions
  • creating PDAs or token accounts through tooling

A simple flow is:

bash
solana-keygen new --outfile ~/.config/solana/zink-deployer.json
solana config set --keypair ~/.config/solana/zink-deployer.json
solana balance

Then switch the CLI to the appropriate cluster URL:

bash
solana config set --url https://testnet-rpc.z.ink

Browser wallets and custom networks ​

When using browser wallets with Zink:

  1. confirm the dApp is targeting the intended Zink RPC endpoint
  2. confirm the wallet understands the network selection being presented
  3. verify account balances and expected addresses before signing
  4. test on a non-production cluster first whenever possible

Sanity checks before signing ​

  • Is the wallet connected to the correct Zink cluster?
  • Is the destination account on Zink, not Solana mainnet?
  • Is the token native to Zink or bridged from Solana?
  • Does the action depend on the Zink Bridge state model?

Secret handling practices ​

Good practices ​

  • store filesystem keypairs with restrictive permissions
  • avoid copying operator keys between hosts unnecessarily
  • use separate wallets for dev, staging, and production
  • back up cold keys offline
  • rotate service keys if exposure is suspected

Things to avoid ​

  • checking keypairs into git
  • baking keypairs into Docker images
  • sharing one hot wallet across unrelated services
  • storing withdrawer authority on the validator machine without a good reason

Quick checks ​

bash
# Show current configured signer
solana address

# Confirm the signer has funds on the current cluster
solana balance

# Confirm your active CLI target
solana config get

Zink is a general-purpose SVM network for programs, operators, and bridge integrations.

Zink