Your first Gold Rush claim, mined for you.

Service status & request lookup

Understanding your claim record

A reimbursement is not immediately spendable money. Eligible included losing or late claims can receive a quantum credit to the claim’s payout address, based on the actual carrier fee and capped at 0.01 BLK. This is not an immediately reusable BLK refund. These generated credits require 500-block maturity and cannot be spent before migration height 6,193,000; the earliest eligible height is max(inclusion_height + 500, 6193000), subject to the credit remaining unspent and all consensus and authorization checks. They cannot fund further claims during Gold Rush. Invalid, expired, duplicate, nonselected or zero-fee claims may receive no reimbursement.

• Historical credits and winning claims are different. Legacy receipts remain available, but are not certified winning awards. A fee-only reimbursement settles an attempt; it is not the winning award.
• During Gold Rush, synthetic credits are phase-locked accounting and are not spendable. From migration height 6,193,000, authenticated unspent credits may become spendable when output maturity and all applicable consensus and authorization conditions are satisfied. The earliest eligible height is max(maturity_height, 6193000), not migration start plus a new blanket maturity period. A record alone does not establish a winning award, current spendability, exchange support, or guaranteed yield. See the roadmap and migration timeline.
• A winning claim's amount depends on its solve height and consensus outcome. The schedule is halving-aware; no fixed amount is promised.
• Inspect the evidence. A complete credit reference links to the explorer and can be checked with gettxout on a compatible synced node. New request receipts report verified outcomes from the worker; historical pool records do not certify a winning disposition. See the reproduction contract.

Request rules & safety

• 50 included-claim attempts per address, for its lifetime. Pending, rejected and no-send work do not count. An included loser or late claim counts once even if its fee is reimbursed. A chain reorganization does not restore used attempts, and re-including the same transaction does not count twice.
• Submissions stop after a verified win. The worker verifies the outcome and completes the handoff. While an outcome is uncertain, it reconciles that claim instead of sending a replacement. There is no promise of a win within 50 attempts.
• The shared daily spending limit is separate. The worker permits at most 25 nonrefundable fee reservations per UTC day across its shared budget. New addresses can queue when that budget is full; this does not promise immediate work. Checking progress does not spend a fee.
• The pool applies its own address and IP limits. A service response such as "already awarded" may refer to historical pool records, not a certified winning award.
• New requests close when processing is paused or readiness is unverified.Existing records stay accessible. Checking a request does not start mining or spend a fee.
• Save your receipt ID. Use it to check the new worker's progress. Repeating the same address submission after human verification recovers the same receipt without resetting its allowance. Receipt IDs are read-only tracking references, not confidentiality credentials. Historical file counters, when shown, are labeled separately and do not count new attempts or verified wins.
• No purchase, no deposit, no keys. We never ask for a private key, seed, or payment. A quantum address is all that's needed — and it's public by design.

Nobody from this project will ever DM you asking for a seed phrase or wallet file. See verified channels if someone claims otherwise.

How to get a quantum address

Choose your system, then follow the shared steps below. Use the current published release in downloads; older screenshots or posts may name a superseded version.

1. Install and sync the latest published production node — run-a-node guide (verify your download first: verify).
2. Confirm the node is synced to the intended network: a recent tip, blocks == headers, initialblockdownload: false, and peer connectivity. Matching heights alone are not enough. In the wallet console, run getnewquantumaddress.
3. Back up the wallet after creating the address. Quantum keys are non-HD and are not recovered from the legacy seed alone. Keep the backup private; submit only the public address.
4. Return to the claim form and paste only the resulting public blk1s… address. Check live service availability before submitting, or look up an existing request while intake is closed. Keep any request receipt for your own follow-up.

Stuck on a step? Use the public support channels on the verified community page. Share your OS, release and a redacted error message, never a wallet file or secret. To follow later releases, subscribe to RSS or Atom.