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 pool's collection wallet while retaining the registered worker identity, accepted difficulty, selected route, and account needed for internal reward attribution.

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, choose a unique mining worker name, and enter an operation name, reachable email address, valid primary or subaddress Monero wallet, and password of at least eight characters. Confirm the age, eligibility, Terms, and Privacy statement; raffle marketing consent remains optional and separate.
2. Choose a route.Use port 3334 for the weekly program, its rental alternate on port 3335, or one of the dedicated raffle ports described below. Every advertised port accepts NiceHash and Mining Rig Rentals.
3. Configure the miner.Select RandomX/Monero, use the prominent dashboard worker name as the Stratum username, leave the mining password blank or enter any placeholder your software requires, 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.Your registered wallet is the destination for an operator payout, not the Stratum username. 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 -a rx/0

NiceHash rental configuration

Algorithm

RandomXmonero

Hostname

xmr.xmr.gives

Port

3335

Worker / username

Your registered worker name

Password

Optional; any value accepted

Difficulty

Automatic or provider-requested fixed value

TLS/SSL

Off

Mining Rig Rentals configuration

Algorithm

RandomX (XMR)

Hostname

xmr.xmr.gives

Port

The selected raffle port

Worker / username

Your registered worker or worker.rig-name

Password

Blank, or x when its form requires a value

Difficulty

Automatic per connection

TLS/SSL

Off

Every branded route ignores Stratum password authentication. A login with no password property, an empty value, x, or any arbitrary non-sensitive placeholder is normalized to the same upstream placeholder. Mining software may still make its password field visually required; enter x in that client without using your website password. 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 their accepted work cannot be credited to an account. Never use a wallet address as the worker. Always use the exact worker shown on Connect miners.

All five advertised ports accept XMRig, NiceHash, and Mining Rig Rentals RandomX connections. Share difficulty adjusts automatically and independently for each socket, allowing low-rate CPUs and large rentals to share an endpoint. A provider that insists on a fixed value can use YOUR_WORKER+DIFFICULTY or password d=DIFFICULTY; absent or invalid hints use automatic difficulty. There is no application-level limit on concurrent rigs. Use dot suffixes to identify them while retaining one account.

Weekly ports 3334 and 3335 are two working endpoints for the same Weekly program. They are on the same hostname and backend, so they are not geographic redundancy. A rental marketplace that requires two genuinely independent pools for refund protection still requires a second operator, hostname, network path, and backend; do not describe two ports on this host as independent infrastructure.

Dashboard → Connect is the complete entry surface. It shows every raffle URL, the Weekly NiceHash alternative, credentials, algorithm, TLS setting, payout-method selector, PPS+ eligibility countdown, allocation, single prize, ticket rule, minimum round activity, scheduled draw, current cutoff, current tickets, and an account-specific live feed. The initial snapshot is rendered with the page and accepted work, hashrate, unsettled work, and ticket totals refresh every two seconds without caching.

How speed changes the accepted-share target

The service estimates an account's recent mining speed from upstream-accepted difficulty. It uses the stronger of the rolling ten-minute and one-hour estimates so a brief reporting dip does not immediately move an active miner into a lower band. The applicable target is recorded with ticket progress and applies to every raffle route.

A good share means a submission the upstream pool accepts. Submitted, rejected, stale, duplicate, or locally reported work does not advance the counter. Share difficulty still determines reward weight, but each accepted submission counts as one good share for ticket progress. Reaching a share target before one hour stores the progress; an accepted share after the hour can issue the completed ticket batch. Partial progress carries within the round.

When measured speed is above 12 kH/s, the miner receives 10% off every published raffle allocation. This is a relative discount: Weekly changes from 1% to 0.9%, Standard from 20% to 18%, MAX from 40% to 36%, and promotional All-In from 60% to 54%. The dashboard displays the active rates and the service queues a one-time account email when the benefit first activates.

XMR.gives Miner Beta v1.0.0

XMR.gives Miner is an Electron desktop controller for miners who do not want to maintain command-line XMRig configuration. Beta v1.0.0 provides a Linux x86-64 AppImage and Windows x64 NSIS installer. The Windows beta is explicitly unsigned while Microsoft Artifact Signing identity validation and Public Trust setup are completed. The download page publishes each artifact's SHA-256 digest and a machine-readable release manifest.

Enter the exact worker from Dashboard → Connect. One managed XMRig process then mines the four branded routes in weighted time segments. Allocations must total exactly 100%. A smooth weighted scheduler spreads segments across the cycle and converges to the selected percentages over time; a short session can differ because a segment cannot be split. One process avoids loading several multi-gigabyte RandomX datasets simultaneously. Accepted and rejected totals carry across route changes.

CPU reserve

80% thread hint, low process priority, and a 48-second mining / 12-second reserve interval.

GPU support

AMD and Intel use OpenCL; NVIDIA uses the separately selected XMRig CUDA plugin.

Hardware caveat

GPU behavior depends on vendor drivers. An exact cross-vendor 80% utilization ceiling cannot be guaranteed.

Engine install

Pinned official XMRig and XMRig Proxy archives are downloaded and rejected unless SHA-256 matches.

Local controls

Mining telemetry and pause/resume use an authenticated XMRig HTTP API bound only to localhost.

Shutdown

Managed miner, proxy, and node processes receive a graceful stop and are force-stopped only after timeout.

Proxy and node choices

XMRig Proxy is a Stratum gateway for downstream rigs. It forwards to one selected XMR.gives route and does not require a Monero node. Local-network listening is opt-in and requires firewall control; the listener must not be exposed unauthenticated to the internet. A Monero node is optional and independent from both pool accounting and the proxy.

Full node retains the complete blockchain and can serve complete history to peers. Pruned node, described in the app as partial storage, still downloads and validates the blockchain but discards most historical block data after validation. It uses substantially less storage and serves less old data. Off mines through XMR.gives without local chain storage. The app runs a user-selected official monerod; it never downloads wallet software or requests wallet keys.

Application updates

The app checks the public release policy at /api/desktop/update-policy at startup and every six hours. Optional updates can be postponed. A mandatory policy is active when the installed version is below the configured minimum; it blocks starting the miner and proxy until the update is installed. Installation first stops every managed process, then closes the app and invokes the platform updater. Admin must publish installer files and update metadata before increasing Latest version or Minimum allowed version.

Microsoft Artifact Signing runbook

Artifact Signing is the planned signing authority for publicly distributed XMR.gives Windows software. The target is a Public Trust certificate profile because test and private profiles are not publicly trusted for ordinary internet distribution. The profile can sign compatible Windows executables, installers, libraries, and scripts through Microsoft-supported integrations; macOS notarization and Linux package-signing remain separate platform workflows.

Admin → Artifact signing stores the minimum operational configuration: individual legal name and contact/address mirror, tenant and subscription IDs, resource group, region, account name, portal identity-validation ID and state, profile name, expected current certificate thumbprint and serial number, and selected machine-credential mode. The certificate identifiers are public verification guards, not credentials or Azure profile locators. It never accepts government identity documents, Social Security numbers, dates of birth, bank or utility documents, private keys, or Azure client secrets. The file is host-local with mode 0600; Azure's portal remains the authority for validation status.

Eligibility and identity validation

Microsoft currently offers Public Trust to individual developers in the United States and Canada. For the requested US individual route, the Azure billing account must be Individual and the billing legal name and address must exactly match the intended certificate identity and verification evidence. Create the Artifact Signing account first, assign the human operator Artifact Signing Identity Verifier at account scope, then start an Individual → Public identity validation in Azure portal. Microsoft does not expose this identity step through CLI or API. The operator follows the emailed trusted-verifier flow and handles supporting evidence only there. Processing is normally 1 to 20 business days and can take longer.

Account, profile, and RBAC

1. Register the provider.Register Microsoft.CodeSigning and install the current artifact-signing Azure CLI extension.
2. Create the account.Create a globally unique Artifact Signing account in the selected resource group and region. The signing endpoint must match that region exactly.
3. Validate the individual.Complete Public identity validation only in Azure portal and copy the completed Identity validation ID.
4. Create a Public Trust profile.Associate it with the completed identity ID. Public Trust Test is for development and is not a substitute for public trust.
5. Authorize the build identity.Assign Artifact Signing Certificate Profile Signer at certificate-profile scope. Owner alone does not grant the service-specific signing permission.
6. Use non-interactive credentials.Prefer workload identity/OIDC or managed identity. A service-principal secret, when unavoidable, belongs only in protected build environment variables.

Protected management API

Signing and verification

On a controlled Windows build agent, install the matching x64 Windows SDK SignTool and Azure Artifact Signing dlib. The repository's scripts/sign-artifact.ps1 accepts one or more Authenticode-compatible artifacts. It creates temporary metadata, signs with SHA-256, timestamps through http://timestamp.acs.microsoft.com, verifies the complete signature chain with signtool verify /pa /all /v, and compares the returned signer thumbprint and serial against the expected current certificate before printing SHA-256 and deleting temporary metadata. Artifact Signing certificates are short-lived and rotate, so confirm the expected identifiers before each release and retain the trusted timestamp.

A release is not signed merely because Azure configuration exists. The final downloaded bytes must pass signature verification, the published digest must be computed after signing, updater metadata must match those signed bytes, and installation/update must pass on a clean Windows VM. Signing changes the file digest, so an unsigned checksum must never be reused for a signed replacement.

XMR payments and BTC conversion requests

Dashboard → Withdraw provides two manually processed methods. The minimum request is 0,003000 XMR. Amounts use up to five decimal places and cannot exceed the currently available balance. A submitted request immediately reserves the complete requested XMR amount so it cannot also be selected in an operator batch.

Raffle prizes are added automatically to the winner's available balance. With the current 0% XMR withdrawal fee, an XMR request to an XMR address has no withdrawal deduction. For BTC, the dashboard shows XMR reserved, the 15% fee, net XMR value, and a live reference estimate. The estimate is not a locked quote; after payment, history shows the actual BTC delivered and its transaction or immutable exchange reference.

1. Choose a method.Select XMR for direct Monero payment or BTC for conversion. The method sets the destination network and fee.
2. Enter amount and destination.Use a valid Monero address for XMR or valid Bitcoin mainnet Base58/Bech32 address for BTC. Check every character.
3. Review the calculation.Confirm the complete amount reserved, fee deducted, and net payment or conversion value.
4. Submit and track.The request becomes pending. You can cancel it and restore the full amount until an administrator locks it for processing.
5. Admin locks and processes.Locking prevents a cancellation race. Admin then sends or converts externally and records evidence; rejection returns the full reserved amount.

Identity, sessions, and wallet changes

An account combines an email login, password hash, role, display name, payout wallet, unique worker name, referral code, Terms acceptance version and time, and raffle-email preference. A signup worker is normalized to lowercase, must contain 3-32 letters, numbers, hyphens, or underscores, and cannot duplicate another worker case-insensitively. 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, but legal disqualification rules still override technical ticket eligibility.

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.

The pool's mining backend uses one operator-controlled collection wallet. A miner's registered wallet is stored separately as that account's payout destination. Use Dashboard → Connect → Payout wallet to replace it. Existing ledgers and prior payout references remain immutable.

How the ledger works

Every accepted Stratum submission is recorded with its account, route, unique share key, timestamp, difficulty, effective payout method, reward-method terms stamp, and raffle allocation. Difficulty is the work weight, so a higher-difficulty NiceHash share is worth proportionally more than a lower-difficulty share. Payout-method and raffle rates are prospective: historic accepted work keeps the values stored when it was accepted.

PPLNS reward method

Pay Per Last N Shares follows confirmed pool receipts. A mining reward exists only when the pool finds a Monero payout block, and only qualifying work still inside the current share window participates. Accepted shares are proof of work, not hourly wages. A miner can work for hours and receive no XMR when no block is found while their work remains in the window. PPLNS has no minimum speed or six-hour eligibility rule.

The PPLNS pool fee is 0%. The complete reward-method calculation is disclosed in the Terms of Service presented during signup and in signed-in calculation records. Historic accepted work keeps the terms stamp recorded when it was accepted.

PPS+ reward method

PPS+ is an internal expected-value method backed by a recorded operator reserve; the upstream pool remains PPLNS. Expected gross value is share difficulty / sampled network difficulty × sampled block reward. The Terms-defined reward factor creates the PPS+ reward base, and the Terms-defined PPS+ pool fee plus route raffle allocation are deducted from that base.

Exact PPS+ economics are disclosed in the Terms of Service presented during signup and retained in ledger and admin audit records for the affected account.

The account must sustain 10 kH/s or more for 6 continuous hours. The rolling one-hour average and complete-session average must both qualify. The timer starts with the first registered rig connection. All account rigs are measured together; one rig disconnecting is harmless while another remains active. A complete disconnect before qualification or a rolling one-hour average below 10 kH/s after warm-up changes the account to PPLNS. Qualification-period work remains PPLNS unless it activates before receipt settlement. Miners unable to run at least six hours on their mining days should select PPLNS.

PPS+ credits are automatic only when reserve capacity exists. Manual confirmed reserve funding and collection-wallet receipt portions attributable to active PPS+ work increase capacity; previously funded PPS+ net credits reduce it. A calculated amount that exceeds capacity stays pending and is not spendable or withdrawable. The same share cannot be credited through both methods.

Mixed-mode master-wallet settlement

Admin enters the exact total confirmed in the master wallet and a unique source reference. The wizard first apportions the receipt between unsettled PPLNS and active PPS+ work by difficulty. The PPS+ portion replenishes reserve. Each PPLNS row then applies its stamped reward-method deduction and route allocation. The preview shows receipt gross, PPS+ reserve, operator-side amount, raffle allocations, and net miner liability before submission. The subsequent payout run is tied to that settlement ID and cannot include prizes or older liabilities.

The weekly route's raffle allocation is 1%. Dedicated routes publish their larger mandatory allocation before connection. All-In uses a 60% promotional allocation, usually 70%. Accounts measured above 12 kH/s receive a relative 10% reduction from every route's published allocation. 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 mining payout cannot exceed the selected receipt, that miner's remaining receipt credit, or the stored unpaid balance. An unscoped batch is rejected. Admin adjustments can add a manual credit or deduct an explicitly selected pool, electricity, or hardware charge; they never expand a receipt cap.

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

There is exactly one prize in each draw: 0.15 XMR for Weekly, 0.50 XMR for Standard, 1.00 XMR for MAX, and 2.00 XMR = $721 USD for All-In. The $721 All-In figure is the advertised promotional reference requested for that prize. MAX and other live USD references refresh at most once every 60 minutes from CoinGecko with Kraken fallback and remain estimates rather than locked conversion quotes. A miner chooses a raffle allocation by choosing its endpoint; work already submitted cannot be moved to another route.

Weekly Raffle

Port 3334, with rental alternate 3335. It allocates 1% of the selected method's reward base, has one 0.15 XMR prize, and draws Friday at 17:00 GMT+2. A completed Day 30 check-in starts a separate 24-hour 0% Weekly allocation window.

Standard Raffle

Port 3336. It allocates 20% of the selected method's reward base, has one 0.50 XMR prize, and draws Sunday at 17:00 GMT+2.

MAX

Port 3337. It allocates 40% of the selected method's reward base, has one 1.00 XMR prize with an hourly live USD estimate, and draws Wednesday at 17:00 GMT+2.

All-In

Port 3338. It allocates 60% of the selected method's reward base during the promotion instead of the usual 70%, has one 2.00 XMR = $721 USD prize, and draws Thursday at 17:00 GMT+2. Miners above 12 kH/s receive the large-miner promotional rate of 54% while they qualify.

Each program counts raw upstream-accepted submissions. After an account records at least 3,600 seconds of mining in that program round, each completed account-specific share target issues one random unique seven-digit ticket and the remainder carries toward the next. Shares can accumulate before the hour is complete. A high-difficulty submission is still one raffle share, while its difficulty remains relevant to mining-reward accounting. Duplicate shares never advance the counter.

Longer participation generally produces more good shares, so each additional completed target creates another ticket and another chance in the same round. This raffle opportunity remains even when PPLNS produces no mining payout for the participant.

The All-In page shows 2.00 XMR = $721 USD, plus a live XMR/BTC reference conversion, gross BTC estimate, and net estimate after the 15% BTC conversion fee. A winner can instead withdraw the credited prize as XMR to an XMR address with the current 0% XMR withdrawal fee.

30-day Daily Check-In

Signed-in participants can make one claim per Johannesburg calendar day. Progress pauses after a missed day and does not reset. Days 1-5 award 2 Weekly entries per day, Days 6-10 award 3, Days 11-15 award 5, Days 16-20 award 7, Days 21-25 award 10, and Days 26-30 award 13. The 30 claims total exactly 200 normal entries.

Day 10 and Day 20 each add one Golden Raffle Ticket represented by 10 additional unique seven-digit entries. Day 30 starts a precise 24-hour window in which Weekly work accepted on ports 3334 and 3335 is recorded at a 0% raffle allocation. The waiver does not alter earlier work, other routes, or work accepted after expiry. Check-in entries do not replace the account's applicable accepted-share target and one-hour mining requirements for draw eligibility.

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 reached the accepted-share target recorded for that account's speed band, hold at least one ticket, and have at least 3,600 seconds of recorded mining-session time in that program round. 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. The admin award wizard accepts only an eligible wallet, locks the configured prize amount, credits that prize to the winner's available balance exactly once, requires LoveMedia evidence, queues notifications, completes the draw, archives interim active tickets, and opens an empty round. Historical tickets remain available for audit while every live account starts the new round at zero.

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, standard and NiceHash fields, complete raffle entry rules, all dedicated addresses, and live account hashrate, shares, settlement, and ticket totals.

Withdraw

Available and pending XMR, XMR/BTC method selection, live fee calculation, wallet destination, request submission, cancellation, status, delivered amount, and payment evidence.

Raffles

Daily Check-In progress, Golden Ticket numbers, waiver state, current program rules, actual personal ticket numbers, pending audits, masked results, and payout state.

Pool Stats

Live pool and network difficulty, current and average effort, latest payout-block time and height, PPLNS window, hashrate, miners, and chain heights, refreshed every three seconds without browser caching.

Status alerts

Account-derived ranking privacy plus separate incident, maintenance, stale-snapshot, and finalized monthly-report email preferences.

Support

An in-dashboard request form with the account name and email prefilled, a first-party arithmetic CAPTCHA, and no navigation outside the dashboard.

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

Workflow A processes reserved miner withdrawal requests with visible fees, destination, delivered amount, rejection/refund, and evidence. Workflow B reconciles mining income and pays only the selected master-wallet receipt's remaining net credits.

PPS+ report

Reserve funding, receipt-derived capacity, eligibility timers, one-hour and session averages, pending accruals, funded credit batches, formula inputs, terms-defined deductions, net credits, and immutable references.

Banked

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

Raffles

Round funding evidence, 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.

Service status

Incident publishing and updates, scheduled maintenance, geographic TCP and RandomX job checks, uptime history, and downloadable monthly-report generation.

Support

The most recent support submissions, sender, category, complete message, received time, and outbox delivery state.

Artifact signing

US individual portal checklist, non-secret Azure resource configuration, readiness state, protected API metadata, live management-SDK connection test, and production SignTool runbook.

Settings

Master collection wallet, administrator password, protected outgoing SMTP host, port, TLS mode, credentials, sender identity, test message, retry, and outbox totals.

Admin starts by identifying the event. A miner-requested withdrawal belongs in Workflow A because its XMR is already reserved. Admin verifies the miner, network, full destination, gross request, fee, and net value; locks the request to prevent miner cancellation; completes the external transfer; records its reference and actual BTC delivered where applicable; then marks it paid once. Rejecting a processing request requires a reason and restores the complete reserved amount.

Workflow B is deliberately sequential. First reconcile a confirmed collection-wallet reward against all unsettled accepted difficulty. The wizard separates the PPS+ reserve portion, operator-side amount, route raffle allocations, and PPLNS net liability. Next choose a minimum threshold and full or smaller receipt-capped amounts. The review exposes each worker, full destination wallet, exact receipt credit, five-decimal payment, and receipt remainder. Only after the external transfer completes should the operator record its immutable reference. Never repeat a Workflow A request in Workflow B. An incoming reward ID is rejected as outbound evidence.

The funding-reconciliation panel distinguishes the selected receipt from combined account liabilities. Raffle-prize awards, manual credits, older liabilities, and unrelated receipts remain recorded but cannot increase the selected mining run. Payment-ready recipients need a valid Monero wallet. Immediately before one atomic ledger update, the server requires a valid settlement ID and rejects a changed balance, duplicate recipient, invalid wallet, excessive amount, over-precision value, per-account receipt breach, or total receipt breach without partial records.

Freshness and interpretation

The public Pool and Website Status page polls every five seconds and combines website health, all five Stratum listeners, entire Main network statistics, and a rolling network-wide Top 10. It does not use XMR.gives route hashrate, local accepted-share totals, client tickets, or generated miners as substitutes for pool-wide data. A separate worker stores one-minute operational, hashrate, payout-window miner-count, and block-effort samples. The page buckets those samples into 15-minute points for 24 hours and six-hour points for 30 days. Uptime treats operational and degraded samples as available and outage samples as unavailable.

Live statistics try the primary network index, local node JSON, and a secondary network index in order, without caching. The active source and failover state are published without exposing backend URLs. Every route receives a local TCP measurement and a full login-to-RandomX-job validation each minute. Hourly independent Globalping checks test public TCP reachability from Europe, North America, and Asia; the status table labels the geographic TCP check separately from the pool-edge job check. Each uptime window and monthly report displays retained sample coverage.

Pool hashrate is estimated from current sharechain difficulty divided by block time. Pool share difficulty is the work target for accepted pool shares; Monero network difficulty is the chain-wide block target. Current effort compares work spent on the block now being sought with statistical expectation. Average effort summarizes recently completed blocks. Roughly 100% is expectation, above 100% took longer, and neither value predicts when the next block must arrive. Active miners and payout-block history are aggregate values from the live source. Mainchain and sharechain heights describe different chains and should not be expected to match.

Account hashrate remains available only in the signed-in dashboard. The public Top 10 instead aggregates actual canonical Main sharechain work for all network miners, applies uncle weighting, estimates 24-hour hashrate, and compares rank with the preceding 24 hours. The complete masked ranking powers the downloadable sharechain-work CSV. The collection address's actual rank is calculated separately, including an explicit not-ranked state. The current payout window publishes Top 1, Top 5, Top 10, remaining-work percentages, and a concentration index.

The durable ranking refreshes hourly. A snapshot older than two hours opens a public incident and emails administrators even when they did not opt into client alerts; recovery resolves it. Monthly reports combine uptime, coverage, average and peak Main hashrate, average miners, and average/peak effort for each UTC month. CSV and JSON downloads are uncached. The open month is provisional and a completed report is final.

Raffle and service 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.

When an account first qualifies above 12 kH/s, the service queues a one-time operational email explaining the 10% large-miner allocation discount, the resulting rate for every raffle, and the 1,000-share ticket target for that speed band. It is a rate disclosure tied to accepted mining work rather than a draw marketing message. The dashboard continues to show whether the discount is currently active as measured speed changes.

The worker reloads mail settings from the protected admin configuration without requiring a web restart. Only STARTTLS or implicit TLS is accepted. The saved password is never rendered back into the admin page; leaving its field blank preserves the current secret.

Incident, maintenance, and monthly-report messages use the same durable outbox with event-specific duplicate protection. Each category is independently disabled by default and can be enabled or withdrawn under Dashboard → Status alerts. Incident updates and maintenance state changes each create a distinct notification event.

Public, client, admin, and mail flow

Anyone can submit the public support form without registration. Signed-in miners use Dashboard → Support so navigation remains in the client shell. The form collects name, reply email, category, subject, and message. It uses a first-party addition question signed by the server, a hidden honeypot, single-use challenge nonce, ten-minute expiry, and a limit of five accepted requests per network hash per hour.

Successful submissions are stored in the local support ledger and atomically added to the durable email outbox for delivery to the configured support recipient. The message sets Reply-To to the sender but escapes all submitted HTML. Admin → Support shows recent requests and email state. Delivered support content is normally purged after 24 months.

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.
• Support requests store a one-way network hash for throttling rather than the submitted raw address.
• Security headers deny framing, restrict browser capabilities, and require HTTPS on future visits.
• Mining Stratum endpoints are TCP without TLS. Their password field is ignored, so leave it blank or use a non-sensitive placeholder.

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.

Policies, consent, and regulatory boundaries

The public footer identifies LoveMedia Foundation NPC, registration number 2024/122569/08, and its Ballito address, and links to the Terms of Service, Privacy Policy, Cookie Policy, and support. The policies document the operator, data categories, purposes, legal bases, recipients, transfers, retention, rights, security, account rules, mining accounting, payouts, raffle mechanics, liability, and disputes.

The consent panel offers Accept all and Essential only with comparable controls and can be reopened from the footer. Current storage is limited to the seven-day HTTP-only login cookie and the six-month consent-preference cookie; no analytics or advertising cookies are active. Authentication remains available under Essential only.

Read-only endpoints

Pool endpoints are read-only and unauthenticated. Account mining data requires the signed HTTP-only session and returns 401 otherwise. Wallets, payouts, and administrative operations are not exposed by a public JSON API.

Fast diagnosis

Invalid work after login

Confirm the algorithm and transport. NiceHash must use RandomXmonero, standard XMRig uses rx/0, and TLS must be off. Every advertised port accepts both login shapes; port 3335 is the Weekly rental alternate.

Rental rejects pool difficulty

Leave difficulty automatic first. If the provider requires a target, use YOUR_WORKER+DIFFICULTY or password d=DIFFICULTY. The value must be a positive whole number; the upstream node enforces its protocol minimum.

Accepted work but no raffle ticket

This is expected until the account has both its displayed target of 300, 600, or 1,000 accepted shares and one hour of mining in that program round. Confirm the exact registered worker, intended route, upstream acceptance, live share counter, speed band, and mining-time indicator. Weekly ports 3334 and 3335 contribute to the same Weekly counter.

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 reached its recorded speed-band share target, hold one ticket, and have 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.

More payout choices, beginning with DOGE

XMR.gives plans to add more coin payout choices. The next planned coin is Dogecoin (DOGE). The intended first release keeps miners connected to the existing Monero RandomX pool while allowing an eligible miner to choose DOGE as the payout coin. In other words, the computer would still perform Monero RandomX work and the operator would convert the miner's recorded payable value to DOGE during payout processing.

This is a roadmap item, not a live DOGE pool or current payment promise. The production release still needs a DOGE address validator, live reference pricing with freshness and source disclosure, a displayed conversion fee and net calculation, minimum and precision rules, liquidity and custody procedures, transaction evidence, cancellation and refund states, accounting reconciliation, legal review, and updated Terms and Privacy disclosures. No launch date is promised until those controls and end-to-end tests are complete.

What is not automatic

The application does not broadcast Monero payments, custody private wallet keys, verify exchange transfers, select raffle winners, or automatically discover new collection-wallet rewards. Admin must enter each confirmed gross reward and unique source reference before PPLNS balances are credited or its PPS+ receipt portion replenishes reserve. Eligible PPS+ batches credit internal balances automatically only within already recorded reserve capacity.

Mining ticket progress advances only after an upstream accepted-share response is recorded against a known account. The app does not infer acceptance from a submitted share, miner-side message, connected socket, or public block event. A mining ticket is issued at the account's recorded 300, 600, or 1,000 accepted-share target after one hour in the same round. Daily claims, Golden entries, and authorized manual entries use separate stored sources but do not remove the mining eligibility minimum.

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