How to use this model

This is a conditional scenario model: it answers “If these launch settings and demand assumptions hold, what follows?” It does not estimate how likely that demand is. A higher target market cap produces a different scenario; it is not evidence that the fund can reach it.

1. Launch. Name your fund and set its fees and starting liquidity in the same settings list as the Launch page, starting from the same defaults: 1 USDG against 100,000 pool tokens and 1,000 for you, a 1% swap fee paid to the fund and a 0.5% mining fee to your wallet. The two fees are independent: you can take swap fees with no mining fee, or a mining fee while the fund keeps swap fees. The model prices everything in USDG and keeps the launch defaults for the rest: manager-led allocation, buying its own liquidity, no allocation rewards and automatic auction prices.
2. Supply. Pick a mining schedule: the same five coins as the Launch page (Kaspa, Monero, Dogecoin, Ethereum and Bitcoin) at their real speed, or Custom. See Mining schedules.
3. Demand. Pick a real token from LONG or Pons whose buyers and sellers your fund gets day by day (Demand from real tokens). Real tokens have 12 to 93 days of history. After that, net money is your choice beside the outcome: no new money (the default), the token's recent trend, or steady buying of $10K, $50K or $250K a month. Trading carries on at the token's recent pace.
4. Read the outcome. Below the form, pick the period (the token's own recorded days, or 1, 3, 5 or 10 years) and how much of what they mine miners sell; the outcome updates as you change them. It shows market cap, treasury, backing per token, creator earnings, token price, supply and trading volume at the end of the period, with ranges from 100 alternative histories; one chart with a tab for each, with the real token's own market cap, treasury and creator earnings drawn alongside for as long as its history runs (pick the token's days as the period to compare them closely). The fund's market cap will usually be far below the token's: the launchpad's is mostly supply minted at launch for free and priced at the last trade, while the fund's supply is mined and paid for. Compare treasuries to see where the money went. A large market cap or gross mining payment is not cash earned by the creator.
5. Save and compare. Download each scenario or copy its link. Change one assumption at a time to understand its effect, then combine adverse assumptions to see where the design stops meeting your objectives.

The calculator does not launch a fund, connect a wallet or change a saved launch draft. Review a shared scenario before treating it as your own. Expand Detailed forecast & CSV for the daily, monthly or yearly table; Show all forecast columns reveals the detailed revenue breakdown.

Mining schedules

A fund's Mine fixes its schedule at launch. The initial rate can be 0.01 to 1,024 tokens a second, the halving interval 7 to 1,460 days (four years), and the tail rate from 0.001 tokens a second up to the initial rate. A tail equal to the initial rate is a constant rate: halvings have no effect.

The five schedules are the Launch page's coins at their real speed. Ethereum follows Ethereum Classic's 20% cuts every two years, which halve issuance about every six and a half years; its halving is held at the four-year maximum. Their rates were chosen for a 300,000,000-token genesis (270M pooled, 30M to the creator); on a smaller genesis the same rates mine many times the starting supply.

A schedule sets the three rates only, as on the Launch page; your liquidity and fees stay as you entered them. Custom keeps the current rates to edit; editing any rate also selects it.

What is chosen, assumed and calculated

• Launch choices: seed liquidity, paired tokens, creator tokens, emissions, halving period, tail, fees and buying allocations. These are parameters the creator chooses; changing them changes the design being tested.
• Future behavior assumptions: the target or annual growth path, monthly market-cap edits, turnover, pool volume share, miner economics, asset prices and withdrawals. These are uncertain inputs; the model does not establish them from launch settings.
• Historical benchmarks: Donut takeover timing and net mining cost relative to mined-token market value. These observations from an earlier experiment inform editable assumptions.
• Calculated outputs: token price, takeovers, fees, treasury, supply and annual issuance. These follow from the chosen inputs and the approximations below.

Buying allocations direct future revenue; they do not continually rebalance existing treasury holdings. Nothing is held at launch.

Demand from real tokens

Instead of inventing a market-cap path, you can give your fund the demand a real token actually had. Twelve tokens launched on LONG and Pons, both on Robinhood Chain, are included, each paired with the asset its pool trades against: winners (AI on NVDA, BONER on HIMS, MEME on AMC, SHROOM on MU), typical outcomes (SCHIFFY and UBIK on GLD, STRATEGY on MSTR, OPTIMUS on TSLA, NASDANQ on QQQ, RKST on SPCX, microduck on NVDA) and a fade (SPACEHOOD on SPCX). The model opens on OPTIMUS, a mid-pack token, rather than a best case.

Your fund gets the token's real buyers and sellers: each day's net money (dollars bought minus dollars sold in its main pool) goes through your fund's own pool. Everything else trades through the same pool: miners selling what they mine, liquidity auctions buying the token half of new liquidity, and arbitrageurs buying below backing to withdraw. Price is whatever the pool says. After the history ends, net money is an assumption you choose:

• No new money (default): buyers and sellers stop adding or taking out money. This is already kinder than most tokens' own trend: nearly all net buying arrived in their first 30 days, and by the end of their histories most were being net sold.
• Recent trend: the token's average net money a day over its last 30 days continues. For most tokens that is steady net selling, the pessimistic case.
• Steady buying: $10K, $50K or $250K a month of net buying, spread evenly. Use it to see how much ongoing demand the fund needs to hold up.

In every case trading continues at the token's recent pace (the median of its last 14 days), and sellers can only sell tokens held outside the pool, fund and creator grant.

This is the same money, not the same market cap. A launchpad token's market cap is many times the money its buyers put in: $AI reached $79.6 million on $0.61 million of net buying, because most of its supply was handed out at launch and never paid for. A fund's supply is almost all mined, miners pay for every new token, and holders can withdraw, so its market cap stays close to the money inside it. Expect a fund to be valued at a fraction of the token's market cap while holding far more real backing.

The forecast shows the fund at the end of that history, with ranges: treasury, backing per token against price, creator earnings, swap fees and mining payments with the share that reached the treasury, and new supply. See The calibrated market model for the measurements behind each step.

What carries over and what does not:

• Trading activity uses each token's main launch pool only (for SHROOM, its SHROOM/USDG pool), because a fund trades and earns fees in its own pool. Many of these tokens also trade in dozens of other pools, much of it arbitrage; AI's launch pool carries roughly 8% of its total volume, so this is conservative. Every swap in those pools is also in the snapshot as daily buys and sells, shown for context.
• Mining never existed for these tokens. Miners' bids use the model's Donut-calibrated mining assumptions.
• Supply follows your preset's emissions, so token prices are not comparable; compare market caps, treasuries and earnings.
• History is short: Robinhood Chain launched on July 1, 2026, so histories run from 11 days (NASDANQ, launched October 9) to 92 days. Some early LONG pools are missing their first days, and Pons V2 tokens start at bonding-curve graduation. Market caps use each token's supply at retrieval, so early caps can be slightly understated where tokens were later burned.
• Survivorship: every token here gained real traction. Most launches never trade like these, so treat even the typical ones as better than an ordinary launch.

Reading the forecast

The forecast compares two outcomes for the same buyers: what actually happened on the token's own launchpad, and what a GlazeCorp fund with your launch settings would have built. The fund's figures and chart lines are the middle of 100 alternative histories (the token's days reshuffled, behaviour drawn from measured spreads); low and high, and the shaded band, cover 8 in 10 of them. The token's days in their actual order are one of those histories, shown in the caption, and are often not the middle.

• Real money first. The table leads with treasury, creator earnings and backing. Market cap comes last: on a launchpad it is mostly supply handed out at launch and priced at the last trade, while a fund's market cap is close to the money inside it.
• Treasury and backing. Most launchpad tokens have no treasury. A GlazeCorp fund builds one from mining payments, plus swap fees if you route them to the fund. The treasury shown includes its liquidity, half of which is the fund's own token, valued at market price; a launchpad vault's own tokens are counted the same way ($AI's vault holds 0.9% of its supply). Backing per token is the treasury divided by supply: what one token withdraws. A withdrawal pays a share of every token the fund holds, liquidity included, so that is the same as outside assets divided by the tokens held outside the fund's liquidity.
• Why backing per token is close to price. Miners pay roughly 80% of what newly mined tokens are worth, and the fund keeps about 19% of each payment after the previous miner's reimbursement, which works out to about 77% of the mined tokens' value. With 1,000 genesis tokens almost all supply is mined, and withdrawal arbitrage stops price from staying more than a few percent below backing. Backing falls behind price when net buying arrives faster than mining can turn it into treasury, as on a token's best days.
• The launchpad side. Each token's fee routing was read on-chain on October 18, 2026. LONG pools charge a 0.7% pool fee, 95% of it to the token's beneficiary, plus a 1% hook fee to the platform. Pons charges a 1% hook fee, 70% to the creator, plus a per-token creator tax. Where that money goes differs by token: $AI sends 80% to a vault governed by its holders (about $404,000 of outside assets, excluding the 8.97M $AI it also holds and its pool liquidity) and 20% to its creator; SCHIFFY and SPACEHOOD send fees to holders or a community vault; OPTIMUS, microduck and SHROOM pay the creator share out to holders every epoch; BONER, MEME, STRATEGY, UBIK, RKST and NASDANQ pay the creator. The forecast estimates each share on the same launch-pool volume and shows any treasury at its on-chain balance.
• Creator earnings. The presets send your fund's swap fees to the creator, so creator income is comparable with the launchpad's, while mining payments build the treasury. Routing swap fees to the fund instead (Swap & mining fees) builds a larger treasury and leaves the creator the mining fee. Creator earned compares what each creator keeps. Where a launchpad creator sends their share to holders or a vault, that amount is noted under the launchpad figure but not counted.

Data: daily candles from the GeckoTerminal API and every swap in each main pool, read from Robinhood Chain's Uniswap v4 PoolManager through a public archive RPC, retrieved October 2026. The snapshot scripts are scripts/fund-model/fetch-reference-tokens.py and scripts/fund-model/fetch-reference-flows.py.

The calibrated market model

Each step of the replay is measured rather than assumed:

• Price follows net flow. Hourly swaps in the reference pools show price moving with net flow divided by pool depth, at a slope of about 1.75 against the 2 a constant-product pool predicts (R² 0.78 over 14,690 token-hours across all 12 pools). Pool depth was about 3% of market cap, growing with roughly the square root of market cap.
• Most of a move lasts, and buyers do not buy dips. About 80% of a flow-driven move was still there 24 hours later (about a fifth reverted, mostly within 6 hours), and daily net buying did not respond to how far price had fallen from its high. Price is largely the running result of net money, not a valuation buyers defend, so the fund receives the token's net money rather than its market cap. The partial reversals are themselves later trades in the token's history, so replaying its flows reproduces them.
• Traders size to liquidity. Real pools took at most about 17% of their depth in net flow an hour (99th percentile; 13–20% by token), so larger net buying waits until your pool can take it. Trading volume scales with your pool's depth against the token's.
• Miners sell most of what they mine. See What miners do with mined tokens.
• Mining capture is backtested. Replaying Donut's real price and emissions through the model's mining auction, a capture fitted on April 19–June 20, 2026 predicted the next two months' payments within 13% and takeover counts within 1%. On August 24, Donut's miners changed strategy and capture fell to 26%, so ranges draw capture between 26% and 93% around the 81.5% default.

What miners do with mined tokens

This is an assumption, and it is the one that moves the forecast most. Every token a miner sells has to be bought by someone; every token a miner keeps is money the miner has put in and left in the fund.

• Main case: miners sell, as Donut's did. 55% of newly mined tokens are sold into the pool at once and the rest over about a week (an exponential with a 7-day mean), so within a few weeks essentially everything mined has been sold. This is fitted to Donut, the one mined token with full on-chain history here: its 147 miners hold 0.8% of the 19.8 million DONUT they mined. Regressing their balances, taken every two days since launch, on tokens mined by age (R² 0.82): about a third of the last day's tokens and a third of those 1–7 days old are still held, 3% of those 7–30 days old, and a stash of about 150,000 DONUT.
• Ranges: some miners keep. Bitcoin shows miners can hold for long stretches. Public miners such as MARA kept nearly all of their output through 2024 and early 2025, paying costs with money raised from investors, then sold heavily when margins tightened: more than all of April 2025's output across public miners, and more in early 2026 than in all of 2025. In aggregate, Bitcoin miners spend roughly what they mine over time (CoinDesk, May 2025, TheEnergyMag, April 2025, CoinDesk, March 2026). So each range run also has miners keep between 0% and 30% of new tokens for good (drawn evenly), alongside 40–70% sold at once and a 3–10 day holding time for the rest.
• How kept tokens are priced. A miner who keeps tokens is holding a share of the fund, so when bidding to take over the Mine the model values kept tokens at outside backing per token (what they could withdraw), and sold tokens at the pool price. Valuing kept tokens at the pool price would let rising bids and a shrinking supply for sale lift each other with no outside money; with this rule the model stays bounded. The setting is capped at 50% kept.
• Not modeled: miners withdrawing instead of selling (similar in effect, as both take money out at about backing), miners buying more tokens, and miners changing behaviour with price.

Ranges rerun the launch 100 times, reshuffling the token's days in week-long blocks (so the money arrives in a different order and amount) and drawing mining capture, miner selling and keeping, the hourly flow limit and withdrawal costs from those measured spreads. The scripts are scripts/fund-model/fetch-reference-microstructure.py, calibrate-reference-microstructure.py, calibrate-donut-miner-selling.py and backtest-donut-mining.mjs.

Opening price, market cap and the demand path

At launch, with all amounts expressed in whole tokens:

Initial supply = tokens paired in the pool + tokens minted to the creator
Opening token price = base tokens deposited × base token USD price / paired fund tokens
Opening market cap = opening token price × initial supply
Starting pool value = 2 × base tokens deposited × base token USD price

The initial pool liquidity is permanently locked outside the fund's redeemable treasury. A creator allocation increases initial supply and implied market cap; it does not add cash to the pool.

Choose one baseline, then optionally edit individual month-end market caps:

• Reach a target / Gradual growth: compounds from launch cap to the target at the chosen month, then stays flat. A lower target also permits a decline.
• Early surge then steady: reaches the same target at the same month, but front-loads the move. It uses the square root of the gradual path's elapsed-time fraction in the exponent, then stays flat.
• Rise then decline: reaches the target at the selected month, then falls by the chosen percentage over an equally long period and stays flat afterward. For example, a month-6 peak with a 50% decline reaches half the peak at month 12. If the peak is outside the forecast, the decline will not appear yet.
• Grow by a yearly percentage: compounds the launch market cap at the entered annual rate throughout the forecast. For example, 5% turns $100,000 into $105,000 after one year and $110,250 after two. This is market-cap growth, not token-price growth or an asset-return assumption; it does not use the target or path-shape settings.

The unedited gradual and annual-growth baselines are:

Cap(t) = opening cap × (target cap / opening cap) ^ min(t / time to target, 1)
Annual-growth cap(t) = opening cap × (1 + annual growth / 100) ^ elapsed years
Token price(t) = cap(t) / effective token supply(t)

Time units must match. The baseline generates every month-end value. An edited month replaces only that endpoint; other months retain their automatic values. Edited values remain fixed when launch amounts, the target, shape or annual rate changes. Reset a month or all monthly edits to return to the baseline. Shortening the forecast preserves later edits for reuse when the horizon is extended. Launch itself is fixed by the launch inputs.

The engine joins the resulting positive endpoints geometrically: between consecutive caps A and B, the cap is A × (B / A) ^ fraction of month elapsed. That same path drives token price, turnover-based trading volume, swap fees and market-based mining bids. Chart points are month-end caps, not average caps for the whole month. The logarithmic chart scale makes large percentage changes readable; switching to linear changes only the display. Exact-value fields and keyboard arrows offer alternatives to dragging.

The selected target or annual rate is a baseline, not a constraint after manual edits. An edited target month can differ from the original target. Effective supply includes pending mining emissions and subtracts modeled burns and withdrawals. A flat cap can therefore mean a falling price as supply grows, or a rising price as supply contracts. Share links, JSON downloads and Copy for AI preserve the demand settings and manual edits; the AI export also includes the resolved monthly path. Older scenarios load as gradual target paths without manual edits.

Market cap is an external assumption, not money deposited into the fund. The model does not derive demand from marketing, holder counts or fund performance. It assumes arbitrage keeps the modeled pool aligned with the price path. Monthly edits can represent growth, downturns and recoveries, but do not simulate intramonth shocks or volatility, probabilities, or feedback between backing and demand. The chart's curve is an assumption, not a prediction or proof of achievable liquidity.

Trading volume and swap fees

Turnover is how much trades each day relative to market cap. Entering 10% means $100,000 of daily trading at a $1,000,000 market cap; it does not mean 10% of the cap arrives as new capital.

Daily trading volume = market cap × daily turnover fraction
Volume in this pool = daily trading volume × pool capture fraction
Gross swap fees = volume in this pool × swap fee fraction
Protocol swap share = 30% of gross swap fees
Remaining swap fees = 70% of gross swap fees

The remaining share goes to the fund or the creator's selected fee recipient according to the launch setting. The current model attributes the modeled pool's remaining fees to that recipient; dilution from additional outside LP ownership is not an exposed scenario control. Fees are modeled as a 50/50 split of buy-side and sell-side volume, collected daily and valued at the modeled asset prices. Token-denominated fees are not guaranteed cash proceeds.

Turnover, pool capture and the swap fee rate are separate inputs. Raising fees increases revenue arithmetically at fixed volume, but the model does not predict the resulting loss of trading demand. Test lower turnover and capture alongside a higher fee. Donut's mining history does not calibrate your future turnover.

Mining price and takeover timing

Each fund has one Mine. When someone takes it over, the outgoing miner receives 80% of the incoming payment. The incoming miner receives emissions during their tenure and expects reimbursement from the following takeover. See Mining.

The starting approximation is that a miner expects to stay for about 30 minutes and expects the following takeover to pay a similar price. Under those assumptions:

Reference tokens = current emission rate per second × 1,800 seconds
Expected net mining cost ≈ 20% × takeover payment
Takeover bid ≈ expected realizable value of reference tokens / 20%

For example, 2 tokens/second for 30 minutes is 3,600 tokens. At $0.01 per token, their spot value is $36. With an 80% realization assumption and no extra costs, the illustrative bid is $28.80 / 0.20 = $144. Expected reimbursement is $115.20 if the next miner also pays $144. Actual reimbursement depends on that next payment.

The implementation adds a liquidity limit and an optional extra dollar cost per takeover:

Batch sale fraction = (1 − swap fee fraction) / (1 + reference tokens / pool token reserve)
Realization fraction = min(net mining cost assumption, batch sale fraction)
Expected value = reference tokens × token price × realization fraction
Bid = max(0, (expected value − extra takeover cost) / 0.20)

The batch sale estimate approximates selling the entire reference reward into the modeled constant-product pool. Taking the smaller fraction caps the historical benchmark by available liquidity without subtracting the same friction twice. It does not simulate a miner's actual execution strategy.

The asking price declines linearly over one hour. After a takeover it resets to the larger of 1 USDG or twice the amount just paid. A new takeover occurs when the declining ask reaches the modeled bid. In a stable regime away from the minimum reset, this tends toward 30 minutes; price rises can bring replacement forward and price falls can delay it. The model assumes the first miner takes over after one hour for free, with emissions beginning then. Each acquired emission rate stays locked until replacement, even if a global halving happens during that tenure.

Thirty minutes is a reference for bidding, not a fixed event schedule. The “similar next payment” assumption is an approximation of expectations, not a solved game-theory equilibrium. The model assumes active miners even when the Mine can be taken over for free. It does not predict abandonment, collusion, miner inventories, financing constraints or strategic competition between bots.

What Donut tells us

The Donut dashboard identifies the earlier mining experiment. The model's October 18, 2026 calibration uses its public indexed tenure data pinned to block 52,782,088, plus DONUT/WETH daily prices. The calculator's “Why the Donut defaults?” section includes source links and a downloadable evidence file.

Source data: public mining subgraph, daily DONUT/WETH price endpoint and Dune query. Timing observations span November 10, 2025–October 18, 2026. The figures below describe the saved snapshot; querying those live endpoints later can return a different sample.

For each completed tenure, net cost is its entry payment minus its outgoing reimbursement. Tenures are grouped by settlement date. The daily ratio divides their summed net cost by their summed mined tokens valued at that day's closing DONUT/WETH price, in the same ETH units as mining costs. It is a ratio of daily sums, not a median of individual miner returns. The value-weighted aggregate ratio is 88.81%, which differs from the daily median used as the default.

Daily closing prices are a proxy for value, not executable quotes at each takeover. The timing sample is longer than the price sample, and same-address replacements are not independent new participants. These historical percentiles describe dispersion, not confidence intervals for a new fund. Donut did not build backing throughout its main expansion or offer this withdrawal mechanism, according to the team's account below. Its data does not establish future treasury returns, trading activity or demand for these funds. The 81.5% figure is a benchmark for the bid approximation, not a measured constant that will hold in every market.

Why this is a new iteration of Donut

GlazeCorp funds are a new iteration of the Donut mining design. The team's account is that Donut introduced backing late, after its main expansion, and holders lacked an efficient redemption path. Its strongest period of activity therefore was not accumulating the redeemable backing intended in this design. The team's diagnosis is that this left Donut without an effective asset-based backstop when demand weakened.

The design thesis is to capture activity into backing from the start and give holders direct access to that backing:

1. Demand can support token price and miners' willingness to pay for emissions.
2. Net mining revenue, plus swap fees directed to the fund, can acquire assets through the configured routes.
3. Settled assets accumulate in the fund while the same activity is also issuing tokens.
4. Holders can burn tokens for their proportional share of selected fund assets. If tokens can be bought for less than the value obtainable from withdrawal after costs, buying and withdrawing can become profitable.

The improvement being tested is backing accumulation during growth, plus usable withdrawal. Assets start accumulating as revenue arrives and auctions settle; creating a fund does not automatically seed its treasury. Fees sent to a manager's wallet do not build that treasury. The relevant outcome is backing per effective token, not just a larger total asset balance, because mining also adds supply.

The team believes these mechanisms address important weaknesses of Donut. That is a design thesis, not a demonstrated explanation of every part of Donut's decline or proof of what its price would have been with earlier backing. The Donut sample has not been segmented around the introduction of backing, so it is not a clean control experiment for an unbacked token. Use it to inform mining behavior, not to assume that a redeemable fund must repeat Donut's price path or that the revised design's outcomes are already established.

How redeemable NAV can support price

Here, NAV per token means the marked value of treasury assets divided by effective supply. The contract pays asset quantities, not a promised dollar price. The practical arbitrage calculation is:

Expected arbitrage profit for a chosen trade size
= realizable proceeds from the assets received on withdrawal
− total cost of buying the fund tokens
− gas, withdrawal/unwind costs and execution risk allowance

If that is positive, buying fund tokens and withdrawing them can create demand below realizable backing value. For an ideal proportional withdrawal at unchanged asset prices, both treasury and supply fall in the same proportion: withdrawal itself does not mechanically raise NAV per remaining token. The price-support mechanism is the incentive to buy discounted tokens and realize the underlying claim.

This supports an economic arbitrage boundary, not an unconditional promise that market price always stays above displayed NAV. Acquisition and liquidation price impact, fees, gas, asset transfer restrictions, asset-price changes and access to arbitrage capital affect the executable opportunity. Uniswap explains how liquidity and trade size affect price impact. A premium can also persist: GlazeCorp does not provide a general basket-deposit-and-mint route at NAV to arbitrage it away.

Fund-owned LP tokens need particular care. Their marked value includes this fund's own token, which is not independent outside backing. Withdrawal still pays them out: a holder who buys one token and withdraws receives a share of the LP, token side included. Buying at price P breaks even when P equals the treasury per token at that price, which works out to outside assets divided by the tokens held outside the fund's LP. The model's arbitrage floor uses that break-even, less the cost of unwinding, so market cap stays at or just under the treasury. External backing, without the token side, is still reported in the CSV; neither mark is an executable withdrawal quote. See Price and backing and Withdrawal.

What the current forecast captures

The model tracks revenue settlement, treasury assets, dilution, burns and assumed proportional withdrawals. It can show whether the selected design accumulates backing per token under a chosen demand scenario.

It does not yet simulate price-responsive withdrawal arbitrage. Market cap follows your input path, and monthly withdrawal is a fixed assumption rather than a response to a discount. The app does not force price to equal the greater of that path and NAV. A forecast price below marked NAV therefore indicates a scenario that needs an execution and arbitrage analysis; it is not a prediction that a profitable discount will remain available. Likewise, a price above NAV does not prove the backstop would hold in a selloff.

To test the backstop dynamically, a future model would need trade-size-dependent purchase and withdrawal quotes, asset-unwind liquidity, costs, arbitrage participation and price/supply updates after each trade. Until then, compare price, marked NAV per token and external backing per token, and treat the arbitrage response as unresolved. Do not describe the current forecast as a simulation of a guaranteed NAV floor.

From activity to creator income and treasury

For a regular paid takeover, 80% goes to the previous miner and the remaining 20% is mining revenue. The Mining fee rate slider displays the creator fee as a percentage of the full takeover payment. The default 0.5% creator fee takes $5 from a $1,000 takeover. Protocol mining fees are also 0.5% of the gross payment, leaving 19% of the full payment for the revenue stream and strategy auctions. The fee breakdown includes the previous miner so all displayed shares total 100% of the takeover payment.

Creator mining fee = gross mining payment × displayed creator fee fraction
Protocol mining fee = gross mining payment × 0.5%
Strategy mining revenue = gross payment − previous miner payout − creator fee − protocol fee

Revenue is streamed to strategies according to allocations. Auction buyers exchange the selected payment assets for the available revenue when the modeled discount meets the buyer-margin assumption. Auction payment assets are split between the fund and allocation rewards. Until settlement, mining revenue is not an asset already held in treasury. See Revenue routing and Strategies and auctions.

The simulation advances streams hourly and collects fees daily. Within each hour, revenue is treated as arriving evenly while each strategy's ask declines, and the model solves when a bidder can first afford the auction, including whole-unit payment rounding. On a reference launch this matches one-second steps to within 0.01% of year-end treasury value; sampling only at the hour mark had understated it by about 12%. Buying allocations remain fixed, and the model does not invent future community or external allocations. LP auction buyers are assumed to supply matched liquidity for new LP shares. Fund-held fund tokens are burned on the modeled daily schedule.

Creator income combines mining fees, any directed swap fees and the creator's modeled allocation rewards. Accrued means earned at that time's modeled value; collected means claimed on the modeled schedule at collection-time value. Neither includes a sale of the creator's initial token allocation or subtracts operating expenses, taxes or launch costs. “Extra takeover cost” is a miner cost, not a creator expense.

Treasury is the marked value of fund-held assets, not cumulative revenue. Fund-owned LP value includes its fund-token side; external backing excludes that side. Withdrawals burn available tokens and remove proportional backing in kind, rather than create new income or a cash withdrawal queue. See The fund and withdrawals. Default withdrawals are zero. Asset growth assumptions compound annually; USDG stays at $1 throughout the model.

Supply, inflation and reading the tables

The global emission schedule halves at the selected interval down to the tail rate. Actual modeled issuance also reflects the one-hour start and the rate locked during each mining tenure. A positive tail means issuance continues; a halving schedule with a tail is not a fixed maximum supply.

Effective supply = initial supply + all accrued mining emissions − burns − withdrawn tokens
Annual issuance rate = tokens mined during the year / opening effective supply
Net annual supply growth = (closing effective supply − opening effective supply) / opening effective supply

A small initial supply can make first-year issuance percentages very large. Issuance and net supply growth differ because burns and withdrawals reduce supply. Price, supply and treasury columns are end-of-period balances; volume, fees, income and newly mined tokens are totals during the period. Years contain 365 days; months are equal 365/12-day buckets, not calendar months. All dollar values are modeled USD marks.

Compare designs before choosing parameters

Start with the outcome you care about: deeper liquidity, long-lived emissions, external backing, creator income or some combination. Set a budget for the seed deposit. Then compare the same demand scenarios across candidate launch designs.

• Reference: use your stated target, timing and turnover. What follows if your central assumptions hold?
• Lower demand: lower the target and lengthen the time to reach it. Does the design still meet your objective if adoption is slower?
• Less trading: lower turnover and the share using this pool. Are earnings mostly dependent on trading assumptions?
• Weaker mining economics: lower realization and raise extra takeover cost. How much revenue depends on miners being able to realize token value?
• Liquidity constraint: reduce the seed deposit while keeping the opening price comparable. Does limited execution depth restrict mining bids?
• Treasury stress: lower asset growth and increase withdrawal. How sensitive is external backing to asset performance and exits?
• Combined downside: apply several adverse assumptions together. Which assumption or parameter breaks the design first?

When comparing liquidity at a fixed opening price, change paired tokens proportionally with the base deposit and account for the resulting change in initial supply. Keep a record of everything changed. Stress cases are chosen scenarios, not probability estimates. A lower turnover setting does not make the model simulate a panic or market closure.

Avoid selecting the configuration with the largest displayed income just because it is largest. Check who receives the fees, how much stays in the fund, the miner liquidity limit, issuance relative to opening supply, and warnings under the forecast. Operating costs must be budgeted separately. The model cannot discover an optimal fee or emission rate without evidence about how participants respond.

Why the schedules follow real coins

Each schedule is a well-known coin's issuance shape. The October 21 v3 study benchmarked 16 coins from their own source code and ran each shape through the same scenarios as the earlier preset study. On a large genesis, the coins' faithful schedules beat the earlier presets on backing per token, dilution and later mining revenue, at about the same fund size, and in calibrated replays of 12 real tokens each held its price better through the first months, with a smaller early treasury.

Mining revenue is 20% of takeover payments, and takeover payments track the dollar value of the tokens being emitted, so the halving interval decides when the fund earns. Later emissions sell at later prices: a slower schedule earns more from each new token when the token grows, and a faster one captures more while the price is still high. Slower schedules also mine slowly while a new fund is small, so takeovers can wait longer until demand grows. Weak-demand outcomes were poor under every design; the demand curve matters far more than the schedule. Switch schedules and tokens in the model to see this directly.

Seed capital is separate from every schedule. Enter the deposit you can actually make. A small seed means a thin pool, so early buying moves price a lot and the market cap can spike; it changes trade price impact and the dollar value of mining rewards, but does not by itself mean a fund cannot bootstrap.

What the schedules do not settle

The 1% swap fee matches common launchpad fees for new tokens, but the model holds volume fixed, so it cannot find an optimal fee. A higher fee wins automatically at fixed volume; a 2% fee earns more only if it keeps more than half the trading. Mining fee rates likewise extract income without modeling how miners respond. The study does not establish miner competition or abandonment, fee-sensitive trading, executable withdrawal arbitrage or a price floor. Stress paths are chosen scenarios, not probabilities, and some imply more pool tokens than exist; the calculator warns when that happens.

Take this to an AI assistant

Open Share & export → Copy for AI to copy this methodology, your scenario JSON, resolved numeric parameters, and the available annual forecast with warnings. It does not send anything to an AI service: paste the text into the tool you choose. The JSON uses ungrouped numbers for interchange; the app displays grouped numbers. The scenario link and Download scenario file preserve editable inputs, while CSV exports preserve calculated rows. A link carries inputs, not a frozen copy of the calculation engine; save the brief and CSV if you need a record of today's outputs.

Copy guide in Share & export, the plain Markdown version and Copy all docs include the methodology but not your current calculator state. If you use those, attach your downloaded scenario JSON and CSV as well. AI tools may not read browser URL fragments, so a scenario link alone is not sufficient context.

Suggested prompt:

Help me evaluate launch parameters using this model and the attached scenario. First explain the design and cash flows in plain language. Separate contract mechanics, my launch choices, uncertain demand assumptions, historical Donut observations and calculated results. Ask about my objectives, seed budget and evidence for demand before recommending changes. Treat the Kaspa, Monero, Dogecoin, Ethereum and Bitcoin presets as starting points rather than proven optima, keep seed independent, and do not assume Bitcoin's faster early mining creates demand. Explain how the halving interval trades outcomes under growing versus falling demand. Compare a reference case, a combined downside case and an upside case without inventing probabilities. Change one input at a time first, then explain interactions. Identify which assumptions drive creator income, liquidity, inflation and external backing per token. Explain the new design thesis: accumulate backing during growth and enable withdrawal arbitrage. Keep the team's historical diagnosis of Donut separate from measured calibration results. Compare market price with marked NAV and realizable withdrawal value; account for costs and the fund-token side of LP holdings. The token replay simulates withdrawal arbitrage below backing less unwind costs; other demand paths do not, so do not claim those establish a NAV floor. Do not treat market cap as cash raised, gross activity as earnings, or the Donut benchmark as a promise. Distinguish results you actually recomputed from qualitative reasoning; if you cannot execute the model, give me exact inputs to try in the calculator. End with a short list of parameter tradeoffs, unresolved questions and evidence that would change the decision.

An assistant can help explain tradeoffs and propose scenarios. Use the calculator to verify numeric claims, review current launch constraints, and retain the assumptions behind the final choice.