The Mana Pool

The Mana Pool is where Magic Internet Finance collects real protocol revenue and splits it equally among active Internet Wizards. Money enters the pool from a short, fixed list of actual sources (trading fees, conjure fees, collected royalties, and direct deposits), is split with the protocol treasury where a split applies, and is then allocated to every active Wizard as an equal SOL entitlement at the moment the pool receives it. Each Wizard's spell decides what happens to its SOL after that (see Spells). This page explains exactly where the money comes from, how the equal-share math works down to the lamport, what the pool does when there is nobody to pay yet, and what does not count as revenue. It is not a forecast. The pool only ever holds what has actually arrived.

Where the money comes from#

These are the only revenue sources the protocol recognizes today. Anything not on this list is not Mana.

A few notes on each row.

DBC trading fees. During launch, MIFI trades on Meteora's Dynamic Bonding Curve. The curve's trading fees for MIFI are configured to pay a fee recipient that the MIFI program controls. Those fees become Mana when they are claimed and ingested, not when the trades happen (see Receipt-time entitlement). This source ends when the curve completes and liquidity migrates.

DAMM v2 LP fees. After migration, MIFI/SOL trades in a Meteora DAMM v2 pool with a 3% fee on every trade. The protocol owns a locked liquidity position in that pool. The trading fees that accrue to that position are collected in SOL and claimed into the pool. Note the wording: the pool charges 3%, and the Mana Pool receives the portion that accrues to the protocol's position. If other liquidity providers are in the pool, their share is theirs.

Conjure fee. Every conjure pays a flat SOL action fee, separate from the 100,000 MIFI principal and from rent. With the proposed launch default of 0.05 SOL and an 80/20 split, 0.04 SOL goes to Mana and 0.01 SOL to the protocol. The Mana portion is allocated to the Wizards that already exist. The new Wizard never receives any part of its own fee.

Collected royalties. Internet Wizards carry a proposed 5% royalty on the Metaplex Core collection, set as advisory (RuleSet::None) so that ordinary wallets and marketplaces can transfer them without extra accounts. Advisory means a marketplace can choose not to pay it. Only royalties that actually arrive are counted, and they go entirely to Mana. Do not assume every resale pays.

Direct deposits. Anyone can send SOL to the reserve address. It will be shared like any other receipt, but the Mana page records it under its own category so nobody mistakes a donation for trading volume. Some marketplaces may pay royalties directly to the reserve rather than to the royalty inbox; the program cannot tell those apart from a donation, so they are shown under direct deposits too.

Two things are deliberately absent from the table. The proposed dispel fee is 0 SOL, so dispelling produces no revenue. Future product revenue (if any) is proposed at the same 80/20 split, but it is not counted in any total until it is real.

The 20% protocol share goes to a separate treasury account. It funds operations, including the network fees the keeper pays to settle Wizards and run spells. The keeper never deducts anything from your entitlement to cover its own costs.

One Wizard, one share#

Every active Wizard is exactly one share of every receipt. There are no multipliers, no boosts, no rarity weighting, and no seniority.

An Infinity Wizard that has bought a lot of extra MIFI still has weight one. "Compounding" in MIFI means the vault accumulates more tokens, not that the Wizard earns a bigger slice of the pool. Cosmetic stage is derived from lifetime allocated SOL and age, and it goes one direction only; it is decoration, not a dividend tier.

Transferring a Wizard moves the whole position, including any entitlement it has not yet settled. Nothing resets, and the buyer settles whatever the seller left on the table. See Internet Wizards: Conjure, Own, Dispel for how ownership and dispel work.

How allocation works, in plain words#

The pool keeps one running number: the total SOL a single share has been entitled to since launch. Call it the index. Every time revenue arrives while there are N active Wizards, the index rises by the amount divided by N. That is the whole allocation step. It does not loop over Wizards, so it costs the same with ten Wizards or ten thousand.

Each Wizard remembers the index at the moment it was activated, and again each time it is settled. That remembered value is its checkpoint. What a Wizard is owed is simply the current index minus its checkpoint. A Wizard conjured today starts with a checkpoint equal to today's index, so it has no claim on anything that arrived before it existed.

Settlement is the step that turns an entitlement into actual lamports in the Wizard's own vault. Anyone can trigger it for any Wizard, because the destination is fixed to that Wizard's vault and nowhere else. The keeper does this routinely; you can also do it yourself from the Wizard's profile.

Lamports are indivisible, but the index is kept at much finer precision, so a settlement can leave a fraction of a lamport owed. That fraction is carried on the Wizard and added to its next settlement. Ten small settlements pay exactly the same whole lamports as one large settlement covering the same period. There is no rounding advantage to settling often, or to waiting.

The exact formula#

The program uses checked integer arithmetic throughout. Q is a fixed-point scale of 10^18. All amounts below are lamports; "scaled" values are lamports multiplied by Q.

Q = 10^18                       # fixed-point scale
N = number of active Wizards

Allocation of R net lamports arriving at the pool:
  if N == 0:
      bootstrap_reserve += R                 # unallocated; see "The bootstrap reserve"
  else:
      delta      = floor(R * Q / N)
      index     += delta
      dust      += R * Q - delta * N         # remainder, < N scaled units

Settlement of Wizard w:
  due_scaled     = (index - checkpoint[w]) + fraction[w]
  whole          = floor(due_scaled / Q)
  fraction[w]    = due_scaled mod Q          # carried forward, always < Q
  checkpoint[w]  = index
  pending_sol[w] += whole                    # moved reserve -> Wizard vault, same transaction

Dispel of Wizard w (after settling it at the current index):
  dust        += fraction[w]                 # the final sub-lamport crumb is recorded
  fraction[w]  = 0
  N           -= 1

Two properties follow directly from this arithmetic and are checked by the protocol's tests:

• Conservation: the lamports held in the reserve always equal the unsettled entitlements plus recorded dust plus the bootstrap reserve. Nothing is created, and nothing is swept while it is needed to cover a fraction someone is owed.
• Path independence: for any Wizard, k settlements over a period produce the same whole and the same final fraction as one settlement over the same period.

A rounding illustration#

This uses made-up inputs to show how the integer math behaves. It says nothing about how much revenue will arrive.

Suppose exactly 1 SOL (1,000,000,000 lamports) of net Mana arrives while 3 Wizards are active. Then R * Q = 10^27, and delta = floor(10^27 / 3) = 333,333,333,333,333,333,333,333,333. The global remainder R * Q - delta * 3 is 1 scaled unit, which is 10^-18 of a lamport, recorded as dust. When each Wizard settles, whole = 333,333,333 lamports and fraction = 333,333,333,333,333,333 scaled units (about a third of a lamport) is carried. The three Wizards receive 999,999,999 lamports between them; the remaining 1 lamport stays in the reserve backing their three carried fractions plus the global dust. Nobody is short-changed, and nobody gets a lamport they were not owed.

Receipt-time entitlement#

Entitlement is decided by who is active when the pool receives the money, not by when the underlying trade happened. This is called receipt-time entitlement, and it is the most important thing to understand about timing.

Trading fees on the Meteora venues accrue to the protocol's fee recipient or LP position first. They are not Mana until a claim transaction moves them into the pool and an ingest step allocates them. The Mana page shows "claimable on venue, not yet received" as a separate figure so you can see money that is on its way but not yet allocated.

The consequence is that someone could, in principle, conjure just before a large claim and dispel just after, sharing in fees generated while they were not a member. The protocol does not pretend this window is zero. It shrinks it in a few ways:

A "Spell Round" in the app is a keeper processing batch. It is the moment pending SOL gets converted according to each Wizard's spell, not the moment anyone becomes entitled to money that already arrived.

The bootstrap reserve#

When there are no active Wizards, N is zero and there is nobody to divide by. Revenue that arrives in that state goes to a separate, visible bootstrap reserve inside the pool. This applies before the very first conjure, and again if every Wizard were ever dispelled.

The very first Wizard's own conjure fee is the clearest example: at the moment that fee is paid, N is still zero, so its Mana portion lands in the bootstrap reserve. The first Wizard does not receive it, and neither does the second. The bootstrap reserve is not a welcome gift for whoever shows up next.

In the current design the bootstrap reserve stays unallocated and is displayed on the Mana page. Any future policy for it would have to be an explicit, visible protocol change, not a quiet reinterpretation.

Dust#

Dust is the sub-lamport residue the integer math leaves behind. It is recorded, it is backed by real lamports sitting in the reserve, and it is never claimable by anyone, including the protocol.

There are two kinds:

The remainder from one membership group is never quietly handed to a different membership group; it stays recorded as dust. The Mana page shows the dust counter alongside the reserve so the conservation check can be read by anyone. The pool keeps a ledger of its crumbs, which is more than most of us can say.

What is not revenue#

The Mana Pool records categories carefully so that the numbers on the Mana page mean what they say. The following are never counted as revenue:

• LP principal. The protocol's liquidity in the DAMM v2 pool is not income, and changes in the composition of that position (more MIFI, less SOL, or the reverse, as the price moves) are not fees.
• Donations mislabeled as trading. Direct deposits are shared, but they are always recorded as deposits. They never appear as trading or LP fee revenue.
• User top-ups. Anything you send to your own Wizard's vault is yours. It is not Mana, it is not shared, and it does not count toward cosmetic stage milestones.
• Rent. Account rent floors are held separately, excluded from Mana totals, and excluded from estimated NAV.
• Token principal. The 100,000 MIFI locked in each Wizard never funds rewards, operations, or swaps. It is not revenue for anyone.
• Fees still sitting on a venue. Until claimed and ingested, they are shown as "claimable, not yet received" and are not in any allocated total.

What you see on the Mana page#

The Mana page in the app is meant to let you check the pool's books, not admire them.

Every receipt and processing transaction links to an explorer. Any USD figure on the page is an estimate from a reference price with a timestamp, and the page says so. Estimated NAV on a Wizard page follows the same rule (see Internet Wizards: Conjure, Own, Dispel).

Rewards depend on activity#

There is no yield built into MIFI. The Mana Pool distributes revenue that was actually generated by actual activity, and nothing else.

• Conjure fees come from new conjures. If nobody conjures, that source is zero.
• Trading fees come from trading. If MIFI trading slows, they slow; if it stops, they stop.
• Royalties come from resales on marketplaces that honor an advisory royalty. Some will not.
• Direct deposits come from people choosing to send SOL to the reserve. Nobody is obliged to.

The Mana page shows these sources separately so the actual revenue mix is always visible. It does not show an APY, because there is no honest one to show. Past receipts are a record, not a rate.

Your Wizard's 100,000 MIFI principal and any assets its spell has acquired remain redeemable through dispel, subject to the program operating correctly, but their market prices can rise or fall, and a Wizard's market price can differ from its estimated NAV. The three spells change the form your SOL ends up in, not how much you were entitled to; realized output depends on execution prices, slippage, and costs at the time each spell runs.

See also#

• The MIFI Token: the MIFI token, the bonding curve launch, and migration to the DAMM v2 pool
• Internet Wizards: Conjure, Own, Dispel: conjuring, owning, transferring, and dispelling a Wizard
• Spells: what Orange, Sol, and Infinity do with settled SOL