Research

Posted on

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

SeriesKnowledge Base
TrackWallets & Keys
LevelBeginner
AudienceNewcomers who unlock their phone with Face ID and want to know what’s under the hood
Tagspasskeys, 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

Posted on

Sponsored Gas Without a Vendor: How “No Network Fee” Became True

How FairWins made “no network fee” an honest promise — by quietly covering the fee itself, using infrastructure it already ran

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:

  1. A kill switch — one setting halts all sponsorship instantly; clients quietly fall back to paying their own fee.
  2. Sanctions screening — the account is checked against sanctions lists, and it fails closed: if it can’t be screened, it isn’t sponsored.
  3. 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.

Further reading

Posted on

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

SeriesFinance Professional Series
TrackMoney, Yield & Markets
LevelIntermediate
AudienceTreasury and payments leads, product managers, risk and compliance officers, allocators
Tagsstablecoins, 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.

Further reading

Posted on

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.

Further reading

Posted on

What Is DeFi Lending, and Where Does the Yield Come From?

Lending out money you’re not using, without a bank in the middle — and an honest look at what pays the interest

SeriesKnowledge Base
TrackEarning & Yield
LevelBeginner–Intermediate
AudienceCurious beginners who have used a bank app but never DeFi
Tagslending, yield, defi, interest, savings
Reading time~6 minutes

The money that just sits there

Think about the cash in your checking account. Between paydays and payments, some of it just sits there doing nothing. Your bank, quietly, does not let it sit — it lends your deposit to other people (mortgages, car loans, business loans), collects interest from them, and hands you back a sliver of that interest as your “savings rate.” The bank keeps the rest.

That arrangement is centuries old, and it works. But it has a catch: you have to trust the bank completely. You can’t see where your money went, you can’t choose the terms, and the bank is the one deciding how much of the earnings you get to keep.

DeFi lending is the same basic idea — lending out idle money to earn interest — rebuilt so that no single company sits in the middle holding your funds. “DeFi” is short for decentralized finance: financial services that run as open software on a blockchain instead of inside one company’s private computers.

What DeFi lending actually is

In plain terms: DeFi lending lets you lend your idle digital dollars to borrowers directly, through open software, and collect the interest they pay — most of it, not a sliver.

The “digital dollars” here are usually a stablecoin — a crypto token designed to stay worth one real dollar, like USDC. You deposit some stablecoins into a shared lending pool. Borrowers take loans out of that pool and pay interest. That interest flows back to everyone who deposited, in proportion to how much they put in. There’s no bank branch, no loan officer, and no company quietly keeping the difference — the rules are just software that everyone can inspect.

Where the yield actually comes from

This is the most important question to ask about any place that promises to grow your money, so let’s be blunt about it.

The yield comes from borrowers paying interest. That’s it. Someone on the other side wants to borrow those digital dollars and is willing to pay to do it, and that payment is your return. It is not magic, it is not “the blockchain printing money,” and it is not a company subsidizing you out of goodwill.

Why would anyone borrow? Often to trade, to avoid selling an asset they want to keep, or to fund a business — the same reasons people borrow in the ordinary economy. And crucially, in well-built DeFi lending, borrowers must post collateral worth more than they borrow. If someone wants to borrow $1,000, they might lock up $1,500 of another asset first. If they don’t pay it back, that collateral is sold automatically to cover the loan. This “over-collateralization” is what protects the pool — and, indirectly, you.

When you understand that yield is just borrower interest, a useful instinct follows: if a return seems far too high, ask who is paying it and why. A healthy answer names real borrowers paying real rates. A suspicious one can’t.

How it differs from a savings account

A bank savings account and a DeFi lending pool rhyme, but the differences matter:

  • Who holds your money. In a bank, the bank holds it. In DeFi lending, your funds sit in open software you can withdraw from directly — nobody has to approve it for you.
  • Who guarantees it. Bank deposits (up to a limit) are often backed by government insurance. DeFi deposits are not. There is no FDIC here. If something breaks, there’s no agency that makes you whole.
  • How the rate is set. A bank sets your savings rate by policy. A DeFi rate floats with supply and demand — more borrowers means higher rates, fewer means lower. It changes constantly.
  • How much of the earnings you keep. Because there’s no bank keeping the spread, more of the borrower interest reaches you.

That trade is the whole story: you give up the safety net and the hand-holding, and in exchange you get transparency, control, and usually more of the yield. Neither is “better” in the abstract — they’re different deals.

How it shows up in FairWins

FairWins has an Earn section that does exactly this. If you’re holding stablecoins between wagers, you can lend them out through Morpho — a well-established lending protocol — and earn a return over time. The money goes straight from your own wallet into the lending pool; FairWins never holds it, and you can withdraw whenever you like. FairWins charges no fee on Earn, and — as with everything on the platform — you always see the exact cost of any action before you approve it. The estimated rate is shown right on each pool, clearly labeled as an estimate, not a promise.

What to watch out for

  • Yield is never guaranteed. The rate you see is an estimate based on today’s conditions. It will move, and it can fall.
  • There’s no insurance. DeFi lending carries real risks — the software could have a flaw, or extreme market conditions could cause losses. Only lend what you could afford to have at risk.
  • “Too good to be true” usually is. A sky-high rate with no clear borrower paying for it is a red flag, not an opportunity.

Lending idle money to earn interest is one of the oldest ideas in finance. DeFi just lets you do it without handing the keys to a bank — which is powerful, and which is also why the responsibility comes back to you.

Related deep-dive

Want the engineering details? Read Earn Without Surprises: Putting Idle Funds to Work, With a Fee You Can See.

Learn more

Posted on

Sanctions Screening as a Shared Building Block: One Guard, Every Money Path

Why FairWins moved compliance out of the frontend and into a single, fail-closed on-chain gate — and how the same small piece of code protects wagers, pools, memberships, and token issuance

The check that wasn’t there

Picture the code review. Your team ships wallet screening for a peer-to-peer wager platform: when a user connects, the website checks their address against a sanctions list, and if the address is listed, the interface refuses to proceed. The compliance box is ticked. The demo looks great.

A week later, someone on the security review asks the obvious question: what happens if a sanctioned address never opens your website? The contracts live on a public blockchain. Anyone with a script can call them directly, bypassing your site entirely. Your screening layer — the one your Terms of Service describe as a control — turns out to be a polite suggestion.

This is the trap that catches most “compliance-aware” crypto apps. Sanctions exposure under US law is strict liability: it doesn’t matter that you intended to block the address, or that your interface would have blocked it. If your contract accepted money from a listed address, the violation happened. A check that lives only in the website is not a control; it’s theater with good intentions.

FairWins’ answer is to treat sanctions screening the way a careful team treats any core safety check: as a shared building block baked into the contracts themselves. One small, shared piece of code — call it the sanctions guard — is consulted by every entry point on the platform where money moves. The website still checks first, for fast feedback and to avoid wasting anyone’s gas, but the layer that actually enforces is the one nobody can route around.

The guard itself

The guard is deliberately tiny: about a hundred lines, holds no funds, and can’t be upgraded. It combines two lists into a single yes-or-no verdict:

  1. A public sanctions oracle maintained by Chainalysis — an on-chain service that answers, for any address, whether it appears on the US Treasury’s sanctions list.
  2. A discretionary block-list the operator maintains — a simple list for addresses tied to illicit finance beyond the official set, editable only by the holder of the narrow compliance permission described in part 1 of this series.

Consumers get two ways to ask the guard a question. One returns a plain yes-or-no, for callers that want to branch on it — that’s what the website’s advisory check uses. The other simply stops the transaction cold if the address is blocked, which is the form the contracts use, because refusing to let a transaction complete is the cheapest and safest way to make sure a forbidden action never happens.

The block-list editing has one nice property worth calling out: every change records who made it, which address was affected, in which direction, and a human-readable reason — all written permanently to the blockchain. So the block-list’s entire history is a built-in audit trail. There’s no separate off-chain compliance database to subpoena or lose; the on-chain event log is the record. And the keys that can edit those lists follow the platform’s air-gapped, offline signing process, so no change happens casually.

Fail-closed, for real

The interesting engineering is in how the guard talks to the outside sanctions oracle. The naive version — just call the oracle and wrap it in a try/catch — has a sharp edge. If the oracle address is misconfigured, pointing at nothing or at the wrong network, that kind of failure isn’t reliably caught, and the system can silently start treating everyone as clean.

So the guard makes the query in a careful, low-level way that gives it full control over every possible failure: the oracle reverts, runs out of gas, returns nothing, or returns garbage. Anything short of a clean, well-formed “yes” or “no” is treated as the oracle gave no usable answer — and in that case the guard blocks every address. The rule is stated plainly in the platform’s requirements: if the screening source is unavailable, refuse the action rather than allow it unscreened. This is what “fail-closed” means — when in doubt, deny.

There’s exactly one deliberate exception, and it’s a configuration, not a failure. Setting the oracle to “none” means block-list-only enforcement — the intended posture for networks where Chainalysis simply doesn’t operate. Test networks get a stand-in; production gets the real oracle address injected at deployment, never hardcoded. The distinction is precise: a configured but broken oracle blocks everyone, while an intentionally unset oracle blocks only the block-list. Confusing those two states is exactly how fail-closed systems quietly turn fail-open.

One guard, four subsystems

What makes this a reusable building block rather than a one-off feature is that the same guard protects four independent parts of the platform in the same way:

Wagers. Every escrow entry point screens first. Creating a wager screens the creator. Accepting one screens both sides — the person accepting and the original creator — because acceptance is the moment the second stake enters escrow, and the creator might have been added to a sanctions list since they first posted the wager. Screen at every entry, every time.

Memberships. Buying, upgrading, extending, or redeeming a voucher into a membership all screen the person before any USDC moves. Even the admin-only path that grants a membership directly screens the recipient — the guard can’t be bypassed even by operators, so a permission-holder can’t accidentally hand access to a listed address.

Wager pools. Group pools screen creators and joiners through the same guard, with one extra safeguard worth stealing: on production networks the pool factory refuses to run at all if screening is supposed to be on but no guard is configured. The “unset means off” convenience that’s fine on a laptop becomes an impossible, boot-blocking state in production.

Token issuance and naming. Issuing a token screens the issuer and passes the same guard into every token it creates. The naming registry checks the guard before letting anyone claim a name.

Each of these holds its own pointer to the guard, so the guard can be swapped out without touching any of them — and a single block-list update propagates instantly to all four. One list, one place to edit it, one event stream, four enforcement points.

What is deliberately not screened

Here’s the design decision most teams get backwards: the exit paths — claiming a refund, claiming a payout, sweeping up expired wagers — are not screened.

The reasoning matters. If an address is added to the block-list after their stake is already sitting in escrow, screening the exit would permanently trap their funds inside your contract. That turns a screening control into an asset freeze — a much heavier and legally distinct act than simply refusing new business, and one that effectively makes your escrow contract a custodian of blocked property. FairWins draws the line cleanly: a listed address can take no new action that moves value in, but can always recover what’s already theirs. The guard gates entry, never exit.

Trade-offs

A little gas on every entry. Each screened action pays for an extra cross-contract call, plus a second one into the oracle when it’s set. That’s real overhead on the busy path. The team judged it worth it, because the alternative — screening only once, at membership time — leaves a gap: an address listed mid-membership could keep wagering until renewal. Re-screening at every entry closes it.

Trusting an outside oracle. The Chainalysis oracle is a centralized, permissioned data source, and FairWins takes its answers as ground truth. The safeguards are structural rather than trustless: the guard only ever reads from it, it can be swapped out if it’s ever compromised or retired, and the discretionary block-list keeps working even with the oracle unset. This is an honest trade — no decentralized sanctions feed exists, and pretending otherwise helps no one.

Fail-closed can mean downtime. If the oracle ever broke for everyone, every screened entry point would halt until an operator re-pointed or unset it. That’s the accepted cost of failing closed: a brief outage is recoverable; a strict-liability violation is not.

Defense in depth, not defense in one place. The on-chain guard is one layer of several: an edge network geo-gate that blocks restricted regions before a request even reaches the app, the website’s fast advisory check, versioned legal documents, and on-chain records of user consent. The guard is the layer that holds when every other layer is skipped — because on a public blockchain, one of them always can be.

Further reading

Posted on

What Is a Stablecoin?

Why a dollar-shaped digital coin makes real-money apps possible — and how it actually stays worth about a dollar

SeriesKnowledge Base
TrackPayments & Markets
LevelBeginner
AudienceCrypto-curious beginners — no technical background needed
Tagsstablecoins, usdc, payments, how-it-works
Reading time~5 minutes

The price-tag problem

Imagine you agreed to split dinner with a friend, and by the time the bill came, the value of the money in your wallet had jumped or dropped 8%. You’d never know what a fair share was. That is roughly what it feels like to use a typical cryptocurrency — like Bitcoin or Ether — for everyday amounts. The technology is fine; the price just won’t sit still.

For a lot of what crypto promises — sending money to a friend, holding a shared pot, settling a bet — that wobble is a dealbreaker. You want the digital dollar in your app to be worth a dollar tomorrow, the same way the balance in your bank app is. That is exactly the gap a stablecoin fills.

What it is

A stablecoin is a digital coin designed to hold a steady value, almost always one US dollar. It lives on a blockchain — a shared public ledger that many computers keep in sync — so it moves with the speed and openness of crypto, but it’s meant to behave like cash.

The one you’ll meet most often is USDC, issued by a regulated company called Circle. One USDC is intended to always be redeemable for one real US dollar. There are others (USDT, and dollar-pegged coins from various issuers), but USDC is the default across FairWins because it’s transparent and widely trusted.

Think of it as a digital gift card denominated in dollars that you can freely send to anyone, spend, or cash back out — not a lottery ticket whose value swings around.

Why it exists

Money apps need a stable unit. If you escrow a stake, hold a group pot, or pay someone across the world, every party needs to agree on what the amount is. Regular bank dollars can’t travel on a blockchain, and volatile crypto can’t hold a steady price. A stablecoin is the bridge: dollar-priced like your bank balance, but programmable and portable like crypto.

That’s why nearly every serious “real-money” crypto app settles in stablecoins rather than in Bitcoin or Ether. It’s the difference between a bet for “200 dollars” and a bet for “however much this coin happens to be worth on payout day.”

How it stays at about a dollar

A well-run stablecoin like USDC keeps its value through a simple, boring, and reassuring idea: every coin is backed by a real dollar (or a safe dollar-equivalent, like short-term US government debt) held in reserve.

Picture a coat check. For every coat handed in, the attendant issues exactly one ticket. Anyone holding a ticket can always walk up and get a coat back. Because the tickets are always redeemable one-for-one, a ticket is never worth more or less than a coat. USDC works the same way: Circle issues a coin only when a real dollar comes in, and burns the coin when someone cashes out. Reputable issuers publish regular reports from outside accountants confirming the reserves are really there.

That redeemability is what pins the price. If a coin ever drifted to 98 cents on an exchange, traders would happily buy it and redeem it for a full dollar, pocketing the difference — and that buying pressure pushes the price right back to a dollar. The promise of “always worth one real dollar on demand” is the anchor.

How it shows up in FairWins

In FairWins, stablecoins are simply the money. When you place a wager, join a group pool, or send funds to a friend, the amount is denominated and settled in a stablecoin like USDC, so every number you see is a plain dollar amount. Stakes held in escrow are held in stablecoins; payouts arrive in stablecoins. FairWins only ever handles a short, vetted list of these dollar-pegged tokens — not volatile coins — precisely so the amount you agreed to is the amount that changes hands.

Whenever a fee applies, FairWins shows you the exact cost, in dollars, before you approve anything.

What to watch out for

Stablecoins are steadier than other crypto, but “stable” isn’t “risk-free.” A few honest caveats:

  • It’s only as good as its backing. A stablecoin’s promise depends on the issuer actually holding the reserves. This is why the quality of the issuer matters, and why transparent, regulated coins like USDC are preferred over obscure ones.
  • Rare “de-peg” moments. In stressful markets a stablecoin can briefly trade slightly below a dollar. Fully-reserved coins have generally recovered, but it’s a reminder that the peg is maintained, not magic.
  • Avoid the algorithmic kind. Some past “stablecoins” tried to hold their price with clever code and trading tricks instead of real reserves. Several collapsed dramatically. Reserve-backed coins like USDC are a different, sturdier design — but the word “stablecoin” alone doesn’t guarantee safety.
  • You’re moving real money. A stablecoin transfer is final, like handing over cash. Double-check amounts and recipients.

For everyday use inside a well-designed app, though, a reserve-backed stablecoin does exactly what you want: it keeps a dollar looking and acting like a dollar.

Related deep-dive

Want the engineering details? Read The Wager Lifecycle: How a Handshake Bet Becomes a Payout Nobody Can Strand.

Learn more

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.