The forcing function
The GENIUS Act (Public Law 119-27) brings U.S. payment stablecoins inside the federal perimeter. A permitted issuer is treated as a financial institution under the Bank Secrecy Act and must maintain an effective anti-money-laundering and economic-sanctions compliance program.[1] It must also hold the technological capability to comply with a lawful order to “seize, freeze, burn, or prevent the transfer” of the stablecoins it issues.[2]
The rule proposed by FinCEN and OFAC in April 2026 makes the engineering requirement explicit: issuers need the “policies, procedures, and the technical capability to block, freeze, and reject” specific transactions, and the agencies stress preventing a prohibited transfer rather than unwinding it afterward.[3] Public comment closes June 9, 2026; the Act takes effect on the earlier of eighteen months after enactment or 120 days after final rules — January 18, 2027.[4]
This is the deadline. The capability it requires also serves the issuer’s own internal controls, as the following sections set out.
Control by promise
Most issuers will meet a control obligation the way the industry always has: a privileged key on the token contract, held by a custodian or an internal team, plus a written policy describing how that key will be used. The regulator — and the issuer’s own control framework — are then asked to trust three things: that the key is held securely, that it is used only as the policy says, and that misuse would be detected. Each is verified after the fact, by sampling logs.
This model is promissory and post-hoc, and it is weak by the standard of any serious control framework:
- It acts too late. A freeze unwinds a transfer that has already settled; the rule asks issuers to prevent it.
- It does not travel. A control on one chain does not reach the same asset bridged to another.
- It does not reach far enough. A contract-level blacklist cannot stop a smart contract, a self-custodied wallet, or an autonomous agent from initiating a non-compliant transfer.
- It depends on a person. A key one administrator can use is a key one administrator can misuse, be compelled to use, or use by mistake — and a single point of compromise.
The regulator and the internal auditor share the same concern. A control that a single party can circumvent, that produces no tamper-evident record, and whose effectiveness can only be sampled is weak under COSO, SOC 2, and SOX alike.
Verifiable control
The alternative is to verify the system rather than trust the operator. Three properties make that possible:
- ◆Blind. The signing key is generated and used only inside a sealed trusted execution environment (TEE). No operator, host, or vendor — Lit included — can see or extract it.
- ◆Bound. The key’s authority is not an administrative setting but on-chain state: it signs only what an immutable, content-addressed policy permits.
- ◆Verifiable. Every decision the key makes, and every transfer it refuses, is an attested record that anyone entitled to it can verify.
Together they close the gap between policy and enforcement: the key leaves human hands, and no privileged actor can sign around the control. That is what impossible to misuse means here; §6 makes it precise. These are also the properties an internal control framework requires, which §5 takes up.
External compliance
Each obligation the GENIUS Act and the proposed rule impose maps to a capability enforced at the moment of signing, rather than asserted in a policy.
| Obligation | Enforced capability |
|---|---|
| Block or reject a prohibited transfer before it executes[1][3] | A policy screens the counterparty against an OFAC/sanctions oracle and withholds the signature on a hit; enforcement happens at the moment of signing. |
| Comply with a lawful order to seize, freeze, or burn[2] | Freeze and burn paths are condition-gated and governance-bound, executing only on a verified order. |
| Enforce across every chain the asset touches[3] | One enclave-held key signs across Bitcoin, EVM, Solana and Cosmos, and reorg-validates cross-chain mint and burn. |
| Reach secondary, smart-contract and agent activity[3] | Authority is bound to the signing key and to scoped, revocable agent permissions — not to a single token contract. |
| Evidence the program and report blocked transactions[3] | Policies are immutable and code-hash-verified; each decision is a cryptographically attested record. |
Internal compliance
The same architecture answers the questions an internal audit, a SOC 2 assessor, and a board risk committee ask — often more cleanly than a conventional stack.
- Segregation of duties, enforced cryptographically. No single person can mint, move, or freeze; authority is split across the network and bound to policy. Segregation of duties stops being an administrative arrangement that can be quietly undone and becomes a property of the system.
- A complete, tamper-evident audit trail. Every action — and every blocked attempt — is an attested, immutable record. An issuer can evidence that a control operated, continuously, not merely that it was designed; that distinction is what external auditors actually test.
- Change management by construction. The policy is code: versioned, content-addressed, and alterable only through on-chain governance. There is no out-of-band configuration change to reconcile.
- A smaller risk surface. There is no custodial key to steal, subpoena, or fat-finger; the insider, coercion, and operational-error paths are removed rather than monitored. The October 2025 episode in which an issuer accidentally minted and then unwound trillions of dollars is precisely the class of error a supply-cap invariant in code prevents.
- Continuous assurance. The control operates and is evidenced in real time, not attested once a quarter.
None of this is a separate product. It is the same enforcement described in §4 and §6, assessed against internal-control standards rather than the statute.
The architecture
Three layers implement the three properties. Each is independently inspectable.
Blind execution. Lit Actions — the policies — run inside trusted execution environments, where the signing key is derived and used. The network connection terminates inside the enclave, so there is no point at which key material is exposed; nothing that touches it leaves.[6][7]
Bound to the chain. A key’s authority is on-chain state on Base: permission contracts bind each key to the exact, content-addressed policies it may run. Changing what a key can do means changing on-chain state under the issuer’s own governance — not flipping an administrative switch.[6]
Verifiable hardware. Each enclave emits a hardware attestation: a signed, deterministic measurement of the exact code running inside. The Proof of Cloud approach extends that attestation to prove the machine runs in vetted infrastructure rather than on an attacker’s bench — binding the chip’s identity to a second root of trust and closing the physical side-channel gap.[8]
A note on trust. No system eliminates trust; it relocates trust to assumptions that can be independently verified. Here those assumptions are the silicon vendor’s hardware root of trust and the on-chain governance that sets policy — both externally attestable, the former hardened by Proof of Cloud. There is no trusted operator.
What an issuer can prove
The result is one architecture whose guarantees can be demonstrated to four different audiences.
| Audience | What an issuer can prove |
|---|---|
| Regulator | Pre-execution sanctions screening and lawful-order seize/freeze across every chain, with evidence of each blocked attempt.[1][3] |
| Internal audit & SOC 2 | Segregation of duties, a complete tamper-evident trail, and control effectiveness demonstrated continuously — not sampled. |
| Board & risk committee | No key-person or insider single point of failure; policy changeable only by governance; custodial and operational risk materially reduced. |
| Counterparties & customers | A non-custodial guarantee that is cryptographically verifiable, rather than asserted. |
Implementation
Demonstrable capability is reached fastest by starting narrow. A reference implementation can enforce sanctions-screened, supply-capped minting on a single asset and a single chain, prove it end-to-end against the proposed rule’s requirements, and expand from there. The goal before January 18, 2027 is a control an examiner and an auditor can verify — not a finished platform.
References
- [1]GENIUS Act, Pub. L. No. 119-27, 139 Stat. 419 (July 18, 2025), § 4(a)(5) (permitted payment stablecoin issuer treated as a financial institution under the Bank Secrecy Act; effective AML and economic-sanctions compliance program). link
- [2]GENIUS Act § 2(16) (definition of “lawful order”); § 4(a)(5) (technological capability to comply with a lawful order to seize, freeze, burn, or prevent the transfer of stablecoins). link
- [3]FinCEN & OFAC, Permitted Payment Stablecoin Issuer AML/CFT Program and Sanctions Compliance Program Requirements (Proposed Rule), 91 Fed. Reg. (Apr. 10, 2026), Doc. No. 2026-06963; public comment closes June 9, 2026. link
- [4]GENIUS Act § 20 (effective on the earlier of 18 months after enactment or 120 days after final implementing regulations). link
- [5]U.S. Department of the Treasury, proposed rule implementing the GENIUS Act’s illicit-finance requirements (Apr. 2026). link
- [6]Lit Protocol, “Introducing Lit Protocol v3 (Chipotle)” — TEE-based execution, on-chain key orchestration, and hardware attestation. link
- [7]Lit Protocol developer documentation — architecture and security. link
- [8]“Proof of Cloud: Data Center Execution Assurance for Confidential VMs,” arXiv:2510.12469; Flashbots, “Mind the Gap.” link
Informational only — not legal advice. Summarizes the GENIUS Act of 2025 (Pub. L. No. 119-27) and the FinCEN/OFAC proposed rule (91 Fed. Reg., Apr. 10, 2026; Doc. 2026-06963), which is not final and may change; comments close June 9, 2026. Architecture described is current to Lit Protocol v3 and subject to change. Consult qualified counsel before relying on any statement here.