Fledge is a trust-first launchpad. This page states — plainly and
without spin — exactly what security work has and has not been done, so you
can judge for yourself. We would rather under-claim than mislead.
Every contract Fledge deploys has its
exact source published — you can read the
precise code before you deploy or buy. The five reviewed contracts, verbatim:
Note: the operator contracts are not yet deployed to Robinhood
Chain mainnet — they deploy at the token launch. On deployment, their source will
be verified on Blockscout so the on-chain bytecode is independently checkable
against the reviewed source, and we will link the verified addresses here.
Every contract was put through a dual, independent AI adversarial review:
two separate models — Anthropic's Claude and xAI's Grok — each reviewed
each contract cold and independently, prompted to attack it rather than bless
it. Findings were reconciled against the code, fixes were applied, and each contract
was re-reviewed until both passes were clean. Because the two models have different
training and different blind spots, agreement between them is a stronger signal than
either alone.
No High- or Critical-severity issue was found in any contract, at any stage.
The residual findings were Low/Informational; the exact change made for each is logged
below.
| Contract | Claude | Grok | Status |
|---|
LaunchToken.sol | ✅ pass — fixes applied | ✅ confirmed | Cleared |
BuybackBurn.sol | ✅ pass | ✅ confirmed | Cleared |
TokenLock.sol | ✅ pass — hardened | ✅ confirmed | Cleared |
FledgeStaking.sol | ✅ pass — hardened | ✅ confirmed | Cleared |
FledgeFeeLocker.sol | ✅ pass | ✅ confirmed | Cleared |
Findings & fixes, per contract
LaunchToken.sol
Launch-fee handling + input validation
The constructor now charges
only the exact launch fee and
refunds any
excess — and because the fee is zero unless a treasury is configured, a no-fee
deploy refunds the full amount rather than stranding ETH. Added a
decimals ≤ 18 bound, moved all input validation ahead of the
external calls (strict checks-effects-interactions), and added a
FeeConfigured event. Grok re-reviewed the reordering and confirmed it.
BuybackBurn.sol
MEV bounded by immutable parameters
No code defect: the core invariant —
ETH can only ever leave as burned $FLEDGE
(no owner, no withdraw) — holds. The one finding was that the public buyback is
sandwichable; its magnitude is bounded by the immutable per-call spend cap and
cooldown. These are set
conservatively (
maxEthPerCall ≈ 0.5% of
pool depth, with a cooldown) so a single buyback moves the price only fractionally
and MEV is uneconomic.
TokenLock.sol
Non-standard-token safety + bounded views
Two Medium findings, both resolved. The claim payout is now
capped at the
contract's actual balance, so a rebasing or fee-on-transfer token can never
revert-and-strand a lock. Added
paginated view getters so a token spammed with
many locks can't gas-DoS the "% locked" trust badge (the unbounded views are
documented as off-chain-only). The vesting comment was also corrected — the behaviour
(a step unlock at the cliff) was already correct and matches the published schedule.
Grok re-reviewed and confirmed both resolved.
FledgeStaking.sol
Overflow guard on lock/emission windows
Solvency was confirmed by both reviewers — principal is 1:1 redeemable and rewards can
never exceed what was funded — and the lock defeats flash-stake reward theft. The one
Low finding (a
uint64 timestamp truncation on absurd durations) was
closed with a
MAX_DURATION (10-year) bound on lock and emission windows.
Grok re-reviewed and confirmed.
FledgeFeeLocker.sol
Minimal by design — no change needed
Both reviewers verified every invariant: principal can never be reduced, the position
NFT can never leave, the fee recipient is immutable, and there is no owner. The two
Low items (an unsafe-
transferFrom footgun, and depositor-chosen recipient
reachability) are documented and depositor-controlled. Deliberately
no recovery
code was added: any such path would reintroduce a fee-redirect surface and weaken the
guarantee — the contract's safety is its minimalism.
Property-based (fuzz) testing
Beyond the manual review, the reward-math and core token/lock contracts carry a
Foundry fuzz / invariant suite. The critical properties were machine-checked
across thousands of randomized operation sequences (with time warps):
- FledgeStaking — solvency: the contract can always
repay every staker's principal plus accrued rewards, and rewards can never dip
into principal; plus per-pool principal accounting. Held, 0 failures.
- TokenLock — no beneficiary can over-claim, nothing vests before the cliff,
and the contract stays solvent for the unclaimed remainder. Held.
- LaunchToken — supply is never inflated, the transfer tax is exact and capped
at 1%, and mint/burn are never taxed. Held.
- BuybackBurn — fork test against the real Uniswap V2 on Robinhood Chain:
ETH can only ever leave as tokens bought and burned to the dead address, within the
immutable per-call cap, and the cooldown is enforced. Held.
- FledgeFeeLocker — fork test against the real Uniswap V3 position manager:
a live position's fees flow to the immutable recipient while its principal liquidity
stays untouched and the NFT never leaves the locker. Held.
All five contracts now carry property-based or fork tests. The remaining
pre-launch item is the independent third-party audit (section 4).
These reviews were performed with AI assistance as rigorous internal
hardening. Two independent models is a strong cross-check, but it carries no independent
accountability and does not replace a third-party audit — see the banner above and
section 4.
Ahead of the dual-AI review, we completed a line-by-line internal review of the launch
contracts and ran
Slither static analysis over them.
- No critical or high-severity issues found. The contracts are ownerless and
immutable by design: no owner key, no mint-after-deploy, no blacklist, no pause, no
admin withdrawal. Any transfer tax is hard-capped at 1% and can never be changed.
- Slither surfaced a few low-level items — all benign false positives, each
explained in the full write-up.
- The largest residual is deploy-time correctness (verifying constructor
addresses at launch), handled by a launch-day checklist.
Read the full internal review, findings and all:
Internal contract review (2026-07).