Monero (XMR) Analysis

TL;DR: Monero is a privacy centered coin that uses novel cryptography to solve the fungibility challenges plaguing blockchain-based assets. In this piece, I explore the technical architecture underpinning the Monero protocol, core competencies/weaknesses of the project, governance mechanisms, and trade-offs against competing currencies. This research report is the primer of a multi-part series where I attempt to deep dive into notable cryptoasset projects from a non-biased perspective.


Monero (XMR) is a distributed ledger project touted as one of the world’s leading privacy-centric coins. The Monero project has carved out a deep niche in its respective community by placing heavy emphasis around being private, electronic cash. While the system itself utilizes the same UTXO structure as Bitcoin, it’s design shifts in the way these UTXO’s are packaged and broadcast to the network, utilizing one-time ring signature architecture, effectively creating an unlinkable transaction where an on looking third party cannot identify the output. The Monero protocol also utilizes a concept called stealth addressing, in which senders initiate transactions by producing a one-time public key visible only to the recipient. The recipient alone possesses the ability to recover the corresponding private part of the key to redeem the funds. By protecting both the sender’s and recipient’s transactional information, Monero possess many inherent strengths compared to the Bitcoin protocol and other leading digital currency systems due to its strong fungibility properties.


Public perception of Bitcoin as an anonymous payment scheme could not be further from the truth. By its very structure, Bitcoin is arguably the most translucent financial system civilization has ever seen. These features come with a set of tradeoffs, as Bitcoin’s extreme transparency is a double-edged sword. Many in the community are worried that it could eventually come at the demise of fungibility. As blockchain analytic programs become more adept, the lineage of transactions will become increasingly visible. If certain bitcoins in the ecosystem become labeled as “tainted” due to association with nefarious transactions somewhere in their lineage, merchants, vendors and exchanges will refuse to accept them due to legal recourse that could potentially ensue. This could lead to a market scenario where mispricing exists between equal denominations of the currency. If equal denominations of bitcoin do not possess equal intrinsic value, the system is no longer fungible.

The transparency of the Bitcoin blockchain makes it possible for an outside third party to conduct a full audit on any account and view the transactional history linked to that address. For corporations and organizations that rely heavily on financial privacy in their business dealings, this is not feasible. If the system loses fungibility, heavy indirect costs are placed upon both users and merchants. Unsuspecting individuals who receive a “tainted” coin are left bag holding a worthless currency that processors will refuse to accept. Merchants and exchanges incur high infrastructure costs to pre-audit incoming transactions. This not only incurs monetary fees but slows down the point-of-sale, reducing customer experience. Monero seeks to alleviate these concerns by making transparency an optional off-chain feature for transacting parties.


Monero traces its lineage back to the publication of the CryptoNote whitepaper. The CryptoNote v1 document claimed to be uploaded to a Tor Hidden Server in late December of 2012, published by a pseudonymous author under the name Nicolas van Saberhagen. The document was followed by a v2 release months later. However, it wasn’t until 2014 that these papers were “discovered” and emerged into the public spotlight, initiating controversy as to whether the authors lied about the publication timeline. Increased scrutiny developed after an investigation showed conflicting publication dates embedded in the PDF metadata. Around this same time, Bytecoin, the first implementation utilizing the CryptoNote protocols, was publicized. Like the CryptoNote authors, the Bytecoin developers remained pseudonymous, and little background regarding the historical origins of the currency existed. The Bytecoin team claimed the protocol had been live for nearly 2 years and had been adopted by numerous individuals across the deep web, yet no evidence of these claims could be supported. Many believed that the pseudonymous developers of the currency had some correlation to the CryptoNote developers, igniting controversy. Bitcoin talk user Thankful_For_Today forked the network roughly one month later, dubbing the new system Bitmonero, after discovering a secret pre-mine in the Bytecoin protocol where nearly 80% of the funds had already been distributed. Continued political and governance turmoil within the BitMonero ecosystem materialized with a tertiary fork only one week after, out of which the Monero protocol was born.


Block Construction:

Monero utilizes the standard UTXO model pioneered by Bitcoin, not a state-account configuration exhibited by alternative currencies such as Ethereum. Like Bitcoin, UTXOs exist in the blockchain and are encumbranced to a designated address when a user spends them. Transactions are bundled into blocks, but generation of Monero blocks is radically different than the traditional model implemented by Bitcoin. In contrast to Bitcoin’s 1MB hardcoded limit, Monero has an extremely dynamic structure with regards to its block ceiling, as well as the coinbase emissions allocated to the winning miner. Maximum block sizes can exist up to 2x the median block of the last n blocks (currently 100). The protocol also maintains a minimum block size configuration of 300 kB. This means miners can construct blocks up to 300 kB without infraction. If they choose to build a block above these parameters, a penalty is levied.

Penalty = BaseReward * ((BlockSize / MN) — 1)²


● MN is the median of the block size over the last N blocks (currently 100)

● BlockSize is the size of the current candidate block

● BaseReward is the current reward as per the emission curve, derived as follows:

BaseReward = 2 * ((S — A) * 2–20 * 10–12)


● S is the initial number of atomic units ( 264–1)

● A is the current circulation, converted to atomic units, which can be found here.

From an economic perspective, if the marginal benefit of adding an additional transaction to a fully diluted 300kb block does not outweigh the marginal cost, miners would simply refuse to add subsequent transactions. This could lead to significant congestion inside the mempool and a backlog in confirmation times during periods of high on-chain volume. Taking such variables into consideration, a default fee of 0.013XMR was configured to incentivize miners to include additional transactions in the event blocks were to become full. Envision the following theoretical situation:


● Average Transaction Size = 13.2kB

● Current BaseReward of 5.7 XMR

● Default Fee of 0.013XMR

Penalty = 5.7 * ((313.2/300)-1)² = ~0.011 XMR.

Since marginal benefit (0.013XMR miner’s fee) > marginal cost (0.011XMR block penalty) the miner would choose to include the transaction in the block.

In summary, the minimum limit, TX penalty and default fee work in tandem to ensure honest block size increases. The system disincentivizes a nefarious miner from DDOS’ing the network by initiating a flood of spam transactions while simultaneously mining them into an excessively large block.


Like Bitcoin, Monero follows a diminishing supply curve in which block rewards decay over time.

A key component that lies in stark contrast to many other cryptocurrency projects is Monero’s unbounded inflation. Once 18.132 Million XMR have been mined, a continuous “tail emission” will output 0.6XMR every two minutes (the average interval of a block solution). Monero believes an indefinite inflation schedule is necessary to provide an incentive for miners to contribute hash power, thereby securing the network.

Proof of Work Algorithm:

Monero utilizes the egalitarian CryptoNight hash function, a proof-of-work based, memory-hard consensus system in which the marginal benefit derived from specialized circuits (GPUs, FPGAs or ASICs) does not outweigh the marginal costs of integrating such hardware. Thus, Monero mining tends to be performed via traditional CPUs. The hash function works by filling a segment of cache with random data corresponding to memory addresses, then subsequently hashing the resulting block after reading and writing to those addresses. This differs from traditional SHA-256 mining in Bitcoin where the accessible data can be stored in L1 cache, and thus be accessed far quicker not having to fetch addresses from RAM or video RAM. Spreading the data across multiple secondary layer caches prevents specialized systems from obtaining a definitive advantage over traditional processors and is more analogous to the one-CPU-one-vote vision described by Satoshi Nakamoto in the Bitcoin whitepaper. Allowing anyone with a simple computer an equiprobable chance at discovering a block means hash rate consolidation is far less likely to become a detrimental threat. This keeps the protocol hedged from centralization and other attack vectors.

Additionally, high levels of centralization induce opportunity for government manipulation at the macro level. Legal patents and economies of scale could potentially lead to situations where only a handful of hardware manufacturers exist. This opens the door to censorship, where governments could shut down the companies’ production facilities, demand hidden backdoors, require licensing to operate or purchase hardware, censor transactions, or initiate temporary sales bans/quotas to distort hash rate equilibrium and damage the network. The Monero Core Team maintains a fierce standpoint that the protocol remains ASIC resistant, vocalizing their intention to curb any potential threats to egalitarian mining. This includes alterations to the Proof-of-Work schematic during scheduled network upgrades as a response mechanism to emergent ASIC hardware.

Stealth Addresses:

Monero utilizes stealth addresses to protect recipient privacy, a feature outlined in the CryptoNote whitepaper. Much like a hierarchical deterministic wallet, stealth addresses allow unique one-time destination addresses for outputs, preventing address reuse and thereby diminishing privacy. Unlike HD wallets though, stealth addresses push the burden of address creation on the sender. This allows the recipient to publish a single address and receive unconditional, anonymous payments to it.

Stealth addresses work slightly different than traditional Bitcoin addresses but are merged from the same underlying elliptical curve principles. Rather than generating a single EC keypair, the recipient will generate dual-EC keypairs in order to create a one-time key to receive payments. Let’s envision a theoretical scenario where Alice pays Bob. Bob begins by generating a dual public-private keypair {(a,A) where A=aG and (b,B) where B=bG)}. Bob concatenates (A,B) into a human friendly, error encoded format to create a standard address, which he publishes to the network. Alice unpacks Bob’s standard address to obtain his public keys (A,B). She then generates a random secret, r, and constructs a one-time public key by multiplying r and A. Alice then takes that value, multiplies it by a generator point G, and finally adds the value to B. She then hashes the result, which we call P.

P= [Hs (rA)]G + B

Alice then takes P and uses it as the destination for her UTXO. She computes the hash’s value R, where R=rG. She packs that R value into her message and broadcasts the transaction.

Subsequently, Bob’s wallet software is checking every transaction passing through the network with his private keys, and can recognize transactions destined to his address via mathematical computation done using (a,b). Once Bob recognizes an output encumbrance to him, he can recover the corresponding one-time private key and spend the funds at any point in the future by signing with x (the private key for above P).

Because knowledge of r is a necessary component in recovery of the one-time private key, Alice can provide verifiable proof she sent the payment either by publishing r, or using a zero-knowledge proof that she knows r.

Ring Signatures:

Sending Monero requires the user to spend some value of XMR associated with a one-time public key, P, as we discussed in the previous section. The sender must provide verifiable proof of ownership by signing a message spending that P with its corresponding private key, x. Up until this point, no one knows that Bob has received a payment from Alice (other than Alice of course). However, holding the funds indefinitely does not provide much utility to Bob. He also needs a way to spend these funds, without leaving a trail back to himself.

To maintain greater anonymity, Monero adopted one-time ring signature technology, proposed in the CryptoNote whitepaper. Ring signatures allot privacy by allowing the sender to join a group, then sign a transaction as a unit, rather than from a single private key. This technique allows the sender an avenue to “blend in” with the crowd. Verifying parties can prove that the output exists and that one of the parties in the group is an authentic signer. However, they cannot determine which of the group members that signer is, as each member holds an equiprobable weight. As the group size increases, the probability of each member being the authentic signer decreases.

A ring signature involves aggregating the user’s authentic P, along with a plethora of “dummy” P’s scattered across the blockchain. The signature is verified by all the Ps, and mathematically any of the corresponding private keys could have signed the transaction, thus obfuscating identity of the authentic sender.

To prevent double-spend attacks, a key image I is created during the construction of a ring. The image is created by taking a hash of P, and multiplying it by the private key x. The mathematical relationship makes it impossible for the signer to try and make two signatures with different I’s and the same x. This mechanism ensures that each P can only be spent once, new XMR cannot be created out of thin air. The Monero network maintains a database of all outstanding key images, so if a user tries to reuse a key, the network will see the output as expended, and reject the transaction.

Ring CT:

With the combination of stealth addresses and ring signatures, both sender and recipient privacy are protected. However, the CryptoNote whitepaper has no implementation that effectively shields the value transfer amounts. If Alice pays Bob 5XMR, and Bob subsequently pays Bruce, Alice could piecemeal segments of the transaction chain by following the commitment values.

Ring Confidential Transactions (Ring CT) is a measure implemented by the Monero protocol which makes transaction values opaque to anyone outside the sending and recipient parties. The protocol accomplishes this by having the sender encrypt the values using a shared secret between the transacting parties. The recipient is then able to decrypt the value using a combination of their private view key, along with the transaction public key.

Third parties are still able to verify the integrity of the values and ensure that new XMR weren’t created out of thin air, without even needing to see the value amounts. This is achieved through cryptographical schemes called Pedersen commitments.

Commitment Inputs — (Transaction Fees + Commitment Outputs) = 0

A simple illustration can provide a basic overview of the mathematical properties involved:

1+2+3+4 = 5+5

If we want the values to remain confidential, we encrypt them, multiplying each by some generator point x, getting:

1x + 2x +3x +4x = 5x + 5x


x(1+2+3+4) = x(5+5)

Without knowing x, verifiers get obfuscated values, but can ensure the input commitments match the outputs (plus transaction fees). The only ones who can see the actual values are the recipient and sender, who know x.

Additionally, Ring CT requires the implementation of range proofs. Almost like a zero-knowledge proof, range proofs ensure that the commitment values fall within a parameter range (greater than 0), without ever exposing the integers themselves. This is necessary to prevent someone starting with 1XMR from creating two separate outputs of -5XMR and 6XMR, thereby creating XMR out of thin air.

Forward Implementations


Kovri is a C++ implementation project that would make Monero compatible with the Invisible Internet Project (I2P). Much like The Tor Project, I2P is a network layer that provides users privacy and anonymity when browsing the web. The architecture consists of nodes that pass end-to-end encrypted data throughout the network, all performed on a volunteer basis. I2P has a fundamentally different composition than Tor, providing different objectives. Tor’s uses circuit-based routing to enable private access to the public internet. It does this by breaking the link from where the request originated, and where it was ultimately delivered. Tor also features hidden services, servers that hold content which can only be accessed within the Tor network itself, and not via the public internet. However, this is more of an auxiliary service.

Simplistically, I2P looks to build a network completely independent from the traditional web where the majority of traffic stays within its borders (think of a network composed purely of Tor hidden services). Unlike Tor, which uses a circuit-based routing standard, I2P uses packet-based routing, analogous to the TCP/IP protocol. This provides higher degrees of reliability due to the protocol’s ability to route around congestion and network disruption.

Currently, one of the few pieces of software that facilitate interaction with these I2P network layers (referred to as a router) is written in Java. This current I2P daemon is quite incompatible with Monero, due to its bloat and difficult integration. Kovri is an alternative implementation written in C++, making it more complementary with Monero’s code. Kovri is a full I2P router, meaning it can be used for other applications than just Monero. This will help increase the strength and utility of the I2P network overall.

Embedding native access to the I2P network within Monero is a positive development with regards to privacy, since it will hide the user’s IP address. The Monero blockchain itself does not store IP addresses in blocks, but because synching a full node consumes a lot of storage, bandwidth and time, many choose to bootstrap their client to a remote node (a node controlled by someone other than yourself) to synch the blockchain. The owner of that remote node may be logging IP addresses of users and could see which TXIDs originated from specific users. Luckily, the operator cannot see what inputs in the ring signature are real and which are decoys, the amount sent, or what address these outputs are encumbranced to. However, if the node operator is nefarious, permanently sniffing your connection, or runs a massive number of nodes, they could potentially accumulate a great deal of information about user transactions and piecemeal information together. By obfuscating user IP addresses over I2P, Kovri highly mitigates the possibility of such attacks.


As we mentioned previously, Monero uses range proofs to ensure that commitment outputs are positive integers, without revealing the underlying value of the outputs themselves. This method prevents users from creating new XMR out of thin air. However, these range proofs come at a cost to efficiency. Range proofs scale linearly with respect to the number of outputs in a transaction, meaning multiple-output transactions must contain a corresponding amount of proofs. Range proofs make up a significant majority of the transaction size and are the precise reason why XMR transactions are so much larger, and thereby costlier, than their crypto-counterparts.

Fortunately, a recent breakthrough called bulletproofs has found a way to significantly decrease the size of these range proofs. With bulletproofs, outputs scale logarithmically rather than linearly:

Current Range Proofs: 1 output = 7kB, 2 outputs = 13kB…

Bulletproofs: 1 output = 2kB, 2 outputs = 2.5kB…

A standard XMR transaction involves 2 outputs, one destined to the recipient, the other back to the sender in the form of change. Using current range proofs, this amounts to roughly a 13.2kB transaction. Using single-output bulletproofs, the size of the transaction is reduced to 2.5kB, a cost reduction of nearly 80%. The implementation of multiple-output bulletproofs will induce even higher savings.

The development team anticipates bulletproof deployment in a single stage during the upcoming September hard fork. Reduction to transaction size will lead to congruent savings in transaction fees, and on verification times as well. Overall, bulletproofs will have a robust impact on the efficiency and functionality of the Monero network.

Scheduled Hard Forks:

Hard forks in a distributed ledger system tend to be contentious. Conflict usually emerges between two or more factions within a community, growing to the point where one splits off and creates a completely independent protocol. However, not all forks have to be bad. Sometimes hard forks occur when a network implementation needs to be pushed, but no backwards-compatible coordination is possible.

Monero schedules predetermined hard forks every six months as pitstops to implement new technology or advance existing architecture. These forks are historically uncontentious and are more analogous to scheduled upgrades. Examples of notable technology implemented during these forks included Ring CT, multisig, and soon-to-be-released bulletproofs.

Scheduled upgrades to the Monero protocol have been highly successful, partly due to the infancy of the system. The community is a small grassroots organization that is very close knit. Consensus seems to be reached with very little disagreement, partly due to the alignment of incentives and complementary vision among group members. As the community continues to grow and adoption becomes more wide-spread, consensus may become problematic as fragmentation occurs.



There is one definitive factor that has emerged in the crypto-ecosystem since the release of the Bitcoin whitepaper in 2008: Blockchains do not scale well. Monero is no exception to this principle.

Like every other protocol system, tradeoffs of certain characteristics must be relinquished to obtain alternatives. As a privacy centric coin, Monero puts transactional anonymity at the top of the list. Doing so comes at a great cost to transactional efficiency. Monero transactions sizes are some of the largest in all the crypto-ecosystem. At current levels, a two-output transaction (one output to recipient, one output as change back to sender) is roughly 30x the size of an average Bitcoin transaction. While new algorithms such as bulletproofs are anticipated to significantly increase savings, these efficiencies may be offset with privacy improvements (ie: increasing standard ring sizes to 100+ members). XMR has some of the most expensive network fees, despite transactional volume only amounting to 3,000–5,000 TX per day. If adoption continues to increase, this could pose serious challenges.

Many of the XMR Core Team members have illustrated the need for off chain scaling to become a viable P2P cash system. However due to the infancy stages of the protocol, most of the work is being done to improve efficiencies on-chain. Very few efforts have been allocated to sidechain/lightening payment channels, showing that the currency still has a way to go before reaching a dynamic threshold.


Decentralized systems have garnered attraction over the past decade due to the individual sovereignty natively imbedded into their protocols. Voluntarism and immutability are core principles that make these systems so powerful. However, they often come at a tradeoff to consensus and innovation.

Monero lacks any hard governance structure or hierarchical leadership. The “highest” degree of power lies in the hands of the Core Development Team. Responsibilities that fall under their jurisdiction include the following:

● Act as primary trusted arbiters of the Forum Funding System on behalf of the community, so as to ensure the completion of all projects to the satisfaction of the community.

● Manage the codebase of the Monero Project, which includes merging code on Github, keeping backups, and ensuring the safety, security, and free access of the code from any party.

● Steward the general donation fund and spending the Monero there on anything they see fit to further the Monero Project.

● Act as trusted signers and distributors of reference clients for the Monero coin, and other related technologies.

● Set a direction and vision for the Monero Project

The development team simultaneously outlines principles that they are not obligated towards:

● Members of the Core Team are NOT anyone’s boss, and no permission is needed from them to do anything.

● The Core Team does NOT act as a centralized point of failure, but encourages organic, self-started initiatives that further the ecosystem of Monero.

● The Core Team does NOT equal Monero. In the event that one, or all of the Core Team goes rogue, we are to remember that Monero is a movement. A global initiative to further privacy globally, and provide real, fungible, digital money for everyone. This can happen even without the presence of the Core Team.

Merging coordinated action and individual sovereignty is no easy process. Attracting strong talent and producing innovative technology has not been the challenge for distributed systems over the years. Finding a way to reach simultaneous consensus on how to implement features has been. Different outlooks and visions for the protocol may result in factions within the community, like we’ve seen happen in Bitcoin. With no intrinsic hierarchy in the governance system to make difficult decisions, progress and innovation could potentially slow due to internal conflict.

Early signs of fragmentation have begun to emerge, catalyzed by the recent (and somewhat controversial) network hard-fork that went into effect April 6th. The fork has two primary components: increase the minimum ring size to 7 signatures, and alter the underlying CryptoNight hash function. The latter was a decision initiated by the Core Team in direct response to the release of the Antminer X3 ASIC rigs. Some community members feel that the move lacks definitive consensus, and paradoxically illustrates centralization concerns, as a small group of developers have the ability to radically transform the structure of the network at whim. However, the decision should come as no surprise and comes in conjunction with the majority of community agreement. The Core Team has consistently iterated egalitarian mining as a fundamental pillar to the protocol, and has outlined a fervent vision to preserve such features. Some members disagree that the team has the ability to outline such a direction, due to the complex economic/political implications of the decisions. Proponents are already launching a forked coin, Monero Classic, which removes the consensus algorithm alteration. The biggest takeaway we can generate from this event is that Monero’s fervent claims to remain ASIC resistant are extremely sincere. They are not afraid to wage war against hardware manufacturers, so expect a cat-and-mouse game of protocol alterations as each side counters.

Capital Financing:

Monero utilizes a unique crowdfunding approach called the Forum Funding System to finance projects. The entire system operates on a donation and is purely meritocratic based. Ideas are introduced across an idea thread, with developers proposing outlined solutions to achieve these objectives. If deemed relevant and obtains community approval, that person/campaign will receive capital pledges from community members to pursue their project. These funds are locked in escrow, and milestone requirements must be hit to receive payout. This safeguard mechanism aligns incentives for both the donors and recipients and ensures protection of the funds from theft or mismanagement.

Funding open-sourced applications has been historically challenging. Many in the Monero community have expressed discontent toward the outrageous sums of capital crowdsourced by alternative protocols in the form of ICO’s and token sales. Similar distrust for distributed currency systems that allocate a percentage of block rewards to the foundational team have been noted. By utilizing the FFS structure, the Monero community wants to foster an ecosystem of character and stewardship that properly aligned incentives across the community.

Relying on a system of donations fundamentally relies on the generosity of the community. Right now, the FFS has been very effective not just raising capital but allocating that capital to projects that have produced highly beneficial content. The grassroots environment fostered in the Monero network is very strong, and donations have been quite prevalent. However, as the community grows, factions could be introduced that split and divide the community, creating problems for consensus. This could detract from the community ethos and impact the generosity of its members in a negative way. Furthermore, at a certain scale, the FFS could suffer from the tragedy of the commons, where common users freeride off the minority development efforts of a few individuals. Average users have little incentive to donate since no tangible efforts of their donations come to fruition in a climatic manner. This free-rider problem could ultimately manifest with the concentrated developers becoming overburdened and upset, walking away from the project altogether.


While Monero provides a degree of anonymity much higher than most cryptocurrencies, no system is perfect. Some attack vectors still exist. Below are examples of notable concerns:

EAE Attack- This involves a transmission of funds from an exchange to Alice, then back to the exchange at a later interval. The exchange, which stores various KYC/AML information, would possess knowledge of Alice’s one-time ring signature. If any ring signatures appear referencing the UTXO Alice received from the exchange, then the exchange will know Alice is one of the possible spenders.

Key Image Reuse- This form of attack is likely to materialize from a fork in the network where private keys from the legacy chain are reused on the new chain (let’s call this network MoneroB). The same key image for rings now exists simultaneously on both forks.

Alice sends XMR to a new legacy wallet, using decoy inputs 1,2,3,4,5 and her authentic input 6. Similarly, she sends money to a new address on MoneroB, constructing a ring with authentic input 6 and decoy inputs 7,8,9,10,11. A third party can analyze the two chains and come to a conclusion that input 6 is the authentic commitment since it exists in both rings. A major problem in this scenario is that Alice’s input 6 is being used as a decoy for a ring constructed by someone else (call him Bob). Bob’s ring consists of decoys 6,12,13,14,15 with authentic input 16. The third party onlooker can now conclude that 6 is a decoy (since they already figured out that it belongs to Alice), reducing the ambiguity factor of the ring by one. By aggregating enough information, the onlooker can fill in many pieces of the puzzle, greatly reducing the security of the ring by removing plausibility of the authentic signer.

This scenario is near impossible to defend against, as any individual possesses the ability to fork the network at any time. If the fork is designed as an attack vector to undermine the legacy chain’s security, the attacker has economic incentives at their advantage. Uneducated users or users who value privacy in little regard are likely to claim their “free money” airdrops on the new chain. Even worse, if the attacker is a deep pocketed organization like a government or large corporation, they could purchase large buy orders on exchanges, artificially increasing price of the asset short term. This would entice users even further to claim their airdrops, compromising integrity of the main chain in the process.

The problem with this situation is tradeoffs are not restricted to the individual user, but rather amortized across the network as a whole. Users who refuse to claim their airdropped coins in an effort to maintain chain integrity are still subject to the negative externalities of those that do. This could potentially lead to an entirely new Byzantine fault problem the network would need to account for.

Ring Sizes- Tying in closely to the above scenarios, low ring sizes increase the probability of an onlooker determining the authentic input inside a ring. Fees scale in response to larger rings, so an underlying incentive exists for users to deploy smaller rings, especially those with “nothing to hide”. In scenarios where an attacker can probabilistically eliminate some decoys, smaller rings only make their job easier.


A compelling argument can be made that over the long run, cryptocurrency systems will exhibit network effects that lie in tandem with Metcalfe’s law, leading to a winner-take-most end scenario. This is thought to be especially true for privacy-centric coins, due to the necessary properties of high liquidity and large user bases to prove functional. Even if the protocol possess strong cryptographic shielding properties, if the network maintain few participants and offers low liquidity, salient points of attack will manifest at the off-chain level (e.g. an exchange endpoint), thereby eroding user privacy. Thus for a privacy-centric network to become truly secure, it must become a de-facto protocol inside its niche. This is most likely to be accomplished through a combination of two elements: early mover advantage and strong utility.

At such a transition point, the network accrues monopolistic advantages over competition. Given that the asset is scarce, an increase in demand combined with [near] fixed supply will lead to a rise in the asset price. This will incentivize miners to migrate to the network due to heightened block rewards, increasing hash rate and contributing to the underlying network security. As the community expands, competent developers will crossover, leading to a more resilient and secure code base. These positive reinforcement mechanisms lead to an economic moat over competition, where small players have an increasingly complex time dethroning the incumbents. Also, currency networks tend to exhibit “sticky” properties due to high transition costs. Networks have the ability to fork, so incumbents can simply steal their competitor’s technology once it has proven to be resilient, leaving little incentive for users to migrate. Implementing new technology to the protocol is easy, generating an initial framework of users is difficult.

At current standards, Monero really only faces significant competition from a single alternative coin: Zcash. Like Monero, Zcash has built a value proposition based off strong degrees of privacy and fungibility. While both protocols seek to achieve the same objectives, each uses novel forms of cryptography to accomplish their aims. Monero deploys encryption schemes which protect sensitive data that exists inside the metadata of a transaction. If this data were to be decrypted, it would leak critical information that would compromise the user’s privacy. Conversely, Zcash routes around the dilemma by removing it from transaction data altogether. Zcash accomplishes this via a novel form of zero-knowledge proofs known as zkSNARKs. ZkSNARKs allow the sender to mathematically prove ownership of the asset without conveying any information in the transaction apart from the fact that they possess knowledge of the sensitive data.

Distinctions between Monero and Zcash appear in many different aspects. The most glaring has to do with cryptography schemes. Theoretically, zkSNARKs can offer higher degrees of security than Monero’s encryption based transactions. However, this does not necessarily mean their protocol is more secure, as attack vectors exist in multiple departments. Zcash offers the ability to initiate a shielded or transparent transaction. Less than 1/3 of transactions are shielded, partially due to the disincentives as they incur higher fees and longer propagation times. Low adoption rates open potential doors for analytical snooping on transactions as they pass in and out of different addresses. This revokes user sovereignty, as security becomes reliant on other users actions to a certain degree. In Monero, privacy is a mandated feature, preventing such drawbacks.

Governance is another stark contrast. Monero exhibits a highly distributed, grassroots-style organizational structure. No hierarchical leadership exists, and alterations to the protocols occur on a fairly consensual basis. Protocol development and research is aggregated across a wide set of contributors. Zcash displays a much more centralized governance structure where power is severely concentrated (at least for the time being). The Zcash Company consists of a highly accredited team of scientists, researchers and developers who drive technological advancements and innovations to the underlying Zcash protocol. Community members then have the ability to opt into these network alterations on their own accord.

Tradeoffs that exist between the two coins can be vaguely summarized by differences involving technological innovation and community governance. Monero offers higher on-chain privacy features in the short run due to its default anonymity settings, larger user base and tried encryption. In the long run, Zcash signals compelling evidence to offer better privacy due to zkSNARKS, increasing shielded transaction adoption rates, and qualified engineering talent. However, Zcash allocates less autonomy to its user base, stemming from its effective monopoly over protocol alterations, combined with its Founders Reward tax on 10% of mined coins. Each protocol provides a unique value proposition that attracts users with different objectives.


With relay, sender, recipient and transactional information all privatized, the level of anonymity provided by the Monero protocol is exceptionally high, positioning it as one of the world’s leading privacy coins. Innovation by Monero Research Labs into Ring CT, KOVRI, and Bulletproofs has illustrated the organization’s competent developers and strong dedication to community necessary for any project to succeed. While researchers argue that novel cryptography in competing systems such as Zcash may overshadow key Monero protocols in the long run, tradeoffs always exist. Raw cryptography is not the standalone decisive factor. Governance, adoption rates, incentives, and capital must all align to create a sustainable ecosystem. Taking into consideration all the different dynamics in the ecosystem at the present, I believe the Monero project has positioned itself as the frontrunner coin in the battle for privacy.

Disclaimer: The author holds a long position in XMR

Special thanks to Justin Ehrenhofer, Pietro Moran, Myles Snider and Derek Hsue for feedback on this piece!