Infrastructure

How Exchanges Add White-Label Solana Staking Without Running Nodes

May 15, 2026AllenHark Team

Adding native SOL staking is one of the highest-converting product additions a Solana-listing exchange can ship. Users want yield on idle SOL, competitors are already shipping it, and the commission flow is real revenue that scales linearly with deposits. The hard part is not demand — the hard part is figuring out the operational shape of the offering.

This is a working playbook for adding white-label Solana staking to an exchange without running validator nodes. It assumes you already have Solana spot listings, a working custody architecture (MPC, HSM, or qualified-custodian-backed), and an engineering team that ships product. The goal: get from "we should do staking" to "users can stake from inside the app" in under a quarter.

Why exchanges run staking under their own brand

A small handful of exchanges historically just sent user SOL to a third-party staking provider and rebadged the experience. That model is bad for everyone:

  • The user has no idea who is actually validating, what the SLA is, or whose risk surface they are exposed to.
  • The exchange loses brand control of a yield product that should be a top-of-funnel feature.
  • The provider owns the relationship and the data.

White-label flips this. The exchange runs a validator under its own name on-chain — same brand, same dashboard, same commission — but does not run the actual infrastructure. The provider's job is to be invisible.

Mechanically, "white-label" means:

  1. The validator's vote and identity keys are generated for and held by the exchange (operationally, in hardware-isolated storage on managed infra).
  2. The validator's on-chain identity is the exchange's brand. Solana explorers show the exchange's name.
  3. The commission rate is set by the exchange and accrues to the exchange's treasury.
  4. The exchange can migrate the validator off the provider at any time without losing delegators or on-chain history.

Everything else — hardware, client upgrades, Jito MEV plumbing, hot-standby failover, monitoring, on-call — sits with the provider.

The integration architecture

Three surfaces. All of which a working exchange custody platform can integrate without rewriting itself.

1. On-chain delegation

When a user stakes, the user's custody platform constructs a Solana SPL stake-program delegation instruction targeting the exchange's white-label vote account. Standard primitives — no custom contract, no proprietary primitives, no third-party RPC dependency.

User clicks "Stake X SOL"
    ↓
Custody platform:
    - creates stake account owned by user
    - signs DelegateStake(stake_account → exchange_vote_account)
    - submits to RPC
    ↓
On-chain stake program processes delegation
    ↓
Activation begins at next epoch boundary

The validator never sees the user's funds. It only sees that "stake account X is now delegated to my vote account."

2. Reporting API

Read-only JSON-over-HTTPS API from the provider exposing the data the exchange's back office needs:

  • Vote credits per epoch, per validator
  • Stake activation curve (warming up, active, deactivating)
  • MEV tips collected and distributed
  • SLA metrics: uptime, missed votes, leader-slot performance
  • Per-delegator reports (for reconciliation with the exchange's user-facing yield display)

The exchange consumes this in the same place it consumes price feeds, deposit/withdrawal feeds, and asset metadata. Standard back-office plumbing.

3. Brandable dashboard

Optional. A user-facing performance dashboard hosted on the exchange's domain, showing the validator's stats with the exchange's branding. Useful for transparency-conscious users; not strictly required.

Custody stays with you

This is the part where most legal and compliance teams want a clear answer. Solana staking is non-custodial by protocol design. The delegator owns the stake account; the validator never touches user funds. The on-chain stake program is the custodian — the validator is just the entity that receives delegation and produces blocks.

Practically, that means:

  • The exchange's existing custody architecture (MPC, HSM, qualified custodian) is unchanged. Staking is just another transaction type to sign.
  • AllenHark (or whichever provider) is never in the signing path for user funds. Vote keys exist on the validator host; user funds do not.
  • Unstaking is initiated by the exchange's custody platform on behalf of the user. The validator cannot block or front-run user withdrawals.

This is a deliberately boring architecture, and that is the point. Boring means well-understood; well-understood means it survives a compliance review.

OFAC and sanctions screening

For exchanges in regulated jurisdictions, sanctions screening at the validator layer is a real requirement. Two layers of screening matter:

  1. At deposit/withdrawal time (the exchange's responsibility): screen the user's address against the OFAC SDN list before allowing on-platform activity.
  2. At transaction-processing time (optional, applied by the validator): the validator can refuse to include transactions from sanctioned addresses in produced blocks.

The second layer is a policy choice. Not every operator wants their validator to be sanctions-aware; for those that do (typically US-regulated exchanges and custodians), AllenHark applies OFAC SDN address screening at the validator's transaction-processing layer. Detail at /managed-validator/security.

Commission and revenue economics

Three components to the unit economics:

  1. Validator commission. Set by the exchange — industry-typical 5–10%. Accrues directly from the on-chain stake-program payout every epoch. No middleman, no settlement.
  2. Jito MEV tips. Collected by the validator (Jito client runs by default), distributed to delegators on top of native rewards. This is real APY uplift and a differentiator from exchanges using non-MEV validators.
  3. Infra fee. Paid to the provider — flat monthly on AllenHark, scaling with delegation acquired if you opt into revenue-share.

Worked example: an exchange with 500,000 SOL staked at a 7% commission and ~7% native APY plus ~1% MEV uplift sees commission revenue of 500,000 × 0.07 × 0.08 = 2,800 SOL/year, against a flat infra fee in the low five figures USD per month. Break-even is well under 100,000 SOL.

Shipping inside a quarter

A realistic timeline for an exchange shipping native SOL staking:

WeekMilestone
1Vendor selection, SLA review, contract
2Validator provisioned and live on mainnet (provider runs this)
3On-chain delegation integration (custody platform wires up DelegateStake)
4Reporting API consumed into back office
5User-facing UI (deposit-to-stake, stake-to-yield-display)
6Compliance review, internal QA, soft launch to a user cohort
7Marketing and full rollout

The validator side (weeks 1–2) is mostly the provider's job. The integration side (weeks 3–7) is the exchange's job. AllenHark provides reference code and integration support for the common patterns; the heavy lift is the exchange's custody-platform changes.

What to ask before signing

Five questions that separate serious vendors from marketing:

  1. Can I see the SLA contract before signing? Look for a credit-back clause. "We target 99.9%" without a remedy is not an SLA.
  2. Who holds the identity and vote keys? Answer should be: the exchange does, recovery process is documented, validator binary has scoped access.
  3. What is the failover RTO and how is it slashing-aware? Look for: hot standby on separate hardware, slashing-protection-aware promotion, sub-slot cutover.
  4. What is the migration path off your service? A vendor that has a clean migration story is a vendor confident you will not want to leave.
  5. What does sample reporting look like? Ask for a real per-epoch report. If the vendor can't produce one, the reporting layer doesn't exist yet.

Where AllenHark fits

AllenHark Managed Validator is built for this exact shape of buyer — Solana-listing exchange, working custody platform, wants to ship native staking under its own brand without becoming a validator-ops shop.

  • Validator live in under 48 hours. Bare-metal AMD EPYC, Agave + Firedancer, Jito MEV, hot-standby failover, 99.9% SLA.
  • Flat-fee pricing from $2,000/month. Public — see /pricing#relay-validator. No surprise tiering.
  • OFAC SDN screening optional. For regulated exchanges.
  • Reference integration code. For the common custody-platform patterns.
  • You hold the keys. Migrate to another provider any time; no vendor lock-in.

Exchange-specific page with FAQ and full integration detail: /managed-validator/for-exchanges.

Ready to evaluate? Start a conversation — we'll hand you the SLA, sample reports, and a flat-fee quote inside one business day.


Related reading: