Price-based unlock: performance-tied vesting on Solana

Price-based unlock: token release that speeds up or slows down with market performance—usually an oracle mark versus a target—not only a fixed calendar.

Classic vesting answers “how much unlocks on this date?” Price-based vesting answers “how much unlocks given where price is?” On Solana, products such as Streamflow expose this as price-based or “aligned” streams next to cliffs and linear schedules. This article is the builder map: mechanics, parameters, comparison to time locks, risks, and when it is the wrong tool.

Time lock vs price-based unlock

Both lock tokens in a program-owned account and let a recipient withdraw only what has unlocked. The difference is the clock.

Time-based versus price-based release models
Dimension	Time-based	Price-based
Driver	Wall clock (cliff + linear / tranches)	Oracle price vs target (+ time caps)
If price dumps	Unlocks continue on schedule	Unlock rate typically slows
If price rips	Same schedule	Unlock rate can accelerate toward full unlock
Recipient certainty	High calendar predictability	Lower calendar certainty; path depends on market
Sell-pressure shape	Cliffs and linear unlock days are known in advance	Less “everyone unlocks on the same bad day” by design
Extra dependency	Clock / slot time	Oracle integrity + liquidity at the mark

How it works (concept)

A stream locks a mint amount for a beneficiary. Each withdraw (or crank) evaluates how much is unlocked. For price-based streams, the program reads a price feed and applies rules such as:

At or above target — unlock progresses on a faster path (for example “duration at target price”).
Below target — unlock progresses more slowly, but a max duration still guarantees eventual release so tokens are not stuck forever.

Streamflow’s docs describe this as a dynamic schedule aligned with market performance: better price → faster unlock; weak price → fall back toward a time-bounded path. Exact formulas live in the product docs and on-chain program—always verify against current Streamflow documentation before you ship.

Key parameters

Parameters you must design deliberately
Parameter	Role	Design note
Target price	Threshold the unlock logic cares about	Set from liquid venues; vanity targets create games
Duration at target	Time to full unlock when conditions hold	Best-case path for high-performing tokens
Max duration	Longest path if price never cooperates	Protects recipients from infinite lock
Oracle / feed	Source of mark price	Thin books and manipulated marks break fairness
Withdraw rules	Who can claim unlocked amount when	Still need crank/claim UX; unlocked ≠ auto-sent unless designed

On Solana: Streamflow and friends

Streamflow is the common production surface for vesting, locks, airdrops, and related distribution on Solana. Price-based vesting is documented in their help center as an oracle-driven alternative to pure time schedules. Their broader program surface (linear/cliff vesting, locks, aligned streams) is covered in Streamflow programs: token ops on Solana. NFT-oriented locks are a separate path (Streamflow NFT lock).

Integrations such as private vesting (for example Umbra + Streamflow) keep price-based and time-based condition types while changing privacy of transfer. Treat privacy as an orthogonal axis: lock logic first, privacy second.

Why teams reach for it

Problems time locks leave open; what price-based tries to fix
Pain with pure time locks	Price-based response
Large unlocks while the market is weak	Slow the unlock path when price is below target
Calendar cliffs as coordinated sell events	Less mechanical “everyone unlocks Tuesday”
Team/investor upside decoupled from holders	Faster unlock only when the mark improves
Community feels schedule is unfair after dumps	Narrative: unlocks track success metrics

Risks and failure modes

Failure modes to design against
Risk	What breaks	Mitigation
Oracle manipulation	Fake mark → wrong unlock rate	Liquid feeds, TWAP where available, sane bounds
Illiquid mark	Target never “real” on thin pairs	Quote against deep USDC pairs; avoid vanity mints
Recipient cash-flow needs	Team cannot plan payroll from calendar	Keep salary stablecoins separate; vest equity-like tokens
Complex comms	Investors misunderstand max duration	Publish both best-case and max schedules in plain English
Program / config error	Wrong feed or units (e.g. decimals)	Test on devnet with known price mocks; dual-review params

When to use it — and when not to

Chooser for distribution design
Situation	Prefer
Team/investor unlocks should track product success	Price-based (or hybrid)
Legal or payroll needs fixed dates	Time-based cliff + linear
Token has deep oracle coverage and liquid markets	Price-based viable
Brand-new thin float, easy to wick	Time-based until markets mature
Community wants transparent “aligned” unlocks	Price-based with public params
You cannot explain max duration in one slide	Simplify to time lock first

Builder checklist

Before you create production streams
#	Check
1	Write best-case and worst-case unlock curves in USD and token units.
2	Name the oracle mint/pair and verify decimals match the program config.
3	Set max duration so “never hits target” still finishes in a bounded time.
4	Separate living costs (stablecoins) from equity-like token vesting.
5	Test claim path on devnet with mocked price high and low.
6	Publish parameters for the community before TGE narratives harden.

Resources

Tokenomics and unlock design are legal and market-sensitive. Verify current program behavior and docs before production. Not financial or legal advice.