Introduction to Monero: What It Is, How It Works, and Why It's Different

Introduction to Monero, part 1 of 3. 1. Fundamentals · 2. Privacy · 3. Wallets and nodes

Monero is digital money that people can send to one another without asking a bank to process the payment. Its currency symbol is XMR. Unlike Bitcoin's public transaction ledger, Monero's blockchain does not normally reveal the amount of a payment, the recipient's reusable address or which earlier output the sender spent.

That privacy is built into ordinary Monero payments. You still need a secure wallet, a trustworthy source for the software and some understanding of who can observe your activity. A private payment record cannot protect a computer infected with malware or erase a receipt held by a shop.

This first part explains digital money, follows one payment from Alice to Bob, and covers mining and supply. Parts two and three explain the privacy mechanisms and practical wallet choices. Technical details were checked on November 8, 2026 against Monero v0.18.5.4. Research that needs a future network upgrade is identified separately.

What Monero is, and where it came from

Monero is an open-source cryptocurrency with its own network, blockchain and currency. Someone can accept XMR for work, send it to another person or keep it in a wallet they control. Its market price can change sharply. A payment of 1 XMR can buy a different amount in dollars from one day to the next.

The project launched in April 2014 from CryptoNote, a design that used different transaction and privacy mechanisms from Bitcoin. The original name was BitMonero. The community adopted Monero after a disagreement with the initial maintainer. There was no premine. Founders did not receive an allocation mined privately before the public launch. The project's history describes that split, and our CryptoNote origins guide follows the design in more detail.

No central bank issues XMR and no company can unilaterally set the network's rules. Software contributors propose changes, miners produce blocks, and people running validating nodes decide which rules their software enforces. Maintainers and large operators can influence decisions, but publishing code is not enough to make everyone run it. Monero also depends on people doing maintenance, security review and support. Decentralization does not remove those responsibilities.

A bank normally maintains your account balance and authorizes changes to its records. A self-custody Monero wallet instead holds the keys needed to authorize spending. Independent computers check the resulting transaction. There is no account-opening process built into the protocol and no central customer-service desk that can reset lost keys or cancel a completed transfer.

Monero uses a different transaction architecture from Bitcoin, including its output addressing, spending proofs and hidden-amount accounting. Those choices affect everything from wallet scanning to transaction size. Normal transfers use the same required privacy mechanisms.

Cryptocurrency and blockchains, from the beginning

A shared record with rules

A blockchain is a sequence of transaction records grouped into blocks. Each block identifies its predecessor using a cryptographic hash, a short value derived from the predecessor's data. Change that data and the hash changes. The links make edits detectable, while proof of work makes replacing accepted history costly.

A transaction consumes existing outputs and creates new ones. An output is a piece of value created by an earlier transaction, with cryptographic conditions that determine who can spend it. Wallet balances are calculated from the outputs a wallet controls. They are not an account balance stored under your name in a central database.

Copying a wallet file must not let its owner spend the same money twice. That is the double-spending problem. Cryptographic authorization establishes who may spend. Network consensus establishes which valid spending history the network accepts when competing transactions or blocks appear.

Wallets, keys and signatures

A wallet is software, sometimes combined with a hardware device, that manages keys and payment records. The coins are represented by blockchain records, not files sitting inside the app. Deleting the app does not delete those records. Losing every usable backup of the spending keys can make the funds inaccessible.

Public-key cryptography pairs information you may share with information you must protect. Public keys allow other people to send payments or verify proofs. Private keys authorize operations that outsiders should not be able to perform. A public address contains public information, not the secrets needed to spend.

A digital signature is a mathematical proof tied to a message and a private key. It is not a picture of a handwritten signature. A signature on one transaction cannot simply be pasted onto a different transaction to authorize a new payment. Monero uses specialized signatures that prove a spending relationship while keeping the actual spent output ambiguous.

Nodes, mining and consensus

A full node checks transactions and blocks against the network's consensus rules. Nodes reject invalid signatures, forbidden spending and blocks that do not satisfy the rules. They also communicate with peers to exchange data. A large number of peers claiming that a transaction is valid does not make a node accept invalid mathematics.

Miners compete to find a block whose proof-of-work hash meets the current difficulty target. Finding one requires repeated computation. Checking the winning proof is much cheaper. When valid branches compete, Monero's chain selection uses accumulated proof-of-work difficulty. The phrase "longest chain" is shorthand that can mislead if it suggests simply counting blocks.

A block gives a payment its first confirmation. Later blocks add confirmations and make replacing that part of history more expensive. This is probabilistic finality, not an absolute promise that a block can never be replaced. A chain reorganization can occur when a node learns of a stronger competing valid chain.

This combination lets a network verify payments without a bank's account ledger. It does not eliminate trust in software, cryptographic assumptions or the availability of honest network connections. Running your own validating node lets you check more of those conditions yourself. The deployed checks are in Monero's blockchain validation code.

Why Monero exists: privacy and fungibility

Bitcoin's base-layer ledger makes transaction amounts and the links between spent outputs public. Its addresses and spending scripts are pseudonymous, rather than automatically labeled with real names. A person who learns that an address belongs to you may be able to follow payments connected to it.

Blockchain analysis combines that public graph with other information. An exchange knows the withdrawal addresses used by its customers. A merchant knows which payment paid an invoice. Analysts can also infer groups of addresses that may share an owner using transaction patterns. These inferences have assumptions and exceptions. They are not all cryptographic proofs. Bitcoin's own privacy guidance explains the exposure and the need to avoid address reuse.

Pseudonymity means acting under an identifier instead of your legal name. Privacy concerns what information another party can learn. A pseudonym can provide little privacy once somebody connects it to a person and follows years of public records.

Financial privacy has ordinary uses. An employee may want to receive a salary without revealing savings to a landlord. A customer may want to pay a business without making unrelated purchases visible. A business may need to keep supplier relationships confidential. In each case, the person receiving the payment can know the information needed for that payment without the whole world receiving the same information.

Fungibility means units are generally interchangeable. A shop normally treats one valid twenty-dollar note as having the same face value as another. On a transparent blockchain, a recipient or service may treat coins differently because of their visible history or an analyst's risk label. Hiding direct transaction links and amounts makes that kind of public history-based discrimination harder in Monero.

A service can still reject Monero, refuse a customer or act on records it holds outside the blockchain. Privacy does not prevent access restrictions or turn a volatile asset into a stable one.

A Monero payment from Alice to Bob

Suppose Alice wants to pay Bob 1 XMR. The amounts in this hypothetical payment illustrate the accounting. Use your wallet's current fee estimate for a real payment. Bob gives Alice a receiving address. Alice's wallet controls an unlocked output worth 1.3 XMR.

1. Alice enters Bob's address and the amount. Her wallet checks the address format and network. Alice still has to check that it belongs to Bob. A valid address can belong to a scammer or be substituted by malware.
2. The wallet selects spendable outputs. In this example it selects the 1.3 XMR output. If one output were insufficient, it could select several. Locked outputs cannot yet be used.
3. The wallet constructs outputs and proofs. It creates a one-time destination for Bob, usually creates change for Alice, chooses decoy outputs for each input and produces the required spending, balance and range proofs. If the illustrative fee were 0.0001 XMR, change would be 0.2999 XMR. The whole selected output is consumed, rather than partly left behind.
4. Alice broadcasts the signed transaction. A node checks it and, if acceptable under its relay policy, passes it onward. The transaction may wait in the transaction pool before a miner includes it. Broadcasting is not confirmation.
5. Other nodes validate it independently. They check its format, referenced outputs, signatures, key images, amount commitments and range proofs. They can reject a repeated spend without being told which ring member is the real one.
6. A miner includes it in a block. The miner performs proof of work on a block candidate. Other nodes accept the resulting block only if the proof and the block's contents satisfy their rules.
7. Bob's wallet recognizes its output. By scanning transaction data with its private view key, Bob's wallet identifies the output intended for it and recovers its amount. It may show an unconfirmed incoming payment before block inclusion. Bob does not have to be online when Alice sends.
8. Bob waits until the output is spendable. Ordinary received outputs have a ten-block spendable-age rule in the reviewed implementation, roughly twenty minutes at the target block rate. Block intervals vary. Mining rewards have a separate sixty-block maturity rule, and an explicit transaction unlock time can impose another restriction. Follow the wallet's unlocked balance rather than a wall-clock countdown.

The network proves that this is an authorized, value-conserving spend of an eligible member of each input ring, with no repeated key image. An outside observer sees those rings and proofs without a public statement identifying Alice, Bob or the 1 XMR amount. Alice and Bob know more because they participated in the payment. A compromised wallet or a merchant's records can reveal information that the blockchain keeps confidential.

The wallet implementation constructs transactions, while consensus constants and validation code govern spendability. Our unlock-time reference explains the different kinds of waiting.

Monero and Bitcoin compared

Both systems let people validate a proof-of-work monetary network without a bank maintaining their account. Their base-layer transaction designs make different information public and impose different costs. This table concerns ordinary on-chain payments, not every wallet, mixing technique or separate payment network built around either currency.

Monero	Bitcoin
Default transaction privacy. Ordinary transfers conceal amounts and reusable recipient addresses, and obscure the real spent output among ring members.	Default transaction privacy. Amounts, output scripts and spending links are public. Addresses are pseudonymous.
Address visibility. One-time output keys appear on chain. The recipient's shared address does not normally appear as the destination.	Address visibility. Output scripts are public and often represented as addresses. Public keys may become visible depending on the script and spend.
Fungibility. Hidden amounts and ambiguous spending links make public history-based classification harder.	Fungibility. A public transaction graph enables history-based analysis, with possible errors and contested labels.
Mining. RandomX aims to favor general-purpose CPUs.	Mining. SHA-256 mining is dominated by specialized ASIC hardware.
Issuance. A declining initial subsidy followed by continuing tail emission. No fixed lifetime cap.	Issuance. Subsidy halves every 210,000 blocks, approaching a maximum near 21 million BTC.
Block timing. Approximately two minutes on average.	Block timing. Approximately ten minutes on average.
Fees. Depend on weight, fee estimates and priority. The fee is public.	Fees. Usually priced by virtual transaction size and demand for block space. The fee is public.
Validation. Nodes check signatures, key images, commitments and range proofs as well as block rules.	Validation. Nodes check signatures, scripts, explicit values and unspent-output rules as well as block rules.
Recovery and synchronization. Wallets scan for privately addressed outputs. Seed format and restore height matter.	Recovery and synchronization. Recovery depends on the wallet's backup format, key derivation and address discovery. A seed alone may need wallet-specific context.
Data and complexity. Privacy proofs and rings add data and cryptographic complexity.	Data and complexity. Many ordinary payments have smaller, simpler transparent transaction structures. Comparisons depend on transaction type.

Monero's monetary rules are publicly verifiable, but its auditability differs from a transparent ledger. You cannot add up all confidential output amounts by reading them from a block explorer. Nodes instead verify the issuance rules and the proofs enforcing conservation. Bugs in cryptographic code or validation remain serious risks. Public amounts make some Bitcoin checks easier to inspect, while also exposing information about users.

Monero's adaptive block-weight rules allow capacity to change, subject to limits and reward penalties. They do not provide unlimited cheap throughput. Larger transactions and blocks still require storage, bandwidth and verification work. Bitcoin also has capacity and fee tradeoffs, but makes different choices about base-layer data and privacy.

For the Bitcoin side, see its transaction documentation, blockchain documentation and wallet recovery discussion. Neither design removes the need to choose secure software and understand what information your counterparties keep.

Mining, RandomX and network security

RandomX is Monero's proof-of-work algorithm. It runs randomized programs and uses memory access patterns intended to suit general-purpose processors. The goal is to reduce the advantage of a narrowly specialized mining chip and make existing CPUs useful for mining. See the RandomX specification for the actual construction.

ASIC resistance is an engineering goal. Specialized hardware may still be possible. CPUs also differ considerably in performance and efficiency. Cheap electricity, capital, access to hardware and control of software distribution can still concentrate mining. The ability to start a miner on a laptop does not mean the laptop will earn more than it costs to operate.

A miner builds a candidate block, chooses valid transactions and repeatedly evaluates proof of work while varying eligible block data. It is not decrypting other people's payments. A successful miner can claim the permitted new issuance plus included transaction fees, subject to consensus rules. Every validating node still checks the block. Owning most of the hash power would not make invalid signatures valid, although it could enable censorship or reorganizations and double-spending attacks against recent payments.

Difficulty adjusts as the network observes block production, aiming to keep the average interval near two minutes as hash power changes. The adjustment cannot promise a block every two minutes. Finding a block is random, and sudden changes in mining power can disturb timing.

Solo mining, pools and P2Pool

A solo miner receives a reward only when it finds an accepted block. With a small share of network hash power, the wait can be long and unpredictable. A conventional pool combines miners' work and uses easier proofs called shares to calculate payouts. That reduces individual payout variance but introduces an operator's rules, fees and possible custody of unpaid earnings.

P2Pool coordinates mining through a separate sharechain instead of a central pool server. When a qualifying Monero block is found, its coinbase transaction pays eligible miners directly according to P2Pool's payout rules. There is no central pool wallet holding those rewards. Running P2Pool still takes software, network connections and maintenance.

P2Pool participation and payouts also have privacy implications. Its sharechain publicly identifies participating payout addresses, so use a separate mining wallet rather than the wallet used for ordinary private spending. Follow the project's P2Pool documentation and our setup guide. The pool dashboard is useful for observing concentration, not evidence that future decentralization is guaranteed.

Supply and tail emission

Monero's initial mining subsidy declined as coins were issued. In 2022 it reached tail emission: a base subsidy of 0.6 XMR per approximately two-minute block. Block-weight penalties can reduce a block's subsidy. Transaction fees are additional miner revenue, transferred from existing holders rather than newly created XMR. The reward calculation defines these details.

Unlike Bitcoin, Monero does not approach a fixed lifetime supply cap. Continuing issuance gives miners a source of revenue alongside fees. It is a design choice about security funding, not a guarantee that mining will always be profitable or that the network cannot be attacked. Miner incentives still depend on costs, fees and the market value of the reward.

At the target interval, a 365-day year contains about 262,800 blocks. Multiplying by 0.6 gives 157,680 XMR per year, before reward penalties and variation in actual block timing. This is a calculation from the protocol targets, not a measured yearly issuance figure.

For an illustrative starting supply of 20 million XMR, that addition is about 0.79% of the starting supply. At 40 million XMR, the same addition is about 0.39%. The supply totals are examples, not claims about today's circulating supply. The absolute annual addition stays approximately steady while its percentage of an increasing total falls.

Calling Monero "inflation-free" would be wrong because new XMR continues to be created. Calling it "unlimited inflation" without explaining the rate is also unhelpful. Supply has no finite cap over an unlimited future, but the annual issuance rate as a percentage of supply tends downward. Monetary issuance also differs from changes in purchasing power. A lower percentage supply increase does not guarantee a rising exchange price.

Bitcoin's subsidy instead falls by half after each 210,000-block interval, so its long-term miner revenue becomes increasingly dependent on fees. Monero retains a block subsidy to help fund mining, while Bitcoin places more of that burden on future fee demand.

Continue with part two: how Monero privacy works.