Drift Staked SOL

Rejected venues wait the longest for re-review; a rejection has to earn another look before the scheduled date.

dSOL is a Sanctum-powered liquid-staking receipt whose stake delegates exclusively to the Drift validator. The design creates a concentrated validator and Drift-ecosystem dependency versus the selected Solana provider’s broad delegation strategy. This is a comparative category decision, not an allegation that dSOL is defective or unsafe.

Kill criteria: the events that revoke this verdict
• The selected provider in this category fails a kill criterion (these are the bench)
• The provider demonstrates a material improvement on the axis it lost on (validator distribution, liquidity depth, or distinct capability)

The research file

Selection, not disqualification

This is a relative choice within an already-accepted exposure category, not an allegation that the non-selected provider carries a disqualifying defect: every provider in the comparator set inherits the same slashing, validator, contract, oracle and token-liquidity risks, and a clean record alone is insufficient to win the selection. The mandate avoids holding multiple near-substitute liquid-staking tokens for the same native asset merely to diversify brands. The alternate reopens if the selected provider breaches a kill criterion or loses its comparative advantage in validator distribution, governance, liquidity, fees, or operating record.

Mechanism

Sanctum describes dSOL as a liquid claim on SOL delegated exclusively to the Drift validator. Staking rewards accrue through the rising dSOL/SOL exchange rate; Drift uses its validator for transaction confirmation and stake-weighted quality-of-service participation.

Control and operating record

Validator operation and delegation are concentrated by design, while Sanctum supplies the LST infrastructure and liquidity routes. Public launch materials establish the mechanism, but this class application does not claim a complete independent incident or performance study of the validator.

Exit consequences

A holder can seek liquidity through Sanctum/Jupiter or redeem through the underlying staking path. Instant exit depends on reserve or secondary liquidity and price; native stake deactivation follows Solana epoch timing. In stress, dSOL can trade away from its exchange-rate value.

Why the class rule decides

The category rule selected Marinade for broader validator distribution among close substitutes. Exclusive delegation to one validator does not win that axis, so dSOL remains on the bench. Review reopens if the selected provider fails a criterion or dSOL materially broadens delegation, deepens liquidity or adds a distinct client-relevant capability.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• Sanctum — Introducing dSOL · secondary · accessed 2026-08-14
  Supports: Introducing dSOL
• Sanctum Learn — native versus liquid staking · secondary · accessed 2026-08-14
  Supports: native versus liquid staking
• Sanctum — instant-exit liquidity design · secondary · accessed 2026-08-14
  Supports: instant-exit liquidity design
• Marinade Docs — delegation strategy FAQ · primary · accessed 2026-08-14
  Supports: delegation strategy FAQ

Inherited controls

The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.