Appearance

Run an RPC Node ​

A Zink RPC node serves JSON-RPC and WebSocket traffic without participating in consensus. It is the right choice for applications, explorers, bots, analytics systems, and backend services that need reliable access to Zink state.

Why run your own RPC? ​

Running a dedicated RPC node gives you control over:

  • request latency
  • rate limits
  • account indexing
  • historical-data retention
  • network placement near your application stack
  • optional plugin/runtime features such as Geyser

Upstream-compatible

A Zink RPC node is still just agave-validator running with --no-voting. The same operational model used on Solana applies here.

When an RPC node is better than a validator ​

Prefer an RPC node if you:

  • need a private endpoint for a production application
  • want to avoid shared RPC throttling
  • need account indexes or full transaction history
  • are not participating in Zink consensus

If you only need local development, use solana-test-validator instead of a full RPC node.

Baseline RPC shape ​

The most important RPC-specific flags are:

  • --no-voting
  • --full-rpc-api
  • --private-rpc when you do not want the port discoverable through gossip
  • --rpc-port
  • --rpc-bind-address
  • --ledger
  • --accounts
  • --account-index

Example baseline launch:

bash
agave-validator   --no-voting   --full-rpc-api   --private-rpc   --rpc-bind-address 0.0.0.0   --rpc-port 8899   --ledger /mnt/ledger   --accounts /mnt/accounts   --entrypoint <ZINK_ENTRYPOINT_1>   --entrypoint <ZINK_ENTRYPOINT_2>   --known-validator <KNOWN_VALIDATOR_PUBKEY_1>   --known-validator <KNOWN_VALIDATOR_PUBKEY_2>   --only-known-rpc   --expected-genesis-hash <ZINK_GENESIS_HASH>   --dynamic-port-range 8000-10000

Public vs private RPC ​

  • Use --private-rpc when the node is only for your own systems or sits behind a load balancer/proxy.
  • Omit --private-rpc only if you explicitly want the node advertised as an RPC service.

Zink recommendation

For production application backends, prefer private RPC behind your own edge or service mesh. Public exposure should be a conscious product decision, not the default.

Account indexing and data strategy ​

RPC nodes often carry heavier storage requirements than validators because operators enable indexes and history.

Common options include:

  • account indexing for token-owner or program-owner lookups
  • longer ledger retention windows
  • WebSocket subscriptions for live application updates
  • plugin-based export via Geyser

Example account-index shape:

bash
agave-validator   --no-voting   --full-rpc-api   --account-index program-id   --account-index spl-token-owner   --account-index spl-token-mint   ...

Only enable the indexes you actually need; every extra index costs RAM, CPU, and disk.

Startup verification ​

After boot, confirm the node is alive and caught up enough to serve requests.

bash
# Local node health
curl -s http://127.0.0.1:8899/health

# Current slot from your node
solana --url http://127.0.0.1:8899 slot

# Compare with cluster view
solana slot

# Confirm RPC API answers normally
solana --url http://127.0.0.1:8899 block-height

If the node is far behind cluster head, it is not ready to serve production traffic.

Systemd example ​

ini
[Unit]
Description=Zink RPC Node
After=network-online.target
Wants=network-online.target

[Service]
User=sage
LimitNOFILE=1000000
Restart=always
RestartSec=3
ExecStart=/home/sage/.local/share/solana/install/active_release/bin/agave-validator   --no-voting   --full-rpc-api   --private-rpc   --rpc-bind-address 0.0.0.0   --rpc-port 8899   --ledger /mnt/ledger   --accounts /mnt/accounts   --entrypoint <ZINK_ENTRYPOINT_1>   --known-validator <KNOWN_VALIDATOR_PUBKEY_1>   --only-known-rpc   --expected-genesis-hash <ZINK_GENESIS_HASH>

[Install]
WantedBy=multi-user.target

Common tuning decisions ​

Ledger retention ​

If you care about storage pressure more than long-range history, consider limiting retained ledger data.

bash
agave-validator --limit-ledger-size ...

RPC isolation ​

If application workloads are heavy, place RPC nodes close to application compute and keep them separate from operator-validator hosts.

Snapshot handling ​

Large snapshot downloads will consume disk bandwidth and network bandwidth. Plan for this when restarting or rebuilding nodes.

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

Zink