General
Burning vs. Locking Liquidity on Solana: Which Builds More Trust for Your Token Launch?
A 2026 arXiv study, "From Hype to Collapse: Investigating Rug Pull Scams on Solana," analyzed 100,063 tokens newly issued on Orca, Raydium, and Meteora during the first half of 2025 and identified 76,469 of them as rug pulls, with 15,606 classified specifically as liquidity withdrawal attacks.
That single figure explains why every Solana launch now faces the same question within its first ten minutes: is the liquidity burned or locked?
Streamflow sits directly on that question as the Solana-native token operations infrastructure platform behind 40,000+ projects and $294M+ in total value locked, where token locks function as verifiable on-chain proof rather than a promise in a Telegram channel.
Burning and locking are treated as interchangeable trust signals across most of the ecosystem. They are not. Burning destroys LP tokens permanently, while locking restricts them under published conditions that anyone can audit and re-check over time.
The harder truth is that neither action, on its own, tells a buyer anything about the other 80% of your supply.
This article breaks down when burning is the right call, when locking wins, and how to build the rest of the trust stack around whichever you choose.
Key Takeaways
Burning liquidity is permanent, while locking liquidity on Solana preserves flexibility for migrations and future pool changes.
Burning vs locking liquidity matters far less than what happens to team and treasury allocations.
Streamflow locks both SPL and LP tokens with public proof links and explorer verification.
Over 40,000 projects use Streamflow for token locks, vesting, and transparent on-chain distribution.
Trust compounds when every lock, cliff, and unlock is visible in one dashboard.
Burning Liquidity Has Become a Ritual, Not a Signal
Burning LP tokens is the loudest thing a launch can do and one of the least informative. It takes a single transaction, costs almost nothing on Solana, and produces a screenshot that circulates for the next hour. Every scanner picks it up, every group chat repeats it, and the launch moves on.
The problem is what a burn does not prove. A burned pool tells a buyer exactly one thing: that specific LP position cannot be withdrawn. It says nothing about the rest of the token.
Specifically, an LP burn does not prove:
That the team wallet holds a reasonable share of supply
That mint and freeze authority have been revoked
That insider allocations are subject to any release schedule
That treasury tokens cannot hit the market next week
That the team behind the launch will still be there in 90 days
Consider a launch where liquidity is burned at minute zero and the deployer still controls 35% of supply in an unrestricted wallet. The pool is safe. The holder is not.
The exit simply moved from the liquidity pool to the supply itself, which is precisely the pump-and-dump pattern that made up the largest rug-pull category in the 2026 Solana study.
Burning solves one attack surface completely and leaves the others untouched.
What Is Actually Being Compared: Two Different Risk Surfaces
The burn versus lock debate conflates two distinct assets. LP tokens represent a claim on the pooled liquidity sitting on a DEX. Project tokens represent supply held by the team, treasury, investors, and contributors.
A liquidity lock is a lock applied to LP tokens to prevent rug pulls on DEX liquidity. A token lock restricts native project tokens from being transferred, sold, or accessed until predefined conditions such as a date, time period, or price level are met. Most launches obsess over the first and ignore the second.
Here is the honest comparison on the LP question alone:
Dimension | Burning LP | Locking LP |
|---|---|---|
Reversibility | Permanent, irreversible | Reversible at unlock only |
Signal at launch | Maximum, instantly legible | Strong, requires reading terms |
Pool migration | Impossible | Possible after unlock |
Fee capture | Forfeited permanently | Retained by position holder |
Ongoing proof | One historical transaction | Live, re-checkable contract state |
Best fit | Fixed-supply memecoins, one-shot launches | Projects with a roadmap past 12 months |
Burning is the stronger absolute guarantee. Locking is the stronger operational choice for any project that expects to still exist, migrate pools, or restructure liquidity in a year. Neither is a substitute for restricting the supply that never entered the pool.
The Trust Stack for a Solana Token Launch
Trust at launch is not a single action. It is a sequence of verifiable commitments, and the LP decision is only the first of four.
1. Decide the LP question based on token lifespan
The decision rule is simpler than the discourse suggests. If the token is a fixed-supply community asset with no roadmap, no treasury operations, and no expectation of migrating venues, burn the LP and remove the question permanently. If the project has a product, a treasury, and a multi-year plan, a published lock is the more honest instrument.
Ask three questions before choosing:
Will this project need to migrate or restructure liquidity within 24 months?
Does the treasury depend on LP fee capture for runway?
Would a public unlock date create more scrutiny than the team can withstand?
A GameFi project planning a v2 pool after its economy stabilizes should lock, not burn. Burning in that scenario forces a second liquidity event later, funded from treasury, and the community reads that as a change in commitment rather than a planned migration.
2. Lock what the burn does not cover
Team allocations, treasury reserves, and investor tranches represent the actual sell pressure risk in almost every launch. Locking them is what turns a burn screenshot into a coherent supply story.
This is where transparent token locks on Solana do the work that an LP burn cannot.
Streamflow supports both time-based and price-based unlock conditions across SPL and LP tokens. Locked tokens cannot be transferred, traded, or accessed before the unlock criteria are met. Every lock produces a public proof link and is verifiable on Solscan, Solana Explorer, and RugCheck.
Fixed-date unlocks for team and treasury tranches
Price-based token locks that release only above defined thresholds
Quick locks for immediate, no-code commitment at launch
LP token support alongside standard SPL locks
A launch that burns liquidity and locks 100% of team supply for 12 months is telling a complete story. A launch that only burns is telling a quarter of one. If you want to test the flow, open the Streamflow app and set up a lock; the no-code path takes roughly 37 seconds.
3. Vest what you cannot lock
Some allocations need to move. Contributors get paid, ecosystem incentives get deployed, and advisors receive their share. A hard lock is the wrong instrument for anything that requires gradual, predictable release.
That is what automated token vesting handles. Vesting is the controlled release of tokens over time to prevent immediate selling and align long-term incentives, enforced by smart contracts rather than a spreadsheet and a calendar reminder.
Linear, cliff, cliff plus linear, graded, milestone-based, and price-based schedules
A 12-month cliff as the standard baseline for founders and core team
Bulk CSV import for contributor and investor cohorts
Immutable once deployed, with no admin override
The distinction matters to sophisticated buyers. Locks say "this cannot move." Vesting says "this moves on a schedule you can read today."
4. Publish one verifiable source of truth
Scattered proof is weak proof. A burn transaction on one explorer, a lock link in a pinned message, and a vesting schedule in a PDF do not add up to a credible supply picture.
A tokenomics dashboard consolidates vesting contracts, token locks, and staking pools into a real-time view with release progress, cliff dates, and unlock events in one place. Public-by-default visibility means the answer to "when do team tokens unlock" is a link rather than a conversation.
The projects that survive their first year are the ones where a skeptical buyer can verify the entire supply structure in under two minutes.
How Streamflow Fits Into This
Streamflow is the infrastructure layer that executes token economies on-chain, which means the trust signals above stop being promises and become enforced contract states. Locks, vesting schedules, and unlock conditions are deployed as audited smart contracts that cannot be unilaterally altered after deployment.
The security layer matters here because the whole point is verifiability. Streamflow's contracts are audited by FYEO and OPCODES, immutable once deployed, and carry no admin override.
Streamflow is also listed in the official Solana Docs under token vesting, which gives teams a reference point beyond marketing claims.
On cost, Solana's near-zero fees and sub-second finality make locking economically trivial compared to equivalent setups on Ethereum. Locking multiple tranches across founders, treasury, and investors is a rounding error in transaction cost, which removes the last practical excuse for leaving supply unrestricted.
Case Study: How Bonk Built Trust Beyond the Pool
Bonk, the Solana meme coin, allocated 55% of its supply to airdrops for early Solana users. The launch could have stopped at liquidity signaling, which is what most meme launches do. It did not.
Bonk used Streamflow for core team vesting, placing 20% of total supply across 22 early contributors on a 3-year linear vesting schedule. That decision moved the trust conversation away from the pool and onto the supply, where the real risk sat.
The outcome was a verifiable commitment structure the community could check on-chain at any point over three years, rather than a single launch-day transaction.
For a meme coin operating in the most trust-scarce corner of the market, that structure is the difference between a two-week lifecycle and a durable community.
What This Means for Web3 Founders and Token Issuers
The question in the title has an answer, and it is not the one most launch checklists give. Burning liquidity builds more trust in the first hour. Locking, applied across LP and supply together, builds more trust across the first year.
Practically, that translates into a short pre-launch sequence:
Burn LP only if the token has no roadmap requiring liquidity flexibility
Lock team and treasury allocations before the pool goes live, not after questions start
Vest contributor and investor tranches on schedules published in advance
Point every proof link at one public dashboard
Founders building past the launch window should also look at Streamflow Business, which extends the same infrastructure into treasury management, payouts, on-chain cap tables, and ownership issuance.
The full guide to token locking on Solana covers the mechanics in more depth.
The launches that hold up are the ones where the trust signal is a system, not a screenshot.
Conclusion
With 76,469 of 100,063 new Solana tokens flagged as rug pulls in a single half-year, buyers have stopped taking launch-day gestures at face value, and a burned pool no longer answers the questions that matter.
Burning wins on absolute finality, locking wins on flexibility and ongoing verifiability, and both are incomplete without locked team supply and published vesting schedules behind them.
Streamflow enforces all three through audited, immutable smart contracts across more than 40,000 projects and $294M+ in total value locked.
Book a demo to see how Streamflow handles LP locks, team allocations, and vesting schedules for a Solana token launch.
Read Next:
Do Token Locks Prevent Rug Pulls? What Locked Liquidity Actually Protects Against
How to Distribute SPL Tokens on Solana: Airdrops, Vesting, and Bulk Distribution Tools
How to Verify a Token Lock On-Chain: Step-by-Step Checklist for Solscan and Etherscan
FAQs:
1. Is burning liquidity better than locking liquidity on Solana?
Burning liquidity is better than locking liquidity on Solana when the token has a fixed supply, no roadmap, and no need to ever migrate or restructure its pool. Locking is better for projects that expect to operate past 12 months, since a lock preserves the ability to migrate liquidity while still publishing verifiable unlock conditions. Neither option addresses team or treasury supply, which is where most launch risk actually sits.
2. Can Streamflow lock LP tokens as well as project tokens?
Yes, Streamflow can lock LP tokens as well as standard SPL project tokens. Both lock types support fixed-date and price-based unlock conditions, produce public proof links, and are verifiable on Solscan, Solana Explorer, and RugCheck. Locked tokens cannot be transferred, traded, or accessed until the unlock criteria are met.
3. How long should a liquidity lock be for a Solana token launch?
A liquidity lock for a Solana token launch should extend at least as far as the project's first credible delivery milestone, which in practice means 6 to 12 months for most launches. Anything shorter reads as a formality rather than a commitment. Streamflow also supports price-based unlock conditions, which let liquidity release against a market threshold instead of a calendar date alone.
4. How do buyers verify that tokens are actually locked?
Buyers verify that tokens are actually locked by opening the public proof link and checking the contract state on Solscan, Solana Explorer, or RugCheck. Streamflow generates these proof links automatically for every lock and vesting contract, and consolidates them into a real-time tokenomics dashboard. Because contracts are immutable once deployed, what the explorer shows today is what will execute at unlock.
5. Are Streamflow's lock and vesting contracts audited?
Yes, Streamflow's lock and vesting contracts are audited by FYEO and OPCODES. They are immutable once deployed, carry no admin override, and execute entirely on-chain. Streamflow is also listed in the official Solana Docs under token vesting, and currently secures over $1.4 billion in total value locked across more than 40,000 projects.
