FairMeme

A Protocol-Enforced Fair Launch Standard for Solana Memecoins

Technical Whitepaper · Version 1.0 · 2025

Abstract

We present FairMeme, a decentralized launchpad protocol on Solana that enforces fairness constraints at the smart contract level rather than at the application layer. The central contribution is the Fair Score — a transparent, real-time, onchain-verifiable composite metric that quantifies the structural risk of any memecoin launch across four dimensions: protocol integrity, distribution health, behavioral signals, and liquidity soundness. We argue that no amount of identity verification or platform-level moderation can substitute for cryptographic constraints enforced by immutable program logic. This principle extends to the development team itself: FairMeme is built by a pseudonymous team, consistent with the thesis that trust belongs in audited code, not in identities.

Table of Contents

1. [Introduction](#1-introduction) - 1.1 Problem Statement - 1.2 Why Not KYC - 1.3 Our Approach 2. [Threat Model](#2-threat-model) - 2.1 Rug Pull - 2.2 Coordinated Pump-and-Dump - 2.3 Bot Sniping at Launch - 2.4 Sybil Airdrop Farming 3. [Protocol Design](#3-protocol-design) - 3.1 Vesting Contract - 3.2 Whale Cap - 3.3 Anti-Bot Launch Delay - 3.4 Progressive Exit Tax - 3.5 Merkle Airdrop - 3.6 Bonding Curve Design 4. [The Fair Score](#4-the-fair-score) - 4.1 Design Philosophy - 4.2 F1 — Protocol Integrity - 4.3 F2 — Distribution Health - 4.4 F3 — Behavioral Signals - 4.5 F4 — Liquidity Integrity - 4.6 Caps & Penalties - 4.7 Composite Formula 5. [Game Theory](#5-game-theory) 6. [Implementation](#6-implementation) - 6.1 Anchor Programs - 6.2 Score Oracle - 6.3 Security Considerations 7. [Competitive Analysis](#7-competitive-analysis) 8. [Roadmap](#8-roadmap) 9. [Conclusion](#9-conclusion) - 9.1 On Pseudonymous Development

• Appendix A — Score Weight Justification
• Appendix B — Switchboard VRF Integration
• Appendix C — Protocol Fee Structure

1. Introduction

The Fairness Problem in Memecoin Markets

The memecoin market on Solana processed over $2 billion in daily volume at its peak in early 2025. The majority of that value was extracted by a small number of actors systematically exploiting structural asymmetries invisible to ordinary participants.

Platforms like Pump.fun democratized token creation and achieved genuine product-market fit. They proved that a large, liquid market for speculative community tokens could exist. What they did not solve — and did not attempt to solve — is the alignment problem between token creators and token buyers.

This paper presents FairMeme, a protocol that reframes the fairness problem: instead of trusting creators or verifying identities, we make certain behaviors structurally impossible through smart contract constraints, and make all remaining risk legible through a transparent, real-time scoring system.

1.1 Problem Statement

Three categories of behavior account for the vast majority of memecoin losses for retail participants.

Rug pulls occur when founding team members sell their token allocation immediately after launch, collapsing the price. Pump.fun reported that approximately 97% of tokens created on the platform lost all value within 30 days. The primary mechanism is founder selling, enabled by unrestricted access to their allocation from day zero.

Coordinated pump-and-dump schemes involve groups of wallets — typically organized via Telegram or Discord — buying a token simultaneously to create artificial price momentum, then selling in coordination once retail buyers have entered. The coordination happens off-chain and is therefore invisible to the blockchain until the dump has already occurred.

Bot sniping at launch allows automated programs to detect a token creation transaction in the mempool and front-run it, acquiring large positions at the opening price before any human buyer can participate. These bots then sell into the early retail demand, extracting value and depressing the organic price discovery.

1.2 Why KYC Is Not the Answer

A common response to these problems is to require identity verification of token creators. We reject this approach on both principled and practical grounds.

Practically, KYC is circumventable. Identity documents are available for rent via commercial services. A verified scammer remains a scammer — their real name adds no constraint on their behavior. More importantly, KYC creates false confidence: users may assume a verified creator implies a safe token, increasing their exposure to the very risks KYC purports to mitigate.

Principally, KYC violates the permissionless nature of DeFi. The value of a decentralized financial system is precisely that it does not require trusted intermediaries to validate participants. Introducing identity requirements recreates the gatekeeping dynamics of traditional finance without the legal protections that accompany them.

1.3 Our Approach

FairMeme is built on two complementary ideas: cryptographic constraint and behavioral transparency.

Where a behavior is harmful and preventable, we prevent it at the contract level. Where it is detectable but not preventable, we measure it in real time and surface it to all participants through the Fair Score. Where it is neither preventable nor fully detectable, we are honest about that limitation.

Core thesis: The Fair Score does not claim to eliminate all risk from memecoin participation. It claims to accurately characterize that risk at every moment, giving participants the information they need to make informed decisions. This is a stronger and more honest claim than any "safe" or "audited" label.

2. Threat Model

2.1 Rug Pull

A rug pull is the extraction of value by a party in a privileged position — typically the token creator. It takes several forms: direct sale of founder-allocated tokens, removal of liquidity pool funds, or minting of additional tokens to dilute existing holders.

Attack vector: Creator controls a wallet with unrestricted access to 15–30% of token supply. After launch hype drives retail buying, creator sells the entire position in a single transaction or series of transactions. Price collapses. LP drained. Zero legal recourse.

Mitigation: On-chain vesting lock enforced by the VestingAccount program. Tokens are held by the program, not the creator's wallet. Release instructions verify Clock::get()?.unix_timestamp > release_timestamp. No admin override. No proxy upgrade path. The constraint is cryptographic.

2.2 Coordinated Pump-and-Dump

Coordination happens off-chain, making it formally undetectable on the blockchain. However, coordination leaves statistical signatures in the transaction history: temporal clustering of buys, correlated wallet funding patterns, and asymmetric sell pressure concentrated in large-balance wallets.

Attack vector: 50 wallets receive a coordinated buy signal via Telegram. They execute purchases within a 30-second window. Price rises 400%. FOMO-driven retail buying follows. Coordinating wallets sell into the retail demand over the next 2–4 hours, each exiting gradually to avoid triggering sell alerts.

Mitigation (partial): Progressive exit tax makes coordinated large-position dumps expensive. Whale cap limits individual accumulation. The Burst Index and Cluster Score within the Fair Score detect and score these patterns in real time. We are transparent that this threat cannot be fully eliminated — human coordination is legal. Our contribution is to make it legible.

2.3 Bot Sniping at Launch

Automated programs monitor the Solana mempool for token creation or pool initialization transactions. Upon detection, they submit buy transactions with elevated priority fees, acquiring positions in the same block or the immediately following block. By the time the first human buyer executes, bots already hold significant supply at a lower average cost.

Attack vector: Token launches at block N. Bots acquire 8% of supply in blocks N through N+2 at a 0.8x average price. Human buyers drive price up 3x over the next hour. Bots sell linearly, extracting value from every retail buy in their price range. Effective tax on retail: ~30% of price appreciation.

Mitigation: Random execution delay of 1 to 3 blocks applied at the program level using Switchboard VRF. The bot cannot know which block will execute. Combined with the whale cap, no single actor can acquire a dominant position in the launch window.

2.4 Sybil Airdrop Farming

When airdrops reward any eligible wallet, sophisticated actors create hundreds of wallets to farm the distribution. This concentrates supply in the hands of a small number of actors despite the appearance of broad distribution, and creates immediate sell pressure when the airdrop recipients liquidate.

Mitigation: Merkle tree commitment pre-launch with optional wallet age filtering. The distribution is fixed before the token exists. Wallet age requirement of 90+ days filters freshly-created sybil wallets. The merkle root is publicly verifiable before any purchase.

3. Protocol Design

Each mechanism described below is implemented as an instruction within an Anchor program. All constraints are enforced at execution time — they cannot be bypassed by the token creator, the platform, or any other party after deployment.

3.1 Vesting Contract

The vesting contract holds founder tokens in a VestingAccount PDA derived from the token mint address and the founder's public key. The account stores the locked amount, the unlock schedule, and a claimed flag per period.

pub struct VestingAccount {
    pub beneficiary: Pubkey,       // founder wallet
    pub mint: Pubkey,              // token mint
    pub total_amount: u64,         // total locked
    pub schedule: [VestPeriod; 8], // max 8 tranches
    pub released: u64,             // cumulative released
}

pub struct VestPeriod {     pub unlock_ts: i64,  // unix timestamp     pub amount: u64,     // tokens in this tranche     pub claimed: bool, }

// Release instruction — no admin override pub fn release(ctx: Context<Release>) -> Result<()> {     let clock = Clock::get()?;     let now = clock.unix_timestamp;     let vesting = &mut ctx.accounts.vesting;

let mut release_amount: u64 = 0;     for period in vesting.schedule.iter_mut() {         if !period.claimed && now >= period.unlock_ts {             release_amount += period.amount;             period.claimed = true;         }     }     require!(release_amount > 0, ErrorCode::NothingToRelease);     // transfer from PDA escrow to beneficiary... } 

The vesting schedule is written at token creation and cannot be modified. The program is deployed as an immutable program — no upgrade authority.

3.2 Whale Cap

The whale cap enforces a maximum holding per wallet during a configurable initial period. The bonding curve's buy instruction queries the buyer's current balance before executing and rejects the transaction if it would exceed the cap.

// In buy instruction, before token transfer
let current_balance = buyer_token_account.amount;
let total_supply = mint.supply;
let cap_pct = launch_config.whale_cap_bps; // in basis points
let cap_absolute = (total_supply as u128)
    .checked_mul(cap_pct as u128).unwrap()
    .checked_div(10_000).unwrap() as u64;

let clock = Clock::get()?; if clock.unix_timestamp < launch_config.cap_expiry {     require!(         current_balance.checked_add(amount).unwrap() <= cap_absolute,         ErrorCode::WhaleCap     ); } 

3.3 Anti-Bot Launch Delay

The launch delay uses Switchboard's Verifiable Random Function (VRF) to generate an unpredictable delay between 1 and 3 slots. The delay is committed to a LaunchDelay account at token creation. Purchases before the launch slot plus delay are rejected.

The critical property is that the delay value is unpredictable — it is generated by the VRF after the token is created but before the launch window opens. A bot monitoring the mempool cannot know the exact execution slot in advance.

3.4 Progressive Exit Tax

The exit tax is a sell-side fee that scales with the seller's proportion of total supply. It is applied at the bonding curve contract level and cannot be bypassed.

Tax proceeds accumulate in a protocol treasury. 50% is redistributed proportionally to all current token holders as a stay premium — holders benefit from whale sells rather than suffering them.

3.5 Merkle Airdrop

The airdrop distribution is defined by a merkle tree whose root is published on-chain at token creation, before any tokens exist. Any party can verify that a given address is in the merkle tree by checking the proof against the root. The tree cannot be modified after deployment.

This provides a critical trust property: buyers can verify the airdrop distribution before deciding to purchase. There are no post-launch "community airdrops" that turn out to be founder wallet top-ups.

3.6 Bonding Curve Design

FairMeme supports three bonding curve shapes, configurable at launch:

Linear:       P(x) = a·x + b
Logarithmic:  P(x) = a·ln(x+1) + b   ← recommended
Exponential:  P(x) = a·e^(bx)

Where x is the proportion of total supply sold and P(x) is the price in SOL. The logarithmic curve scores highest in F4 because it provides the most equitable price discovery — early buyers get meaningful price advantage without the extreme early-buyer monopoly that exponential curves create.

4. The Fair Score

4.1 Design Philosophy

The Fair Score measures structural risk, not creator intent. It makes no judgment about whether a founder is honest. It measures whether the contract structure makes dishonesty possible, and whether observable behavior patterns match known attack signatures.

Three principles govern the score's design:

Objectivity. Every component is derived from on-chain data or deterministic computation thereof. No human judgment, no oracle manipulation, no platform discretion enters the score calculation.

Transparency. The formula is public. Anyone can replicate the calculation independently. The score is a statement of fact, not a label of trust.

Dynamic. The score is recalculated on every new block. A token that scores 94 at launch may score 71 three hours later if whale accumulation has grown. Participants always see the current state, not a snapshot from launch.

4.2 F1 — Protocol Integrity (30 points)

F1 measures whether the smart contract structure prevents the creator from extracting value through privileged actions. This domain has the highest weight because it is fully within the creator's control before launch and cannot be improved after deployment.

A F1 score below 15 triggers a global score cap of 60 and displays a STRUCTURAL RISK warning. This cap is non-compensable — no amount of good behavioral scores can override a broken protocol structure.

4.3 F2 — Distribution Health (25 points)

F2 measures how the token supply is distributed across wallets. Concentrated supply enables manipulation regardless of protocol integrity.

Gini Coefficient

We apply the Gini coefficient — a measure of inequality from economics — to token supply distribution:

G = 1 − 2∫₀¹ L(x) dx

where L(x) is the Lorenz curve of the supply distribution

GiniScore = 6 × max(0, 1 − G/0.9) Threshold: G > 0.85 scores 0. G = 0 scores 6. 

Wallet Age Score

The average age of buyer wallets is a proxy for sybil attack probability. Fresh wallets — created within 30 days of the token launch — are strong indicators of coordinated sybil behavior. The wallet age score penalizes tokens where more than 40% of buyers have wallets younger than 30 days.

4.4 F3 — Behavioral Signals (30 points)

F3 is the most technically sophisticated domain. It detects coordination patterns in the observable transaction history using information-theoretic and graph-theoretic methods.

Burst Index — Shannon Entropy

We measure the temporal distribution of buy transactions across the first 100 slots after launch. Shannon entropy quantifies coordination clustering:

H = −Σᵢ p(i) · log₂(p(i))

where p(i) = fraction of volume in slot i of the launch window

BurstIndex = H / H_max · 10 H_max = log₂(100) ≈ 6.64 (perfect uniform distribution)

Low entropy (clustered buys) → Low Burst Index → Low F3 score 

Cluster Score — Graph Analysis

We construct a directed graph G = (V, E) where vertices are wallets and edges connect wallets that (a) transacted within the same 2-slot window AND (b) share a funding ancestor within 3 hops. We identify connected components. If the largest component holds more than 8% of total supply, the Cluster Score is capped at 4/10.

Sell Pressure Asymmetry

The ratio of sell-side pressure from large holders vs. small holders is computed hourly. If wallets holding more than 1% of supply have a sell/buy ratio more than 3x higher than wallets holding less than 0.1%, this triggers a Sell Pressure Asymmetry penalty — a classic signature of coordinated exit during retail buying.

4.5 F4 — Liquidity Integrity (15 points)

F4 measures whether the liquidity pool is deep enough and balanced enough to prevent price manipulation.

4.6 Caps & Penalties

Score caps are non-compensable by design — certain structural failures cannot be offset by good behavior in other dimensions.

4.7 Composite Formula

FairScore = F1×0.30 + F2×0.25 + F3×0.30 + F4×0.15 + MerkleBonus − Σ penalties
            subject to all caps

F1 ∈ [0,30]  F2 ∈ [0,25]  F3 ∈ [0,30]  F4 ∈ [0,15] MerkleBonus = 3 if merkle root committed pre-launch, else 0 FairScore ∈ [0, 100] after all caps and penalties 

Score Tiers

5. Game Theory

Why Honest Founders Prefer FairMeme

The Fair Score creates a signaling equilibrium where good behavior is incentivized and bad behavior is costly — without requiring trust in any party.

Consider the decision of a token creator with genuinely good intentions. On Pump.fun, their token is indistinguishable from a rug pull until it fails to rug. On FairMeme, they can credibly signal their commitment by locking their allocation for 365 days — a signal that costs nothing if they intended to hold anyway, but would be extremely costly to a scammer who plans to sell immediately.

This is the classic economic mechanism of costly signaling: the cost of a signal to the honest sender approaches zero, while the cost to the dishonest sender is prohibitive. Vesting locks, LP burns, and mint revocations are all costless to a creator who was never going to extract value. They are highly costly to one who was.

The progressive exit tax creates a second incentive: alignment of interest between holders. A whale who holds 3% of supply and sells dumps the price for all other holders. The 12% exit tax on that position means the whale absorbs 12% of the loss they impose on others. This is a Pigouvian tax on a negative externality, applied automatically by the smart contract.

The platform does not need to trust anyone. The mechanisms make trustworthiness observable (Fair Score) and rational (exit tax, vesting). The honest founder benefits from both: their score is high because their structure is good, and their token's price is protected by the tax deterring whale exits.

The residual problem is off-chain coordination. No on-chain mechanism can prevent legal voluntary trading. Our response is that the Fair Score's behavioral detection (Burst Index, Cluster Score) makes this visible — buyers can see the coordination pattern as it forms and adjust accordingly.

6. Implementation

6.1 Anchor Programs

FairMeme consists of four Anchor programs deployed on Solana mainnet-beta:

fair_launch (~1,800 lines Rust) — The core program. Handles token creation, bonding curve initialization, and all buy/sell instructions with integrated whale cap, launch delay, and exit tax logic.

Key instructions: initialize_launch, buy, sell, graduate.

vesting_escrow (~600 lines Rust) — Standalone vesting contract. Holds founder allocations in PDAs, enforces unlock schedules. Composable — can be used with any SPL token independently of fair_launch.

merkle_distributor (~400 lines Rust) — Airdrop distribution contract. Accepts a merkle root at initialization, processes claims with proof verification. Includes wallet age verification via Switchboard oracle.

fair_score_registry (~300 lines Rust) — On-chain registry of Fair Scores. Updated by the Score Oracle via a permissioned crank. Stores the current score and 30-day history per token mint.

6.2 Score Oracle

The Fair Score requires off-chain computation — graph analysis of the wallet cluster network and entropy computation over transaction history cannot be done efficiently within Solana's compute limits.

The Score Oracle is a trusted indexer operated by the FairMeme team in v1, with a migration path to a decentralized oracle network (Switchboard) in v2. The oracle reads Solana transaction history, computes the Fair Score components, and submits updates to the fair_score_registry program.

Acknowledged limitation: The oracle dependency is a centralization vector in v1. The protocol is designed to function without it — the four on-chain constraint mechanisms operate independently. The Fair Score is additional signal, not a gate. We publish the oracle source code and commit to a decentralization timeline.

6.3 Security Considerations

Program upgrade authority: All FairMeme programs are deployed with upgrade authority set to a 4-of-7 multisig at launch, with a plan to upgrade to a DAO-controlled program authority in Q3 2026.

PDA validation: All program accounts are derived from deterministic seeds including the token mint address. This prevents substitution attacks where a malicious account is passed in place of the expected program account.

Integer overflow: All arithmetic uses Rust's checked arithmetic or the SafeMath pattern. Amount calculations for the bonding curve are performed in u128 to prevent overflow before division.

Re-entrancy: Solana's single-threaded account locking model prevents classical re-entrancy attacks. We additionally mark critical state changes before external CPI calls as a defense-in-depth measure.

7. Competitive Analysis

Every anti-scam mechanism on FairMeme is the first in its category among major Solana launchpads. The competitive advantage is not easily replicated: the Fair Score algorithm requires months of calibration data to be meaningful, and immutable programs cannot be "upgraded" to add these features retroactively on existing platforms.

8. Roadmap

Phase 0 — Research & Design (Q2 2025) ✓

• Threat model formalization
• Fair Score algorithm design
• Protocol specification whitepaper
• UI/UX prototype

Phase 1 — Devnet (Q3 2025) ← Current

• Anchor program development (fair_launch, vesting_escrow)
• Score Oracle v1 (centralized indexer)
• Internal security review
• Community testnet launch

Phase 2 — Mainnet Beta (Q4 2025)

• External security audit (Sec3 / OtterSec)
• Mainnet deployment — 4/7 multisig authority
• merkle_distributor + fair_score_registry programs
• Full UI launch — trade, dashboard, launch flow

Phase 3 — Protocol Maturation (Q1–Q2 2026)

• Score Oracle v2 — Switchboard decentralized computation
• Score calibration using 6 months of mainnet data
• API for third-party integrators
• Mobile-first trading interface

Phase 4 — Decentralization (Q3 2026)

• DAO governance for protocol parameters
• Program authority transferred to governance
• Score algorithm upgrades via governance vote
• Cross-chain expansion research (Base, Sui)

9. Conclusion

The memecoin market does not need to be cleaned up. It needs to be made legible. FairMeme does not prevent gambling — it prevents cheating.

We have shown that the three primary failure modes of memecoin launches — rug pulls, coordinated pumps, and bot sniping — are addressable through combinations of smart contract constraints and transparent behavioral measurement. None of these solutions require identity verification, platform trust, or centralized moderation.

The Fair Score is the central innovation. It transforms opaque structural risk into a real-time, verifiable, universally comparable number. A token that scored 94 at launch and now scores 71 tells a story — a story visible to every participant simultaneously, not just to insiders. This information symmetry is the core value proposition.

The memecoin market has demonstrated genuine demand for speculative community tokens. The problem is not the demand — it is the structural asymmetry between sophisticated actors who understand the risks and retail participants who do not. FairMeme's thesis is that this asymmetry is not fundamental to the market; it is an artifact of insufficient tooling.

9.1 On Pseudonymous Development

FairMeme is developed by a pseudonymous team. This is intentional, and it is consistent with the protocol's core thesis.

Throughout this paper, we have argued that trust should be placed in audited, immutable code — not in the identity of any individual. This principle applies equally to token founders and to protocol developers. The founder's name does not appear in the vesting contract. The whale cap does not care who wrote it. The audit firm's signature is what matters — not ours.

We anticipate the objection: "How can an anti-scam platform be built by an anonymous team?" The answer is embedded in the question itself. The entire point of FairMeme is that you should not need to trust us. If the protocol required you to trust the development team, it would be a contradiction of everything in this document.

Satoshi Nakamoto never revealed their identity. The Bitcoin network has processed over $10 trillion in transactions. The trust is in the protocol, not the person.

"The founder's name does not appear in the vesting contract. The audit firm's signature does. We consider this the correct order of trust."

The physical security of contributors is also a real concern in the current environment. Pseudonymous development is not evasion — it is a reasonable precaution for anyone building financial infrastructure that challenges powerful incumbent interests. We make no apology for it.

What we commit to instead of identity: open source code, public audit reports, onchain-verifiable program deployments, and a governance roadmap that progressively removes any remaining trust dependency on the development team. By Phase 4, the protocol will be controlled by a DAO. At that point, the question of who built it becomes entirely irrelevant.

This whitepaper describes a protocol in pre-deployment phase. Smart contract code will be published on GitHub and submitted for external audit before mainnet deployment. The Fair Score algorithm and all scoring weights are subject to revision based on testnet data. Participation in memecoin markets involves substantial financial risk. FairMeme reduces certain structural risks — it does not eliminate market risk.

Appendix A — Score Weight Justification

F1 and F3 each receive 30% weight because they address the two highest-impact attack vectors: protocol-level rug (F1) and behavioral coordination (F3). F2 at 25% addresses distribution concentration, which is detectable but harder to prevent at the contract level. F4 at 15% addresses liquidity mechanics, which are important but second-order relative to the other factors.

These weights were derived from a qualitative analysis of 200 failed token launches on Pump.fun between January and June 2025, categorized by primary failure mode. They will be recalibrated using FairMeme mainnet data after 90 days of operation.

Appendix B — Switchboard VRF Integration

The anti-bot launch delay uses Switchboard's on-chain VRF to generate a verifiably random delay value between 1 and 3 slots. The VRF proof is published on-chain, allowing any party to verify that the delay was generated randomly rather than chosen by the team. This prevents the platform from selectively advantaging or disadvantaging specific launches by manipulating the delay.

Appendix C — Protocol Fee Structure

FairMeme charges a 0.05 SOL creation fee and a 0.5% platform fee on bonding curve buy transactions. 50% of the platform fee goes to the protocol treasury. The remaining 50% is split: 25% to the Score Oracle operational fund and 25% to a community grants program for tooling development.

Appendix D — Full Scoring Reference

FairScore = F1×0.30 + F2×0.25 + F3×0.30 + F4×0.15 + MerkleBonus − Σ penalties

F1 — Protocol Integrity (0–30 pts)   Founder vesting lock:     0–10 pts   LP lock status:           0–8 pts   Contract immutability:    0–7 pts   Mint authority revoked:   0–5 pts

F2 — Distribution Health (0–25 pts)   Top-10 concentration:     0–8 pts   Wallet age (avg buyers):  0–7 pts   Gini coefficient:         0–6 pts   G = 1 − 2∫L(x)dx   Active holder diversity:  0–4 pts

F3 — Behavioral Signals (0–30 pts)   Burst Index (Shannon):    0–10 pts  H = −Σ p(i)·log2(p(i))   Cluster Score (graph):    0–10 pts  largest component < 8% supply   Sell pressure asymmetry:  0–6 pts   New wallet ratio:         0–4 pts

F4 — Liquidity Integrity (0–15 pts)   Depth/MCap ratio:         0–6 pts   LP concentration:         0–5 pts   Slippage symmetry:        0–4 pts

MerkleBonus: +3 pts if merkle_root committed before launch_ts

Score Caps (non-compensable):   F1 < 15:                  score ≤ 60   No vesting (0 days):      score ≤ 55   Whale cap > 3%:           score ≤ 65   Top-10 > 30% supply:      score ≤ 65   Cluster > 8% supply:      score ≤ 55

Penalties (additive):   LP unlocked:              −8 pts   Founder allocation > 20%: −5 pts 

FairMeme Whitepaper v1.0 · Pre-publication draft · Not investment advice Smart contract code pending audit · All protocol parameters subject to change before mainnet deployment Contact: fairmeme.app · Apache 2.0 License