Summary
Liquefaction is a “service” that lets multiple people securely rent, share, or pool crypto assets using TEE, bypassing traditional single-owner controls. It exposes weaknesses in how ownership is enforced on-chain, affecting everything from token rewards to digital identity and governance. This breaks the conventional link between addresses and single users. First Application (takemyape.com) - lending out someone’s Bored Ape and accessing all the privileges.
Key Innovation
Breaking the long held belief of Single Entity Address Ownership. Trusted Execution Environments (TEEs) to control private keys with programmable, multi-user policies, enabling private, rental of on-chain assets.
Background
Dark DAOs (2018) This work shows how Trusted Execution Environments (TEEs) can be used to attack DAO governance by enabling privacy-preserving bribery and vote delegation. The authors demonstrate this on Oasis Sapphire to covertly manipulate Ethereum DAOs—revealing systemic vulnerabilities as DAOs scale.
Team
Cornell Tech researchers James Austgen PhD, Andrés Fábrega, Mahimna Kelkar, Dani Vilardell, Kushal Babel lead by Professor Ari Juels and FlashBots’ Sarah Allen, and Stanford’s Jay Yu.
Examples
(i) Locked tokens: Tokens distributed in airdrops or vesting schedules are bound to specific addresses and cannot be transferred until unlocked. (ii) Loyalty rewards: DEXes reward high-activity addresses with discounts or benefits to encourage repeated use. (iii) Soulbound Tokens (SBTs): SBTs represent non-transferable identity credentials tied permanently to a single address. (iv) Voting and economics: Many blockchain systems rely on fixed address ownership to enforce voting integrity, tokenomics, and traceability.
Glossary
(i) Key Encumbrance: Secret key is generated inside a TEE and managed by an app using access policies. Users never directly control the key—access can be delegated or restricted, such as barring an owner from using their key during a rental period. (ii) SEAO (Single-Entity Address Ownership): The assumption that one user owns and controls each blockchain address. (iii) Asset-Time Segmentation: Assigning asset control to specific users at set times. (iv) CK Proof (Complete Knowledge Proof): A cryptographic proof showing direct, exclusive control of a private key.
Components
(Key Innovations - focus on the innovations, and key parts)
| TEEs | Liquefaction’s core mechanism relies on TEEs to securely generate and manage private keys under strict policy control. These keys are never exposed to users, removing the risk of manual key leaks or overrides. |
|---|---|
| Policy Delegation | A structured model for delegating authority over assets. This framework includes time-bound, asset-specific, and hierarchical delegation rules enforced through smart contracts. It ensures safe delegation without asset conflicts. |
| Encumbered Wallet | Wallets created from modular policy contracts that define who can sign what, when, and how. Sub-policies can delegate access down a tree, enabling multi-layered control and flexibility |
| Privacy | By operating within TEEs and leveraging off-chain message signing, transactions and access control logic remain hidden, preventing on-chain traceability. |
Countermeasures
Complete Knowledge (CK) proofs, require proving direct user control (non-encumbered) of private keys, thus safeguarding applications from unintended key sharing or delegation. (i) A TEE initially holds the private key and generates a Proof of Complete Knowledge (PoCK)—a cryptographic statement proving the key exists within the enclave. (ii) Then, the TEE releases the key to the user. Once released, the TEE can no longer enforce access-control policies, ensuring that the user alone holds and controls the key. Example: Proof-of-work (PoW)-based CK proofs: (i) An ASIC (or other dedicated hardware) computes a key-specific challenge—typically a computation that requires both knowing the private key and expending real work (e.g., hash preimages). The result proves that the user had direct access to the key during computation without relying on a policy-controlled enclave. Paper By: Mahimna Kelkar, Cornell Tech, Kushal Babel, Cornell Tech, Philip Daian, Cornell Tech, James Austgen, Cornell Tech, Vitalik Buterin, Ethereum Foundation, Ari Juels, Cornell Tech
Performance
Low tx costs and practical latency, making it viable for real-world use. Uses standard Ethereum-compatible smart contracts, ensuring ease of adoption without specialized TEE expertise.
Key Tech Highlights
(1) TEE Key Control: Keys made and stored in TEEs; users never see or hold the key. (2) Smart Access Rules (Γ) Rules decide who can sign what, based on wallet data, blockchain state, and user input. (3) Safe Policy Changes (β): Only owners can give away rights; checks stop abuse (e.g. pre-signed tricks). (4) Asset-Time Split One user controls an asset at any time; splits balances for fair use (e.g. 5 ETH for Alice, 10 ETH for Bob). (5) Wallet Ops (ℱ_LW) (a) Gen: make wallet (b) Sign: sign if allowed (c)Update: change rules safely (d) Verify: prove someone has access (6) Privacy by Design: Users only see their own rights; others’ access stays hidden unless shared. (7) Nested Control: Access can be split again into new wallets; allows sharing and lending layers.
Implementation
(1) TEE-Based Wallet: Keys are generated and secured inside TEEs; users never handle keys directly. (2) Smart Contract on Oasis Sapphire: Written in Solidity, uses a TEE-backed EVM for privacy and secure execution. (3) Access Manager (AM): Entity (user or contract) that creates the wallet, sets access rules, and manages policy transitions. (4) Policy Tree: Access rules encoded as sub-policies in a hierarchical structure; each controls specific permissions and expires over time. (5) Signature Flow: Signing requests flow up the policy tree for validation; root node signs and returns. (6) Asset-Time Segmentation: Prevents double-use of assets by enforcing time-bound, exclusive access. (7) Sub-Balances: Split ether and tokens into per-user sub-balances to support multiple users. (8) Nonce Control: Prevents pre-signing abuse; uses Ethereum nonce and inclusion proofs to manage signing sequence. (9)Fee Handling: Each sub-policy pays for its own execution and proof costs from its balance.