Live rates
USDC → EURC0.9214 +0.18%
USDC → XSGD1.3408 -0.04%
USDC → BRLA4.9721 +0.42%
XSGD → TGBP0.5812 +0.15%
USDC → EURC0.9214 +0.18%
USDC → BRLA4.9721 +0.42%
USDC → XSGD1.3408 -0.04%
EURC → GBPA0.8403 -0.22%
USDC → MXNB19.94 +0.31%
USDC → KRWO1,384 -0.07%
USDC → JPYC152.41 +0.14%
USDC → NZDD1.6720 -0.08%
USDC → CCHF0.8812 +0.05%
USDC → CADC1.3712 -0.12%
USDC → EURC0.9214 +0.18%
USDC → XSGD1.3408 -0.04%
USDC → BRLA4.9721 +0.42%
XSGD → TGBP0.5812 +0.15%
USDC → EURC0.9214 +0.18%
USDC → BRLA4.9721 +0.42%
USDC → XSGD1.3408 -0.04%
EURC → GBPA0.8403 -0.22%
USDC → MXNB19.94 +0.31%
USDC → KRWO1,384 -0.07%
USDC → JPYC152.41 +0.14%
USDC → NZDD1.6720 -0.08%
USDC → CCHF0.8812 +0.05%
USDC → CADC1.3712 -0.12%
Compliance · For Institutional Liquidity Providers

Compliant by design.
Custody-free by construction.

Sera enforces sanctions screening, illicit-flow filtering, and counterparty risk controls at the protocol layer — without ever taking custody of user funds. This page documents the framework institutional liquidity providers, treasury desks, and regulated counterparties rely on when routing through Sera.

Custody modelNon-custodial
Smart-contract auditCertiK · live monitor
Screening cadenceContinuous · pre & intra-trade
Last reviewed28 April 2026
Regulatory posture · please read

Sera operates as an unlicensed, non-custodial protocol.

Sera is not a licensed money services business, money transmitter, virtual-asset service provider, broker-dealer, or financial institution in any jurisdiction. The protocol is a set of audited smart contracts paired with off-chain quoting and routing infrastructure. Counterparties are responsible for their own regulatory posture, including any licensing, registration, KYC, source-of-funds, tax, and reporting obligations that apply to their activities.

This page describes the voluntary compliance controls Sera operates at the application and contract layer to keep sanctioned actors and illicit flows out of the routing graph. These controls are not a substitute for the licensing stack a counterparty's own activities may require, and Sera makes no representation that use of the protocol satisfies any specific regulatory requirement that applies to a counterparty.

§ 01 · Compliance Architecture

Screening lives at the contract, not the front end.

Every address that interacts with Sera passes a compliance gate before any route is built or any quote is bound. Non-compliant addresses are rejected at the contract level — not just hidden in the UI.

AddressComplianceChecksGet Rate forSwap or SendSwapperContractCheck availableLiquiditySignedtransaction dataNon-compliant addresses are rejected at the contract levelSWAP & SENDEXECUTIONMARKETPLACE · LIMIT ORDERSETTLEMENT
01 / 03PRE-TRADE

Address screening before quote.

Every connecting address is evaluated against the blocklist before any route is built. Sanctioned, mixer-linked, and high-risk addresses never receive a binding quote.

02 / 03INTRA-TRADE

Continuous re-evaluation.

Wallets are re-screened on a continuous cadence, not only at first connect. If an address is flagged after onboarding, access is revoked at the next interaction.

03 / 03CONTRACT-LAYER

Enforced at the contract.

The blocklist is enforced at the swap and intent contracts, not only the front end. Bypassing the UI does not bypass the screen.

§ 02 · Wallet Screening · KYT & KYA

Two layers of screening, continuously.

Sera operates Know Your Transaction (KYT) and Know Your Address (KYA) screening across every interacting wallet, sourced from industry-leading on-chain analytics partners. Coverage spans direct exposure, indirect exposure, and continuously updated real-world entity attribution.

KYT · Know Your Transaction
Real-time monitoring of every interaction.
Each transaction routing through Sera is evaluated in real time against high-risk typologies — sanctions exposure, mixer interaction, ransomware, and illicit-flow patterns. Alerts surface within seconds of an on-chain event, with severity tiers driving automated action at the contract layer.
KYA · Know Your Address
Wallet-level risk scoring before connect.
Every connecting address is scored against direct and indirect exposure to the typology categories below, going as many hops back as needed until an attributed service is hit. Risk scores update continuously as the analytics layer learns new attributions and clusters.
Category 01
Sanctions exposure

Multi-list, multi-jurisdiction sanctions coverage — U.S. Treasury OFAC SDN, EU consolidated, UN, UK HMT, plus addresses linked to sanctioned states (Russia, Iran, DPRK, Cuba, Syria) and OFAC-50% rule beneficial-ownership clusters.

Category 02
Mixers and tumbling services

Custodial and non-custodial mixers, privacy pools, chain-hopping bridges used as obfuscation primitives, and any service whose attributed purpose is to break the on-chain trail between source and destination.

Category 03
Hack, exploit & ransomware proceeds

Wallets receiving funds traceable to public exchange hacks, bridge exploits, smart-contract drains, ransomware payouts, and wallets attributed to the ransomware affiliate ecosystem within the analytics provider's tracing window.

Category 04
Darknet markets

Vendor wallets, market admin wallets, cash-out clusters, and wallets with material indirect exposure to active or recently shuttered darknet markets across all major chains.

Category 05
Fraud, scams & phishing

Rug-pulls, romance scams, investment-scam clusters, phishing drainers, fraud shops, and addresses attributed to organised scam networks. Both direct and indirect exposure are scored.

Category 06
Terrorism financing

Wallets attributed to designated terrorist organisations, fundraising wallets associated with violent-extremism actors, and clusters surfaced by the analytics provider's terrorism-financing typology.

Category 07
Child sexual abuse material

Wallets attributed to CSAM vendors and distribution clusters. Coverage is treated as zero-tolerance — any direct or material indirect exposure results in immediate, permanent denial of access.

Category 08
High-risk exchanges & unregistered VASPs

Exchanges with lax or absent KYC programs, exchanges domiciled in FATF-deficient jurisdictions, and unregistered virtual-asset service providers with material exposure to the categories above.

§ 03 · Access Restrictions

What a blocklisted address can and cannot do.

Restrictions apply at both the application layer (front end and API) and the contract layer (swap router, intent settlement, marketplace). Funds custody is separate — see Section 04.

Capability
Compliant address
Blocklisted address
Connect to Sera front end
✓ permitted
✗ refused
Receive a binding swap quote
✓ permitted
✗ refused
Place or cancel limit orders via API
✓ permitted
✗ refused
Execute swaps via swapper contract
✓ permitted
✗ refused at contract
Read account data & trade history
✓ permitted
✗ refused
Withdraw owned tokens from Vault
✓ permitted
✓ emergencyWithdraw()
§ 04 · Non-Custodial Guarantee

Sera can deny access. Sera cannot touch your funds.

Wallet screening governs access to Sera's off-chain services and on-chain routing. It does not — and architecturally cannot — affect a user's ability to retrieve tokens already deposited in the Vault contract.

The escape hatch

Every depositor retains a permissionless on-chain path to their tokens, even if blocklisted.

Tokens held in Sera's Vault contract are owned by the depositor. emergencyWithdraw() can be called directly on-chain — without the API, without the front end, and regardless of compliance status. There is no admin key, multisig, or oracle signal that can freeze, seize, or redirect user funds. This is a property of the contract, not a policy.

Property 01 · Ownership
Vault balances are credited to the depositor's address. Sera cannot reassign them.
Property 02 · Permissionless exit
emergencyWithdraw() is callable by the depositor regardless of access status.
Property 03 · No freeze primitive
No contract function exists to freeze, seize, or redirect user-owned tokens. Verified in audit.
§ 05 · For Institutional Liquidity Providers

Counterparty assurances your compliance team will ask for.

When you provide liquidity on Sera, you quote against flow originating from screened addresses across the protocol. The controls below are designed to give institutional LPs and their compliance officers a defensible posture on counterparty risk.

CONTROL 01

Counterparty pre-screening

Every taker that consumes your liquidity has cleared the same KYT and KYA screen. You are not quoting into anonymous traffic — you are quoting into traffic that has passed a sanctions and high-risk filter at the contract layer.

CONTROL 02

Source-of-funds expectation

LPs are expected to deposit liquidity from wallets whose source of funds they can document under their own AML program. Sera applies the same screening to LP addresses as to taker addresses, but does not perform substantive KYC.

CONTROL 03

On-chain audit trail

Every fill, every fee, every routing hop is recorded on-chain and independently verifiable. LPs and their auditors can reconstruct any time window directly from the chain — no reliance on Sera-controlled databases.

CONTROL 04

Sanctions list refresh

The blocklist is refreshed continuously against the analytics providers' feeds. New OFAC designations and freshly attributed illicit-flow clusters is updated in real time without our intervention.

CONTROL 05

Indirect exposure tracing

Screening evaluates not only direct exposure but indirect exposure across multiple hops and addresses, until an attributed service is reached and flags intermediate exposure to prevent undesirable funds.

CONTROL 06

Issuer eligibility upstream

Stablecoins routable on Sera are restricted to regulated, 1:1 fiat-backed or government-bond-backed issuers with third-party reserve attestations. Algorithmic and crypto-collateralized assets are not eligible.

Available now · on request

Documentation pack for qualified counterparties.

Available today on request to qualified institutional counterparties under NDA where applicable.

CertiK smart-contract audit reports
GITHUB →
Sera Compliance Framework (v1.0)
PDF →
In development · expanding pack

Roadmap through 2026.

The institutional documentation pack expands through the year. Items below are in active development and will be released on request as they reach release-candidate quality.

Differential audit reports per upgrade
PDF
Monitoring & on-call runbook
PDF
Incident response procedures
PDF
LP-side reporting endpoints
API
§ 06 · Disputes & Enquiries

Flagged in error? We review every case.

Address attribution is imperfect. If a wallet has been blocked and you believe the classification is incorrect, submit the form below. Each enquiry is reviewed on a case-by-case basis against the underlying analytics evidence.

Reach the compliance team directly.

Use the form to submit any of the following. We aim to respond to qualified enquiries within 1–3 business days.

  • False-positive review
  • Institutional onboarding
  • Regulator information request
  • Security disclosure
  • Operational due diligence pack

By submitting, you confirm the information provided is accurate and may be retained for compliance review purposes.

Document version v1.0
Last reviewed 28 April 2026