Chippr Robotics

August 21, 2026July 21, 2026

Censor, Never Steal: Why the Service That Decides Is Never the Service That Signs

How FairWins runs a funded gas wallet on the open internet by splitting one server into two — a bouncer that decides, and an engine that pays

The button that spends someone else’s money

In part 1 of this series we covered the friendly half of gasless transactions: on FairWins, a user with no cryptocurrency for network fees can still act. They sign an instruction — “accept this wager,” “claim my winnings” — with their wallet, off to the side, for free. Someone else then pays the small network fee to actually submit it. That post ended on an uncomfortable word: someone.

Someone has to run a server. That server holds a funded wallet, accepts signed instructions from anyone on the internet, and turns them into paid transactions. Every bad outcome you can picture is on the table: the wallet’s key gets stolen; a bot floods the server until the gas budget is gone; a sanctioned wallet slips an action through; one deliberately expensive transaction burns a week’s budget in a single shot; or the whole thing falls over at 2 a.m. and people are stuck mid-wager.

FairWins had an extra constraint. The platform’s standing rule is no backend — just smart contracts, a static web app, and an indexer that reads the blockchain. This gas-paying server is the one deliberate exception, and being the exception raised the bar: if a server has to exist, its potential for damage has to be small enough to describe in a sentence.

The design that shipped does exactly that. One service decides whether a transaction should exist at all. A completely different service decides how it gets paid for and confirmed. Neither can do the other’s job. The goal, in the team’s own words: the hosted system can only ever censor, never steal.

The split: a bouncer in front, an engine behind

Picture two machines wired together.

The first is the bouncer. It faces the internet, receives each signed instruction, and runs it through a checklist before letting anything through. Is the system paused by its emergency switch? Is this a supported network and action? Who actually signed this — worked out mathematically from the signature itself, never taken on the sender’s word? Have we already processed this exact instruction (no double-submitting)? Does the signer pass a sanctions screen and stay under their rate limit? Would this blow the fee budget? Only an instruction that clears every gate gets packaged up and handed onward.

The second is the engine. It is a well-known open-source piece of infrastructure, run as-is, that does one unglamorous job well: take a fully-formed transaction, pay for it, and get it confirmed on the blockchain — managing the fiddly mechanics of ordering, pricing, retries, and switching to a backup connection if one fails. Crucially, the engine holds the gas wallet’s key. That key lives inside a hardware security module — a tamper-resistant vault that can use the key to sign but can never hand the key out.

Between the two machines is a deliberately tiny opening. The engine receives only a finished transaction: where it’s going, and how fast to push it. It never sees the original instruction, never learns who signed it, and holds no opinions. All the judgment lives in the bouncer; all the mechanics live in the engine.

That narrow seam buys three things. The engine is swappable — it’s off-the-shelf, so it could be replaced without touching a line of policy logic. The engine is auditable by its settings rather than its code — a plain configuration file pins a spending cap per network and, most importantly, a list of the only addresses it is ever allowed to pay. Even if hijacked, it could only ever pay into FairWins’ own contracts. And the policy is testable without touching a real blockchain, because it’s cleanly separated from the machinery.

Status flows back honestly: the engine tells the bouncer when a transaction is genuinely confirmed on-chain, and only then does the app report it as done. The system never guesses or reports success early.

Fail closed where money moves

The most telling item on the checklist is the sanctions screen. The smart contracts already screen everyone — so why screen again? Because the gas wallet pays the network fee before the contract ever gets a chance to reject the transaction, and “we paid to submit a sanctioned wallet’s transaction” is a sentence nobody wants to write. So the bouncer re-checks the true signer against the same on-chain screen.

The rule when that screen can’t give a clear answer is strict: if it says no, reject; if it’s unreachable, also reject — never “assume it’s fine and pay anyway.” This is the instinct across the whole checklist: when money is about to move, refuse rather than guess.

What a total compromise actually buys an attacker

Because of the split, the worst case fits in a small table:

Part	Holds	Can do	Cannot do
Bouncer	two shared passwords	accept or refuse instructions, screen, rate-limit	sign anything, move funds, fake a signer
Engine	the ability to use the gas key	pay for transactions to approved addresses only	exceed the spending cap, pay anyone else, touch user funds
Hardware vault	the actual gas key	produce signatures	ever reveal the key
Gas wallet	a small balance for fees	pay network fees	anything else — it has no special authority

Take over the entire hosted system and here is your whole prize: the small gas balance, plus the power to refuse service for a while. No user funds are reachable — the stakes sit in escrow contracts that independently verify every signature themselves. No administrative power is reachable — the keys that could change the contracts live offline, on physically separate storage, in an entirely different security tier. The blockchain re-checks and re-screens everything regardless of what the server claims. That’s what “censor, never steal” means as an engineering property rather than a slogan.

One checklist, two gasless systems

FairWins actually runs two flavors of gasless transactions, and this is where the split pays off twice.

The first is the one above: signed instructions submitted on a user’s behalf. The second serves the platform’s passkey wallets — accounts you unlock with Face ID or a fingerprint (the same WebAuthn standard your phone already uses for passwordless sign-in). For these, FairWins can sponsor the network fee directly, so the user pays nothing.

Rather than build a second server, the same bouncer simply grew a second door. Sponsoring a fee reuses the same emergency switch, the same sanctions screen, and the same rate limits — plus two extra ceilings that cap what any single sponsored action can cost, so one deliberately expensive request can’t drain the sponsorship fund. One perimeter, one audit trail, one emergency switch, covering two economically different systems. The same checklist has since taken on the platform’s other outside connections too — the collectibles marketplace and the prediction-market trading feature. This bouncer turned out to be the platform’s one reusable piece of backend.

Optional by construction: the never-stranded rule

All of this would still be a liability if people needed it. They don’t. A firm rule holds throughout: every action that can go through the gas-paying server must also complete perfectly well without it, landing exactly the same result on the blockchain — the user just pays their own small network fee.

The app enforces this automatically. Before asking you to sign, it quietly checks whether the server is healthy. If that check fails, the emergency switch is on, the network looks down, or anything goes wrong mid-flow, the app silently routes the very same action through your own wallet as an ordinary paid transaction. Same destination, same result; the only difference is who covered the fee. The sponsored-passkey path behaves the same way — any problem, and the confirmation screen honestly says the user is paying.

Because the worst case is merely “users pay their own fee,” the emergency switch is cheap to pull — which means operators will actually pull it when they should.

Design decisions

Build the judgment, buy the machinery. Transaction ordering, fee pricing, and connection failover are solved problems with sharp edges; a mature open-source engine handles them well. The judgment layer — which contracts, which actions, whose signatures, what limits — encodes FairWins-specific calls no off-the-shelf tool could know. The split puts custom code exactly where the custom decisions are.

Fail closed on money, fail soft on availability. Screening and address-pinning fail closed — the bouncer would rather refuse than guess. Availability fails soft — every refusal degrades to self-pay. The asymmetry is the whole point: the only thing this infrastructure is ever allowed to break is its own usefulness.

Compliance as Code: On-Chain Screening, KYC/AML Programs, and the Travel Rule

What a contract-level sanctions gate can and cannot do — and where it fits inside a real compliance program

Series	Finance Professional Series
Track	Compliance, Disclosure & Governance
Level	Advanced
Audience	Compliance officers, BSA/AML program leads, fintech risk and product managers, general counsel
Tags	`sanctions`, `KYC-AML`, `travel-rule`, `screening`, `controls`
Reading time	~9 minutes

Informational, not advice. This briefing is educational. It is not legal, regulatory, or compliance advice, and it does not describe a regulated money-services program. Sanctions and AML obligations vary by jurisdiction and are evolving; consult qualified counsel for your own facts.

The control that lived in the wrong place

Imagine reviewing a peer-to-peer platform’s compliance posture. On paper it screens users: when a customer connects, the interface checks their wallet address against the sanctions list and refuses to proceed if there’s a hit. The Terms of Service describe this as a control. The screen even renders a tidy “blocked” state. As a compliance reviewer, you ask the question that decides whether this is a control or a decoration: what happens if a sanctioned party never loads your interface?

On a public blockchain, the settlement logic is directly reachable. Anyone with a script can call the contracts without ever touching the website. A screen-only check is a suggestion, not an enforcement point. And US sanctions exposure is effectively strict liability — intent and interface design don’t rescue you if prohibited property was accepted. So the compliance-relevant question is never “does the app screen?” It is “where does enforcement actually bind, and can it be routed around?”

This is the lens for understanding programmatic compliance: pushing a specific, narrow control — sanctions and blocklist screening — down to the layer where value actually moves, so it cannot be bypassed. It is powerful and genuinely useful. It is also frequently oversold. The honest version distinguishes carefully between what address screening does and what a full KYC/AML program does, because they are not substitutes.

The traditional model

In a regulated financial institution, sanctions screening is one component of a broader Bank Secrecy Act / anti-money-laundering (BSA/AML) program. That program rests on several pillars: a written program with board-level ownership; Customer Identification and Customer Due Diligence (CIP/CDD) — you verify who the customer is; ongoing transaction monitoring; sanctions screening of parties and transactions against lists such as OFAC’s Specially Designated Nationals; suspicious-activity reporting; recordkeeping; and independent testing. Screening is the gate; identity verification, monitoring, and reporting are the rest of the house.

Layered on top for value transfers is the FATF travel rule (FATF Recommendation 16). It requires that originator and beneficiary information — names, account identifiers, and often address or identifier details — travel with a qualifying transfer between the institutions on each end. It exists so that the sending and receiving institutions can each screen the counterparty and reconstruct a payment’s parties after the fact. Crucially, the travel rule is an obligation on regulated intermediaries (banks, and, in the crypto context, “virtual asset service providers”). It presumes there is an intermediary who takes custody and holds identity data to pass along.

What changes on-chain

A contract-level screening control collapses the gate into the settlement path itself. Instead of a website consulting a list and asking the system to stop, the settlement logic consults a shared screening component on every entry point where money moves in — and simply refuses to complete a transaction from a listed address. Because the check lives with the money, skipping the interface skips nothing.

Three properties are worth a compliance reader’s attention.

Fail-closed by design. A well-built on-chain gate treats an unavailable or malformed answer from its screening source the same as a hit: it blocks. If the sanctions data source can’t give a clean, well-formed “yes” or “no,” the safe posture is to deny rather than wave everyone through. This is the on-chain analogue of a control that defaults to “hold” when the screening system is down — the opposite of the fail-open behavior that quietly creates exposure.

A built-in, immutable audit trail. The screening source combines a public on-chain sanctions oracle (a service that answers, for any address, whether it appears on the US Treasury list) with a discretionary operator blocklist for addresses tied to illicit finance beyond the official set. Every blocklist change — who made it, which address, in which direction, and a human-readable reason — is written permanently to the chain. There is no separate compliance database to reconcile or lose; the event log is the record. For anyone who has assembled evidence for an exam or a lookback, an immutable, timestamped change history is a real operational advantage.

Gate entry, never exit. A deliberate and defensible line: entry paths (putting value in, creating or accepting a position) are screened; exit paths (claiming a refund or a payout already owed) are not. If an address is listed after its stake is already in escrow, screening the exit would trap those funds — converting a screening control into a de facto asset freeze, a heavier and legally distinct act that would make the contract a custodian of blocked property. Refusing new business is not the same as freezing existing property, and conflating the two is a common design error.

Where it genuinely differs — address screening is not identity KYC

Here is the distinction a compliance professional must hold firmly, because marketing language routinely blurs it.

Address screening answers “is this address on a list?” It does not answer “who is this person?” A contract gate checks a wallet against sanctions and blocklists. It performs no identity verification, no beneficial-ownership analysis, no CDD, no sanctions screening of a name behind the address, and no ongoing behavioral monitoring. A newly created wallet with no listing history passes trivially — it is clean as an address while being completely unknown as a person. Address screening is necessary but nowhere near sufficient for a program that must actually know its customer.

This also reframes the travel rule honestly. The travel rule is about intermediaries exchanging identity data about the parties to a transfer. A non-custodial, peer-to-peer settlement layer where users hold their own keys and the platform never takes custody sits differently from a custodial VASP in most current frameworks — but “differently” is not “exempt,” classification is jurisdiction-specific and unsettled, and regulators are actively extending travel-rule expectations into crypto. The correct posture is not to claim the rule doesn’t apply; it is to recognize that a screening gate does not satisfy the travel rule, because the gate transmits no originator/beneficiary identity information at all. These are different controls addressing different obligations.

Risk & controls

Oracle/data-source risk. The on-chain sanctions oracle is a centralized, permissioned feed taken as ground truth. Mitigations are structural, not trustless: the gate only reads from it, the source can be replaced if compromised or retired, and the operator blocklist keeps working even if the oracle is unset. No decentralized sanctions feed exists; pretending otherwise helps no one.
List-coverage risk. Sanctions lists change; on-chain oracles update on their own cadence; addresses are added faster than any list captures. Screening reduces exposure to known listed addresses. It does nothing about a sanctioned party operating through a fresh, unlisted wallet — the residual risk that only real identity diligence addresses.
Availability vs. exposure. Fail-closed means a screening-source outage can halt entry across the platform until an operator restores or reconfigures it. That downtime is the accepted cost: a recoverable outage beats a strict-liability violation.
Program completeness. The largest risk is treating the gate as the whole program. Address screening is one layer among many a serious operation still needs — jurisdictional geo-controls, versioned legal terms with recorded consent, and, where the activity and jurisdiction require it, actual identity verification and monitoring. Defense in depth, not defense in one place.

How FairWins approaches this

FairWins treats sanctions screening as a shared, fail-closed building block enforced inside the contracts rather than in the interface. A single screening component — the public sanctions oracle plus an operator-maintained, fully audit-logged blocklist — is consulted at every entry point where value moves: creating and accepting wagers (both sides are re-screened at acceptance), buying or extending memberships, joining pools, and issuing tokens. The interface still checks first for fast feedback, but the enforcement layer is the one no one can route around. Exit paths are intentionally never gated, so a mid-position listing can’t strand funds. FairWins is explicit that this is address screening, not identity KYC, and that participants remain fully subject to applicable law — the gate is a genuine control, not a complete compliance program.

Informational, not advice. Nothing here is a determination that any particular activity is or isn’t subject to the travel rule, VASP registration, or any AML obligation. Those are facts-and-jurisdiction questions for qualified counsel.

Related deep-dive

For the engineering details, see Sanctions Screening as a Shared Building Block.

One Signature, Zero Gas: How Gasless Payments Actually Work

How FairWins turned every action into a signed “intent” — you sign what you want, and someone else pays the fee to submit it

The Stranded User

A user wins a wager on FairWins. Fifty USDC sits in escrow with their address recorded as the winner. All they have to do is claim it. One problem: their wallet holds exactly zero of Polygon’s native coin — the token every transaction needs to pay its network fee, its “gas.” They funded their wallet with USDC from an exchange, never touched the native token, and have no intention of learning what a gas station is. Their money is on-chain, provably theirs, and completely out of reach.

The old flow was worse than one stuck action. Just creating a wager took two transactions: a step to authorize the platform to move your stablecoin, then the step that actually creates the wager. Accepting one meant the same dance. Every step needed native gas, and the failure mode was plain: a user who holds only the stablecoin can’t act at all.

The cruelest version is lopsided — a user who scraped together enough gas to place a bet but can’t afford the gas to claim their winnings. Money in, no money out. Any gasless design that fixes deposits but not withdrawals has built a lobster trap.

The fix is to make the entire platform run on signed intents. Instead of sending a transaction and paying the fee, the user signs a message — for free, no gas — describing exactly what they want to do. Anyone can then carry that signed message onto the blockchain and pay the fee to submit it. Crucially, the on-chain effect is always credited to the person who signed it, never to whoever submitted it. One signature replaces the whole authorize-then-act dance, and a helper service — a “relayer” — pays the fee.

What an Intent Actually Is

An intent is a structured, human-readable message the user signs with their wallet, built on EIP-712 — a widely used standard for signable data a wallet can display in plain terms, so you see the actual stake, deadline, and counterparty, not a wall of hex. Every action on the platform has its own intent: create a wager, accept one, claim a payout, declare a draw, buy a membership tier, and so on.

Each intent locks down three things:

Who is acting — a named field that must match whoever actually signed. You can’t sign on someone else’s behalf.
Every detail of the action — stake amounts, deadlines, which wager. Nothing is left blank for the submitter to fill in later.
A replay guard and an expiry — a random one-time code so the same intent can’t be reused, plus a window so a stale intent eventually expires.

Signatures are checked under a fingerprint unique to each contract and each network, so a signed intent is valid on exactly one contract on exactly one blockchain — a one-time code used up on one contract can never be replayed on another. The check also accepts signatures from smart-contract wallets, so FairWins’ passkey wallets can sign intents too. A failed intent never uses up its one-time code; a successful one can never run twice.

Paying With a Signature, Not a Gas Balance

Signing an action is the easy half. The hard half is money-in actions. The intent says “stake 50 USDC” — but the platform still has to pull 50 USDC out of the wallet, which normally needs a separate, gas-paying authorization first.

This is what EIP-3009 is for — a feature built into Circle’s USDC that lets a holder authorize a specific payment purely by signing. The user signs an authorization naming who gets paid, how much, and a validity window; the receiving contract presents that signature to the USDC token, and the transfer happens. No standing “allowance” ever exists, and no separate transaction is needed.

So a money-in intent carries two signatures: the FairWins intent (“accept wager 41”) and the USDC payment authorization (“pay 50 USDC”). Which raises the attack that shapes the whole design: what stops the submitter from mixing and matching? Could they staple your payment authorization to a different action, or pair your accept-intent with a payment meant for something else?

They can’t, because the two signatures are cryptographically stapled together. The intent you sign references the exact payment it’s meant to travel with, and the contract refuses to proceed unless the payment matches — same amount, same one-time code — the one you committed to. The USDC token adds the final lock: the payment can only land in the contract that’s asking. The net result: a submitter can refuse to carry your intent, but can never substitute, redirect, or resize the payment.

Two Twins, Identical Rules

Every gasless action is a twin of an ordinary one. Accepting a wager the normal way and accepting it via a signed intent run the exact same checks against the person acting — sanctions screening, membership gating, ownership, account freezes. The only difference is how the acting identity is established: from the sender on the direct path, from the recovered signature on the intent path. The submitter’s own standing is never consulted, and because both twins run the same underlying action, they can’t quietly drift apart.

Keeping Three Codebases in Perfect Sync

Here’s the lesson most write-ups skip. The exact shape of each intent has to be defined in three separate places: the smart contract that verifies it, the app that helps the user sign it, and the relayer service that handles it.

These three definitions must be byte-identical — not just similar in spirit. The signing standard fingerprints the entire structure, so a single reordered field, or a field’s type written slightly differently, produces a completely different fingerprint and a signature that verifies to a random, wrong address. The failure is silent when you build it and total when a real user tries: every signature rejected, every time.

The discipline FairWins landed on treats the deployed contract as authoritative, and every other copy documents exactly where it matches. New intents ship in all three places at once, with cross-references so no one edits one and forgets the others. It’s unglamorous bookkeeping, and it’s the entire difference between a working gasless system and a flood of mysterious support tickets.

Never Stranded

The final rule is architectural humility: the relayer is optional, and the design has to survive without it. Every gasless flow keeps a pay-your-own-gas fallback — the original path is never removed. The app enforces this at the wiring level: a screen literally can’t ship a gasless-only dead end, because the code refuses to build one. If the relayer is switched off, overloaded, rate-limiting, or timing out, the app quietly falls back to the user paying their own gas, and the on-chain result is identical.

The fallback also covers networks where the signature-based payment simply doesn’t exist — one test network’s stablecoin lacks it entirely, so the app detects the gap before opening the signing prompt and uses the normal path. And status is honest end to end: the interface never shows “confirmed” before a transaction is actually mined. Signed, pending, confirmed, expired, and failed are all distinct, truthful states.

Design Decisions

Random one-time codes, not a counter. Each intent’s replay guard is a random value, usable in any order. A counter would force a user’s actions into strict sequence and let one stuck intent block everything behind it; random codes let someone sign three intents and have them land in any order. Cancellation is precise — a user can kill one specific unsubmitted intent, and even that can be gasless.

Sign everything, trust nothing. Every detail the action uses is inside the signed message. The alternative — signing a compact code that stands for details delivered separately — is fewer bytes but shows the user nothing legible to approve. Human-readable signed data means the wallet displays the real stake, deadline, and counterparty.

Fee recovery is bounded and segregated. An optional second payment authorization lets the platform recover its gas cost in USDC, but it’s capped on-chain, settles in the same transaction as the action, and pays into a segregated account — never the relayer’s own wallet. A compromised relayer gains no power to skim fees.

Censorship is the accepted residual risk. A relayer can decline to submit an intent; it cannot forge, alter, or replay one. And because the pay-your-own-gas path always exists, refusal degrades to mere inconvenience. That trade — accept the possibility of censorship, eliminate any custody of user funds — is the entire design in one sentence.

Note: FairWins wagers are peer-to-peer agreements based on publicly available information and legitimate forecasting. Gasless submission changes who pays the transaction fee, not who is accountable: every intent is credited to its signer, who remains fully subject to applicable law and the platform’s compliance screening.

Enough Signatures Is Not Enough: Adding Real Rules to a Shared Vault

How a small guard contract turns “enough people approved” into “enough people approved, and it obeys the rules” — with no admin key and no way to lock a vault out of its own money

The transaction that had every signature it needed

A three-owner treasury runs a two-of-three multisig: any two owners must approve before money moves. One Tuesday a proposal appears in the queue — send 180,000 USDC to an address nobody recognizes. Owner one approves it from a phone between meetings; the amount looks like the quarterly market-maker payment, and the description says exactly that. Owner two approves an hour later for the same reason. Two approvals: threshold met. The transaction executes. The address belonged to whoever phished owner one and quietly queued the proposal.

Nothing in the multisig failed. That’s the uncomfortable part. A multisig has exactly one control — enough owners agree — and once that bar is cleared, it will send any amount, to any destination, at any time. Everything else teams rely on is procedure: “we review destinations carefully,” “we never approve on mobile,” “big transfers get a phone call first.” Procedures are rules that live in people’s heads, and people approve things between meetings.

Part 1 covered FairWins’ shared vaults: a group holds a multisig with a propose-and-approve queue. This post adds the missing layer — a policy engine that constrains what an already-approved transaction may do, after the threshold is met but before the money moves. The phished proposal above dies at that final step against a per-transaction limit or a recipient allowlist, no matter how many signatures it collected.

The interesting question is where such rules can live so they’re actually binding. Checks inside the app are only advisory — anyone can talk to the multisig directly. A rules service on a company server is just another party you have to trust. The place that actually works is a transaction guard: a contract the multisig itself consults, on-chain, before every execution.

Where the guard sits

A modern Safe multisig can register a guard contract with a veto over every transaction. Just before executing an approved transaction, the Safe hands the guard the full details; if the guard objects, the transaction never runs.

FairWins’ guard is a single shared contract per network: one immutable contract holds the rule settings and running totals for every vault that has opted in, filed under each vault’s address. Because the multisig itself is the one asking, the guard always knows which vault’s rules to apply — no setup handshake needed.

Two properties define the trust model. First, the guard is restriction-only: it can block a transaction but never start, approve, or execute one, and it holds no money. Second, a vault is the only authority over its own rules: changing a vault’s policy is itself a transaction that must clear that vault’s normal approval threshold. There is no owner, no admin role, and the guard is deliberately not upgradeable — an upgrade key over it would be a master backdoor over every vault’s enforcement.

The rules

Version 1 ships the classic treasury controls, each independently switchable per vault:

Per-transaction limit — per asset; no single outgoing transaction may exceed it.
Daily limit — per asset, over a rolling 24-hour window.
Recipient allowlist — outgoing money may only go to pre-approved addresses.
Cooldown — a minimum wait between money-moving transactions.

A transaction “counts” against these limits when it moves value — sending the native coin, or one of the standard token operations the guard recognizes: transfer, transfer-on-behalf-of, and approve. Counting approve matters: approving a spender is a spending grant, and ignoring it would leave an obvious loophole where the vault grants an unlimited allowance and the spender quietly drains it later.

The allowlist has a subtlety worth copying. For token movements it checks the beneficiary — whoever ultimately receives or can pull the tokens — not just the token contract being called. For everything else it checks the direct target, so even a transaction the guard can’t fully interpret still can’t reach an un-approved contract. A locked-down vault genuinely stays locked down.

Closing the escape hatches first

Limits are worthless if a transaction can step outside the accounting entirely. So while any rule is active, the guard flatly rejects two dangerous shapes:

Code that runs inside the vault’s own context. One transaction type lets external code execute with the vault’s full authority — it could move funds without tripping any rule, or even rewrite the guard’s own settings. Refused outright. (The cost is that a certain batching trick isn’t available on rule-governed vaults; since these flows are single-action anyway, nothing is lost.)
Gas-refund transactions. The multisig can be told to reimburse the submitter’s gas out of vault funds — an outflow the limits wouldn’t otherwise see. Refused too.

Both rejections come back as clear, named errors, so the app can explain exactly why something was blocked instead of guessing at a cryptic failure.

You can always loosen the rules

The classic failure mode of on-chain rules is locking yourself in: owners set a cooldown of a year, or turn on an allowlist whose only address is now defunct, and the vault is bricked. The fix is a simple, deliberate carve-out. Two kinds of transaction skip all the spending rules entirely: managing the vault itself (owners, threshold, the guard), and changing the vault’s own policy. Both still require the vault’s normal approval threshold — so the only thing exempt is the collective ability to change the rules.

The result: a too-strict policy can always be loosened by the same group consent that set it, and no vault can ever be locked out by its own rules. This isn’t just asserted — it’s tested against a real multisig deployment, not a stand-in mock.

What you see is what gets enforced

Owners should learn a transaction breaks policy before they spend approvals on it. The guard offers a read-only preview that runs the exact same rule check the real enforcement uses, and the app runs every proposal through it first — so what the interface warns you about can never drift from what the chain enforces. Enforcement itself is careful about ordering: the guard reads and evaluates first, then records the updated totals, and never calls out to another contract, so there’s no room for the reentrancy trickery that plagues contracts that move money.

Rules from the very first transaction

A guard attached after creation leaves a window where early transactions are unpoliced. So FairWins can wire the guard in during vault creation itself: the guard address and starting rules are part of the setup, baked into the vault’s predicted address, and if any part of that setup fails the whole creation is aborted — a half-configured vault can never come into existence. For an existing vault, attachment is ordered so there’s never a moment where the guard is half-on.

Design decisions and accepted limits

Immutable, not upgradeable — on purpose. Elsewhere FairWins leans on upgradeable contracts, but the guard has no upgrade path by design: whoever could swap it out could disable every vault’s enforcement. Improvements ship as a brand-new guard that each vault chooses to adopt through its own approval — consent per vault, never a decision imposed by a single deploy key.

Fixed daily window, not perfectly rolling. A truly continuous rolling window would require storing unbounded transaction history on-chain. The simpler fixed-reset window can, in a worst case straddling a reset, allow up to twice the limit — a small, bounded weakening that’s disclosed in the interface rather than hidden.

Uninterpreted transactions pass the spending limits. The guard values native transfers and the standard token operations; something exotic like a DEX swap passes the spending limits unmeasured. It still faces the allowlist on its target — so a vault that needs a hard lockdown turns on the allowlist and gets one.

Conservative accounting. Totals are recorded before the transaction executes. If the inner action later fails quietly, the spend still counts. Overcounting can only ever restrict, never over-permit — the safe direction to err.

The through-line: every rule that exists is enforced exactly, every gap that exists is named, bounded, and disclosed, and no key anywhere can quietly waive either.

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/

August 11, 2026August 9, 2026

Shared Vaults Where No One Person Can Move the Money

How FairWins lets a group hold a shared treasury and act as the group — using battle-tested multisig wallets, and nothing but the blockchain to coordinate

Note: FairWins wagers are peer-to-peer forecasts on publicly available information. Nothing here changes that: money that moves out of a shared vault passes the same sanctions and membership checks as a personal-wallet action, and everyone involved remains subject to applicable law.

Several People, One Vault, No Server

The Ethereum Classic Cooperative holds its money the way most serious on-chain organizations do: in a multisig — a shared wallet where several people must approve before any money moves. No single keyholder can drain it. If one laptop is stolen or one person goes rogue, the funds are still safe, because a spend needs, say, two of the three owners to sign off.

We wanted groups to do exactly this inside FairWins: hold a shared treasury, then place a wager or send a payment as the group, with a spend only going through once enough co-owners approve. The shared wallet itself was the easy part. We use Safe, the most widely used multisig on Ethereum and its cousins — audited for years, already deployed on the networks we care about. Rolling our own would have been the worst security decision available to us.

The hard part was everything around the wallet. The usual way people coordinate a Safe assumes a hosted server in the middle: it stores proposed transactions, collects approvals, and feeds them to the wallet’s screen. FairWins has a firm rule against exactly this — no company server the app must depend on. The app has to keep working, and members must never be locked out of their own money, even if every piece of FairWins-run infrastructure disappeared tomorrow.

So the real question was: how do the co-owners of a shared vault discover a pending transaction, check that it’s legitimate, approve it, and execute it — using nothing but the blockchain itself? The answer needed surprisingly little new code: one tiny contract that holds no money and has no power.

Why Safe, and Which Version

A “vault” in FairWins is a standard Safe multisig — not a fork, not a wrapper. Vaults you create work with the rest of the Safe ecosystem, and an existing Safe (like the Cooperative’s) can be loaded just by its address.

The version we picked mattered more than we expected. We chose the release whose official contracts sit at the same addresses on every network we support — Ethereum Classic, its Mordor test network, and Polygon. One consistent set of addresses everywhere means far less that can go wrong, and it let us confirm each contract was really deployed by asking the chain directly rather than trusting a list. When those contracts aren’t present on a network, the app honestly says the feature is unavailable. The app also carries no heavyweight Safe software library — the standard toolkit assumes the hosted server we don’t run, and the little we actually need is stable enough to talk to directly.

Approving Without a Middleman

A Safe can authorize a transaction two ways: owners can sign it off-chain and someone gathers the signatures, or each owner can register their approval directly on the blockchain. We use only the second. In plain terms:

Build the exact transaction the group wants to make.
Fingerprint it — reduce it to a unique hash, a short code that stands in for the full transaction and can’t be forged.
Approve — each owner sends a small on-chain transaction that says “I approve the transaction with this fingerprint.” The blockchain itself becomes the record of who has approved.
Execute — once enough approvals exist to meet the threshold, any owner triggers the transaction. The Safe checks the on-chain approvals and runs it.

No signatures are collected off-chain, and the same approval can’t be counted twice. Best of all, this flow can never strand anyone: the vault’s own on-chain state is the coordination, so if FairWins vanished, any standard Safe tool could read those same approvals and finish the job.

The Missing Piece: Knowing What You’re Approving

On-chain approvals create one real gap. When an owner is asked to approve, all the blockchain shows is the fingerprint — a meaningless-looking code that reveals nothing about where the money is going. The full details don’t appear on-chain until the transaction executes, far too late to review.

The hosted server most people run exists largely to fill this gap. Our replacement is a deliberately tiny contract — think of it as a public bulletin board. When someone proposes a transaction, they post its full details there, and everyone else’s app watches for proposals affecting their vault.

The clever part is that the board holds no trust. Each co-owner’s app takes the posted details, re-computes the fingerprint itself, and refuses to approve anything whose details don’t match the fingerprint being claimed. A tampered or spoofed proposal produces a different fingerprint and dies inside the co-owner’s own app; the worst a bad actor can do by posting junk is waste their own transaction fee. The board carries information, never authority.

And because even this contract is optional, there’s a fallback: a proposer can export the full transaction as a signed file and share it as a link or QR code. The co-owner imports it, checks the same fingerprint, and approves — working even on a network where the board was never deployed.

“Operate As the Vault”

A custody tab that only sends simple transfers is just a basic Safe client, not a real integration. The whole point is that a member can become the vault: create a wager staked from the vault’s funds, or pay someone from it, with the action held until the co-owners approve. Originally the app only knew you as your personal connected wallet. Rather than teach every feature about shared vaults, every money-moving action now flows through one shared checkpoint:

Personal mode: send from your own wallet, exactly as before.
Vault mode: assemble the group transaction, post it to the bulletin board, record your own approval — and return a pending proposal, never a completed action.

A persistent banner shows which identity is active, and a pending vault action shows up only in the vault’s own queue — never as a phantom entry in your wager list or payment history until the blockchain confirms it. Implying money moved when it hasn’t is exactly the dishonesty the design refuses.

One honest wrinkle surfaced along the way. Inbound movements — receiving funds, or a refund owed to the vault — need no group approval, since the contract routes that money to the recorded party no matter who asks. But claiming a winning payout is different: the contract insists the winner themselves claim it, so a vault that wins a wager must claim through the normal group-approval path. We documented that as a known exception rather than pretend a single owner could pull the payout alone.

A Socket for Rules

Everything above makes the vault usable; it doesn’t yet make it governable beyond “enough people approved.” A multisig has exactly one control — a set number of owners agree — and once that bar is cleared it will send any amount, anywhere. Safe’s answer is a transaction guard: a contract the Safe consults before executing anything, which can veto a transaction that breaks the rules. This feature ships the wiring so a brand-new vault can be rule-governed from its very first transaction. What those rules look like — spending limits and allowlists enforced at execution time, so even a quorum of compromised signers can’t break them — is the subject of part 2.

Design Decisions

Adopt a proven multisig, don’t build one. Years of audits and a whole ecosystem of compatible tools, for free — and we picked the version whose official addresses match across all three of our networks.
No hosted coordination. On-chain approvals replace the middleman server. Each approval is a small fee-paying transaction; in exchange, the blockchain is the single source of truth and no one can ever be locked out.
A bulletin board that carries data, never trust. Every proposal is re-verified inside each co-owner’s own app, and the signed-file fallback means zero required infrastructure.
Honesty over convenience. Every money-moving flow reroutes through one well-reviewed checkpoint, pending vault actions live only in the vault queue, backups store addresses and labels but never key material, and the vault-won-payout exception is documented rather than papered over.

The lie in the confirm screen

A member creates a FairWins passkey account, receives 40 USDC from a friend, and tries to send 10 of it onward. The confirm screen says “Gasless · sponsored — no network fee.” They tap confirm with their fingerprint. The transfer fails.

Here’s why. Every blockchain transaction costs a small network fee, paid in the chain’s own native token — not in the stablecoin the member actually holds. This account had 40 USDC and zero native token, so there was nothing to pay the fee with, and the transaction was rejected. It’s worse on a member’s very first action, which also has to pay to deploy their account on-chain — so during a busy period even an account holding some native token could come up short.

In other words, the product had promised “sponsored” before the machinery to sponsor anything existed. That broke a standing FairWins principle: the interface must never claim something that isn’t true. There were two ways to fix it — change the words, or make them true. FairWins chose to make them true, with one firm constraint: no third-party sponsorship service. The company already ran the plumbing that submits these gasless transactions and the gateway that screens them, so sponsorship had to be built from those parts.

This post walks through what that took: a deliberately tiny “paymaster” contract, an approval service bolted onto the gateway FairWins already ran, a securely held signing key, and — because nobody may ever be stranded — a fallback that keeps every member able to act even when sponsorship is down.

What sponsoring a fee actually means

The smart-account standard these wallets use lets a transaction name a paymaster: a contract that tells the network, “I’ll cover the fee for this one.” The network then charges the fee to the paymaster’s pre-funded balance instead of the user’s. The entire design question is how the paymaster decides which transactions to pay for.

A verifying paymaster answers that with a signature. An off-chain service looks at each transaction and, if it approves, signs a stamp of approval tied to that exact transaction. The contract’s only on-chain job is to check the stamp is genuine — signed by the one authorized signer — and, if so, cover the fee.

The FairWins paymaster is intentionally minimal: its approval stamp is bound to the specific transaction — its sender, its exact contents, the fee ceiling, the network, the paymaster’s own address, and a short expiry window. Because the stamp is nailed to all of that, an approval can’t be reused on a different transaction, on a different network, or after it expires. And it needs no memory of past transactions: the account’s own built-in transaction counter already makes each one single-use. A contract that checks a signature and stores no state is the simplest and safest kind, and stays portable to other networks later.

The economics are just as simple. The paymaster holds a pre-funded deposit with the network, and that deposit is both the sponsorship pool and the hard cap on how much can ever be lost. When the network runs a sponsored transaction, it draws the fee from that deposit — FairWins paying its own gas back, one transaction at a time, all accounted for on-chain.

The decision half: an approval service on the gateway FairWins already ran

The approval signature has to come from somewhere, and where is the real policy decision. There’s an open standard for exactly this handshake — how a wallet asks a sponsorship service for approval — with two steps: a dummy approval so the wallet can estimate the transaction size, then the real, signed one. Because the FairWins frontend already builds transactions with standard tooling, adopting it made the client-side work nearly free.

Rather than stand up a whole new service, FairWins added a sponsorship route to the gateway that already fronts its other gasless features. That gateway already had the three controls sponsorship needs, and the new route reuses them instead of reinventing them:

A kill switch — one setting halts all sponsorship instantly; clients quietly fall back to paying their own fee.
Sanctions screening — the account is checked against sanctions lists, and it fails closed: if it can’t be screened, it isn’t sponsored.
Quotas — per-account and platform-wide rate limits, so no one account and no single day can drain the pool.

Two extra ceilings are new, because sponsorship spends real money on every transaction: a sanity limit on transaction size and a worst-case cost cap, so a single deliberately expensive transaction can’t burn a big slice of the deposit. Every refusal happens before anything is signed, so a rejected request costs the operator nothing.

That signature comes from a securely managed cloud key service — the gateway never holds the raw signing key. Critically, the gateway refuses to start if its signing key doesn’t match the signer the on-chain contract expects. A mismatch that would otherwise silently break every sponsorship instead fails loudly at deploy time, where someone will notice.

One discipline is worth calling out: the “stamp” being signed is computed in two separate codebases — the contract and the gateway — and they must produce byte-for-byte identical results, or every sponsored transaction fails. A cross-check test deploys the real contract and asserts the two agree.

Never stranded, never dishonest

Sponsorship is a nice-to-have, and the platform rule is that a nice-to-have must never strand a member. So the app treats every failure to get sponsorship — service down, kill switch on, quota hit, screening refusal, network blip — identically: rebuild the transaction to pay its own fee and quietly retry once.

There’s a subtle trap the code is careful about. If a transaction would fail on its own merits — say, sending more than the account holds — that’s not a sponsorship failure and must not be silently retried, because the retry would fail identically and hide the real reason. So the fallback only kicks in for genuine sponsorship or network failures.

The disclosure follows the same honesty rule that created this feature. The system tracks a single fact: was this transaction actually sponsored? The confirm screen renders straight from it — “Gasless — no network fee” when true, “You pay the network fee” when false, including the exact shortfall when the account can’t cover it. The rule that the words must match reality is built into the mechanism, not left to good intentions.

Why we built it this way

Sponsor the fee, don’t charge it in stablecoin. An alternative was a paymaster that quietly takes a little USDC to cover the fee — but that needs price feeds, extra accounting, and an approval step, all for an outcome where the member still pays. Sponsoring is the smallest pattern and the only one that makes “no network fee” literally true.

Self-hosted, eyes open. Refusing outside vendors costs real work — key management, quota design, watching the runway — and buys independence: no vendor lock-in, no per-transaction markup, and every policy decision enforced in FairWins’ own gateway.

A small, bounded blast radius. If the approval-signing key were ever stolen, the thief could approve sponsorships — wasting the deposit on other people’s fees — but could not withdraw a cent: withdrawal is restricted to a separate owner key kept in offline, air-gapped storage. The worst case is capped at the deposit, throttled by quotas, cut off by the kill switch, and cleaned up by rotating to a new signer. Keeping the deposit deliberately small keeps that worst case small by policy, not by hope.

Open to everyone. Sponsorship isn’t reserved for higher membership tiers. Any passkey account that passes screening and stays within quota qualifies — spend is bounded by the ceilings, the pool, and the kill switch, not by narrowing who benefits.

The result: when the confirm screen says “no network fee,” it’s telling the truth — the app quietly covered it — and when it can’t, it says so plainly.

Tokenized Cash as the Unit of Settlement: What a Stablecoin Actually Is on the Books

Stablecoins versus e-money and bank deposits, peg mechanics and reserve attestation, and why an app settles in them — with an honest read on de-peg and issuer risk

Series	Finance Professional Series
Track	Money, Yield & Markets
Level	Intermediate
Audience	Treasury and payments leads, product managers, risk and compliance officers, allocators
Tags	`stablecoins`, `settlement-asset`, `tokenized-cash`, `e-money`, `payments`
Reading time	~8 minutes

Which dollar is it, exactly?

When an app tells you a balance is “200 dollars,” a finance professional’s next question is the right one: a claim on what, held by whom, redeemable how? A bank deposit is an unsecured claim on a commercial bank, insured to a limit, settling through the banking system. E-money is a claim on a licensed issuer that must hold safeguarded funds against it. A money-market fund share is a claim on a pool of short-dated instruments, redeemable at (or very near) par. These are different instruments with different risk, different settlement, and different legal treatment — even though each reads as a dollar on a screen.

A dollar-pegged stablecoin is another such instrument, and the point of this briefing is to place it precisely among the ones you already know: what it structurally resembles, where the analogy breaks, and why an application would choose it as its unit of settlement despite carrying risks a bank deposit does not.

The traditional model: how “cash” settles today

In conventional finance, the settlement asset varies by rail. Retail payments settle across bank deposits and card networks; wholesale settles in central-bank reserves; securities settle delivery-versus-payment through infrastructures that exchange the asset and the cash simultaneously to eliminate principal risk. Each rail has an operator, a settlement window (often T+1 or T+2), business hours, and a legal framework governing finality and reversal.

E-money regimes and money-market funds are the closest reference points for what a stablecoin is trying to be. E-money is prepaid value: you hand a licensed issuer fiat, they issue redeemable digital value one-for-one, and regulation requires the fiat be safeguarded — segregated, held in secure assets — so it is there when you redeem. A money-market fund takes cash, holds short-term government and high-quality paper, and lets you redeem shares at approximately par on demand. Both are “dollar-shaped claims backed by conservative assets, redeemable near par.” Hold that thought.

What changes with a stablecoin

A reserve-backed stablecoin — USDC, issued by the regulated firm Circle, is the most common reference — is tokenized cash: a digital bearer-style instrument on a public blockchain, intended to always be redeemable for one dollar. Structurally it is analogous to e-money backed by a conservative reserve: the issuer creates a coin when a real dollar arrives, holds reserves against outstanding coins (typically cash and short-dated US government debt), and burns the coin on redemption. Reputable issuers publish regular third-party attestations confirming the reserves exist and match supply.

Note the careful word: analogous. A stablecoin is not, by that fact, a regulated e-money instrument or a fund — its legal classification is unsettled and varies by jurisdiction, and this briefing makes no claim of regulatory equivalence. What it shares with those instruments is the structure: a redeemable claim backed by a reserve, whose price is pinned by that redeemability.

The peg mechanics are worth stating plainly, because they are what a risk officer actually underwrites. The anchor is arbitrage against redemption. If the token trades at 99 cents on an exchange while remaining redeemable for a full dollar, arbitrageurs buy the cheap token and redeem it for par, and that buying pressure pushes the market price back toward a dollar. The peg holds because redemption is credible. Which means the peg is exactly as strong as the reserve behind it and the redemption channel in front of it — and no stronger.

Two properties change everything else. First, settlement is near-instant, final, and continuous — no T+2, no business hours, no operator queue. That is a genuine operational upgrade for a payments or escrow application: the moment the transfer confirms, value has moved and cannot be clawed back. Second, it is programmable — it can be escrowed by code, released against conditions, and settled inside an application without a bank in the loop. For a real-money app, those two properties are the entire reason to settle in a stablecoin rather than in a volatile crypto asset (whose price won’t sit still) or in bank rails (which can’t ride the same programmable settlement layer).

Where it genuinely differs

Better. Continuous, near-instant, final settlement; native programmability; global reach without correspondent-banking friction; a transparent, publicly auditable supply. For escrow and cross-border use, these are real advantages over multi-day, business-hours rails.

Worse or different. No deposit insurance and no chargeback: settlement is final the way cash is final, so an error or a payment to the wrong address has no reversal mechanism. You take issuer credit and reserve risk directly — the token is a claim on the issuer’s reserve management, not on an insured bank. And you inherit the peg’s failure mode: it is maintained, not guaranteed.

Risk and controls

Issuer and reserve risk. The token is only as good as the reserve behind it and the issuer running it. Favor issuers with conservative, transparent reserves (cash and short-dated government paper), regular attestations from credible auditors, and clear redemption rights. Treat the attestation cadence and reserve composition as ongoing diligence, not a one-time check. Avoid algorithmic designs that attempt to hold a peg through trading mechanics rather than real reserves — several have collapsed, and the label “stablecoin” alone guarantees nothing.
De-peg risk. In stressed markets a fully-reserved stablecoin can briefly trade below a dollar; the notable historical episodes tied to reserve concentration have generally recovered, but “generally recovered” is not “cannot fail.” Size exposure and concentration accordingly, and monitor the peg the way you would monitor a money-market fund’s shadow price.
Settlement-finality and operational risk. Irreversibility raises the stakes on payment operations: address verification, transaction review, and the custody controls covered elsewhere in this series matter more, not less, than on a reversible rail. There is no back office to unwind a mistake.
Custody and counterparty risk. How the token is held (self-custody versus a third party) reintroduces custody risk on top of issuer risk — two distinct layers to assess separately.
Compliance risk. Transfers are pseudonymous but permanently public. Sanctions screening and applicable AML obligations — including travel-rule considerations where they apply — remain fully in force; the rail’s transparency is a tool here, not an exemption. Regulatory classification of stablecoins is evolving and jurisdiction-specific.

How FairWins approaches this

FairWins uses stablecoins as its unit of settlement precisely for the reasons above: a stake, a group pot, or a payment is denominated and settled in a dollar-pegged token, so every figure a member sees is a plain dollar amount rather than “whatever this coin is worth on payout day.” The platform deliberately handles only a short, vetted list of reserve-backed, dollar-pegged tokens — not volatile assets — so the amount agreed is the amount that changes hands. Escrowed stakes are held in stablecoins and payouts arrive in stablecoins, with the finality that makes a code-held escrow trustworthy: once resolved, the winner can claim and no one can strand the funds. Movements pass the same sanctions and membership checks as any other action, on-chain transparency notwithstanding. And where any fee applies, FairWins discloses the exact cost, in dollars, before a member approves — the settlement asset’s transparency extended to the platform’s own economics. (The core wager escrow itself is denominated and settled in these tokens; it is not a yield product, and no return is implied by holding a stake.)

The honest summary for this reader: a reserve-backed stablecoin is structurally analogous to conservatively-backed tokenized cash, with settlement properties that genuinely beat traditional rails, in exchange for taking issuer, reserve, and finality risk directly and giving up insurance and reversibility. It is the right unit of settlement for a real-money application because of those trade-offs, not in spite of your needing to understand them.

This is educational information for finance professionals, not investment, legal, tax, or regulatory advice. Stablecoins carry issuer, reserve, de-peg, and operational risk; a peg is maintained, not guaranteed, and regulatory treatment varies by jurisdiction and is evolving. Assess any settlement asset against your own risk framework.

Related deep-dive

For the engineering details, see The Wager Lifecycle: How a Handshake Bet Becomes a Payout Nobody Can Strand.

Losing Every Passkey Shouldn’t Mean Losing the Account

How FairWins made passkey accounts recoverable — without bringing back the seed phrase — and folded connecting, controlling, and recovering into one simple screen

The phone in the river

Someone signs up for FairWins with a passkey. No seed phrase, no browser extension — Face ID creates the credential, and a smart-contract account springs from it. The onboarding passkeys always promised: nothing to write down, nothing to lose.

Then the phone goes in the river. Or the browser profile gets wiped, or the laptop dies. Most of the time your phone’s built-in sync (iCloud Keychain, Google Password Manager) has quietly backed the passkey up and you’re fine — but not always. A passkey created in a browser profile that wasn’t syncing is simply gone. With an old-style wallet, recovery was brutal but obvious: retype your twelve words. Passkeys deliberately removed those words. So what’s the recovery story now?

There was a second, quieter problem that made the recovery question moot: even connecting was broken. The app offered three different places to connect, each with different options, and one couldn’t even reach the passkey option. Worse, two real bugs locked passkey users out: on some browsers, signing back in left every transaction crashing, and one browser would silently sign you into your first passkey no matter which account you picked.

The insight was to treat all of this as one thing. Connecting, managing who controls your account, and recovering after a lost device are really the same lifecycle — so they should live behind one door. This post walks through how that works, and why none of it touched the account contracts.

The account already knew how to be recovered

Remember from the previous post: a FairWins passkey account doesn’t have a single owner. It keeps a list of owners, each of which can be a passkey or an ordinary wallet address. They’re equal peers — any one can add or remove the others.

That is the entire recovery mechanism, hiding in plain sight. If a second controller exists when your phone dies, recovery is a single action: that controller adds a fresh passkey. And because a linked ordinary wallet can do this with a plain everyday transaction, recovery needs no special infrastructure — no relayer, no service, nobody’s permission but your own. The account also protects itself: it refuses to remove its last remaining owner, and it only accepts changes from a genuine current owner.

So the real work was never in the contracts. It was in getting people to actually have that second controller before disaster, and making the app honest and reliable enough to use it.

One front door for connecting

The first fix was a single connect screen. Every entry point now opens the same dialog; nothing else renders its own list of choices. The options are ordered passkey first, then WalletConnect, then browser-extension wallets, and the app checks up front whether each is actually available — showing an honest “not detected” or “not supported” instead of failing after you tap.

It also runs only one connection attempt at a time, so a background attempt to restore your previous session can never barge in and override one you started yourself — which is what used to produce those stuck states.

The two bugs that made passkeys unusable

A single front door only helps if the passkey path behind it is solid. Two root-cause fixes shipped alongside it, both app-side bugs against perfectly correct contracts.

The half-saved credential. When you first signed up, the app recorded everything it needed about your passkey. When you later signed back in, it didn’t record the same details — and that missing information was exactly what the transaction machinery needed, causing the crash-on-every-transaction bug. The fix: repair the record on every sign-in, and if it’s still incomplete, catch it early with a clear “please sign in again with your passkey” message instead of letting it explode deep in the signing code later.

The passkey the app didn’t choose. When a browser holds several passkeys and the app makes an unspecific request, some browsers just grab the first one — locking multi-account users into account number one. The fix was to always tell the browser exactly which passkey this session should use, and, when several exist, show the app’s own account picker before the biometric prompt rather than letting the browser guess.

A third, subtler fix falls out of recovery: once an account can gain new controllers, the app can no longer assume your passkey is “owner number one.” It now reads the account’s real owner list on-chain and matches your credential to its actual position — and if your credential isn’t in the list, it stops rather than sign blindly.

Linking before disaster

Recovery depends on having a second controller while you still have passkey access. So the account screen lists every current controller and lets you add a second passkey, link an external wallet, or remove one — each a single biometric approval.

Two honesty rules govern linking. First, the app states plainly that a linked wallet gains full control — equal peers means equal power. Second, every wallet you try to link is screened against sanctions lists before anything goes on-chain, and it fails closed: flagged or impossible to screen means refused. Any account still down to a single controller gets a persistent “link a backup before you lose this device” warning.

Recovery without FairWins

There’s also a wallet-only recovery flow for the worst case: your passkeys are gone, but you linked a wallet earlier. You connect that wallet — no passkey anywhere — and the app walks you through it:

Which account? The blockchain has no “look up my accounts by owner” index, so the app asks for the account address, suggesting ones your browser has previously associated with passkeys.
Prove ownership. The app confirms the address is a real, deployed account, then that your connected wallet really is an owner, before letting you continue.
Create and authorize. You make a fresh passkey on the new device, and your linked wallet sends one ordinary transaction adding it as an owner. Only once that confirms does the app save the new credential — so your very next sign-in can transact.

Because the account is a standard, publicly documented smart contract, this same recovery works with generic, off-the-shelf tools even if FairWins the company vanished. Your funds were never dependent on us being around.

Why we built it this way

No guardians, no social recovery. Recovery is strictly “any controller you linked ahead of time can act.” An account whose only passkey lived on a lost, un-synced device is unrecoverable by design — no one, including FairWins, can help. That’s a hard trade, made on purpose: guardian schemes reintroduce trusted third parties, and phone sync already covers the common case. The answer is gentle pressure to link a backup early, not a custodial safety net that would compromise self-custody.

Equal owners, not thresholds. Every controller is a full peer. That’s simpler to reason about and it’s what makes wallet-only recovery a single transaction — but it means linking a wallet hands over full control, which the app says out loud. People who want “2-of-3”-style shared custody have a separate multisig option.

Recovery restores control, not secrets. The owner list guards your funds, but encrypted private features use a separate master seed. A freshly recovered controller that never held that seed can’t read old encrypted data until the keys are re-shared to it. Getting your funds back and getting your encrypted history back are two different steps, and the app is upfront about that.

A frontend fix for a frontend problem. Fixing both bugs in the app — with clear error messages instead of crashes — kept the audited account contracts untouched.

The result: connecting has one front door, every passkey prompt is pinned to the account you actually chose, and losing every passkey becomes an inconvenience instead of an ending — as long as you linked a backup first. Making sure you did is the app’s whole job.

Passkey Smart Accounts: A Wallet You Open With Your Fingerprint

How FairWins turned Face ID into a real, self-custodial crypto account — no seed phrase, no browser extension, nothing to write down

The twelve words nobody wants to write down

Picture how someone joins a peer-to-peer wager app. A friend sends a link. You have never installed a crypto wallet, you have never copied twelve recovery words onto a scrap of paper, and you are not about to start tonight. What you do have is a phone with a fingerprint sensor and a small, tamper-resistant security chip that has been quietly signing things for you — payments, app logins — for years.

That chip speaks a standard called passkeys — the same WebAuthn technology behind Face ID and fingerprint sign-in on the sites you already use. When you create a passkey, your device generates a private key that it never hands out. It will only prove who you are after a biometric check, and the secret itself never leaves the hardware. That is exactly the security model crypto wallets have chased for a decade: a key that can’t be exported, phished, or pasted into a fake support chat.

There is one stubborn catch. Passkeys and Ethereum accounts speak different mathematical “dialects” for signatures. The security chip in your phone signs using one type of cryptographic curve; ordinary Ethereum accounts expect a different one. They simply don’t recognize each other’s signatures, and no amount of interface polish papers over that. If you want a passkey to control real funds, the account itself has to become a small smart contract — a program on the blockchain — that knows how to read the passkey’s dialect. And something other than the user has to be able to submit that first transaction, because a brand-new passkey can’t pay a network fee from an account that doesn’t exist on-chain yet.

That is the whole idea behind FairWins passkey accounts: a smart-contract wallet controlled by a passkey, able to verify the phone’s signatures directly, living at an address that’s known before the wallet is ever deployed.

An account is a list of owners, not a single key

Rather than build this from scratch, FairWins uses a widely deployed, professionally audited smart-wallet design — Coinbase’s Smart Wallet — and adopts it as-is, without rewriting its logic. The rule is deliberate: an audited contract is only worth something if you don’t quietly fork and change it. Reusing it unmodified means those outside audits still apply.

The clever part of that design is how it defines ownership. An “owner” of the account isn’t one fixed key; it’s simply an entry in a list, and each entry can be one of two things:

a linked ordinary Ethereum wallet address (say, a MetaMask you already have), or
a passkey — represented by the two numbers that make up its public key.

Both kinds sit in the same list and carry equal authority. Any owner can add or remove other owners, and the contract refuses to remove the last one — so an account can never accidentally lock itself out by deleting its only controller. When a signature arrives, the account looks at which owner produced it and checks it the right way: the passkey path for a passkey, the ordinary path for a linked wallet. One mechanism covers both signing in for transactions and approving off-chain messages.

Checking a passkey signature on the blockchain

A passkey signature is more than a scribble over some data. When your device signs, it wraps the thing you’re approving inside a small standardized bundle that also records details like “this was a genuine WebAuthn sign-in” and “a user was present.” To trust that signature, the contract re-runs the important checks from the official WebAuthn specification right on-chain: it confirms the bundle is the expected kind, that the challenge inside it matches what was really being approved, that a user was actually present, and it rejects a known signature-tampering trick. It deliberately skips a few checks that the phone and the app’s site association already enforce — an honest trade that keeps verification affordable.

Then there’s the heavy math of actually verifying the signature, which is expensive to do on a blockchain. Where the network offers a fast built-in helper for exactly this kind of signature, the contract uses it (cheap — a few thousand units of gas). Where a network doesn’t, the same contract quietly falls back to doing the math the slow, pure-software way. Same code, both worlds — which is why supporting a new network later is a configuration change, not a contract rewrite.

An address before there’s an account

Here’s a nice trick that makes onboarding feel instant: your account address exists before the wallet is actually deployed. The address is calculated purely from your initial list of owners, so the app can show it — and a friend can send funds to it — while the contract itself is still just a plan. FairWins deploys the piece that mints these addresses in an identical way on every supported network, so your address is the same everywhere.

Deployment happens lazily, the first time you actually do something. That first action carries a little bundle of setup instructions: the network deploys your account and performs your transaction together, in one shot. (One hard-won lesson from building this: a popular off-the-shelf toolkit assumed a different deployment source than the one FairWins uses, which quietly produced the wrong predicted address and made every early transaction fail. The fix was to pin everything to the exact same source. If you ever wire a custom wallet into a generic toolkit, check its address assumptions first.)

No seed phrase doesn’t mean no keys

Passkeys are great at signing but they don’t encrypt. Some FairWins features — the private ones — need encryption keys too. So the app uses a companion capability of the passkey standard to derive a stable secret from your authenticator, stretch it into an encryption key, and use that to wrap a single master seed. Every owner on the account unwraps the same seed, which is why your encrypted data survives switching devices. If an authenticator doesn’t support this capability, the app says so plainly rather than silently generating the wrong keys.

Why we built it this way

Reuse an audited design, don’t fork it. Using the Coinbase Smart Wallet unmodified keeps its outside security audits meaningful. A private fork would need re-auditing forever.
Upgrades belong to the user. These accounts can be upgraded, but only the account’s own owner can authorize that. FairWins holds no override switch over anyone’s wallet — which is what makes this genuinely self-custodial, not “self-custodial” in scare quotes.
Fast where possible, correct everywhere. Using the network’s built-in signature helper where it exists, and falling back to software elsewhere, costs a bit more on some chains but means one single codebase runs everywhere.
Honest about fees. The confirm screen only says a transaction is sponsored when it truly is; otherwise it says you pay the network fee. (A later post covers how sponsorship works.)

The result is an account you open with a thumbprint, funded at an address that exists before the contract does, and controlled by keys that no server — including ours — ever holds.

The button that spends someone else’s money

The split: a bouncer in front, an engine behind

Fail closed where money moves

What a total compromise actually buys an attacker

One checklist, two gasless systems

Optional by construction: the never-stranded rule

Design decisions

Further reading

The control that lived in the wrong place

The traditional model

What changes on-chain

Where it genuinely differs — address screening is not identity KYC

Risk & controls

How FairWins approaches this

Related deep-dive

Further reading

The Stranded User

What an Intent Actually Is

Paying With a Signature, Not a Gas Balance

Two Twins, Identical Rules

Keeping Three Codebases in Perfect Sync

Never Stranded

Design Decisions

Further reading

The transaction that had every signature it needed

Where the guard sits

The rules

Closing the escape hatches first

You can always loosen the rules

What you see is what gets enforced

Rules from the very first transaction

Design decisions and accepted limits

Further reading

The twelve words nobody wants to write down

What a passkey is

What a smart account is

How the two fit together

How this shows up in FairWins

What to watch out for

Related deep-dive

Learn more

Several People, One Vault, No Server

Why Safe, and Which Version

Approving Without a Middleman

The Missing Piece: Knowing What You’re Approving

“Operate As the Vault”

A Socket for Rules

Design Decisions

Further reading

The lie in the confirm screen

What sponsoring a fee actually means

The decision half: an approval service on the gateway FairWins already ran

Never stranded, never dishonest

Why we built it this way

Further reading

Which dollar is it, exactly?

The traditional model: how “cash” settles today

What changes with a stablecoin

Where it genuinely differs

Risk and controls

How FairWins approaches this

Related deep-dive

Further reading

The phone in the river

The account already knew how to be recovered

One front door for connecting

The two bugs that made passkeys unusable

Linking before disaster

Recovery without FairWins

Why we built it this way

Further reading

The twelve words nobody wants to write down

An account is a list of owners, not a single key

Checking a passkey signature on the blockchain

An address before there’s an account

No seed phrase doesn’t mean no keys

Why we built it this way

Further reading