There is a version of this story that starts with a whitepaper. KYC architecture diagrams. A six-month compliance review. A Fireblocks contract that costs three times what the deck said by year two.
That version is real. It has happened to a lot of teams. It is also not the only version anymore.
The version we’ll walk through starts differently — with an on-chain finance API for developers, a sandbox account, and the realisation that the infrastructure decisions that used to take quarters can now be made in an afternoon. Not because the compliance requirements went away, but because someone already built the layer that satisfies them.
Why has building compliant on-chain infrastructure taken months — until now?
Because the compliance and custody requirements of regulated finance are genuinely hard to build — and for a decade, building them was the only option. KYC linked to wallets, OFAC screening inside transactions, MPC key management with HSM backing. These are not features. They are architectural decisions. What changed is that they are now available as infrastructure you call, not infrastructure you build.
For the better part of a decade, building on-chain finance infrastructure meant one of two things. You either used a permissionless protocol — fast to integrate, impossible to make compliant — or you built the compliance and custody layer yourself, which meant hiring specialists, running a security audit, and explaining to your CFO why a six-month infrastructure project was a prerequisite for a payment feature.
The reason that trade-off persisted so long is that the compliance and custody requirements of regulated finance are genuinely hard. KYC needs to travel with every wallet, not live in a front-end. OFAC screening needs to run inside the transaction, not before it. MPC key management needs institutional-grade HSM backing, spending policy enforcement, and audit logging that survives a regulatory examination. These are not features you bolt on. They are architectural decisions that propagate through every subsequent choice.
What has changed is not the requirements. What has changed is that those requirements are now available as infrastructure — the same way SSL/TLS is available as infrastructure, and you do not have to understand the cryptography to serve HTTPS.
This is a walkthrough of that infrastructure, using Tresori’s on-chain finance API for developers. By the end of it, you will have provisioned a compliant MPC wallet, routed a stablecoin payment API, and verified Travel Rule compliance API. In 12 lines of code. The compliance and custody layer is handled. You just call it.
What changes when compliance is infrastructure rather than something you build?
Everything. When compliance is infrastructure, a wallet provisioning call is also a KYC-linking call, a key management call, and a policy enforcement call. You do not add compliance to a payment flow. You get a payment flow that was compliant before you wrote the first line.
A Tresori wallet is not a key pair you generate and store. It is a compliant MPC wallet — MPC key management fintech-backed, policy-enforced, linked to a verified entity in your system at the moment of creation. The KYC status your user completed at onboarding does not live in your database alone.
const wallet = await client.wallets.create({
entity_id: ‘usr_8f3kd92’,
chains: [‘solana’, ‘ethereum’],
policy: ‘standard_compliance’
});
Three things happen in that call that you did not have to write. The wallet is linked to usr_8f3kd92 in your entity registry. The MPC key management fintech shares are distributed across HSM-backed infrastructure, with no single point of compromise. The standard_compliance policy attaches OFAC screening blockchain and Travel Rule compliance API to every outbound transaction from this wallet — at the protocol level, not the application layer.
You get back addresses. Everything else is handled.
Key takeaway: KYC-linked wallet provisioning in on-chain finance is not a key management problem. It is an identity and compliance problem. An on-chain finance API for developers that solves all three in one pass is the architectural difference that matters.
Why is the contract short when the compliance requirements are not?
Because the compliance requirements moved into the infrastructure layer. The contract does not carry OFAC logic, Travel Rule packaging, or MPC key management — it calls an execution layer that does. Shorter code is not a shortcut. It is what happens when the hard work is done somewhere else.
const payment = await client.payments.send({
from_wallet: wallet.id,
to_address: ‘AhX9…recipientAddress’,
amount: ‘250.00’,
currency: ‘USDC’,
chain: ‘solana’,
memo: ‘Invoice #INV-2024–0391’
});
Before the transaction reaches the chain, Tresori runs OFAC screening blockchain against the destination address, packages Travel Rule compliance API originator data against the IVMS 101 standard, and routes the payment via stablecoin payment API to the optimal RPC endpoint. If the destination address matches a sanctions entry, the payment does not execute.
That is the architectural difference between compliance as a transaction-layer property and compliance as a wrapper around a permissionless protocol. In DeFi, a sanctions screen fails and the transaction executes anyway — the protocol has no mechanism to stop it. Here, the compliance logic is inside the execution layer.
Why should the chain be a parameter, not an architecture decision?
Because locking your architecture to a single chain means rebuilding every time the market moves. The chains that matter for on-chain finance infrastructure today — Solana, Base, Arbitrum, Stellar — are not the same ones that will matter in three years. The right infrastructure decision is one that makes chain selection a runtime choice, not a foundational commitment.
Stablecoin settlement infrastructure decisions are liquidity decisions, custody decisions, and — increasingly — jurisdiction decisions. Solana for settlement speed and USDC volume, Base and Arbitrum for permissioned blockchain payments with institutional tooling, Stellar for MENA and Southeast Asian remittance corridors.
Tresori routes across all of them from the same on-chain finance API for developers surface. The chain is a parameter, not an integration decision.
Why does Travel Rule compliance break when it lives in a front-end?
Because a front-end can be bypassed. The moment a user interacts with a permissionless contract directly — without going through your application layer — the Travel Rule check never runs. Compliance that depends on a user taking the right path is not compliance. It is a process that works until it doesn’t.
const compliance = await client.compliance.check({
payment_id: payment.id
});
The Travel Rule requirement — that originators and beneficiaries of transfers above a threshold be identified at the protocol level — is the one that trips most teams building regulated payment flows. The standard implementation puts the check in a front-end that calls a VASP directory before the user submits the transaction. That approach breaks under MiCA, breaks under any jurisdiction that requires the data at the protocol level rather than the application level, and is trivially bypassed by anyone who does not use your front-end.
Tresori’s Travel Rule implementation packages the originator and beneficiary data into the transaction at the point of execution. The compliance.check call returns the full compliance record — the data that exists in the audit trail, the data that satisfies a regulatory examination. You are not building a compliance report. You are reading one that was written when the transaction was created.
Key takeaway: Travel Rule compliance API that lives in a front-end is not compliance. It is a wrapper that breaks the moment someone bypasses the front-end. Compliance at the transaction layer does not break, because there is no front-end to bypass.
What is sitting behind those 12 lines?
Seven layers that used to take quarters to build: MPC key management, HSM-backed storage, spending policy enforcement, OFAC screening at execution, Travel Rule packaging, multi-chain routing, and SOC 2-compatible audit logging. None of it is in the 12 lines. All of it runs every time you call them.
Twelve lines of code. Three API calls. And what sits behind them is worth listing, because it is the list that used to take quarters to build: MPC wallet infrastructure with distributed key shares and HSM backing. OFAC screening running inside transaction execution. Travel Rule originator/beneficiary data packaged to IVMS 101 standard. Multi-chain routing logic across 50+ networks. SOC 2-compatible audit logging. Spending policy enforcement. KYC-to-wallet entity linking.
None of that is yours to maintain. None of it is yours to audit. None of it needs to be explained to a compliance officer who has never seen a blockchain address.
The question developers kept asking — “how do I add compliance to my on-chain payment flow?” — was always the wrong question. The right question is “how do I build a payment flow where compliance is already there?” The answer, it turns out, is twelve lines.
How do you know the sandbox is production-ready before you go live?
Because the sandbox runs the same infrastructure as production — same compliance checks, same custody layer, same Travel Rule implementation — on test funds. There is no stripped-down demo environment. What you build in the sandbox is what goes live. The only thing that changes is the key.
The sandbox is the fastest way to understand what the infrastructure layer can carry before committing to a production integration. Multi-chain routing, batch payment flows, webhook configuration for transaction status updates, and the full Travel Rule implementation are all available from day one.
FAQs
Can you really build on-chain finance infrastructure in 12 lines of code?
Yes. The compliance, custody, and Travel Rule logic is infrastructure — not something you write. You call it.
What does a 12-line on-chain finance smart contract look like?
Which Ethereum Layer 2 is best for regulated on-chain finance applications?
Base for teams on Coinbase’s stack. Arbitrum for ecosystem depth. Both have the USDC liquidity and institutional custody support regulated use cases require.
How does compliance integration work in such a small contract?
It doesn’t live in the contract at all. OFAC screening, Travel Rule, and KYC enforcement run in Tresori’s infrastructure layer before the transaction reaches the chain.
What security layers support this 12-line contract?
MPC with distributed key shares, HSM-backed storage, OFAC screening at execution, spending policy enforcement, and SOC 2 audit logging — all in the infrastructure layer, none of it yours to maintain.
How can developers test these contracts locally?
Tresori’s sandbox mirrors the full production API across 50+ chains using test funds. Same code, no changes required to go live.
Where can developers access Tresori SDK and smart contracts?
The SDK and full documentation are at tresori.xyz/developers. The sandbox — covering wallet provisioning, stablecoin settlement, and compliance across 50+ chains — is at tresori.xyz and provisions in under a day.
Top comments (0)