Mine tokenized stocks
with an active browser tab.

Start mining in six steps

1. Install and unlock a compatible wallet. Add Solana and keep enough native SOL for transaction gas.
2. Hold at least 100,000 STONKS. Eligible balance is liquid wallet balance plus principal already placed in voluntary locks. Ordinary mining requires no deposit.
3. Open the Dashboard and connect. Verify the wallet prompt shows Solana, Solana mainnet, and the intended site origin.
4. Press Start Mining. Sign the login challenge and explicit START message. This authenticates the session; it does not transfer tokens.
5. Keep the tab visible and online. The client sends a heartbeat every 10 seconds. Hiding, refreshing or closing the page stops the session, and it never resumes automatically.
6. Claim when finalized stocks appears. Potential personal rewards are intentionally hidden. The claimable number appears only after epoch settlement and on-chain root publication. Claiming always withdraws the full available delta.

Current fixed product settings

The current simulation baseline is 3% total trader fee and 2% project fee, but launch fees remain manual parameters. Reward accounting depends on the SOL actually received by the protocol collector, not on a hard-coded fee percentage

What counts as active mining?

A wallet earns weight only after an explicit START and while its authenticated WebSocket session remains alive in a visible browser tab. Reloading, hiding the page, losing connectivity, switching wallet accounts or closing the computer stops mining. There is no background, offline or automatic mining

Why splitting wallets does not help

Weight is linear. One wallet holding 1,000,000 tokens has the same aggregate base weight as ten eligible wallets holding 100,000 each for the same active time. There is no free reward per wallet, no wallet-age multiplier and no base faucet

Balance changes

Purchasing more tokens is allowed and is reflected by later on-chain samples. Selling does not confiscate a wallet balance. Falling below the 100,000-token threshold prevents continued eligible sampling, and the user must restore eligibility and explicitly start a new session

The funding loop

1. STONKS trades against native SOL on the PONS bonding curve and, after graduation, through the PONS V4 pool.
2. Creator/project fees that actually reach the allowlisted collector are accounted as committed SOL. Fees retained elsewhere are not counted as miner backing.
3. When committed SOL is worth at least $10, the keeper requests competing approved routes and uses the complete available committed SOL balance.
4. The buyer verifies router and function selector allowlists, exact SOL input, deadline, max spend, minimum stocks output, oracle floor, freshness and Stocks pause state.
5. Actual stocks received is recorded. A failed, stale or unsafe route leaves SOL committed and retries later; it cannot force a worse arbitrary route.

How rewards become claimable

Each five-minute epoch closes with sampled mining weights and finalized stocks funding. The reward engine allocates actual stocks output proportionally, carries empty-miner funding and rounding dust forward, and builds a cumulative Merkle entitlement root

An independent verifier rebuilds the candidate from append-only evidence. The publisher may sign only an exact manifest digest whose epoch, root, allocation and observed vault backing agree. Personal pending estimates are not shown because they can change before finalization

Claim rules

• No minimum amount and no expiry while the project remains operational.
• The user pays SOL gas.
• A claim withdraws all currently available Stocks; partial claims are not offered.
• Unallocated dust remains in accounting and carries forward.
• An underpayment can be raised in a later cumulative correction root. A published overpayment is never clawed back from a user.

Trade liquidity for predictable power

Locks are optional deposits into the lock vault. Locked principal remains part of the 100,000-token eligibility calculation. The multiplier is fixed when the position is created

Early withdrawal is always possible. The displayed penalty declines linearly from its maximum to zero at unlock. The penalty is burned, and the remaining principal returns to the wallet. Partial withdrawal conserves the position’s accounting and does not create extra boosted weight

Temporary power paid in STONKS

Boost payment is burned. Price captures 70% of the modelled incremental reward value and is bounded between 0.001% and 1.00% of eligible balance. Quotes expire after 60 seconds. No more than 20% of system base weight may be simultaneously boosted

Boosts are intentionally additive, start in a future epoch and cannot overlap. This blocks last-second reward capture, multiplicative stacking and quote replay

What everyone can see

• Rewards Ready: USD value of Stocks available for future allocation.
• Total Stocks Mined: current USD value of finalized stocks allocated across all miners.
• Active Miners: currently alive mining sessions, not registered wallets.
• Tokens Burned: aggregate STONKS destroyed through approved mechanisms.
• Current Epoch / countdown: the active five-minute settlement window.
• Stocks Purchased: lifetime protocol spend and cumulative Stocks acquired.

Aggregate figures create a shared public view without disclosing each miner’s pending allocation. A connected wallet sees only finalized, currently claimable personal stocks

Fail-closed by design

• No wallet-age check, free wallet weight or base reward per address.
• Signed challenge/START authentication and single-use session replacement.
• 10-second samples are backed by RPC quorum and append-only audit evidence.
• Independent finalized-chain and weight RPC quorums reject stale or disagreeing endpoints.
• Purchase jobs are idempotent, re-quoted and guarded against duplicate execution.
• Reward roots require independent verification and exact vault-backing conservation.
• Purchase, root, boost and verifier keys are separate; ADMIN is not loaded into application containers.
• Critical readiness failures keep operational signers disabled.

Main components

The backend, verifier, market observations and operational signers are centralized at launch. User claims remain on-chain and user-paid, but new mining samples and settlements depend on those services

Read before participating

• Token risk: $STONKS can lose most or all of its market value.
• Stocks token risk: tokenized stock availability, redemption, restrictions, liquidity or issuer rules may change.
• Smart-contract risk: tests and audits reduce risk but cannot prove the absence of every defect.
• Centralization risk: sampling, settlement and operational signers depend on team-run infrastructure at launch.
• Oracle and route risk: stale prices, paused assets or thin liquidity can delay purchases.
• Regulatory risk: tokenized-stock rewards may be restricted by jurisdiction or wallet eligibility.
• Browser availability: sleeping devices, hidden tabs and network loss stop mining immediately.
• No guaranteed yield: rewards depend on actual fees, stocks purchases, active weight and protocol uptime.

Common problems

Key terms

For the source-of-truth engineering policy, teams should use config/product-policy.json and CANONICAL_PRODUCT_POLICY_v0.1.md in the handoff package