Should You Fork Uniswap or Build From Scratch?

TL;DR

• Fork if: shipping fast in a known niche, your edge is distribution rather than protocol design, you genuinely don't intend to modify the protocol.
• Build from scratch if: novel mechanism, you'll maintain and modify the code in production, you want to deeply understand what you're shipping.
• Hybrid (most common, often correct): fork the core protocol, rebuild peripheral or differentiated parts. Most successful protocol families took this path.
• Cautionary tales: Hundred Finance ($7M lost to inherited cToken donation attack), Venus blocksPerYear (5x interest inflation from porting Ethereum constants to BSC unchanged), Midas Capital (similar share-inflation attack). All started with fork-without-understanding the security defenses they were copying.
• The right answer is rarely pure fork or pure build. It's about which parts to fork, which parts to rebuild, and how much understanding you've earned of the parts you copied.

Why this matters

The fork-vs-build decision is one of the highest-leverage early decisions a Web3 founder makes. It determines:

• How fast you can ship.
• How much engineering capacity you need.
• How exposed you are to inherited bugs.
• How much you can differentiate from competitors.
• How much you'll spend on audits and ongoing maintenance.

Most teams default to "fork" without explicit reasoning. They see the success of Pancakeswap, SushiSwap, Aerodrome, and pattern-match: "fork a winner, ship to a new chain or with a small twist". This works for some teams; it has produced spectacular failures for others.

If you're a founder making this decision, the framework here lets you explicitly reason about your specific situation. The default answer is rarely correct.

The fork case

Forking is the right call when:

1. Time-to-market matters more than differentiation

You're entering a market where being first is the dominant edge. The competitive moat is community/liquidity, not protocol design. Examples:

• Pancakeswap on BSC (2020): forked Uniswap V2, brand-customized for BSC, launched immediately, captured the first-mover liquidity. Pancakeswap's success was distribution + chain-positioning, not protocol innovation.
• Aerodrome on Base (2023): forked Velodrome (which forked Solidly), customized for Base, became Base's dominant DEX. Same playbook.

Both teams understood they weren't building a novel mechanism. They were deploying a proven one to a new chain.

2. The protocol you're forking is mature

A protocol that's been live for 2+ years, audited multiple times, and survived market stress is a known quantity. Forking it means inheriting a battle-tested design.

Uniswap V2, Compound V2, Aave V2: each has years of production exposure. Their bug surface is largely known. Audits of their forks can focus on what's been changed, not the entire codebase.

Compare to a fresh fork of a 6-month-old protocol: you're inheriting the original team's bug debt without their context for fixing it.

3. Your edge is non-protocol

If your competitive advantage is regulatory positioning, ecosystem access, brand, distribution, or chain-specific optimization, forking is the right call. The protocol is infrastructure; you're competing on layers above it.

4. You don't intend to modify the protocol

If you'll deploy and never touch the core code, forking is fine. Most fork-without-understand failures come from teams that DO modify the code (and break inherited defenses) without understanding what they broke.

If you fork Uniswap V2 unchanged and deploy, you inherit V2's security properties. That's reasonable. If you fork it and add a new mint function, you've introduced a fresh bug surface that your audit needs to cover.

The build case

Building from scratch is the right call when:

1. You have a novel mechanism

Your protocol does something existing protocols don't do. Aave's flash loans were a novel mechanism in 2020. Curve's stablecoin invariant was a novel mechanism in 2020. Liquity's redemption-driven peg was a novel mechanism in 2021.

Novel mechanisms can't be forked because they don't exist yet. You're building infrastructure. Building from scratch is the only option.

2. You'll maintain and modify the code in production

If your roadmap involves ongoing protocol updates, custom features, integration-specific changes, you need deep familiarity with the codebase. Forking and modifying as you go works for one or two changes; for sustained development, building from scratch (or at least rebuilding aggressively from a fork) gives you the ownership you need.

3. The cost of being wrong is catastrophic

If your protocol holds significant TVL (>$50M), a fork-without-understand failure can wipe you out. Build-from-scratch with extensive testing is the conservative choice when stakes are high.

This is more about engineering hygiene than fork vs build per se. A team that forks and audits as carefully as a team that builds from scratch will produce equivalently safe code; the question is which path your team can execute well.

4. You want to learn what every line does

Educational value. The team that rebuilds Uniswap V2 line by line in Academy understands every line by the end. The team that forks Uniswap V2 understands the lines they touched.

For a one-off protocol, this might not matter. For a team that will work in DeFi for years, the deep understanding compounds.

The hybrid case (most common)

Most successful protocols are hybrids. They fork the well-known core and rebuild what they're differentiating on.

Examples:

• Compound V3 (Comet): not a fork of V2; significant ground-up rebuild. The Compound team understood V2 deeply enough to know what to keep and what to change.
• Aave V2 vs V1: V1 was Aave's original codebase; V2 was a substantial rebuild informed by V1's operational learnings. Same team, accumulated knowledge applied to a fresh implementation.
• Curve V2 vs V1: V1 was the stableswap invariant; V2 added concentrated liquidity around dynamic pegs. Hybrid: kept the bonding curve concept, rebuilt the implementation.

The hybrid pattern is "fork what's solved, build what isn't". This requires the team to know which parts are which. Forking your differentiation is missing the point. Rebuilding the core is wasted effort.

Cautionary tales

Hundred Finance ($7M, 2023)

Forked Compound V2 across multiple chains. The fork inherited Compound V2's cToken contract, which is vulnerable to a donation attack if not deployed alongside specific defenses (minimum supply on first deposit, integration patterns that prevent 1-wei initial mints).

The Hundred Finance team didn't understand the donation attack pattern. They deployed the cToken without the defenses. An attacker:

1. Minted 1 cToken share by depositing 1 wei.
2. Donated a large amount of underlying directly to the contract.
3. The exchange rate skewed.
4. Subsequent depositors rounded to zero shares.
5. Attacker drained.

We covered the pattern in the Compound V2 fork donation attack article.

The fix is well-known and simple. The Hundred Finance team didn't know they needed it because they hadn't rebuilt Compound V2 from scratch. They'd forked it.

Venus blocksPerYear (Shadow Arena documented)

Venus is BSC's largest lending protocol, a Compound V2 fork. Compound V2 uses blocksPerYear = 2,102,400 (assuming Ethereum's 15-second blocks). BSC has 3-second blocks.

The Venus team forked the constant unchanged. Result: 5x interest inflation. We covered this in the Venus blocksPerYear article.

The fix is one number. The team needed to understand that blocksPerYear is a chain-time-dependent constant, not a universal one. They didn't, because they hadn't reconstructed Compound V2 from first principles.

Midas Capital (similar pattern, $600K+)

Midas was another Compound V2 fork with the cToken donation attack vulnerability. Lost a smaller amount than Hundred but illustrated the same root cause: forking without understanding the defensive choices.

The pattern

All three cases share the same arc:

1. Team forked a known-good protocol (Compound V2).
2. Team didn't reconstruct from scratch; they trusted the original code.
3. The original code's defensive choices weren't fully visible to the team because they hadn't earned that understanding.
4. When the team modified the deployment context (different chain, different decimals, different surrounding integrations), they broke inherited defenses without realizing it.
5. Loss of funds.

The fix that would have prevented all three: reconstruct the protocol from scratch in a sandbox before deploying the fork. Time investment: 30-50 hours. Saving: $7M+ across the three cases.

Decision framework

Ask yourself, in order:

1. Is your edge protocol design or distribution/positioning?

If protocol design: build (or hybrid-with-significant-build). If distribution/positioning: fork.

2. Will you modify the protocol's core logic?

If yes: build the parts you'll modify; fork the parts you won't. If no: fork is fine, but verify you genuinely won't modify (most teams do, eventually).

3. What's the TVL exposure on day one?

If <$10M: fork is fine; small protocols recover from small bugs. If $10M-$100M: fork-and-audit-thoroughly is the minimum; ideally hybrid. If >$100M: build, or build-the-changed-parts. The cost of fork-without-understand failure is too high.

4. How much engineering bandwidth do you have?

If 1-2 engineers: fork; you don't have capacity to rebuild. If 3-10 engineers: hybrid is realistic. If 10+ engineers: build is feasible; you can sustain a longer development cycle.

5. Is the protocol you'd fork a mature, well-audited, production-tested codebase?

If yes (Uniswap V2, Compound V2, Aave V2): fork is reasonable. If no (recent fork of a fork of a fork): higher risk; consider rebuilding the parts you'll touch.

The combined answers give you the right shape. Pure fork is rare; pure build is rare. Hybrid is the default for most teams.

Related questions

Can I fork and then audit thoroughly? Yes, and this is the right call when forking is the strategic choice. The audit needs to cover the inherited code, not just your changes. That's roughly 2-5x the audit cost of "audit the changes only".

Does the original team's reputation matter? Yes. A fork of Uniswap V2 (mature, multi-audited, multi-firm-reviewed) is different from a fork of a 6-month-old protocol with one audit. The original's track record predicts your inherited bug surface.

What about Compound V3 forks? Compound V3 (Comet) is much smaller and tighter than V2. Forking it is more straightforward, fewer inherited assumptions to reason about. The same general principles apply.

Should I fork audit firm-recommended forks? A protocol that's been audited multiple times by reputable firms (and shipped without major exploits since) is the gold standard for forking. Inheriting their audit history is meaningful.

How long does building from scratch take? For a Uniswap V2-style protocol with comprehensive testing: 3-6 months for an experienced team. For a Compound V2-style: 4-8 months. For something novel: indefinite, depends on the design space.

Can I do "fork and rewrite gradually"? Yes. Some teams fork to ship fast, then rebuild parts over time as they accumulate understanding. This is rational if your TVL stays small early; less rational if your TVL grows fast.

Where to see this in Academy

The Build pillar at Zealynx Academy is the rebuild path for two of the most-forked protocols in DeFi. Uniswap V2: 217 tests across 16 sections. Compound V2: 207 tests across 18 sections. Working through either gives you the deep understanding that prevents fork-without-understand failures.

We covered the broader argument in the why-rebuild-vs-fork-protocols article, which sits beside this one. That article makes the pedagogical case; this article gives the decision framework.

The Shadow Arena pillar lets you audit forks with the bug list available, which is good practice for whichever side of the fork-vs-build line you end up on. Auditing forks is a separate skill from designing them.

If you're a Web3 founder reading this and the answer is "we're going to fork": the deepest insurance you can buy against fork-without-understand is to spend 30-50 hours doing the Academy reconstruction of the protocol you're forking. Your team will be much harder to surprise after.