Why I Used Streamflow for LP Locking — and What "Permanent Lock" Actually Means

#blockchain #web3 #defi #solana

When I was designing the LP locking structure for $NONPC, the first thing I had to decide was what problem I was actually trying to solve.
Most projects that "lock liquidity" are solving a trust problem. They want holders to believe the team will not pull the liquidity. The typical solution is an announcement: "We have locked the LP." Sometimes there is a screenshot. Sometimes a link to a lock interface.
I had seen what happens when that approach fails. Projects that claimed locked liquidity but had authority structures with enough design flaws that the locks were effectively cancellable. Once I saw that pattern up close, I stopped treating LP lock announcements as meaningful on their own. The claim is only as strong as the on-chain state behind it — and most people never check the on-chain state.
That framing shaped every decision I made about locking.

The Two-Layer Structure

AFX uses two different locking mechanisms for two different purposes.
The initial LP — the liquidity provided at launch — is time-locked via Streamflow until December 16, 2026 (UTC). This lock is immutable and non-cancelable. When it expires, 100% of the LP tokens are burned. The team cannot withdraw the liquidity before that date. The lock conditions are verifiable on-chain:

Lock Contract: D58vtmtVyWy7hJyZn6e33ZiBe9LF5iZDPWYkKFBq9jcq
LP Mint: 2j4cHo6Kzxre3LUPw5z7BfvD7Yi5bc7H1DvEVHZ6cjur
Pool Address: CiDmAPSWe9T3WrHb4AYJ41BhRC83QKDAJBnpH4RwpKPz

The LP that AFX generates through weekly fee reinvestment uses a different mechanism: Raydium's Burn & Earn. This burns the LP tokens directly, making them structurally unrecoverable. There is no expiry date. There is no unlock event. The LP is simply gone from circulation.
The reason for using two different mechanisms comes down to what each one needs to accomplish. Streamflow handles time-bounded locking well and has an established audit track record on Solana. Burn & Earn handles permanent removal without any future unlock event. Using Streamflow for the reinvestment LP would mean every weekly execution creates a new time-locked position with a future expiry — which is not the design intent. AFX reinvestment LP needs to be permanently out of reach, not just locked until a future date.

Why Streamflow Specifically

I considered other locking mechanisms and custom implementations before landing on Streamflow. The two factors that drove the decision were audit track record and verification simplicity.
A custom locking implementation might have been possible, but it would have required its own audit to be meaningful. An unaudited custom lock is just another trust assumption. Streamflow has been used and reviewed by enough projects on Solana that its behavior is well-documented. More importantly, anyone can look up a Streamflow lock on a block explorer and verify the conditions without needing to understand the underlying contract code.
Verification simplicity matters more than it might seem. The goal was not just to lock the LP — it was to make the lock state something holders could actually check. If verifying the lock requires specialized knowledge, most people will not verify it. They will just trust the announcement. That defeats the purpose.

The "Permanent Lock" Problem

When writing the AFX specification, I ran into a genuine tension around the phrase "permanent lock."
The design intent is clear: LP that goes through Burn & Earn is structurally unrecoverable under normal conditions. It does not recirculate into the market. For practical purposes, it is gone.
But "permanent" is a strong word. The specification includes this language: "Note that 'permanent lock' in this document refers to a design intended such that the locked LP position is structurally fixed in a state that is fundamentally non-redeemable and does not recirculate into the market. However, since external risk factors such as DEX specification changes, smart contract vulnerabilities, and network failures may theoretically persist, this expression is a definition of the design goal, not a guarantee of outcome."
Writing that disclaimer was a deliberate choice. There was real tension between the strength of the word "permanent" and the honest uncertainty that exists in any on-chain system. DEX specifications change. Smart contract vulnerabilities are discovered. Network behavior evolves. Saying "permanent" without qualification would be overpromising.
I wanted to avoid the pattern I had seen in other projects — strong language that implies certainty where none exists. Stating the design goal clearly while explicitly noting its constraints felt more honest than claiming an absolute guarantee that cannot actually be made.

What You Can Verify

For the Streamflow time lock:
Search D58vtmtVyWy7hJyZn6e33ZiBe9LF5iZDPWYkKFBq9jcq on Solscan. The lock conditions, expiry date, and current state are all visible. The lock either exists in the state described or it does not. That check does not require trusting any documentation.
For the Burn & Earn permanent locks from AFX reinvestment:
Once AFX begins executing weekly reinvestments, each LP addition will be visible in the pool's transaction history. The burn transactions are permanently on-chain.
The distinction I keep coming back to: a lock announcement and a verifiable on-chain lock state are different things. The announcement is what the team says. The on-chain state is what actually exists. Checking the latter takes about thirty seconds on a block explorer.

A Note on What Locking Does and Does Not Solve

LP locking removes one specific risk: the team pulling liquidity. It does not remove market risk, smart contract risk, or the risk that the protocol fails for other reasons.
I think it is worth being explicit about this because "locked liquidity" has become a marketing term in crypto — something projects mention to signal safety without being specific about what risk is actually being addressed. The lock addresses one failure mode. The design of AFX is meant to address others. But neither eliminates all risk, and saying so clearly is more useful than implying otherwise.