All articles
solanavestingtoken-unlockstreamflowtokenomicsoraclebuildersdistribution

Price-based unlock: performance-tied vesting on Solana

Price-based unlock ties token release to an oracle mark instead of only the calendar. How it works on Solana, key parameters, Streamflow’s aligned streams, risks, and when to use it vs cliffs and linear vesting.

devrels.xyz/a/224short link

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
DimensionTime-basedPrice-based
DriverWall clock (cliff + linear / tranches)Oracle price vs target (+ time caps)
If price dumpsUnlocks continue on scheduleUnlock rate typically slows
If price ripsSame scheduleUnlock rate can accelerate toward full unlock
Recipient certaintyHigh calendar predictabilityLower calendar certainty; path depends on market
Sell-pressure shapeCliffs and linear unlock days are known in advanceLess “everyone unlocks on the same bad day” by design
Extra dependencyClock / slot timeOracle 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
ParameterRoleDesign note
Target priceThreshold the unlock logic cares aboutSet from liquid venues; vanity targets create games
Duration at targetTime to full unlock when conditions holdBest-case path for high-performing tokens
Max durationLongest path if price never cooperatesProtects recipients from infinite lock
Oracle / feedSource of mark priceThin books and manipulated marks break fairness
Withdraw rulesWho can claim unlocked amount whenStill 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 locksPrice-based response
Large unlocks while the market is weakSlow the unlock path when price is below target
Calendar cliffs as coordinated sell eventsLess mechanical “everyone unlocks Tuesday”
Team/investor upside decoupled from holdersFaster unlock only when the mark improves
Community feels schedule is unfair after dumpsNarrative: unlocks track success metrics

Risks and failure modes

Failure modes to design against
RiskWhat breaksMitigation
Oracle manipulationFake mark → wrong unlock rateLiquid feeds, TWAP where available, sane bounds
Illiquid markTarget never “real” on thin pairsQuote against deep USDC pairs; avoid vanity mints
Recipient cash-flow needsTeam cannot plan payroll from calendarKeep salary stablecoins separate; vest equity-like tokens
Complex commsInvestors misunderstand max durationPublish both best-case and max schedules in plain English
Program / config errorWrong 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
SituationPrefer
Team/investor unlocks should track product successPrice-based (or hybrid)
Legal or payroll needs fixed datesTime-based cliff + linear
Token has deep oracle coverage and liquid marketsPrice-based viable
Brand-new thin float, easy to wickTime-based until markets mature
Community wants transparent “aligned” unlocksPrice-based with public params
You cannot explain max duration in one slideSimplify to time lock first

Builder checklist

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

Keep reading

Get new articles in your inbox

Technical deep-dives on Solana tooling, infrastructure, and ecosystem. No noise.