Instant delivery

Lifetime updates

1 domain license

Blockchainv6.1.5

Monero Blockchain Addon

Name: Monero Blockchain Addon
Brand: MashDiv
SKU: monero
Price: 129.00 USD
Availability: InStock

Add XMR custody to your exchange with no third party in the path — your node, your wallet files, your keys.

4.9010 sales

$129$149Save 13%

You'll also need Bicrypto and Ecosystem for Bicrypto

On its own, Monero Blockchain Addon won't work — it only runs if you already own these products. Open the Requirements tab to see exactly what you need and add them to your order.

See it working Live demo Documentation View on CodeCanyon

Per-user XMR deposit addresses, created the first time a customer asks
Deposits credited at 6 confirmations — compiled in, so nobody can lower it
Live confirmation progress pushed to the deposit page as each block lands
A background scanner catches deposits arriving after the page is closed
Withdrawals signed by the customer's own wallet — no platform hot wallet
The exact fee read off a transaction that is built and deliberately not sent
Your fee minus the network fee lands in your master wallet in the same send
Locked outputs hold the payout and retry instead of failing and refunding
One relay attempt ever — a lost response goes to review, never a resend
Pay-to-many credited per wallet, so one transfer can fund several customers
The backend re-points wallet-rpc at your daemon after a restart, by itself
Live diagnostics probe both daemons and catch a wrong network before launch

Inside Monero Blockchain

The chain nobody can host for you

On every other chain the platform custodies, a node or an explorer somewhere can tell you which transactions belong to an address. On Monero nothing can — that calculation needs the wallet's view key, and only the wallet has it. So this addon talks to your monerod and your monero-wallet-rpc, and gives you per-user XMR addresses, confirmation-aware crediting and signed withdrawals on infrastructure you own outright.

In detail

Monero is the one chain in this platform that nobody can custody on your behalf. There is no explorer API and no public node that can say which transactions belong to an address: on Monero that calculation needs the wallet's view key, and only the wallet has it. So this addon does not integrate a service. It gives the Ecosystem addon full XMR custody — per-user deposit addresses, confirmation-aware crediting and signed withdrawals — through infrastructure you run yourself.

How it works

The first time a customer opens the XMR deposit page, the platform creates a Monero wallet file named after their Ecosystem wallet, reads back the primary address and encrypts the mnemonic with the Ecosystem vault key. Your wallet directory ends up holding one file per customer plus the platform's own master wallet. Deposits are found by opening each wallet, refreshing it against your daemon and reading its transfers; six confirmations credits the balance, and progress is pushed to the deposit page as each block lands. Withdrawals are signed by the customer's own wallet file, because Monero has no gas payer — and your platform fee rides along as a second destination in the very same transaction.

The surface you configure

What	Where	Decides
Daemon and wallet RPC URLs	`.env`	which monerod and which wallet-rpc the backend drives
One Digest credential pair	`.env`	both services must share it — there is no second account
`XMR_NETWORK`	`.env`	which withdrawal address prefixes are accepted
Withdrawal fee	the XMR token record	your margin on every payout
Chain status	Admin, Ecosystem, Blockchains	the seeded row ships disabled

The six-confirmation rule, the ninety-minute monitor ceiling and the two-hour locked-funds window are compiled in, not settings.

What operators control

Enable or disable the chain behind a licence check. Set the withdrawal fee that becomes your margin, collected into your master wallet one payout at a time. Run live diagnostics that probe both daemons, compare your declared network against the one monerod actually runs, and verify the licence, the chain service and the master wallet. Everything else is your infrastructure: the node, its disk and its uptime.

This one is demanding on purpose. It needs Bicrypto core, the Ecosystem addon, an activated licence, and a fully synced monerod plus a long-running monero-wallet-rpc on your own server — budget a permanently growing quarter-terabyte of local SSD. Treat the wallet directory as key material: the files carry no password, so their permissions are all that protects every customer's keys, and no seed re-derives them. Deposits also record no sender: that field is always N/A, and no compliance process can change it.

One wallet file per customer, and one door into all of them

There is no HD derivation on this chain. The first time a customer opens the XMR deposit page the platform creates a wallet file named after their Ecosystem wallet, reads back the address and encrypts the mnemonic with the Ecosystem vault key — so your wallet directory grows by one file per customer, with the platform's master wallet beside them. Because monero-wallet-rpc holds exactly one wallet open at a time, every operation is queued: withdrawals and deposit checks take the high lane, and the background refresh that keeps dormant wallets synced waits behind them.

That directory is key material and nothing re-derives it — back it up alongside the database and the .env that decrypts the stored mnemonics. The wallet files themselves carry no password, so their file permissions are all that protects them. Expect Monero operations to feel like seconds to minutes rather than milliseconds, because they queue.

Withdrawals priced on a real transaction, not an estimate

Monero's fee depends on the outputs the wallet actually spends, so the platform builds the transaction, tells the wallet not to relay it, and reads the exact fee back. It then pays the customer their amount minus that fee, and adds your margin — your configured fee minus the same network fee — as a second destination in one send. If freshly received outputs are still protocol-locked, the payout is held and retried rather than failed, and the final relay is issued exactly once, because a retry can broadcast a second transaction.

Your margin is your fee minus the actual network fee. Price the XMR token's withdrawal fee below what Monero charges and you earn nothing on every payout, silently — and the same is true if the XMR master wallet is missing or disabled: the customer is still paid, you simply collect zero.

Two gates, one live probe, and one row that is only a warning

Activation is the same two gates as the other licensed chains — a licence file on disk and a chain row you switch on, which ships off — plus a live health check against your wallet RPC that decides whether the chain comes up at all. The admin console probes both daemons, checks the licence, the chain service and the master wallet, and compares the network you declared against the one monerod is really running, which is the difference between accepting your customers' withdrawal addresses and rejecting all of them.

This is a chain inside the Ecosystem addon, so it needs Bicrypto core and Ecosystem before it needs anything of its own. And the daemon is deliberately not part of that startup gate: an unsynced or unreachable monerod leaves the chain reading enabled while no deposit can be detected and withdrawals fail at fee estimation. Monitor it separately from day one.

A deposit nobody else can look up, and a customer who can watch it anyway

On this chain there is no public explorer view of an incoming transfer, so your own daemon is the only thing that can see one. The platform shows the customer their transfer the moment it is noticed — at zero confirmations, marked seen rather than credited — and pushes the count as it climbs. The balance moves at six confirmations and not before, and the amount is read in piconero and divided by a trillion on the way in.

Two paths notice a deposit and they cannot double-credit: a live session while the customer has the page open, capped at ninety minutes, and a background scanner that no-ops on any wallet a live session already owns. Three wallets are checked at a time, because every one of them queues behind the single wallet RPC. No sender is recorded on a Monero deposit — the chain does not carry one — so a customer asking you to trace where their coins came from is asking for something that does not exist.

third-party services in the path: 0
daemons you run and supervise: 2
confirmations before a credit: 6
decimals — amounts are piconero: 12

Everything included

63 capabilities, in 5 areas

Every item below exists in the source you receive. Nothing here is a roadmap.

Per-customer wallets

Monero has no address derivation, so custody here is a directory of wallet files.

One monero-wallet-rpc wallet file per customer, created the first time they open the XMR deposit page
Wallet filename is the customer's Ecosystem wallet id; the platform's own is master_wallet
Primary address on account 0 read back and written into the wallet's address map
Mnemonic read at creation and encrypted with the Ecosystem vault key before it is stored
Network label stamped from the address prefix the wallet RPC returns, not from your .env
Named-wallet existence check that creates the file when it is missing
Balance read that refreshes against your daemon first, so a fresh open never answers from its stale cache
XMR registered as a NATIVE token with a blank contract and twelve decimals
Deposits always go to the customer's own address — no custodial contract on this chain
Every wallet operation serialised through one queue, withdrawals and deposit checks in the high lane
Background refresh of the most stale dormant wallet holding a balance, at low priority behind everything else
Wallet-context assertion before every read and every transfer

Deposits and confirmations

No explorer, no webhook, no address index — the wallet is the only thing that can see a deposit.

Deposit detection as a queued open, refresh, read transfers, close cycle
Six confirmations before a balance is credited
Live confirmation progress pushed to the deposit page as each block lands
Mempool transfers broadcast at zero confirmations, carrying the required count
Live session monitor at a five-second per-wallet interval, three wallets a batch, two seconds between passes
Background sweep for deposits that arrive after the page is closed — one wallet every twenty seconds
A sweep is a no-op while a live monitor already owns that wallet
Monitor stops after three consecutive empty checks past a ten-minute floor, and at ninety minutes unconditionally
Monitoring continues past the idle retry cap while a transfer is still confirming
Pay-to-many credited per receiving wallet, so one transfer can fund several customers
Two dedupe layers: a thirty-minute in-memory wallet-and-hash cache, and a database check on both
Credited deposits written as XMR, NATIVE, DEPOSIT, COMPLETED, with the amount and the network fee

Withdrawals

Signed by the customer's own wallet file, priced on a transaction that was really built.

No platform hot wallet and no gas payer — the network fee comes out of the outputs being spent
Pre-flight estimate from the daemon's fee table, shown on the withdrawal form
Exact fee read off a real transaction built with do-not-relay and never broadcast
Customer receives their amount minus the actual network fee
Your margin — configured fee minus the actual network fee — paid to the master wallet as a second destination in the same send
Unlocked-balance pre-check against amount plus margin before anything is built
Locked outputs hold the row PENDING with the unlocked and total figures, for the queue watchdog to retry
A two-hour ceiling on that hold, after which the withdrawal fails and refunds cleanly
Destination validated against the address prefixes for your declared network before anything is queued
Idempotency guard: a row already COMPLETED, or already carrying a hash, is never re-sent
One relay attempt with a 120-second budget, never retried
A lost relay response recorded as TIMEOUT for manual review rather than refunded
Failure writes guarded so a withdrawal that already has a hash can never be flipped to FAILED and refunded
Platform profit recorded against chain XMR, wallet type ECO, type WITHDRAW, with all three fee figures in its description

Your Monero infrastructure

What the backend does to keep two daemons of yours usable.

Drives your own monerod and your own monero-wallet-rpc — nothing third-party anywhere in the path
Five environment keys: the two RPC URLs, one credential pair, and the network you declare
HTTP Digest authentication negotiated from the 401 challenge, for both services
An error that names which service demanded credentials when none are configured
The backend points wallet-rpc at your daemon itself at startup, rather than trusting its launch flags
The same repair re-issued once on a daemon error before the refresh is retried
Exponential daemon back-off, thirty seconds doubling to a five-minute cap
Daemon errors kept off a wallet's retry budget, so monitors survive an outage and resume
An already-open wallet closed and the open retried once
Three attempts a second apart on ordinary calls, with per-operation budgets from thirty seconds to fifteen minutes
An authentication failure treated as permanent — the wallet is unmonitored instead of retried forever

Activation, diagnostics and oversight

Two gates, one live probe, and the console that tells you which one failed.

A machine-bound licence file, read when the chain service is constructed
A seeded chain row you switch on from the admin panel — it ships disabled
A second licence check in front of the chain's own API routes, cached for five minutes
A live third gate: a version call against your wallet RPC decides whether the chain comes up at all
Requirements screen listing every Monero key, whether it is set, and what breaks without it
Live probes of the wallet RPC and of the daemon's height and sync flag
Your declared network compared against the network monerod is really running
Prerequisite checks for the licence, the chain service module and the master wallet
A per-flow readiness verdict for deposits and for withdrawals
A warning raised for keys that are set but read by nothing
RPC URLs with embedded credentials refused, so a bad value never reaches an error message
Master wallet creation, enable and disable, and a live balance in the admin panel
Master wallet transaction history in the admin panel
Every line the service logs tagged XMR, so one grep is the whole story

Licence: Regular licence — full source; activation is machine-bound and writes a licence file
Requires: Bicrypto core and the Ecosystem addon, both licensed separately. Monero is a chain inside Ecosystem, not a standalone product.
You must run: A fully synchronised monerod and a long-running monero-wallet-rpc, on your own server. There is no provider, no explorer API and no hosted option — on this chain there cannot be.
Disk and memory: Around 250 GB of local SSD for the blockchain, growing continuously, plus headroom for the daemon on top of the platform's own needs. Pruning cuts the footprint and still syncs wallets.
Processes: Two more under your supervisor, beside the platform's own: monerod and monero-wallet-rpc
Wallet RPC flags: Must be started with a wallet directory — wallets are opened by filename. Started against a single wallet file instead, every open fails.
Ports: The daemon's peer-to-peer port faces the internet; both RPC listeners belong on loopback, since the backend runs on the same host.
Configuration: Five environment keys. None are in the example file, and all are read once when the service is constructed — a change needs a backend restart.
RPC transport: HTTP Digest authentication with one credential pair shared by the daemon and the wallet RPC. There is no way to give them different accounts.
Asset: XMR only, as a NATIVE token with twelve decimals — Monero has no token layer
Counted surface: 5 environment keys, 12 wallet-RPC methods, 2 daemon methods, 1 seeded chain row
Access control: No permission keys of its own. Enabling the chain and running its diagnostics use Ecosystem's blockchain keys; the master wallet and the XMR token use Ecosystem's wallet and token keys.
Storage: Deposits, balances and withdrawals touch no ScyllaDB. Ecosystem needs it for order books and candles, so you will have it either way.
Both RPC endpoints must be plain HTTP: The service speaks HTTP. An https:// URL passes the admin diagnostics, which use a different client, and then fails at runtime. Keep both listeners on loopback and this never comes up.
The wallet files carry no password: Every create and open passes an empty one, and the environment key that looks like it changes that is read by no code. The directory's file permissions are the only thing protecting every customer's Monero keys.
Nothing re-derives a wallet: There is no seed behind the per-customer files. Back the wallet directory up alongside the database and the .env that decrypts the stored mnemonics; a copy of one without the other is worthless.
Every operation queues: monero-wallet-rpc holds one wallet open at a time, so a withdrawal and a deposit check cannot overlap. Expect seconds to minutes, not milliseconds — and wallet count, not disk, is what eventually binds.
No subaddresses, no integrated addresses: Each customer gets one permanent primary address and no payment ID. Nothing in the product calls for a second address on a wallet.
Deposits record no sender: The from field is always N/A, because Monero transactions do not reveal one. If your compliance process expects a source address on every deposit, decide that before you enable the chain.
The daemon is not part of the startup gate: An unreachable or unsynchronised monerod leaves the chain reading enabled while no deposit can be detected and withdrawals fail at fee estimation. Monitor it separately from day one.
Price the withdrawal fee above the network fee: Your margin is the token's configured fee minus the actual network fee. Set it lower — or leave the XMR master wallet missing or disabled — and the customer is still paid while you collect nothing, silently, on every payout.
Two outcomes need a human: A lost relay response, and a withdrawal stuck mid-broadcast, are never auto-refunded: the transaction may already be on the network, and paying twice is worse than a delay. Both raise for manual review.
The timings are compiled in: Six confirmations, the ninety-minute monitor ceiling and the two-hour locked-funds window are constants, not settings. No screen changes them.