← Back to Fledge
Fledge: A Transparent, Non-Custodial
Token Launchpad for Robinhood Chain
Whitepaper v0.1 — Draft
The Fledge Team
July 2026  ·  fledge.fun  ·  @fledgefun
Abstract

Fledge is a transparent, non-custodial token launchpad for Robinhood Chain. It lets anyone deploy a standard, fixed-supply ERC-20 whose safety is guaranteed by construction: no owner key, no mint after deploy, no blacklist, no pause, and any transfer tax hard-capped at 1% and immutable — a "99% can't-sell" honeypot is impossible to build on Fledge. The token is deployed from the creator's own wallet; the platform never holds a private key. Every contract's exact source is published and verifiable, creators are encouraged to burn their liquidity (provable on-chain), and team/treasury allocations lock in a non-custodial vesting contract with no early exit. Fledge is funded by a small launch fee that flows to a trustless buy-back-and-burn contract for the platform's own $FLEDGE token. It is the deliberate opposite of a bonding-curve casino: no bundling, no hidden owners, no dumpable surprises — a launchpad built to still be standing, and trusted, in five to seven years.

Contents
  1. Introduction
  2. System Overview
  3. The Launch Standard
  4. Non-Custodial Deployment
  5. Liquidity, Locks & Trust Signals
  6. Fees & the Buyback Flywheel
  7. The $FLEDGE Token
  8. Staking
  9. Security & Transparency
  10. Integrity Doctrine
  11. Roadmap
  12. Risk Disclosure
  13. Team

1. Introduction

Token launchpads have a trust problem, and it is largely self-inflicted. The dominant model rewards speed and spectacle — bonding curves, bundled buys that disguise one wallet as a crowd, hidden owner functions that can tax, freeze or rug holders after the fact. The people who get hurt are the ordinary buyers the spectacle was designed to attract.

Fledge's thesis is that the durable launchpad is the honest one. Instead of competing on how fast a token can pump, Fledge competes on what a buyer can verify before they act: that the supply is fixed, the source is published, the owner cannot change the rules, the tax cannot exceed 1%, and the insider allocations are locked on-chain. None of these are promises to trust — they are properties of the contract, readable by anyone.

The second half of the thesis is non-custody. Fledge never asks a creator to hand over a key. Deployment is a transaction the creator signs from their own wallet; the platform is a front-end and a set of open contracts, not a vault. This is the same discipline that governs its sister project, the Chirp trading bot — and the reason both can make the trust claims they do.

2. System Overview

ComponentRole
fledge.funPublic launchpad: deploy, verify, add/burn liquidity, lock, discover
LaunchTokenThe anti-honeypot ERC-20 template every creator deploys (Section 3)
Deployment flowCreator signs from their own wallet; the platform holds no keys (Section 4)
TokenLockNon-custodial vesting/lock for team, treasury, or any creator's bag (Section 5)
BuybackBurnTrustless buy-back-and-burn contract funded by launch fees (Section 6)
FledgeStakingOn-chain, non-custodial lock-to-participate contract (Section 8)
Discover / registryPublic, verifiable index of every token launched via Fledge

Fledge deploys onto Robinhood Chain, an Arbitrum-technology L2 with a fair-markets ethos and near-zero fees. All trading liquidity uses the canonical Uniswap deployment on that chain; the launchpad's helpers appear only where a real router is configured and degrade gracefully everywhere else, so a token is never deployed against a phantom venue.

3. The Launch Standard

Every token deployed through Fledge is an instance of LaunchToken — a standard OpenZeppelin ERC-20 with a single, tightly-bounded extension. Its safety properties are structural, not promised:

PropertyGuarantee
Fixed supplyMinted once in the constructor; there is no mint function. Supply can only ever fall (via burns), never rise
No ownerThe contract is ownerless. There is no admin, no setter, no privileged address of any kind
Immutable taxThe transfer tax, its mode, recipient and split are set once in the constructor and marked immutable — no one can change them after deploy
1% hard capThe tax is capped at MAX_FEE_BPS = 100 (1.00%) at the contract level. A high "can't-sell" tax will not compile into a deployable token
No blacklist, no pauseThere is no function to freeze, block or trap a holder. Anyone holding the token can always move it

The tax, when a creator enables it at all, has four honest modes — None, Burn (the whole tax is burned, deflationary), Recipient (the tax goes to a fixed address), and Split (divided between burn and recipient by a fixed share). The initial holder and the fee recipient are exempt so that seeding liquidity and collecting fees are never self-taxed. Because all of this is fixed at construction with no setter, what a buyer reads in the verified source is what the token will do forever.

4. Non-Custodial Deployment

Fledge holds no private keys, ever. A creator connects their own wallet, the platform assembles the constructor arguments, and the creator signs and pays for the deployment transaction themselves. The resulting token is owned by no one; the creator simply holds the initial supply as a normal balance.

This is a deliberate architectural choice, not a convenience gap. A launchpad that custodies keys — for "easier" deployment, for a server-side vault, for automated liquidity — is a launchpad that can be compromised, coerced, or tempted. Fledge removes that surface entirely: there is no key to steal because there is no key. The trade-off is that a creator needs a self-custody wallet and a small amount of ETH for gas; the payoff is that no Fledge operator can ever move a creator's tokens or a holder's funds.

5. Liquidity, Locks & Trust Signals

A safe token contract is necessary but not sufficient — the liquidity behind it matters just as much. Fledge makes both legible:

Together these separate the two things a rug needs — pullable liquidity and a dumpable insider bag — and put both under public, on-chain scrutiny.

6. Fees & the Buyback Flywheel

Fledge charges a small ETH fee per launch. That fee is committed, in full, to a trustless BuybackBurn contract — an ownerless contract with no admin key and no withdrawal function. ETH that enters it can only ever leave one way: swapped on Uniswap for $FLEDGE and sent to the dead address.

Launch on Fledge → ETH fee → trustless BuybackBurn (no owner, no key) → market-buys $FLEDGE → burned. More launches → more burns → scarcer $FLEDGE.

The contract is hardened against value extraction: each buyback spends at most a fixed per-call cap and calls are separated by a cooldown, both immutable, so the ETH held can only be converted to burned tokens at a bounded rate — while the contract stays fully ownerless. This is the entire value engine, and every other design decision is constrained to not undermine it: launch fees are never spent twice, and staking rewards come from a finite pre-funded pool, never from the fee flow.

7. The $FLEDGE Token

$FLEDGE does not exist yet. No contract address has been published; anything sold as $FLEDGE today is counterfeit. The official address will appear only on fledge.fun and the official X account, simultaneously, at launch.

PropertyValue
Ticker / standard$FLEDGE — ERC-20, Robinhood Chain
Total supply1,000,000 — fixed, no mint after deploy
Transfer taxNone
Launch standardDeployed on Fledge itself: verified source, fixed supply, LP burned
Value mechanismLaunch fees → trustless buy-back & burn

$FLEDGE is the flagship example of an honest launch — the platform's own token, launched through the platform, held to the same standard every creator is.

7.1 Allocation

BucketShareTreatment
Liquidity (fair launch)40%Seeds Uniswap, LP burned
CEX & additional DEX LP12%Usage-gated — released only when actually deployed to a listing / new pool, each disclosed on-chain
Staking rewards17%Finite pool, decaying emission (Y1 40 / Y2 30 / Y3 20 / Y4 10)
Treasury / ecosystem14%3-year linear vest, on-chain lock
Team10%1-year cliff, then 4-year linear vest (fully vested Year 4)
Community / marketing7%18-month linear vest

Fledge is a 5–7 year project, and the vesting reflects that — but selectively, to avoid the low-float / high-FDV unlock-overhang trap that a blanket multi-year lock creates. Insider supply (team, treasury, community — 310,000 tokens) time-vests on-chain through TokenLock with no owner and no early exit. The CEX/DEX bucket is usage-gated rather than time-locked, so a real listing can be seized in year one without a lock that would have to be broken. Staking is a decaying finite emission, not a team vest. Every non-liquidity bucket is locked, vested or usage-gated on-chain and publicly verifiable — nothing can be dumped by surprise.

8. Staking

Fledge's staking is on-chain and non-custodial — tokens are locked in the contract, rewards are claimed on-chain, and no server ever holds a key. It offers four lock pools (1 month, 6 months, 1 year, 3 years), each with a finite reward allocation drawn from the 170,000-token staking bucket, longer locks funded more heavily. Rewards accrue pro-rata to a staker's share of their pool and are claimable at the end of the lock; there is no early withdrawal except a user-initiated, principal-only emergency exit that forfeits rewards. The pool is a one-time finite distribution funded by an add-only distributor with no owner withdrawal — after it empties, only burns continue. It is deliberately not funded from launch fees, which are committed entirely to the burn.

Framing and legal note. "Stake for yield" is the strongest securities signal in this design. Fledge intends to present staking as lock-to-participate (priority, discounts, governance) rather than a yield promise, and will seek legal counsel on marketing framing before staking goes public. Nothing here is a promise of profit.

9. Security & Transparency

Every Fledge contract is open-source, and its exact source is published. The launch contracts (LaunchToken, BuybackBurn, TokenLock) have undergone an internal line-by-line review plus Slither static analysis, which found no critical or high-severity issues; the review and the reasoning behind each low-level finding are published on the security page.

An independent, third-party audit is planned before the $FLEDGE token launch, and the auditor's full report will be published when complete. Until then, Fledge does not describe its contracts as "audited." When the contracts are deployed to mainnet, their source will be verified on Blockscout so the on-chain bytecode is independently checkable. The honest, current status always lives at fledge.fun/security.

9.1 Audit Scorecard

Every launch contract undergoes a dual, independent AI adversarial review: two separate models (Anthropic's Claude and xAI's Grok) each review the contract cold and independently — prompted to attack it, not to bless it — and their findings are then reconciled, fixes applied, and the contract re-reviewed until both passes are clean. Because the two models have different training and different blind spots, agreement between them is a stronger signal than either alone, and any disagreement is investigated against the code.

To be precise about terms: this is a dual-AI review, not a formal third-party audit. It does not replace the independent audit planned before the $FLEDGE token launch (§11) — it catches and fixes issues early and shows our work. We do not call the contracts "audited" until that third-party audit completes. The scorecard reflects live progress and is updated as each contract clears both passes.

ContractClaude (adversarial)Grok (independent)Status
LaunchToken.sol✅ pass — fixes applied & re-reviewed✅ confirmedCleared
BuybackBurn.sol✅ pass✅ confirmedCleared *
TokenLock.sol✅ pass — hardening applied & re-reviewed✅ confirmedCleared
FledgeStaking.sol✅ pass — hardening applied & re-reviewed✅ confirmedCleared
FledgeFeeLocker.sol✅ pass✅ confirmedCleared

* BuybackBurn is code-cleared by both reviews (ownerless; ETH can only ever exit as burned $FLEDGE). Its only material exposure is bounded MEV on the public buyback, whose magnitude is set by the immutable maxEthPerCall cap — chosen conservatively relative to live pool depth at deployment.

No High- or Critical-severity issue has been found in any contract. Low/Informational findings — and the exact fix applied to each — are published on the security page. The funds-holding and reward-math contracts (BuybackBurn, FledgeStaking) additionally receive property-based (fuzz / invariant) testing, and every contract is covered by Slither static analysis, before mainnet.

9.2 Testnet Verified

Every contract is deployed to the Robinhood Chain testnet and exercised end-to-end on a live chain before it is deployed to mainnet. Testnet verification confirms a contract behaves as specified and that its intended and basic adversarial paths work — it complements, and does not replace, code review and audit.

Testnet verification covers, per contract:

The current per-contract testnet status, addresses and block-explorer links are published on the security page — that page, not this document, is the live source of truth for what is deployed today. On mainnet, each contract's source is verified on Blockscout so the on-chain bytecode is independently checkable against the reviewed source.

10. Integrity Doctrine

What Fledge will never do, as a permanent, written boundary:

Fledge's sister project, the Chirp trading bot, runs a safety report that detects these exact patterns in tokens across the chain. Fledge does not sell both the disease and the cure.

11. Roadmap

Roadmap items are never removed — completed items are ticked and stay, so this section doubles as a public record of what was promised and delivered.

Phase 0 — Platform live (current)

Phase 1 — Hardening & audit

Phase 2 — $FLEDGE launch

Phase 3 — Ecosystem

12. Risk Disclosure

13. Team

ElfDev — Founder & Developer
Python/backend developer with experience in blockchain systems, launchpad and DeFi infrastructure. Builder of the Chirp trading bot for Robinhood Chain and Aster Pilot, a live algorithmic trading system. Fledge is self-funded through its early phase.

Contact: support@fledge.fun  ·  X: @fledgefun