{"id":"cc4af251-3b43-4fe7-b7fe-e55b75937b77","arxiv_id":"2412.02634","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":7.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Liquefaction demonstrates that private keys inside trusted execution environments can be encumbered with multi-user policies, enabling private, policy-controlled sharing of blockchain assets that breaks the single-owner assumption.","lead":"The paper presents Liquefaction, a TEE-based wallet system that lets multiple parties privately rent, share, or pool control of a single blockchain address and its assets. It shows how this system breaks the common assumption that one address equals one owner, enabling both attacks and new applications.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The transaction policy's pre-signing defense is incomplete: a sub-policy can obtain an off-chain signed transaction before expiry, broadcast it after expiry, and spend funds that were subsequently reassigned, violating the asset-time segmentation on which the safety claim depends.","rationale":"The reader's CONDITIONAL verdict is the right category, but I do not agree that the TEE idealization in Section 4.4 is the most load-bearing concern. That limitation is honestly disclosed and is standard for this line of work. A more concrete problem is internal to the policy design: the paper explicitly identifies pre-signing as an attack to prevent, yet the implementation's nonce-based mechanism does not prevent the single pre-signed transaction it allows, and off-chain signing makes it invisible to the policy's state. This is an internal inconsistency rather than a disagreement with external consensus, and it survives even if the TEE is perfectly secure. The attack breaks asset-time segmentation for fungible assets, which is the property that makes renting and pooling safe, so the central claim needs a caveat or a fix. Requiring every signature request to be recorded on the TEE blockchain before a signature is released, or otherwise maintaining persistent per-signature state, would close the gap, but the submitted artifact does not describe such a mechanism. The reader's verdict of CONDITIONAL is therefore appropriate, with this pre-signing gap as an explicit condition to resolve.","tokens_in":27148,"tokens_out":10951,"duration_ms":119471,"concrete_test":"Run the transaction encumbrance policy from Section 4.3 in a test deployment: (1) grant sub-policy P a sub-balance of X ETH; (2) have P request, off-chain, a signed transaction sending X ETH to an external address, but do not broadcast it; (3) expire P and grant sub-policy Q access to the same funds; (4) broadcast P's old transaction. If the transaction is accepted on Ethereum and Q cannot then spend its allocated balance, the pre-signing defense fails. A second analytic check is to inspect the deployed policy contract to confirm whether off-chain signature requests update any persistent tracking variable that beta consults; if they do not, the sealing rule in Section 3.2 cannot detect the outstanding signature.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"Section 4.3 states that the policy \"must prevent sub-policies from pre-signing transactions which would enable them to spend funds or maintain continued access after their access expires,\" and then relies on requiring all signed transactions to use the current account nonce. The nonce rule only ensures that at most one transaction can be included after expiry; it does not prevent that one transaction. Moreover, Section 4.3 deliberately permits off-chain signing without persistent TEE-blockchain state (\"we aim to allow sub-policies to sign transactions off-chain... at no cost\"), so the wallet contract cannot know that an expiring sub-policy already holds a valid signature that can spend its sub-balance. The formal model in Section 3.2 seals assets that have an outstanding signature by recording it in intst, but the implementation cannot maintain that record for off-chain signatures. Concretely, an access holder P can sign a transaction sending its full sub-balance to an external address, not broadcast it, let its sub-policy expire, have the access manager assign the same funds to Q, and then broadcast the old transaction. The transaction is valid on Ethereum, the funds leave the encumbered address, and Q's later transaction with the same nonce fails. Asset-time segmentation, described as the \"key guiding principle\" of Section 3.2, is therefore violated even in the idealized TEE model. This directly undermines the central claim that addresses can be safely rented, shared, or pooled with rich multi-user policies.","agreement_with_reader":"disagree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Liquefaction, a TEE-based wallet platform that 'encumbers' private keys so that signing rights over a single blockchain address can be rented, shared, or pooled among multiple users under programmable access-control policies. The authors argue that this breaks the Single-Entity Address-Ownership (SEAO) assumption underpinning many blockchain applications, with consequences for voting, soulbound tokens, airdrops, loyalty points, and transaction-history analytics. The paper introduces a formal access-control model (asset-time segmentation) in Section 3, describes a prototype implemented on Oasis Sapphire in Section 4, reports measured gas and latency costs, discusses a liveness fallback system and the Complete Knowledge countermeasure, and enumerates several adversarial and beneficial applications, including two Dark DAO variants. The central claim is that Liquefaction demonstrates a practical, private way to liquefy blockchain assets that were previously considered illiquid.","tokens_in":27456,"tokens_out":6962,"duration_ms":67096,"significance":"If the safety properties claimed for the policy model hold, this is a significant systems-and-security contribution. The paper ships an open-source implementation, reports concrete performance numbers (Figures 7 and 8), and provides working demonstrations such as the Dark DAO and soulbound-token encumbrance, which make the SEAO threat concrete rather than theoretical. The formal model in Section 3 is a useful starting point for reasoning about key-encumbrance policies, and the privacy definition in Section 3.3 is clearly stated. The paper also explicitly acknowledges its TEE trust assumptions in Section 4.4, which is honest and appropriate for a demonstration of feasibility. However, the implementation does not fully realize the formal model's pre-signing protections, and this gap directly affects the paper's core safety claim, as detailed in the major comments.","major_comments":[{"comment":"The pre-signing defense is incomplete and does not enforce asset-time segmentation. The paper states that requiring all signed transactions to use the current account nonce 'prevents sub-policies from sending more than one transaction after their access expires, fulfilling goal (4) to the maximum extent possible.' This explicitly concedes that one post-expiry transaction remains possible, but the paper's safety claim requires that no assets be spendable after reassignment. Concretely, a sub-policy P can obtain an off-chain signature transferring its full sub-balance to an address P controls, let its sub-policy expire, have the access manager assign the same destination/sub-balance to Q, and then broadcast the old transaction. Because no transaction has been included in the meantime, the account nonce is unchanged, the old transaction is valid on Ethereum, Q's later transaction with the same nonce fails, and the funds leave the encumbered address. This violates the 'key guiding principle' of Section 3.2 and the claim in Section 4.1 that asset-time segmentation is enforced globally by beta. The nonce rule only bounds the number of post-expiry transactions; it does not prevent the spend itself.","section":"Section 4.3, 'Pre-signing' paragraph"},{"comment":"The formal model's pre-signing protection does not carry over to the implementation. In Figure 1, LWSign records (P,m,ost) in intst, which permits beta to 'seal' assets with outstanding signatures, and Section 3.2 says policy updates are allowed only for unsealed assets. However, Section 4.3 explicitly aims to let sub-policies sign transactions off-chain 'without requiring changes to the TEE blockchain's state,' so the wallet contract has no record of outstanding off-chain signatures and cannot seal the corresponding assets. The transaction-attribution mechanism described later in Section 4.3 only decides which sub-policy's balance to debit after a transaction is included; it does not prevent the asset-time violation. This gap between the ideal functionality and the implementation is load-bearing. The authors should either require all spend-capable signing requests to be committed to the TEE blockchain (so that outstanding signatures are visible to the policy) or maintain an explicit sealing invariant in the policy contract; otherwise the safety claims for renting, sharing, and pooling must be weakened.","section":"Sections 3.2 and 4.3"},{"comment":"The statement that 'a Liquefaction wallet (including AM) cannot remove or reduce access already conferred' is not supported by the implementation. In the pre-signing attack, the AM grants access to Q after P's sub-policy expires, but P's earlier off-chain signature still allows P to spend the same funds. Thus Q's access is effectively reduced by P's action even though the AM did not explicitly revoke it. A formal invariant stating what 'access' means with respect to off-chain signatures, and a proof or implementation mechanism that preserves this invariant under all interleavings of LWSign, sub-policy creation, and expiration, would be needed to substantiate this claim.","section":"Section 4.1, 'Policy transitions'"}],"minor_comments":[{"comment":"Typo: 'applications can prevent mitigate against Liquefaction' should read 'prevent or mitigate against Liquefaction.'","section":"Section 5.2"},{"comment":"Typo: 'in addtion' should be 'in addition.'","section":"Section 4.3"},{"comment":"Typo: 'non-transferablilty' should be 'non-transferability.'","section":"Section 6.2"},{"comment":"Several entries have stray spacing, e.g., 'V otes,' 'V oters,' and 'T oken-Gated'; these should be cleaned up.","section":"Figure 10"},{"comment":"The idealized TEE assumption is stated clearly, but given the history of TEE side-channel attacks cited in [31], [59], [79], the paper should state more explicitly that the central safety claims hold only under this idealization, and that a TEE compromise would invalidate both confidentiality and policy enforcement. This would help readers calibrate the strength of the demonstration.","section":"Section 4.4"}],"recommendation":"major_revision","confidential_remarks":"The paper is well-written and the implementation is a genuine engineering effort, with open-source code and measurements. The main issue is not stylistic but substantive: the implementation does not realize the formal pre-signing sealing mechanism, and the concrete attack described above violates the paper's central safety claim. I believe this is fixable within the manuscript's scope—for example, by requiring all spend-capable signing requests to be committed on the TEE blockchain, or by explicitly narrowing the safety claims and documenting the residual risk. I would therefore recommend major revision rather than rejection. The authors should also consider adding a short security analysis of the revised protocol against the pre-signing attack, ideally with a state-machine invariant connecting the formal model to the implementation."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Best read as a demonstration paper: it makes key encumbrance concrete with a working wallet on Oasis Sapphire, measured costs, and real applications (Dark DAO, SBT rental with Flashbots). The first general policy model for encumbered keys (asset-time segmentation, sub-policy delegation tree) is a genuine new contribution; prior work had Dark DAOs and CK but not this framework. Credit where due: open-source code, gas/latency measurements, and the liveness fallback design are real work. The paper does not oversell its formal grounding; it states the idealized TEE model clearly.\n\nNow the soft spots, in proportion. The stress-test concern about pre-signing is correct. Section 4.3 requires all signed transactions to use the current nonce, which limits a sub-policy to at most one transaction after expiry—but that one transaction can be the one that spends funds reassigned to another sub-policy. The paper's own text says the nonce rule fulfills goal (4) 'to the maximum extent possible,' which is an honest admission that the defense is incomplete. The formal model in Section 3.2 seals assets with outstanding signatures in intst, but the implementation deliberately allows off-chain signing without persistent state, so the wallet contract cannot know that an expiring sub-policy holds a valid signature. That gap directly weakens the asset-time segmentation claim for the implementation. The fix is not trivial—Ethereum transactions have no native expiry—but it is addressable, e.g., by requiring all sub-policy signatures to be committed on the TEE chain before release, at the cost of the 'no-cost off-chain signing' goal.\n\nThe TEE security assumption is stated honestly and is standard for this line of work. The broader ecosystem impact claims are broader than what is implemented, but they read as a survey of implications rather than proof. Reproducibility would benefit from a pinned commit.\n\nBottom line: this is a serious systems and security paper. It deserves a rigorous peer review, with the pre-signing gap as the central referee issue. The flaw weakens the safety claim but does not kill the core result—that TEE-based key encumbrance is practical and systematically breaks the single-entity address assumption. I'd cite it if I worked on key encumbrance or DAO security, and I'd bring it to reading group.","headline":"Solid systems paper that makes the SEAO break concrete with working code, but the pre-signing defense leaves a real gap that weakens the asset-time segmentation guarantee.","tokens_in":28023,"tokens_out":4853,"would_cite":true,"duration_ms":48181,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Liquefaction shows that a blockchain address's private keys can be rented, shared, or pooled inside a trusted execution environment, privately breaking the assumption that one address equals one owner.","keywords":["trusted execution environments","key encumbrance","cryptocurrency wallets","Single-Entity Address-Ownership","Dark DAOs","soulbound tokens","complete knowledge","blockchain privacy"],"falsifier":"Extract the encumbered private key from the TEE during a rental period and sign a transaction the policy should have blocked; if the target blockchain accepts the signature, the claim that Liquefaction privately enforces ownership policies collapses.","tokens_in":26967,"feed_emoji":"🔑","tokens_out":6635,"duration_ms":59662,"temperature":0.7,"pith_summary":"The paper introduces Liquefaction, a wallet platform that places a user's private signing key inside a trusted execution environment and lets a programmatic policy decide when signatures are produced. Its claim is that this 'key encumbrance' breaks the standard assumption that one blockchain address is controlled by one entity, because the same key can be rented, shared, or pooled among many parties with no direct on-chain trace. A sympathetic reader should care because many applications—locked tokens, airdrops, loyalty points, soulbound tokens, DAO voting, and quadratic voting—assume address ownership is a stable identity signal. Liquefaction shows those assumptions can be undermined privately, and it also identifies beneficial uses and a countermeasure. If true, it shifts the burden onto any application that needs to prove a key is unencumbered.","feed_headline":"Blockchain keys can be rented and pooled with no on-chain trace","feed_subtitle":"TEE-encumbered keys let one address be shared, rented, or pooled with no on-chain trace.","key_machinery":"The central object is an encumbered key: a secret signing key generated and held only inside a TEE-backed wallet contract, so the human 'owner' never has direct access. Around it, the wallet manager offers four operations (create wallet, sign, update policy, verify access), and policies obey asset-time segmentation: every asset is exclusively controlled by one player until a deadline, fungible balances are split into sub-balances, and newly signed transactions must use the current nonce so a departing player cannot pre-sign a spend after access expires. Sub-policies form a delegation tree; each signature request is checked recursively from the leaf up to the root. This machinery converts a raw key into a rentable, shareable credential without leaving on-chain evidence of the sharing.","core_discovery":"Liquefaction is a wallet that demonstrates, by construction, that the Single-Entity Address-Ownership assumption is fragile. Instead of handing a private key to one user, it places the key in a trusted execution environment and attaches an access-control policy to it. The policy can rent out signing rights for a time window, partition fungible balances among sub-policies, and refuse to revoke already-granted access, while the policy itself is kept private from other players. Because the wallet can sign arbitrary Ethereum-style transactions, the same encumbered address can vote in DAOs, hold locked tokens, prove ownership of a soulbound token, or receive airdrops while the benefits are being consumed by someone else, and an on-chain observer cannot tell the address is shared.","pith_inferences":["Inference: If TEE-based key encumbrance becomes common, on-chain analytics and compliance tools that map addresses to individuals will need to treat address histories as potentially shared or rented, not as reliable identity signals.","Inference: The same mechanism that enables privacy-preserving DAOs and dusting-attack mitigation could erode the evidentiary value of on-chain provenance, challenging proofs of reserves and provenance-based claims.","Inference: The practical timeline depends on whether attested execution can resist side channels: hardened mainstream TEEs would make Liquefaction-style wallets cheap and ubiquitous, while persistent TEE breakability would keep the threat mostly theoretical."],"forward_implications":["A holder of vesting or locked tokens can sell effective control before the lockup expires without moving the tokens on-chain.","A DAO voter can privately delegate or sell a vote while the wallet's policy prevents the owner from overriding it.","Soulbound tokens, airdrop eligibility, loyalty rewards, and token-gated ticketing lose their one-account, one-owner guarantee.","Wash trading and fake-theft fraud become harder to detect because rented addresses can look unconnected.","Applications that want to preserve SEAO-based security can require complete-knowledge proofs that a key is not encumbered."],"supporting_citations":[{"why":"Introduces Dark DAOs and the original key-encumbrance concept for opaque on-chain vote buying, which Liquefaction implements and extends.","marker":"[23]"},{"why":"Defines and formalizes Complete Knowledge, the countermeasure Liquefaction recommends for applications that want to resist encumbrance.","marker":"[41]"},{"why":"Supplies the formal abstraction for attested execution secure processors that the paper uses as its idealized TEE security model.","marker":"[69]"},{"why":"Documents privacy flaws and native rollback protections in TEE-based smart-contract platforms like Sapphire, shaping the paper's threat-model assumptions.","marker":"[38]"},{"why":"Provides the standard description of Intel SGX as a TEE implementation, grounding the claim that TEEs can host encumbered keys.","marker":"[22]"},{"why":"An example of a side-channel attack on SGX that the paper explicitly excludes from its idealized model but cites as a known limitation.","marker":"[16]"}],"fun_headline_variants":["TEE wallet rents keys with no on-chain trace","Liquefy crypto: shared keys, zero on-chain footprint","Private key pooling via TEE, unseen on-chain","Break single-owner keys: TEE encumbrance","Rent, share, pool blockchain keys privately"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the TEE underlying the wallet is genuinely confidential, correct, and live, with side-channel attacks and deployment mistakes assumed away.","fun_headline_variants_meta":{"raw":{"variants":["TEE wallet rents keys with no on-chain trace","Liquefy crypto: shared keys, zero on-chain footprint","Private key pooling via TEE, unseen on-chain","Break single-owner keys: TEE encumbrance","Rent, share, pool blockchain keys privately"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000156,"raw_usage":{"total_tokens":1221,"prompt_tokens":951,"completion_tokens":270,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":567,"completion_tokens_details":{"reasoning_tokens":190}},"tokens_in":567,"tokens_out":270,"duration_ms":3613,"temperature":1.0,"reasoning_tokens":190,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T23:13:25.141634+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Extract the encumbered private key from the TEE during a rental period and sign a transaction the policy should have blocked; if the target blockchain accepts the signature, the claim that Liquefaction privately enforces ownership policies collapses.","supporting_citations":[{"cited_title":"On-chain vote buying and the rise of dark DAOs","cited_arxiv_id":null,"evidence_quote":"Introduces Dark DAOs and the original key-encumbrance concept for opaque on-chain vote buying, which Liquefaction implements and extends."},{"cited_title":"Complete knowledge: Preventing encumbrance of cryptographic secrets","cited_arxiv_id":null,"evidence_quote":"Defines and formalizes Complete Knowledge, the countermeasure Liquefaction recommends for applications that want to resist encumbrance."},{"cited_title":"Formal abstractions for attested execution secure processors","cited_arxiv_id":null,"evidence_quote":"Supplies the formal abstraction for attested execution secure processors that the paper uses as its idealized TEE security model."},{"cited_title":"SGXonerated: Finding (and partially fixing) privacy flaws in TEE-based smart contract platforms without breaking the tee","cited_arxiv_id":null,"evidence_quote":"Documents privacy flaws and native rollback protections in TEE-based smart-contract platforms like Sapphire, shaping the paper's threat-model assumptions."},{"cited_title":"Intel SGX explained","cited_arxiv_id":null,"evidence_quote":"Provides the standard description of Intel SGX as a TEE implementation, grounding the claim that TEEs can host encumbered keys."},{"cited_title":"Sgxpectre: Stealing intel secrets from SGX enclaves via speculative execution","cited_arxiv_id":null,"evidence_quote":"An example of a side-channel attack on SGX that the paper explicitly excludes from its idealized model but cites as a known limitation."}],"review_version":1}