monero.loveA little love for the network.
← All guides

Reference / 120 terms

Monero & Crypto Glossary: Terms Explained With Examples

Look up a wallet message, a node setting or the cryptography behind a payment. Each term has an example, related definitions and sources.

120 terms

How Monero privacy components fit together

These components address different questions in current standard transactions. No single component supplies every privacy property.

Input ambiguity

CLSAG signatures leave the real input ambiguous among its ring members.

CLSAG, Ring size

Recipient unlinkability

One-time output keys avoid publishing the reusable receiving address.

Stealth address, One-time public key / output public key

Amount confidentiality

Commitments conceal amounts. Range proofs and balance checks establish allowed values and conservation.

Pedersen commitment, Bulletproofs+

Double-spend detection

Key images let nodes reject repeated spending without naming the real ring member.

Key image, Double spending

Network observations

Dandelion++ and configured Tor or I2P routing address network observations, with different assumptions.

Dandelion++, Transaction relay over Tor and I2P

Fees, output keys, key images, proof data and transaction structure remain public. Wallet security and records held by other parties are separate concerns.

Protocol baseline: v0.18.5.4, reviewed 2026-11-07 UTC. Historical and developing mechanisms are marked. About the sources.

A

Adaptor signature

Protocol and cryptography

Also called: adaptor signatures

A signature construction in which completing a signature reveals secret information to someone who has the matching partial signature. Swap protocols use that relationship to connect spending on different chains.

Example: BasicSwap uses an adaptor-signature protocol for Monero swaps rather than requiring a Bitcoin-style script on the Monero chain.

Common confusion: This is a swap-protocol tool, not a replacement for the CLSAG signatures in ordinary Monero transactions.

Read: How Monero atomic swaps work

Sources: BasicSwap protocols and messaging

Air gap

Wallets and keys

Also called: air-gapped, airgapped

Separation of a device from network connections. In an offline-wallet setup, an air-gapped signer holds spending secrets while data crosses through a controlled method such as QR codes or removable media.

Example: An offline laptop signs a payment prepared by a view-only wallet on a connected computer.

Common confusion: Transferred files and QR data still need validation. An air gap does not make compromised software safe.

Sources: Feather: offline transaction signing

Atomic swap

General cryptocurrency

A protocol for exchanging assets across chains with linked settlement and recovery paths rather than handing both assets to a central custodian. Exact guarantees depend on the protocol and participants following it.

Example: A BTC/XMR swap uses protocol-specific locks and refund procedures if a counterparty stops responding.

Common confusion: Atomic does not mean instant or fee-free. Users may need to remain online, wait for timeouts or run recovery steps.

Read: What Are Atomic Swaps? Bitcoin, Monero and BasicSwap

Sources: BasicSwap protocols and messaging

Atomic units

General cryptocurrency

Also called: piconero

The smallest integer units used for Monero amounts. One XMR equals 1,000,000,000,000 atomic units.

Example: An RPC value of 1,000,000,000 atomic units represents 0.001 XMR.

Common confusion: Read the API field units before displaying a number as XMR.

Sources: Moneropedia: atomic units · Stable implementation: cryptonote_config.h

B

Blinding factor

Protocol and cryptography

Also called: mask

Secret randomness mixed into a commitment so the committed value cannot be guessed just by calculating commitments to likely amounts.

Example: Two commitments to the same amount can differ because they use different blinding factors.

Common confusion: The blinding factor is not the payment amount and is not a wallet password.

Sources: Stable implementation: ringct/rctSigs.cpp · Zero to Monero, second edition (mathematical background)

Block

General cryptocurrency

A unit of blockchain history containing a miner transaction and references to included ordinary transactions. Its header links it to the preceding block.

Example: A pending payment gains its first confirmation when it is included in an accepted block.

Sources: Moneropedia: block · Stable implementation: cryptonote_config.h

Block height

Node operations

Also called: height

A block position counted from the genesis block at height zero. Some status fields report chain height as the number of blocks, one more than the highest block index.

Example: get_block_count returns a count. Subtract one to obtain the highest existing block height for that snapshot.

Technical detail: Use the meaning documented for each RPC field. Do not treat a block count and a block index as interchangeable.

Sources: Daemon RPC reference · Stable implementation: cryptonote_config.h

Block propagation

Node operations

Also called: fluffy block

The spread of a newly found block through the peer network. Nodes validate it before accepting it as part of their chain.

Example: Two peers learn about the same block at slightly different times.

Technical detail: Monero can use compact block messages, often called fluffy blocks, that avoid resending transaction data a peer already has.

Sources: Stable implementation: p2p/net_node.inl · Stable implementation: cryptonote_core/blockchain.cpp

Block reward

Mining

Also called: miner reward, coinbase transaction

The value assigned to the miner transaction under the rules, including permitted new issuance and included transaction fees.

Example: A block can pay its miner the tail-emission subsidy plus fees from ordinary transactions it includes.

Common confusion: The subsidy is newly issued XMR. Fees are paid from transaction inputs. The miner output still has a maturity rule.

Sources: Stable implementation: cryptonote_core/blockchain.cpp · Stable implementation: cryptonote_config.h

Block verification

Node operations

Checking a block against the accepted chain and network rules. Checks include proof of work, transaction validity and the permitted miner reward.

Example: A peer cannot make your node accept an oversized reward merely by advertising a higher height.

Common confusion: Synchronization optimizations can use known historical hashes. Check node settings before assuming every startup redoes every historical proof.

Sources: Stable implementation: cryptonote_core/blockchain.cpp

Blockchain

General cryptocurrency

An ordered history of blocks linked by cryptographic references. Nodes validate it and resolve competing histories according to consensus rules.

Example: A node checks a new block against its predecessor instead of trusting a loose list of payments.

Sources: Moneropedia: blockchain · Stable implementation: cryptonote_core/blockchain.cpp

Blockchain database / LMDB

Node operations

Also called: LMDB, blockchain database

LMDB is the database engine monerod uses to store chain data and indexes. Its files are local storage, not a wallet backup.

Example: Copying a node database can save synchronization time, but it does not recover lost wallet keys.

Read: Monero Database Sync Modes Explained

Sources: LMDB documentation · Daemon options and console commands

Blockchain synchronization

Node operations

Also called: node sync, initial sync

The process of bringing a daemon up to the chain it accepts from the network. It downloads block data and applies the checks appropriate to its synchronization settings.

Example: A node restored from an older database must catch up before it can reliably serve current wallet data.

Common confusion: A fully synced daemon does not mean every connected wallet has finished scanning.

Command entered in the running daemon console

sync_info

Sources: Daemon options and console commands · Stable implementation: cryptonote_core/blockchain.cpp

Bootstrap daemon

Node operations

Also called: bootstrap node

A temporary remote daemon that a local daemon can use for selected RPC requests while its own blockchain is still catching up.

Example: Your wallet gets usable responses through the bootstrap daemon before the local database reaches the tip.

Common confusion: A seed node helps discover peers. A bootstrap daemon can answer wallet-facing RPC requests.

Sources: Stable implementation: rpc/core_rpc_server.cpp · Daemon options and console commands

Bulletproofs

Protocol and cryptography · Historical in Monero

A family of compact zero-knowledge range proofs without a trusted setup. Monero used the original Bulletproofs construction before switching new transactions to Bulletproofs+.

Example: A node validating older chain data may encounter an original Bulletproof even though a new payment uses the newer format.

Sources: Bulletproofs paper, IACR 2017/1066 · Stable implementation: cryptonote_core/blockchain.cpp

Bulletproofs+

Protocol and cryptography · Current

Also called: Bulletproofs plus

The range-proof construction used for current Monero confidential output amounts. It reduces proof size relative to the earlier Bulletproofs construction.

Example: A current transaction supplies a Bulletproofs+ proof for its output commitments.

Common confusion: It proves amount ranges. It does not by itself hide the real input or the receiving address.

Sources: Bulletproofs+ paper, IACR 2020/735 · Stable implementation: ringct/rctSigs.cpp · Stable implementation: cryptonote_core/blockchain.cpp

C

Carrot

Protocol and cryptography · Development

A proposed Monero output-addressing protocol being tested alongside FCMP++. It changes how wallets derive and recognize payment information while aiming to retain compatibility with existing addresses.

Example: Testing a Carrot-aware wallet on the beta stressnet does not change how your stable mainnet wallet receives payments.

Sources: FCMP++ and Carrot beta stressnet releases · Monero v0.18.5.4 release

Change output

Protocol and cryptography

Also called: change

An output returning the unused part of selected inputs to the sender. Outputs are consumed as units, so the wallet creates change when the inputs exceed payment plus fee.

Example: Spending a 1 XMR output for a 0.2 XMR payment with an illustrative 0.0001 XMR fee leaves 0.7999 XMR as change.

Common confusion: Change is a new output and can be temporarily locked even though the funds were already yours.

Sources: Moneropedia: change · Stable implementation: wallet/wallet2.cpp

Checksum

General cryptocurrency

Also called: checksums

A value calculated from data to detect changes. Software downloads often use a cryptographic hash as their checksum.

Example: You compare the hash of a downloaded Monero archive with the value in the signed release hash list.

Common confusion: A matching hash is useful only if the expected value is trustworthy. Verify the signature and signing-key identity rather than trusting a hash supplied beside an unknown download.

Read: Verify a PGP signature

Sources: Monero: verifying release downloads

CLSAG

Protocol and cryptography · Current

Also called: Concise Linkable Spontaneous Anonymous Group

The linkable ring-signature construction used by current standard Monero transaction inputs. It proves the required signing relationships while keeping the real input ambiguous within its ring.

Example: A node verifies a CLSAG for an input and checks its key image against previous spends.

Technical detail: CLSAG replaced the older MLSAG construction. Old signatures remain relevant when validating historical blocks.

Sources: CLSAG paper, IACR 2019/654 · Stable implementation: ringct/rctSigs.cpp · Stable implementation: cryptonote_core/blockchain.cpp

Cold storage

Wallets and keys

Also called: cold wallet, offline wallet

Keeping spending secrets away from a network-connected device. A separate online wallet can monitor incoming funds and prepare unsigned transactions.

Example: A phone kept offline signs QR-based transactions while another phone broadcasts them.

Common confusion: Receiving funds does not require bringing the spending key online. Backups and a tested recovery procedure still matter.

Read: Monero offline wallets and cold storage

Sources: Feather: offline transaction signing

Commitment

Protocol and cryptography

A cryptographic representation that hides a value while binding its creator to that value. It supports later proofs about the committed data.

Example: A transaction can commit to an amount and prove relationships involving it without publishing the amount.

Common confusion: A commitment is not an encrypted amount that every verifier can decrypt.

Sources: Zero to Monero, second edition (mathematical background) · Moneropedia: pedersen commitment

Confirmation

General cryptocurrency

Inclusion in a block and the blocks subsequently built on top of it. The containing block counts as the first confirmation.

Example: A payment in the chain tip has one confirmation. Another accepted block raises it to two.

Common confusion: Confirmation and spendability are different. Recent chain history can also change during a reorganization.

Sources: Daemon RPC reference · Stable implementation: wallet/wallet2.cpp

Consensus rules

Node operations

Rules nodes use to decide which blocks and transactions are valid and which valid chain to follow. Monero chain selection uses cumulative proof-of-work difficulty.

Example: A longer chain with less cumulative work does not automatically outrank a shorter valid one.

Sources: Stable implementation: cryptonote_core/blockchain.cpp · Moneropedia: consensus

Cryptographic hash

Protocol and cryptography

Also called: hash, digest

A function that maps data to a fixed-length digest with security properties such as resistance to finding collisions. Hashes help identify and bind transaction data.

Example: Changing transaction data changes the digest used to identify it.

Technical detail: Monero uses Keccak-256 in several core operations. It should not be silently replaced with standardized SHA3-256, which uses different padding.

Common confusion: Hashing is not encryption. There is no decryption key that restores arbitrary original data from a digest.

Sources: Monero hashing · Stable implementation: crypto/crypto.cpp

Curve point

Protocol and cryptography

An element of the elliptic-curve group. Monero public keys, commitments and key images are represented using encoded points.

Example: Adding two commitments uses point addition rather than ordinary addition of the displayed hexadecimal strings.

Technical detail: Validating encodings and subgroup-related conditions matters. Not every arbitrary byte string is a safe point input.

Sources: Edwards25519 curve · Stable implementation: crypto/crypto.cpp

D

Daemon RPC versus wallet RPC

Node operations

Daemon RPC exposes node and blockchain functions. Wallet RPC operates a wallet and can expose sensitive functions such as creating transfers.

Example: An explorer queries daemon RPC for a block. A payment service uses wallet RPC to track its own receipts.

Common confusion: Never expose wallet RPC on the assumption that it is a harmless public node interface.

Sources: Daemon RPC reference · Wallet RPC reference

Dandelion++

Node operations

Also called: Dandelion, stem, fluff

A transaction-spreading method that first relays along a narrow stem path and then broadcasts in a wider fluff phase. Monero uses it to make the original network source harder to infer.

Example: The first peer that widely broadcasts a payment need not be the wallet user who created it.

Common confusion: It is not a VPN or a guarantee against a well-positioned observer.

Sources: Dandelion++ research paper · Stable implementation: cryptonote_protocol/levin_notify.cpp

Database size versus blockchain height

Node operations

Height counts progress through blocks. Database size measures local storage, which also depends on pruning, indexes and database allocation.

Example: Two nodes at the same height can have different data.mdb file sizes without either being behind.

Common confusion: A larger file is not evidence of a more current or more accurate chain.

Sources: Moneropedia: pruning · Daemon RPC reference

Decentralized exchange

General cryptocurrency

Also called: DEX

A trading system that reduces reliance on a central exchange operator, with designs that vary in custody, matching and dispute handling.

Example: BasicSwap uses atomic-swap protocols, while RetoSwap trades use a different escrow and dispute model.

Common confusion: The label alone does not establish how funds are secured or who can influence a trade.

Read: DEX vs CEX: A Beginner's Guide to Crypto Exchanges

Sources: BasicSwap protocols and messaging · RetoSwap project · RetoSwap trade and dispute documentation

Decoy output

Protocol and cryptography

Also called: decoy, mixin

An existing blockchain output included as a possible input in another payment ring. Its owner does not participate or grant permission for that selection.

Example: Your old output can appear in a transaction created by a stranger without that stranger spending your funds.

Common confusion: Appearing in a ring does not prove an output was spent in that transaction.

Sources: CLSAG paper, IACR 2019/654 · Stable implementation: wallet/wallet2.cpp

Digital signature

Protocol and cryptography

A cryptographic check that binds a message to the required secret-key authority. The verifier uses public information rather than receiving the secret.

Example: Changing signed transaction data causes its signature checks to fail.

Common confusion: A valid signature does not by itself establish a real-world name or prove that software was safe.

Sources: Stable implementation: crypto/crypto.cpp · CLSAG paper, IACR 2019/654

Discrete logarithm problem

Protocol and cryptography

Also called: DLP, ECDLP

The problem of recovering a scalar x from a point P = xG and a known base point G. Well-chosen elliptic-curve groups make this computationally difficult.

Example: Seeing a standard public spend key does not provide a practical way to calculate its private scalar.

Common confusion: This is a hardness assumption about a mathematical problem, not a promise that software or key storage cannot fail.

Sources: Edwards25519 curve · Zero to Monero, second edition (mathematical background)

Double spending

Protocol and cryptography

Also called: double-spend prevention, double-spend detection

Trying to spend the same output more than once. Monero combines valid spend proofs, key-image checks and consensus over the accepted chain to prevent both spends being accepted.

Example: Two competing transactions can attempt to consume one output, but both cannot be valid spends in the same accepted history.

Sources: Stable implementation: cryptonote_core/blockchain.cpp

E

Elliptic-curve cryptography

Protocol and cryptography

Also called: ECC

Cryptographic constructions using a group of points on an elliptic curve. Monero key operations use Edwards25519-related group arithmetic.

Example: Multiplying a generator point by a private scalar produces a public key point.

Common confusion: Using this curve does not mean every Monero signature is the standard Ed25519 signature scheme.

Sources: Edwards25519 curve · Stable implementation: crypto/crypto.cpp

Encryption

Protocol and cryptography

Transforming readable data into ciphertext recoverable with an appropriate key. Wallet-file encryption protects stored secrets while the wallet is locked.

Example: A stolen encrypted wallet file still requires the correct decryption credentials, subject to the strength of the password and implementation.

Common confusion: Hashing, signing, committing to an amount and encrypting a wallet file solve different problems.

Sources: Stable implementation: wallet/wallet2.cpp

Escrow

General cryptocurrency

An arrangement that holds funds under conditions governing their release. In Monero trading software, multisignature arrangements can give different participants defined roles.

Example: A trade locks XMR while payment is completed, with a dispute path if the parties disagree.

Common confusion: An escrow trade is not automatically an atomic swap. Read the specific network rules and dispute model.

Read: RetoSwap DEX: What It Is and How to Use It

Sources: RetoSwap project · RetoSwap trade and dispute documentation

F

FCMP++

Protocol and cryptography · Development

Also called: Full-Chain Membership Proofs++

Full-Chain Membership Proofs++ is a proposed replacement for the small-ring membership approach used by current Monero inputs. The reviewed implementation is in beta stressnet releases, not the verified stable mainnet format.

Example: A beta test transaction does not show that a mainnet wallet has gained the proposed larger anonymity set.

Technical detail: Carrot is a separate proposed addressing-layer change tested alongside FCMP++. Do not apply either development design as a description of current stable transactions.

Sources: FCMP++ and Carrot beta stressnet releases · Monero v0.18.5.4 release · Stable implementation: cryptonote_core/blockchain.cpp

Fee estimate

Node operations

Also called: fee estimates

A suggested fee rate supplied by a daemon and used by wallet software when constructing a payment. The final fee also depends on transaction weight and wallet policy.

Example: A wallet requests a rate from its remote node, then calculates a fee for the transaction it is preparing.

Common confusion: An estimate is not a measurement of the private amount being sent. A remote server response is also not proof that its suggested fee is reasonable.

Read: Wallet protection against excessive remote-node fees

Sources: Daemon RPC reference · Stable implementation: wallet/wallet2.cpp

Full node

Node operations

A node that validates the blockchain according to consensus rules. Full validation and retaining every byte of old transaction data are different choices.

Example: A pruned Monero node still checks blocks, but stores less historical proof data.

Sources: Moneropedia: node · Moneropedia: pruning

Fungibility

General cryptocurrency

The property that units of a currency can substitute for equal-value units. Monero privacy aims to make public transaction-history-based discrimination harder.

Example: A recipient values 1 XMR as 1 XMR instead of choosing it by a publicly readable ownership trail.

Common confusion: This does not guarantee that every business or jurisdiction accepts the currency.

Sources: Moneropedia: fungibility

G

Generator point

Protocol and cryptography

Also called: base point

A fixed point used as a base for scalar multiplication. Monero uses a base point for keys and additional fixed points in its proof constructions.

Example: A wallet computes B = bG from the private scalar b and the standard base point G.

Common confusion: The generator is public. Security depends on the secret scalar and the hardness assumptions, not on hiding G.

Sources: Edwards25519 curve · Stable implementation: ringct/rctSigs.cpp

H

Hard fork / network upgrade

Node operations

Also called: hard fork, protocol upgrade

A change to consensus rules that requires compatible software. In a coordinated upgrade, nodes begin enforcing the new rules at an agreed activation point.

Example: Installing a newer wallet release does not itself activate a new transaction format on mainnet.

Sources: Stable implementation: hardforks/hardforks.cpp · Monero v0.18.5.4 release

Hardware wallet

Wallets and keys

Also called: hardware wallets

A dedicated device that signs payments while keeping spending secrets separate from the connected computer. The host application prepares requests and communicates with the network.

Example: You inspect a destination and amount on the device before approving a transfer prepared by desktop wallet software.

Common confusion: Device integrity, supported software, recovery backups and checking the device display all remain necessary.

Read: Offline and hardware wallet options

Sources: Feather: offline transaction signing · CLI wallet reference

Hash to point

Protocol and cryptography

A deterministic mapping from data to a curve point. Monero uses a particular mapping in its key-image construction.

Example: An output public key supplies the input to Hp when constructing its spend key image.

Technical detail: Hp(P) is not just a hexadecimal digest treated as a point. Use the protocol implementation rather than inventing a conversion.

Sources: Stable implementation: crypto/crypto.cpp · CLSAG paper, IACR 2019/654

Hashed timelock contract

Protocol and cryptography

Also called: HTLC, hashed timelock contracts

A script-based payment condition that permits a claim using a matching secret and provides a time-based recovery path. Some atomic-swap protocols connect two such contracts through the same secret.

Example: In a compatible cross-chain swap, claiming one side reveals information needed to claim the other before its deadline.

Common confusion: Monero does not provide the Bitcoin-style scripting needed for the same HTLC construction. BTC/XMR swaps use a different protocol.

Read: Atomic swap protocols explained

Sources: Bitcoin BIP 199: HTLC construction · BasicSwap protocols and messaging

Hashrate

Mining

Also called: hash rate, H/s, kH/s, MH/s

The estimated number of proof-of-work hashes computed per second. A miner measurement and a network estimate describe different scopes.

Example: 1 kH/s means 1,000 hashes per second. A pool estimate can fluctuate because it is inferred from submitted work.

Read: Getting Started with P2Pool: How to Mine Monero

Sources: RandomX specification · P2Pool project documentation

I

I2P

Node operations

Also called: Invisible Internet Project

An anonymity network built around encrypted tunnels and destinations inside its network. Monero software can use configured I2P services and peers.

Example: An I2P node address needs an appropriate local I2P connection, not an ordinary DNS lookup.

Common confusion: I2P protects a network path. It does not remove identifying information you disclose to another person.

Read: I2P vs. Tor: What's the Difference?

Sources: I2P network introduction · Tor and I2P node routing

Inbound and outbound connections

Node operations

Also called: inbound, outbound

An inbound connection was initiated by another peer. An outbound connection was initiated by your daemon. Both can carry protocol messages.

Example: A node behind a router may have outbound peers but no reachable inbound P2P listener.

Command entered in the running daemon console

print_cn

Sources: Daemon options and console commands · Stable implementation: daemon/command_server.cpp

Integrated address

Wallets and keys

A standard address with an embedded short payment identifier. It lets a recipient distinguish payments using that identifier.

Example: A service provides an integrated address for a particular payment reference.

Common confusion: It is not the same format as a subaddress. Legacy standalone long payment IDs should not be confused with embedded short IDs.

Sources: Integrated addresses

K

Key image

Protocol and cryptography

A public cryptographic tag tied to the actual output being spent. It lets nodes recognize another attempt to spend that output without directly exposing which ring member it was.

Example: A second transaction presenting an already-spent key image cannot be accepted as another valid spend.

Technical detail: Conceptually I = x Hp(P), where x is the one-time private scalar and P its output public key. This is not the wallet master spend key.

Common confusion: A key image is public. It is not a public label identifying the real ring member.

Sources: Stable implementation: crypto/crypto.cpp · Stable implementation: cryptonote_core/blockchain.cpp · CLSAG paper, IACR 2019/654

L

Linkability

Protocol and cryptography

The ability to detect that two signatures use the same relevant secret, without necessarily identifying the signer. Monero uses this property to detect repeated spending.

Example: Two otherwise different attempted spends produce the same required key image for the same real output.

Common confusion: This technical property does not mean every payment by one wallet is publicly linked.

Sources: CLSAG paper, IACR 2019/654 · Stable implementation: crypto/crypto.cpp

Liquidity

General cryptocurrency

How readily an asset can be bought or sold in the amount you need without a large price change. It depends on available counterparties and market depth.

Example: A market has several small offers but not enough suitable orders to fill a larger trade at the displayed price.

Common confusion: A listed price does not establish that your entire trade can execute there.

Sources: Uniswap: price impact and slippage

M

Mainnet, testnet and stagenet

Node operations

Also called: mainnet, testnet, stagenet

Separate Monero networks with separate chains. Mainnet carries real XMR. Testnet and stagenet are testing environments, and their coins are not mainnet money.

Example: A stagenet wallet cannot spend its test balance on mainnet.

Technical detail: --testnet and --stagenet are startup options. A beta stressnet is another explicitly defined test environment, not proof of mainnet deployment.

Sources: Monero network types · Stable implementation: cryptonote_config.h

Mining difficulty

Mining

A measure of how much hashing work is expected to find a valid block. Monero adjusts it as the chain develops to target an average block interval.

Example: Dividing network difficulty by the 120-second target gives a hashrate estimate, not a direct measurement of every miner.

Common confusion: Difficulty does not guarantee that the next block arrives in exactly two minutes.

Sources: Stable implementation: cryptonote_config.h · Stable implementation: cryptonote_core/blockchain.cpp

Mining pool

Mining

A way for miners to combine work and distribute rewards according to a payout scheme. Pool shares provide evidence of contributed work.

Example: A small miner may receive smaller, more frequent payouts instead of waiting to find a solo block.

Common confusion: Pool fees, custody and payout rules differ. A submitted share is not automatically a Monero block.

Read: Getting Started with P2Pool: How to Mine Monero

Sources: P2Pool project documentation

Mining share

Mining

Also called: share

A proof of work meeting a pool or sidechain target. It lets the pool account for contributions even when the work does not meet Monero block difficulty.

Example: Many accepted shares can arrive before anyone in the pool finds a Monero block.

Common confusion: Miner-to-pool shares and P2Pool sidechain shares can use different targets. A share count is not a block count.

Sources: P2Pool project documentation

Monero

General cryptocurrency

Also called: XMR

A cryptocurrency network designed for private, verifiable payments. Its native unit is XMR, and independent nodes enforce its rules.

Example: You can receive XMR into a wallet and verify the chain with your own node.

Common confusion: Blockchain privacy does not erase records held by exchanges, merchants or compromised devices.

Sources: Monero software overview · Moneropedia: wallet

Monero CLI wallet

Wallets and keys

Also called: monero-wallet-cli

monero-wallet-cli is the terminal wallet application. It scans for your outputs and prepares payments, while monerod handles the blockchain and peer network.

Example: A wallet can use a daemon on another computer without uploading its private spend key.

Common confusion: A monerod status command reports node state, not your wallet balance.

Shell command, does not open a wallet

monero-wallet-cli --help

Sources: CLI wallet reference

monerod

Node operations

Also called: daemon, Monero daemon

The node program supplied with Monero. It downloads and checks blocks, maintains a blockchain database and exchanges information with peers. A wallet connects to it but keeps its own keys.

Example: You can close your wallet while monerod continues synchronizing.

Shell command, exits after printing the version

monerod --version

Sources: Daemon options and console commands · Monero v0.18.5.4 release

Multisignature

Wallets and keys

Also called: multisig, multi-signature

A wallet arrangement requiring a threshold of participants to cooperate in authorizing a spend. Monero participants exchange setup and signing information rather than simply attaching several ordinary signatures to a payment.

Example: A two-of-three arrangement requires cooperation from two participants to spend under its signing rules.

Common confusion: Making copies of one seed does not create multisignature protection. Setup data, recovery requirements and software limitations differ from a single-key wallet.

Read: RetoSwap trading and escrow

Sources: Monero documentation: multisignature

O

One-time public key / output public key

Protocol and cryptography

Also called: output public key, one-time key

The public curve point attached to an output that a later input can reference in a ring. The recipient derives its corresponding private key using wallet secrets and transaction data.

Example: A recipient recognizes two incoming outputs with distinct public keys even though both used the same receiving address.

Technical detail: For a standard-address output, P = Hs(D || i)G + B, where D is the encoded shared derivation, i is the encoded output index and B is the public spend key. Hs maps data to a scalar. The derivation includes cofactor handling. This is a conceptual formula, not implementation code.

Sources: Stable implementation: crypto/crypto.cpp · Zero to Monero, second edition (mathematical background)

Onion service

Node operations

Also called: onion services, hidden service

A service reached within the Tor network using an onion address. The connection can avoid revealing the server network address to its client and does not use a Tor exit relay to reach that service.

Example: A wallet connects to a daemon onion endpoint through its configured Tor proxy.

Common confusion: An onion address does not prove that the service operator or application is trustworthy.

Read: Use Monero Love over Tor

Sources: Tor Project: onion services · Tor and I2P node routing

Order book

General cryptocurrency

Also called: offer book

A list of available buy and sell offers, usually showing price and quantity. A peer-to-peer offer list may also include payment methods and trade limits.

Example: An offer may quote a good price but cover less XMR than you want to buy.

Read: RetoSwap DEX: What It Is and How to Use It

Sources: BasicSwap protocols and messaging · RetoSwap project

Output

Protocol and cryptography

Also called: UTXO

A spendable unit created by a transaction, with a one-time public key and, for confidential payments, an amount commitment. A wallet balance is built from outputs it can recognize and spend.

Example: One payment can create two outputs for the recipient and change rather than changing a public account balance.

Common confusion: A receiving address can receive many outputs. It is not itself an output.

Sources: Stable implementation: ringct/rctSigs.cpp · Stable implementation: crypto/crypto.cpp

P

P2P network

Node operations

Also called: peer-to-peer network

The peer-to-peer network connects Monero daemons so they can exchange blocks, transactions and peer information. It is separate from a wallet connection to RPC.

Example: Your daemon downloads a new block from another daemon, then checks it locally.

Sources: Stable implementation: p2p/net_node.inl · Daemon options and console commands

P2Pool

Mining

A decentralized mining pool that uses a sidechain to track work and arrange direct miner payouts when it finds a Monero block.

Example: Your P2Pool node tracks sidechain shares while a separate miner sends it hashing work.

Common confusion: The P2Pool sidechain and the Monero blockchain are different chains. A sidechain share is not necessarily a main-chain block.

Read: Getting Started with P2Pool: How to Mine Monero

Sources: P2Pool project documentation · Moneropedia: p2pool

Pedersen commitment

Protocol and cryptography

A commitment made from two curve points and two scalars. Monero uses it to hide amounts while supporting checks that values balance.

Example: Nodes can add output commitments when checking a transaction instead of adding publicly visible payment amounts.

Technical detail: Write C = bG + vH, with amount v and secret blinding scalar b. G and H are fixed points whose discrete-log relationship must not be known. Binding relies on the relevant hardness assumption. Actual transactions also require valid signatures and range proofs.

Sources: Moneropedia: pedersen commitment · Stable implementation: ringct/rctSigs.cpp

Peer and peer discovery

Node operations

Also called: peer discovery, peer list

A peer is another node connected to your daemon. Discovery uses initial contact points and exchanged peer information to find possible connections.

Example: A remembered address appears in a peer list even though it is not currently connected.

Common confusion: Known peers are not the same count as active connections.

Command entered in the running daemon console

print_pl

Sources: Stable implementation: p2p/net_node.inl · Stable implementation: daemon/command_server.cpp

Peer banning

Node operations

Preventing connections to a peer address, automatically after certain failures or through an operator action. A ban is local node policy.

Example: A daemon may reject a peer sending invalid data while continuing to communicate with other peers.

Common confusion: An address on a ban list is not, by itself, proof of who operated it or why the failure happened.

Read-only command entered in the running daemon console

bans

Sources: Stable implementation: p2p/net_node.inl · Stable implementation: daemon/command_server.cpp

Private spend key

Wallets and keys

Secret scalar used to derive the one-time private keys that authorize spending. In an ordinary wallet, it is central to control of the funds.

Example: An offline signer holds spending secrets while a view-only computer prepares unsigned transactions.

Common confusion: A transaction secret key and a private view key are not substitutes for the spend key.

Read: Monero Offline Wallets: Cupcake, Cold Storage and Signing

Sources: Moneropedia: spendkey · Stable implementation: crypto/crypto.cpp

Private view key

Wallets and keys

Secret material used with public transaction data to recognize incoming outputs and recover their amounts. It does not alone authorize spending.

Example: A view-only wallet can notice a received payment while its spend key stays offline.

Common confusion: It exposes financial information. It does not automatically give a complete record of outgoing recipients or spent status.

Sources: Moneropedia: viewkey · Stable implementation: wallet/wallet2.cpp

Proof of work

Mining

Also called: PoW

A mechanism that requires miners to find a hash meeting a difficulty target. Nodes can check the result much more cheaply than miners search for it.

Example: A miner tries many candidate hashes before finding one accepted as a block proof.

Sources: Proof of work · Stable implementation: cryptonote_core/blockchain.cpp

Pruned node

Node operations

Also called: pruning

A validating node that discards selected old transaction proof data after checking it. Monero retains the information needed to track the chain and keeps portions of the prunable data to serve peers.

Example: Two synced nodes can report the same height while the pruned one uses less disk space.

Technical detail: Pruning an existing LMDB database in place can free internal pages without shrinking the file on disk. Do not equate a pruning flag with immediate filesystem space recovery.

Sources: Moneropedia: pruning · Stable implementation: cryptonote_core/blockchain.cpp

Public address

Wallets and keys

Also called: receiving address, standard address

An encoded destination containing public keys and network information. It tells a sender how to create outputs for a wallet.

Example: You give a customer a receiving address, then your wallet detects the output their transaction created.

Common confusion: The address you share is not the one-time output public key stored on the blockchain.

Sources: Standard address construction

Public node

Node operations

A node whose operator offers an interface to other users. On wallet connection lists, this usually means publicly reachable daemon RPC.

Example: A public wallet endpoint may accept restricted RPC queries while rejecting administrative methods.

Common confusion: An open P2P port alone does not make a node a public wallet RPC service.

Sources: Daemon options and console commands · Remote node documentation

Public spend key

Wallets and keys

The public curve point corresponding to the private spend key. A standard address includes it as part of the information senders use to create outputs.

Example: A sender can use your public address without learning the secret required to spend the payment.

Technical detail: For a standard wallet, B = bG, with private scalar b and generator G. Subaddresses use derived public keys.

Sources: Standard address construction · Stable implementation: crypto/crypto.cpp

Public view key

Wallets and keys

The public curve point corresponding to a private view key. Senders use it to derive recipient-specific output information.

Example: A sender uses the public view key encoded in a standard address to construct a payment the recipient can recognize.

Technical detail: For a standard wallet, A = aG. Knowing A does not reveal the private scalar a.

Sources: Standard address construction · Stable implementation: crypto/crypto.cpp

Public-key cryptography

Protocol and cryptography

Also called: asymmetric cryptography

Cryptography that separates public information from a corresponding secret. Monero uses public keys for receiving constructions and signatures, while private keys remain with wallet holders.

Example: Someone can construct a payment using your address without knowing the keys needed to spend it.

Common confusion: A public/private key pair is not automatically an encryption system. Signing and key agreement are different operations.

Sources: Standard address construction · Stable implementation: crypto/crypto.cpp

R

RandomX

Mining · Current

The proof-of-work algorithm used by current Monero mining. It is designed around workloads suited to general-purpose CPUs, including memory-intensive execution.

Example: Two CPUs can have different RandomX performance even at the same advertised clock speed.

Sources: RandomX documentation · RandomX specification

Range proof

Protocol and cryptography

A proof that a committed number lies inside an allowed range without revealing that number. Monero needs this alongside balance checks to rule out invalid amount constructions.

Example: A transaction proves its output amounts are within the permitted range while leaving the amounts hidden.

Technical detail: Current output range proofs cover unsigned 64-bit amounts. Arithmetic balance alone would be insufficient because curve scalar arithmetic wraps modulo a group order.

Sources: Stable implementation: ringct/rctSigs.cpp · Bulletproofs+ paper, IACR 2020/735

Remote node

Node operations

A daemon reached over a network instead of running alongside the wallet. It supplies blockchain data and accepts transactions for relay.

Example: A phone wallet uses a server to obtain blocks it needs to scan.

Common confusion: Remote does not mean trusted. The operator can observe connection metadata and can provide incomplete or misleading responses.

Read: Connect Your Monero Wallet to a Remote Node

Sources: Remote node documentation

Restore height

Wallets and keys

A starting block position for wallet scanning. Choosing a point before the first payment avoids scanning irrelevant earlier history.

Example: If a restored wallet looks empty because scanning started too late, use an earlier restore point and rescan.

Common confusion: A restore height cannot replace the correct keys. Polyseed records an approximate birthday, not the entire transaction history.

Sources: CLI wallet reference · Polyseed format

Restricted RPC

Node operations

A daemon mode that limits available methods and some returned data. It is intended to reduce what remote clients can do or learn through RPC.

Example: A public service permits blockchain queries but does not offer every daemon administration method.

Technical detail: --restricted-rpc is a daemon startup option. Restriction does not provide authentication, encryption, bandwidth limits or immunity to abuse.

Sources: Stable implementation: rpc/core_rpc_server.cpp · Daemon options and console commands

Ring member

Protocol and cryptography

One candidate output included in a ring signature. The wallet knows which member it is spending, while the others act as decoys.

Example: A current ring contains the real output and other outputs selected by the wallet.

Common confusion: Ring members are outputs, not a list of people who jointly sign.

Sources: Moneropedia: ringsize · Stable implementation: cryptonote_core/blockchain.cpp

Ring signature

Protocol and cryptography

A signature proving that a signer controls one key in a specified group without identifying which one. In Monero, the group consists of candidate outputs for an input.

Example: A payment input names a ring of candidate outputs, but its signature does not announce which candidate is spent.

Common confusion: Ring signatures concern input ambiguity. Recipient unlinkability comes from the output-address construction.

Sources: Moneropedia: ringsignatures · CLSAG paper, IACR 2019/654

Ring size

Protocol and cryptography · Current

The number of candidate outputs in a ring, including the real input. The verified stable mainnet rules require 16 for ordinary current ring inputs.

Example: A ring of 16 contains one real input and 15 decoys.

Common confusion: Sixteen candidates do not guarantee equal likelihood. Timing, selection and outside information can affect analysis.

Sources: Stable implementation: cryptonote_core/blockchain.cpp · Stable implementation: cryptonote_config.h

RingCT

Protocol and cryptography

Also called: Ring Confidential Transactions

Ring Confidential Transactions is the framework that lets nodes verify confidential Monero payments without publishing their transferred amounts. It combines commitments, signatures and proofs.

Example: A node checks that committed inputs balance committed outputs plus the public fee without reading the hidden amounts.

Common confusion: RingCT does not encrypt the entire transaction. Fees, key images, output keys and other structural data remain public.

Sources: Moneropedia: ringCT · Stable implementation: ringct/rctSigs.cpp

RPC

Node operations

Also called: remote procedure call

Remote procedure call: an application interface for asking another program to perform a named operation. Monero exposes daemon and wallet APIs with different capabilities.

Example: An application asks a daemon for get_info rather than parsing its terminal screen.

Technical detail: A method name such as get_info is not a shell option. Some daemon methods use JSON-RPC and others use dedicated HTTP paths.

Sources: Daemon RPC reference · Wallet RPC reference

RPC authentication

Node operations

A credential check that controls access to an RPC service. monerod supports RPC login credentials, but credentials do not replace transport protection or network access controls.

Example: An operator keeps administrative RPC private and requires authentication for the authorized client.

Technical detail: The daemon option is --rpc-login. Avoid placing real passwords in shared command examples, shell history or public configuration repositories.

Sources: Daemon options and console commands · Stable implementation: rpc/core_rpc_server.cpp

S

Scalar

Protocol and cryptography

An integer used in curve-group calculations, commonly interpreted modulo the subgroup order. Private keys and commitment masks are examples in Monero.

Example: In B = bG, b is the private scalar and B is the public point.

Common confusion: A scalar and an encoded curve point can have the same byte length while meaning different things.

Sources: Edwards25519 curve · Stable implementation: crypto/crypto.cpp

Seed node

Node operations

An initial peer contact that helps a new daemon discover other nodes. It is a networking aid, not an authority that decides which blocks are valid.

Example: A fresh node contacts a seed, learns other peers and validates the chain it receives.

Sources: Stable implementation: p2p/net_node.inl

Seed phrase

Wallets and keys

Also called: mnemonic, recovery phrase, Polyseed

A human-readable encoding used to restore wallet secrets. The format matters: Monero wallets use several schemes, and word counts are not interchangeable.

Example: A 16-word Polyseed needs compatible restoration support. A legacy 25-word backup also needs an appropriate scan start point.

Technical detail: Feather supports 16-word Polyseed, older 14-word Feather seeds and 25-word Monero seeds. Hardware wallets may use their own recovery scheme. Record the wallet and format, any seed passphrase, and recovery instructions. A wallet-file password is not necessarily a seed passphrase.

Common confusion: A seed may recover funds without restoring local labels, transaction notes or every piece of transaction-proof data. Do not publish or paste it into an online checker.

Sources: Monero seed schemes · Legacy seed format · Polyseed format · Feather seed formats and restoration

Self-custody

Wallets and keys

Keeping control of the keys needed to authorize spending instead of leaving that authority with a service. It also makes recovery your responsibility.

Example: You withdraw XMR from an exchange to a wallet whose recovery material only you control.

Read: Monero Offline Wallets: Cupcake, Cold Storage and Signing

Sources: Moneropedia: wallet · Moneropedia: spendkey

Shared secret

Protocol and cryptography

A value that two parties can derive using their own secret and public information from the other party. Monero uses this idea in output construction and recognition.

Example: In the simple standard-address case, the sender derives rA and the receiver derives aR, with A = aG and R = rG.

Technical detail: These expressions give the same point in the simplified key-agreement relationship. Production derivations also specify encoding, cofactor handling and hashing.

Sources: Standard address construction · Stable implementation: crypto/crypto.cpp

Slippage

General cryptocurrency

The difference between the price expected when submitting a trade and the price obtained. Market movement and execution conditions can contribute.

Example: A market order fills at a worse average price than the quote displayed a moment earlier.

Common confusion: Price impact from your own trade is a related but distinct cause of execution cost. Fixed-price peer offers have their own acceptance and settlement rules.

Sources: Uniswap: price impact and slippage

SOCKS proxy

Node operations

Also called: SOCKS, SOCKS5, SOCKS5 proxy

An intermediary that accepts application requests for network connections. SOCKS5 supports requests naming a host or an address, which matters when deciding where name resolution occurs.

Example: A wallet sends its connection request to a local Tor SOCKS proxy instead of opening a direct connection to the remote node.

Common confusion: SOCKS itself is not an anonymity network. Each application must use the intended proxy and name-resolution path.

Sources: IETF RFC 1928: SOCKS5 · Tor and I2P node routing

Stealth address

Protocol and cryptography

Also called: one-time address

The one-time output-address construction used to avoid placing the reusable receiving address directly on-chain. Senders derive fresh output keys from recipient public keys and transaction-specific information.

Example: Two payments to the same receiving address normally produce different output public keys.

Common confusion: This does not hide every transaction field or stop the sender from knowing whom they paid.

Sources: Moneropedia: stealthaddress · Stable implementation: crypto/crypto.cpp

Stratum

Mining

A family of mining communication protocols used to send jobs to miners and return submitted work. Monero mining software and pools use implementations suited to their mining workflow.

Example: XMRig receives a job from P2Pool and submits a result that meets the requested share target.

Common confusion: A Stratum endpoint is not a daemon RPC endpoint. TLS support also depends on the connection configuration.

Read: Getting started with P2Pool

Sources: XMRig: pool connections · P2Pool project documentation

Subaddress

Wallets and keys

An additional receiving address derived by the same wallet. Separate subaddresses help avoid giving unrelated payers the same reusable identifier.

Example: You use different subaddresses for two customers while both payments arrive in one wallet.

Common confusion: Subaddresses do not stop a merchant, exchange or device from linking information it already holds.

Sources: Subaddress construction

T

Tail emission

Mining

The continuing base subsidy after the main emission phase. Monero has a base tail subsidy of 0.6 XMR per block at a target interval of two minutes.

Example: Miners still receive newly issued XMR after the initial emission curve has tapered down.

Technical detail: Fees are additional. Block-weight penalties can reduce the subsidy, and actual block times vary.

Sources: Moneropedia: tail emission · Stable implementation: cryptonote_config.h · Stable implementation: cryptonote_core/blockchain.cpp

Tor

Node operations

A network that routes connections through relays to reduce the direct link between a client and its destination. Onion services provide connections within Tor.

Example: A wallet configured for an onion node reaches it through Tor instead of connecting directly to its public IP address.

Common confusion: Tor Browser settings do not automatically configure a separately running wallet or daemon.

Read: I2P vs. Tor: What's the Difference?

Sources: Tor Project: how Tor works · Tor and I2P node routing

Transaction

General cryptocurrency

A protocol message that creates outputs and, for an ordinary payment, proves authorized spending of existing outputs. It also records the fee and required public proof data.

Example: A payment can create a recipient output and a change output back to the sender.

Sources: Moneropedia: transaction · Stable implementation: cryptonote_core/blockchain.cpp

Transaction fee

General cryptocurrency

The public amount a transaction pays to the miner that includes it. It is separate from the private payment amount sent to the recipient.

Example: If a wallet sends 0.2 XMR and displays a fee of 0.0001 XMR, that fee is an additional cost, not the transferred amount.

Technical detail: The numbers here are illustrative, not a current fee quote. Fees depend on transaction weight, network rules and wallet policy.

Read: Monero Adds Wallet Protection Against Excessive Fees From Remote Nodes

Sources: Daemon RPC reference · Stable implementation: ringct/rctSigs.cpp

Transaction ID

General cryptocurrency

Also called: txid, transaction hash

The hash used to identify a transaction. It lets software look up public transaction data but is not a complete payment receipt.

Example: You paste a transaction ID into an explorer to check whether it has been mined.

Common confusion: A transaction ID alone does not reveal the receiving address or hidden payment amount.

Sources: Daemon RPC reference · Monero hashing

Transaction pool

Node operations

Also called: mempool, txpool

The transactions a particular node knows about that have not been included in its accepted blockchain. Nodes can temporarily hold different pools.

Example: A just-broadcast payment appears in one node before a peer receives it.

Command entered in the running daemon console

print_pool_stats

Sources: Daemon RPC reference · Stable implementation: daemon/command_server.cpp

Transaction private key

Wallets and keys

Also called: transaction secret key, tx key

A secret used by the sender when deriving output information for a transaction. Wallet commands often call it the transaction key or tx key.

Example: A sender may use retained transaction secret material to help prove a payment to a particular recipient.

Common confusion: This key alone does not authorize spending the recipient outputs. Disclosure can still damage payment privacy.

Sources: Stable implementation: wallet/wallet2.cpp · Stable implementation: crypto/crypto.cpp

Transaction proof

Wallets and keys

A proof used to demonstrate a particular payment relationship to someone who has the required address and transaction information. It is different from publishing a transaction ID alone.

Example: A sender generates a wallet-supported proof for a merchant disputing receipt of a payment.

Common confusion: A proof can disclose information to its verifier. Do not treat it as a public statement that reveals no payment details.

Sources: Wallet RPC reference · Stable implementation: wallet/wallet2.cpp

Transaction public key

Protocol and cryptography

Public transaction data that lets recipients derive the shared information needed to recognize outputs. A transaction can contain additional public keys.

Example: A wallet combines its private view key with transaction public data while scanning an incoming payment.

Technical detail: For the simple standard-address construction, R = rG. Transactions involving subaddresses can use a different construction and additional keys.

Sources: Stable implementation: crypto/crypto.cpp · Standard address construction · Subaddress construction

Transaction relay

Node operations

Forwarding a transaction between nodes so it can reach miners and other peers. Relay policy is not the same thing as confirmation.

Example: A wallet receives a successful submission response, but the transaction is still waiting for a block.

Sources: Stable implementation: cryptonote_protocol/levin_notify.cpp · Daemon RPC reference

Transaction relay over Tor and I2P

Node operations

A daemon can route locally submitted transactions through configured Tor or I2P peers. This separates that relay path from direct clearnet transaction broadcasting.

Example: A wallet talks to its local daemon, which relays its payment through a configured anonymity-network zone.

Common confusion: --tx-proxy does not mean all daemon traffic, block synchronization or wallet RPC connections use Tor or I2P. Each path needs its own configuration.

Read: Monero Developers Address Tor and I2P Privacy Weakness in Node Synchronization

Sources: Tor and I2P node routing · Stable implementation: p2p/net_node.inl · Stable implementation: cryptonote_protocol/levin_notify.cpp

Transaction verification

Node operations

Checking a transaction against protocol rules, including authorization, proofs, value balance and whether its key images have already been spent.

Example: A transaction with a valid-looking shape is still rejected if its proof fails.

Common confusion: Public verification does not require revealing the payment amount or identifying the real ring member.

Sources: Stable implementation: cryptonote_core/blockchain.cpp · Stable implementation: ringct/rctSigs.cpp

Transaction weight

Node operations

The measure Monero uses to account for transaction fees and block capacity. It is based on transaction data, with protocol-defined adjustments for some proof structures.

Example: Two transactions with different input and output counts can require different fees even when both send the same amount of XMR.

Common confusion: Weight is not the payment amount. Do not assume it always equals the serialized byte length reported by an explorer.

Sources: Stable implementation: cryptonote_core/blockchain.cpp · Daemon RPC reference · Stable implementation: wallet/wallet2.cpp

U

Unlock time and spendable age

Wallets and keys

Also called: locked balance, unlocked balance, maturity

Rules determining when an output may be spent. Ordinary received outputs have a 10-block spendable age, while miner outputs have a 60-block maturity rule in the reviewed stable code.

Example: A wallet can show a confirmed incoming payment in its total balance before it appears in the unlocked balance.

Technical detail: An explicit transaction unlock_time can add a height or timestamp condition. Block counts are not exact wall-clock delays. Use the wallet unlocked status rather than a timer.

Common confusion: A confirmation counter and the earliest block allowed to spend an output have boundary conventions. Do not infer spendability solely from a rounded “20 minutes” estimate.

Sources: Stable implementation: cryptonote_config.h · Stable implementation: cryptonote_core/blockchain.cpp · Stable implementation: wallet/wallet2.cpp

V

View-only wallet

Wallets and keys

Also called: watch-only wallet

A wallet with viewing information but without the private spend key. It can find incoming outputs but cannot sign ordinary spends on its own.

Example: An online watch wallet monitors receipts for an offline signer.

Common confusion: Spent status can require imported key images from the signing wallet. A view key alone does not automatically identify all outgoing payments.

Read: Monero Offline Wallets: Cupcake, Cold Storage and Signing

Sources: Stable implementation: wallet/wallet2.cpp · Wallet RPC reference

W

Wallet

Wallets and keys

Software or hardware that manages keys and uses blockchain data to find funds and prepare payments. The coins are represented by blockchain outputs, not stored as files inside the app.

Example: Restoring a compatible seed lets a new wallet scan for the same outputs.

Sources: Moneropedia: wallet

Wallet RPC

Wallets and keys

monero-wallet-rpc provides an API for a loaded wallet. Its authority depends on that wallet, including whether it holds spending keys or is view-only.

Example: A shop can query a view-only wallet for incoming payments without placing spend keys on that server.

Sources: Wallet RPC reference

Wallet synchronization

Wallets and keys

Also called: wallet scan, wallet sync

Scanning blockchain data to recognize outputs belonging to a wallet and update its state. The wallet can do this through a local or remote daemon.

Example: A node is fully synced, but a newly restored wallet still needs to scan years of blocks.

Sources: Stable implementation: wallet/wallet2.cpp · CLI wallet reference

Z

Zero-knowledge proof

Protocol and cryptography

Also called: ZKP

A proof of a statement that does not reveal the secret witness beyond what the statement itself discloses. Monero uses such techniques to validate hidden transaction information.

Example: A range proof demonstrates that a hidden amount is allowed without exposing its exact value.

Common confusion: The statement and public inputs remain visible. Zero knowledge does not mean the whole transaction reveals nothing.

Sources: Bulletproofs paper, IACR 2017/1066 · Bulletproofs+ paper, IACR 2020/735

ZMQ

Node operations

Also called: ZeroMQ

ZeroMQ is a messaging library used by monerod for interfaces including publish/subscribe notifications. Subscribers can receive events instead of repeatedly polling for them.

Example: P2Pool can subscribe to daemon notifications when new block data becomes available.

Common confusion: --zmq-pub configures a publisher. It is distinct from the ZMQ RPC bind options and from a mining pool Stratum port.

Sources: Stable implementation: daemon/daemon.cpp · P2Pool project documentation

About the sources

Operational examples are checked against the stable source and official documentation. The examples show input, not captured daemon output, and do not change a running service. Cryptographic papers explain constructions, while the stable code determines which ones are deployed.

Zero to Monero, second edition, predates CLSAG and Bulletproofs+. It is used for mathematical background, not as the current transaction-format specification. No real wallet secrets or payment identifiers are included.

Support Monero Love

Help keep the public nodes and packages running. Send any amount of XMR.

Scan with a Monero wallet to donate to Monero Love.89hGTKxRVA3AUeKAbCRBt5TMSzq3MQZooNNsezCpNFjp2oeJPRx8AJeGKA8ziHZNqab78f4Vr1ntxhPDxX5298nnGZjHkhm