How the sealed corridor works.

CLOISTRA is a cross-border payment corridor whose compliance rulebook is encrypted. The cap on a single transfer, the list of screened recipients, the ceiling on how much one sender may move per month — all of it lives on Ethereum as ciphertext, and every payment is checked against it without the chain, the sender, or even the corridor operator ever seeing the thresholds.

This inverts the usual design. Confidential-payment systems encrypt the amount and publish the rules. CLOISTRA seals the rules themselves, keeps the amounts confidential too, and still gives a regulator a lawful way in: one designated compliance officer holds the only decryption rights, granted onchain, usable only through a threshold key ceremony.

The whole thing runs on fully homomorphic encryption via the FHEVM — contracts compute directly on encrypted values. There is no trusted server holding plaintext, no commit-reveal scheme, no mirror database. What the chain stores is what exists.

Picture a remittance corridor with a published $10,000 per-transfer cap. Nobody launders $10,001 through it. They send $9,900, eleven times, from four wallets. Published thresholds are not guardrails — they are instructions for how to stay invisible. Regulators call the practice structuring, and it works precisely because the boundary is known.

Hiding the number is not enough, because rejection leaks. If the corridor refuses a transfer over the line, a probing sender can binary-search the cap in a dozen attempts without ever reading it. And even a perfectly opaque corridor fails if its own operator can read the risk model — models that staff can read are models that leak, to competitors and to the people they are meant to catch.

So the requirements stack up to something strange: rules that everyone can verify are enforced, that no one can read — not the sender, not an observer, not the operator who wrote them — where failure is indistinguishable from success from the outside, and where one auditor can still decrypt specific outcomes when the law requires it. That set of requirements has exactly one known construction, and it is homomorphic encryption.

A payment moves through the corridor in four steps. None of them exposes a cleartext value onchain.

1 — Encrypt. The sender types an amount into the browser. The Zama relayer SDK encrypts it client-side under the network’s public FHE key and produces a zero-knowledge input proof binding the ciphertext to this sender and this contract. No decryption key exists in the browser; the network’s secret key exists nowhere at all — it lives sharded across a threshold KMS.

2 — Verify the input. Onchain, FHE.fromExternal checks the proof. A forged ciphertext, or someone replaying another user’s ciphertext as their own, reverts here — at the door, before any rule is evaluated.

3 — Adjudicate, encrypted. The corridor computes the velocity predicate, then hands the engine the sealed amount. The engine folds five encrypted comparisons into one boolean — cap, cumulative total, custody, drawdown floor, recipient screening — ANDs in the velocity result, and settles through a single FHE.select(ok, amount, 0). The moved amount is either the sender’s ciphertext or an encrypted zero. There is no branch, so there is nothing to observe: gas, events, and storage writes are identical either way.

4 — Account and receipt. The corridor adds the actually-moved ciphertext into the sender’s encrypted running total, and the engine extends a public hash-chained receipt — proof that a settlement happened, and in what order, revealing nothing about what it decided.

All four evaluate on every transfer, always, in the same order, into the same single boolean. A transfer blocked by screening is byte-for-byte indistinguishable from one blocked by velocity — or from one that cleared.

Decryption is not a matter of trust here; it is a matter of onchain grants. Every ciphertext handle carries an access-control list maintained by the FHEVM itself, written by the contracts at the moment each value is created.

The operator row is the unusual one, and it is the point: the party with the most operational power has zero read access to the policy it administers. An insider cannot leak what an insider cannot read.

The contracts are written against @fhevm/solidity. Encrypted values are typed — euint64 for amounts and limits, ebool for predicates — and operated on with homomorphic primitives: FHE.le, FHE.add, FHE.and, FHE.select. The actual FHE computation runs on a coprocessor network; symbolic handles onchain commit to every intermediate value. ZamaEthereumConfig resolves the host, the ACL, the KMS verifier, and the input verifier by chain id, so nothing is hardcoded.

Custody is an ERC-7984 confidential token (OpenZeppelin’s FHEVM-native standard), so balances and transfer amounts are ciphertext all the way down — the corridor never holds a cleartext number even internally.

Client-side, the browser uses @zama-fhe/react-sdk: useEncrypt for input encryption and proofs, useUserDecrypt for the officer’s audit path. The server-side off-ramp uses @zama-fhe/sdk with a Node relayer client and a viem-backed signer — the same protocol the browser speaks, driven by the officer’s key. The Foundry test suite (39 tests) runs on forge-fhevm’s cleartext harness locally; real FHE, relayer, and KMS behavior is exercised on Sepolia.

One design decision worth naming: the engine exposes exactly one settlement path. Every consumer contract — the corridor, the single-agent leash, the cross-contract option — funds out through the same internal function and the same FHE.select. There is no second door to audit.

The rolling per-sender limit is the part with real engineering teeth, because a naive version leaks and a clever-looking version breaks. The construction:

Each sender has an encrypted running total and a public window anchor. Block timestamps are public information — pretending otherwise would be theater — so the window rollover is a plaintext branch on a public clock, which costs nothing and hides nothing that was ever hidden. The amounts inside the window are what matter, and those never leave ciphertext.

The predicate is carried + amount ≤ ceiling, computed homomorphically — an absolute sealed number against an absolute sealed number, deliberately avoiding encrypted division, which is where FHE designs go to die.

The subtle part is what advances the total. The engine returns the sealed moved outcome and grants the corridor transient compute rights on it — compute, not decrypt. The corridor adds moved, not the proposed amount, into the accumulator in the same transaction, without ever learning what it added. A transfer nullified by any rule contributes an encrypted zero, so a blocked payment cannot eat a sender’s window budget. Ciphertext flows from one contract’s accounting into another’s, and no one decrypted anything.

A corridor that reverts on violation publishes its rulebook one revert at a time. CLOISTRA never reverts on a rule breach. The transaction succeeds, the receipt chain extends, events fire — and the moved amount is an encrypted zero. The sender sees “settled, outcome sealed.” So does everyone else.

This is what makes probing worthless. Send one transfer or a hundred; walk the amount up or down; nothing in gas, logs, storage, or timing distinguishes the transfer that cleared from the one that died. The chain cannot tell you where the line is, because the chain itself does not know.

Replays and stale submissions do revert — on the public nonce, before any sealed evaluation. Ordering integrity is public; policy is not. The distinction between what should be public (that settlement happened, in what order) and what must not be (why it resolved the way it did) is drawn deliberately, rule by rule.

A sealed outcome still has to move money somewhere. A server-side listener runs as the compliance officer — the one identity with the decrypt grant. It watches settlement events, user-decrypts each sealed moved handle through the relayer and threshold KMS, and calls a payout provider only when the decrypted amount is greater than zero. A nullified transfer disburses nothing, and the listener could not fake it otherwise: the events it watches carry no cleared-or-not bit to shortcut on.

Payouts run through a Flutterwave v3 adapter (Nigerian naira, bank transfer, sandbox), keyed idempotently to the corridor and nonce so one onchain clear can never pay twice — retrying a processed settlement gets rejected by reference. The provider sits behind a typed interface; swapping rails touches one file and zero contracts.

The demo token in this corridor is clUSD, an ERC-7984 confidential token minted on Sepolia for custody testing. The operator pre-funds sealed custody with that token; the sender does not receive a visible balance and submits only an encrypted amount. In the sandbox off-ramp, decrypted moved units map 1:1 to NGN for evidence capture.

All four contracts are verified on Etherscan. The full loop has been closed more than once — an encrypted transfer clearing every sealed rule onchain, officer-decrypted through the KMS, and disbursed as a successful sandbox payout — most recently at nonce 12, decrypted to moved = 100 clUSD and paid as 100 NGN (provider reference …-12_PMCKDU_1, status SUCCESSFUL). Per-transaction evidence, blocks, and gas figures live in the repository’s DEPLOYMENTS.md.

The contracts are unaudited and hold demo value on a testnet. The fiat leg is a licensed provider’s sandbox: it proves the integration end to end, and it is not production money movement — that requires a live provider account, a funded float, and the compliance approvals that come with both.

Some things are public on purpose and should be understood as such: addresses, transaction timing, nonce ordering, and window anchors. FHE hides values, not traffic patterns. The single-sender demo configuration also trades a deliberately generous velocity ceiling for repeatability; a production corridor would keep it tight and rely on each sender having their own window.

And the trust model is explicit: confidentiality rests on the FHEVM’s coprocessor, ACL, and threshold KMS. That is a far smaller and more inspectable surface than “trust the operator’s database,” but it is not zero, and pretending otherwise would be the kind of claim this page exists to avoid.

One command builds the contracts, runs all 39 Foundry tests, typechecks the frontend and the off-ramp, and checks formatting:

Then pnpm start serves this app. The operator, sender, and officer consoles each take one seat at the corridor; the scout’s-eye toggle in the header shows any page as an outside observer sees it — which is to say, sealed.