Monero Blockchain

The Monero Blockchain addon adds XMR to Ecosystem's custody set: per-user deposit addresses, confirmation-aware deposit crediting, and signed withdrawals, all through your own Monero infrastructure.

That last clause is the whole story. Every other chain Ecosystem supports reads from somebody else's node — an RPC provider, an explorer API, a public cluster. Monero has no such thing, by design. There is no public API that will tell you which transactions belong to an address, because on Monero nobody can compute that without the wallet's view key. So the addon does not talk to a service. It talks to your monerod and your monero-wallet-rpc, both of which you install, run and keep alive yourself.

Budget for that before you buy. A synced Monero node is a permanent ~250 GB of SSD and two daemons that must be running whenever the platform is.

What it requires

Requirement	Why	If it is missing
Bicrypto core	Everything	The extension cannot be enabled
Ecosystem addon	Wallets, deposits, withdrawals, markets — Monero is a chain inside Ecosystem, not a standalone product	Nothing to plug into
A licence for this product	Product ID 54578959. Activation writes lic/54578959.lic	The status toggle refuses with 403
monerod, fully synchronised	Fee estimation, wallet sync, confirmations	Deposits are never detected; withdrawals fail at fee estimation
monero-wallet-rpc, started with --wallet-dir	Wallet creation, balances, transfers — every operation	The chain is disabled at startup and stays disabled
The Ecosystem vault, unlocked	The wallet mnemonic is encrypted before it is stored	Address generation fails

Note what is not in that list: ScyllaDB. Ecosystem needs it for order books and candles, so you will have it, but Monero deposits, balances and withdrawals do not touch it.

Monero is not like the other chains

Read this section before you read anything else. Almost every operational surprise on this chain traces back to one of these four facts.

There is one wallet file per user wallet. On EVM chains a single master wallet's HD material derives an unlimited number of addresses and one provider watches them all. Monero has no such derivation here. When a user first opens the XMR deposit page, the platform calls create_wallet on monero-wallet-rpc with the ECO wallet's UUID as the filename, and stores the resulting address and mnemonic. The master wallet is a wallet file too, named master_wallet. Your --wallet-dir therefore grows by one wallet file per customer who has ever looked at the XMR deposit page.

Subaddresses are not used. Every wallet operates on account_index: 0 and its primary address. There is no create_address call anywhere in the product. The address a user is shown is a standard mainnet address beginning with 4.

All wallet operations are serialised through one process. monero-wallet-rpc can only have one wallet open at a time, so the addon runs a global queue: open, refresh, do the work, close, next. A withdrawal and a deposit check on two different wallets cannot overlap. Withdrawals and deposit checks run at high priority; background staleness refreshes run at low priority behind them. This is the single biggest difference in feel — Monero operations are measured in seconds to minutes, not milliseconds, and they queue.

The daemon is your explorer. Confirmation counts, fee estimates and sync state all come from monerod. An unsynced daemon does not degrade the chain gracefully — it silently stops deposits arriving and makes withdrawals fail.

XMR is the only asset

Monero has no token layer, so there is exactly one Ecosystem token row on this chain and its contractType is NATIVE. You create it through the token import flow with a blank contract, not the deploy flow — see Tokens and markets.

There are no custodial wallets on Monero either. Custodial contracts exist only for EVM tokens that cannot pay their own gas; XMR deposits always go to the user's own wallet address regardless of how the token row is flagged.

One consequence worth knowing: XMR is treated as network-agnostic by the token eligibility rule, so the network label on the token row is never compared with XMR_NETWORK. The mismatch that bites operators on other chains cannot happen here through the token row. It can still happen through the daemon — see Configuring the RPC connection.

Three gates, checked in order

Activation is not a single switch. On every service startup the addon evaluates:

1. Licence. lic/54578959.lic must exist. Results are cached for five minutes.
2. Database row. ecosystem_blockchain where productId = 54578959 must have status = true. It ships false.
3. Wallet RPC reachability. A get_version call against XMR_WALLET_RPC_URL. If it throws, the chain is marked inactive and every Monero operation refuses with "Monero service not available."

The daemon check is deliberately not a gate — an unreachable monerod logs a warning and the chain stays nominally active. That is a trap, not a kindness: the chain looks enabled while no deposit can be detected. Always confirm the daemon separately.

If the chain is active but the wallet RPC was started without a daemon, the backend repairs it: at startup it calls set_daemon on monero-wallet-rpc with the host and port from XMR_DAEMON_RPC_URL and the credentials from XMR_RPC_USER / XMR_RPC_PASSWORD, and it repeats that call once whenever a refresh fails with a daemon error. The backend is authoritative over the wallet RPC's daemon connection.

Where to go next

Related

• Supported blockchains — how licensed non-EVM chains are enabled, and the other three.
• Master wallets and the vault — the encryption that protects every mnemonic this addon creates.
• Deposit wallets and custody — the ECO wallet and address map this chain writes into.