Drift Staked SOL

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.

Review triggers: events that reopen the verdict
• The selected provider in this category fails a review trigger (these are the bench)
• The provider demonstrates a material improvement on the axis it lost on (validator distribution, liquidity depth, or distinct capability)

Watched nightly: a warning on its venues or files, or a cited document that changes, reopens the memo. The first confirmation is due 2026-11-15.

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 review trigger 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.

Research, shelf, and client selection

This record found no disqualifying defect, but favorable research does not create firm-shelf eligibility or a client recommendation. Firm policy must separately admit the product; client purpose and constraints then determine the candidate set; and the advisor records any selection and amount.

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 research above describes the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The layer with the most administrative power sets the position’s effective control; that describes control, not quality or suitability.