One Contract, Two Halves: Beating a Hard Size Limit Without Moving House
What Are Spending Guardrails?
Renovating a Contract Without Changing Its Address
Passkeys and Smart Accounts: A Wallet With No Password to Write Down
What a passkey is, what a “smart-contract wallet” means, and why together they let you have a real crypto account without ever seeing a seed phrase
| Series | Knowledge Base |
| Track | Wallets & Keys |
| Level | Beginner |
| Audience | Newcomers who unlock their phone with Face ID and want to know what’s under the hood |
| Tags | passkeys, smart-accounts, webauthn, wallets, basics |
| Reading time | ~6 minutes |
The twelve words nobody wants to write down
If you have tried a crypto wallet before, you may remember the moment it handed you twelve random words and told you, sternly, to write them on paper and never lose them, never photograph them, never type them anywhere. That list — called a seed phrase — is the master key to the account. Lose it and your money is gone; let someone see it and they can take everything.
For most normal people, that is where crypto ends. Guarding twelve words like a launch code is nobody’s idea of a fun Tuesday night.
Here is the good news: you almost certainly already use a better system every day, and you probably do not even think of it as security. It is the fingerprint or face scan that unlocks your phone and signs you into apps. This primer explains that system — called passkeys — and the second piece that lets it control real money: a smart account.
What a passkey is
A passkey is a login credential built into your device that you unlock with your face or fingerprint instead of a password. It is the everyday name for a technology called WebAuthn, the same standard behind Face ID sign-in and fingerprint logins on banking and shopping sites you already trust.
Here is the part that makes it powerful. When you create a passkey, your phone generates a secret key and stores it inside a tiny, tamper-resistant security chip. That secret never leaves the chip — not to the app, not to a server, not even to you. When something needs approval, the chip proves it is you (after your face or fingerprint check) without ever revealing the secret itself.
Compare that to a seed phrase or a password, which you can be tricked into typing into a fake website or reading aloud to a scammer posing as support. A passkey has nothing to type and nothing to hand over — there is simply no secret sitting around for a thief to phish. That is exactly the security property crypto wallets have wanted for years.
What a smart account is
So passkeys are a great way to prove it is you. But there is a catch when you try to point one at a crypto account.
An ordinary crypto account is basically a single key and nothing else — a plain lockbox with one lock. It expects signatures written in one specific mathematical “handwriting.” Your phone’s security chip signs in a different handwriting. The two do not recognize each other, so a passkey cannot directly open an old-style account.
The fix is to make the account itself a little smarter. Instead of a plain lockbox, your account becomes a small program that lives on the blockchain — a smart account (you may also hear “smart-contract wallet” or “account abstraction”). Because it is a program, it can be taught to read your passkey’s handwriting and check your phone’s signatures directly.
That upgrade quietly unlocks conveniences a plain account never could:
- No seed phrase. Your face or fingerprint is the key. There is nothing to write on paper.
- More than one way in. A smart account keeps a list of approved controllers, not a single fixed key. You can add a second passkey on your tablet, or link an existing wallet as a backup — any of them can get you in.
- It can protect itself. Because it is a program, the account can enforce its own rules — for example, refusing to remove its very last controller so you cannot accidentally lock yourself out forever.
Think of an old account as a padlock, and a smart account as a small, programmable door with a guest list you can update as your life changes.
How the two fit together
Put them side by side and the experience clicks. The passkey is who you are — proven by your face or fingerprint, backed by a secret that never leaves your phone. The smart account is where your money lives — a program on the blockchain that recognizes that passkey and follows rules you can trust. You unlock it the same way you unlock your phone: the account confirms the approval came from a passkey on its guest list, and only then does anything move. No password, no seed phrase, no browser extension.
How this shows up in FairWins
When you join FairWins, this is exactly what happens — usually in a few seconds and without you thinking about any of it. Your face or fingerprint creates a passkey, and a smart account is set up that recognizes it. There is no twelve-word phrase to record, because there isn’t one.
FairWins leans on the smart account’s guest-list design in a friendly, practical way. It encourages you to add a backup controller — a second passkey or a linked wallet — so that if your phone is lost or broken, another approved device can still get you in. Adding one is a single face or fingerprint approval. And when you link something as a backup, the app tells you plainly that a backup controller has full control of the account, because on the guest list everyone is an equal peer.
What to watch out for
- A passkey is only as safe as your device’s backup. Most phones automatically sync passkeys to your cloud account (iCloud Keychain, Google Password Manager), so a new phone restores them. But a passkey made in a browser profile that wasn’t syncing can be genuinely lost — which is exactly why adding a second controller in the app matters.
- “No seed phrase” is not “no responsibility.” You still hold your own account. The responsibility shifted from guarding a paper phrase to keeping a backup way in. Do that early.
- Anyone with a controller has full power. Only link a wallet or add a passkey you actually trust and control. The app says so, and means it.
- Your face and fingerprint never leave your phone. The biometric check happens on your device to unlock the passkey; FairWins never sees it.
Related deep-dive
Want the engineering details? Read Passkey Smart Accounts: A Wallet You Open With Your Fingerprint — how FairWins turned Face ID into a real, self-custodial account with no seed phrase.
Learn more
- What passkeys are, in plain terms (FIDO Alliance): https://fidoalliance.org/passkeys/
- Passkeys / WebAuthn overview (Ethereum.org): https://ethereum.org/en/wallets/
- Account abstraction, explained (Ethereum.org): https://ethereum.org/en/roadmap/account-abstraction/
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=falsethe 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), orunverified(Stamps recognition unavailable). Only
positively-verifiedspendablecoins 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
Dust & Hash: The Long Watch of Gorgoroth
Season 2: Episode 2
It has been some time since the last entry. That, too, is intentional. Gorgoroth is not a place for spectacle; it is a place for endurance. Progress here is measured not in announcements, but in stability, repeatability, and the quiet absence of failure.
What began as a proving ground for Fukuii has become something sturdier — almost permanent. We have built the tools needed to live here. The most important of them is fukuii-cli, a simple but disciplined instrument that can start and stop nodes, initiate syncs, and smoke-check environments before trouble has a chance to take root. These are not glamorous victories, but they are the kind that matter. Infrastructure earns trust by being boring.It has become clear to me that Gorgoroth may outlive Fukuii itself. What started as a test configuration is turning into a pattern — a way of standing up networks quickly, validating assumptions, and hardening systems before they are exposed to the wider world. Trials, it seems, have a habit of becoming institutions.Our efforts have not been limited to the client alone. The frontier has widened.Beyond Fukuii, the work now stretches into prediction-market-powered DAOs, mining pool infrastructure, TokenMint 2.0, and other experiments still finding their shape. Each one feeds the others. Each one strengthens the army.My time in Mordor served its purpose. I learned what I needed to learn there — about systems, about patience, about what survives prolonged exposure to reality. I no longer feel the need to rush. The army grows whether I watch it or not. The tools mature. The noise fades.I can see it now, rising in the distance through the haze — Barad-dûr.That will be the final test. Not of whether Fukuii can run, but of whether everything we have built can stand together under real pressure, real users, and real consequences.I am patient.The time is near.
The Gorgoroth Trials continue.
What has emerged most clearly over this period is the distinction between the tools we are forging. Fukuii is a node client — sovereign, focused, and increasingly disciplined. Gorgoroth is something else entirely: a battle-net test harness designed to validate Ethereum Classic node behavior under controlled, repeatable conditions.
They serve different purposes. They answer different questions.
Fukuii asks: Can this client run the network correctly?
Gorgoroth asks: Can clients survive reality together?
To support this work, we have built the operational tooling needed to manage the terrain. fukuii-cli now allows us to start and stop nodes, manage sync behavior, and perform smoke checks on environments before deeper testing begins. These tools are not flashy, but they are decisive. They reduce uncertainty. They shorten feedback loops. They make the work repeatable.
Gorgoroth is not an endpoint, nor is it a byproduct. It is a compatibility proving ground — one that may be reused, adapted, and extended beyond Fukuii as other clients, configurations, and assumptions are tested against Ethereum Classic’s rules. Its value lies in discipline, not permanence.
Beyond Fukuii and Gorgoroth, the frontier has widened. Work continues across prediction-market-powered DAOs, mining pool infrastructure, TokenMint 2.0, and related systems that benefit from the same rigor learned here. Each effort strengthens the others. Each sharpens the collective understanding of what it takes to operate in the open.
My time in Mordor served its purpose. It taught me how systems behave when no one is watching — and how patience outperforms urgency. The army grows steadily now, not through force, but through alignment.
In the distance, Barad-dûr rises — not as myth, but as a final integration test. That is where everything converges: client behavior, operational readiness, compatibility, and public trust.
I am patient.
The work continues.
The time is near.
Read more: Dust & Hash: The Long Watch of Gorgoroth Read more: Dust & Hash: The Long Watch of GorgorothEthereum 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