Get started
Position paper

Provable Control

Code-enforced authority for the privileged keys behind tokenized real-world assets.

Mint · burn · freeze · seize — those keys are the single point of failure.
Book a deployment review
See the Lit Actions examples
Issuing a payment stablecoin under the GENIUS Act? See /stablecoins →
Abstract

Tokenized real-world assets — treasuries, funds, private credit, securities — are controlled by privileged keys: the authority to mint, burn, freeze, seize, and reissue. Today that authority sits in an administrative account, a multisig, or a custodial operator’s mutable policy — a single point of failure that a person can misuse, be coerced into using, be subpoenaed against, or trigger by accident, and whose failures surface only after they settle. The roughly $300 trillion that Paxos accidentally minted in October 2025,[1] and the ~$285 million drained from Drift through a phished multisig in April 2026,[2] are not edge cases; they are the failure mode. Unlike payment stablecoins, no statute mandates a remedy for tokenized securities[12][13] — the forcing function is risk, not a deadline. This paper sets out a control architecture in which privileged-key authority is generated and used only inside sealed hardware, bound to immutable on-chain policy, and attested on every action and every refusal. The authority cannot be exercised outside its policy — by an operator, an intruder, or an error — and every use, and every refusal, leaves a verifiable record. Control becomes something an issuer or transfer agent can prove rather than promise.

1

The single point of failure

Every tokenized asset depends on privileged keys. Someone must be able to mint new units against new backing, burn on redemption, freeze a sanctioned holder, and — under a lawful order — seize or reissue. Those powers are legitimate and necessary. The open question is who, or what, holds them, and what constrains their use.

Today the answer is an ordinary administrative key, and the failures are on the record. On October 15, 2025, Paxos — the regulated issuer of PayPal’s PYUSD — accidentally minted roughly $300 trillion in PYUSD when a typo turned an intended $300 million transfer into $300 trillion; the excess was burned about 22 minutes later. According to security firm Halborn, PYUSD’s supply was controlled by a single externally owned account with unlimited mint privileges, without a multi-signature wallet or built-in controls.[1]

It is not an isolated error. In April 2026, attackers phished two of five signers on Drift’s governance multisig — a 2-of-5, zero-timelock configuration — and exploited Solana “durable nonces” to drain roughly $285 million.[2] In 2019, Tether accidentally minted $5 billion in USDT through a token-decimal error before reversing it.[3] In March 2021, a compromised deployer key with authority over PAID Network’s contract upgrade let an attacker replace the token and mint at will.[4] Different assets, different mechanisms, one root cause: a privileged key that a single party holds, and that the contract simply trusts.

Payment stablecoins now have a dated mandate to address this — the GENIUS Act. Tokenized securities do not: GENIUS regulates payment stablecoins, not securities,[12] and the EU’s MiCA excludes financial instruments.[13] No statute prescribes the mechanism. But securities laws apply regardless of an asset’s format — the SEC’s staff has been explicit that tokenization changes the plumbing, not the regulatory perimeter[9] — and the operational risk above is realized, repeatedly. The forcing function is risk, and the standard a board and an auditor already apply.

2

Control by promise

Most tokenized-asset programs meet a control requirement the way the industry always has: a privileged role on the token contract, held by an issuer, transfer agent, or custodian, plus a written policy describing how it will be used. The asset’s holders, the issuer’s board, and any examiner are then asked to trust that the key is held securely, used only as the policy says, and that misuse would be caught — each verified after the fact, by sampling logs.

The dominant tokenization standard builds this in. ERC-3643 (T-REX) vests privileged Owner and Agent roles with the power to mint, force transfers, and recover wallets; the standard recommends, but does not require, that those roles be decentralized — they may be ordinary accounts or multisigs the contract trusts.[6] Its own reviewers flag the risk: if the agent keys “are compromised or misused, assets can be arbitrarily moved, frozen, or reassigned.”[7] Securitize’s widely deployed DSToken exposes a discretionary, role-gated seize() — a forced transfer to a designated issuer wallet — behind an upgradeable proxy whose implementation an administrator can replace.[8] Custodial policy engines add a further layer of trust: they enforce rules a workspace owner can edit, and you trust the operator that the enclave runs the code it claims.

This model is promissory and post-hoc, and weak by the standard of any serious control framework:

  • 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.
  • 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 role cannot stop a self-custodied wallet, a smart contract, or an autonomous agent from initiating a non-compliant transfer.
  • It can fail onto innocents. In May 2026, a court-ordered freeze forced Circle to blacklist a shared pooled USDC contract, locking roughly $12.6 million belonging to every depositor — including users with no connection to the dispute; a court reversed it days later as unwarranted.[5] The operator complied correctly. Innocent parties still lost access.

A securities regulator and an internal auditor share the same concern. A control 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.

3

Verifiable control

The alternative is to verify the system rather than trust the holder. Four properties make a privileged key impossible to exercise outside its policy:

  • ◆Blind. The privileged 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.[14][15]
  • ◆Bound. The key’s authority is not an administrative setting but on-chain state on Base: it signs only what an immutable, content-addressed policy permits. Changing what it can do is an on-chain governance action, not an admin switch.[15]
  • ◆Verifiable. Every action the key takes, and every transfer it refuses, is a hardware-attested record — provable to a regulator or auditor, asserted by no single operator.[16]
  • ◆Confidential. The same enclave screens the holder and amount in the clear only to enforce policy; investor identities, balances, and the counterparty graph never touch the public chain. An issuer screens against sanctions and eligibility without publishing its book to the world.

Together they relocate the privileged key out of human hands: no administrator, intruder, or error can sign around the control, and the screen runs without putting investor activity on-chain. That is what impossible to misuse outside its policy means here; §6 makes it precise.

4

Privileged power, enforced at signing

Each privileged power becomes a capability enforced at the moment of signing, rather than a discretion asserted in a policy.

Privileged powerEnforced at signing
Mint[1]A supply cap and sanity-bound invariants live in code; no signature is produced if a mint would exceed the on-chain cap. The PYUSD ~$300-trillion class becomes impossible, not monitored.
Burn / redeemCondition-gated and governance-bound; each burn is an attested record.
Freeze / blockA sanctions and eligibility screen runs inside the enclave; the signature is withheld on a hit, and the block is itself an attested record — without publishing the holder or amount on-chain.
SeizeExecutes only on a verified, governance-bound lawful order; attested, with no discretionary operator path.
Reissue / recoverBound to verified loss or order conditions; attested; cannot be triggered outside policy.
Table 1 — Privileged powers mapped to controls enforced at signing.
5

What an issuer can prove

One architecture, demonstrable to four different audiences.

AudienceWhat an issuer or transfer agent can prove
Securities regulator / examinerPrivileged operations occur only within policy, across every chain the asset touches, with evidence of each action and each refusal — even though no statute yet mandates the mechanism.[9]
Internal audit & SOC 2Segregation of duties enforced cryptographically; a complete, tamper-evident trail; control effectiveness demonstrated continuously, not sampled — against COSO and SOC 2, with the AICPA’s 2026 controls-over-stablecoin-operations criteria as the nearest published analog.[11]
Board & risk committeeNo key-person or operator single point of failure; policy changeable only by governance; the PYUSD and Drift failure class is removed, not monitored.
Counterparties, LPs & investorsA non-custodial guarantee that is cryptographically verifiable, rather than asserted.
Table 2 — Guarantees demonstrable to each audience.
6

The architecture

Three layers implement the 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.[14][15]

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 — recorded, and auditable on Basescan — not flipping an administrative switch.[15]

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 — closing the physical side-channel gap.[16]

Sealed enclave · operators are blind
01
Authorize against the chainThe enclave reads the on-chain permission contracts: is the caller allowed, and is this policy bound to this key?
02
Fetch the immutable policyIt loads the exact policy by content identifier — content-addressed, so the code cannot have been substituted.
03
EnforceThe policy runs in a sandbox: sanctions and eligibility screen, supply cap, lawful-order check, limits. If any check fails, no signature is produced.
04
Sign, without exposing the keyOnly on success does the enclave use the key. The key never leaves the hardware; the decision — and any refusal — is attested.
Figure 1 — The lifecycle of a single privileged signing request inside the enclave.

A note on trust. No system eliminates trust; it relocates trust to assumptions that can be independently verified. Here those 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, the latter auditable on Basescan.[15] There is no trusted operator.

7

Honest scope

The defensible claim is a pair of properties in combination, and it is worth stating plainly what this does and does not do. The moat is privileged-key authority bound to immutable, content-addressed policy — not a mutable configuration — and externally provable through attestation of every action and every refusal, with no operator to trust. Policy-in-a-TEE, non-custodial signing, and hardware attestation each exist elsewhere; the combination — immutable on-chain policy plus decentralized, externally verifiable attestation — is what removes the privileged-key single point of failure rather than relocating it.

What this is not: a regulatory mandate. No statute requires this mechanism for tokenized securities. Securities laws apply regardless of an asset’s format — a tokenized security is still a security, and tokenization changes the plumbing, not the regulatory perimeter[9][10] — but the driver here is operational risk and internal-control rigor, not a deadline. This architecture is a control; it is not legal advice and creates no legal obligation.

8

Implementation

Demonstrable capability is reached fastest by starting narrow. A reference implementation can enforce sanctions-screened, supply-capped minting plus a governance-bound seize and freeze on a single asset and a single chain, prove it end-to-end, then extend across the other chains the asset touches. The architecture is cross-chain by design; starting on one chain proves the control, not a retreat from it. The goal is a control an examiner and an auditor can verify — not a finished platform.

Book a deployment review
See the Lit Actions examples
9

References

  1. [1]Halborn, “Explained: The Paxos PYUSD Incident (October 2025)” — on Oct. 15, 2025 a typo turned an intended $300M transfer into roughly $300 trillion in PYUSD, burned about 22 minutes later; per Halborn, supply was controlled by a single externally owned account with unlimited mint privileges and no multi-signature wallet or built-in controls. See also CNBC (Oct. 16, 2025). link
  2. [2]BlockSec, “Drift Protocol Incident” — on Apr. 1, 2026 (UTC) attackers phished two of five signers on a 2-of-5, zero-timelock governance multisig and exploited Solana “durable nonces” to drain approximately $285.3 million. link
  3. [3]CoinDesk, “Tether Accidentally Minted $5 Billion of Its Stablecoins, Then Deleted Them” (July 16, 2019) — a token-decimal error during a chain swap created $5B USDT, subsequently burned to the intended value. link
  4. [4]PAID Network attack postmortem (attack Mar. 5, 2021; postmortem published Mar. 7, 2021) — a compromised deployer key with authority over the contract’s upgrade function let an attacker replace the token and mint at will. link
  5. [5]The Block, “Court-ordered Circle freeze traps $12.6 million in Zama cUSDC contract” (May 2026) — pursuant to a temporary restraining order, Circle blacklisted a shared pooled “confidential USDC” contract (~12,606,386 USDC), locking every depositor including uninvolved users; a court lifted the freeze on June 1, 2026 as unwarranted. link
  6. [6]ERC-3643 (T-REX) standard, EIP-3643 — Owner (ERC-173) and Agent roles hold mint, forced-transfer, and recovery powers; the standard recommends but does not require those roles to be a multisig or contract, permitting ordinary externally owned accounts. link
  7. [7]QuillAudits, “ERC-3643 Explained” — flags the centralization risk: “if these agent keys are compromised or misused, assets can be arbitrarily moved, frozen, or reassigned,” and that limiting agent roles via multisig or contract-based access control “is a necessity.” link
  8. [8]Securitize DSToken (securitize-io/dstoken) — exposes a role-gated seize(address,address,uint256,string) that forcibly transfers tokens to a designated issuer wallet, deployed behind an upgradeable OpenZeppelin ERC-1967 proxy whose implementation an administrator can replace. link
  9. [9]SEC staff statement on tokenized securities (Jan. 28, 2026), Divisions of Corporation Finance, Investment Management, and Trading & Markets — federal securities laws apply regardless of whether a security is tokenized; the statement grants no relief and creates no new framework. link
  10. [10]Commissioner Hester M. Peirce, “Enchanting, but Not Magical: A Statement on the Tokenization of Securities” (July 9, 2025) — tokenization does not transform the nature of the underlying asset; tokenized securities remain securities subject to the federal securities laws. link
  11. [11]AICPA, “Updates Criteria for Stablecoin Reporting to Address Controls Over Stablecoin Operations” (Jan. 12, 2026) — a framework for controls over issuance, redemption, asset custody, and vendor management; the nearest published analog for controls over token operations. link
  12. [12]GENIUS Act, Pub. L. No. 119-27 (2025), § 17 — amends the federal securities and commodities laws so that a payment stablecoin issued by a permitted issuer is not a “security” or “commodity”; the Act regulates payment stablecoins, not securities, so tokenized securities have no GENIUS-equivalent mandate. link
  13. [13]Regulation (EU) 2023/1114 (MiCA), Art. 2 — does not apply to crypto-assets that qualify as financial instruments under MiFID II; tokenized securities remain under the existing EU financial-services regime, not MiCA. link
  14. [14]Lit Protocol, “Introducing Lit Protocol v3 (Chipotle)” — TEE-based execution, on-chain key orchestration, and hardware attestation. link
  15. [15]Lit Protocol developer documentation — on-chain permissions on Base and the On-Chain KMS: root-key release is gated by smart contracts on Base, with every configuration change a public, auditable transaction on Basescan. link
  16. [16]“Proof of Cloud: Data Center Execution Assurance for Confidential VMs,” arXiv:2510.12469 — extends hardware attestation to prove an enclave runs in vetted infrastructure. link

Informational only — not legal advice. Tokenized securities remain subject to existing securities laws regardless of format; see the SEC staff statement on tokenized securities (Jan. 28, 2026). No statement here creates a legal obligation or describes a regulatory mandate. Incident figures are drawn from the cited third-party reports and reflect those sources. Architecture described is current to Lit Protocol v3 and subject to change. Consult qualified counsel before relying on any statement here.