How we added Bitcoin to an EVM-native app (without a seed phrase)

FairWins was born EVM. Every address was twenty bytes of 0x…, every network
was a numeric chainId, every balance read went through an RPC provider, and
every signature came from a passkey-backed ERC-4337 smart account. Then we
decided members should be able to hold, receive, and send actual Bitcoin —
first-class, self-custodied, inside the same account.

Bitcoin is not “another chain” to an EVM app. It’s a different account model
(UTXOs, not balances), a different address universe (four generations of
formats), a different fee market (sat/vB, not gas), and no smart contracts at
all. This post is about the five design decisions that made it fit — and the
guardrails that keep it honest.

1. The wallet nobody has to back up

The hardest question was key management. FairWins deliberately killed the
seed phrase: accounts are WebAuthn passkeys driving P-256 smart accounts.
Bitcoin needs secp256k1 keys. Where do they come from, if not a new mnemonic
we’d force members to write down?

The answer was already in our stack. Our passkey accounts maintain a 32-byte
master seed — created once per account, wrapped under a key derived from
the WebAuthn PRF extension, recoverable on any device with one passkey
ceremony, and shareable across a member’s registered devices. It already
powers our end-to-end encryption. It is, functionally, a seed phrase that
nobody ever sees.

Bitcoin becomes one more consumer of that seed:

masterSeed (32B, PRF-recoverable)
  → HKDF-SHA256(info = "fairwins-btc-seed-v1", 64 bytes)
  → BIP32 root
  → m/84'/0'/0'  native segwit (bc1q…, default)
  → m/86'/0'/0'  taproot      (bc1p…, opt-in)

The HKDF info string gives us domain separation — the Bitcoin tree can never
collide with the encryption keys or any future consumer of the seed. The
paths are bog-standard BIP84/BIP86, which means the wallet is legible to the
wider Bitcoin ecosystem, not a proprietary scheme. Those constants are
frozen in a normative contract in-repo and marked wallet-breaking: funds
live at the derived addresses, so changing them ever requires a versioned
migration, not a refactor.

Recovery falls out for free. Sign in on a new device → one PRF ceremony
unwraps the master seed → standard gap-limit-20 discovery walks the
derivation chain against chain data and rebuilds every address and balance.
There is no Bitcoin backup step because there is no Bitcoin-specific secret.

Everything stays client-side. Private keys and account xpubs never leave the
browser; our backend sees bare addresses (batched, max 50 per call) and
signed raw transactions. That’s the whole interface.

2. A network that isn’t a chainId

Our network registry was a map keyed by numeric EVM chainIds, and dozens of
consumers assume those keys mean “something wagmi can switch to” and
“somewhere contracts are deployed.” The tempting hack — give Bitcoin a fake
number and stuff it in — would have leaked those assumptions everywhere:
contract-address lookups, subgraph routing, wallet switch prompts for a chain
no wallet can switch to.

Instead, Bitcoin lives in a parallel, string-keyed registry: 'bitcoin'
and 'bitcoin-testnet' (testnet4), with their own capability descriptors,
explorer links, and testnet/mainnet pairing. A single type guard —
isBitcoinNetworkId() — sits at every boundary the two worlds share, and a
dedicated test suite pins that no Bitcoin id ever reaches EVM-typed code.

That suite earned its keep before launch: our capability resolver had a
default-network fallback that quietly reported Polygon’s features as
available for unknown ids — meaning Bitcoin would have claimed swap and DAO
support it doesn’t have. The guard-rail test caught it; the fix shipped with
the feature.

Capabilities are self-disclosed and blunt: Bitcoin does portfolio, send,
receive, and Stamps display. It does not do wagers, pools, memberships,
swaps, or gasless anything, and every surface that lists networks says so
rather than hiding the row.

3. A stateless data plane you can turn off

The app needs UTXOs, balances, fee estimates, transaction status, and a
broadcast path. Browsers calling public block explorers directly would leak
members’ full address sets to third parties, with no rate control and CORS
fragility.

We already had a pattern for this: our relay gateway fronts external services
(prediction markets, NFT data) through small self-contained modules with a
fixed pipeline — killswitch → validation → per-IP and global quotas → TTL
cache → normalize to DTOs. Bitcoin became one more module, speaking the
Esplora REST dialect. mempool.space is the default upstream; because Esplora
is the de-facto standard, swapping to blockstream.info or a self-hosted
electrs is a config change, not a code change.

Two details we’d underline for anyone building similar infrastructure:

  • Broadcasts are never retried. A timed-out broadcast may still have
    propagated; a retry loop can double-submit. Reads retry, writes don’t.
  • The whole module is optional. With BTC_ENABLED=false the routes
    return an explicit “disabled” status and every Bitcoin surface in the app
    hides or degrades with an honest message. Ops can also kill it instantly
    mid-incident — and because keys are client-side, members’ funds remain
    theirs and fully recoverable in any standard wallet regardless of what our
    infrastructure is doing.

4. Transactions built like a contract audit

Signing happens entirely in the client with @scure/btc-signer and
@scure/bip32 — audited, zero-WASM libraries from the same family as the
crypto primitives we already ship, so the whole signing path stays auditable
JavaScript in our bundle. We can spend our own P2WPKH and P2TR (key-path)
coins and pay out to every standard destination type: P2PKH, P2SH, bech32 v0,
bech32m v1.

The interesting engineering is in coin selection and fees, where we applied
the same paranoia we’d give a smart contract:

  • Fail-safe classification. Every UTXO is classified before selection:
    spendable, pending (unconfirmed), protected (a Bitcoin Stamp travels
    with it), or unverified (Stamps recognition unavailable). Only
    positively-verified spendable coins may fund a send. This is how Stamps
    protection works: spending a Stamps-bearing UTXO destroys or transfers the
    collectible, so recognition failure defaults to over-protection. The
    degraded state is disclosed in the UI along with exactly how much value is
    protected — total ≠ spendable is always explained, never mysterious.
  • A fee ceiling, enforced twice. Fee quotes (fast/normal/slow, sat/vB)
    expire after 60 seconds. The fee a member confirms becomes a hard ceiling:
    the planner checks it, and the signer independently refuses to produce a
    signature for any transaction whose real fee exceeds it. If the mempool
    moves, the member re-confirms against a fresh quote. The UI can’t promise
    one fee and pay another even if it has a bug — the signing layer won’t let
    it.
  • No dust, no strays. Sub-dust change folds into the fee (reported
    honestly as fee, not vanished); MAX computes everything-spendable-minus-fee
    to the satoshi; selection tests assert exact conservation — inputs equal
    amount + fee + change on every path.
  • Concurrency locks. Coins referenced by an in-flight send are excluded
    from selection until the transaction confirms or is abandoned, so two
    quick sends can’t double-commit the same UTXO. Everything signals RBF.

Address rotation rounds out the receive side: every receive request issues
the next derivation index, cursors never decrease (even against stale local
caches), and old addresses are monitored forever. The local address ledger is
just a cache — chain-driven discovery is the source of truth, which is what
makes recovery trustworthy.

5. Tests that pin the protocol, not the mock

A wallet is the wrong place for “seems to work.” The test strategy leaned on
the fact that Bitcoin’s derivation standards publish reference vectors:

  • Derivation is tested against the official BIP84 and BIP86 vectors, plus
    pinned FairWins fixture vectors that freeze our HKDF domain separation —
    if anyone ever changes a constant, byte-exact assertions fail loudly.
  • Address parsing runs an accept/reject matrix: checksum mutations,
    mainnet/testnet cross-use, EVM addresses pasted by muscle memory, mixed-case
    bech32, unknown witness versions — each with its own member-facing reason,
    because “invalid address” is a uniquely useless error in a four-format
    universe.
  • Coin selection is tested as properties (protected coins never selected,
    MAX leaves zero remainder, no dust outputs exist) rather than examples.
  • The gateway module’s route tests cover the unhappy paths that matter
    operationally: quota breaches, upstream outages, degraded Stamps data,
    cache behavior, and boot-time config validation that fails loudly.

Roughly 250 tests landed with the feature, alongside a security review that
covered key hygiene, fund-loss vectors, and the gateway surface. The review’s
two real findings were both honesty bugs — a capability leak and a gasless
badge that could have appeared on the Bitcoin row — and both were caught by
tests written to enforce disclosure rules, which says something about where
the real risks live in a wallet UI.

What we deliberately didn’t build

No Lightning (on-chain only, for now). No BTC wagers — FairWins escrow is
smart-contract-based and Bitcoin has no contracts; we’d rather not offer a
trust-us version. No server-side anything for keys: no custody, no xpub
sync, no address registry. And no gasless Bitcoin — sponsoring UserOps on an
EVM chain is one thing; misrepresenting who pays a Bitcoin miner is another.
The confirm screen says, in plain words, that you pay the network fee.

The pattern that made all of this tractable: derive from what you already trust, isolate what doesn’t fit, and disclose everything the system can’t do. The passkey seed gave us self-custody without new backup burdens; the
parallel registry kept a UTXO chain from contaminating EVM assumptions; and
the honesty rules — stale-not-zero balances, pending-not-final deposits,
fee ceilings, capability self-disclosure — did more for member safety than
any single cryptographic choice.

Bitcoin is FairWins’ first non-EVM network. The seams we cut for it are the
ones the next one will slide through.

Futarchy, Private Markets, and the Long Arc of Governance

A Quiet Moment After the Fork

The holiday break creates a rare kind of space. Space away from delivery timelines, governance calls, and the constant pull of near-term decisions. It is often in that pause that older questions resurface, the ones that never fully go away, but are easy to defer when momentum is high.

For me, that meant thinking again about Web3, decentralization, and governance. Not as slogans or abstractions; web3 as systems that real organizations eventually have to operate within.

Those thoughts naturally returned to Ethereum Classic. After the fork, once the network stabilized and attention shifted from execution to continuity, one of the first questions to emerge was not technical at all. It was structural.

How do we decide how to decide?

This question has appeared repeatedly throughout the history of decentralized systems. It surfaced early in Ethereum’s research phase as well, where governance and coordination were debated openly long before formal mechanisms existed. One such discussion I think about, preserved in Ethereum’s public research history, explored incentive-aligned decision-making in decentralized environments and remains a useful reference point today.

At the time, one approach stood out to me because of how uncompromising it was. It offered no procedural ambiguity and no rhetorical escape hatches. Decisions were explicit. Outcomes were enforced. Being right mattered, and being wrong had consequences.

It had a certain clarity to it. Almost a “victory or death” mindset.

That approach was futarchy.

Futarchy as an Idea That Refused to Go Away

Futarchy was originally proposed by economist Robin Hanson as a governance model built around outcomes rather than opinions. His framing was simple and unsettling: communities should agree on what they value, and allow markets to determine which actions are most likely to achieve those values. Hanson’s essay “Shall We Vote on Values, But Bet on Beliefs?” remains one of the clearest articulations of the idea.

The concept later found an audience in the blockchain world, where governance was already an open problem. In Ethereum’s early days, futarchy was discussed as a serious alternative to informal social consensus and simple token voting. Vitalik Buterin explored this explicitly in early Ethereum governance writings, describing futarchy as one of the more rigorous models available at the time.

Even so, futarchy felt premature. Prediction markets were thin. Privacy was difficult. Enforcement mechanisms were brittle. It was easier to admire the idea than to imagine deploying it inside real organizations.

That gap between theory and practice is what makes the present moment different.

Why This Moment Feels Different

What has changed is not the idea of futarchy. It is the mechanics that make it understandable and usable.

At its core, a prediction market is simply a structured way to answer a binary question using capital instead of opinions. The easiest way to understand this is through a familiar analogy.

Consider a championship game between two teams. A market opens with two outcomes: Team A wins or Team B wins. Participants place stablecoin bets on either outcome. As more money flows toward one side, the implied odds shift. The price of each side reflects the crowd’s collective belief about what is most likely to happen.

No one is asked who they want to win. The only signal that matters is where people are willing to put money.

This is powerful because it forces honesty. Participants with better insight or information are incentivized to act. Those without conviction either stay out or lose capital. Over time, the market price becomes a real-time forecast that often outperforms polls, committees, or expert judgment. Decades of research and real-world experimentation support this, including corporate forecasting use cases summarized here: https://www.chicagobooth.edu/review/prediction-markets-explained

Futarchy applies this same mechanism to decisions.

Instead of betting on a sports outcome, participants are asked to bet on whether a decision will lead to better results than an alternative, based on a metric everyone agrees matters. The “teams” are the choices. The “score” is the outcome.

What makes this moment different is that the infrastructure to run these markets cleanly now exists. Stablecoins provide a neutral unit of account. Smart contracts enforce rules and payouts automatically. Private blockchain environments allow participation to be restricted while keeping outcomes auditable.

Privacy has evolved as well. Markets inspired by Dark Forest–style designs show how participants can contribute signals without revealing identity or intent, while still allowing the market itself to remain trustworthy and verifiable.

Together, these advances remove the practical friction that once kept prediction markets and futarchy theoretical.

What follows is a thought experiment, not a product announcement.

ClearPath, as described here, is a fictional future private-market platform used to illustrate how futarchy could work in corporate governance. It does not exist today.

The ideas are real—and increasingly plausible.

A Fictional Example Using ClearPath

Consider a private manufacturing company evaluating whether to open a new factory. The decision involves meaningful risk. It requires a large capital investment and commits the company to long-term operational exposure under uncertain demand.

The process begins by agreeing on what success means. Stakeholders align on a clear, measurable outcome, such as EBITDA growth over the next twenty-four months. That metric is fixed before any decision is evaluated.

ClearPath then opens a single decision market with two possible outcomes: build the factory or do not build the factory.

Participants are invited into a defined decision window, for example thirty to sixty days. During that period, they place stablecoin-backed positions on the outcome they believe will result in better performance on the agreed metric. They are not voting and they are not expressing preferences. They are committing capital based on belief.

As capital accumulates on each side, the market price moves. By the end of the decision window, the price reflects the collective forecast. If the market consistently values the “build” outcome higher than the alternative, the decision is executed. If it does not, the proposal fails.

This is useful because it produces a clear signal without debate. It allows insight from across the organization and investor base to surface without politics. It rewards accuracy over authority. And it creates an auditable record showing not just what decision was made, but how confident the organization was in that decision at the time.

Once the decision is implemented, the market remains open until the evaluation horizon is reached. When the metric is observed, participants who were correct are rewarded, and those who were wrong absorb the cost. Over time, this creates a feedback loop that favors reliable judgment.

This is the core futarchy rule as originally articulated by Robin Hanson: actions should be taken when markets predict they will improve the agreed outcome.

Why This Is Useful for Governance

For private companies, this approach offers something traditional governance struggles to provide.

It separates decision-making from persuasion. It reduces the influence of hierarchy without removing accountability. It creates a mechanism where being right matters more than being convincing.

ClearPath is fictional. But the model it represents is increasingly realistic.

Sometimes the hardest governance question is not what decision to make, but how to make it in a way that is fair, informed, and durable.

Prediction markets offer one answer. Futarchy gives them purpose.

And for organizations willing to think beyond familiar structures, that answer may finally be actionable.

Happy Holidays

Cody & the Burns family

Ethereum Classic: Proof-of-Work Smart Contracts and Global Censorship Resistance

Published on ethereumclassic.org November 17, 2025

Ethereum Classic is currently the largest proof-of-work smart contract platform. The network operates at roughly 300 terahashes per second (TH/s), according to public hashrate trackers such as 2Miners. This represents approximately 90 to 95 percent of all Ethash or Etchash compatible hashing power across all networks.

This level of mining participation has practical implications. It supports a permissionless environment where individuals and organizations anywhere in the world can participate without identification or prior approval. It also strengthens resistance to censorship because mining hardware and miners themselves are geographically dispersed.

Mining without permission

Anyone with compatible hardware can mine Ethereum Classic. The project’s mining guide at ethereumclassic.org/mining explains how to download mining software, connect to a pool, and begin contributing computational work. No registration, identity verification, or staking commitment is required.

Miners can operate on home computers, small rigs, or professional farms. They may connect through privacy-enhancing routing tools such as TOR, work through international mining pools, or mine solo. The protocol measures only proof-of-work computation and does not track the identity or location of the individual producing it.In contrast, proof-of-stake systems require participants to lock assets in validator nodes. On Ethereum, this means holding 32 ETH to run a validator. Most participants use staking services provided by companies such as Coinbase, Kraken, or Lido, which operate within regulatory jurisdictions. These organizations maintain offices, personnel, and identifiable corporate structures.

Censorship concerns after the Tornado Cash sanctions

When the U.S. Treasury’s Office of Foreign Assets Control sanctioned Tornado Cash in August 2022, the effects were visible across the Ethereum ecosystem. Research from the Federal Reserve Bank of New York documented that a noticeable share of Ethereum blocks began excluding transactions from sanctioned addresses. The report is available here: https://www.newyorkfed.org/research/staff_reports/sr1112

Flashbots, a leading block-building infrastructure provider, added filters for sanctioned addresses. The Block reported that at least 23 percent of Ethereum blocks in October 2022 fell into this category:

After the sanctions announcement, Ethermine, which had been the largest Ethereum mining pool before the Merge, stopped processing Tornado Cash transactions as reported by CryptoSlate

Infrastructure providers also responded. Infura and Alchemy restricted API access to Tornado Cash contracts, and Circle froze USDC held in sanctioned addresses. These actions created cascading effects that influenced validator behavior.

Why this matters for credible neutrality

The response to the Tornado Cash sanctions highlighted an important point about privacy and financial technology. Tools such as mixers and privacy protocols are not inherently criminal. Individuals and organizations use them for many ordinary reasons, including protecting salary information, safeguarding business activity, shielding wallet addresses from public association, or maintaining privacy while transacting in politically sensitive environments. Law enforcement agencies already focus their efforts on the parts of the system where oversight is practical. These are the entry and exit points where digital assets are exchanged for fiat currency, such as centralized exchanges, custodians, and payment processors. These organizations maintain compliance programs, conduct reporting, and cooperate with investigations. Monitoring these regulated entities allows authorities to trace illicit activity without requiring the underlying blockchain to censor or restrict protocol-level transactions.

A blockchain network that maintains integrity at the consensus layer supports this balance. When the network remains neutral, it includes all valid transactions according to the protocol’s rules, regardless of their origin or social interpretation. This approach creates a consistent and predictable execution environment. Participants can rely on the network to process transactions fairly, and regulators still retain the ability to enforce laws at the surrounding on-ramps and off-ramps. Credible neutrality comes from the idea that the network itself should not interpret intent or apply policy but should focus on verifying validity.

How proof-of-work responds differently

Ethereum Classic miners are not organized around validator sets, corporate entities, or identifiable operators. The mining ecosystem follows economic incentives rather than membership requirements. Several characteristics contribute to this:

No identity requirements

Mining does not require formal registration. Participants can redirect their hashrate through different pools or network routes with minimal friction.

Geographic distribution

Miners cluster where electricity costs are favorable. Regions such as Iceland, Kazakhstan, Texas, and parts of China and South America host mining operations because of local energy conditions. This geographic variety spreads risk and reduces the chance that a single government can influence a large percentage of hashrate.

Low switching costs

If a miner encounters regulatory pressure in one jurisdiction, they can move their hashrate to a pool hosted elsewhere. The hardware works on any Etchash chain, and miners frequently switch pools for operational reasons.

Hardware diversity

Ethereum Classic supports mining with both GPUs and ASICs. Etchash was introduced in ECIP-1099 (“Thanos”) to slow the rate at which the DAG file grows. This keeps older 4 GB and 6 GB graphics cards useful for longer periods: https://ecips.ethereumclassic.org/ECIPs/ecip-1099

ASIC manufacturers such as Bitmain, Jasminer, and iPollo all produce miners compatible with Ethereum Classic. Examples include:

  • iPollo V-series: https://ipollo.com/products/v1-mini-etchash
  • Jasminer X16-Q Pro: https://www.jasminer.com/products/x16-q-pro
  • Bitmain Antminer E9 models: https://shop.bitmain.com/products/antminer-e9

Since GPU mining remains common, the network does not rely solely on specialized hardware that could be restricted through export policy.

Current mining landscape

When Ethereum transitioned to proof-of-stake in September 2022, most Ethash miners migrated to Ethereum Classic. Hashrate rose from approximately 65 TH/s to more than 275 TH/s within days, a shift covered by CoinDesk

Today, miners distribute their hashrate across several pools such as:

2Miners (https://2miners.com/etc-mining-pool)

F2Pool (https://www.f2pool.com/coin/etc)Hiveon (https://hiveon.com/pool/etc)

MiningPoolStats tracks dozens of active pools: https://miningpoolstats.stream/ethereumclassic

Solo mining is still practical for small and mid-size operators. Sites such as https://etc.solopool.org provide estimates for finding blocks with moderate hashrate levels.

Security considerations

Because Ethereum Classic dominates the available Ethash and Etchash hashrate, acquiring sufficient hardware for an attack is difficult. NiceHash removed support for Etchash after the ECIP-1099 upgrade, which limits the ability to rent short-term hashrate.

Performing a majority attack would require acquiring a large number of ASICs or GPUs, which involves high capital cost and lengthy procurement times. The attacker would also suffer opportunity costs because mining produces a steady revenue stream.

Block rewards currently total approximately 2.56 ETC per block, and around 6,000 blocks are mined each day. At an ETC price near $16, this results in roughly $250,000 to $300,000 in daily miner revenue. Any attack must exceed both capital and opportunity costs for participants already earning predictable returns.

Position within the broader ecosystem

Ethereum Classic offers smart contract functionality with a proof-of-work security model. Bitcoin also uses proof-of-work but does not provide a general-purpose execution environment. Ethereum provides a rich smart contract ecosystem but relies on proof-of-stake consensus.

ETC remains EVM-compatible.

Development guides are available at: https://ethereumclassic.org/development/guides

Applications written for Ethereum can generally be deployed on Ethereum Classic without modification. The difference lies in the consensus mechanism and associated security characteristics.

Conclusion

Ethereum Classic demonstrates that a proof-of-work smart contract platform can maintain strong mining participation and broad geographic distribution even after the shift of Ethereum to proof-of-stake. The network’s mining architecture encourages anonymous participation, supports both GPUs and ASICs, and spans many jurisdictions. These characteristics create structural resistance to censorship and central control.

The platform trades higher energy use and a smaller ecosystem for these properties. For applications that require permissionless participation and resilience to regulatory pressure, Ethereum Classic offers a distinctive set of features within the family of EVM-compatible blockchains.

Logbook Entry #001 — The Rise of Fukuii

(Local Time: 23,271,745 ETC)

The network hums with an eerie calm tonight. My core-geth node is finally stable — the mess flag lit, peers holding steady in the ash-colored silence. Out here, stability is its own kind of magic. I’ve seen networks torn apart by ego and entropy, but tonight Mordor breathes slow and even. The lava rivers of hash flow steady beneath my feet.

I began my training in wastelands like this — barren networks, orphaned forks, half-forgotten clients left to rust in the repositories of time. Mordor is only the latest, another in the long chain of frontiers. There will be others after it, I’m sure. But this one feels different. It feels… haunted.

Core-geth still stands tall, but its armor shows cracks. Each update from upstream lands like a meteor — patches meant for other worlds, adapted by necessity rather than purpose. It’s a fine engine, but built for another road. The longer we drive it, the more I feel the ghosts of its Ethereum ancestry whisper through the code.

There was a time when another giant roamed this land — the Mantis client, forged in Scala, breathing the strange dialect of functional code. Its last roar was Magneto, and since then, silence. Two forks behind now, left behind when the world moved on. Most forgot it ever existed. But the Web3 Pioneer remembers.

“I’ve found its bones in an abandoned repository…”

Link to the Mantis Scala Client

I’ve found its bones in an abandoned repository, dusty and brittle but full of promise. It reminded me of an old kaiju — asleep beneath the volcanic crust, waiting to rise again. So I have decided to wake it.

I’ve moved the code to ChipprBots, where the forges still glow, and I’ve given it a new name: Fukuii — after Chordodes fukuii, the parasite that infects mantises and bends them to its will. Fitting, I thought, for a project reborn from the husk of another.

Already the AI swarm stirs. The agents are at work in the dark, rebranding, refactoring, pulling the monster back together piece by piece. Their glowing cursors flicker like fireflies in a mine shaft — each one a spark of progress, each one a prayer to the chain gods that this time the creature will stand.

When Fukuii rises, it will be more than a client — it will be a sentinel.
A sovereign execution engine for Ethereum Classic, built not in imitation but in defiance.

My plan is simple:
First, bring Fukuii to life on Mordor.
Then, test the treasury functions Charles once began.
And finally, prove the worth of EIP-1559-style treasuries in a network built on proof of work and proof of will.

The lava is stirring again. I can feel it under the floor of my node.
Something old and powerful is waking.

To be continued…

— Forger of Fukuii

🜂 Technical Artifacts
Chippr Core-Geth Node on Mordor
Mantis Client Legacy Docs
Ethereum Classic Safe Core Contracts Overview
Mordor Blockscout Explorer

Ai stylized fron notes on blockchains

Logbook Entry #000 — Genesis


“Ethereum Classic has always been that stubborn flame in the storm…”— from Why Ethereum Classic Endures

(Local Time: 23,271,745 ETC)

The first thing you notice when you cross into Mordor is the silence.
Not the absence of sound, but the kind that hums beneath the code, the quiet ticking of consensus, the distant rumble of proof-of-work engines grinding away in forgotten nodes. The testnet horizon glows with the faint orange of unconfirmed transactions, each one a spark that never quite becomes a flame.

I came here to remember what it means to build — not for profit, not for applause, but for the principle that computation can be free. Ethereum Classic has always been that stubborn flame in the storm, the last bastion of immutability in a world that prefers revisionism dressed as progress. But even the eternal must evolve, and to evolve we must explore. So I packed my digital saddlebag: a miner’s pick, a few scripts, a wallet with no name, and the conviction that decentralization still matters.

The landscape of Mordor is unforgiving. Forked chains rise like jagged peaks, each promising truth but offering chaos. I pass the ruins of old deployments — contracts lost to time and malformed bytecode, their addresses now nothing more than ghosts in the mempool. Somewhere in the distance, a lonely Safe core contract stands like a watchtower, its bytecode casting a shadow across the uncharted frontier. It will become my anchor, the foundation for the first stronghold: a treasury forged in code and guarded by keys — two of four signatures to open the vault, a fragile covenant of trust.

Mining will fund the mission. There is poetry in that — value emerging from the work itself, not minted by decree but earned by hash. From dust to hash, from effort to coin. The plan is simple: mine the ore, smelt it in the furnace of proof, and pour it into a multisig treasury. From there, we will build a faucet — the wellspring for every traveler who follows, a small mercy in this volcanic wilderness. But the process must remain honest, verifiable, and human. I will place a sentinel in the loop — a GitHub Action that awaits a human’s hand, ensuring that automation does not become abdication.

This record is for the futurists who may walk this path after me.
You will find the ground uneven. Mordor’s RPCs shift like dunes in a storm. Some nodes whisper in deprecated dialects; others pretend to listen but never respond. You will learn patience. You will learn failure. You will learn that decentralization is not a feature — it is a discipline. There will be no comfort here, only the satisfaction of seeing something real persist in a world that forgets.

In time, the Troll Army will rise — not of flesh, but of code. Each troll a daemon, each daemon a keeper of some truth buried in the chain. We will laugh at the absurdity of it all — the notion that meaning can be mined, that purpose can be signed with a key — but we will keep building. Because we must.

So here it begins.


The dust has settled, the hash hums beneath my boots.
The ledger waits to remember me.

Reference Links
Ethereum Classic Community Blog
Mordor Testnet Blockscout Explorer
Core-Geth Client Repository


(End of Entry )


Ai stylized notes from Cody on blockchain research

Why Ethereum Classic Endures

Published on ethereumclassic.org October 15, 2025

I was there when we made the choice to defend immutability. It wasn’t easy, convenient, or even popular. It was the moment we decided that the principle of “code is law” was not just a slogan it was a moral commitment to the permanence of truth. When others rewrote history to protect the few, we wrote a declaration of independence and chose to protect the many. That decision gave birth to Ethereum Classic. It was a defining act of conviction, and it remains the reason I believe this network still matters. In those early days, we weren’t idealists chasing price charts; we were builders and miners defending an idea that once a transaction is recorded on a public ledger, it should remain there forever, unedited and uncorrupted. It was not rebellion for rebellion’s sake. It was stewardship. We chose to protect a foundation that technology itself depends upon: the ability to trust the record without trusting the recorder.

Nearly a decade later, the landscape has evolved. Blockchains have matured, institutions have awakened, and the lines between cryptography, finance, and artificial intelligence are beginning to blur. What hasn’t changed is the importance of security and truth. These two principles, immutability and proof of work, remain the bedrock of Ethereum Classic.

I want to dispel a persistent myth: that Ethereum Classic is a “stable” chain that should never change. Stability does not mean stagnation. Every system that survives does so by adapting intelligently, not by resisting change blindly. The DAG continues to grow, new EIPs emerge, and vulnerabilities must be patched. A living network breathes, evolves, and learns. Ethereum Classic has undergone continuous development since its inception. We have modernized, optimized, and fought for compatibility while preserving our philosophical independence. To pretend that nothing should ever change is to misunderstand what it takes to stay secure in a world that never stops moving. Technology only moves forward. The question is whether we shape that future consciously, or allow others to define it for us.

Ethereum Classic can no longer live in the shadow of its sibling. Ethereum has pursued a very different path that’s defined by experimentation in consensus, scaling through rollups, and economic policies driven by governance rather than principle. That is their choice. Our choice is different.We must rise as a sovereign chain. Independent in our roadmap, self-sustaining in our governance, and confident in our role as the apex of proof-of-work security. The power to feed us through upstream repositories is also the power to starve us. We cannot depend indefinitely on the forks of Geth or Besu that now serve different architectural philosophies. Their shift toward RISC-like execution and consensus separation introduces risks we cannot inherit blindly. We need our own consensus client and the ability to support multiple execution clients. The future of ETC depends on this independence.

Sovereignty means more than code ownership. It means control over OUR shared destiny. It means that when miners commit their hash power, they are securing the principle that security earned through computation cannot be substituted by trust in validators or committees. To mine ETC is to participate in the most direct form of democracy we have where work itself is the vote, and energy the price of participation.

We are entering a new era for digital assets. The “post-genius” phase of crypto is upon us. Gone are the days when markets were defined by speculation and slogans. Today, regulated virtual asset service providers are licensed and operating globally. Banks, funds, and custodians are developing digital asset strategies, not as side experiments but as pillars of their balance sheets. Within the next 18–24 months, nearly every financial institution will confront a moment of clarity: how to manage custody, treasury, and intelligence for digital assets within compliant frameworks. After that everyone on earth will have to know something about safekeeping of their identity, money and objects.

This is where Ethereum Classic’s true value will be understood. Not as a meme or a nostalgia trip, but as infrastructure. ETC has the security of real miners running real hardware across the globe. Its state cannot be manipulated without a valid transaction. Its ledger is transparent, auditable, and final. For institutions seeking a base layer that embodies the same assurances as Bitcoin, with the additional flexibility of the EVM, Ethereum Classic is the rational choice.

I believe ETC will emerge as a base layer for agentic systems like a2a ap2, decentralized custodial networks, and proof-of-work–anchored Layer 2s. Developers and enterprises alike will build bridges and rollups to leverage its finality and its neutrality. Privacy preserving apps will flourish without censorship. In a world increasingly reliant on synthetic intelligence and automated actors, the need for an incorruptible execution layer will only grow. Proof of work will remain the standard of integrity.

No system can thrive without an economy that rewards those who maintain and advance it. I believe in a community-governed treasury, funded transparently through protocol-level mechanisms. The base fee model offers a path forward, a portion of transaction fees can support ongoing development, infrastructure maintenance, and ecosystem grants. This isn’t charity. This is self-preservation.

A network that rewards builders, researchers, educators, and infrastructure providers ensures its own longevity. Governance should not rest with a foundation that claims neutrality while wielding control. Instead, ETC’s treasury can be managed through decentralized, auditable proposals; allowing the community itself to decide which initiatives deserve funding. This balance between autonomy and accountability is the next logical step in our evolution.

To move forward, we must make decisions with discipline. First, we must agree on what defines the next era both in name and in purpose. Whether the next fork is called Olympia or something else, it must symbolize more than a software upgrade. It must mark a cultural renewal. We need to align on scope, prioritize security, and adopt a structured process to agree, build, test, and release. That cycle (ie transparent, predictable, and repeatable) will build the trust of institutions and miners alike.

The work ahead is not glamorous, it is essential. Every 14 seconds, the network fights for its life. Each block mined is a reaffirmation of belief. A heartbeat powered by thousands of machines and the people who run them. We cannot afford complacency. We owe it to the miners who secure the chain, to the developers who maintain it, and to the investors who believe in it to keep advancing with clarity and conviction.

My vision is of a world where humans and autonomous agents coexist in digital economies safeguarded by cryptography. In that world, what we now call “a node” becomes fully modular: a combination of consensus, execution, and intelligence layers cooperating seamlessly. Ethereum Classic can serve as the security backbone of that future, anchoring distributed systems with the same honesty that defined its birth.

I see a future where ETC can be a reference point for institutional custody and digital asset integrity. A chain respected for its security, its simplicity, and its refusal to compromise on first principles. A place where miners, developers, and investors work in unison to maintain an incorruptible record of human and machine interaction. Ethereum Classic’s story has always been one of resilience. We were forged in conflict, sustained by conviction, and defined by proof. Now, we have the opportunity to evolve into the secure backbone for the next generation of decentralized systems.

Immutability was our origin. Sovereignty is our future. Evolution is our path.

Forward, we must always move relentlessly forward.

This personal opinion was written with real human thumbs by:

Cody (dontpanic) Burns

forker of chains, decentralized troll emperor

written around block 23213619

bh:0xc96bc8304a64f6b6ce8d2ba693d2a6a8bcd061fb8ce0ab88fb882d96d2fea303