The complete mining pool guide

What XMR.gives does

XMR.gives is a Monero mining gateway, account portal, reward ledger, and raffle administration system. Mining software connects to xmr.xmr.gives. The gateway forwards valid RandomX work to the mining backend while retaining the registered worker identity needed for account attribution and raffle ticket records.

The product has three surfaces. Public pages provide current pool statistics and connection information. The client dashboard provides wallet, worker, balance, raffle, and referral information for one miner account. The role-protected admin dashboard provides user oversight, ledger adjustments, payout records, reserve records, raffle settlement, externally audited winner entry, and email-outbox controls.

From registration to the first share

1. Create an account.Open registration, enter an operation name, reachable email address, valid primary or subaddress Monero wallet, and a password of at least eight characters.
2. Choose a route.Use port 3334 for the weekly program, port 3335 for NiceHash-compatible rentals, or one of the dedicated accepted-share raffle ports described below.
3. Configure the miner.Select RandomX/Monero, use your dashboard worker name as the username, use x as the password, and leave Stratum TLS off.
4. Confirm activity.Check the miner console for accepted work, then review the dashboard and raffle page. Pool-wide stats update independently from account attribution.
5. Keep the wallet current.Payments are associated with the wallet saved at payout time. Changing it does not rewrite historical payout records.

Endpoints and required fields

Standard XMRig configuration

xmrig -o xmr.xmr.gives:3334 -u YOUR_WORKER_NAME -p x -a rx/0

NiceHash rental configuration

Algorithm

RandomXmonero

Hostname

xmr.xmr.gives

Port

3335

Username

Your registered worker name

Password

x

TLS/SSL

Off

Worker matching accepts the account ID, full account email, or assigned worker name. A suffix such as worker.rig02 falls back to the base worker name before the first period. Unknown worker identities can receive mining work, but cannot be attributed to an account or receive share-based raffle tickets. Always use the exact value shown on Connect miners.

Identity, sessions, and wallet changes

An account combines an email login, password hash, role, display name, payout wallet, assigned worker name, referral code, and raffle-email preference. Registration creates a miner role; administrator roles are provisioned operationally and cannot be selected through public registration. An administrator can also have a mining profile and participate under the same published rules.

The wallet validator accepts standard Monero addresses beginning with 4 and subaddresses beginning with 8. Integrated addresses are accepted when their length and Base58 character set are valid. The system never requests or stores a wallet seed, private spend key, private view key, exchange password, or two-factor code.

Use Dashboard → Connect → Payout wallet to replace an address. Existing ledgers and prior payout references remain immutable. The new address is used for future operational payouts and future raffle eligibility displays.

How the ledger works

The standard accounting mode is PPLNS. Mature mining rewards are credited as earned ledger entries. Raffle-route settlement begins with a gross XMR amount and accepted-share totals for the selected round. Gross rewards are apportioned by each account’s share count, the published route allocation is deducted, and the remainder becomes the miner’s unpaid balance.

The launch pool fee is 0%. The weekly route’s raffle allocation is 1%. Dedicated routes publish their larger mandatory allocation before connection. The configured minimum miner payout is 0,003000 XMR.

Miner payouts are manual. An admin records an amount and transaction ID only after using the approved payment channel. A payout cannot exceed that miner’s unpaid balance. Admin adjustments can add a manual credit or deduct an explicitly selected pool, electricity, or hardware charge; deductions cannot exceed the available unpaid balance and create matching reserve-ledger entries.

Banked value is the sum of operator-side ledger credits less recorded reserve withdrawals. A reserve withdrawal cannot exceed that balance. Recording a reserve withdrawal does not broadcast a transaction.

Programs, prizes, and schedules

Prize values are displayed as whole XMR amounts because configured prizes are whole coins. Allocation percentages apply to gross mining rewards on that route. A miner chooses the allocation by choosing the endpoint; it is not a dashboard toggle and cannot be changed after a share has been submitted.

Accepted-share programs are Standard Raffle, MAX, All-In. Ticket numbers are random, unique seven-digit values within a program round. A duplicate share submission cannot create a second ticket because the gateway stores a unique share key.

What happens at draw time

At the scheduled cutoff, the open round moves to a drawing state and its ticket population is frozen. A potential winner must have at least one ticket in that round and at least 3,600 seconds of recorded mining-session time. Idle sessions stop accumulating after the activity freshness window expires.

LoveMedia Foundation NPC is the external source of truth for winner selection. The web application does not run or claim to reproduce the external random selection. An authorized admin enters the winning wallet supplied by LoveMedia. The system rejects wallets that are not in the eligible set, records one result per prize rank, and completes the round after all configured prize ranks have winners.

The winner receives a congratulatory email. Opted-in participants receive an announcement showing only the first four and final four wallet characters. The dashboard shows the masked result and whether reward allocation evidence has been recorded. Funding evidence, reward allocation evidence, and actual payment transactions are separate records.

Every client page

Dashboard

Hashrate snapshots, unpaid and paid totals, accepted and rejected shares, blocks, connection summary, raffle counts, referral link, email preference, and recent balance ledger.

Connect

Current payout wallet, wallet-change form, standard and NiceHash fields, and the dedicated raffle addresses.

Raffles

Current program rules, allocation, endpoint, schedule, ticket totals, the latest 50 personal tickets, pending audits, masked results, and payout state.

Pool Stats

Live pool and chain measurements refreshed every three seconds without browser or server caching.

The client sidebar remains part of every /dashboard/* route. Authentication failures redirect to login; miner accounts cannot open administrator pages.

Administrative workflows

Overview

Registered miner count, aggregate stored hashrate, unpaid liability, paid lifetime total, reserve balance, and master-wallet summary.

Users

Account identity, wallet, worker activity, blocks, gross earned amount, deductions, paid amount, and current amount owed.

Payouts

Manual credits, selected deductions, miner payout recording, transaction references, and complete miner ledger review.

Banked

Operator reserve composition and reserve-withdrawal records, capped to the recorded reserve balance.

Raffles

Round funding evidence, reward settlement, manual ticket creation, eligible-wallet review, external winner entry, LoveMedia reward allocation evidence, and failed-email retry.

Pool Stats

The same uncached live statistics shown publicly and to miners.

Settings

Master collection wallet update and administrator password change.

Freshness and interpretation

Public, client, and admin statistics request the latest aggregate mining-network data through the server. The browser polls every three seconds and adds a timestamp query parameter. The API and upstream requests use no-store behavior and send explicit no-cache response headers.

Pool hashrate is estimated from current sharechain difficulty divided by block time. Active miners and block history are aggregate values from the live statistics source. Mainchain and sharechain heights describe different chains and should not be expected to match. “Reconnecting” means the current source request failed; it does not by itself prove that submitted mining work has stopped.

Account hashrate and share counters are separate stored account metrics. They are not derived by the public stats component, so aggregate stats can remain live while a worker’s account row is stale or unattributed.

Winner and community email

Raffle result emails are inserted into a durable outbox. A dedicated worker claims pending rows, sends through authenticated SMTP with STARTTLS, and marks each row sent or failed. Event keys prevent the same result email from being enqueued twice for one recipient.

Winners receive the program, prize rank, amount, full payout wallet, and referral link. Other opted-in miners receive a masked winner wallet and their own referral link. Every promotional result email contains a tokenized unsubscribe link. Unsubscribing disables future raffle announcements but does not remove the account or affect mining.

Controls and responsibilities

• Passwords are stored as bcrypt hashes, never plain text.
• Login sessions use signed, HTTP-only, same-site cookies with a seven-day lifetime; production cookies require HTTPS.
• Server actions re-check the account role before admin operations.
• The public config API omits the master collection wallet.
• Winner announcements mask wallet addresses for non-winners.
• Mining Stratum endpoints are TCP without TLS; do not reuse a sensitive password as the Stratum password.

Users are responsible for entering an address they control and retaining their own wallet recovery material. Operators are responsible for host security, SMTP security, backups, transaction reconciliation, tax treatment, promotions law, eligibility terms, prize funding, and incident response.

Read-only endpoints

These endpoints are read-only and unauthenticated. Account data, wallets, tickets, payouts, and administrative operations are not exposed by a public JSON API.

Fast diagnosis

Invalid work after login

Confirm the endpoint and algorithm. NiceHash rentals must use port 3335 with RandomXmonero; standard XMRig uses rx/0. TLS must be off.

Accepted work but no raffle ticket

Confirm you selected an accepted-share raffle port, used the exact registered worker identity, and the upstream response marked the share accepted. The weekly route uses a block-based rule.

Worker appears anonymous

Replace a wallet address or arbitrary username in the miner’s user field with the worker value shown in Dashboard → Connect.

Stats show reconnecting

Refresh after a few seconds and compare the miner console. Public aggregate-stat failure is independent from Stratum connectivity.

Winner wallet rejected

The round must be in drawing state, the wallet must exactly match an eligible account, and that account must have a ticket plus at least one hour of recorded session time.

Email remains failed

Admin should verify SMTP health, inspect the outbox error, correct the mail service, then use the retry control. Duplicate event protection remains in place.

What is not automatic

The application does not broadcast Monero payments, custody private wallet keys, verify exchange transfers, select raffle winners, or guarantee that a prize has been funded. It records the funding and reward allocation evidence supplied by authorized administrators.

The weekly program is configured for eligible-block tickets. The Stratum bridge intentionally does not convert ordinary accepted shares on that route into tickets; eligible block attribution requires the operations ingestion process or an authorized manual ticket. Share-based ticketing is automatic only on Standard Raffle, MAX, and All-In.

Account/ledger data and raffle data are host-local stores designed for this single application host. A complete disaster-recovery plan must back up both stores together. Running multiple writable web instances without a coordinated database migration would risk inconsistent state.