NS-3 devnet redeployment — in preparation

The settlement layer for derelict liquidity.

Anyone can settle an abandoned Solana liquidity pool under fixed rules. Six on-chain checks decide eligibility, one atomic transaction does the work, and the split is set by formula.

$1.10BEstimated stranded on Solana, base case
6Criteria that must all pass
40/40/20LP holders, salvor, protocol
0Tokens, NFTs or points
Open source, Apache-2.0NS-3 devnet redeployment in preparation20% protocol ceiling fixed in bytecodeLP claims never expire
The problem

The liquidity stays. The market leaves.

When a memecoin dies, its pool keeps the valuable side: SOL, USDC or USDT. Holders rarely recover it. The frontend is gone and the position looks too small to chase.

Illustrative chart: a token’s pool value spikes at launch, collapses, then settles into a long flat plateau of stranded liquidity. Research estimate: $2.17 billion stranded across chains in the base case, of which $1.10 billion on Solana across about 155,000 pools.

Estimates of stranded candidate-pool liquidity from Ghost Pools, WP-2026-001r4, under a base-case valuation. They are not the value recoverable at displayed prices, and not protocol revenue. Lack of recent trading is a screening signal, not proof that a pool is abandoned. Read the methodology ↗

How it works

Certify. Salvage. Settle.

Evaluation and execution are separate programs, so no single path can both declare a pool derelict and move its funds.

Diagram of the GraveYield settlement lifecycle: a derelict pool is certified by GraveScanner against six criteria, then settled by GraveVault in one atomic transaction. Proceeds split 40% to LP holders in an unsweepable vault, 40% to the salvor, and at most 20% to the protocol.
01

Certify

GraveScanner checks six criteria, records an anchor, and issues a certificate only after two consecutive epochs. It never moves liquidity.

02

Salvage

GraveVault withdraws from Raydium V4 and swaps through Jupiter in one atomic transaction. If any check fails, everything reverts.

03

Settle

Proceeds are split by formula. LP holders claim with a Merkle proof from an unsweepable vault, with no expiry.

C190+ days inactiveC299% price collapseC30.5+ SOL residualC4LP not burnedC5LP not lockedC6Two epochs confirmed

C1 and C2 rest on signed oracle attestations verified in-transaction. The other criteria are read directly from on-chain state.

Settlement

One formula. No discretion.

Every salvage divides its recovered SOL the same way.

40%

LP holders

Snapshot-verified claims, held in a vault that no admin key can sweep.

40%

Salvor

Paid on delivery of the salvage, in the same transaction.

≤20%

Protocol

A ceiling, not a target, enforced in program bytecode.

Security

What governance cannot change.

Four invariants are enforced in program bytecode. Changing one needs a program upgrade. The public-notice, timelock and multisig process is the committed governance posture for such changes — it is process policy, not functionality the current programs enforce.

Bytecode

The 20% share is a ceiling

A config update that tries to raise it is rejected with error 7005.

Bytecode

The LP vault is unsweepable

No sweep instruction exists in v1.0, for any admin key.

Bytecode

Claims survive an emergency pause

Holders can always claim from a completed salvage.

Bytecode

One settlement per pool, ever

A second attempt fails at account initialization.

Process commitments — governance policy, not program-enforced functionality: the current devnet programs implement neither a timelock nor a functional authority-transfer mechanism (config changes are signed directly by the dedicated governance authority). For mainnet the plan is: no token at any layer, 72-hour timelocks on parameter changes, 7-day notice for standard upgrades, and Squads multisig custody (3-of-5 at launch). Read all ten invariants ↗

Status

Where the build stands.

The NS-3 devnet redeployment is in preparation: program identities are assigned and the NS-3 preparation is complete on review branches across all five repositories (open pull requests, not yet merged) — the default branches synchronize when those PRs merge, and deployment and on-chain acceptance remain pending. The earlier devnet generations (NS-1, NS-2) remain on devnet as preserved, untouched historical records. Nothing here is on mainnet, and no salvage has run yet.

In preparation
  • NS-3 program identities assigned (owner-held custody)
  • NS-3 preparation complete on review branches across all five repositories (PRs open — merge pending)
  • Deployment and acceptance checks pending owner execution
Verifiable today
  • Read-only evaluation across all six criteria
  • Settlement economics tested against mainnet Raydium bytecode
  • Deploy transactions reproducible from the repo
Not yet live
  • First salvage operation
  • Indexer, snapshot service, SDK release
  • Multisig custody and independent audit

Read the deployment record ↗