DEV Community

Cover image for How I Used Solana PDA to Remove Human Discretion From Fee Reinvestment
No NPC Society
No NPC Society

Posted on

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

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

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

Top comments (0)