Research

Posted on

Put Your Idle Crypto to Work: Staking Comes to FairWins

Earn staking rewards on ETH and POL, right from your wallet — with the same honest, self-custodial design you already trust for wagers.

Most of the crypto sitting in a wallet is doing nothing. It waits. Staking changes that: you put an asset to work securing a network, and the network pays you for it. Until now, doing that meant leaving FairWins for a maze of unfamiliar apps, wrapped tokens, and fine print.

Not anymore. Staking is now live under Finance → Earn → Staking. Pick an asset, see exactly what you’ll earn and what you’ll pay, sign once, and you’re staked — without ever handing your funds to us.

Two ways to stake

We launched with the two staking styles that cover the most ground, each surfaced as its own clearly-labeled option in the Stake list.

Liquid staking keeps you flexible. You stake ETH with Lido and receive wstETH, or stake POL with Polygon’s sPOL and receive sPOL. These liquid staking tokens quietly grow in value as rewards accrue — and because they’re ordinary tokens in your wallet, you can hold them, move them, or swap back to the underlying asset whenever you like. No lock-up to think about for the token itself.

Delegated staking goes straight to the source. You delegate POL to a curated Polygon validator and earn the validator’s rewards directly. We maintain a hand-picked allowlist of reputable, healthy validators — filtered for strong uptime, sensible commission, and a named operator — so you’re choosing from a short, vetted list rather than a sea of unknowns. Delegated positions have an unbonding wait when you exit, and we tell you that up front, every time.

Honesty is the whole point

FairWins has one rule that shapes every screen: never imply something the chain hasn’t actually done. Staking is no exception.

  • You see the real numbers before you sign. Estimated APR, the asset you’ll receive, and — where one applies — the platform fee as its own line item with the exact amount that will actually be staked. No surprises after the fact.
  • You can always get your funds back. Unstaking, withdrawing, and claiming rewards are always available. Nothing we do can trap your position.
  • Unbonding and slashing are stated plainly. Delegated staking carries an unbonding period and, like all delegation, a slashing risk. We put both in front of you rather than burying them.
  • When something isn’t available, we say so. If a network’s staking is temporarily unavailable, you’ll see an honest “not available right now” state — never a broken screen or a guessed rate.

And it’s non-custodial from end to end. You stake from your own wallet, straight to the provider. FairWins never takes custody of your assets between transactions — a stake either completes atomically or reverts and leaves you exactly where you started.

A transparent platform fee that funds the commons

Running a trustworthy financial surface costs something, and we’d rather be honest about how it’s funded than hide it. Liquid staking now carries a small platform fee that flows to the FairWins treasury — the shared pot that keeps the lights on and the platform improving.

Here’s how we’ve kept it fair:

  • It’s disclosed before you sign, always — a clear line showing the rate and the net amount you’ll stake. You are never charged more than the rate you were shown.
  • It applies only to liquid staking. Delegated staking is fee-free. (This isn’t arbitrary: a delegation is bound to your wallet by design, and routing it through a fee layer would have meant taking custody — which we won’t do. So we charge only where we can do it cleanly and atomically.)
  • When the rate is zero, there’s no fee line at all — the experience is byte-for-byte identical to fee-free staking.

The fee lives in the same single, on-chain fee configuration every other FairWins service uses. One source of truth, publicly visible, no hidden second ledger.

Built to be governed — and to be stopped

Behind the friendly Stake button is a new on-chain control surface that makes staking safe to operate at scale.

If a provider is ever compromised, a validator misbehaves, or a contract address comes into question, an authorized responder can pause new staking on that network instantly — no app update, no waiting. Within moments, the Stake area stops offering new positions and shows an honest paused state. Crucially, a pause never touches your exits: unstake, withdraw, and claim keep working the entire time, because those paths never route through our contracts.

Every operator action — pausing, resuming, updating a provider address, curating the validator list — is recorded on-chain as an auditable history of who changed what and when. And these controls are held by a multisig, so no single key can move them. It’s the kind of plumbing you shouldn’t have to think about, precisely because we did.

Woven into the app you already use

Staking isn’t a bolt-on. It’s wired into the surfaces you rely on:

  • Portfolio bottom sheets surface your staked positions and let you act on them in place.
  • Notifications keep you posted on the moments that matter.
  • Your activity log records every stake, unstake, and claim as part of your unified history.
  • Passkey and classic wallets both just work — a passkey stakes in a single confirmation that covers the whole action, spending permission included.

Get started

  1. Open Finance → Earn → Staking.
  2. Pick an option — Lido (ETH), sPOL (POL), or a curated Polygon validator (POL).
  3. Review the terms: estimated APR, what you’ll receive, the unbonding wait if any, and the fee line if one applies.
  4. Enter an amount and confirm. You’re staked.

Your crypto has been sitting still long enough. Put it to work — on your terms, in your custody, with every number on the table.

Staking involves risk, including validator slashing and provider-protocol risk, and rewards are variable and not guaranteed. Availability depends on the network. Always review the terms shown before you stake.

Posted on

Soulbound Memberships, Transferable Vouchers: Splitting a Token in Two

Why FairWins made membership non-transferable, then built a gift-and-resale market on top of it anyway

Responsible use. FairWins wagers are based on publicly available information and legitimate forecasting. Memberships gate access to that activity; they are not a mechanism for circumventing any law. All participants remain fully subject to applicable laws and compliance requirements, and every membership — however acquired — passes sanctions screening.

The gift you can’t give

A FairWins membership is deliberately boring. You pay in USDC — $2 for Bronze, $8 for Silver, $25 for Gold, $100 for Platinum — and for the next 30 days your wallet can create and accept wagers, up to a limit set by your tier. The membership is soulbound, a term for something permanently bound to a single wallet: it lives at your address, it can’t be transferred, and there’s no market for it. That’s a feature, not a limitation. An access record that can move is an access record that can be stolen, rented out to a sanctioned party, or briefly borrowed to sneak past a compliance check.

Then a product request landed: let me buy a membership for a friend. And its sibling: let me resell the one I bought and don’t want. Both are completely reasonable — gift cards and resale markets are table stakes for any paid product — and both are, on their face, impossible. A record welded to your address has nothing to hand over. And making it movable would destroy the very properties the platform relies on: sanctions screening happens when membership is granted, usage limits are tracked per wallet, and the wager engine trusts that the wallet holding a membership is the one that was screened.

The tempting-but-wrong fix is to bolt a “transfer, and re-screen the new owner” button onto the membership itself — turning a fixed access record into a moving target every other part of the system has to special-case. The fix FairWins shipped is cleaner: don’t make the membership transferable. Make the right to claim one transferable, and keep the two ideas in completely separate contracts.

Two rails, one membership

Start with what “soulbound” actually means here. A FairWins membership isn’t an NFT with transfers switched off — it isn’t a token at all. It’s just a record in the platform’s membership ledger, filed under your wallet address: which tier you have, when it expires, and how much of your usage limit you’ve used this month. There’s no “transfer” button to disable because there’s nothing to hand over — non-transferability simply falls out of how the data is shaped.

It’s worth contrasting this with the popular “soulbound token” — a standard for NFTs permanently locked to a wallet but still visible in it. FairWins didn’t need the token part at all: memberships are read by contracts, not shown off in wallets, so a plain ledger entry is simpler, cheaper, and has no transfer machinery to audit.

Buying a membership directly writes that record: it screens the buyer against sanctions lists, pulls the tier’s price in USDC, marks the tier and its expiry, and resets the usage counters. Thirty days later, it lapses.

The new idea adds a second way in that lands on the exact same record. A membership voucher is a real, freely transferable NFT — think of it as a prepaid gift card for a membership — minted for the tier’s normal price. The whole trick is in what a voucher doesn’t do:

  • It grants no membership while you hold it. No clock is running, no usage limits accrue, your wallet has no access.
  • It never expires. A voucher is a bearer claim you can sit on for a year and still redeem into a fresh, full 30-day membership.
  • It locks in its tier and duration at the moment it’s minted. If the team later reprices or retires that tier, the voucher still delivers exactly what it was bought for.

Because the voucher is inert — it confers nothing until redeemed — it is completely safe to trade. Gifting it is an ordinary transfer. Reselling it works on any standard NFT marketplace. The contract even suggests a small resale royalty back to the treasury (2.5% by default, capped in the code at 5% so it can never be cranked higher). None of that touches compliance, because none of it grants anyone access.

Redemption: where the rails converge

A voucher becomes a membership at one moment: redemption. This is the single control point where everything a direct buyer faces gets applied to the person redeeming.

In plain terms, the redemption does this, in order:

  1. Confirm the person redeeming actually owns the voucher.
  2. Confirm they don’t already have an active membership for that role.
  3. Screen them against the sanctions lists — and if they’re listed, stop everything right here.
  4. Write the membership: grant the exact tier and duration the voucher locked in, reset the usage counters, record which terms they agreed to.
  5. Only then, as the very last step, burn the voucher.

The ordering carries the product’s failure semantics. If the redeemer is sanctioned, or already holds an active membership, the entire call is undone and the voucher is left completely untouched — still owned, still tradable. A legitimate buyer is never punished because some previous holder couldn’t redeem, and because the voucher is destroyed only at the very end, any earlier failure rolls the whole thing back safely.

Notice who gets screened: only the person redeeming, and only at the moment of redemption. Minters and resale buyers are deliberately not screened. That’s a conscious trade-off: a sanctioned party could profit by reselling a voucher they never redeem. What they can never do is turn one into actual platform access, because the screen sits exactly where access is granted. Compliance lives at the point of use, not the point of trade.

After redemption, the two routes are indistinguishable. The wager engine reads the same membership record either way and has no idea how it was obtained — and that’s a hard requirement, verified by running the full test suite against both routes.

The economics are deliberately flat

A voucher costs exactly the tier’s normal price — the same amount the direct route charges — so neither path is cheaper and there’s no buy-here-redeem-there arbitrage to game. The money goes to the treasury the moment the voucher is minted, which works because granting the membership later costs the platform essentially nothing, so there’s no need to hold reserves against outstanding vouchers. There are no primary refunds: buyer’s remorse is resolved by reselling or redeeming. And the voucher’s own artwork and description — generated entirely on-chain — literally reads “utility access token, not an investment.”

Buying a batch of vouchers as gifts and sending them straight to a recipient is handled by a small, separate helper, since the voucher itself only mints one at a time. The helper pulls the exact total, mints the batch, and forwards every one to the recipient in a single transaction. It holds no funds at rest and has no admin or withdrawal path. If it isn’t deployed on a given network, buying one at a time still works.

Privacy: pseudonymity, stated plainly

The voucher route has a quiet second use. Because redemption only checks that you own the voucher — never that you minted it — you can move a voucher to a fresh wallet and redeem it there. The resulting membership keeps no back-reference to who bought it or how it changed hands, so your wagering activity isn’t chained on the public ledger to the wallet that originally paid. A gasless version goes further: since redeeming moves no money, a helper service can submit the transaction for you, so even the wallet paying the network fee needn’t be your trading wallet.

FairWins is careful not to oversell this. Voucher mints, transfers, and burns are all public events — anyone can watch a voucher move. What redeeming from a fresh wallet buys you is pseudonymity, not cryptographic unlinkability, and the interface is required to say exactly that.

Design decisions

Changeable logic, frozen asset. The membership ledger can be upgraded in place — the voucher feature itself arrived as one such upgrade — because screening, terms, and grant logic must be able to evolve. The voucher is the opposite: deliberately not upgradeable, because the rules of a tradable, paid-for bearer asset must not change after someone buys it. The thing people pay for stays fixed; the machinery around it can improve.

The membership is a ledger entry, not a locked NFT. No transfer function to disable, no locked-token standard to implement. The only cost is that it’s invisible in your wallet — which doesn’t matter for something only contracts ever read.

Royalty as a hint, not a cage. Forcing royalties would mean whitelisting marketplaces or running our own, killing open trading and the trade privacy that comes with it. A flat, capped suggestion keeps the utility framing honest, accepts that some marketplaces will ignore it, and lets the platform earn reliably on the first sale.

The general pattern travels well. When you need a token to be both non-transferable (for compliance and integrity) and transferable (for gifting and resale), you don’t need one token that does both badly. You need two artifacts — an inert, tradable claim and a soulbound grant — joined by a single, guarded redemption that burns one and writes the other.

Further reading

  • ERC-721, the non-fungible token standard the voucher is built on: https://eips.ethereum.org/EIPS/eip-721
  • EIP-2981, the NFT royalty standard: https://eips.ethereum.org/EIPS/eip-2981
  • EIP-5192, the minimal soulbound (locked) NFT standard discussed above: https://eips.ethereum.org/EIPS/eip-5192
  • OpenZeppelin Contracts, the audited building blocks behind the token and access logic: https://docs.openzeppelin.com/contracts
Posted on

Custody Without a Custodian: Rethinking Safekeeping When Nobody Holds Your Assets

What self-custody actually changes about segregation, insolvency remoteness, and operational responsibility — and how passkey-based smart accounts turn a scary phrase into a controls story

SeriesFinance Professional Series
TrackCustody & Settlement
LevelIntermediate
AudienceTreasury and operations leads, custody and fund-ops specialists, compliance and risk officers, allocators
Tagscustody, self-custody, segregation, insolvency-remoteness, operational-risk, smart-accounts
Reading time~8 minutes

The question a custody review is supposed to answer

Every custody due-diligence checklist, whatever its length, is really trying to answer three questions. Are the assets segregated from the custodian’s own balance sheet? Are they insolvency-remote — safe if the custodian fails? And who bears the operational burden of keys, reconciliation, and access control? A qualified custodian exists precisely so that a professional can answer “yes, yes, them” and move on.

Self-custody breaks that shorthand. There is no third party holding the asset, no omnibus account, no custodial agreement to paper. For a finance professional, the instinct is unease: if nobody is the custodian, who is accountable? The honest answer is that self-custody does not remove the three questions — it relocates them. Segregation becomes structural rather than contractual. Insolvency remoteness becomes near-absolute rather than negotiated. And operational responsibility, which a custodian used to absorb, comes home to the asset owner. Whether that trade is attractive depends entirely on the quality of the controls that replace the custodian. That is the subject worth examining closely.

The traditional model: a custodian as intermediary and shock absorber

In the traditional world, a qualified custodian is both a safekeeping agent and a legal firewall. Client assets are held in segregated accounts, recorded as belonging to the client rather than the custodian, and — where the structure is sound — placed beyond the reach of the custodian’s creditors if it fails. Layered on top are the operational services you are really paying for: reconciliation, access controls, dual authorization, insured vaults, audited processes (often evidenced by a SOC 2 report, an independent attestation of a service organization’s controls), and a claims path when something goes wrong.

Those benefits are real, and so are the frictions. Assets sit inside someone else’s balance sheet and legal perimeter. Segregation is only as good as the paperwork and the jurisdiction’s insolvency law. Access is gated by the custodian’s hours, systems, and risk appetite. And the arrangement introduces the very thing custody is meant to reduce elsewhere — a concentrated counterparty whose failure, freeze, or error becomes your problem. History offers enough examples of client assets caught in a failed intermediary to make the point without belaboring it.

What changes on-chain: the asset never enters a balance sheet

Self-custody on a public blockchain rearranges the picture at the root. A stablecoin such as USDC held in a self-custodial account is recorded on the network as belonging to that account’s address. It is not on FairWins’ balance sheet, not in an omnibus pool, and not subject to any transfer that the account’s own keys do not authorize. Segregation stops being a promise in a custody agreement and becomes a property of where the asset lives: one address, one owner, no commingling by construction.

Insolvency remoteness follows from the same fact. If Chipprbots — the software provider — were to disappear tomorrow, the assets would not be entangled in its estate, because they were never in its possession. There is no omnibus account to unwind, no creditor claim to litigate, no administrator deciding the order of the queue. The network keeps running; the keys keep working. That is a materially stronger form of insolvency remoteness than most custodial structures can offer, and it is worth stating plainly because it is one of the genuine advantages.

What does not vanish is operational responsibility. Someone must hold the keys, control access, and make sure the right people — and only the right people — can move funds. In a custodial model, the custodian’s operations team does this. In self-custody, it is you. This is where most of the traditional custody value actually sat, and it is the part self-custody hands back to the owner. The interesting question is therefore not “is self-custody safer?” but “can the key-management and access controls be made institution-grade?”

Passkey-based smart accounts as a controls story

This is where the account design matters more than the custody label. A FairWins account is not a private key written on paper. It is a small program on the blockchain — a smart account — whose authority to move funds is defined by a list of owners and a set of rules the account itself enforces. The controls a treasurer cares about are expressed in that program rather than in a service-level agreement.

Start with the keys. Each owner can be a passkey — the same hardware-backed, biometric credential (WebAuthn, the standard behind Face ID and fingerprint sign-in) that already protects enterprise logins and payments. The private key is generated inside a tamper-resistant chip, never leaves the device, and will only sign after a biometric check. It cannot be exported, emailed, or pasted into a fake support chat. Compared with a seed phrase on paper — the classic self-custody failure mode — this is a categorical improvement in the operational risk that most worries a controls reviewer: key exfiltration and social engineering.

Now the access model. Ownership of the account is a list, not a single secret. That list can hold more than one credential, and the account refuses to remove its last owner, so it cannot lock itself out. This is the on-chain analogue of controls a treasury team already runs: no single point of failure, redundant signers, and a recovery path that does not depend on one fragile artifact. For higher-value balances, the same building blocks extend to multi-signature arrangements, where several independent approvals are required before funds move — structurally similar to the dual-authorization and quorum controls you would demand of any corporate treasury account, but enforced by code rather than by a bank’s back office.

Two further properties are worth a risk officer’s attention. First, upgrades to the account’s logic can only be authorized by the account’s own owners; the software provider holds no override switch over anyone’s funds. That is what makes this self-custody without scare quotes — nobody but the owner can move or freeze the owner’s assets. Second, because the rules live in an open, auditable program deployed identically across networks, the control environment is inspectable in a way a proprietary custodial black box is not.

Risk and controls: an honest ledger

Self-custody removes custodian counterparty risk and delivers strong segregation and insolvency remoteness. In exchange, it concentrates a different risk set that a professional must own explicitly.

  • Key and access risk. There is no custodian help desk and, for on-chain transfers, no reversal. Passkeys and multi-owner accounts sharply reduce the classic loss modes, but device loss, recovery design, and owner-list governance now sit inside your control framework, not a vendor’s. Recovery must be planned before it is needed, not after.
  • Operational and process risk. Reconciliation, authorization workflows, and segregation of duties do not disappear; they move in-house. The upside is that on-chain balances are continuously and independently verifiable against the public ledger — a stronger reconciliation primitive than a custodial statement — but someone has to run the process.
  • Smart-contract risk. The account is code, and code can carry bugs. FairWins’ mitigation is to build on a widely deployed, professionally audited smart-account design and adopt it unmodified, so external audits keep applying, rather than forking it into something un-reviewed. Reused audited components are a control; bespoke unaudited ones are a risk.
  • Compliance and classification risk. Self-custody does not change your KYC/AML, sanctions-screening, or record-keeping obligations, and the regulatory treatment of custody-technology arrangements varies by jurisdiction and is still evolving. Nothing here substitutes for your own legal and regulatory analysis.

The through-line: self-custody is not the absence of controls. It is a different placement of controls, and passkey-based smart accounts are what make that placement defensible to an institutional reviewer.

How FairWins approaches this

FairWins never takes custody of user funds. Assets sit in self-custodial smart accounts controlled by passkeys, with multi-owner and multi-signature options for higher-value balances, upgrade authority that belongs solely to the account owner, and audited, unmodified account logic underneath. Operational responsibilities that a custodian would traditionally absorb are handed back to the owner deliberately — and the account design exists to make carrying them realistic rather than reckless.

This briefing is educational and informational only. It is not investment, legal, tax, custody, or regulatory advice. Custody arrangements and their regulatory treatment vary by jurisdiction and are evolving; assess your own obligations with qualified advisors before acting.

Related deep-dive

For the engineering details, see Passkey Smart Accounts.

Further reading

Posted on

What “Be Your Own Bank” Actually Means

Self-custody in plain English: what a key is, why “not your keys, not your coins” caught on, and the responsibility that comes with the freedom

SeriesKnowledge Base
TrackWallets & Keys
LevelBeginner
AudienceCurious newcomers who use a bank app but have never held crypto
Tagsself-custody, wallets, keys, security, basics
Reading time~5 minutes

Who holds the vault key?

Think about the money in your bank account. You can see the balance in an app, tap to send some, and trust that it will be there tomorrow. But you are not the one actually holding it. The bank holds it. If you forget your password, the bank can reset it. If someone drains your account, the bank can often claw the money back. That safety net exists because a company sits in the middle, holding your money on your behalf.

That arrangement is called custody — someone else has custody of your funds. It is comfortable and familiar. It also means the bank can freeze your account, decline a payment, or close your access if it decides to.

Crypto offers a different arrangement, and it has a name that sounds bold: self-custody. It means you hold your own money directly, with no company standing in the middle. People sometimes call this “being your own bank.” This primer is about what that really involves — the freedom and the responsibility, honestly.

What self-custody actually is

In crypto, your money lives on a shared public ledger — a giant, tamper-resistant record that thousands of computers keep in sync. Nobody “has” your coins in a drawer. Instead, the ledger says a certain balance belongs to a certain account, and the only way to move that balance is to prove you control the account.

You prove it with a key — think of it as a secret password that also acts as a signature. Whoever holds the key can move the money. There is no manager to appeal to, no “forgot password” button that a company can press for you. The key is the ownership.

That is the whole idea. Self-custody means the key lives with you, not with a company. In older wallets, that key was often shown to you as a list of twelve or twenty-four words — a seed phrase — that you were told to write on paper and never lose. (Newer wallets, including FairWins, replace that with your phone’s built-in security — more on that in the next primer.)

Why people care: “not your keys, not your coins”

You will hear this phrase everywhere in crypto: “not your keys, not your coins.” It is a warning, and it comes from hard experience.

When you leave your crypto on an exchange or app that holds the keys for you, you are trusting that company the same way you trust a bank — except most crypto companies are not banks and have none of a bank’s protections. Several large ones have collapsed or been hacked, and people who thought they “owned” coins there discovered they only owned an IOU that the company could no longer honor.

The phrase means: if you do not personally hold the keys, you do not truly own the coins — you own a promise. Self-custody removes the middleman and the promise. Your money cannot be frozen by a company, cannot vanish in someone else’s bankruptcy, and does not require anyone’s permission to move.

The trade-off, stated honestly

Freedom has a price, and it would be dishonest to skip it: with self-custody, you are responsible for your own keys. There is no support line that can undo a mistake.

  • If you lose the only key and have no backup, the money is gone. Not “frozen pending review” — gone.
  • If someone tricks you into revealing your key or signing something you did not understand, they can take everything, and no one can reverse it.
  • Nobody can help you recover access the way a bank can, precisely because nobody else has your key.

This is not meant to scare you off. Millions of people self-custody safely by doing two simple things: keeping a backup so a single lost device is not the end, and slowing down before approving anything involving money. The rest of this track is about making those two things easy.

How this shows up in FairWins

FairWins is a self-custody app. When you join, an account is created that only you control — the keys never touch a FairWins server, and the company holds no master switch over your funds. That is a deliberate design choice: it is what lets FairWins honestly say your money is yours.

FairWins tries to keep the good part of self-custody (you are in control) while softening the scary part (one mistake ends everything). It does this two ways worth knowing now. First, it uses your phone’s own security hardware instead of a seed phrase you have to write down. Second, it strongly encourages you to add a backup controller — a second way to get into your account — before anything goes wrong, so a lost or broken phone is an inconvenience, not a catastrophe. The app will nudge you until you have one, on purpose.

What to watch out for

  • A backup is not optional. The single most common way people lose self-custodied money is having exactly one way in, then losing it. Set up a backup early, while everything is working.
  • No one legitimate ever needs your key or recovery words. Anyone who asks — “support,” a giveaway, a friend in a hurry — is trying to rob you. Real apps never ask.
  • Read before you approve. Signing a transaction is like signing a check that cannot bounce or be cancelled. FairWins shows you exactly what you are approving before you approve it; take the extra second to look.
  • Self-custody is a responsibility, not a personality test. If you are not ready for it on day one, that is fine — just do not keep more on any app than you would be comfortable managing.

Related deep-dive

Want the engineering details? Read Losing Every Passkey Shouldn’t Mean Losing the Account — how FairWins makes a self-custody account recoverable without bringing back the seed phrase.

Learn more

Posted on

One Action, One Role: RBAC and the Operations Control Plane

How FairWins maps every privileged action to exactly one permission — and makes the operator dashboard prove it

The compliance officer who couldn’t reach her own tool

Picture a compliance officer at a wagering platform. Her job is narrow and serious: when an address needs to be blocked from the protocol, she adds it to a block-list, and the reason is recorded permanently on the blockchain. The system was built for exactly this. She holds one specific permission — the one that lets her edit the block-list — and nothing more. She cannot pause the platform, cannot touch the treasury, cannot freeze anyone’s account.

Then she opens the admin panel, and the block-list tab isn’t there.

This was a real gap FairWins found while auditing its own controls. The permission existed on the blockchain, and her account held it. But the admin dashboard had never been taught that this permission existed, so it hid the block-list behind the top-level “full administrator” permission instead. The underlying security was correct — and completely useless in practice. To do her narrow job, she would have needed to be handed the keys to everything, which is precisely the over-reach the narrow permission was designed to prevent.

The lesson generalizes. Access control isn’t only a smart-contract problem. A permission that exists on-chain but not in the operator’s screen creates quiet pressure to over-grant, and over-granting is how “least privilege” — the principle that every account should hold the minimum power it needs — dies in real life. This post walks through both halves of FairWins’ answer: the on-chain discipline of “one action, one role,” and the admin console built to mirror it, screen by screen.

The permission inventory: one paid role, six operator roles

FairWins is a peer-to-peer wager platform. Smart contracts hold each side’s stake in escrow and settle the bet against a trusted outside source of truth. Its permission model is deliberately small: one permission that members buy, and six that operators hold. All of them use a plain, well-audited access-control library from OpenZeppelin, an industry-standard toolkit for smart contracts — nothing exotic, nothing homegrown.

The paid one lets a member create and accept wagers; members buy it as a time-limited membership tier, and it’s the subject of part 2 in this series. The other six are the operator permissions, and each maps to a single, clearly bounded job:

  • Full administrator — protocol wiring, tier pricing, treasury withdrawals, and handing out or revoking the other permissions.
  • Guardian — can pause and un-pause the whole platform in an emergency. Nothing else.
  • Account moderator — can freeze and unfreeze an individual account. Cannot pause the platform.
  • Membership manager — can grant or revoke memberships directly. Cannot touch admin permissions.
  • Sanctions admin — can edit the compliance block-list. This is the compliance officer’s role.
  • Upgrader — can ship new versions of the upgradeable contracts. Cannot grant itself anything.

A handful of narrower, single-purpose permissions exist for individual subsystems — issuing tokens, setting fees, curating the naming registry — but they follow the exact same pattern, each scoped to one job.

One action, one role

The discipline that holds the whole model together is simple to state: every privileged action is guarded by exactly one permission. Not “admin or guardian.” Not a points system where enough small permissions add up to a big one. One gate per door.

Pausing the platform requires the guardian permission, full stop. Freezing an account requires the account-moderator permission, full stop. Changing pricing or protocol wiring requires the full-administrator permission. There’s one instructive exception that actually proves the rule: swapping out a piece of the wager engine’s code is treated as an upgrade — because it changes what code runs — so it requires the upgrader permission rather than the administrator one. The gate matches the true weight of the action.

The upgrader permission is kept separate from the top administrator permission on purpose. It can later be reassigned to a time-locked multi-signature wallet without changing any code, and the ability to perform future upgrades is wired in permanently, so an upgrade can never accidentally strip away the platform’s own ability to be upgraded again.

The negative space matters as much

FairWins keeps a table of what each role explicitly cannot do, and that table earns its keep. A guardian can stop the whole platform but cannot seize an account. A moderator can freeze an account but cannot pause the platform or move money. A membership manager can hand out memberships but cannot revoke anyone’s admin powers. The compliance officer can block an address and do nothing else. Even the full administrator has hard limits baked into the code: it cannot create wagers on someone’s behalf, cannot decide who wins, and cannot move staked funds — there is simply no button for any of those, because no such function was ever written.

When you design a permission, write its “cannot” list first. It tells you whether the role is genuinely narrow or just labeled that way.

The control plane: permissions flow from the contract to the screen

The operator side is a single admin console, reorganized after that audit into clear groups: a control room, incident response, compliance, membership and revenue, protocol config, identity, access control, and infrastructure.

The core rule of the interface mirrors the core rule of the contracts: each screen is shown only to operators who hold the on-chain permission its actions require, and a group of screens appears only if the operator can actually use at least one screen inside it. The dashboard calculates permissions the exact same way the contracts do and checks them against the live blockchain, so what an operator sees is a faithful picture of what they can actually do.

A guardian signing in sees the control room, incident response, and infrastructure — nothing else. The compliance officer from the opening now sees the control room and compliance. Crucially, the dashboard isn’t enforcing security — the contracts do that, and they can’t be fooled by a hidden or shown button. The dashboard’s job is to make the permission set legible, so nobody is ever tempted to over-grant a big role just to make a screen appear.

One subtlety the console gets right: different permissions live on different contracts, so when an operator grants a permission, the request has to be routed to the specific contract that defines it — not blanket-sent to one place and hoped for the best.

Design decisions

Why a plain, boring access-control library? Standard, audited permission checks are understood by every reviewer and every tool in the ecosystem. The “one action, one role” discipline delivers most of what elaborate custom permission systems promise, without introducing a new thing that can break or be attacked. The cost is granularity: withdrawing fees currently requires the full administrator permission, and splitting out a dedicated “treasurer” would take a contract upgrade — a noted future option, not a quick setting.

Why gate the UI on permissions at all, if the contracts already enforce them? Because the failure mode of a permission-blind dashboard isn’t a break-in — it’s privilege creep. The gap that started this story showed that when the interface doesn’t know about a permission, operators get handed a bigger one to compensate. Modeling every permission in the console is what keeps the on-chain least-privilege design honest in day-to-day operations.

What deliberately stays off the console. Two things are excluded by policy, not by accident. Anything touching the most sensitive keys — the ones that authorize upgrades — stays on offline, air-gapped, scripted paths that never touch a web form. And the optional relay service that can sponsor gasless transactions has no remote admin controls at all, on purpose: an internet-facing kill switch would be a brand-new attack surface, and the relay’s worst case is designed to be “refuses to help,” never “loses funds.” The console shows the state of both, read-only, and links to the written procedures.

Not everything needs a permission. Routine housekeeping — sweeping up expired wagers, settling ones whose outcome is already known — is open to anyone by design, so those screens are open to any operator. And some contracts have no admin controls whatsoever: no permission can drain or redirect their funds because no function to do so exists. The strongest access control is the door you never build.

Further reading

Posted on

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.

Posted on

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

Posted on

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 Gorgoroth
Posted on

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.

Posted on

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