The memecoin with a US Treasury floor.

00The whole idea in one line

A memecoin you can always redeem for a pro-rata share of a vault of tokenized US T-bills: a redemption floor that can only rise. Equivalently: a machine that converts memecoin trading volume into a real-world asset (US Treasury bills) owned by the holders.

01Abstract

FLOOR is a fixed-supply memecoin (1,000,000,000 tokens, minted once by the Flap launchpad, no mint function) on Robinhood Chainwhose defining property is a hard, on-chain redemption floor. An ownerless vault contract holds SGOV: tokenized 0–3 month US Treasury bills. Any holder may redeem FLOOR at the vault and receive their pro-rata share of that SGOV in-kind, minus a 2% fee that stays in the vault. The Flap token has no burn function, so redeemed FLOOR is locked in the vault forever and the floor is computed over the effective supply: total supply minus the vault’s locked FLOOR. The floor per token, vault SGOV / effectiveSupply, is monotone by construction: every operation the system permits either raises it or leaves it unchanged, and §3 proves this case by case.

The floor is fed by trading. The token is created by the Flap launchpad (flap.sh) and launched on a public bonding curve that graduates to a DEX pool whose liquidity Flap locks. Every pool trade pays a tax: 2% on buys, 4% on sells; plain wallet transfers are untaxed, and the rates are immutable once set. Flap’s protocol keeps 41% of the collected tax after graduation (60% during the curve); 100% of the remainder is paid, as native ETH, to a converter that pays 40% to the launch operator and turns the other 60% into SGOV for the vault under an on-chain dual-Chainlink guard. There is no team allocation beyond the disclosed creator initial buy, no vesting, and no emission. The vault and converter have no owner; the token is a Flap contract, and §4 discloses exactly what that means for trust. The operator’s entire income is the disclosed 40% converter share (§6). The contracts are unaudited at launch (§8); nothing in this paper asks for trust that a contract read cannot replace (§9).

02Background: Robinhood Chain + SGOV

Robinhood Chain (chain id 4663) carries tokenized real-world assets as plain ERC-20s, priced by dedicated Chainlink feeds that update 24/5, following traditional market hours. Among them is SGOV: a tokenized share of an ETF holding 0–3 month US Treasury bills. SGOV is an accumulating asset: T-bill yield is not paid out as a dividend but shows up as slow, steady price appreciation of the share itself. Its Chainlink feed (8 decimals) tracks that price on-chain; on weekends the feed freezes, because the underlying market is closed.

Memecoins on every chain share one lifecycle: launch at zero and, for almost all of them, return to zero, because nothing underneath ever accrues. FLOOR attaches a one-way ratchet to that lifecycle. The ratchet is funded by a real trading tax converted into a real yield-bearing asset, and it is engineered so that the money path never depends on an oracle: redemption is in-kind SGOV, computed from two live balances. A frozen weekend feed can make a UI number stale; it cannot touch solvency. The vault is solvent by construction at every block.

03The mechanism

3.1The vault and the redemption math

FloorVaultV2 has no owner, no pause, no upgrade path, and no parameter setter: the constructor is the entire configuration surface. The Flap token has no burn function, so redemption locks the redeemed FLOOR in the vault forever instead of burning it, and every floor computation runs over the effective supply: total supply minus the vault’s own locked balance. The vault exposes one economic action, redeem(amount, receiver), which computes exactly this (fee = 200 bps, hard-capped at 1,000 bps in the constructor):

Three details carry the design. Effective supply is read before the pull: the redeemer is paid out of the share their own tokens represent, so redemption never over-pays against the post-lock supply. Truncating integer division rounds in the vault’s favor: dust from every rounding stays behind. And no function in the vault’s bytecode can ever move its FLOOR out: the lock is as irreversible as a burn, and the denominator it removes tokens from is the effective supply, so locked tokens can never dilute anyone’s redemption claim. A redeemWithPermit variant does approval and redemption in one transaction; donate() (or a plain SGOV transfer; balances are read live) lets anyone raise the floor for everyone, irreversibly.

3.2The invariant

Write F = V / S, where Vis the vault’s SGOV balance and S is the effective supply: FLOOR’s constant total supply minus the FLOOR the vault has locked. F is denominated in SGOV per redeemable FLOOR; the USD floor shown anywhere is simply F × SGOV price, and since SGOV itself accrues T-bill yield as price appreciation, the USD floor rises even when F stands still. Every state change the system permits falls into one of four channels, and each one moves F in only one direction.

3.3Mini-proof, per operation

Redemption raises the floor. A holder redeems a tokens with fee fraction f (here f = 0.02). The vault pays (V·a/S)·(1−f) and locks a, removing it from the effective supply:

The lock is why the denominator is the effective supply. The Flap token has no burn function, so totalSupply never falls. If the floor were computed over totalSupply, vault-locked tokens would keep counting in the denominator and dilute every remaining holder’s claim forever. Computing over effectiveSupply = totalSupply − vault FLOOR makes the lock exactly as strong as a burn: the tokens are gone from every future computation, and no function anywhere can bring them back.

Tax conversion raises the floor. The converter deposits g SGOV into the vault:

The four channels are exhaustive: the vault has no other outbound path for SGOV, no function anywhere can move the vault’s locked FLOOR, and the token has no mint function. Monotonicity is not a policy; it is the absence of any function that could violate it. The property is additionally exercised by the V2 invariant suite and a full launch-to-redemption pipeline test against forked mainnet state before launch.

04The tax architecture

4.1One tax, charged at the pool

The FLOOR token is a FlapTaxTokenV3, created by the Flap launchpad. Every pool trade pays a tax: 2% on buys, 4% on sells. The tax applies only to pool trades; plain wallet-to-wallet transfers are untaxed. The rates are set at creation and immutable afterward, and the tax carries a fixed duration, also immutable: ours is set to roughly 100 years, effectively permanent, though “effectively” is not “forever” and §8 lists the expiry as a risk. Flap’s processor auto-swaps the collected tax and pays it out as native ETH to the token’s beneficiary, which the launch wires to FloorConverterV2.

4.2The cuts, disclosed: Flap’s 41%, then 40/60

Two parties take a share of the tax, and both are stated here in full. Flap’s protocol keeps 60% of the collected tax during the bonding-curve phase and 41% after DEX graduation; that is the platform’s price, set by Flap, not by us. 100% of the remainder reaches the converter, which routes 40% to the operator wallet and 60% into SGOV for the vault, by immutable constants in verified bytecode. That ratio is stated here, on the tokenomics page, and in the contract source, because it is the deal: the operator is paid in disclosed ETH cash flow (never in tokens), and the constructor caps the operator share at 90% so the floor-feed channel can never be configured below 10%. The rationale is plain: the operator funds the keeper and everything else out of this stream, and an operator paid openly in ETH has no reason to hold, dump, or manipulate FLOOR itself.

4.3Platform trust: what Flap can and cannot do

This design is less trustless than a fully self-deployed stack, and that is disclosed here rather than discovered later. Flap’s Portal and tax processor are upgradeable contracts that Flap controls, and Flap could in principle redirect the tax beneficiary away from our converter, cutting off the floor’s tax feed. Our keeper checks the beneficiary on every run, and this site can read it live; if it ever stops pointing at the converter, that fact is public within one keeper cycle. What Flap can never do, under any upgrade: touch the SGOV already in the vault, move the vault’s locked FLOOR, or block redemption, which is a direct in-kind transfer from an ownerless contract. The worst case of a hostile Flap is a floor that stops growing through the tax channel, never a floor that falls.

4.4The converter guard and the no-approvals argument

FloorConverterV2receives the post-cut tax stream as native ETH. On each primary conversion it pays the operator’s 40% off the top, then converts the remainder to SGOV, which is force-forwarded to the vault in the same transaction; SGOV has no other exit. The primary path is a keeper-triggered swap through a single 1inch router address pinned at deploy. The keeper supplies calldata but never touches funds: the contract itself holds the ETH, calls the pinned router, measures the SGOV it actually received, and reverts the entire transaction unless the fill clears an on-chain, dual-Chainlink value check:

The quiet part of the design is what does not exist: token approvals. The input is native ETH, so there is no allowance anywhere for hostile router calldata to exploit; the worst any calldata can do is produce a bad fill, which the oracle check rejects. A fully compromised keeper key is bounded to at most 3% slippage on one conversion per hour, and can steal nothing. If the keeper goes silent for 30 days, a fallback path opens permissionlessly: anyone can push queued ETH through two Uniswap v4 legs (ETH→USDG→SGOV) under the same oracle check, so a lost key or a dead router can never permanently strand the floor’s tax stream. The fallback pays no operator share: if the keeper is dead, everything goes to the floor. The converter has no owner, no withdraw, and no upgrade.

05Launch

The launch is sequenced so that nothing tradeable exists before the floor does. First, FloorVaultV2 and FloorConverterV2 are deployed and their source verified on Blockscout, with nothing tradeable and nothing at risk. Then a single Flap Portal transaction creates the token:

• Creation, via Flap. The Portal mints the fixed 1,000,000,000 supply and opens the public bonding curve, with the 2%/4% tax and its ~100-year duration fixed at creation and the tax beneficiary wired to the converter. The only launch-day position is the disclosed creator initial buy (planned: 0.001 ETH, a launch-day choice), made on the same curve at the same price available to anyone in the same block.
• Graduation, by Flap. When the curve reaches its threshold, Flap migrates the token to a DEX pool and locks the liquidity. Neither the operator nor any FLOOR contract ever custodies the pool.

What deliberately does not exist: team token allocation (none beyond the disclosed creator buy; the operator is paid in disclosed ETH cash flow), vesting (nothing to vest), token treasury (none), staking emissions (the redeemable supply only ever shrinks).

Sniping: the disclosed reality.A public launch will be bought in-block by bots; recent launches on this chain were, and FLOOR’s will be too. This is disclosed rather than fought, because the design itself taxes fast flippers three ways: every sell pays the 4% tax (which, after Flap’s cut, feeds the floor), every exit through the vault pays the 2% redemption fee to remaining holders, and the graduated liquidity they trade against is locked by Flap. Snipers accelerate the ratchet; they cannot break it.

06What the operator earns

Full transparency, in one table. This is the operator’s complete economic relationship to the protocol, enforced by immutable constants:

For scale: of every dollar of tax the token collects after graduation, Flap keeps 41 cents; of the remainder, the operator receives 40% and the vault 60% (before conversion slippage, which the oracle guard caps at 3%). The exact per-scenario figures live in the published economic simulation (§7) rather than here, because a disclosed cash-flow deal that never touches the token is the point of the design, not any particular revenue projection.

07Economics (simulation)

The repository ships a deterministic daily-step simulator (sim/floor-sim.mjs; run it yourself). Its assumptions (market prices, volume regimes, buy/sell mix, realized conversion slippage, the tax and cut parameters as deployed) are stated in the file and printed with every run. They are assumptions, not predictions; every figure the simulator produces is a simulation output, not a projection or a promise, which is why this paper points at the simulation instead of quoting its numbers as if they were facts about the future.

The floor starts near zero. Say it plainly. The launch puts no SGOV in the vault: the vault fills only from the post-cut tax stream, so on day one the floor is effectively zero and the per-token numbers stay small against a 1,000,000,000 supply for a long time. What the mechanism guarantees is never the level, only the direction.

The direction holds in every simulated scenario. Across the simulated regimes (modest launch, heavy hype, dead market, and a death-spiral mass exit), the floor is monotone non-decreasing at every daily step. The death-spiral case is the one that matters: even when a large fraction of the supply redeems in days, the floor rises through the event, because every exit pays the 2% ratchet to those who remain and locks the redeemed FLOOR out of the denominator. A bank run makes remaining holders richer per token. That is the entire point of the design, observed in simulation and enforced by the §3 algebra; the scenario-by-scenario figures are in the simulator’s output.

source: node sim/floor-sim.mjs · stated assumptions · simulation, not a forecast

Above the floor, the market price is whatever the market decides; the floor is a lower bound, not a valuation. The honest framing: FLOOR is a memecoin whose downside terminates at a small but strictly rising number instead of at zero.

08Risks

• Unaudited at launch. The contracts carry a test suite (unit, invariant, and a full fork-of-mainnet pipeline test of create→trade→graduate→convert→redeem), but no external audit at launch. Verified source is not a substitute for one. The immutability that protects holders also means a shipped bug can never be patched.
• Platform dependence: Flap.The token contract and the tax routing belong to the Flap launchpad. Flap’s Portal and tax processor are upgradeable contracts under Flap’s control, and Flap could in principle redirect the tax beneficiary away from our converter, halting the floor’s tax feed. Our keeper checks the beneficiary on every run and this site can read it live; SGOV already in the vault, the locked FLOOR, and redemption itself are beyond Flap’s reach. Still, this is a real reduction in trustlessness versus a fully self-deployed design, and it is permanent.
• The tax expires. The 2%/4% trading tax carries a fixed duration set at creation: roughly 100 years, effectively permanent but not literally forever. After expiry the tax channel stops, and the floor grows only from redemption fees, SGOV yield, and donations. Expiry can never lower the floor.
• Thin, young chain. Robinhood Chain is new: liquidity is shallow, explorer indexing lags, tooling is immature, and the chain has a demonstrated copycat problem: verified-but-fake tokens and routers imitating real ones. Only addresses published on this site are canonical. In-block sniping of the launch is expected (§5).
• SGOV issuer and regulatory exposure. The floor is denominated in a tokenized security: economic exposure only, no shareholder rights, jurisdictional restrictions, and an issuer that retains conventional issuer powers over the token. Regulatory action against tokenized treasuries, the issuer, or the chain could impair what a redeemed SGOV token is worth or whether it can be used. The vault guarantees delivery of SGOV tokens, not what SGOV itself will be.
• Oracle freezes and the keeper. Chainlink feeds on this chain freeze on weekends; the converter tolerates 4 days of staleness and simply queues ETH when it must wait. Redemption never touches an oracle. The keeper is a single operator-run key: its compromise is bounded to 3% slippage per hourly conversion, and its death is covered by the 30-day permissionless fallback. But until that window opens, conversion cadence depends on the operator.
• Reflexivity of tax revenue.The floor’s growth is a function of trading volume, and memecoin volume is attention; it can die. If it does, floor growth decays toward just the T-bill appreciation on SGOV already vaulted plus the redemption ratchet. The invariant holds in a dead market; the growth rate does not.
• Level vs. direction.The floor starts near zero and may stay far below the market price indefinitely. It bounds the downside above zero; it does not make FLOOR “backed” at its trading price, and everything paid above the floor is speculation.
• Dependency risk.The system builds on Flap’s launchpad contracts, the DEX pool the token graduates to, Uniswap v4’s PoolManager (fallback path), OpenZeppelin libraries, Chainlink feeds, and (primary path only) the 1inch router. A defect in any dependency is a defect in FLOOR.

09Verify everything

Every load-bearing claim in this paper is a contract read, an event log, or an absence you can check in verified source. At launch, the contract addresses are published on this site (until then they are null in the site’s own source, and every live surface reads “opens at launch”, the same no-fabricated-numbers rule this paper follows).

• The floor only rises: read vault.floorPerToken() at any two blocks; the later read is never smaller.
• The lock is real: watch vault.effectiveSupply() fall with every redemption while floor.totalSupply()stays constant; the difference is the FLOOR locked in the vault, and the vault’s verified source has no function that can move it.
• The liquidity is Flap-held, then Flap-locked:the bonding curve and the graduated DEX position live in Flap’s contracts, never in an operator wallet. Check the token’s holders and the graduation transaction on the explorer.
• The split is 40/60:an immutable constructor constant in FloorConverterV2’s verified source, and every Converted event carries the actual amounts routed.
• The tax still points at the floor:read the beneficiary on Flap’s tax processor for the token; it should be the converter. The keeper checks this every run, and this site can read it live.
• The launch was clean:the creation transaction shows the full supply minted to Flap’s curve, with the disclosed creator initial buy as the only launch-day position.

The /proof page operationalizes this. At launch it runs the public proof sequence and links each claim to its transaction hash: a buy, a sell (honeypot disproof), a conversion with the 40/60 split visible on-chain, and a live redemption that locks FLOOR for SGOV. Explorer: robinhoodchain.blockscout.com; the SGOV token and feed addresses used by the protocol are pinned in the site source from canonical registries, never from explorer search.

Nothing in this paper asks for trust. Every claim is a contract address and a function you can call, and until launch, it is a repository you can read.