Gems

what is Gems

Gems is a launchpad for mineable tokens on Solana. A token here has a fixed supply that is released round by round, and mining is the only way new units reach anyone.

  1. 01

    launch

    Choose the name, ticker and metadata. Supply and mining rules are fixed at launch. No creator or token admin can change them later.

  2. 02

    stake

    Deposit token units into the excavation. That deposit is your weight for the round. It stays yours, and you can withdraw it once the round it weighted has settled.

  3. 03

    dig

    Your browser builds a proof each round and submits it. Everyone who submits splits that round's emission in proportion to what they staked, not by who solved it first.

  4. 04

    claim

    Rewards accrue as each round closes. Claim them when you want, without stopping mining.

Mining pays Solana transaction fees every round. This site is showing demo data. Market and mining values are not live.

read the docs
launch

security and status

This program holds a mint authority and, once anyone stakes, other people's tokens. Below is what has actually been demonstrated and what has not, kept apart on purpose.

the ledger

Proven means there is an artifact or a test run behind it today. Unproven means the step has not been taken, not that it failed. Nothing here is described as safe, audited or verified.

  • Mint authority is revoked in the launch transaction

    Compiled-program integration suite, including metadata and authority assertions

    proven

    §2.4

  • No instruction accepts a token creator as a signer

    Program source and independent review of the on-chain scope

    proven

    §2.1

  • A solution for one token is rejected by another

    Tenant isolation and cross-token replay cases in the integration suite

    proven

    §6.2

  • Splitting a position across wallets does not multiply weight

    Wallet-splitting case in the integration suite

    proven

    §4.1

  • Direct transfers into a stake vault credit nobody

    Donation case in the integration suite; liabilities stay bounded by the balance

    proven

    §4.6

  • A lapped round stops resolving instead of returning newer numbers

    Ring eviction covered by unit tests and by the integration suite

    proven

    §4.5

  • Settlement cannot pay out more than a round reserved

    Integer truncation, exercised across three weighted rounds with exact balances

    proven

    §4.4

  • Proof verification fits the compute budget

    Measured at 219,715 units against a 300,000 unit request

    proven

    §5.5

  • The SBF build reports no stack-frame diagnostic

    Verifier log grepped for stack, frame, exceed and error matches

    proven

    §9.2

  • Two independent reviews found no remaining high-severity issues

    One program review and one web transaction review, each within its reviewed scope

    proven

    §9.2

  • The exact current artifact completes the deployed acceptance path

    Not run. Two tokens, two wallets, several rounds, settle, claim and withdraw against a deployed program

    unproven

    §9.3

  • The release build is reproducible from committed source

    The payload stages and checksums, but records a local build mode. The container build has not run in CI

    unproven

    §9.3

  • The real browser wallet path works against the reviewed artifact

    No preview has been run against a deployed version 2 program

    unproven

    §9.3

  • An independent security firm has reviewed the program

    Not commissioned. It is a stated prerequisite before mainnet, not a completed step

    unproven

    §9.3

  • Upgrade authority sits behind a timelocked multisig

    Mainnet deployment still needs an explicit operational key choice

    unproven

    §9.4

  • The source is publicly readable

    No public repository is configured, so the citations throughout this site are not yet checkable by you

    unproven

    §10.3

check it yourself

The useful checks do not require trusting this site. All three read the cluster directly.

  1. Confirm a token's supply cannot grow

    spl-token display <MINT> --url mainnet-beta

    Mint authority and freeze authority must both read as none. If either is set, the supply is not fixed, whatever any page says.

  2. Confirm the program is what you were told it is

    solana program dump <PROGRAM_ID> out.so --url mainnet-beta && sha256sum out.so

    The reviewed version 2 build hashes to 426c36de596e94dc50f27e30be9337d111a3f531888c1d4b1fde3171852cbd34. A different hash means a different program, which is currently the expected result: the reviewed build has not been deployed yet.

  3. Read a token's frozen parameters

    solana account <CONFIG_PDA> --url mainnet-beta

    The config PDA is derived from the seeds lode-config and the mint. Supply, round length, halving interval, difficulty target and creator allocation are all in it, and no instruction writes to any of them after launch.

standing prohibitions

Recorded in the repository as rules for anyone working on it, so they survive a change of contributor rather than living in someone's judgement.

  • No admin, update instruction or economic setter may be added to a launched token.

  • The token mint may never be removed from the Equihash input block.

  • The creator allocation ceiling may not be raised above 10% without an explicitly recorded decision.

  • No random-payout feature: no jackpots, lotteries or prize draws.

  • No difficulty retargeting.

  • No claim that a deploy, test run or mainnet flow succeeded without the actual output.

reporting

There is no published security contact yet. Saying so is more useful than publishing an address nobody is committed to monitoring. A disclosure channel is a prerequisite for mainnet alongside the independent review, and neither has been completed. §9.3