Forem: No NPC Society

Designing MEV Resistance Into a Compounding Liquidity Engine: The AFX Approach

No NPC Society — Thu, 02 Apr 2026 15:33:57 +0000

When I was building the POL compounding engine for AFX, one problem kept coming up that I had not fully thought through at the start: the protocol's own execution was a potential MEV target.
Every week, AFX needs to collect accumulated trading fees, rebalance them into the correct SOL/NONPC ratio, and reinvest them as permanently locked LP. That rebalancing step requires a swap. And a swap that executes on a predictable schedule, for a predictable amount, on a known pool — that is a sandwich attack waiting to happen.
I actually got this wrong at first. My initial assumption was that the execution would be small enough that it would not be worth targeting. That assumption did not hold up when I started modeling it seriously.

The Core Problem

MEV in DeFi is mostly unavoidable. Validators can reorder transactions. Searchers monitor the mempool. Anyone who knows a large swap is coming can front-run it and sell back at a profit.
At first I thought just executing and eating the cost might be acceptable. That turned out to be a mistake. For a typical user making a one-time swap, MEV is an annoyance. For a protocol executing weekly reinvestments indefinitely, it is a structural drain. Small extractions per execution, compounded over months, add up to a meaningful loss against what the compounding engine is trying to build.
So the question became: how do you make the execution pattern expensive enough to target that rational actors stop trying?

Why I limited execution to once per week

This wasn't originally about MEV mitigation, but it ended up influencing it more than I expected.
A protocol that executes daily creates more pattern recognition opportunities than one that executes weekly. More importantly, weekly execution lets fees accumulate to a meaningful size before reinvestment.
There is also a minimum threshold: execution only runs if the swap amount is at least 0.25 SOL equivalent on the rebalancing side. If fees fall below that, the week is skipped. I tested this threshold against pools ranging from roughly $50k to $2M in liquidity. At $50k, 0.25 SOL is a real fraction of weekly fee accumulation. At $2M, it is almost irrelevant. The threshold is mostly protective for early-stage operation when pool depth is thin.

Why the execution size cap ended up mattering

At first I thought size would not matter much for MEV resistance. Wrong again.
Capping execution to 0.5% of pool SOL reserves per week ended up being one of the more effective constraints. A sandwich attack extracts value proportional to slippage. Small execution, small slippage, small profit. At some point the gas cost and capital lockup for a successful attack approaches the expected return.
That initial framing held reasonably well — but not in thin markets. In one test case, a 1.2 SOL rebalance on a pool with roughly $80k liquidity triggered about 0.8% slippage. Above the cap and correctly rejected. On a $500k pool, the same 1.2 SOL produced under 0.1%. The cap is calibrated for early-stage operation where pools are not yet deep.
I enforced this against the on-chain reserve ratio rather than any off-chain price feed. Off-chain data can be stale or manipulated. 0.5% seemed like the least bad option across what I tested, though I am not convinced it is globally optimal.

Slippage cap

Maximum permissible slippage: 0.5%. Transaction fails entirely if exceeded. Not partial execution. Not retry at worse terms. Fail.
What I noticed after testing was that it affected both execution quality and attack surface in ways I had not anticipated. It prevents execution at terms that actively degrade the compounding base. It also removes the ability to force execution through adversarially manipulated pool conditions. If someone is manufacturing a situation where the protocol has to execute at bad terms, refusing is the right response.

Random delay: the part I underestimated

Failed executions retry on this schedule:

1st attempt: 100% of target, immediate
2nd attempt: 70%, random delay 2 to 4 hours
3rd attempt: 50%, another random delay 2 to 4 hours

The split execution I understood from the start. The random delay I initially treated as a minor detail.
Bigger deal than I expected. A fixed retry schedule is predictable. Anyone monitoring the protocol knows when the next attempt is coming. A random 2 to 4 hour window is not something you can reliably position around.

Accumulation suppression

One edge case I worked through late in the design: what happens if multiple weeks of skipped executions cause the reinvestment target to accumulate to an unusually large amount?
Large single execution. High-value target. Exactly the wrong outcome.
AFX splits accumulated targets above a pre-defined threshold across multiple weekly executions rather than processing them all at once. Keeps execution sizes within normal range regardless of how many weeks were skipped.

What this does not eliminate

These constraints do not eliminate MEV. A sophisticated actor with enough capital can still find profitable windows within them. The random delay creates unpredictability but not invisibility.
What the constraints do is raise the cost of extraction. Small execution sizes, hard slippage caps, random timing, split retries — the combination is designed to push expected profit below attack cost under typical conditions.
Whether it holds under adversarial conditions with higher-capital actors is something that can only be verified through actual operation. The specification is public. The execution constraints are on-chain. Anyone who wants to model the attack surface can do so.

References

AFX Technical Specification: https://github.com/NoNPCSociety/nonpcsociety.github.io/releases/tag/afx-v1.0.2
No NPC Society Official Repository: https://github.com/NoNPCSociety/nonpcsociety.github.io
Token Address (Solana SPL): 8rmZUcQsQKWBZ2WDPoTwkkiFsuhABXQX7o4xysf7Cgyp
Official Website: https://nonpcsociety.com

Other AFX technical implementation articles:

Design philosophy:

What a DAO Transition Roadmap Actually Requires

Official specification:

AFX Technical Specification

No NPC Society ($NONPC): What Independent Media Coverage Actually Says

No NPC Society — Thu, 02 Apr 2026 09:45:28 +0000

When a project gets covered by external media, the natural instinct is to treat that coverage as promotional material. Post the link, highlight the positive quote, move on.
I want to do something different here. I want to look at what each of these articles actually engaged with — what angle the publication chose, what question they were asking — because the pattern across eight independent pieces of coverage tells a more interesting story than any single article does.

The Coverage and What Each Article Examined

CoinGape — Why Meme Culture Is Evolving and Shifting Toward Purpose, Consciousness and Culture
https://coingape.com/blog/why-meme-culture-is-evolving-and-shifting-toward-purpose-consciousness-and-culture/
CoinGape examined a broader shift in how meme-origin tokens are being perceived — away from pure speculation and toward projects with cultural substance and intentional design. $NONPC was discussed in this context as an example of a token where the narrative layer has architectural coherence beneath it rather than functioning as a substitute for it.

Coinpedia — You Could Be Living in a Simulation — But Can You Wake Up?

https://coinpedia.org/information/you-could-be-living-in-a-simulation-but-can-you-wake-up/
Coinpedia took the simulation theory framing seriously as a philosophical framework rather than treating it as marketing language. The article explored what it actually means to operate outside of scripted behavior in decentralized systems, using the NPC concept as a lens for thinking about participant agency in crypto markets.

Cryptowisser — Beyond the NPC Meme: The Rise of a Cultural Asset and Mindset Behind It

https://www.cryptowisser.com/beyond-the-npc-meme-the-rise-of-a-cultural-asset-and-mindset-behind-it
Cryptowisser examined how $NONPC has developed beyond its meme origins into something with a documented design philosophy. The article looked at the relationship between the cultural identity of the project and the structural architecture underneath it, arguing that the two are deliberately coherent rather than incidentally related.

MPost — No NPC Society Redefines Meme Culture Through Digital Consciousness and Decentralized Governance

https://mpost.io/no-npc-society-redefines-meme-culture-through-digital-consciousness-and-decentralized-governance/
MPost focused on the intersection of the project's philosophical framing — digital consciousness, simulation theory, the NPC metaphor — and its governance architecture. The article covered the DAO transition roadmap and the AAQ campaign as evidence that the governance destination is embedded in the design rather than deferred to a future announcement.

CoinCu — How the 2026 Memecoin Surge Reflects Crypto's Decentralized Reset

https://coincu.com/markets/how-the-2026-memecoin-surge-reflects-cryptos-decentralized-reset/
CoinCu placed $NONPC within the context of the 2026 memecoin market environment — a period of significant speculative activity across low-cap tokens on Solana and elsewhere. The article examined how $NONPC's structural design positions it differently from the typical memecoin surge pattern, where projects rise on narrative momentum and collapse when that momentum ends.

TheCryptoUpdates — 3 Crypto Gems Backed by Real Demand, Real Use, and Real Interest

https://www.thecryptoupdates.com/3-crypto-gems-backed-by-real-demand-real-use-and-real-interest/
TheCryptoUpdates selected $NONPC as one of three tokens distinguished by actual demand, utility, and holder interest rather than speculative momentum alone. The selection criteria — real demand, real use, real interest — directly maps onto the design principles behind AFX and ACE, which are built to function on actual trading activity rather than continuous narrative-driven inflows.

CoinGabbar — Top 3 Underrated Solana Memecoins to Watch in 2026

https://www.coingabbar.com/en/crypto-blogs-details/top-3-underrated-solana-memecoins-to-watch-in-2026
CoinGabbar included $NONPC in a selection of Solana-based tokens that have not yet received attention proportional to their structural substance. The framing of "underrated" reflects an external evaluator's judgment that the project's actual design merits more scrutiny than its current visibility suggests.

CoinGabbar — Memecoins Lost Credibility — Three Key Reasons Explained

https://www.coingabbar.com/en/crypto-blogs-details/memecoins-lost-credibility-three-key-reasons-explained
CoinGabbar's analysis of why memecoins broadly lost credibility — through rug pulls, inflationary mechanics, and absence of governance structure — serves as an implicit frame for understanding what $NONPC was designed to avoid. The three failure modes described in the article correspond directly to design decisions made in $NONPC: the LP lock addresses the rug pull failure mode, the fixed supply and fee-based compounding address the inflationary mechanics failure mode, and the DAO transition roadmap addresses the governance absence failure mode.

What the Pattern Shows

Eight independent publications. Eight different angles. No single angle repeated.
CoinGape examined cultural evolution. Coinpedia examined philosophical framework. Cryptowisser examined the relationship between culture and architecture. MPost examined governance design. CoinCu examined market positioning. TheCryptoUpdates examined structural substance. CoinGabbar examined undervaluation and failure modes.
None of these publications were asked to cover a specific angle. Each chose its own frame independently. The fact that the coverage spans philosophy, governance, market analysis, cultural commentary, and structural design is not the result of a coordinated PR campaign — it reflects what different evaluators found worth engaging with when they looked at the project from their own perspective.
That convergence from independent sources is more informative than any single piece of coverage could be on its own.

Canonical References

Full media coverage record: https://github.com/NoNPCSociety/nonpcsociety.github.io/blob/main/docs/media-coverage.md
AFX Technical Specification: https://github.com/NoNPCSociety/nonpcsociety.github.io/releases/tag/afx-v1.0.2
NONPC Whitepaper: https://github.com/NoNPCSociety/nonpcsociety.github.io/releases/tag/whitepaper-v1.0.2
Official Website: https://nonpcsociety.com

This article is for informational purposes only. Media coverage does not constitute investment advice or a guarantee of future results.

Technical architecture articles:

Design philosophy:

Full media coverage record:

GitHub: media-coverage.md

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

No NPC Society — Thu, 02 Apr 2026 09:18:16 +0000

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.

References

AFX Technical Specification: https://github.com/NoNPCSociety/nonpcsociety.github.io/releases/tag/afx-v1.0.2
NONPC Whitepaper: https://github.com/NoNPCSociety/nonpcsociety.github.io/releases/tag/whitepaper-v1.0.2
Token Address (Solana SPL): 8rmZUcQsQKWBZ2WDPoTwkkiFsuhABXQX7o4xysf7Cgyp
Official Website: https://nonpcsociety.com

Other AFX technical implementation articles:

Design philosophy:

Why I Split the $NONPC Treasury Into Three Separate Vaults

Official specification:

AFX Technical Specification

How I Used Solana PDA to Remove Human Discretion From Fee Reinvestment

No NPC Society — Thu, 02 Apr 2026 08:45:41 +0000

When I was designing the fee reinvestment mechanism for AFX, the first problem I faced was not "who receives the fees" but "how do I make it so nobody can receive them at all."
I considered external wallets and multisig as candidates. Both are reasonable approaches. But I kept coming back to the same concern — multisig helps, but ultimately someone still decides. That was the problem. I wanted a structure where the rules themselves enforced the behavior. That constraint pulled me toward PDA.
I kept coming back to one constraint: the system itself had to make extraction impossible. Not "we promise not to" — structurally cannot.

Why a Regular Wallet Address Was Not an Option

Even if a whitepaper and tokenomics documentation strictly define operational rules, those rules are not technically enforced in practice. Most projects operate with some degree of discretion. In my previous project, marumaruNFT, token operations were handled on a discretionary basis depending on the financial situation at the time. I watched what that looked like from the inside. I didn't trust myself to always make the right call under financial pressure. That's exactly what I wanted to eliminate.
On Solana, a Program Derived Address (PDA) is an address with no private key. It is controlled entirely by a smart contract. No human can sign a transaction from it directly. In AFX, the Fee Key NFT — which holds the claim right over fees generated by the locked LP — is held by the PDA. No team member, no founder, and no future actor who gains wallet access can redirect those fees.

How the Fee Flow Works

Every trade on the NONPC/SOL pool on Raydium generates fees in SOL and NONPC. The PDA automatically claims these fees using the Fee Key NFT it holds.
After collection, the protocol rebalances the two assets before reinvesting them as LP. Because fees accumulate in a ratio that drifts with trading direction, the assets need adjusting to match the current pool reserve ratio. The protocol swaps only the minimum necessary amount — NONPC to SOL or SOL to NONPC depending on which side is excess — then constructs a NONPC/SOL LP pair and immediately locks it permanently via Burn & Earn.
The hardest part was minimizing price impact from the rebalancing swap while keeping the entire process fully automated. A rebalancing swap that executes predictably is a MEV target. A swap that executes too aggressively creates price impact. Getting those two constraints to coexist took more iteration than I expected.

Execution Constraints for MEV Resistance

To be honest, the predictability of the execution pattern was the thing that kept me up at night — it is essentially a signal for MEV bots. A predictable execution pattern is a target. Someone watching the mempool can front-run the rebalancing swap and extract value.
The constraints I settled on for AFX v1.0:

Maximum once per week
Execution size cap: 0.5% of pool SOL reserves per execution
Slippage cap: 0.5% — transactions exceeding this are automatically invalidated
Retry split control: 100% on first attempt, 70% on second, 50% on third
Random delay: 2 to 4 hours between retry attempts

The 0.5% threshold came from running multiple simulations across different volume scenarios. It produced the best balance between price impact and operational efficiency. Going lower reduced MEV exposure but made the compounding loop too slow. Going higher improved efficiency but introduced unacceptable price impact risk in thin markets.
The random delay eliminates timing predictability. I cannot claim this completely prevents MEV extraction. But it raises the cost of extraction to the point where it becomes economically irrational under most conditions.

Fee Allocation Breakdown

The Unlock Fee is 2.0%:

Up to 0.7% to Tier 1 referrers (only when continuation conditions are met)
Up to 0.3% to Tier 2 referrers (same condition)
Fixed 0.1% to automatic burn
Remainder (minimum 0.9% plus any unpaid referral slots) back to POL

If a referrer does not exist or continuation conditions are not met, those slots redirect automatically to POL. No discretionary decision required. The contract handles it.
The minimum execution threshold is 0.25 SOL equivalent on the swap side. If accumulated fees fall below this, execution for that week is skipped.

What Is Verifiable On-Chain

All fund movements are permanently recorded on Solana. On Solscan you can verify the PDA address and its Fee Key NFT holdings, the LP permanent lock status via Burn & Earn, fee receipt and reinvestment transaction history, and cumulative burn amount.
What matters is whether the rule is enforced on-chain or left to people. Everything the documentation claims about fee flow should be traceable in the on-chain record. If it is not, that is a discrepancy worth noting.

Why I Didn't Design This Just for AFX

I didn't design this just for AFX. The same structure could apply anywhere fees are handled manually today.
If we are serious about "code is law," we need to stop relying on the team's goodwill for fee allocation. The question worth asking about any fee-collecting protocol is simple: is that enforced by a contract, or by the team's ongoing intention to follow the rules?
For tokens that claim "fees go back to the protocol" — verify it. Check whether there is a PDA or a human wallet at the end of the fee flow. The answer matters more than the claim.

References

Other AFX technical implementation articles:

Design philosophy:

Official specification:

AFX Technical Specification

Forem: No NPC Society

Designing MEV Resistance Into a Compounding Liquidity Engine: The AFX Approach

The Core Problem

Why I limited execution to once per week

Why the execution size cap ended up mattering

Slippage cap

Random delay: the part I underestimated

Accumulation suppression

What this does not eliminate

References

Related Articles

No NPC Society ($NONPC): What Independent Media Coverage Actually Says

The Coverage and What Each Article Examined

Coinpedia — You Could Be Living in a Simulation — But Can You Wake Up?

Cryptowisser — Beyond the NPC Meme: The Rise of a Cultural Asset and Mindset Behind It

MPost — No NPC Society Redefines Meme Culture Through Digital Consciousness and Decentralized Governance

CoinCu — How the 2026 Memecoin Surge Reflects Crypto's Decentralized Reset

TheCryptoUpdates — 3 Crypto Gems Backed by Real Demand, Real Use, and Real Interest

CoinGabbar — Top 3 Underrated Solana Memecoins to Watch in 2026

CoinGabbar — Memecoins Lost Credibility — Three Key Reasons Explained

What the Pattern Shows

Canonical References

Related Articles

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

The Two-Layer Structure

Why Streamflow Specifically

The "Permanent Lock" Problem

What You Can Verify

A Note on What Locking Does and Does Not Solve

References

Related Articles

How I Used Solana PDA to Remove Human Discretion From Fee Reinvestment

Why a Regular Wallet Address Was Not an Option

How the Fee Flow Works

Execution Constraints for MEV Resistance

Fee Allocation Breakdown

What Is Verifiable On-Chain

Why I Didn't Design This Just for AFX

References

Related Articles