The mine, explained.

Beginner

Think of a round like a quick guessing game played on a board of 30 squares.

1. A new round opens and a short timer starts. In the example art the timer is about 30 seconds.
2. You pick anywhere from 1 to 30 squares you think might win, and you put some SOL behind your picks.
3. Your choices are sealed in a locked box. Nobody, not even the people running it, can peek at where anyone placed.
4. When the timer ends, one square is revealed as the winner.
5. If one of your squares is the winning one, you win. Everyone who picked a losing square loses the SOL they put in.
6. The losing SOL is gathered into a pot, and all the winners share it.
7. On top of that, winners also get a slice of brand-new ZINC tokens that the round creates.

So you are really just guessing which square gets revealed, with your stake riding on the answer.

Intermediate

Here is how a round actually works once you look at the numbers.

1. A round opens for deposits for a fixed window (the example shows roughly 30 seconds).
2. You “deploy” SOL onto a hidden pattern covering 1 to 30 of the board’s squares. The amount you stake is your choice each round.
3. A small deploy fee is taken off the top, so your net stake is slightly less than what you sent.
4. Your tile pattern is encrypted before it ever reaches the chain, so it stays private permanently, not just until the round ends.
5. After the window closes, a random number is revealed and one winning square is selected from the 30.
6. All the net SOL from losing squares forms the pot.
7. That pot is split among the winners in proportion to how much each of them staked on the winning square.
8. Winners also receive freshly minted ZINC, sized by how much SOL the whole round deployed.

Advanced

On-chain, a round is driven by the deploy_round instruction and a sequential Round account.

1. You call deploy_round with totalAmount (gross lamports, caller-chosen per round) plus an encrypted tile mask: maskEncryptionKey (X25519), maskNonce, and maskCiphertext, a 64-byte ciphertext encoding your 30-tile placement. The plaintext mask is never published, so placements are hidden forever.
2. Deploy fees (deploy_total_fee_bps) are skimmed; your Miner.total_amount records the net stake.
3. Deposits close at close_after_slot. Only after that slot is randomness fixed, so no one can react to the entropy while the round is open.
4. Settlement reveals round.rand, and winning_square = rand % 30 selects the winning tile (displayed tile = square + 1).
5. The net pot (round.total_deployed) is paid pro-rata to each winner’s net stake on the winning tile, using total_on_winning_tile as the denominator.
6. Winners also share newly minted ZINC from the emission curve.

Because the mask is encrypted and rand is only sampled after close_after_slot, neither miners nor operators can game the outcome. Every value is publicly verifiable on-chain.

Beginner

Think of Bricks as raffle tickets you collect just by playing.

1. You mine ZINC by deploying SOL onto hidden tiles in a round.
2. Every time you mine, the protocol hands you some Bricks automatically. You do not buy them or claim them separately.
3. Your Bricks pile up in your account over time.
4. Later, those Bricks become entries into the Stockpile, a separate prize with a SOL and ZINC pot.

The more raffle tickets you hold, the better your chance when the Stockpile is revealed. Bricks do not decide whether you win an individual mining round. That is a different mechanic. Bricks are mainly your stake in the Stockpile prize. Mining is the only thing you have to do; the tickets accumulate as a side reward.

Intermediate

Here is how Bricks are actually earned, step by step.

1. Each qualifying deploy credits Bricks to your PlayerProfile, the account that tracks your lifetime totals and spendable balance.
2. The amount scales with two things you control: how much SOL you mine, and how few tiles you spread across.
3. Spreading onto fewer tiles is more “focused”: one tile is the most focused choice and tends to earn the most Bricks per deploy.
4. This creates a trade-off: covering more tiles raises your chance of hitting the winning square in the round, but earns fewer Bricks. Covering one tile earns more Bricks but is a riskier play in the round.
5. Mining in consecutive rounds builds a streak, which adds a bonus on top.

So Bricks reward conviction. You decide each round whether to optimize for the round payout or for Stockpile tickets, and the numbers shift accordingly.

Advanced

The earning intuition follows a simple shape. Let S be the SOL you mined and T be the number of selected tiles. More S pushes Bricks up; more T pushes them down, so the most Bricks come from mining more SOL onto fewer tiles, with a single tile being the extreme.

1. A small private jitter is folded into the calculation. Because the exact factor is not public, you cannot reverse-engineer an input that games the maximum: the reward stays incentive-aligned rather than exploitable.
2. Streaks track consecutive qualifying rounds on your PlayerProfile. Each unbroken round adds a streak bonus, but the bonus is capped, so it rewards consistency without running away.
3. Miss a qualifying round and the streak resets, which is why steady participation matters.
4. Bricks behave as weighted lottery tickets: the Stockpile selects ranked winners, and your odds are proportional to your share of all committed Bricks.

Your balance lives on PlayerProfile, which records lifetime Bricks earned and your current spendable total for entering the Stockpile.

Beginner

Every time you mine a round, you put some SOL onto the board. The protocol takes a small cut of that SOL before the rest goes into play. Think of it like the rake at a poker table: the house keeps a slice, and the remainder is what’s actually in play and paid out to winners.

Step by step:

1. You choose how much SOL to deploy into a round.
2. The protocol skims a small fee off the top: in the current example, 10% of the SOL you deploy.
3. The remaining 90% becomes your real stake on your hidden tiles.
4. If you win, your payout is based on that 90% net stake, not the full amount you sent.

So a fee exists, it’s small relative to what you keep playing with, and it’s the same for everyone. Nothing is hidden: the rate is published and you can see it before you deploy.

Intermediate

The fee isn’t just “lost.” It’s split into parts, and most of it works in your favor as a ZINC holder.

Step by step, where the 10% fee goes:

1. A part funds the Stockpile, the secondary SOL + ZINC jackpot that pays out to bricks-holders, so some of your fee flows back to players.
2. A part pays affiliates, but only if you were referred by one. Referred players also receive bonus bricks, so a binding is a perk, not a tax.
3. A part feeds the Bonanza, the rolling ZINC mega-pot that pays out to round winners.
4. A part funds protocol work, the admin/treasury slice that keeps the system running.

Separately, a buyback slice of your deploy buys ZINC on the open market: steady buy pressure that supports the token’s price and staking yield.

The takeaway: the fee is mostly recycled into player prizes, not pure overhead. The SOL game itself is a near-fair redistribution among players, minus this fee.

Advanced

All fee rates are config-driven, read live from the on-chain Config account in basis points (bps), never hard-coded, and changeable by governance.

Step by step:

1. deploy_total_fee_bps is the total SOL skim at deploy time. It decomposes into deploy_admin_fee_bps (protocol/treasury), deploy_stockpile_fee_bps (feeds the Stockpile), deploy_affiliate_fee_bps (paid to a bound affiliate, or zero if unbound), and a bonanza share that feeds the Bonanza pot.
2. Your net staked = gross × (1 − deploy_total_fee_bps / 1e4). At the example 10% rate, depositing 1 SOL leaves 0.9 SOL of effective stake on the winning-tile math.
3. The buyback is funded separately via a buyback_fee_lamports portion that accrues to the buyback vault and is swapped to ZINC through the Meteora pool by a crank.
4. Implication for EV: on the SOL side, the house edge is approximately deploy_total_fee_bps. Your positive expectancy must therefore come from minted ZINC + Bonanza + Stockpile bricks outweighing that fee. If those rewards don’t clear the edge, the round is −EV.

Beginner

Think of the Bonanza as a progressive jackpot that sits on top of the normal game.

1. Every round, a pile of ZINC tokens is set aside in one shared pot.
2. That pot keeps growing, round after round.
3. Most rounds, the pot does nothing; it just gets bigger.
4. Then, on a rare round, the pot “pops” and pays out all at once.
5. The people who win that lucky round split the whole jackpot between them.

It works a lot like a lottery where nobody wins for a while: the longer it goes without popping, the bigger the eventual payout. In the official example, only about 1 in 692 rounds hits the Bonanza, so when it finally lands, it can be large. You don’t buy a separate ticket: mining a round and landing on the winning square puts you in line for it. The numbers shown in the infographic, like roughly 1 in 692 rounds or 8,450 ZINC, are just examples. The real pot size changes constantly.

Intermediate

Here is how the pot actually fills and who gets to share it.

1. Some rounds end with no winner: nobody’s hidden tiles covered the winning square.
2. On those dry rounds, the ZINC that would have gone to direct winners is redirected into the Bonanza pot instead.
3. The pot keeps rolling forward until a round finally triggers a payout.
4. When that happens, only winning-tile miners in that round are eligible, the people whose tiles actually covered the winning square.
5. Those winners split the entire pot pro-rata: the more you staked on the winning tile, the larger your slice.

The key intuition: dry spells are not wasted. Each no-winner round quietly inflates the prize that some future round will collect. That is why a long streak of misses makes the next hit so valuable. The 1-in-692 figure and any ZINC amounts in the infographic are illustrative examples, not fixed protocol constants.

Advanced

Mechanically, the Bonanza is a dedicated ZINC pot held on the protocol’s Treasury account.

1. The Treasury tracks bonanza_pot, the current undistributed jackpot in ZINC base units, backed by a bonanza_token_account vault.
2. When a round resolves with no winner, a configured share of the direct-winner ZINC (no_winner_direct_winner_zinc_bonanza_share_bps) is routed into bonanza_pot. Dry rounds inflate it.
3. Each winner-positive round is tested against a per-round hit roll, bonanza_hit_divisor (a value of 1 makes every winner-positive round eligible).
4. On a hit, the live bonanza_pot is snapshotted into that round’s bonanza_payout_amount and distributed to that round’s winners, pro-rata to their stake on the winning tile.
5. A long no-winner streak inflates the shared pot, sharply raising the expected value of winning, so it becomes strongly +EV to mine, and to size up for a larger share.

All rates are config-driven and read live from the on-chain Config. Treat any specific divisor or ZINC figure as an example, not a constant.

Beginner

Sometimes a round turns into a “Wildcat,” where a big reserve of its ZINC goes to one lucky miner on top of the normal payouts.

1. A round plays out as normal: miners pick squares and one winning square is revealed.
2. Every so often, that round is also flagged as a Wildcat round.
3. When that happens, the round sets aside a reserve of ZINC for a single winner.
4. One miner is then chosen to receive that reserve.
5. That lucky miner walks away with most of the round’s ZINC reserve, on top of whatever they normally won.

So a Wildcat is just a special round where the ZINC, instead of being shared thinly, piles onto one person. You do not do anything different to take part. If you are already mining and you land on the winning square, you are in the running for the big prize.

Intermediate

Here is how often Wildcats happen and who can win one.

1. Roughly 1 in 4 rounds becomes a Wildcat round. (That ratio is just an example; the real frequency is set by the protocol and can change.)
2. When a round is a Wildcat, most of that round’s ZINC reserve goes to one chosen miner, on top of the normal payouts.
3. Only miners who landed on the winning square are eligible.
4. Among those eligible winners, one is picked to take the Wildcat reserve.
5. Your chance of being picked is not equal for everyone. It scales with how many round Bricks you brought into the round, so committing more Bricks improves your odds.

In short: keep entering rounds, aim to land on the winning square, and stack round Bricks.

Advanced

On-chain, a Wildcat is a weighted single-winner selection layered on top of normal round settlement, driven by the wildcat_* fields on the Round account.

1. At settlement, the round is tested for Wildcat status; if it qualifies, is_wildcat_round is set true.
2. Only miners on the winning tile enter the selection. Each is assigned weight proportional to their round Bricks, and these are summed into total_wildcat_weight.
3. A random wildcat_ticket is generated against that total weight, walking the weighted entrants until the ticket lands inside one miner’s slice.
4. The selected miner is recorded in the wildcat_winner_* fields and receives most of that round’s ZINC reserve, on top of their ordinary pro-rata payout.

Because selection is weight-proportional, your probability of winning is your Bricks divided by total_wildcat_weight (for example, a single dominant miner might hold 69.268% of the weight, just an illustration). More round Bricks means a larger slice of the ticket space and better odds.

Beginner

Think of the Stockpile as a second prize pot that fills up alongside the normal rounds, separate from them.

1. As you mine, you earn a resource called Bricks. Bricks are your ticket into the Stockpile.
2. Every round drops a little SOL and a little ZINC into the Stockpile pot, so it keeps growing.
3. When you want a shot at that pot, you buy in by spending some of your Bricks (along with a little ZINC).
4. The more Bricks you stake, the better your chances of winning.
5. At the end, the pot is revealed and shared out among the top entrants.

So the Stockpile is a recurring jackpot you buy into with the Bricks you have already earned. The example pot art shows numbers like 12.4 SOL and 38,920 ZINC, but those are just illustrations.

Intermediate

Here is how entries actually work.

1. The Stockpile pot grows continuously. Each round that settles adds some SOL and some ZINC to it, so the prize keeps building between rounds.
2. To enter, you spend two things together: your earned Bricks plus some ZINC. You cannot enter on Bricks alone.
3. Each buy-in raises the Bricks-and-ZINC cost of the next entry, so getting in early is cheaper.
4. Your odds scale with the Bricks you commit: winners are selected in proportion to how many Bricks each player put in.
5. When the Stockpile closes, up to 10 ranked winners are selected. They split the SOL + ZINC pot by rank, plus any extra prizes attached to that selection.

So a larger Bricks stake buys both a bigger share of the odds and a better expected payout. The example values (12.4 SOL, 38,920 ZINC) are placeholders, not fixed amounts.

Advanced

On-chain, the Stockpile runs as a parallel cycle to rounds, with its own account and lifecycle.

1. A Stockpile account tracks the cycle: entries[], total_committed_bricks_x10k, winning_ticket, plus pot totals (sol_payout_amount, zinc_payout_amount). Settling rounds feed it a configured share of SOL and ZINC.
2. To enter, you commit Bricks (counted in x10k units) together with ZINC. Each entry is recorded in entries[] and added to total_committed_bricks_x10k.
3. Entry pricing is dynamic. An entry-step config (stockpile_entry_step_bps) raises the next entry’s cost after each buy-in, and a refill-minimum config (stockpile_refill_min_entry_bps) governs re-entry, so the price ratchets up over the cycle.
4. Selection is a weighted-ticket reveal. After close, randomness fixes winning_ticket, and because tickets are weighted by committed Bricks, more Bricks means a higher chance to win.
5. Payout fills StockpileWinners with up to 10 ranked entries, each carrying a share_bps slice of the SOL + ZINC pot, plus any extra SPL prizes.

Because the pot totals, committed Bricks, and the winning ticket all live on-chain, every selection is publicly verifiable. The numbers shown in the art (12.4 SOL, 38,920 ZINC) are examples.

Beginner

Staking is a way to put your ZINC to work instead of letting it sit idle.

1. You lock some ZINC into the protocol’s staking vault.
2. While it is locked, the protocol uses fees it has collected to buy ZINC back from the open market.
3. Most of that bought-back ZINC is destroyed forever. Burning tokens shrinks the total supply, which makes each remaining ZINC scarcer.
4. A smaller slice of that bought-back ZINC is handed out to people who are staking, as a reward.
5. The longer your ZINC stays staked, the more of those rewards build up for you.
6. Whenever you like, you can claim your rewards or unlock your ZINC and take it back out.

So staking earns you a cut of what the protocol buys back, while the bigger burned portion quietly makes the whole supply tighter, a win for holders either way.

Intermediate

Here is how the rewards actually flow, using the example split shown in the art.

1. The protocol collects fees and uses them to buy ZINC from the market.
2. That bought ZINC is split. Roughly 90% is “melted”: burned permanently and removed from supply.
3. The remaining ~10% is set aside as the reward pool for stakers.
4. Your share of that pool is proportional to how much you have staked relative to everyone else.
5. You can claim your accumulated ZINC at any time, or unstake to withdraw your principal.
6. Claiming has a bonus: the ZINC rewards you collect also grant you extra Bricks, the tickets used for the Stockpile jackpot.

These percentages are an example; the real split is config-driven and read live from the chain. The takeaway is that staking yield is funded by buybacks, and the large melted portion keeps ZINC deflationary while you earn.

Advanced

On-chain, staking rewards are factor-based rather than per-block accrual.

1. stake(amount) and unstake(amount) move ZINC in and out of the staking vault, updating Treasury.total_staked.
2. The treasury tracks a global staking_rewards_factor. Your StakePosition stores a rewards_factor_checkpoint from when you last interacted.
3. Claimable yield is roughly balance · (treasury.staking_rewards_factor − position.rewards_factor_checkpoint), so you accrue exactly the factor growth since your checkpoint.
4. Newly funded rewards do not unlock instantly; they vest over staking_reward_vesting_slots, smoothing payouts across time.
5. claim_staking_yield pays out ZINC and also issues Stockpile Bricks at staking_bricks_per_zinc_x10k.
6. The reward pool is fed by melt and buybacks: melt routes ZINC into the shared melt sink, a deflationary action that simultaneously supports staking yield.

Because the factor only ever rises and your checkpoint advances on each action, rewards are deterministic and verifiable.

Beginner

Here is how ZINC supply works, step by step.

1. There is a fixed lifetime supply of 6,538,000 ZINC, the most that can ever exist.
2. ZINC is not all handed out at once. New ZINC is created by mining, the same activity that powers each round.
3. The more SOL people deploy into rounds, the more new ZINC the protocol mints.
4. Mining gets harder over time. As the total supply grows, each round mints less ZINC, much like Bitcoin’s halvings slowly shrink the block reward.
5. So early activity earns ZINC faster, and the rate quietly tapers as the supply approaches the cap.
6. On the other side, fees from the game are used to buy ZINC and permanently destroy it (“melt”).
7. That buy-and-burn removes coins from circulation, working against new minting.

The short version: a hard cap on supply, mining that issues new coins more slowly over time, and fees that quietly burn coins back out.

Intermediate

Now the flows that move ZINC around.

1. Each round measures how much SOL was deployed into it.
2. That SOL volume feeds an emission curve that mints new ZINC for the round. The curve saturates, so doubling volume does not double the ZINC.
3. The round’s freshly minted ZINC is split into buckets. As an example split: roughly 75% goes directly to that round’s winners, about 20% seeds the Bonanza jackpot pool, with the remainder feeding the Stockpile pot and the Wildcat bonus.
4. Winners therefore earn ZINC on top of the SOL pot they already share.
5. Undistributed jackpot ZINC accumulates over time, raising the payoff of future wins.
6. Separately, a slice of every deploy is set aside as a buyback fee, collected in SOL.
7. The protocol periodically spends that SOL to buy ZINC on the market (buyback), then melts what it buys, burning it.

So SOL volume creates ZINC, ZINC is shared between players and prize pools, and fees flow back as a buyback that ends in a burn.

Advanced

The emission engine is a saturating bonding curve with a built-in halving.

1. Per-round mint follows roughly curve_max_round_mint · (1 − e^(−total_deployed / curve_saturation_lamports)). Small deploys mint near-linearly; large deploys flatten toward curve_max_round_mint.
2. curve_saturation_lamports sets where the curve reaches about 63% of its per-round ceiling, so beyond it extra SOL yields sharply diminishing ZINC.
3. A halving factor driven by curve_history_minted scales emissions down as cumulative minting passes successive thresholds, mirroring Bitcoin-style halvings.
4. curve_max_supply enforces the hard cumulative cap (6,538,000 ZINC); minting cannot breach it.
5. The combined effect: ZINC-per-SOL falls monotonically as cumulative supply grows.
6. Against issuance, melt routes ZINC into a shared deflationary sink. Buyback-fee SOL is swapped for ZINC, which is then melted and burned, and the sink also supports staking yield.
7. Net supply is therefore minting minus melt, asymptotically bounded by the cap.

Read treasury.total_zinc_minted and total_zinc_melted with the curve params to estimate the live rate.

Beginner

If you want to buy or sell ZINC, there’s one main place it trades, and the protocol itself is a steady buyer in the background.

Step by step:

1. ZINC lives in a single main trading pool. When you buy or sell, your trade flows through that pool.
2. Every time someone mines a round, a small slice of their SOL is set aside.
3. The protocol uses that set-aside SOL to buy ZINC from the pool.
4. The ZINC it buys is then melted, permanently removed from circulation.

So two things happen continuously: the protocol keeps buying ZINC, which adds demand, and it keeps melting what it buys, which slowly shrinks the supply. That mix of steady buying and shrinking supply is a supportive backdrop, though not a promise about price (markets still move).

Intermediate

The interesting part is the loop, and how it feeds itself.

Step by step:

1. A portion of each deploy’s SOL is routed into a dedicated buyback vault.
2. That SOL accumulates over many rounds until there’s enough to act on.
3. The protocol spends it to buy ZINC in a Meteora pool, the same pool where everyone else trades.
4. The ZINC it buys is melted continuously, so it never re-enters supply.

Why this is a flywheel: the buying creates real buy pressure in the market, while the melting creates scarcity by removing tokens for good. More mining means more fees, so more buying and more burning: the busier the game gets, the stronger both effects become. The melt sink also helps fund staking yield, so holders feel the effect from two directions.

Advanced

Mechanically, this runs through Meteora and an admin/crank instruction.

Step by step:

1. ZINC trades in a Meteora DAMM v2 pool (a concentrated-liquidity AMM on Solana). This is the venue both users and the protocol transact against.
2. A buyback_fee_lamports portion of each deploy_round accrues to the buyback SOL vault, separate from the regular deploy fees.
3. An admin/crank calls run_buyback / buyback, which swaps the accumulated buyback-fee SOL into ZINC through the Meteora pool, then melts that ZINC into the shared melt sink.
4. Regular users don’t touch that instruction. To trade, they swap via aggregators like Jupiter or Meteora, which route orders into the same pool with slippage and price-impact handling.

Because the melt sink feeds staking_rewards_factor, every buyback both tightens supply and lifts staking yield. The buyback is a protocol-driven tailwind, not an action any single user takes, and every leg of it is verifiable on-chain.