Loybek Documentation

Complete reference for Loybek — the first fully verifiable on-chain loyalty rewards protocol for Solana token communities.

What is Loybek?

Loybek is an on-chain protocol that automatically redistributes creator trading fees to loyal token holders through provably fair lottery draws.

When you launch (or register) a token with Loybek, 100% of the Pump.fun creator fees flow into a Fee Vault PDA — an on-chain account that nobody controls. A keeper bot periodically snapshots all holders, calculates loyalty points, publishes a Merkle root on-chain, generates verifiable randomness, and distributes rewards to a winner — all in a way that anyone can independently verify.

100%

Creator fees → holders

Human can manipulate draws

∞

Independently verifiable

Why Loybek exists

The Solana memecoin space is plagued by "cashback" mechanisms that claim to reward holders — but actually do the opposite. Revenue sharing and buyback-burn tokens incentivize flipping and swing trading: buy → collect revenue → sell → repeat. The "loyal holder" who never sells gets diluted while swingers extract value.

The cashback problem

✗Revenue sharing — pays everyone proportionally. Swingers who rotate in and out collect the same rate as diamond hands.

✗Buyback-and-burn — creates artificial buy pressure, but swingers time the cycle and sell the pump. Real holders see price gyrate without lasting benefit.

✗Reflection tokens — reward volume, not loyalty. High-frequency traders generate more volume → collect more reflections.

The Loybek answer

✓Loyalty-weighted draws — your chance of winning is directly proportional to how long you've held and how much you've NOT sold.

✓Brutal sell penalty — selling ANY amount instantly cuts your score by 50%+. No more "sell the top, buy back lower, collect rewards."

✓Fully on-chain verifiable — Merkle proofs + commit-reveal VRF. Nobody can rig the outcome. Every draw is independently auditable.

How it works

The reward cycle runs automatically via a keeper bot. Here are the five phases:

Fee Collection

Pump.fun creator fees accumulate in a program-owned Fee Vault PDA. Nobody can withdraw — only the program's distribute instruction can move funds out, and only after verifying a valid Merkle proof + VRF result.

Holder Snapshot

The keeper takes a periodic snapshot of all token holders — balances, hold duration, sell history. This data feeds the loyalty points formula.

Merkle Tree + On-Chain Commit

Loyalty points are computed, a Merkle tree is built, and the root hash is published on-chain. This cryptographically commits to the exact state of every holder.

Verifiable Randomness (VRF)

A commit-reveal VRF scheme generates unpredictable randomness on-chain. The keeper commits a secret hash, waits for slot hashes to change, then reveals — producing a result nobody could have predicted.

Distribution

The VRF result selects a winner (weighted by loyalty points). The keeper submits a Merkle proof on-chain. The program verifies the proof + VRF, then transfers SOL (+ tokens if available) to the winner.

Architecture

Loybek uses a hybrid on-chain / off-chain architecture. Heavy computation (snapshots, loyalty scoring, Merkle tree construction) happens off-chain for cost efficiency. Critical state (fee vault, Merkle roots, VRF results, distribution records) lives on-chain for verifiability.

On-chain (Anchor / Solana)

• Config PDA — per-token settings (authority, keeper, prize bps, protocol fee)

• Fee Vault PDA — holds creator fees (SOL + tokens). Only distribute can move funds out.

• Snapshot PDA — Merkle root + VRF commit/reveal data per draw sequence

• Distribution PDA — immutable record of each distribution (winner, amount, proof)

Off-chain (Keeper Bot + MongoDB)

• Holder snapshots — periodic fetches of all holders via DEX API

• Loyalty scoring — formula computation for all eligible holders

• Merkle tree construction — SHA-256 tree with sorted pairs

• Draw records — historical data for the verify page

This separation means you get the cost efficiency of off-chain computation with the trust guarantees of on-chain verification. The keeper cannot fabricate a winner because the Merkle root is already committed on-chain, and the VRF result cannot be predicted or manipulated.

On-Chain Program (Anchor)

The Loybek Anchor program is deployed at ESgQayjFN7QuwhZWB8S1Ciii88JnsyJTHMe47WEydCNM on Solana mainnet. It manages all on-chain state and enforces the rules of the protocol.

Instructions

initializeCreate a Config PDA + Fee Vault PDA for a new token. Sets the authority (admin), keeper (bot), and prize basis points range.

set_snapshotSubmit a Merkle root on-chain for a specific draw sequence. Only callable by the keeper. Commits the holder state cryptographically.

commit_randomnessPhase 1 of VRF — keeper sends SHA-256 hash of a random secret. At this point, the keeper doesn't know the future slot hash.

reveal_randomnessPhase 2 of VRF — keeper reveals the secret. Program verifies hash(secret) == commit, then computes: vrf_result = SHA-256(secret || slot_hash || merkle_root || sequence).

distributeVerify Merkle proof against the committed root, verify VRF result, then transfer SOL (and tokens if vault ATA has balance) to the winner. Creates an immutable Distribution Record.

update_configChange authority, keeper address, prize bps range, protocol treasury, or pause/unpause. Authority-only.

PDA Derivation

Config = PDA(["config", mint], program)

Fee Vault = PDA(["fee_vault", mint], program)

Snapshot = PDA(["snapshot", mint, sequence_u64_le], program)

Distribution = PDA(["distribution", mint, sequence_u64_le], program)

All PDAs are deterministically derived. Anyone can compute them from the token mint address.

Loyalty Points Formula

Every holder in the snapshot (top 100 by balance) receives a loyalty score based on four factors. The formula is designed to reward patient holders and exponentially punish sellers, while giving a modest bonus to those who DCA into their position.

points = balanceShare × holdRatio × sellPenalty × (1 + dcaBonus)

balanceShare=balance / totalSupply

Pure linear proportion of the token supply you hold. If you hold 1% of supply, your balanceShare is 0.01. Holding 2× as many tokens gives you 2× the weight — no diminishing returns, no caps. This ensures whales have proportional influence but don't monopolize the system due to the other multipliers.

holdRatio=yourDays / maxDays

How long you've held relative to the longest holder in the current set (0–1). This is intentionally relative, not absolute. On Solana memecoins where the average hold time is measured in hours, even holding for 3 days could make you the max holder. This means new tokens don't need months to build meaningful scores. It rewards patience versus the crowd, not arbitrary calendar time.

sellPenalty

The brutality of this multiplier is intentional. Zero sells = 1.0x (no penalty). Sold anything at all → instant −50% baseline, then quadratic decay: 0.5 × (1 − sellRatio)² where sellRatio = totalSold / totalBought.

Sold 0%→ 1.00xfull pointsSold 1%→ 0.49x−51%Sold 5%→ 0.45x−55%Sold 10%→ 0.41x−59%Sold 25%→ 0.28x−72%Sold 50%→ 0.13x−87%Sold 75%→ 0.03x−97%Sold 100%→ 0.00x−100%

This makes swing trading extremely unprofitable within Loybek. A trader who sells 10% of their bag loses 59% of their loyalty score — far more than the 10% they freed up.

dcaBonus=min(0.50, growthPct)

Where growthPct = (balance − initialBalance) / initialBalance. If you've grown your position by ≥10% since first seen → bonus up to +50% (capped). This rewards genuine DCA behavior — buying more over time. Spam micro-buys (like 0.01 SOL) won't reach the 10% threshold on any real position. The cap at +50% prevents the bonus from dominating the formula.

Normalization

After computing raw scores, all loyalty points are normalized to a 0–100,000 range. The highest scorer gets 100,000 points; everyone else is scaled proportionally. These normalized points become weights for the weighted random selection — a holder with 50,000 points has exactly 50% the win chance of someone with 100,000 points.

See the live leaderboard with all score components → Loyalty Leaderboard

Holder Snapshots

The keeper bot periodically fetches the top 100 holders by balance. Only these top 100 are eligible for loyalty rewards. For each holder, it records:

• Current balance — how many tokens they hold right now

• First seen at — timestamp from MongoDB (not DEX API, which can be unreliable)

• Total bought — lifetime volume of tokens received

• Total sold — lifetime volume of tokens sent/sold

• Initial balance — balance when the holder was first detected (for DCA bonus)

Holders with zero balance are tracked as "exited" and excluded from scoring. System wallets (bonding curve, Raydium AMMs, deployer wallets) are excluded from draws.

Why top 100?

Limiting to the top 100 holders by balance keeps the Merkle tree compact (smaller proofs, lower on-chain cost) while covering virtually all meaningful holders. Wallets outside the top 100 typically hold dust amounts.

Snapshots run on a configurable schedule (default: daily). The snapshot data becomes the input for loyalty scoring and Merkle tree construction.

Merkle Proofs

After computing loyalty points for all eligible holders, the keeper constructs a SHA-256 Merkle tree. This tree cryptographically commits to the exact state of every holder at snapshot time.

Leaf construction

leaf = SHA-256(wallet_pubkey_bytes || loyalty_points_u64_le || cumulative_before_u64_le)

Each leaf encodes the wallet address, their exact loyalty points (as little-endian u64), and cumulative points of all previous leaves (for weighted selection). Tree pairs are sorted before hashing to produce a canonical ordering.

The Merkle root is published on-chain via the set_snapshot instruction. From that moment, the holder state is immutably committed. When distributing a reward, the keeper must provide a valid Merkle proof for the claimed winner. The on-chain program verifies the proof against the committed root — if it doesn't match, the transaction fails.

Why this matters

Even if the keeper bot is completely compromised, it cannot fabricate a winner. It can only distribute to a wallet that was genuinely in the snapshot with the exact loyalty points that were committed. The Merkle proof is a mathematical guarantee — there is no backdoor.

Verifiable Randomness (VRF)

Loybek uses a commit-reveal VRF scheme for winner selection. This is a two-phase process that makes the randomness unpredictable to all parties — including the keeper operator and Solana validators.

Phase 1 — Commit

The keeper generates a 32-byte random secret and sends SHA-256(secret) on-chain. At this point, the keeper doesn't know what the future slot hash will be. The commit is recorded in the Snapshot PDA.

Phase 2 — Reveal (after ~2 seconds)

The keeper waits for slot hashes to change, then reveals the original secret. The program verifies that SHA-256(secret) == committed_hash, then computes:

vrf_result = SHA-256(secret || slot_hash || merkle_root || sequence)

The slot hash comes from the Solana SlotHashes sysvar — it changes every ~400ms. Since the keeper committed the secret before the slot hash was known, and the slot hash is determined by the validator after the commit, neither party can predict or control the final VRF result.

Winner selection

The VRF result (32 bytes) is interpreted as a little-endian u128 integer. This value is taken modulo the total loyalty points to produce a position in the weighted distribution. The keeper walks through the Merkle tree leaves (ordered by cumulative points) to find the winner whose range contains that position.

position = u128_le(vrf_result[0..16]) % totalLoyaltyPoints

Draw Cycle

The keeper runs the full draw cycle on a configurable interval (default: every 15 minutes). The cycle only executes if the fee vault has a minimum balance (default: 0.1 SOL).

Check vault balance— Skip if below MIN_FEE_VAULT_SOL (default 0.1 SOL)

Load latest snapshot— Use current holder data + loyalty scores

Build Merkle tree— Construct SHA-256 tree from all eligible holders

Submit Merkle root— set_snapshot on-chain (creates Snapshot PDA)

Request VRF— commit_randomness → wait → reveal_randomness

Select winner— Use VRF result for weighted random selection by loyalty points

Distribute on-chain— Submit Merkle proof → program verifies → SOL + tokens transferred

Record draw— Store full draw details in MongoDB for verification UI

After a successful draw, a 2-hour cooldown is applied for the winner's wallet. The same wallet can win again after the cooldown expires. There is no global cooldown — the next draw runs on schedule as long as the vault has sufficient balance.

Prize Calculation

Each draw distributes a fixed percentage of the fee vault balance to the winner.

prize = vaultBalance × 0.20%

Currently fixed at 20 basis points (0.20%) of vault balance per draw. Configured on-chain via prize_bps_min / prize_bps_max.

This conservative approach ensures the vault is never drained in a single draw. With draws every 15 minutes and 0.2% per draw, it would take hundreds of draws to significantly deplete the vault — meanwhile, new creator fees continuously flow in.

If the vault also holds SPL tokens (e.g., from token buybacks or donations), those are distributed alongside SOL using the same prize percentage.

Fee Collection

When a token is deployed or registered with Loybek, Pump.fun's creator fee sharing is configured to route 100% of trading fees to the Loybek Fee Vault PDA.

• 100% to Fee Vault PDA — the sole shareholder

• Admin revoked (locked) — nobody can change this, ever

Once locked, the fee sharing config is immutable on-chain. Neither Loybek, nor the token creator, nor Pump.fun can redirect the fees. They will flow to the vault forever.

The keeper periodically cranks a permissionless distributeFees instruction to move accumulated fees from the Pump.fun fee pool into the Fee Vault PDA. Anyone can crank it.

Native Token Rewards

Besides SOL from creator fees, you can deposit your native SPL token directly into the Fee Vault PDA. The program's distribute instruction automatically checks the vault's associated token account (ATA) — if it holds a balance, the winner receives both SOL and tokens in the same transaction.

How it works

1. Send your token — transfer any amount of your SPL token to the Fee Vault PDA address (the ATA is created automatically on first transfer).

2. Same draw, dual reward — each draw, the winner receives prize_bps% of the vault's SOL balance and the same percentage of the token balance.

3. Top up anytime — you can deposit additional tokens whenever you want. There's no lock-up or schedule required.

This is completely optional. If the vault ATA has zero token balance, draws proceed normally with SOL-only rewards. The token prize percentage mirrors the SOL percentage — controlled by the same on-chain prize_bps config.

Use case: you can run token buybacks, community airdrops, or marketing budgets through the vault — loyal holders are rewarded with your project's native token on top of the SOL they already earn from trading fees. It's an easy way to boost holder incentives without changing any config.

Draw Verification

Every Loybek draw is independently verifiable. The Verify page lets you audit any past draw by checking five aspects:

✓

On-chain data exists

Snapshot PDA with Merkle root and VRF result is on-chain and matches the draw record.

✓

Merkle root matches

The off-chain Merkle root matches the one committed on-chain before the VRF was generated.

✓

VRF fulfilled

The commit-reveal VRF completed successfully. The vrf_result on-chain matches the recorded result.

✓

Winner matches VRF

The winner was correctly selected from the VRF result using weighted random selection against the Merkle tree.

✓

Distribution recorded

A Distribution Record PDA exists on-chain with the winner address, prize amount, and timestamp.

The verify page also shows the full Merkle proof (all sibling hashes), the VRF commit/reveal values, and links to Solscan for every on-chain transaction. You can independently recompute the Merkle root and verify the VRF output matches the committed slot hash.

Verify any draw → Draw Verification

Deploying a Token

The fastest way to launch a Loybek-enabled token. The deploy flow handles everything automatically:

Fill out the form— Choose name, ticker, description, and optionally an image.

Deposit SOL— Send the required amount to a one-time deployer wallet. This covers Pump.fun token creation + initial liquidity.

Automatic deployment— The keeper detects your deposit and deploys the token on Pump.fun with a vanity mint address.

On-chain initialization— Config PDA + Fee Vault PDA are created. Fee sharing is configured with 100% to vault and permanently locked.

Token active— Your token appears on the Tokens page. The keeper starts running draws as soon as fees accumulate.

Deploy a token → Deploy page

Registering an Existing Token

Already have a Pump.fun token? You can add it to Loybek by configuring creator fee sharing to point at the Loybek vault. Here's the process:

Enter your mint address— We derive the unique Fee Vault PDA for your token and show you the address to use.

Configure fee sharing— On Pump.fun (or via Plugy API), set the vault PDA as the sole shareholder at 100%. You can do this from the Pump.fun creator settings page.

Lock the config— Revoke admin access so the fee sharing is permanently locked. This is irreversible — it's what makes the system trustless.

Register— Once verified (100% to vault PDA + locked), click Register. We initialize the on-chain config and start running draws.

Important: Locking fee sharing is a one-way operation. Once locked, nobody — not you, not Loybek, not Pump.fun — can redirect the creator fees. They flow to the vault and get distributed to holders forever. This is what makes Loybek trustless.

Anti-Gaming Measures

Every aspect of Loybek is designed to make gaming the system uneconomical.

Sell penalty is quadratic, not linear

A swing trader who sells 10% of their bag doesn't lose 10% of their score — they lose 59%. The quadratic function makes partial selling extremely costly. The only optimal strategy for score maximization is to never sell.

Hold ratio is relative

You can't game holdRatio by just showing up early and forgetting. It's relative to the current longest holder. If someone has held for 30 days and you've held for 15 days, your holdRatio is 0.5 — regardless of what day you bought.

DCA bonus has a threshold

Micro-buys to farm the DCA bonus won't work. You need to grow your position by ≥10% to trigger any bonus. On a real position, that means meaningful additional buys. The bonus is capped at +50% to prevent it from dominating.

Winner cooldown

After winning, a wallet enters a 2-hour cooldown. This prevents the same extremely loyal holder from sweeping consecutive draws.

Excluded wallets

System wallets (bonding curve, AMM pools, deployer wallets, protocol treasury) are automatically excluded from draws. Only real holders participate.

Sell history is permanent

The sell penalty is based on totalSold / totalBought — lifetime totals, not recent activity. You can't "reset" your sell history by buying back. Once you've sold, that damage to your score is permanent.

Trust Model

What Loybek can and cannot do — a transparent breakdown of trust assumptions.

Component	Trust level	Explanation
Fee Vault	Trustless	PDA owned by program. Nobody has private key. Only distribute instruction can move funds after Merkle + VRF verification.
Fee Sharing Config	Immutable	Locked on Pump.fun with admin revoked. Cannot be changed by anyone, ever.
Winner Selection	Verifiable	Commit-reveal VRF + Merkle proof. Anyone can independently verify any draw.
Merkle Root	Committed on-chain	Published before VRF. Cannot be changed after the fact. Keeper can't pick a different tree.
Holder Snapshots	Off-chain (verifiable)	Computed off-chain, but committed via Merkle root. Discrepancy would be detectable by comparing against on-chain token balances.
Keeper Bot	Semi-trusted	Can delay draws or go offline, but cannot steal funds, fabricate winners, or redirect fees. Worst case: draws stop until keeper is restarted.
Prize Amount	On-chain enforced	prize_bps is set in the Config PDA. The program enforces the percentage during distribution.

Cost per Cycle

Each draw cycle involves several on-chain transactions. The total cost is minimal.

set_snapshot— Submit Merkle root

~0.002 SOL

commit_randomness— VRF phase 1

~0.0005 SOL

reveal_randomness— VRF phase 2

~0.0005 SOL

distribute— Prize transfer + record

~0.002 SOL

Total per draw

~0.005 SOL

Keeper operational costs are covered by the protocol fee (configurable, currently 0%). The cost is deducted from each distribution if a protocol fee is set.

Glossary

PDA (Program Derived Address)

An address deterministically derived from a seed and program ID. No private key exists — only the program can sign for it.

Fee Vault

The PDA that holds accumulated creator trading fees. Derived from ["fee_vault", token_mint].

Merkle Tree

A hash-based data structure that allows proving a specific piece of data exists in a set without revealing the entire set.

Merkle Root

The single top hash of a Merkle tree. Committing this on-chain locks the entire dataset.

Merkle Proof

A chain of sibling hashes that proves a leaf belongs to the tree with the committed root.

VRF (Verifiable Random Function)

A function that produces randomness along with a proof that the output was correctly generated. Nobody can predict or manipulate the result.

Commit-Reveal

A two-phase scheme: first commit a hash (locking your choice), then reveal the preimage. Prevents the committer from changing their mind after seeing external data.

Keeper

An off-chain bot that automates the reward cycle: snapshots, Merkle trees, VRF requests, and distributions.

Loyalty Points

A score computed for each holder based on balance, hold time, sell history, and DCA behavior. Determines win probability.

Prize BPS

Basis points (1/10000) of the vault balance distributed as the prize in each draw. 20 bps = 0.20%.

Fee Sharing

Pump.fun's creator fee sharing system. Routes trading fees to specified shareholders — in Loybek's case, 100% to the Fee Vault PDA.

Distribution Record

An immutable on-chain PDA created after each draw. Records the winner, prize amount, Merkle root, and VRF result.

→ Leaderboard → Recent Winners → Verify Draw → Deploy Token → Add Token → All Tokens

Loybek — Loyalty that finally pays back. First fully verifiable on-chain rewards protocol on Solana.