The Wager Lifecycle: How a Handshake Bet Becomes a Payout Nobody Can Strand
What Is Escrow and How Can Code Hold the Money “Trustlessly”?
One Address, Everywhere: Why Deterministic Deployment Matters
What Is Sanctions Screening? (And Why an App Checks Your Wallet)
One Contract, Two Halves: Beating a Hard Size Limit Without Moving House
What Are Spending Guardrails?
Renovating a Contract Without Changing Its Address
Compliance as Code: On-Chain Screening, KYC/AML Programs, and the Travel Rule
What a contract-level sanctions gate can and cannot do — and where it fits inside a real compliance program
| Series | Finance Professional Series |
| Track | Compliance, Disclosure & Governance |
| Level | Advanced |
| Audience | Compliance officers, BSA/AML program leads, fintech risk and product managers, general counsel |
| Tags | sanctions, KYC-AML, travel-rule, screening, controls |
| Reading time | ~9 minutes |
Informational, not advice. This briefing is educational. It is not legal, regulatory, or compliance advice, and it does not describe a regulated money-services program. Sanctions and AML obligations vary by jurisdiction and are evolving; consult qualified counsel for your own facts.
The control that lived in the wrong place
Imagine reviewing a peer-to-peer platform’s compliance posture. On paper it screens users: when a customer connects, the interface checks their wallet address against the sanctions list and refuses to proceed if there’s a hit. The Terms of Service describe this as a control. The screen even renders a tidy “blocked” state. As a compliance reviewer, you ask the question that decides whether this is a control or a decoration: what happens if a sanctioned party never loads your interface?
On a public blockchain, the settlement logic is directly reachable. Anyone with a script can call the contracts without ever touching the website. A screen-only check is a suggestion, not an enforcement point. And US sanctions exposure is effectively strict liability — intent and interface design don’t rescue you if prohibited property was accepted. So the compliance-relevant question is never “does the app screen?” It is “where does enforcement actually bind, and can it be routed around?”
This is the lens for understanding programmatic compliance: pushing a specific, narrow control — sanctions and blocklist screening — down to the layer where value actually moves, so it cannot be bypassed. It is powerful and genuinely useful. It is also frequently oversold. The honest version distinguishes carefully between what address screening does and what a full KYC/AML program does, because they are not substitutes.
The traditional model
In a regulated financial institution, sanctions screening is one component of a broader Bank Secrecy Act / anti-money-laundering (BSA/AML) program. That program rests on several pillars: a written program with board-level ownership; Customer Identification and Customer Due Diligence (CIP/CDD) — you verify who the customer is; ongoing transaction monitoring; sanctions screening of parties and transactions against lists such as OFAC’s Specially Designated Nationals; suspicious-activity reporting; recordkeeping; and independent testing. Screening is the gate; identity verification, monitoring, and reporting are the rest of the house.
Layered on top for value transfers is the FATF travel rule (FATF Recommendation 16). It requires that originator and beneficiary information — names, account identifiers, and often address or identifier details — travel with a qualifying transfer between the institutions on each end. It exists so that the sending and receiving institutions can each screen the counterparty and reconstruct a payment’s parties after the fact. Crucially, the travel rule is an obligation on regulated intermediaries (banks, and, in the crypto context, “virtual asset service providers”). It presumes there is an intermediary who takes custody and holds identity data to pass along.
What changes on-chain
A contract-level screening control collapses the gate into the settlement path itself. Instead of a website consulting a list and asking the system to stop, the settlement logic consults a shared screening component on every entry point where money moves in — and simply refuses to complete a transaction from a listed address. Because the check lives with the money, skipping the interface skips nothing.
Three properties are worth a compliance reader’s attention.
Fail-closed by design. A well-built on-chain gate treats an unavailable or malformed answer from its screening source the same as a hit: it blocks. If the sanctions data source can’t give a clean, well-formed “yes” or “no,” the safe posture is to deny rather than wave everyone through. This is the on-chain analogue of a control that defaults to “hold” when the screening system is down — the opposite of the fail-open behavior that quietly creates exposure.
A built-in, immutable audit trail. The screening source combines a public on-chain sanctions oracle (a service that answers, for any address, whether it appears on the US Treasury list) with a discretionary operator blocklist for addresses tied to illicit finance beyond the official set. Every blocklist change — who made it, which address, in which direction, and a human-readable reason — is written permanently to the chain. There is no separate compliance database to reconcile or lose; the event log is the record. For anyone who has assembled evidence for an exam or a lookback, an immutable, timestamped change history is a real operational advantage.
Gate entry, never exit. A deliberate and defensible line: entry paths (putting value in, creating or accepting a position) are screened; exit paths (claiming a refund or a payout already owed) are not. If an address is listed after its stake is already in escrow, screening the exit would trap those funds — converting a screening control into a de facto asset freeze, a heavier and legally distinct act that would make the contract a custodian of blocked property. Refusing new business is not the same as freezing existing property, and conflating the two is a common design error.
Where it genuinely differs — address screening is not identity KYC
Here is the distinction a compliance professional must hold firmly, because marketing language routinely blurs it.
Address screening answers “is this address on a list?” It does not answer “who is this person?” A contract gate checks a wallet against sanctions and blocklists. It performs no identity verification, no beneficial-ownership analysis, no CDD, no sanctions screening of a name behind the address, and no ongoing behavioral monitoring. A newly created wallet with no listing history passes trivially — it is clean as an address while being completely unknown as a person. Address screening is necessary but nowhere near sufficient for a program that must actually know its customer.
This also reframes the travel rule honestly. The travel rule is about intermediaries exchanging identity data about the parties to a transfer. A non-custodial, peer-to-peer settlement layer where users hold their own keys and the platform never takes custody sits differently from a custodial VASP in most current frameworks — but “differently” is not “exempt,” classification is jurisdiction-specific and unsettled, and regulators are actively extending travel-rule expectations into crypto. The correct posture is not to claim the rule doesn’t apply; it is to recognize that a screening gate does not satisfy the travel rule, because the gate transmits no originator/beneficiary identity information at all. These are different controls addressing different obligations.
Risk & controls
- Oracle/data-source risk. The on-chain sanctions oracle is a centralized, permissioned feed taken as ground truth. Mitigations are structural, not trustless: the gate only reads from it, the source can be replaced if compromised or retired, and the operator blocklist keeps working even if the oracle is unset. No decentralized sanctions feed exists; pretending otherwise helps no one.
- List-coverage risk. Sanctions lists change; on-chain oracles update on their own cadence; addresses are added faster than any list captures. Screening reduces exposure to known listed addresses. It does nothing about a sanctioned party operating through a fresh, unlisted wallet — the residual risk that only real identity diligence addresses.
- Availability vs. exposure. Fail-closed means a screening-source outage can halt entry across the platform until an operator restores or reconfigures it. That downtime is the accepted cost: a recoverable outage beats a strict-liability violation.
- Program completeness. The largest risk is treating the gate as the whole program. Address screening is one layer among many a serious operation still needs — jurisdictional geo-controls, versioned legal terms with recorded consent, and, where the activity and jurisdiction require it, actual identity verification and monitoring. Defense in depth, not defense in one place.
How FairWins approaches this
FairWins treats sanctions screening as a shared, fail-closed building block enforced inside the contracts rather than in the interface. A single screening component — the public sanctions oracle plus an operator-maintained, fully audit-logged blocklist — is consulted at every entry point where value moves: creating and accepting wagers (both sides are re-screened at acceptance), buying or extending memberships, joining pools, and issuing tokens. The interface still checks first for fast feedback, but the enforcement layer is the one no one can route around. Exit paths are intentionally never gated, so a mid-position listing can’t strand funds. FairWins is explicit that this is address screening, not identity KYC, and that participants remain fully subject to applicable law — the gate is a genuine control, not a complete compliance program.
Informational, not advice. Nothing here is a determination that any particular activity is or isn’t subject to the travel rule, VASP registration, or any AML obligation. Those are facts-and-jurisdiction questions for qualified counsel.
Related deep-dive
For the engineering details, see Sanctions Screening as a Shared Building Block.
Further reading
- FATF Recommendations and the travel rule (Recommendation 16): https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html
- FATF guidance on virtual assets and VASPs: https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html
- US Treasury OFAC sanctions programs and the SDN List: https://ofac.treasury.gov/sanctions-list-service
- FFIEC BSA/AML Examination Manual (program pillars, CDD, sanctions): https://bsaaml.ffiec.gov/manual
- Investopedia, “Know Your Client (KYC)”: https://www.investopedia.com/terms/k/knowyourclient.asp
Passkeys and Smart Accounts: A Wallet With No Password to Write Down
What a passkey is, what a “smart-contract wallet” means, and why together they let you have a real crypto account without ever seeing a seed phrase
| Series | Knowledge Base |
| Track | Wallets & Keys |
| Level | Beginner |
| Audience | Newcomers who unlock their phone with Face ID and want to know what’s under the hood |
| Tags | passkeys, smart-accounts, webauthn, wallets, basics |
| Reading time | ~6 minutes |
The twelve words nobody wants to write down
If you have tried a crypto wallet before, you may remember the moment it handed you twelve random words and told you, sternly, to write them on paper and never lose them, never photograph them, never type them anywhere. That list — called a seed phrase — is the master key to the account. Lose it and your money is gone; let someone see it and they can take everything.
For most normal people, that is where crypto ends. Guarding twelve words like a launch code is nobody’s idea of a fun Tuesday night.
Here is the good news: you almost certainly already use a better system every day, and you probably do not even think of it as security. It is the fingerprint or face scan that unlocks your phone and signs you into apps. This primer explains that system — called passkeys — and the second piece that lets it control real money: a smart account.
What a passkey is
A passkey is a login credential built into your device that you unlock with your face or fingerprint instead of a password. It is the everyday name for a technology called WebAuthn, the same standard behind Face ID sign-in and fingerprint logins on banking and shopping sites you already trust.
Here is the part that makes it powerful. When you create a passkey, your phone generates a secret key and stores it inside a tiny, tamper-resistant security chip. That secret never leaves the chip — not to the app, not to a server, not even to you. When something needs approval, the chip proves it is you (after your face or fingerprint check) without ever revealing the secret itself.
Compare that to a seed phrase or a password, which you can be tricked into typing into a fake website or reading aloud to a scammer posing as support. A passkey has nothing to type and nothing to hand over — there is simply no secret sitting around for a thief to phish. That is exactly the security property crypto wallets have wanted for years.
What a smart account is
So passkeys are a great way to prove it is you. But there is a catch when you try to point one at a crypto account.
An ordinary crypto account is basically a single key and nothing else — a plain lockbox with one lock. It expects signatures written in one specific mathematical “handwriting.” Your phone’s security chip signs in a different handwriting. The two do not recognize each other, so a passkey cannot directly open an old-style account.
The fix is to make the account itself a little smarter. Instead of a plain lockbox, your account becomes a small program that lives on the blockchain — a smart account (you may also hear “smart-contract wallet” or “account abstraction”). Because it is a program, it can be taught to read your passkey’s handwriting and check your phone’s signatures directly.
That upgrade quietly unlocks conveniences a plain account never could:
- No seed phrase. Your face or fingerprint is the key. There is nothing to write on paper.
- More than one way in. A smart account keeps a list of approved controllers, not a single fixed key. You can add a second passkey on your tablet, or link an existing wallet as a backup — any of them can get you in.
- It can protect itself. Because it is a program, the account can enforce its own rules — for example, refusing to remove its very last controller so you cannot accidentally lock yourself out forever.
Think of an old account as a padlock, and a smart account as a small, programmable door with a guest list you can update as your life changes.
How the two fit together
Put them side by side and the experience clicks. The passkey is who you are — proven by your face or fingerprint, backed by a secret that never leaves your phone. The smart account is where your money lives — a program on the blockchain that recognizes that passkey and follows rules you can trust. You unlock it the same way you unlock your phone: the account confirms the approval came from a passkey on its guest list, and only then does anything move. No password, no seed phrase, no browser extension.
How this shows up in FairWins
When you join FairWins, this is exactly what happens — usually in a few seconds and without you thinking about any of it. Your face or fingerprint creates a passkey, and a smart account is set up that recognizes it. There is no twelve-word phrase to record, because there isn’t one.
FairWins leans on the smart account’s guest-list design in a friendly, practical way. It encourages you to add a backup controller — a second passkey or a linked wallet — so that if your phone is lost or broken, another approved device can still get you in. Adding one is a single face or fingerprint approval. And when you link something as a backup, the app tells you plainly that a backup controller has full control of the account, because on the guest list everyone is an equal peer.
What to watch out for
- A passkey is only as safe as your device’s backup. Most phones automatically sync passkeys to your cloud account (iCloud Keychain, Google Password Manager), so a new phone restores them. But a passkey made in a browser profile that wasn’t syncing can be genuinely lost — which is exactly why adding a second controller in the app matters.
- “No seed phrase” is not “no responsibility.” You still hold your own account. The responsibility shifted from guarding a paper phrase to keeping a backup way in. Do that early.
- Anyone with a controller has full power. Only link a wallet or add a passkey you actually trust and control. The app says so, and means it.
- Your face and fingerprint never leave your phone. The biometric check happens on your device to unlock the passkey; FairWins never sees it.
Related deep-dive
Want the engineering details? Read Passkey Smart Accounts: A Wallet You Open With Your Fingerprint — how FairWins turned Face ID into a real, self-custodial account with no seed phrase.
Learn more
- What passkeys are, in plain terms (FIDO Alliance): https://fidoalliance.org/passkeys/
- Passkeys / WebAuthn overview (Ethereum.org): https://ethereum.org/en/wallets/
- Account abstraction, explained (Ethereum.org): https://ethereum.org/en/roadmap/account-abstraction/