Search the word Equihash and an ASIC vendor holds 2 of the top ten results, at positions 1 and 6, with a shopping panel for the same seller alongside them. The rest of the page is mining calculators and mining software.
The results page for an algorithm designed to blunt the advantage of purpose-built hardware is a hardware shop. That is not an argument about anything, and it is a useful place to start.
what follows covers what Equihash is and what its designers claimed for it. Our guide to How Zcash mining works covers Zcash mining, and our guide to Mine Zcash profitably covers whether mining pays.
What Equihash actually is
Equihash originates in an academic paper by Alex Biryukov and Dmitry Khovratovich, titled "Equihash: Asymmetric Proof-of-Work Based on the Generalized Birthday Problem" and archived in 2015 (source: Cryptology ePrint Archive). The Zcash protocol specification names both of them as its designers, which is unusual: most chains do not attribute their proof-of-work scheme to anybody.
The underlying problem is a variation of the generalized birthday problem, which the specification states directly: given a long sequence of bit strings, find a specific number of distinct ones that combine to zero.
Two integers define an instance, written n and k. The specification pins both at 200 and 9 respectively, for the live network and the test network alike (source: Zcash protocol specification). Between them those integers decide how much memory a solver needs and how large its search space is, and neither has ever been revised.
What makes the choice interesting is the word asymmetric in the title. Finding a solution is meant to be expensive in a specific way; checking one is meant to be trivial. That asymmetry is the whole design, and our explainer on proof of work covers why every such scheme needs it.
What distinguishes this one is where the expense is placed. Most proof-of-work schemes make a solver repeat a cheap operation an enormous number of times, so the limiting resource is arithmetic throughput. Equihash makes the solver hold a large table in memory while it searches, which shifts the constraint from how fast a chip computes to how fast it can move data.
What the paper claimed, precisely
This is where most accounts of Equihash lose the thread, and the mechanism of the error is worth naming: they replace a specific, testable engineering claim with a vaguer one that is far stronger and much easier to repeat (source: Cryptology ePrint Archive).
The paper's abstract sets out what the construction does: it "requires a lot of memory to generate a proof (called 'memory-hardness' feature) but is instant to verify". So the cost being imposed is memory rather than raw computation, and the verification stays cheap.
Three further claims sit alongside it, and each is precise enough to be tested. The designers introduce "the new technique of algorithm binding to prevent cost amortization", which is aimed at hardware that would otherwise spread one expensive setup across many attempts. They state that "possible parallel implementations are constrained by memory bandwidth", which locates the bottleneck rather than asserting one. And they quantify the tradeoff: the scheme "increases the computations by the factor of 1000 if memory is halved, and presents a proof of just 120 bytes long".
Read that list again and notice what is not in it. Nobody claimed that purpose-built hardware could not be built. The claim is that the advantage such hardware could obtain is constrained by memory bandwidth, and that skimping on memory is punished steeply.
Those are different statements, and conflating them is the single most common error in writing about this subject. A design that raises the cost of an advantage has not promised to eliminate it, and the paper is careful in a way its retellings are not.
Our guide to How Zcash mining works quotes what the protocol specification says about why Zcash chose this design, and is equally careful about the verb it uses.
What Zcash did with Equihash, and what it left alone
Zcash adopted Equihash at launch with the parameters above and has kept them. Across every network upgrade this chain has shipped, and there have been many, the specification states those two values without a per-upgrade qualifier, which is how it marks values that have never been revised.
That is a decision, not an absence of one. Parameters are the tuning knob an Equihash chain has: raising memory requirements is the documented lever for making existing hardware obsolete, and it is available at any upgrade. Zcash has not pulled it.
Meanwhile hardware built for precisely this instance is sold openly, and one vendor's catalog lists models reaching 420 Ksol/s (source: Crypto Miner Bros). Our guide to Mine Zcash profitably covers what that means for anyone considering mining, which is a separate question from what it means for the design.
The absence of a parameter change is the part worth sitting with. An Equihash chain that wanted to reset the hardware landscape has a documented way to do it, and choosing not to use it for a decade is a position rather than an oversight.
this guide does not tell you whether that outcome counts as the resistance failing. Our guide to How Zcash mining works declines that verdict on the grounds that the protocol document claims only an attempt, and nothing found for this guide changes the evidence available. What can be stated is narrower and more useful: the parameters were held, and hardware for them exists.
Whether a chain's miners are general-purpose or purpose-built also changes who runs the network, which our explainer on nodes, miners and wallets sets out as three distinct roles.
What the other chain did instead
The contrast that makes all of this legible is Monero, a chain that wanted the same property from its own proof of work, faced the same hardware pressure a few years later, then took the opposite route in response to it. Its answer is on the record and it is not a tuning change.
Rather than tuning an existing algorithm, it replaced one. RandomX is described by its own repository as "a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs", using "random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware" (source: RandomX).
Monero's own documentation records the adoption and the intent: RandomX was "developed by Monero contributors and adopted by Monero from release 0.15", and "the goal is to discourage the use of specialized hardware (like ASICs)" (source: Monero).
Note the shared vocabulary. Both designs reach for memory-hard techniques and both aim at the efficiency advantage of purpose-built hardware. The difference is in what each project was prepared to do about it afterwards: one held its parameters, the other changed algorithms and said so in a release note.
Neither response is obviously correct. Changing a proof-of-work algorithm is disruptive, invalidates hardware people bought in good faith, then has to be done again whenever the problem returns. Holding parameters is stable, predictable, then accepts whatever hardware market develops. Our comparison of Monero and Zcash covers the wider differences between the two, and how Monero works covers its side in detail.
What the pair does establish is that two projects with the same stated objective, both staffed by capable cryptographers, reached different conclusions about whether the objective was reachable by tuning. That is worth more than either project's own assessment of itself.
What none of this settles
Whether Equihash succeeded is not answered anywhere here, and the reasons are evidentiary rather than diplomatic. An intention is all the protocol document records (source: Zcash protocol specification), and the existence of a product category is all the vendor listings establish about hardware.
Neither of those measures how much advantage purpose-built hardware actually obtains over a general-purpose machine, which is the precise quantity the paper's central claim was about.
The paper's specific claims are not disproved by the existence of ASICs either. Its assertion was that parallel implementations are constrained by memory bandwidth, and a machine can be purpose-built and still be bandwidth-bound. Testing that needs measurements nobody publishes.
Nothing here is a proof-of-work tutorial. What hashing is, why difficulty exists, and how a block gets found are covered by our guides to Bitcoin mining and difficulty adjustment, and none of it is Zcash-specific.
The comparison drawn above is between two design responses, not between two chains. Which privacy model is better is a separate argument that turns on cryptography rather than on mining hardware, and our guide to Zcash vs bitcoin covers the Bitcoin comparison that people usually reach for instead.
And none of it is a reason to buy or avoid mining hardware. That decision runs on electricity contracts and depreciation rather than on what a paper hoped a decade ago, and our guide to Mine Zcash profitably sets out why no page can compute it for you.
One further limit belongs here. Nothing above tells you that either project made the wrong call, and the article deliberately presents both responses without ranking them. Two teams of capable cryptographers looked at the same problem and disagreed about whether tuning could solve it, which is information about the problem rather than about either team.
What the function actually asks a miner to do
The construction is easier to reason about once its shape is clear, and the shape explains where the memory requirement comes from.
The puzzle is a search problem rather than a repeated hash. A miner generates a large collection of candidate values, then looks for a subset of them that combines to satisfy a condition. Finding that subset requires holding the collection where it can be searched, and the collection is deliberately sized so that holding it costs real memory.
Two parameters govern the difficulty of that search, and they set both the size of the collection and how many elements must combine. Changing them changes the memory a solver needs and the amount of computation per unit of memory, which is the knob the design uses to position the puzzle where memory dominates.
Verification is deliberately cheap and asymmetric to solving. Any node can confirm that a proposed subset satisfies the condition in a trivial amount of work, without reproducing any part of the search. That asymmetry is what makes any proof-of-work function usable at all: expensive to produce, negligible to check.
The consequence worth carrying is that difficulty here is not a single scalar the way it is on a chain using a plain hash puzzle. It is a parameter choice sitting underneath the usual difficulty adjustment, and changing it is a consensus change rather than an automatic response to hash rate.
What a chain gets and gives up by choosing this
Four trade-offs follow from the choice, and they are the reason the decision is still argued about.
It gets a higher barrier to specialized hardware, which was the objective and which was partly achieved. Purpose-built machines took longer to arrive here than on chains using simpler puzzles.
It gives up simplicity in verification and in implementation. A search-based puzzle is more code than a hash comparison, and more code in consensus-critical paths is more surface for defects.
It gets a puzzle whose resistance is relative to the memory technology of the moment rather than fixed. That property decays without anyone doing anything, which is an unusual kind of maintenance burden.
And it gives up the ability to change course cheaply. Altering the parameters, or replacing the function entirely, requires a consensus change with all the coordination that implies, so a design that ages badly cannot simply be patched.
None of those four settles whether the choice was correct. They do explain why the question has stayed open for a decade rather than resolving into a consensus one way or the other.
Why memory-hard puzzles were expected to help
The idea behind the design is easier to judge once the reasoning behind it is stated in full, because the reasoning is sound and the outcome still went the other way.
A proof-of-work puzzle that depends mostly on raw arithmetic is easy to build dedicated hardware for. The circuit computes one function, over and over, with no need for much storage. Removing everything a general processor carries around gives an enormous efficiency advantage. That is why specialized machines took over the earliest chains so completely.
A puzzle that requires large amounts of fast memory changes the economics. Memory is a commodity. Its cost per unit is roughly the same for everyone, and a specialized machine still has to buy it. If the memory dominates the cost of solving, then the advantage a custom circuit can extract shrinks toward the difference in the surrounding logic rather than the difference in the whole machine.
That is the argument, and it is a good one. What it underestimated is how much of the surrounding cost still remains, and how much a specialized design can save on power, packaging and density even when it buys the same memory as everyone else. A narrower advantage is still an advantage, and at scale a narrower advantage compounds exactly the same way.
There is also a second-order effect that is easy to miss. A parameter choice that makes the puzzle memory-hard on the hardware available at design time does not stay memory-hard as memory gets cheaper and denser. The property is relative to the technology of the moment rather than absolute, which means a design can be correct when published and wrong a few years later without anyone changing anything.
What the outcome actually shows
Three things are supportable from the record, and each is narrower than the argument usually made from it.
Memory-hardness raised the cost of building specialized hardware rather than preventing it. That is a real effect and it delayed the transition, which is not nothing.
The property does not hold indefinitely against a determined and well-funded effort. Any parameter set can be attacked once the reward justifies the engineering, and the reward grows with the asset.
And no proof-of-work function has been shown to be resistant permanently. The distinction worth carrying is between a design that raises a cost and a design that closes a door, and only the first has ever been demonstrated by anyone.
A fourth observation is specific to how this gets argued. The design document states an intention rather than a guarantee, and it says so in its own words. Coverage of the subject routinely upgrades that intention into a claim the document never made, then treats the eventual arrival of specialized hardware as a broken promise. Reading the original wording settles that without needing a view on the engineering at all.
What to take from a decade of the experiment
The useful conclusion is about how to read design claims rather than about this function specifically, and it generalizes past Zcash entirely.
A resistance property is a cost claim, not a prohibition. Saying a design resists specialized hardware means building that hardware is more expensive, and expense is a threshold that a large enough reward eventually clears. Nothing in the literature has ever claimed otherwise, and the stronger reading appears mostly in secondary coverage.
A parameter choice ages. Any design positioned against the hardware available when it was published drifts as hardware changes, without anyone doing anything wrong. That means resistance is a maintenance commitment rather than a property you can ship once.
And a design decision can be correct and still not achieve its objective. The reasoning that produced this choice was sound given what was known at the time, and the outcome went partly the other way. Judging the decision by the outcome alone is a mistake people make about engineering constantly, and it is worth resisting here specifically, because the alternative available in 2016 was a function already known to have been captured completely.
There is a fourth point that only becomes visible with hindsight. A chain that changes its proof-of-work function to restore a resistance property has to coordinate a consensus change, and every such change costs the network something in coordination risk. So a design that ages has an ongoing price attached. That price is paid in upgrades rather than in electricity, and it price is part of the honest accounting for the choice.
The comparison people reach for is a different chain that changed its function repeatedly to preserve the same property. That approach has its own costs, its own critics and its own record. Setting the two side by side is a genuinely open question rather than a settled one.
Frequently asked questions
Is Equihash ASIC resistant?
Its designers never claimed that purpose-built hardware was impossible. The 2016 paper claims memory-hardness with instant verification, algorithm binding to prevent cost amortization, and that parallel implementations are constrained by memory bandwidth, with computation rising by a factor of a thousand if memory is halved. Those are claims about constraining an advantage rather than eliminating hardware, and machines built for Zcash's parameters are sold today. Whether that counts as the design failing is not something the available documents settle.
What are Zcash's Equihash parameters?
The protocol specification pins them at 200 and 9, the same on the live network and the test network. They set how much memory a solver needs and how large the search space is. The specification gives them without a per-upgrade qualifier, the marker it uses for values that have never been revised, so they have been the same across every network upgrade the chain has shipped.
Why did Monero use RandomX instead of Equihash?
Monero pursued the same goal by a different route. Its documentation records that RandomX was developed by Monero contributors and adopted from release 0.15, with the stated goal of discouraging purpose-built hardware, and the algorithm's own repository describes it as optimized for general-purpose CPUs using random code execution alongside memory-hard techniques. Where Zcash kept its parameters, Monero replaced the algorithm.
What is the generalized birthday problem?
It is the mathematical problem Equihash is built on, and the Zcash protocol specification describes the shape of it: given a long sequence of bit strings, find a set number of distinct ones that combine to zero. The parameters n and k fix how long the strings are and how many must be combined, which is what turns an abstract problem into a specific amount of work with a specific memory requirement.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are the original Equihash paper, the Zcash protocol specification, the RandomX repository, Monero's own project documentation, and a hardware vendor's product listings. All facts independently verified against cited documentation current as of August 2026. what follows states what each project claimed and did, and deliberately reaches no verdict on whether ASIC resistance succeeded.