Solana Validator Security Controls: A Buyer's Guide

If you are buying a managed Solana validator service — for your exchange, wallet, fund, treasury, LST issuer, or protocol — the security posture of the provider is the part of the contract that matters most when things go wrong. Pricing is recoverable. SLA breaches are creditable. A botched key handover or a slashing event is not.

This is a working buyer's guide to evaluating a managed-validator provider's security controls. It is written for procurement teams, security leads, and engineering managers who own the diligence on this category and need a checklist that asks the right questions. We will not name specific certifications you should require — the right answer depends on your jurisdiction and risk appetite — but we will lay out the technical controls that should be table-stakes regardless of whether the provider holds a certificate.

The framework

Eight control areas. Each has a "what good looks like" benchmark and a question you should ask the vendor.

Key management
Slashing protection
Operator access and audit trail
Encryption at rest and in transit
Change management
Sanctions screening (where applicable)
Hardware isolation
Incident response

Walk a vendor through all eight. If they can answer crisply on each, you have a serious vendor. If they hedge or talk in marketing terms, you have a problem.

1. Key management

What good looks like: Identity and vote keys are generated and held in hardware-isolated environments. Access is tightly scoped — only the validator binary needs them, and access is logged. Keys are not in cloud blob storage, not in container layers, not on shared filesystems, not in source control, not in the operator's home directory. Rotation is operator-initiated and documented.

Question to ask: "Walk me through where the vote key lives, who has access to it, and what happens if it has to be rotated."

Red flags:

"It's encrypted in the cloud" without specifics on the threat model.
"We have access" without specifics on who and how that access is audited.
"We have not had to rotate one" — that is not an answer; that is an absence of process.

2. Slashing protection

What good looks like: Every validator host maintains a slashing-protection bookkeeping record (the highest slot the node has voted on). The hot-standby promotion path explicitly handles slashing-protection handoff — the new primary refuses to vote until the old primary has been confirmed retired and the bookkeeping record has been reconciled. Migration paths are designed so two nodes cannot vote on overlapping ranges.

Question to ask: "Walk me through a failover scenario. What prevents a double-vote?"

Red flags:

"We rely on the operator to coordinate" — slashing protection should be enforced by the system, not by a runbook.
"We have not seen a slashing event" — fine, but does the design make one impossible, or just unlikely?
Vague answers about "manual checks" during cutover.

3. Operator access and audit trail

What good looks like: Named individual SSH keys to bastion hosts. Per-operator audit log capturing every command run on every validator host with operator identity and timestamp. No shared accounts. No casual root access. Operators can subscribe to the audit feed for their own validator and ingest it into their SIEM.

Question to ask: "Can I see a sample of the audit log for a validator? What does it capture and how do I get access to my validator's feed?"

Red flags:

"We have audit logs" without specifics.
"We can share them on request" — that is not a feed; that is an awkward process.
No clarity on what gets logged (commands? login events? changes only?).

4. Encryption at rest and in transit

What good looks like: All operational data — ledger snapshots, monitoring telemetry, configuration, audit logs — is encrypted in transit (TLS 1.3) and at rest on managed hardware. Encryption-at-rest key material is rotated on a documented schedule. Cipher selection follows current best practice (no TLS 1.0, no deprecated cipher suites).

Question to ask: "What is your encryption-at-rest setup and key rotation cadence?"

Red flags:

Vague "everything is encrypted" answers without specifics.
No clear story on key rotation.
Customer data flowing over plaintext channels at any point.

5. Change management

What good looks like: Every config change, binary upgrade, identity rotation, and failover event is proposed, peer-reviewed, applied, and recorded. Operators can request the full change history for any operator-impacting event on their validator. No after-hours cowboy upgrades.

Question to ask: "Can I see the change-management trail for a recent Agave or Firedancer upgrade on one of your customer validators?"

Red flags:

"We move fast" — fine for product engineering, not fine for production validator changes.
No clear story on who reviews what.
Operators are not told about config changes that affect their validator.

6. Sanctions screening (where applicable)

What good looks like: OFAC SDN screening is available as an optional layer at the validator's transaction-processing path for operators that require sanctions-aware infrastructure. The screening list is sourced from the canonical OFAC publication and refreshed on each update. The screening is opt-in — not imposed on operators that do not need it.

Question to ask (if you are in a regulated jurisdiction): "Do you offer OFAC SDN screening at the validator layer? How is the screening list maintained?"

Red flags:

"We don't screen" — fine if you don't need it, problematic if your jurisdiction requires it.
"We always screen" — also potentially problematic if your business model is not aligned with this.
Vague answers about "compliance" without specifics.

7. Hardware isolation

What good looks like: Each managed validator runs on dedicated bare-metal hosts. No co-tenant workloads. Standby node runs on separate hardware in the same region. Validator hosts are not shared across operators (one customer's validator does not run on the same box as another's).

Question to ask: "Is my validator on dedicated hardware or shared with other customers?"

Red flags:

"Cloud-hosted" without details on whether it is bare-metal.
Shared hardware with other validator customers (this is a real risk profile).
No clear story on physical isolation between the primary and standby.

8. Incident response

What good looks like: Named 24/7 on-call rotation with paged response for SLA-impacting events. A documented triage → mitigation → post-mortem cycle. Operators receive a written incident report for any event that affects their validator's SLA, with a clear timeline and remediation actions.

Question to ask: "Show me a sample incident report from a recent SLA-impacting event."

Red flags:

"We have on-call" without specifics on who and how they are paged.
No post-mortems shared with customers.
"We have not had incidents" — see slashing-protection commentary above.

What about SOC 2, ISO 27001, and other certifications?

This is the part where buyers want a clean answer and there isn't one.

A SOC 2 Type II report and an ISO 27001 certificate are valuable artifacts — they evidence that a third party audited the provider against a documented framework and signed off. For some buyers (large financial institutions, regulated exchanges in certain jurisdictions, government-adjacent custodians), a certificate is a hard procurement gate.

For other buyers, the certificates are less informative than the technical controls underneath. A provider that has SOC 2 Type II but cannot give you a clear answer on slashing protection has been audited against a framework that did not test the validator-specific thing that matters most. Conversely, a smaller provider operating to SOC 2-consistent controls without holding the certificate may have a tighter posture on the validator-specific risks than a generalist with the badge.

The honest framework is:

If your procurement gate requires a certificate, ask for the certificate. Don't try to argue around it.
If your procurement gate is "is this safe to run my stake on," walk through the eight controls above and judge the answers. The certificate is one signal; the answers are another. Both matter.

Putting it together

When you finish your vendor evaluation, you should have crisp, specific answers to:

Where do the vote keys live and who has access?
What prevents a double-vote during failover or migration?
Who can run commands on the validator host and is it audited?
Is everything encrypted and how are keys rotated?
How is every change to the validator managed?
What is the sanctions-screening story (if applicable)?
Is the hardware dedicated and isolated?
What does an incident look like and what do I get from the post-mortem?

If you cannot get those answers in one diligence call, the vendor is not ready to run institutional stake.

How AllenHark answers these

We aim to be the kind of vendor that gives you crisp answers on every control above. The full security posture is documented at /managed-validator/security, including the OFAC screening option, the hardware-isolation story, and the change-management discipline. We do not currently hold SOC 2 Type II or ISO 27001 certifications, and we say so on the page — the intent is to describe technical controls, not claim regulatory attestations we do not hold.

For institutional buyers running formal procurement, we can share the security brief, a sample audit log, and the incident-report format under NDA. Request the security brief.

Related reading: