White-Label Liquid Staking Token (LST) Setup on Solana

A liquid-staking token (LST) is the most useful piece of Solana DeFi for a brand to own. It is non-custodial, it is composable across the entire ecosystem, it captures both native staking APY and MEV uplift for holders, and — done right — it puts a brand's name on a token that lives in users' wallets and shows up in every Solana DeFi UI.

This is an operator's guide for launching a white-label LST on Solana backed by a dedicated managed validator. It assumes you have a brand, a captive user base (wallet, exchange, fund, DeFi protocol), and a plan for distributing the LST. The infrastructure side — the validator and the stake-pool integration — is what we will walk through here.

What a white-label LST actually is

A liquid-staking token is an SPL token whose price tracks the value of staked SOL. When a holder deposits SOL into the pool, they receive LST tokens at the current exchange rate. The pool delegates the SOL to one or more validators. As staking rewards accrue (native rewards plus MEV tips), the LST's exchange rate against SOL appreciates. When the holder wants out, they redeem LST for the corresponding SOL.

A white-label LST is one where:

• The token is branded as yours — your name, your icon, your mint authority.
• The underlying stake is concentrated on a validator you control (typically a dedicated white-label validator).
• The fee parameters and pool policy are yours to set.
• The DeFi distribution is yours to drive.

The validator operator (AllenHark, in this context) provides the infrastructure that backs the stake, the MEV path that drives uplift, and the operational reliability. You provide the brand, the captive user base, and the LST-level decisions.

The three integration paths

There are three ways to set up the on-chain side of a white-label LST. They differ in how much control you keep and how much DeFi distribution you get out of the box.

Path 1: Raw SPL stake pool

The canonical Solana primitive. Deploy the SPL stake-pool program with your parameters; set your validator as the (or a) delegate; mint your LST.

Pros

• Maximum control. You set every parameter — fees, rebalancing logic, delegate list, mint authority.
• Audited, well-understood primitive. The on-chain risk surface is minimal.
• No counterparty layer above the program.

Cons

• DeFi distribution is your job. You list on Kamino, MarginFi, Drift, Orca, Meteora, etc. one-by-one.
• No native instant-unstake. Standard SPL stake-pool redemption follows Solana's epoch-boundary deactivation timing.
• No shared LST liquidity routing. Holders that want to swap to SOL hit your liquidity, not a shared pool.

Best for: LST issuers with bespoke yield strategies or who have the engineering resources to drive their own DeFi listing campaign.

Path 2: Sanctum-backed pool

Sanctum is an aggregator layer that sits on top of SPL stake pools. You deploy a stake pool, register with Sanctum, and inherit a set of capabilities the raw primitive does not provide.

Pros

• Instant unstake. Holders can redeem LST to SOL immediately via Sanctum's shared liquidity reserve, instead of waiting an epoch.
• DeFi reach on day one. Sanctum's router lets your LST trade against any other Sanctum LST and any major DEX without manual listing work.
• Sanctum's marketing reach. Sanctum surfaces your LST in their interface and partnerships.

Cons

• Your pool operates within Sanctum's framework. Parameters you can change are a subset of what raw SPL allows.
• Sanctum-level fees apply on top of your validator commission.

Best for: New LSTs that want instant DeFi reach and a working instant-unstake UX without doing every listing one-by-one.

Path 3: Hybrid

Deploy raw SPL for control, optionally list with Sanctum later for distribution. This is the path operators take when they want maximum flexibility now and Sanctum-level reach as a phase-2 option.

The launch timeline

A realistic timeline for a white-label LST launch:

The validator side stays on the timeline reliably. The variable timing is the pool deployment and DeFi listing, which is more of a coordination problem than an engineering problem.

Economics and fees

Three components to LST economics:

1. Validator commission. Set by you, accrues to you. Industry-typical 5–10%. This is your direct revenue stream from the LST.
2. MEV-tip flow. The validator collects Jito tips, which flow into the stake pool as reward. The LST's exchange rate against SOL appreciates faster as a result. MEV tips accrue to LST holders, not to the operator — that is the value proposition of holding the LST instead of staking natively at a non-MEV validator.
3. Optional pool management fee. SPL stake pool supports a management fee charged at the pool level (separate from the validator commission). Sanctum has its own fee parameters. Both are operator-set.
4. Validator infra fee. Paid to AllenHark — flat monthly, see /pricing#relay-validator. Separate from LST-level economics; this is the cost of operating the validator that backs the pool.

Operational considerations

A few things that catch operators off-guard:

• Stake activation curve. SOL deposited into the pool does not start earning yield instantly. It activates at the next epoch boundary. New deposits during an epoch are in a "warming up" state and earn nothing until activation. Holders who do not understand this complain about flat returns in week one.
• Redemption queue (path 1). Raw SPL pools deactivate stake at the epoch boundary. Holders that redeem a large amount may have to wait an epoch for the SOL to unlock. Sanctum's shared liquidity reserve papers over this for path 2.
• Validator concentration risk. A single-validator-backed LST is exposed to that validator's uptime and behavior. Mitigations: hot-standby failover on the validator (which AllenHark provides by default), and optionally a multi-validator delegation policy in the pool.
• Slashing. Solana slashing is currently soft (validator marked, delegators leave). For an LST, a slashed backing validator is a brand-existential event. The validator operator's slashing-protection-aware operations posture is the thing that prevents this.
• MEV-tip claim cadence. Jito tips accrue per-epoch and are claimable by the validator's tip-distribution account at epoch boundaries. The pool consumes these as additional stake reward. Make sure your reporting reflects MEV-uplift APY separately from native APY — sophisticated holders will compare.

How AllenHark fits

AllenHark Managed Validator is the validator-side half of the LST stack. Specifically:

• Dedicated validator under your brand. Live on mainnet in under 48 hours.
• Jito client by default. MEV tips flow to the pool automatically; LST holders capture the uplift.
• Agave + Firedancer choice. Default Agave for production stability; Firedancer where the performance characteristics warrant.
• Hot-standby failover. Concentration risk mitigated on the validator side.
• 99.9% SLA. Credit-back on missed uptime.
• Pool-layer agnostic. We work with raw SPL stake pool, Sanctum, or hybrid. You pick.
• No control over your token. We operate the validator; you hold mint authority, pool parameters, and the LST's brand.

LST-specific page with FAQ and Sanctum-vs-SPL comparison: /managed-validator/lst.

Bottom line

Launching a white-label LST is largely about coordination: pool layer + validator + brand + DeFi distribution. The validator side is the most operationally heavy piece and the easiest to outsource. The brand and distribution are the parts only you can do.

Pick the pool layer based on whether you want maximum control (raw SPL) or maximum day-one DeFi reach (Sanctum). Pair it with a dedicated managed validator that runs Jito by default and has a real failover story. Ship.

If you want the validator half done right, start a conversation. We will spin up the validator while you coordinate the pool side.

Related reading:

• Best white-label Solana validator providers in 2026
• MEV-aware delegation on Solana validators
• How exchanges add white-label Solana staking without running nodes
• Zero-downtime migration: self-hosted to managed Solana validator