Tag: web3

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

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

Put Your Idle Crypto to Work: Staking Comes to FairWins

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

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

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

Two ways to stake

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

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

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

Honesty is the whole point

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

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

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

A transparent platform fee that funds the commons

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

Here’s how we’ve kept it fair:

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

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

Built to be governed — and to be stopped

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

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

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

Woven into the app you already use

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

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

Get started

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

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

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

Posted on

Soulbound Memberships, Transferable Vouchers: Splitting a Token in Two

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

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

The gift you can’t give

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

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

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

Two rails, one membership

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

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

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

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

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

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

Redemption: where the rails converge

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

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

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

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

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

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

The economics are deliberately flat

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

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

Privacy: pseudonymity, stated plainly

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

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

Design decisions

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

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

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

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

Further reading

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

What “Be Your Own Bank” Actually Means

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

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

Who holds the vault key?

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

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

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

What self-custody actually is

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

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

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

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

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

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

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

The trade-off, stated honestly

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

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

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

How this shows up in FairWins

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

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

What to watch out for

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

Related deep-dive

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

Learn more

Posted on

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

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

The compliance officer who couldn’t reach her own tool

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

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

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

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

The permission inventory: one paid role, six operator roles

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

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

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

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

One action, one role

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

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

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

The negative space matters as much

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

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

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

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

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

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

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

Design decisions

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

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

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

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

Further reading