Security at FNC Token
A small, non-upgradeable on-chain surface plus an honest custodial trust model. Locked token, hard cap, owner-gated redemption — and reserves held off-chain with published proof. Every guarantee, every audit status, and how to report a vulnerability.
External audits
On-chain surface — locked token, NAVRegistry, RedemptionEscrow
Scheduled: Q3 2026Cross-review — NAV clamp / staleness fail-closed + redemption settlement
Scheduled: Q4 2026No audits complete yet — this is testnet.
FNC is currently live on Sepolia testnet. Tokens have no monetary value. Mainnet deployment will not proceed until both audit firms have signed off and all reported issues are remediated.
Hard guarantees.
FNC is an ERC-20 + EIP-2612 Permit + Burnable token with a fixed 21,000,000 supply minted once. Minting is renounced — no new FNC can ever be created.
MAX_SUPPLY = 21_000_000e18 · minter renounced · totalSupply frozenStandard ERC-20 transfer logic. No transfer fee, no blocklist, no flag that disables transfers. FNC is transferable by holders forever.
no fee-on-transfer · no blacklist · transferable foreverThe token, NAVRegistry, and RedemptionEscrow are deployed final. No UUPS / Transparent / Beacon proxy. The bytecode on Etherscan is the bytecode forever.
no upgrade slot in storage · non-upgradeable contractsThe operator posts NAV to the NAVRegistry. Posted values are clamped to bounded per-update moves, and if the NAV is stale, the registry reports not-fresh so redemption settlement halts rather than paying on bad data.
NAVRegistry.navFresh() gates redemption · clamp on postNAVRedemption egress is owner-gated and runs in a manual window, but holders can always cancel a pending request and keep their FNC. The escrow can never trap your tokens.
RedemptionEscrow.cancel() · egress requires operator signerRedemptionEscrow settles FNC→USDC at a flat floor (0.97 × NAV). Redeemed FNC is burned at settlement, reducing supply and lifting NAV per token for everyone who remains.
floorBps = 9700 · FNC burned on settle()Custodial, and honest about it.
FNC is custodial, not trustless. The on-chain contracts (token, NAVRegistry, RedemptionEscrow) are small and non-upgradeable, but the reserves that back FNC are held off-chain by the operator. Your protection comes from operator-backed reserves plus published proof-of-reserves — not from a claim that the backing lives entirely on-chain.
- ›Off-chain treasury custodyReserve assets (Bitcoin, stablecoins, yield) are held in operator custody. For mainnet, custody moves to a multisig (3-of-5) so no single key controls the reserve.
- ›Proof-of-reservesThe operator publishes proof-of-reserves and posts the resulting NAV on-chain to the NAVRegistry, so anyone can compare the floor against the backing.
- ›Owner-gated egress, holders freeOnly the operator signer can settle redemptions and move reserve assets. Holders can always cancel a pending redemption and keep their FNC — the escrow never traps tokens.
- ›Small audited on-chain surfaceThree contracts, no governance, no DAO, no proxy. Less code on-chain means a smaller attack surface and a tractable audit.
A bug bounty program will launch on Immunefi alongside mainnet deployment. Until then, please report findings via responsible disclosure below.
Report a vulnerability
If you discover a security issue, please report it privately. Do not open a public issue or post about it on social media until we've had a chance to acknowledge and triage.
What to include
- ·Detailed description of the vulnerability
- ·Step-by-step reproduction (PoC code if applicable)
- ·Affected contracts / addresses / commit hash
- ·Your assessment of severity and impact
- ·Optional: how you would fix it
We commit to acknowledging your report within 48 hours and providing a triage status within 5 business days.