Skip to main content

Revenue Flows & Treasury

Every ETH spent in MINERAL's mining mechanisms flows through a transparent, on-chain revenue distribution system. This page maps the complete path of every wei.


Complete Revenue Map​

Auction Mining Revenue (80-8-3-3-6)​

User pays ETH to mine a vein
│
├── 80% ──→ Previous Operator (pendingEth, pull-based)
│ └── First mine: goes to Treasury instead
│
├── 8% ──→ BuybackVault
│ └── Accumulates until keeper triggers buyback
│ └── ETH → swap for MINERAL → burn tokens
│
├── 3% ──→ StakingVault.fundRewards()
│ └── Distributed to stakers by tier weight
│ └── Claimable as ETH
│
├── 3% ──→ AutoLPVault
│ └── Accumulates until keeper triggers LP
│ └── 50% swap to MINERAL + 50% ETH → add liquidity
│
└── 6% ──→ Treasury (direct transfer)
└── Fallback: queued as pendingEth if transfer fails

Block Mining Revenue (90-3-3-4)​

Users deploy ETH onto 5x5 grid
│
├── 90% ──→ Winner Pool
│ ├── Normal: split among winning square deployers
│ ├── Motherlode hit: + accumulated jackpot
│ └── No winner: rolls into Motherlode pool
│
├── 3% ──→ Motherlode Pool
│ ├── Accumulates across rounds
│ ├── 1/625 chance per round to trigger
│ └── On trigger: entire pool added to winner payout
│
├── 3% ──→ StakingVault.fundRewards()
│ └── Same as Auction Mining (pooled together)
│
└── 4% ──→ Treasury (direct transfer)
├── Fallback: queued as pendingTreasuryRewards
└── Retry via pushTreasuryRewards()

Buyback & Burn​

The Buyback mechanism creates permanent deflationary pressure by purchasing MINERAL from the open market and destroying it.

How It Works​

8% of Auction Mining revenue
│
└── BuybackVault (accumulates ETH)
│
└── Keeper calls executeBuyback()
│
├── Pull ETH from BuybackVault
├── Swap ETH → MINERAL via DEX router
├── Verify received amount (anti-manipulation)
└── Burn all purchased tokens (permanent)

Execution Parameters​

ParameterDescription
maxEthToSpendMaximum ETH to use in this buyback
minTokensOutMinimum MINERAL tokens to receive (slippage protection)
deadlineTransaction deadline (timestamp)

Who Can Execute​

Buyback execution is keeper-gated:

  • Only authorized keepers can call executeBuyback()
  • The contract owner is automatically registered as the first keeper
  • Additional keepers can be added/removed by the owner
  • Minimum 1 keeper must always exist (cannot remove the last one)

Why keeper-gated? To prevent MEV bots from sandwiching the swap. Authorized keepers can use private mempools or MEV protection services.

Anti-Manipulation​

The executor checks the token balance before and after the swap:

balanceBefore = token.balanceOf(this)
router.swapExactETHForTokens(...)
tokensReceived = token.balanceOf(this) - balanceBefore
require(tokensReceived >= minTokensOut)

This prevents router manipulation where the swap returns fewer tokens than expected.

Burn Effect​

Burned tokens reduce totalSupply. While this technically reopens minting headroom under the 21M cap, the EmissionsController's schedule determines actual minting — burns don't accelerate emissions. The net effect is a permanent reduction in circulating supply.


Auto Liquidity Provision​

The Auto-LP mechanism deepens the MINERAL/ETH trading pair, reducing slippage and improving price stability.

How It Works​

3% of Auction Mining revenue
│
└── AutoLPVault (accumulates ETH)
│
└── Keeper calls executeAutoLP()
│
├── Pull ETH from AutoLPVault
├── Split: 50% ETH for swap, 50% ETH for LP
├── Swap first half: ETH → MINERAL via router
├── Verify swap result (anti-manipulation)
├── Add liquidity: MINERAL + ETH → LP tokens
├── LP tokens sent to designated recipient
└── Revoke router approval (security)

Execution Parameters​

ParameterDescription
maxEthToSpendMaximum ETH to use
minTokensOutMinimum MINERAL from swap (slippage)
minTokensLPMinimum MINERAL for LP (slippage)
minEthLPMinimum ETH for LP (slippage)
deadlineTransaction deadline

LP Recipient​

LP tokens are sent to a configurable lpRecipient address. This can be:

  • Treasury — Protocol retains LP tokens (can withdraw liquidity later)
  • Dead address — LP tokens permanently locked (liquidity can never be removed)

The choice of lpRecipient determines whether the liquidity is permanent or reversible.

Recovery Functions​

The AutoLPExecutor includes safety functions for edge cases:

  • recoverTokens() — Recover accidentally sent tokens
  • recoverETH() — Recover leftover ETH from failed operations

Treasury​

The Treasury receives a percentage of revenue from both mining mechanisms:

  • 6% from Auction Mining
  • 4% from Block Mining
  • Early unstake penalties from StakingVault

Treasury Uses​

The Treasury funds:

  • Protocol development and maintenance
  • Infrastructure costs (Chainlink VRF subscription, RPC nodes)
  • Future ecosystem development
  • Emergency reserves

Treasury Safety (Block Mining)​

Treasury address changes in the Block Mining contract are protected by a 1-day timelock:

setTreasury(newAddress)         // Queue change
└── Wait 1 day
applyTreasury() // Apply change

This gives the community 24 hours to review any treasury address change before it takes effect.


Staking Rewards Distribution​

Both mining mechanisms contribute to staking rewards:

SourceContribution
Auction Mining3% of mining revenue
Block Mining3% of round deposits

These ETH flows arrive at the StakingVault via fundRewards() and are distributed across the 5 staking tiers based on allocation weights and total stake per tier.

Fallback Mechanism (Block Mining)​

If the StakingVault transfer fails (gas issues, contract upgrade):

  • Rewards are queued as pendingStakingRewards
  • Anyone can call pushStakingRewards() to retry the transfer
  • Events track both queuing and successful push

Surplus Management​

What is Surplus?​

Surplus is any ETH in the Block Mining contract that exceeds tracked obligations:

trackedBalance = motherlode + outstandingWinnerClaims + pendingStakingRewards
+ pendingTreasuryRewards + currentRoundDeposits

surplusBalance = address(this).balance - trackedBalance

Surplus can occur if ETH is force-sent to the contract via selfdestruct or other edge cases. (Note: the receive() function reverts, so normal ETH transfers are rejected.)

Surplus Sweep​

A timelocked mechanism to recover surplus ETH:

queueSurplusSweep(recipient, amount)    // Owner queues sweep
└── Wait 1 day (ADDRESS_UPDATE_DELAY)
executeSurplusSweep() // Owner executes
└── Checks: amount <= current surplus balance
└── Transfers ETH to recipient

Sweep can be canceled at any time before execution:

cancelSurplusSweep()                     // Owner cancels

This ensures:

  • No ETH is ever permanently stuck in the contract
  • The community has 24 hours to review any sweep action
  • Sweeps cannot touch tracked obligations (motherlode, unclaimed winnings, etc.)

Tracked Balance Accounting​

The Block Mining contract maintains a comprehensive accounting of all ETH obligations:

ComponentDescription
board.motherlodeAccumulated Motherlode jackpot
outstandingWinnerClaimsSum of all unclaimed winner pools across all rounds
pendingStakingRewardsQueued staking rewards that failed to forward
pendingTreasuryRewardsQueued treasury rewards that failed to forward
Current round depositsETH deployed in the active (unsettled) round
getTrackedBalance() = motherlode + outstandingWinnerClaims
+ pendingStakingRewards + pendingTreasuryRewards
+ (current round totalDeployed if not settled)

getSurplusBalance() = address(this).balance - getTrackedBalance()

This provides full transparency: at any time, anyone can verify that the contract holds enough ETH to cover all its obligations.


Summary: Where Every Wei Goes​

Auction Mining (per 1 ETH mined)​

AmountDestinationFinal Effect
0.80 ETHPrevious operatorIncentivizes mining competition
0.08 ETHBuyback → BurnReduces token supply permanently
0.03 ETHStakersReal ETH yield
0.03 ETHAuto-LPDeepens liquidity
0.06 ETHTreasuryProtocol development

Block Mining (per 1 ETH deployed)​

AmountDestinationFinal Effect
0.90 ETHWinnersReward for correct square
0.03 ETHMotherlodeGrowing jackpot (1/625 trigger)
0.03 ETHStakersReal ETH yield
0.04 ETHTreasuryProtocol development