Monero

transfer Assessed on Monero mainnet (monero:418015bb9ae982a1975da7d79277c270)www.getmonero.org

Ratings apply to this deployment only. Treat them as unverified for other chains. Why this deployment: Monero is its own proof-of-work chain, so the unit is Monero mainnet as defined by the reference node monerod at tag v0.18.5.3 (mainnet_hard_forks in src/hardforks/hardforks.cpp L34-L76; current fork v16 since height 2,689,608). CAIP-2 id from the registered monero namespace (ChainAgnostic/namespaces monero/caip2.md, mainnet genesis hash prefix). Excluded: stagenet, testnet, Wownero and other forks, exchanges and atomic-swap tools.

At a glance

Category: Protocols for privacy-preserving transfers
Chain: Monero mainnet
CROPS tally: 20 of 23 hold up · 1 no evidence
Security audits: 8 published
Offered: Everywhere
Last edited: 2026-10-13 · History

Censorship Resistance2 PartialWeakest: Admin pause or freeze powers; Settle without the provider; Neutral settlement, disclosed filtering; Token and chain freeze risks disclosed
Open No evidenceWeakest: Contracts verified onchain
Free2 PartialWeakest: No proprietary dependencies
Privacy2 PartialWeakest: Tracking and analytics; Third parties in the payment flow
Security1 WeakWeakest: Audits and bug bounty

Holds up 20

Not yet evidenced 1

No evidenceContracts verified onchain

Where it is offered

Offered everywhere, per the provider's code or documents. Checked 2026-10-09. Not scored.

The protocol has no country or address rules, and the official node, CLI and GUI wallets contain no country or IP-geolocation gate in GitHub code search on 2026-10-09. The GUI picks bootstrap nodes from the P2P network, not by region. Optional DNS lookups (MoneroPulse) and remote nodes chosen by the user are outside the protocol. Legality of use and exchange access vary by jurisdiction; that is not an availability restriction by the protocol.

Evidence (2)2 verified

Verified
The GUI starts the local node with bootstrap address auto and no location check; code search of monero-gui for country returns nothing.
monero-project/monero-gui · main.qml
commit d7c2f13d88 · checked 2026-10-09
Verified
Transaction validation has no address or country rule.
monero-project/monero · src/cryptonote_core/blockchain.cpp
commit 22578c3f7d · checked 2026-10-09

Censorship Resistance

Who can block valid use, and can users route around them?

2 PartialPillar rating: weakest of 5
5 of 5 Partial or better

What would raise this pillar

Admin pause or freeze powers reaching Strong: No pause, freeze, blacklist, or relayer/allowlist role that can stop settlement exists in the settlement contracts.
Settle without the provider reaching Strong: A payer or payee can complete settlement by calling the public contract directly, with the ABI and addresses documented.
Neutral settlement, disclosed filtering reaching Strong: Settlement contracts contain no address or geographic filtering, and any filtering in the SDK, frontend, or backend is disclosed in code or a versioned repo document, names its list source, and is bypassed by the direct settlement path (C2 at least 2). Requires every required component in the request path to be public, or a trace.
Token and chain freeze risks disclosed reaching Strong: Supported tokens and chains enumerated in code and docs, with issuer freeze/blacklist powers and sequencer or forced-inclusion assumptions stated to payees.

Admin pause or freeze powers

Can any privileged role stop, freeze, or block payments through the settlement contracts, and how is that role constrained? C1

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The consensus rules contain no admin key, pause, freeze, blacklist or allowlist role, and recipients are one-time addresses that a filter could not target. The core team runs the MoneroPulse DNS domains, which publish checkpoints; nodes look them up by default but only enforce them if the operator opts in. Rule changes need a hard fork that miners and node operators choose to run. Judgment call: the substance is anchor 3, but a 3 needs onchain evidence about a deployed contract, which a chain with no contract addresses cannot supply, so we take 2.

Evidence (2)2 verified

Verified
monerod fetches checkpoints from the MoneroPulse DNS domains (checkpoints.cpp L315-L338), but enforce-dns-checkpointing defaults to false and disable-dns-checkpoints turns the lookup off; enforcement is the operator's opt-in.
monero-project/monero · src/cryptonote_core/cryptonote_core.cpp
commit 22578c3f7d · checked 2026-10-09
Verified
Rule changes are hard forks compiled into releases at fixed heights; the last mainnet fork (v16) was at height 2,689,608 in August 2022.
monero-project/monero · src/hardforks/hardforks.cpp
commit 22578c3f7d · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Settle without the provider

Can a payer or payee complete settlement by calling the public contracts directly, without the provider's API, signer, or relayer? C2

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A payer signs a transaction in their own wallet and submits it to any Monero node; the payee detects it by scanning with their view key. No company, API or signer is in the path. Judgment call: this is direct settlement in substance, but anchor 3 is defined by calls to public contracts and needs onchain evidence about a deployed contract, which this chain has none of, so we take 2.

Evidence (1)1 verified

Verified
The node's send_raw_transaction RPC takes only the signed transaction hex (plus relay and sanity flags) and relays it to the P2P network; any monerod, the user's own or a remote one, accepts it.
monero-project/monero · src/rpc/core_rpc_server_commands_defs.h
commit 22578c3f7d · checked 2026-10-09

Reliance on hosted services

Does the payment flow require a relayer, paymaster, bundler, or API that only the provider runs? C3

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No relayer, paymaster or API is required. A user can run monerod and a wallet locally; light users can point the wallet at any remote node, and the GUI's simple mode picks one from public nodes advertised on the P2P network rather than from a vendor list. All node code is public.

Evidence (1)1 verified

Verified
With bootstrap-daemon-address set to auto (the GUI's simple modes, main.qml L792), monerod picks a public node advertised on the P2P network, so there is no vendor endpoint; the local node takes over once synced.
monero-project/monero · src/rpc/core_rpc_server.cpp
commit 22578c3f7d · checked 2026-10-09

Neutral settlement, disclosed filtering

Is the settlement layer free of address or geographic filtering, and is any filtering at the edge disclosed and avoidable? C4

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The settlement layer is neutral: consensus has no address or country rules, and recipients are unlinkable one-time addresses. We found no screening in the node, the CLI or the GUI. A remote node can refuse to relay, but the wallet can switch node or use its own. Judgment call: the substance fits 3, but 3 needs a distributed-package or trace record for the client, which we do not have, so we take 2.

Evidence (2)2 verified

Verified
Transaction validation checks ring sizes, key images and proofs; it has no address or country rule.
monero-project/monero · src/cryptonote_core/blockchain.cpp
commit 22578c3f7d · checked 2026-10-09
Verified
GitHub code search on 2026-10-09 for country, analytics and telemetry in monero-project/monero-gui returned nothing; in monero-project/monero, country matched only an old English mnemonic word list.
monero-project/monero-gui · main.qml
commit d7c2f13d88 · checked 2026-10-09

Token and chain freeze risks disclosed

Are the tokens and chains the rail depends on enumerated, with their issuers' freeze powers and sequencer assumptions stated to payees? C5

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The rail carries one asset, XMR, on one proof-of-work chain, so there is no issuer freeze and no sequencer to inherit. The upgrade schedule is published in the README. Neither the GUI nor the CLI states to payees that the chain depends on scheduled hard forks and miner adoption. Scored 2: enumerated in code, assumptions not stated.

Evidence (1)1 verified

Verified
The README's upgrade table lists every mainnet fork and states that upgrades are scheduled; the chain carries only XMR, with no issued tokens and no sequencer.
monero-project/monero · README.md
commit 22578c3f7d · checked 2026-10-09

Open

Is the whole stack visible?

No evidencePillar rating: weakest of 4
2 of 4 Partial or better · 1 no evidence

What would raise this pillar

Contracts verified onchain reaching Weak: Some contracts verified.

Contracts verified onchain

Does the deployed bytecode match public source, and can a third party rebuild it? O1

No evidence

Sets the pillar rating

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No checkable evidence settles this yet, so it counts as 0.

Not applicable as worded: Monero has no contracts, and its rules run in node software that each operator builds or downloads. The repo has reproducible-build tooling (contrib/guix), but we did not verify any release binary against source.

Whole stack published

Are the SDK, frontend, backend or API, indexer, and deploy scripts all public? O2

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Every layer of a payment is public: node, wallet library, CLI and GUI wallets, RPC servers and build scripts. Remote nodes run the same public code. Scored 3.

Evidence (1)1 verified

Verified
The monero repo at v0.18.5.3 contains the node (daemon, cryptonote_core, p2p, rpc), the wallet library and CLI (wallet, simplewallet), the wallet RPC server and reproducible-build scripts (contrib/guix); the GUI is in monero-project/monero-gui at v0.18.5.3 (d7c2f13d).
monero-project/monero · src
commit 22578c3f7d · checked 2026-10-09

Can be self-hosted

Can a stranger reach a working deployment from the README? O3

1 Weak

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Build and run documentation exists for the node and wallets. Reproduction not attempted, so the score is capped at 1.

Evidence (1)1 verified

Verified
The README documents dependencies and build steps for each platform and how to run monerod; the GUI README covers its build.
monero-project/monero · README.md
commit 22578c3f7d · checked 2026-10-09

Interfaces and data export

Are ABIs, event schemas, an API schema, and a payee data export in a non-proprietary format all in the repo? O4

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A payee can export transfers to CSV from the CLI, and the RPC request and response types are versioned in the repo. There are no contract ABIs. The RPC interface is defined as C++ serialization structs; the human-readable RPC reference lives on the website, not in the repo. Judgment call: the export would support 3, but we are not sure the C++ definitions count as an API schema equivalent to OpenAPI, so we take the lower anchor, 2.

Evidence (1)1 verified

Verified
The CLI's export_transfers command writes the wallet's transfer history to a CSV file (output<N>.csv by default); node RPC messages are defined in src/rpc/core_rpc_server_commands_defs.h and wallet RPC in src/wallet/wallet_rpc_server_commands_defs.h.
monero-project/monero · src/simplewallet/simplewallet.cpp
commit 22578c3f7d · checked 2026-10-09

Free

Does the license actually let a third party fork, modify, and run it?

2 PartialPillar rating: weakest of 3
3 of 3 Partial or better

What would raise this pillar

No proprietary dependencies reaching Strong: A production deployment needs no proprietary plugin or hosted-only service.

Open-source licences

Does every repository needed to run the product carry an OSI-approved license? F1

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Every repository needed to run the rail (node, wallet library, CLI and GUI) is BSD-3-Clause. The meta repository (process documents) has no licence file, but nothing needs it to run. It is not listed under repos because nothing runs from it.

Evidence (1)1 verified

Verified
monero, monero-gui and monero-site carry the BSD 3-clause licence; the meta repo (process documents) has no licence file and no running component needs it.
monero-project/monero · LICENSE
commit 22578c3f7d · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Protection against relicensing

Can the provider unilaterally relicense future versions, and has it committed not to? F2

3 Strong

Best evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

There is no CLA, copyright stays with each contributor, and the repo's contribution contract forbids copyright assignment, so no single party can relicense the code. No relicensing has happened. Judgment call: we read the no-assignment and share-alike rules as the written licence-stability commitment anchor 3 asks for.

Evidence (2)2 verified

Verified
The contribution contract says the project MUST use a share-alike licence, patches MUST use the project licence, patches are owned by their authors, and there MUST NOT be any copyright assignment process.
monero-project/monero · docs/CONTRIBUTING.md
commit 22578c3f7d · checked 2026-10-09
Verified
The LICENSE file's commit history since 2016 (14f75384) shows only copyright-year updates.
monero-project/monero · LICENSE
commit 22578c3f7d · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

No proprietary dependencies

Does a production deployment need a proprietary plugin or hosted-only service? F3

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

A production deployment needs no proprietary component: node and wallets are public and run on their own. The default DNS lookups are optional. Judgment call: the code supports 3, but with no O3 reproduction we take 2.

Evidence (1)1 verified

Verified
The only external services the node consults by default are the MoneroPulse DNS records (checkpoints, update notices), and both can be disabled by flag.
monero-project/monero · src/cryptonote_core/cryptonote_core.cpp
commit 22578c3f7d · checked 2026-10-09

Privacy

What can an observer learn, and did the user knowingly choose it?

2 PartialPillar rating: weakest of 5
5 of 5 Partial or better

What would raise this pillar

Tracking and analytics reaching Strong: None in SDK, widget, or frontend manifests and lockfiles, confirmed by trace.
Third parties in the payment flow reaching Strong: Only the configured RPC; no third-party indexer, risk-scoring, or pricing vendor in the critical path.

Tracking and analytics

Do the SDK, widget, or frontend ship analytics, telemetry, error reporting, or fingerprinting? P1

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

We found no analytics, telemetry or crash-reporting SDK in the node, CLI or GUI. The node's default update check is a DNS lookup, counted under P4. We ran no trace. Judgment call: absence shown only in code is capped at 2.

Evidence (1)1 verified

Verified
The GUI's persistent settings hold node addresses and display options and no analytics setting; code search of monero-gui for analytics and telemetry returned nothing, and in monero only a Trezor protobuf matched telemetry.
monero-project/monero-gui · main.qml
commit d7c2f13d88 · checked 2026-10-09

Data collected beyond payment

Does the flow collect anything beyond addresses, amounts, token, and chain? P2

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The flow collects only what settlement needs: a transaction whose outputs, amounts and optional encrypted payment ID are readable only by the recipient. No required component holds an account or identity. A remote node, if used, sees the user's IP and the transactions and outputs they request (see P4).

Evidence (1)1 verified

Verified
Submitting a payment sends only the signed transaction; no RPC on the payment path takes account, identity or contact fields.
monero-project/monero · src/rpc/core_rpc_server_commands_defs.h
commit 22578c3f7d · checked 2026-10-09

Payments linkable onchain

What do calldata and events reveal about who paid whom for what? P3

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

By default every payment goes to a one-time stealth address, hides the amount, and hides the spent output among 16 ring members. Fee, transaction size, input and output counts, timing and tx_extra contents are visible. The sender is hidden only probabilistically: decoy-selection and timing heuristics, and transactions that spend outputs created together, can narrow the ring; we record these in the finding and do not score them. Judgment call: we score what the protocol reveals by default, which is anchor 3.

Evidence (1)1 verified

Verified
From fork v15 every input must use a ring of 16 (15 decoys plus the real output) and all rings in a transaction must be the same size; amounts are hidden by RingCT with Bulletproofs+ (cryptonote_config.h HF_VERSION_BULLETPROOF_PLUS 15).
monero-project/monero · src/cryptonote_core/blockchain.cpp
commit 22578c3f7d · checked 2026-10-09

Third parties in the payment flow

Which third parties see a request during a payment, and can they be swapped out? P4

2 Partial

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

With a local node, only the user's DNS resolver (for MoneroPulse lookups) and P2P peers see anything. With a remote or bootstrap node, that node sees the user's IP, the transactions they submit and the outputs they request. Both are named in code and can be swapped or disabled by setting. Scored 2: third parties present, named in code, swappable.

Evidence (2)2 verified

Verified
check-updates defaults to notify (a DNS lookup of MoneroPulse records), and DNS checkpoints are looked up hourly unless disabled (L272-L280).
monero-project/monero · src/cryptonote_core/cryptonote_core.cpp
commit 22578c3f7d · checked 2026-10-09
Verified
In simple mode the wallet's requests go through a bootstrap public node until the local node syncs.
monero-project/monero · src/rpc/core_rpc_server.cpp
commit 22578c3f7d · checked 2026-10-09

Endpoints can be changed

Can RPC and indexer URLs be changed, and is the indexer code public? P5

3 Strong

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

The node endpoint, which is both RPC and indexer for a Monero wallet, is configurable in the GUI and CLI, and the node code is public.

Evidence (1)1 verified

Verified
The GUI stores a user-editable list of remote nodes (remoteNodesSerialized, edited in components/RemoteNodeEdit.qml) and a bootstrap node address; the CLI takes --daemon-address.
monero-project/monero-gui · main.qml
commit d7c2f13d88 · checked 2026-10-09

Security

Who can cause loss, lock users in, or change the rules?

1 WeakPillar rating: weakest of 6
5 of 6 Partial or better

What would raise this pillar

Audits and bug bounty reaching Partial: Audit pinned to a commit, resolutions not individually linked.

Who holds funds in transit

Who holds funds between payer and payee, and can the provider redirect them? S1

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Value moves directly from the payer's outputs to the payee's one-time outputs in one transaction; keys stay in the user's wallet. No one holds funds in flight. Judgment call: anchor 3 in substance, but 3 needs onchain evidence about a deployed contract, which this chain has none of, so we take 2.

Evidence (1)1 verified

Verified
A transaction spends the payer's outputs and creates one-time outputs only the payee's keys can spend; there is no escrow or intermediary account.
monero-project/monero · src/cryptonote_core/blockchain.cpp
commit 22578c3f7d · checked 2026-10-09

Who can upgrade the code

Who can change the contract code, and with how much notice? S2

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

No key can change the rules. Upgrades are hard forks compiled into node releases at fixed heights, announced in the README schedule ahead of time, and effective only if miners and node operators run them; the last one was in August 2022. The core team's MoneroPulse checkpoints are advisory unless an operator enforces them. Judgment call: notice is given by schedule but there is no enforced delay, and 3 would also need onchain evidence this chain cannot supply, so we take 2.

Evidence (1)1 verified

Verified
The README states that upgrades are scheduled hard forks whose software is released before the fork date, and tabulates every fork with its height and minimum version; the next fork is listed as undetermined.
monero-project/monero · README.md
commit 22578c3f7d · checked 2026-10-09

Token approval scope

How large an allowance does the SDK ask users to grant, and for how long? S3

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

There are no token approvals; each payment is a signed transaction and nothing can pull funds later. Judgment call: this beats exact-amount approvals in substance, but 3 needs a distributed-package or trace record for the client, so we take 2.

Evidence (1)1 verified

Verified
Wallets submit fully signed transactions; Monero has no allowance or delegated-spend mechanism.
monero-project/monero · src/rpc/core_rpc_server_commands_defs.h
commit 22578c3f7d · checked 2026-10-09

Funds safe if provider disappears Derived

If the provider disappears tomorrow, do payees keep their funds and the ability to keep settling? S4

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Derived from S1=2 (anchor 3 in substance), C2=2 (direct in substance), C3=3 and O3=1. Funds are outputs controlled by the user's keys (S1), any node accepts a payment (C2), and no hosted service is required (C3). There is no provider whose disappearance would stop the rail; if the project's maintainers stopped, the released code would keep running. We did not reproduce a self-hosted setup (O3=1). Judgment call: 2, not 3, for that reason.

Evidence (1)1 verified

Verified
Node discovery and bootstrap rely on the P2P network, not on a vendor service.
monero-project/monero · src/rpc/core_rpc_server.cpp
commit 22578c3f7d · checked 2026-10-09

Secrets and webhook handling

Are secrets kept out of client bundles and are webhooks signed and verified? S5

2 Partial

Best evidence: VerifiedChecked 2026-10-09 10 days ago

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Spend and view keys stay in the user's wallet file. The protocol has no API keys or webhooks, and we found no bundled service keys. Judgment call: absence shown only in code is capped at 2, since 3 needs a distributed-package or trace record.

Evidence (1)1 verified

Verified
Remote-node credentials in the GUI are per-node username and password entered by the user; no service keys are bundled.
monero-project/monero-gui · main.qml
commit d7c2f13d88 · checked 2026-10-09

Audits and bug bounty

Has the code been audited at a pinned commit, were findings fixed traceably, and is there a live bounty? S6

1 Weak

Sets the pillar ratingBest evidence: VerifiedChecked 2026-10-19 today

UnreviewedAssessed by AI research agent (seed), 2026-10-09

Audit reports exist for protocol components (CLSAG, Bulletproofs), and a bug bounty with scope is in a repo. We did not read the audit PDFs for a pinned commit, and the current release has not been shown to be the audited code. Scored 1: audit reports, no pinned commit shown.

Evidence (2)2 verified

Verified
The CLSAG audit report by JP Aumasson and Antony Vennard (2020) is in the website repo; research-lab/audits/BP holds Bulletproofs audit statements of work.
monero-project/monero-site · resources/research-lab/audits/clsag.pdf
commit 5a596d1933 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
A live bug bounty paid in XMR from community donations, with scope (code only, not live sites) and HackerOne intake, is defined in the meta repo; the monero README links it.
monero-project/meta · VULNERABILITY_RESPONSE_PROCESS.md
commit 97fb74b0bf · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

Security audits 8

Published audits and similar reviews of this provider's code, newest first. Context for the Audits and bug bounty rating, which scores them; this list does not change any rating, and an audit of older code says little about what is deployed now.

Date	Auditor	Type	Scope	Covers deployed code	Findings
2021-02-15	ZenGo X	Audit	Bulletproofs+ range proofs - review of the paper and of the C++ implementation for Monero. at `2d287f69b7` Hosted on the co-author's site and linked from Monero's CCS proposal. Bulletproofs+ became mandatory at the August 2022 hard fork; the audited branch was merged with later changes.	Partly	2 vulnerabilities (missing point-at-infinity check, missing zero-challenge check) and several weaknesses
2020-07-29	JP Aumasson and Antony Vennard	Audit	CLSAG ring signatures - review of the paper and of the C++ implementation (clsag-device branch), coordinated by OSTIF. at `66bcde2` CLSAG has been the consensus ring signature since the October 2020 hard fork; the audited code has been edited since in monero-project/monero.	Partly
2019-07-30	Quarkslab	Audit	RandomX proof-of-work (tag 1.0.4 and later commits), funded by the Monero community via OSTIF. at `5d815c57c0` The node vendors a later RandomX release. The RandomX README says none of the four 2019 audits found critical vulnerabilities.	Partly
2019-07-10	X41 D-Sec	Audit	RandomX proof-of-work algorithm and implementation.	Partly
2019-07-02	Kudelski Security	Audit	RandomX proof-of-work algorithm and implementation.	Partly
2019-05-28	Trail of Bits	Audit	RandomX proof-of-work at release 1.0.2, funded by Arweave. at `378d5de`	Partly	3 findings (single AES rounds in AesGenerator, insufficient VM testing, brittle parameters)
2018-10-20	Quarkslab	Audit	Bulletproofs implementation (bp-multi-aggregation branches) for Monero, via OSTIF. at `b7e61db030` Also reviewed 7f964dfc on bp-multi-aggregation. Original Bulletproofs were replaced by Bulletproofs+ in August 2022 and remain only to validate older transactions.	Partly	Major issues in proof verification (overflow, multi-exponentiation errors, missing input checks) and medium deserialization issues, fixed before deployment
2018-07	Kudelski Security	Audit	Bulletproofs integration in Monero (bp-multi-aggregation branch), via OSTIF. Hosted by OSTIF, which coordinated the audit. Same supersession as the Quarkslab Bulletproofs report.	Partly	3 low-severity issues and 7 observations; no major or critical issues

Compiled from: The monero-site repo (resources/research-lab/audits and blog posts on CLSAG, Bulletproofs and Bulletproofs+), the monero and meta repos, the CCS proposal pages for the Bulletproofs+ audits, the RandomX repo's audits folder (RandomX is the proof-of-work in the node, vendored as external/randomx), OSTIF's and Quarkslab's posts, and the Trail of Bits publications list. Not logged: JP Aumasson's second Bulletproofs+ audit (CCS milestone completed March 2021; no report link found), Cypher Stack's 2024 review of Zano's CLSAG variant, and the FCMP++ reviews and contest (including Trail of Bits' July 2026 FCMP++ crypto review), which cover an upgrade not yet activated. No audit of the current wallet or node release as a whole was found. Checked 2026-10-13. Only published reports are listed; private audits a provider mentions without a report are not.

Operational and procurement

Facts an institution's procurement, finance and security functions ask for. Separate from the CROPS ratings and never scored.

Group A: operational facts. Group B: 45 due-diligence controls derived from a UN agency's vendor requirements: 9 evidenced, 0 attested, 6 absent, 29 not applicable, 1 unknown. "Not applicable" means there is no operator to hold the control: it falls to whoever deploys the rail. How to read this.

Group A: operational facts

Fees

Evidenced

Component	Paid by	Amount	Basis
network	payer	Dynamic per-byte fee; sample 0.000491 XMR for a 1,535-byte transaction (block 3,780,260, 2026-10-09)	Consensus minimum since fork v15 is 0.95 x block_reward x 3000 / median_weight^2 per byte of weight; nodes reject fees more than 2% below it. Wallets pay a multiple by priority. Paid to the miner; changes need a hard fork.

There is no protocol, developer or provider fee; the only charge is the miner fee. The sample is one block on one day; the per-byte minimum moves with the block reward (tail emission 0.6 XMR) and the median block weight.

Verified
get_dynamic_base_fee (L3621-L3663) computes the per-byte minimum from the block reward, DYNAMIC_FEE_REFERENCE_TRANSACTION_WEIGHT (3000, cryptonote_config.h L75) and the long-term effective median from HF_VERSION_2021_SCALING (v15); check_fee (L3667-L3718) multiplies by transaction weight and rejects fees below 98% of it.
monero-project/monero · src/cryptonote_core/blockchain.cpp
commit 22578c3f7d · checked 2026-10-09
Verified
Block 3,780,260 (2026-10-09 12:10:24 UTC) holds two-output transactions of 1,532-1,539 bytes paying 490,240,000-492,480,000 piconero (about 0.00049 XMR, 320,000 piconero per byte). Read through a public explorer API; any monerod returns the same block.
xmrchain.net/api/block/3780260
block 3780260 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Custody model

Evidenced

Self-custody

Agrees with the S1 finding (anchor 3 in substance, capped at 2 only for want of contract evidence). Value moves from the payer's outputs to one-time outputs only the payee's keys can spend; nobody holds funds in flight.

Evidence shared with CROPS: S1 item 1

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Licences and registrations

N/A: falls to the institution

No operating entity runs the rail. Monero is a proof-of-work chain run by independent miners and node operators; the project has no company, and its Core Team and volunteers maintain software and escrow donations but do not transmit or hold users' funds.

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Cash-out options

N/A: falls to the institution

Native-asset rail. The payee receives XMR at its own address; converting XMR to local currency is outside the protocol and depends on exchanges whose availability varies by jurisdiction.

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

First deployment

Evidenced

2014-04-18 (block 1): Monero mainnet launch (block 1, first mined block; genesis has timestamp 0). The current format (ring 16, Bulletproofs+, view tags) dates from fork v15, 2022-08-13.

Judgment call. The first mined block is recorded because the genesis block carries no real timestamp.

Verified
Mainnet GENESIS_TX and GENESIS_NONCE (10000) compiled into monerod v0.18.5.3; hardforks.cpp L34-L36 starts fork version 1 at height 1.
monero-project/monero · src/cryptonote_config.h
commit 22578c3f7d · checked 2026-10-09
Verified
Block 1 (hash 771fbcd6...8148) has timestamp 1397818193, 2014-04-18 10:49:53 UTC. Block 0 (hash 418015bb...32e3, the CAIP-2 reference) has timestamp 0. Read through a public explorer API; any monerod returns the same headers.
xmrchain.net/api/block/1
block 1 · checked 2026-10-09

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Operating entity

Absent

Judgment call. Recorded as absent (no maintaining legal entity exists) rather than unknown. The Core Team, the Monero Research Lab and the vulnerability response team are informal groups; the security contacts in meta/VULNERABILITY_RESPONSE_PROCESS.md are individuals. Search of the website and docs repositories for company, corporation, legal entity and foundation found no entity.

Verified
The getmonero.org FAQ text states that Monero is an open source community project with no company that runs it and no CEO; contributors are volunteers or community-funded.
monero-project/monero-site · _i18n/en.yml
commit 5a596d1933 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
The Core Team describes itself as an informal group that escrows the Community Crowdfunding System and stewards the General Fund; no legal entity is named.
monero-project/monero-site · _posts/2019-12-03-core-team-general-fund.md
commit 5a596d1933 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Security incidents

Evidenced

2017-05-17: Disclosure of the CryptoNote key-image bug that allowed undetectable inflation. Found 2017-02-19, patched secretly in v0.10.2 and enforced by the April 2017 fork; the project scanned the chain and states Monero was never exploited. funds lost: no source
2018-09-05: Post-mortem of the multiple-counting bug in wallet transfer reporting (fixed in v0.12.3.0); exchanges using get_transfers could be credited several times over. An exchange was exploited through a Monero fork; losses on Monero itself are not stated. funds lost: unknown source
2018-09-25: Post-mortem of the burning bug. The wallet did not warn on outputs sent to a reused one-time address, so an attacker could leave a service with unspendable outputs; patched privately for exchanges, protocol and supply unaffected. funds lost: unknown source
2021-09-20: Post-mortem of two decoy-selection bugs in the reference wallet (v0.14.1.0 to v0.17.2.2) that weakened sender privacy; fixed in v0.17.2.3. funds lost: no source
2023-06-08: Post-mortem of the 10-block-old decoy selection bug (HIGH severity, wallets v0.13.0.2 to v0.18.2.1) revealing the real input of transactions spending outputs exactly 10 blocks old. funds lost: no source
2023-11-04: The Core Team reports the Community Crowdfunding System hot wallet was drained of 2,675.73 XMR on 2023-09-01, source not ascertained; the General Fund covered the loss. Project donation funds, not user funds or the protocol. funds lost: yes source
2025-08-26: Post-mortem of the find_and_save_rings() bug (wallets v0.12.0.0 to v0.18.4.1) that sent outgoing transaction ids to the daemon on first wallet load, reducing sender anonymity against an untrusted remote node; fixed in v0.18.4.2. funds lost: no source

Absence of a found incident is not evidence that none occurred.

Primary sources are the project's own post-mortems in monero-project/monero-site. The 2021-12 multisig vulnerability notice (experimental feature) and the 2016 MWR Labs statement are not listed. Privacy-loss incidents in the reference wallet are included because the rail's property is privacy; none moved funds.

Verified
Overview and timeline of the key-image bug, including the statement that the Monero blockchain had never been exploited.
monero-project/monero-site · _posts/2017-05-17-disclosure-of-a-major-bug-in-cryptonote-based-currencies.md
commit 5a596d1933 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
Core Team notice of the CCS wallet drain of 2,675.73 XMR on 2023-09-01 and the General Fund covering it.
monero-project/monero-site · _posts/2023-11-04-ccs-wallet-incident.md
commit 5a596d1933 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19
Verified
Quick facts of the find_and_save_rings() privacy bug (severity, affected versions, fix). The other post-mortems listed are in the same _posts directory at this commit.
monero-project/monero-site · _posts/2025-08-26-post-mortem-of-find-and-save-rings-bug.md
commit 5a596d1933 · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Product changes affecting users

Evidenced

2017-01-10: Fork v4 (height 1,220,516) allows RingCT transactions (hidden amounts). source
2018-10-18: Forks v8/v9 (heights 1,685,555 and 1,686,275) enable then require Bulletproofs and fix ring size at 11. source
2019-11-30: Fork v12 (height 1,978,433) switches proof of work to RandomX and requires at least two outputs. source
2020-10-17: Forks v13/v14 (heights 2,210,000 and 2,210,720) introduce the CLSAG signature format and forbid MLSAG. source
2022-08-13: Forks v15/v16 (heights 2,688,888 and 2,689,608) raise ring size to 16, add Bulletproofs+ and view tags, and change the dynamic fee and block-weight algorithm. No fork since; the next is listed as undetermined. source

Forks v2, v3, v5 to v7, v10 and v11 are omitted for brevity; they are in the same README table.

Verified
Scheduled software upgrades table with height, date, fork version and details for every mainnet fork; the next fork row is XXX (not determined).
monero-project/monero · README.md
commit 22578c3f7d · checked 2026-10-09
Verified
Mainnet fork heights compiled into monerod. Dates above are the activation-block timestamps read from xmrchain.net/api/block/<height>, which match the README dates.
monero-project/monero · src/hardforks/hardforks.cpp
commit 22578c3f7d · checked 2026-10-09 · source unchanged at weekly re-read 2026-10-19

UnreviewedAssessed by AI research agent (operational), 2026-10-09Checked 2026-10-09

Volume transacted (verified only)

Not observable

Ring signatures, stealth addresses and RingCT hide senders, recipients and amounts by design; only transaction counts and fees are public. Monero also has no contract address the volume script could query.

UnreviewedAssessed by AI research agent (operational), 2026-10-09

Group B: institutional due diligence

Control	State	What was found
Assurance and certifications
B1.1 ISO 27001, developer organisation Is the organisation that develops the product ISO 27001 certified, and does the certificate name that entity?	N/A: falls to the institution implied from the component list
B1.2 ISO 27001, hosting and support organisation Is the organisation that hosts and supports the service ISO 27001 certified in its own name, with a scope covering the service?	N/A: falls to the institution implied from the component list
B1.3 SOC 2 Type II or ISAE 3000/3402 reports Does the provider undergo periodic SOC 2 Type II or ISAE 3402 Type II assessments and make reports available?	N/A: falls to the institution implied from the component list
B1.4 Independent source-code security review before go-live Was the application reviewed by an independent party before launch, and is the report linked?	N/A: falls to the institution implied from the component list
B1.5 Penetration testing Is the service penetration-tested before go-live and at least every three years, with results available?	N/A: falls to the institution implied from the component list
B1.6 Vulnerability scanning cadence Are the platform and the application scanned for vulnerabilities at least every six months?	N/A: falls to the institution implied from the component list
Vulnerability and patch management
B2.1 Security contact and disclosure policy Is there a published way to report a vulnerability (SECURITY.md, security.txt, or a disclosure page)?	Absent	none of 3 repo(s): monero-project/monero ✗ no security policy file; monero-project/monero-gui ✗ no security policy file; monero-project/monero-site ✗ no security policy file source 1 · source 2 · source 3
B2.2 Patch service levels Does the provider commit to patch timelines for known vulnerabilities (the partner expects 30 days critical, 40 high, 90 medium)?	Evidenced	Vulnerability Response Process. Acknowledgement within 3 working days; HIGH and MEDIUM fixed in a point release, LOW in the next regular release; HIGH announced publicly within 3 working days of the patch release; the response team has 90 days to complete the process, after which the researcher may disclose. No fixed patch deadline per severity of the 30/40/90-day kind. The process covers code in the project's repositories, not the websites. It is run by volunteers. source 1
B2.3 Dependency and vulnerability scanning in CI Do the public repositories run dependency or code scanning automatically?	Absent	none of 3 repo(s): monero-project/monero ✗ no scanning config or workflow step found; monero-project/monero-gui ✗ no scanning config or workflow step found; monero-project/monero-site ✗ no scanning config or workflow step found source 1 · source 2 · source 3
Incident reporting and continuity
B3.1 Incident reporting commitment Does the provider commit to notify customers of security or data incidents within a stated time (the partner expects 24 hours)?	N/A: falls to the institution implied from the component list
B3.2 Backups and restore testing Are customer records backed up daily and restores tested on a schedule?	N/A: no such service implied from the component list
B3.3 Recovery plan Is there an approved and tested recovery plan for the service?	N/A: no such service implied from the component list
B3.4 Status page and post-mortems Does the provider publish service status and post-mortems for incidents?	N/A: falls to the institution implied from the component list
Identity and access (operator side)
B4.1 MFA for end users Can or must end users protect accounts with multi-factor authentication?	N/A: no such service implied from the component list
B4.2 MFA and separate accounts for privileged access Is privileged access protected by MFA and kept on separate accounts?	N/A: falls to the institution implied from the component list
B4.3 Periodic access reviews Are user access rights reviewed at least annually and privileged accounts at least six-monthly?	N/A: falls to the institution implied from the component list
B4.4 Segregation of duties and joiner-mover-leaver controls Is there a documented segregation-of-duties model and a joiner-mover-leaver process?	N/A: falls to the institution implied from the component list
B4.5 Session timeout Are idle interactive sessions terminated after a defined period (the partner expects 60 minutes)?	N/A: no such service implied from the component list
API and integration
B5.1 API authentication, browser to server Which standard (OAuth 2.0, OpenID Connect, SAML, JWT) protects browser-to-server API calls?	N/A: falls to the institution implied from the component list
B5.2 API authentication, server to server Are server-to-server calls authenticated with keys or PKI certificates, and are keys scoped and rotatable?	N/A: falls to the institution implied from the component list
B5.3 Token expiry Do API tokens expire, and within what period (the partner caps it at 120 minutes for public data, 30 otherwise)?	N/A: falls to the institution implied from the component list
B5.4 Export controls If an API exports data, does it limit volumes and log exports?	N/A: falls to the institution implied from the component list
Data protection and privacy governance
B6.1 Data classification and encryption Does the provider state a data classification and enforce encryption at rest and TLS 1.2 or better in transit?	N/A: falls to the institution implied from the component list
B6.2 Production data kept out of test environments Does the provider state that production or real personal data is not used in development and testing?	N/A: falls to the institution implied from the component list
B6.3 Data retention and deletion on termination What is retained, for how long, and is customer data removed on termination?	N/A: falls to the institution implied from the component list
B6.4 Data protection impact assessment and roles For systems holding personal data, has a DPIA been completed and are controller and processor defined?	N/A: falls to the institution implied from the component list
B6.5 Data processing or sharing agreement available Can a customer obtain a data processing agreement or equivalent?	N/A: falls to the institution implied from the component list
Logging and monitoring
B7.1 Audit logging Are account changes, logins and activity on important records logged and retained?	N/A: falls to the institution implied from the component list
B7.2 Central monitoring and endpoint detection Are logs sent to a managed SIEM and is endpoint detection running on all platforms?	N/A: falls to the institution implied from the component list
Hosting and network
B8.1 Hardened hosting Are hosts hardened to a recognised benchmark, with only essential ports open, IDS/IPS, a WAF for internet-facing applications and tenant isolation?	N/A: falls to the institution implied from the component list
B8.2 Deployment configuration and infrastructure as code Does the repository ship reproducible deployment configuration (containers, IaC, Helm) that a self-hoster can harden?	Evidenced	some of 3 repo(s): monero-project/monero ✓ deployment configuration: Dockerfile; monero-project/monero-gui ✓ deployment configuration: Dockerfile.android; monero-project/monero-site ✗ no deployment configuration source 1 · source 2 · source 3
Engineering practice in public repositories
B9.1 Default branch protected Does the default branch require reviews and passing checks, with no direct pushes?	Absent	none of 3 repo(s): monero-project/monero ✗ no branch rules visible (classic branch protection is not readable without push access); monero-project/monero-gui ✗ rules: deletion, non_fast_forward; monero-project/monero-site ✗ no branch rules visible (classic branch protection is not readable without push access) source 1 · source 2 · source 3
B9.2 CI runs on pull requests Does every pull request trigger automated checks?	Evidenced	all of 3 repo(s): monero-project/monero ✓ 3 workflow file(s); monero-project/monero-gui ✓ 3 workflow file(s); monero-project/monero-site ✓ 4 workflow file(s) source 1 · source 2 · source 3
B9.3 Tests run in CI Do the CI workflows run the test suite?	Absent	none of 3 repo(s): monero-project/monero ✗ test command in a workflow; monero-project/monero-gui ✗ test command in a workflow; monero-project/monero-site ✗ test command in a workflow source 1 · source 2 · source 3
B9.4 Coverage reported Is test coverage measured and reported (the partner expects 85%)?	Absent	none of 3 repo(s): monero-project/monero ✗ coverage tooling referenced; monero-project/monero-gui ✗ coverage tooling referenced; monero-project/monero-site ✗ coverage tooling referenced source 1 · source 2 · source 3
B9.5 Versioned releases Are releases tagged with immutable semantic versions?	Evidenced	some of 3 repo(s): monero-project/monero ✓ latest tags: v0.18.5.4, v0.18.5.3, v0.18.5.1; monero-project/monero-gui ✓ latest tags: v0.18.5.4, v0.18.5.3, v0.18.5.2; monero-project/monero-site ✗ latest tags: 2026-07-21, 2026-07-08, 2026-05-12 source 1 · source 2 · source 3
B9.6 Signed tags or commits Are release tags or recent commits cryptographically signed?	Evidenced	all of 3 repo(s): monero-project/monero ✓ 9 of 10 recent commits signed; monero-project/monero-gui ✓ 10 of 10 recent commits signed; monero-project/monero-site ✓ 9 of 10 recent commits signed source 1 · source 2 · source 3
B9.7 Changelog Is a changelog maintained with the code?	Evidenced	all of 3 repo(s): monero-project/monero ✓ 10 release(s) with notes; monero-project/monero-gui ✓ 10 release(s) with notes; monero-project/monero-site ✓ 7 release(s) with notes source 1 · source 2 · source 3
B9.8 Contribution and branching model documented Does the README or contribution guide state how changes are proposed, reviewed and released?	Evidenced	all of 3 repo(s): monero-project/monero ✓ CONTRIBUTING file; monero-project/monero-gui ✓ contribution section in README; monero-project/monero-site ✓ CONTRIBUTING file source 1 · source 2 · source 3
Architecture documentation
B10.1 Architecture documentation Is there a public architecture document covering logical, infrastructure and integration architecture and the components used?	Evidenced	Logical and integration views only. The docs describe the node/wallet split (monerod, wallet CLI, wallet RPC, GUI), their P2P, keyboard and JSON-RPC interfaces and the data directory; the RPC references and the Levin P2P protocol are documented separately. No single architecture document and no infrastructure view, as no operator-run infrastructure is required. source 1 · source 2
Commercial and financial
B11.1 Contracting entity Which legal entity would an institution contract with, and in which jurisdiction?	N/A: falls to the institution implied from the component list
B11.2 Funding of ongoing operation How is ongoing operation and maintenance funded (revenue, foundation, grants, fee switch), per a primary source?	Evidenced	Donations only. There is no protocol funding stream (the block reward, including tail emission, goes to miners). Development is paid through the Community Crowdfunding System and the General Fund, both escrowed by the Core Team; the bug bounty is paid from community donations. The 2023 CCS wallet drain (2,675.73 XMR) was covered from the General Fund (see incidents). No current treasury figure was read. source 1 · source 2
B11.3 Termination terms What happens to customer funds and data on termination by either side?	N/A: falls to the institution implied from the component list
AI components
B12.1 AI in the payment path Does an AI system take part in payment processing or compliance decisions (for example automated transaction screening)?	Absent	source 1 CROPS C4 · CROPS C4
B12.2 AI controls documented If AI is used, are monitoring, validation, override, decommissioning and bias evaluation documented?	Unknown implied from the component list

Scope of assessment

Components in the payment path

Component	Role	Public	Licence	Operator	Required
Monero mainnet consensus (proof-of-work miners and full nodes)	ledger	Yes	BSD-3-Clause	miners and node operators; rule changes ship as scheduled hard forks	Yes
monerod reference node (own node or a remote node run by someone else)	backend	Yes	BSD-3-Clause	user, or any public remote-node operator	Yes
wallet2 library and monero-wallet-cli (in the monero repo)	wallet	Yes	BSD-3-Clause	user	Yes
Monero GUI wallet	wallet	Yes	BSD-3-Clause	user	No
Public remote and bootstrap nodes (GUI simple mode picks one via P2P)	api	Yes	BSD-3-Clause	independent node operators	No
MoneroPulse DNS records (advisory checkpoints, update notices)	other	No	proprietary	Monero core team domains (moneropulse.se/.org/.net/.co)	No

Repositories

Repository	Role	License
monero-project/monero	backend	BSD-3-Clause
monero-project/monero-gui	frontend	BSD-3-Clause
monero-project/monero-site	docs	BSD-3-Clause

Contracts

None listed.

Assessor notes

Unit: Monero mainnet transfers. Pins: monero@22578c3f (v0.18.5.3), monero-gui@d7c2f13d (v0.18.5.3), meta@97fb74b0, monero-site@5a596d19. The chain has no contracts, so cells whose top anchor needs onchain contract evidence (C1, C2, S1, S2) are capped at 2 with the reason in each finding, and O1 is unknown. No transactions, node runs, builds, traces or self-host attempts were made. No primary legal source was cited: EUR-Lex refused automated requests (HTTP 202 challenge), so the EU AML Regulation's treatment of anonymity-enhancing coins is not recorded here.