/jump to repo

Repos Recent Bookmarks Watched Notes Tags Discover Compare Stats GitHub

Repository brief

ethereum/go-ethereum

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis

cached 2026-03-30T15:43:58.144Z

1mo ago

ethereum/go-ethereum

`ethereum/go-ethereum` is the main Go implementation of the Ethereum protocol, with a large and active upstream history. It is a high-interest base for forks because it has broad protocol, networking, node, and tooling coverage, plus very recent ongoing releases and fixes.

Loading tags...

Stars50,963

Forks21,885

Default branchmaster

Last pushed2026-03-30T15:22:30Z

Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs

Maintenance:

Magnitude:

Sort:

Selected

Prefer this fork if your goal is MEV-focused Ethereum infrastructure and you need the added bundle APIs. Prefer upstream if you want current geth maintenance, broad compatibility, and lower operational risk.

Choose this fork if you are working on Scroll and want execution-client behavior tailored to its rollup architecture. Do not choose it if you need the broadest upstream geth compatibility or the latest upstream-only changes with minimal fork-specific divergence.

Choose this fork if you need a Taiko execution engine with Taiko-specific APIs, genesis, and consensus behavior. Choose upstream go-ethereum if you want a broadly compatible Ethereum client or expect to follow mainline geth closely.

Choose this fork only if you need ETHW/PoW-specific behavior and are willing to accept substantial drift from upstream. If you want current Ethereum client maintenance, broader compatibility, or active security and protocol fixes, upstream `go-ethereum` is the better base.

Choose this fork only if you specifically need its old customized behavior or workflow assets. For anything that must track modern Ethereum protocol changes or current geth fixes, upstream is the safer choice.

Choose this fork if you need Ubiq network compatibility and accept a stale, heavily customized codebase. Choose upstream geth if you need current Ethereum features, active maintenance, or easier long-term upgrades.

Choose this fork if you need a go-ethereum base with searcher-specific execution and API behavior. Choose upstream if you want the latest general-purpose Ethereum client features with less maintenance burden and fewer compatibility surprises.

Choose this fork only if you need its legacy/customized historical surface area. For production Ethereum node work, upstream is the better default because this fork is both far behind and structurally very divergent.

Choose this fork if you need XinFin/XDC-specific functionality and are willing to accept substantial divergence from upstream geth. Prefer upstream if you need broad Ethereum compatibility, faster upstream alignment, or the full default geth API surface.

Prefer this fork only if you need its chain-specific networking and fork-rule customizations. If you want current geth features, security fixes, and lower maintenance cost, upstream is the safer choice.

Fork comparison

flashbots/mev-geth

38/100

stale

significant_divergence

Prefer this fork if your goal is MEV-focused Ethereum infrastructure and you need the added bundle APIs. Prefer upstream if you want current geth maintenance, broad compatibility, and lower operational risk.

Likely purpose

An Ethereum client fork adapted for MEV-focused block production and bundle simulation, likely for searchers, builders, and operators who need Flashbots-style auction workflows rather than stock geth behavior.

Best for

MEV searchers and builders; Teams running Flashbots-compatible infrastructure; Operators who specifically need bundle simulation APIs; Users who value MEV workflows over staying close to upstream geth

Additional features

MEV auction support
`eth_callBundle` for simulating bundles against a target block context
`eth_estimateGasBundle` for bundle gas estimation
Flashbots-oriented node behavior for builder/searcher workflows
Expands API, schema, or SDK surface area for downstream integrations and generated clients.
Introduces more operational workflow surface such as server-side handling, auth, session control, or admin tooling.

Missing features

Falls far behind upstream go-ethereum, so it likely lacks many later protocol, RPC, and networking fixes from recent releases.
Does not appear to track current upstream maintenance, including newer release-cycle changes and recent EIP/networking updates.
Likely harder to adopt as a general-purpose geth base because the fork is anchored to an older upstream snapshot from 2022.
It trails upstream by 200 commits, so some recent upstream features and fixes are likely not present yet.

Strengths

Useful if your product depends on MEV bundle simulation or Flashbots-style auction flows.
Large, established fork with a clear product direction instead of a generic node clone.
Keeps the core go-ethereum base, so it still starts from familiar geth architecture and tooling.

Risks

High divergence makes rebasing onto modern upstream expensive.
Stale activity means security, consensus, and RPC behavior may lag current geth.
The fork may be a poor fit if you need a broadly maintained production Ethereum client.