Both hide amounts the same way: every output is a Pedersen commitment with a range proof, so observers cannot read the value or forge a negative one. The difference is everything else. Monero adds ring signatures and mandatory stealth addresses. Tari's Mimblewimble base layer has no addresses, relies on aggregation and cut-through, and adds one-sided payments with stealth addresses.
Last refreshed September 9, 2026
| Coverage scope | Answer family | Privacy | |
|---|---|---|---|
| Stable fields | commitment and range proof construction, RingCT mandatory date, Mimblewimble absence of addresses, aggregation and cut-through, Tari RFC statuses | Dynamic fields | Monero protocol upgrades to ring size or signature scheme, Tari RFC revisions |
On amounts, they are the same trick. Both schemes replace a visible value with a Pedersen commitment and attach a range proof showing the hidden value is non-negative and within bounds. Tari's Mimblewimble base layer mandates this for every output. Monero's RingCT has been mandatory for every transaction since September 2017.
The difference is what else gets hidden. Monero layers two more mechanisms on top: ring signatures so an observer cannot tell which output was spent, and stealth addresses so only sender and receiver know where a payment went. Mimblewimble has no addresses at all and instead lets transactions be merged and cut through, removing much of the transaction graph.
Tari is Mimblewimble plus two additions. Tari's base layer uses Bulletproofs+ range proofs and adds TariScript one-sided payments with stealth addresses, so a recipient no longer has to be online to build the transaction and one-sided outputs are not trivially scannable.
The amount-hiding layer is shared. Everything above it differs.
| Mimblewimble (Tari) | RingCT (Monero) | |
|---|---|---|
| Amounts | Hidden by Pedersen commitment plus Bulletproofs+ range proof, on every output | Hidden by Pedersen commitment plus Bulletproofs range proof, mandatory since September 2017 |
| Sender | No per-transaction mechanism; aggregation and cut-through blur the graph | Ring signature: observer cannot tell which group member signed |
| Receiver | No addresses in classic form; Tari adds stealth addresses for one-sided payments | Mandatory one-time stealth address per transaction |
| Transaction graph | Compacted; spent outputs can be cut through | Fully retained; obscured by decoys rather than removed |
| Recipient participation | Required in classic Mimblewimble; optional on Tari via one-sided payments | Not required |
| Scripting | None in classic Mimblewimble; Tari adds TariScript | None |
Two philosophies for the same goal. Monero hides the sender by surrounding the real input with decoys and keeps every transaction on chain. Mimblewimble removes structure instead: merged and cut-through transactions leave less graph to analyse in the first place. The Mimblewimble paper describes the privacy gain as an enormous boon amplified by confidential transactions, provided the original component transactions are not published.
That proviso is the whole caveat. Cut-through helps against someone reading the chain later. It does not help against someone watching transactions arrive on the network before they are merged.
Neither guarantees sender or receiver anonymity under every threat model. Ring signatures give plausible deniability among a group, not proof of non-involvement. Mimblewimble's graph privacy depends on transactions being aggregated before the originals are observed.
Tari's own RFC states a linkability limit. RFC-0203 notes that while one-time addresses are not algebraically linkable, a transaction that consumes several such outputs lets an observer infer they share an owner.
Amount hiding does not hide that a transaction happened. Both chains still show that outputs were created and spent. What an observer cannot read is the value, and on Monero, which specific input was spent.
Confidential is not the same as untraceable. Network-level observation, exchange records and user behaviour sit outside what either protocol addresses.
| Amount hiding, Tari | Pedersen commitments with Bulletproofs+ range proofs, every output |
|---|---|
| Amount hiding, Monero | Pedersen commitments with Bulletproofs range proofs, mandatory since September 2017 |
| Tari range proof bounds | Zero to 2^64 microTari per output |
| Addresses in classic Mimblewimble | None |
| Tari stealth addresses | RFC-0203, Implemented, for one-sided payments |
| Monero stealth addresses | Required for every transaction |
| Monero Bulletproofs deployed | October 2018 |
Do Tari and Monero hide amounts equally well?
Yes, on amounts. Both replace the visible value with a Pedersen commitment and attach a range proof. Tari's Mimblewimble base layer mandates it for every output; RingCT has been mandatory on Monero since September 2017. The designs diverge on sender and receiver privacy, not on amounts.
If Mimblewimble has no addresses, how do you receive Tari?
Classic Mimblewimble has no addresses; the recipient creates keys on the fly and takes part in building the transaction. Tari adds TariScript one-sided payments so a sender can pay an offline recipient, and RFC-0203 stealth addresses so those outputs cannot be trivially scanned for.
Which one hides the sender better, Tari or Monero?
Monero surrounds the real spent output with decoys in a ring signature, so the network cannot tell which output was spent. Tari's Mimblewimble has no equivalent per-transaction mechanism; it relies on transactions being merged and cut through so there is less graph to trace.
What is a range proof and why does Tari's Bulletproofs+ matter?
A range proof shows a hidden amount lies within a valid range, which stops negative outputs from creating coins out of nothing. Tari uses Bulletproofs+, which extends the Bulletproofs system Monero deployed in October 2018 with aggregated proofs and batch verification.
Does cut-through make Tari transactions untraceable?
No. Cut-through compacts the chain's history so a later reader sees less structure. It does nothing about an observer who watches transactions arrive on the network before they are aggregated, which the Mimblewimble paper itself flags as the condition for the privacy gain.