BurnlyFans V1
Whitepaper.

SECTION 01

Abstract

BurnlyFans V1 is a planned fair-launch Base memecoin protocol built around disclosed Creator Rewards. The planned launch sends 100% of BF supply to a Clanker-created liquidity pool, with no team allocation, presale, creator vault or developer buy.

Of Creator Rewards actually received, 40% forms the Creator Cut and 60% returns to BF and community mechanisms through 20% Burnback, 35% Fan Vault and 5% Top Fans. BF burns are permanent; distributions are variable and may be zero.

SECTION 02

BurnlyFans Overview

BurnlyFans separates two economic layers. Launch allocation determines where BF supply begins: the planned split is 100% Clanker liquidity pool and 0% elsewhere. Creatonomics determines what happens to Creator Rewards received after trading begins: 40/20/35/5.

Eligible community burns create weekly Fan Power. Following Friday finalization, burners may pull-claim their pro-rata share of the community ETH pool.

SECTION 03

Why BurnlyFans Exists

The protocol converts a disclosed portion of memecoin creator economics into inspectable burn and community routes. It aims to keep the product simple: trade BF, optionally burn BF, measure Fan Power, and claim only what immutable accounting makes available.

BurnlyFans does not pay passive holders, promise profit or treat its indexer as an accounting authority.

SECTION 04

BF Token

BF is the planned BurnlyFans ERC-20 token and is not deployed. The interface currently assumes 18 decimals; verified deployed bytecode and configuration will be authoritative.

No team token allocation, presale, creator vault or developer buy is planned. The entire supply is intended for the initial Clanker liquidity pool.

SECTION 05

Fair Launch Model

The planned Clanker V4 configuration allocates 100% of BF supply to the Clanker-created liquidity pool: 0% team allocation, 0% presale, 0% creator vault and 0% developer buy. Creator compensation instead comes from the disclosed Creator Cut.

This is a pre-deployment design statement. It becomes a factual launch claim only after the final Base transaction, pool allocation, reward recipients, fees and supply are verified onchain.

SECTION 06

Creator Rewards

Creator Rewards are net assets actually received through the configured Clanker liquidity position and reward routing. They are not trading volume, token supply or guaranteed revenue.

Worked examples use a planned approximation of 1% of BF trading volume. Final results depend on the verified Clanker fee and recipient configuration, Clanker-level fees, real volume and rewards actually collected.

SECTION 07

Creatonomics

BurnlyFans routes 100% of Creator Rewards received: 40% Creator Cut, 20% Burnback, 35% Fan Vault and 5% Top Fans. The final three routes are the 60% described as returning to BF and community mechanisms.

At an illustrative $50,000 average daily volume and 1% Creator Reward assumption, seven-day volume of $350,000 would produce approximately $3,500 of Creator Rewards: $1,400 Creator Cut, $700 Burnback, $1,225 Fan Vault and $175 Top Fans. This is not a forecast.

SECTION 08

Creator Cut

Forty percent of Creator Rewards received is routed to the configured Creator Safe. It is project-controlled compensation, not community-owned funds.

At the creator's discretion it may support maintenance, development, infrastructure, operations, liquidity support, marketing, security work, audits, experiments, community drops or future expansion. No fixed internal spending promise is made.

SECTION 09

Burnback

Twenty percent of Creator Rewards received funds protected BF purchases. Permissionless executions spend capped WETH slices, enforce a guarded minimum output and deliver acquired BF directly to The Furnace.

A separately funded executor bounty may compensate execution. It cannot reduce, redirect or custody the 20% Burnback allocation.

SECTION 10

The Furnace

The Furnace is the permanent destination for BF burned by users and the protocol. No withdrawal route exists in the planned core.

Direct BF transfers to The Furnace remain irreversible but do not create Fan Power, ranking credit or claims because they bypass Burn Router accounting.

SECTION 11

Burn Cycles

Burn Cycles run Friday 16:00 UTC to Friday 16:00 UTC. Confirmed block timestamps assign burns to cycles. Permissionless finalization fixes protocol and community accounting after the end time.

SECTION 12

Fan Power

One eligible BF burned through the Burn Router creates one BF of Fan Power for the active cycle. Fan Power is proportional accounting weight, not staking, interest or a permanent multiplier.

Holding BF creates no entitlement. Fan Power resets by cycle, and burning BF is irreversible.

SECTION 13

Fan Vault

Thirty-five percent of Creator Rewards received funds the weekly Fan Vault. Its size follows actual inflows and may be zero.

If the distributable community pool is 3 ETH, total Community Fan Power is 1,000,000 BF and Alice contributed 100,000 BF, her current share is 10% and her estimated Drop is 0.30 ETH. Later burns reduce her percentage; later funding may increase the pool.

SECTION 14

Friday Drop

After finalization, community entitlements equal community pool multiplied by user Fan Power divided by total Community Fan Power. Claims are pulled by eligible wallets.

With a 4 ETH pool and Alice, Bob and Charlie burning 100,000, 300,000 and 600,000 BF, their shares are 0.4, 1.2 and 2.4 ETH. This does not establish profitability because BF was permanently destroyed.

SECTION 15

The Burner

The Burner executes available Burnback value in permissionless six-hour slots. A price guard supplies an authoritative minimum output; user-supplied minimum output cannot weaken that floor. BF output goes directly to The Furnace.

SECTION 16

Burn Loop

Protocol Burnback purchases may create protocol weight in the weekly cycle. ETH attributable to that weight can only return to The Burner, where it buys and burns BF again.

The loop is a destination constraint, not a growth guarantee. It depends on real revenue, execution and market liquidity.

SECTION 17

Loop Cut

The protocol's proportional weekly share is hard-capped at 20% of the funded Fan Vault: Loop Cut = min(protocol proportional share, 20% × funded vault).

The Loop Cut cannot be withdrawn for operations or creator compensation. With no community burns, funding rolls forward instead of being awarded to protocol weight.

SECTION 18

Heat Index

Estimated Drop = current Fan Vault × burn amount / (existing Community Fan Power + burn amount). Heat Index = (estimated Drop / conservative BF value − 1) × 100.

For a 0.30 ETH estimated Drop against BF valued at 0.20 ETH, the simplified value is +50%. It is not APR, APY or promised yield. Participation, vault inflow, Loop Cut, price, liquidity and execution conditions can all change before finalization.

SECTION 19

Top Fans

Five percent of Creator Rewards received funds the calendar-month Top Fans pool. Only the monthly ranking determines V1 Top Fans payouts. Cycle, Quarter, Year and All Time are contextual or historical statistics, not additional pools.

SECTION 20

The Hot 25

The 25 largest eligible monthly burners form The Hot 25. Every occupied rank receives 4% of that month's pool; unused rank allocations roll forward. Equal totals use deterministic address ordering.

Creator, project and protocol wallets are excluded by the immutable deployment denylist.

SECTION 21

Claim System

Friday Drop and Top Fans distributions use pull claims. Finalized entitlements cannot be increased, over-claimed or claimed twice. Recipients may select a compatible claim destination.

SECTION 22

Expired Claims

Weekly claims expire 90 days after cycle end. Unclaimed ETH and residual dust then route exclusively to The Burner for another BF buy-and-burn. They cannot become Creator Cut or operations funds.

SECTION 23

Permissionless Burnback Execution

Any caller may execute an available Burner slot when the protected output condition is satisfied. A separately capitalized and capped bounty may pay the caller without touching Burnback principal.

SECTION 24

Protocol Architecture

V1 separates RevenueRouter, BurnRouter, WeeklyVault, MonthlyTopFans, Burner, Furnace and optional ExecutorBounty responsibilities. External swap and price adapters are explicit integration boundaries.

The launch pool and Creator Reward plumbing are Clanker/Uniswap infrastructure; the 40/20/35/5 routing begins only after net Creator Rewards reach BurnlyFans.

SECTION 25

Trust Model

Contracts are authoritative for balances, eligibility, weights, finalization and claims. Base events are canonical for historical aggregation. The website and indexer improve usability but cannot create entitlement.

Users must trust verified immutable deployment inputs, reviewed adapters, Base, Clanker and Uniswap behavior, and the narrowly scoped pause authority.

SECTION 26

Immutable Core

Allocations, burn destinations, weekly timing, the Loop Cut cap, expiry and Top Fans rules are intended to be immutable after deployment. The planned fair-launch supply configuration must also be verified from the Clanker deployment transaction.

SECTION 27

Security Model

The security council may pause new community burns and Burner execution. It cannot withdraw protocol funds, change allocations, recover burned BF, rewrite historic weights or redirect claims.

Immutability reduces governance discretion but increases the importance of pre-deployment review and correct constructor inputs.

SECTION 28

Risks

Risks include permanent BF loss, price volatility, low liquidity, adverse execution, contract or adapter defects, oracle/TWAP failure, delayed permissionless action, wallet splitting, ranking competition, external Clanker/Uniswap/Base changes and regulatory uncertainty.

Volume and reward examples are illustrative. Creator Rewards, Friday Drops, Top Fans pools and the Heat Index may all be zero.

SECTION 29

Data / Indexing Model

BurnRouter events are aggregated deterministically by active cycle, calendar month, UTC quarter, UTC year and all time. Recent Burns is an indexed convenience view.

The indexer is not the source of truth for accounting and cannot fabricate production transactions or claims.

SECTION 30

Transparency / Verify

Before deployment, all addresses are pending. After deployment, Verify must expose BF, the Clanker pool, launch-supply allocation, reward recipients and every protocol contract with Base explorer links.

The fair-launch claim requires onchain proof of 100% supply in the launch pool and zero team, presale, creator-vault and dev-buy allocations.

SECTION 31

Disclaimer

BurnlyFans is experimental pre-deployment software. Burning BF is irreversible. Rewards depend on actual Creator Rewards and eligible burns, may vary materially and may be zero. Heat Index and volume examples are not forecasts, APR, APY or financial advice.