Verifiable Computation with Trusted Execution Environments and On-Chain Digital Rights Tokens Bingle Stegmann Kruger1,2 and Co-Pierre Georg1
arXiv:2609.21728v1 [cs.CR] 18 Sep 2026
1
Frankfurt School of Finance & Management, 60322 Frankfurt am Main, Germany 2 University of Cape Town, Cape Town, South Africa [email protected]
Abstract. We present an architecture that enables data owners to combine private data into data pools using Trusted Execution Environments (TEEs) and manage these pools by issuing narrowly scoped computational rights, encoded as Digital Rights Tokens (DRTs), to third-party data analysts. Each DRT binds specific open-source code to a pool and is issued and redeemed on a distributed ledger. Data analysts can obtain the right to execute open-source code on the combined sealed data inside a TEE and receive the result from this code execution, but not the underlying data. We argue for a control-centric view of privacy in which creators retain ex ante control over how their data is processed. A reference implementation runs WebAssembly (WASM)/Python jobs over sealed datasets and records redemptions on Solana, illustrating the feasibility and limitations of the platform. Keywords: Trusted execution environments · Verifiable computation · Blockchain-based data markets · Data governance
1
Introduction
Data is a strategic asset with significant economic value [20]. Yet, contemporary infrastructures reward the entities that hold data rather than the individuals and organisations that create it [26]. Access-based sharing typically requires providers to disclose raw datasets, after which recipients can copy, combine, or repurpose the data beyond the intent of the original agreement. This mismatch between economic value and technical control underlies recurring privacy incidents [8,17,31] and constrains research and innovation that depend on sensitive datasets [15]. One approach to this governance challenge is information-centric networking [3]. Building on this line of research, Laoutaris and Iordanou [19] propose combining information-centric networking with Trusted Execution Environments (TEEs) and digital watermarking to let users regulate access to their data, receive compensation for authorised use, and foster ownership over digital information. They identify several challenges–two of which are particularly central–that any system aspiring to restore user control must overcome. First, such a system must enable the controlled sharing of data with third parties. Second, it must ensure that users are compensated for the use of their data.
2
B.S. Kruger and C.P. Georg
In this paper, we present an information infrastructure that not only solves both challenges but also satisfies a stricter control condition. An ideal information infrastructure would enable users not only to make their data available to third parties—who could then copy the data and use it in unauthorised ways— but also to control how third parties process their data. Digital watermarking can help to trace how third parties have used data and when it has been copied, but it does not prevent the unauthorised use of the data, and in many instances, one-time unauthorised use suffices to cause harm to the users who created the data. We propose a system that allows users to create personal data vaults, combine their data with the data of other users in joint data pools, and grant third parties the right to execute code over the joint data pools without losing control over their data in the sense of Definition 2. 1.1
Digital Privacy and Digital Rights
For legal scholars, privacy is a contested concept with different, overlapping, competing schools of thought [27]. These include: (i) the right to be let alone [29], (ii) limited access to the self [13], (iii) secrecy [24], and (iv) control over personal information [30]. For this paper, we focus on digital privacy,3 i.e., privacy in the context of “social and economic activity conducted online” as defined by Fainmesser, Galeotti, and Momot [12]. We seek a suitable definition of digital privacy, without binding ourselves to the constraints of existing information systems. Towards this end, first note that all four notions of privacy contain an element of privacy-as-control over information, which motivates a control-based understanding. Westin [30] defines privacy as “the claim of individuals, groups, or institutions to determine for themselves when, how, and to what extent information about them is communicated to others.” In Westin’s view, control over information is an expression of ownership: “personal information, thought of as the right of decision over one’s private personality, should be defined as a property right” [30]. We adopt a notion of ownership as control over a bundle of rights in the sense of Demsetz [10]. Taken together, this leads to the following definition: Definition 1. Information ownership is the control over a bundle of rights attached to an information. Since data is the physical embodiment of information, this definition also naturally translates to data ownership. This formulation also addresses Westin’s [30] and Solove’s [27] critique that creators cannot control downstream use by allowing each right in the bundle to be specified explicitly (e.g., by binding permitted code), yet Definition 1 still overlooks the relational nature of data [1], motivating an alternative definition in which users jointly control the bundle of rights: Definition 2. Information co-ownership is the joint control over a bundle of rights attached to an information. 3
Various cryptographic approaches exist to provide users with a basic notion of digital privacy, the simplest of which is for the user to encrypt their data before storing it.
Verifiable computation with TEEs and On-Chain DRTs
3
The definition says nothing about how joint control is organised. Consequently, any system that allows users to own their data must provide a governance system within which joint control can be organised. With all of the above, we are now able to define digital privacy for this paper: Definition 3. Digital privacy is a user’s control over information they created. Before outlining an information infrastructure that respects users’ digital privacy, it is necessary to specify how “rights attached to an information” can be encoded. To this end, consider the rights granted to the creator of an information in a specific setting, namely when storing information in a file on a computer with a Unix-based operating system [25]. Initially, Unix provided three file rights, read (r), write (w), and execute (x), to three categories of users: the file’s owner, members of the owner’s group, and all other users. Assuming that user1 created a file, the implied rights can be expressed as: user1 :: r1 w1 x1 user2 :: r2 w2 x2 .. .. .. . . . userN :: rN wN xN , where ri , wi , xi ∈ {0, 1} indicate the presence (1) or absence (0) of the right. Each useri , therefore, either has or does not have the right to read, write or execute a file, i.e., only up to three rights. Consequently, each user only has a minimal bundle of rights and only limited options to control these rights (e.g., transfer them to another user). On Unix, the operating system provides some protection for users’ rights, with the exception of root, who can always override the file permissions. While a discussion about the legal status and nature of digital rights is beyond the scope of this paper, our goal is to create an information infrastructure that recognises digital rights as inalienable rights. The Universal Declaration of Human Rights [28] recognises privacy as a human right in Article 12 and the right to own property in Article 17. If taken seriously, this implies two criteria that an information infrastructure should satisfy: First, the owner or group of owners of an information must be able to define which digital rights they hold. Consequently, they must also be able to decide which rights to grant to others. And second, the owner or group of owners of an information must not be deprived of their rights. To satisfy the first criterion, consider an information infrastructure that allows rights (r) of the type: user1 :: r11 . . . rK 1 user2 :: r12 . . . rK 2 .. .. .. . . . userN :: r1N . . . rK N, where K is the total number of rights implemented by the infrastructure and rki ∈ {0, 1} indicates whether useri holds right k (1) or not (0).
4
B.S. Kruger and C.P. Georg
As the number of possible rights is very large, we have decided to represent a right as a Digital Rights Token (DRT). A DRT abstracts an individual right into a tokenised form that can be issued, transferred, and redeemed within the infrastructure. A DRT is defined by a unique name, a short description, a unique data pool address to which the DRT refers, and a unique reference to a piece of code which implements the right. DRTs also include the token supply and the unique address of a smart contract that manages the tokens. Specifically, the smart contract manages the issuance and ownership of tokens and their distribution in the primary market, as well as their redemption. Definition 4 summarises the structure of a DRT. Definition 4. A Digital Rights Token (DRT) is an on-chain digital asset representing specific, verifiable rights concerning a data pool. Each DRT corresponds to one unit of a specific right. A DRT has the following properties: – drtType : "append" (right), or "wasm" | "python" (execution runtime) – mintAddress : Address (a Base58-encoded address) – managingPoolAddress : Address (pool account address) – poolName : String (human-readable dataset/pool name) – supply, cost : N (nonnegative integers for token supply and cost) – githubUrl : URL – codeHash : Hash (cryptographic hash of approved code) Privacy as control over use. Our design targets control-centric privacy where creators decide how their data may be processed (the allowed computations, encoded in the DRTs), by whom (DRT holder), and under which terms (price, quotas, and output constraints). Accordingly, data creators retain ex ante control over how their data is processed rather than who may copy it. This notion recognises that outputs may leak bounded information–by design–and makes that trade-off explicit and enforceable through mechanisms and implementation rather than policy statements alone. In contrast to watermarking or contractual restrictions, the permitted computation and its runtime environment are bound to on-chain state and an attested TEE. Contributions. In this paper, we make the following contributions: – We formalise digital rights as a K-dimensional rights vector and instantiate each right as a Digital Rights Token (DRT) that encodes per-computation licences over a specific sealed data pool, including supply, price, code reference, and a code hash. This enables the creation of secondary markets while ensuring that no data is exposed beyond what is explicitly permitted by the authorised computations. – We present an information infrastructure with a redeem-to-execute path that binds a redeemed DRT to a specific, auditable program (open-source code with an expected hash value) and an attested TEE. The DRT’s onchain immutability and an oracle trigger ensure that only authorised code executes, while RA-TLS channels and per-pool sealing keys ensure raw data never leaves the enclave and only permitted results are returned.
Verifiable computation with TEEs and On-Chain DRTs
5
– We provide a proof-of-concept open-source implementation demonstrating end-to-end feasibility: DRT issuance and redemption on Solana and enclave execution of WASM/Python jobs over sealed pools. While not yet complete, the implementation highlights both the practicality of our approach and current limitations (e.g., oracle trust, side-channel risks, and output leakage). 1.2
Scope and limitations
We prioritise control over secrecy as outputs may reveal bounded information determined by the permitted computation, and we make this trade-off explicit. Our implementation is minimal and should be read as a proof of concept rather than a complete system. The implementation currently supports CPU-based TEEs and enclaved execution of basic WASM/Python programs, but does not include multi-oracle consensus, GPU TEEs, or advanced output-privacy mechanisms beyond limiting the number of DRTs (e.g., rate limiting, aggregation-only schemas, or differential-privacy wrappers). Runtime failures of redeemed DRTs are not yet handled gracefully. In addition, known limitations of Intel SGX, such as side-channel vulnerabilities, apply to our prototype. Our contribution demonstrates how on-chain digital rights, enclave attestation, and tokenised incentives can be combined into a cohesive mechanism for control-centric data sharing. Future work. In this paper, we focus on presenting an information infrastructure using DRTs for verifiable computation. We leave a systematic performance evaluation of our implementation to future work, including execution overhead and the scalability of DRT issuance on-chain. Other avenues for exploration include extending support to GPU-enabled TEEs, integrating stronger outputprivacy mechanisms (e.g., differential privacy or aggregation-only schemas), incorporating multiple oracle nodes, and analysing incentive and governance models for data contributors and data analysts.
2
System Overview
Designing an alternative information infrastructure for information co-ownership must address established dimensions of information infrastructures. Hanseth and Monteiro [16] identify six aspects of information infrastructures. Information infrastructures (i) have an enabling function, (ii) are shared by a collection of users and user groups, (iii) are open, (iv) are socio-technical systems, (v) are connected and interrelated ecologies of networks, and (vi) develop through extending the installed base. We propose an alternative information infrastructure that satisfies these six aspects by enabling users to own information as per Definition 2, where co-ownership entails joint control over the rights attached to an information. Consequently, our system inherently aligns with the first aspect of information infrastructures.
6
B.S. Kruger and C.P. Georg
Frontend
Issue transactions & Query Blockchain
Blockchain SDK
1
Enclave attestation & deployment, encrypted channel to transmit data
Backend
3
2 Execution Enclave N
Attest
Enclave Deployment Service
Attest
Blockchain Execution Enclave 1
4
Smart Contract
Receive veri cation requests from execution enclaves & transmit Blockchain data
Oracle Nodes 5
Query & return Blockchain State
fi
Fig. 1. Architecture of the proposed information infrastructure that facilitates information co-ownership.
Our system4 consists of five key components, shown in Figure 1. First, the frontend application provides users with an interface to create pools, issue and redeem DRTs, and manage contributions. Second, the enclave deployment service provisions and manages new enclaves for each data pool, maintaining isolation across pools. Third, execution enclaves, implemented using TEEs based on Intel SGX [4,9], manage each data pool by sealing and unsealing5 data (data always remains in the enclave), verifying DRT redemptions via an oracle, and executing only the computations authorised by the DRT. These (attestable) enclaves essentially function as an API facilitating secure computation and controlled data exchange between components. Fourth, the rights attached to each dataset (i.e., data pool) are represented as Solana SPL tokens and recorded on the Solana testnet. Solana was chosen due to its low fees, smart-contract flexibility, and configurable crypto-assets, although other permissionless blockchains with smart contract capabilities could be used with minor implications for our system. Fifth, oracle nodes bridge the blockchain and the execution enclaves by monitoring token redemptions and conveying blockchain state updates, ensuring that only authorised computations are executed inside the TEE. Together, these components enforce co-ownership by coupling tokenised rights (DRTs) with verifiable computation inside attested enclaves. 4
GNU AGPL v3; Zenodo: https://doi.org/10.5281/zenodo.21874955 (core library), https://doi.org/10.5281/zenodo.21874949 (enclave deployment service). 5 Encryption and decryption using an enclave-specific key.
Verifiable computation with TEEs and On-Chain DRTs
2.1
7
User Roles and Workflows
The system defines four primary roles, which are not mutually exclusive: data creators, code creators, data contributors, and data analysts. A fifth role, traders, may emerge where DRTs are exchanged for profit. Data creators define a schema (e.g., JSON) and instantiate a pool by specifying permissible DRTs and their configurations (e.g., supply and cost). A data pool (Section 2.2) consists of a data package and an associated smart contract that manages the issuance, distribution, ownership and redemption of DRTs. The enclave deployment service deploys a new enclave with our library, while the associated smart contract mints the DRTs that govern the pool. Code creators provide the open-source code referenced by these DRTs. Data contributors join existing pools by purchasing and redeeming an AppendDRT, uploading schema-conformant data to the enclave over an encrypted channel, and receiving contributor tokens that track pool ownership and revenue shares. Data analysts obtain computational access by purchasing and redeeming an ExecuteDRT, each binding a single open-source program to a pool. The redemption of DRTs is recorded on-chain and relayed by oracles to the enclave, which unseals the data, verifies the code hash, and executes only the permitted computation. Results are returned over an encrypted channel to the analyst, while raw data remains sealed. Contributor royalties are distributed via smart contracts in proportion to ownership tokens, enabling revenue sharing without disclosure of underlying data. Data Lifecycle. To make the role of each component concrete, we trace data through the system from creation to result delivery. The lifecycle has four phases: (P1) Pool creation, (P2) Contribution, (P3) Redemption and execution, and (P4) Settlement. During P1 (Algorithm 1), the data creator defines a schema and the permitted computations for the pool (i.e., the DRTs). Each permitted computation is admitted to an allow list as a (code reference, code hash) pair and is associated with an ExecuteDRT.6 The smart contract registers the pool and its DRT mints. The deployment service launches a new enclave, and the creator optionally verifies the enclave through remote attestation before provisioning encrypted seed data.
Algorithm 1 P1: Pool creation Require: Data creator C, Solana program S, Enclave E, Deployment service D, Pool schema σ, Code references rj , Code hashes hj 1: C defines schema σ, permitted computations (DRTs), and pricing 2: C publishes permitted computations as allow-listed pairs (rj , hj ) 3: S registers the pool and creates the corresponding DRT mints 4: D provisions a new enclave E for the pool 5: E publishes an attestation quote binding its code and configuration 6: C optionally verifies the attestation and provisions encrypted seed data to E 6
AppendDRT is native to the SDK and therefore has no code reference or hash.
8
B.S. Kruger and C.P. Georg
For P2 (Algorithm 2), a contributor buys an AppendDRT and redeems it for the target pool. The smart contract burns the token and emits a redemption event, which the oracle relays to the enclave. The contributor uploads a record over an encrypted channel. The enclave validates the record against the pool schema and seals it. This binds the record to the attested state, so other enclave images, including downgraded ones, cannot unseal it. The contract records the contributor’s pool share for later royalty distribution. Algorithm 2 P2: Contribution Require: Contributor Ui , Solana program S, Oracle O, Enclave E, Pool schema σ, DRT type AppendDRT, Encrypted record xi 1: procedure Contribute(Ui , xi ) 2: Ui redeems an AppendDRT for the target pool 3: S burns the token and emits a redemption event 4: O relays the redemption event to E 5: Ui sends encrypted record xi to E over the attested channel 6: E validates xi against σ and seals xi into the pool state 7: S records Ui ’s contribution share 8: end procedure
Under P3 (Algorithm 3), an analyst buys an ExecuteDRT bound to a specific (code reference, code hash) pair from the pool’s allow list and redeems it against the smart contract. The oracle resolves the code reference and forwards the candidate computation to the enclave. The enclave recomputes the code hash, checks it against the on-chain record, and verifies that the computation is approved for the pool. After verification, the enclave unseals the pool, executes the computation, and enforces the output policy7 associated with the DRT. Raw records do not leave the protected boundary at any step and only the policy-approved (DRT) result is released. Algorithm 3 P3: Redemption and execution Require: Analyst A, Solana program S, Oracle O, Enclave E, DRT type ExecuteDRT, Code references rj , Code hashes hj , Computation j 1: procedure ExecuteJob(A, rj , hj , j) 2: A redeems an ExecuteDRT bound to (rj , hj ) 3: S burns the token and emits a redemption event carrying (rj , hj ) 4: O resolves rj and forwards candidate computation j to E as (rj , hj ) 5: E verifies Hash(j) = hj 6: E unseals the pool and executes j 7: E returns j(pool) to A over an encrypted channel ▷ raw records never leave E 8: end procedure
7
The declared output shape or disclosure constraints are described in Section 2.3.
Verifiable computation with TEEs and On-Chain DRTs
9
Algorithm 4 P4: Settlement Require: Analyst A, Solana program S, Enclave E, Analyst payment p 1: procedure Settle(A, p) 2: A receives j(pool) from E 3: S distributes the royalty share of p to the contributor-token holders 4: S records the redemption and computation identifier 5: end procedure
Finally, for P4 (Algorithm 4), the enclave returns the result to the analyst over an encrypted channel. A share of the analyst’s payment is routed on-chain to the contributor-token holders pro rata. Revenue therefore follows contribution without requiring disclosure of which contributor supplied which record. The combination of (i) on-chain provenance for every redemption and payout and (ii) attested provenance for every enclave provides a tamper-evident audit trail of who computed what, on which dataset, and under which approved code. 2.2
Data Pools
A data pool is the abstraction that groups compatible contributions under a common schema and execution policy. A data pool is defined as follows: Definition 5. A data pool is a data structure σ, r, C, Kp , a where – σ is a schema, – r is a vector of permitted rights realised as DRT mints, – C is an append-only multiset of contributor records governed by σ, – Kp is a sealing key held only inside the pool’s enclave, and – a is the Solana program-derived address (PDA) that anchors r to the pool. A pool is therefore a multi-contributor data set bound to a fixed schema and a fixed set of computations (DRTs), not a single user’s upload. A creator opens a pool when there is value in making a class of records jointly analysable, and contributors then append records under the same schema. The AppendDRT mechanism enforces the attribution. Pools live in their own enclaves, and the trade-off is deliberate. Sealing keys are per-pool, so a compromise of one enclave cannot unseal records of another. The working set of an enclave is bounded by a single pool, which keeps memory pressure tractable, and the enclaves scale with the number of pools rather than with the volume of data. Pool creation is the only operation that requires a new enclave to be provisioned, and this is an infrequent operation amortised over the life of the pool since contributions and redemptions reuse the same enclave. Where pools are small or low-risk, multiple pools can be co-located in a single enclave by isolating them with per-pool sealing keys and schema-tagged interfaces. The prototype uses the simpler one-poolper-enclave configuration. Contributors and analysts choose pools through the registry maintained on-chain by the smart contract. Each pool advertises its schema, its enclave measurement, the set of DRTs, and the redemption history.
10
2.3
B.S. Kruger and C.P. Georg
Governance: Resale, Permitted Computations, and Output
The code permitted by a DRT is fixed by the pool creator during pool creation (Algorithm 1) and is visible to all contributors and analysts. The creator therefore defines the allowable DRTs for the pool, including the associated code and terms (e.g., output policy). Three properties hold, under the platform and authorisation assumptions in Section 2.4, regardless of operator behaviour. First, on resale, DRTs are freely transferable, but redeeming a DRT burns it, so the total number of times a computation can run on a pool equals the supply chosen during pool creation. Second, on permitted computations, each non-append DRT names an open-source program and a hash of its compiled artefact, and before execution the enclave fetches the program and refuses to run if the hash does not match. Third, on output controls, output is bounded per redemption by the open-source code referenced by each DRT and across redemptions by the DRT’s burning supply. The pool creator therefore determines which computations may run on the pool, how many times they may run, and what form their outputs may take. For example, a creator may require aggregate-only outputs together with composable in-enclave wrappers such as differential-privacy noise or minimum-cohort guards. 2.4
Threat Model and Deployment Assumptions
We separate trust into a platform layer (the TEE and its remote attestation) and an authorisation layer (the on-chain rules governing which code may run on which pool). At the platform layer we rely on standard TEE guarantees of code authenticity, runtime integrity, and confidentiality of data in use. We assume an untrusted host where infrastructure operators could in principle substitute malicious services without users noticing. To mitigate this, we use RA-TLS (Remote Attestation over TLS) to ensure that users only establish secure channels with genuine enclaves, and data at rest is protected by enclave-specific sealing keys. The prototype runs on Azure DCsv3 [21] confidential VMs, but the design is TEE-agnostic, with AMD SEV-SNP [2], Intel TDX [18], and ARM CCA [5] as viable alternatives. The authorisation layer rests on two assumptions. (T1) Hardware: the TEE faithfully executes the loaded image and remote attestation binds its measurement to a verifiable quote. We accept the published adversary model for the underlying TEE family and treat physical attacks and microarchitectural side channels [6,7,23] as out of scope. (T2) Authorisation: pool creators choose, and contributors accept, a set of computations (DRTs) whose outputs they are willing to release. The DRTs are public, immutable, and bound to on-chain code hashes. This split clarifies that the residual risk of authorising malicious code (DRT) is a T2 concern rather than a T1 failure—the hardware proves which code ran—governance decides whether that code should have run. Permitted computations (DRTs) are open-source Python scripts or WASM binaries that users can verify via hashes. The DRT redemptions are recorded on-chain and relayed to enclaves by oracle nodes (we start with a single oracle node, but the design supports k-of-n consensus for stronger guarantees).
Verifiable computation with TEEs and On-Chain DRTs
11
Our platform prioritises control rather than secrecy, as computation results are returned. Thus, users cede some privacy, but the chosen computation (DRT) limits the scope of leakage and to whom. Ensuring that only approved code runs is the key challenge, as attestation and hash verification constrain execution. Given the known limitations of TEEs, we treat them as an enabler rather than a solution in themselves. Our contribution lies in coupling attested compute with on-chain rights to operationalise enforceable control. Concretely, this requires a layered stance: (i) minimise the trusted computing base with narrow enclave interfaces; (ii) bind code and configuration to attestation, require signed updates, and block rollbacks; (iii) constrain outputs via aggregation, rate limiting, and computation-specific caps; and (iv) harden operations with audit logs, deny/allow lists of measurements, and eventually multi-oracle consensus. The novelty lies in integrating these layers so that data creators retain ex ante, enforceable control over how their data is processed. Appendix A discusses recurring engineering challenges, and Appendix B addresses output resale and compositional reconstruction.
3
Feasibility and Preliminary Evaluation
Our implementation demonstrates the end-to-end feasibility of the proposed information infrastructure. Specifically, it supports the creation of data pools, the issuance and redemption of DRTs as Solana SPL tokens, and the execution of WASM and Python jobs over sealed datasets using Intel SGX. Our prototype demonstrates that the core workflows can be realised in practice: pool instantiation, token redemption, code verification, and in-enclave execution. We present the prototype as evidence that verifiable, control-centric computation is technically feasible, and we hope this forms a foundation for further evaluation. A key inhibitor in the current implementation is the time required to initialise a new enclave for each data pool, although this is assumed to be an infrequent operation. Moreover, throughput under varying pool sizes requires further investigation, as our initial tests rely on small datasets and simplistic DRT-authorised code (e.g., computing mean or median values). Our work connects to several lines of research. First, privacy-preserving data sharing has traditionally relied on cryptographic primitives such as secure multiparty computation [33], homomorphic encryption [14], or frameworks such as differential privacy [11]. However, these approaches prioritise secrecy but often suffer from performance or usability limitations. Second, TEEs such as Intel SGX [4,9] have been applied to protect sensitive computations, though prior work highlights their side-channel vulnerabilities [6,7,23]. Third, tokenised data governance has been explored in blockchain-based data markets [22,32], but such systems typically emphasise access rights, licensing, or accountability without enforceable control over what computations are performed on the underlying data. Our contribution lies in integrating these strands by binding narrowly scoped digital rights (DRTs) to auditable code and attested TEEs, thereby operationalising privacy as control over use rather than secrecy alone.
12
B.S. Kruger and C.P. Georg
References 1. Acemoglu, D., Makhdoumi, A., Malekian, A., Ozdaglar, A.: Too much data: Prices and inefficiencies in data markets. American Economic Journal: Microeconomics 14(4), 218–256 (November 2022) 2. Advanced Micro Devices (AMD): AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and More. White paper (2020) 3. Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., Ohlman, B.: A survey of information-centric networking. IEEE Communications Magazine 50(7), 26–36 (2012) 4. Anati, I., Gueron, S., Johnson, S., Scarlata, V.: Innovative technology for CPU based attestation and sealing. In: Proceedings of the 2nd international workshop on hardware and architectural support for security and privacy. vol. 13. ACM New York, NY, USA (2013) 5. Arm: Arm CCA Security Model. Revision 1.0, Document Number DEN0096 (Aug 2021) 6. Bulck, J.V., Minkin, M., Weisse, O., Genkin, D., Kasikci, B., Piessens, F., Silberstein, M., Wenisch, T.F., Yarom, Y., Strackx, R.: Foreshadow: Extracting the keys to the Intel SGX kingdom with transient out-of-order execution. In: 27th USENIX Security Symposium (USENIX Security 18). pp. 991–1008. USENIX Association, Baltimore, MD (Aug 2018) 7. Chen, G., Chen, S., Xiao, Y., Zhang, Y., Lin, Z., Lai, T.H.: SgxPectre: Stealing Intel secrets from SGX enclaves via speculative execution. In: 2019 IEEE European Symposium on Security and Privacy (EuroS&P). pp. 142–157. IEEE (2019) 8. Cheng, L., Liu, F., Yao, D.: Enterprise data breach: Causes, challenges, prevention, and future directions. Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery 7(5), e1211 (2017) 9. Costan, V., Devadas, S.: Intel SGX explained. Cryptology ePrint Archive, Paper 2016/086 pp. 1–118 (2016) 10. Demsetz, H.: Toward a theory of property rights. The American Economic Review 57(2) (1967) 11. Dwork, C.: Differential privacy. In: Proceedings of the 33rd International Conference on Automata, Languages and Programming. pp. 1–12. ICALP’06, SpringerVerlag, Berlin, Heidelberg (2006) 12. Fainmesser, I.P., Galeotti, A., Momot, R.: Digital privacy. Management Science 69(6), 3157–3173 (2023) 13. Gavison, R.: Privacy and the limits of law. The Yale Law Journal 89(3), 421–471 (1980) 14. Gentry, C.: Fully homomorphic encryption using ideal lattices. In: Proceedings of the Forty-First Annual ACM Symposium on Theory of Computing. pp. 169–178. STOC ’09, Association for Computing Machinery, New York, NY, USA (2009) 15. Goldfarb, A., Tucker, C.: Privacy and innovation. Innovation Policy and the Economy 12(1), 65–90 (2012) 16. Hanseth, O., Monteiro, E.: Understanding information infrastructure (2000) 17. Hinds, J., Williams, E.J., Joinson, A.N.: “It wouldn’t happen to me”: Privacy concerns and perspectives following the Cambridge Analytica scandal. International Journal of Human-Computer Studies 143, 102498 (2020) 18. Intel: Intel Trust Domain Extensions. White paper (2020) 19. Laoutaris, N., Iordanou, C.: What do information centric networks, trusted execution environments, and digital watermarking have to do with privacy, the data
Verifiable computation with TEEs and On-Chain DRTs
13
economy, and their future? SIGCOMM Comput. Commun. Rev. 51(1), 32–38 (Mar 2021) 20. McKinsey & Company: Financial data unbound: The value of open data for individuals and institutions (2021), https: //www.mckinsey.com/industries/financial-services/our-insights/ financial-data-unbound-the-value-of-open-data-for-individuals-and-institutions, last accessed 2026/05/07 21. Microsoft: ‘DC’ family general purpose VM size series (2026), https: //learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/ dc-family?tabs=dcasv6%2Cdcasv5%2Cdcasccv5%2Cdcsv3, last accessed 2026/05/07 22. Missier, P., Bajoudah, S., Capossele, A., Gaglione, A., Nati, M.: Mind my value: a decentralized infrastructure for fair and trusted IoT data trading. In: Proceedings of the Seventh International Conference on the Internet of Things. IoT ’17, Association for Computing Machinery, New York, NY, USA (2017) 23. Murdock, K., Oswald, D., Garcia, F.D., Van Bulck, J., Gruss, D., Piessens, F.: Plundervolt: Software-based fault injection attacks against Intel SGX. In: 2020 IEEE Symposium on Security and Privacy (SP). pp. 1466–1482. IEEE (2020) 24. Posner, R.A.: The Economics of Justice. Harvard University Press, Cambridge, MA, USA (1983) 25. Ritchie, D.M., Thompson, K.: The UNIX time-sharing system. Communications of the ACM 17(7), 365–375 (Jul 1974) 26. Sadowski, J.: When data is capital: Datafication, accumulation, and extraction. Big Data & Society 6(1) (2019) 27. Solove, D.J.: Understanding Privacy. Harvard University Press, Cambridge, MA, USA (2008) 28. United Nations General Assembly: Universal declaration of human rights. Paris (1948) 29. Warren, S.D., Brandeis, L.D.: The right to privacy. 4 Harvard Law Review 193 (1890) 30. Westin, A.F.: Privacy and Freedom. Washington and Lee Law Review, NY, USA (1967) 31. Wheatley, S., Maillart, T., Sornette, D.: The extreme risk of personal data breaches and the erosion of privacy. The European Physical Journal B 89(1), 7 (2016) 32. Xiao, Y., Zhang, N., Li, J., Lou, W., Hou, Y.T.: PrivacyGuard: Enforcing private data usage control with blockchain and attested off-chain contract execution. In: Chen, L., Li, N., Liang, K., Schneider, S. (eds.) Computer Security – ESORICS 2020. pp. 610–629. Springer International Publishing, Cham (2020) 33. Yao, A.C.C.: How to generate and exchange secrets. In: 27th Annual Symposium on Foundations of Computer Science. pp. 162–167 (1986)
A
Engineering Challenges
Although the system combines familiar building blocks (a TEE, a smart contract, an oracle, and a frontend), prototyping surfaced five non-trivial challenges that we expect to recur in any deployment of this pattern.
14
B.S. Kruger and C.P. Georg
C1: Binding on-chain rights to off-chain execution. The DRT contract is onchain and the enclave is off-chain. The link between them must satisfy both safety and liveness. Safety requires that one redemption authorises at most one execution, even if the same event is forwarded multiple times. Liveness requires that a valid redemption eventually reaches the enclave. Our prototype uses a single oracle, so a malicious or faulty oracle can delay, censor, or omit an execution. However, it should not cause a correctly implemented enclave to execute an unauthorised computation, provided that forwarded redemptions are checked against authenticated ledger state rather than trusted as oracle assertions. Because redemptions are durably recorded on-chain, missed events can be recovered and reprocessed from ledger history. However, putting a full RPC client, Solana verifier, or similar blockchain logic inside the enclave would increase the trusted computing base and is therefore undesirable. The enclave should remain minimal and only verify the smallest necessary evidence. Threshold-based oracle quorums can improve liveness and reduce reliance on a single relay, but require deduplication of forwarded events inside the enclave. C2: Reconciling code identity. A program admitted to a pool’s DRT library carries two identities, namely the source repository (e.g., a GitHub link) and the cryptographic hash of the program. Any change to the source, however minor, will produce a different hash and invalidate the corresponding DRT until the source is reverted. This rigidity is a feature rather than a bug, since it guarantees that what an analyst redeems is exactly what was admitted, but it places the burden of versioning on pool creators. In practice, code creators can publish revised programs as new DRTs alongside the originals rather than overwriting them. We leave more sophisticated approaches, such as semantic versioning bound to attestation policies, to future work. C3: Operational hygiene of attestation. Attestation evidence is not write-once. Collateral expires, signing keys rotate, and TEE microcode receives advisories. A “provision once, run forever” flow breaks under any of these. The deployment service should re-attest enclaves on every restart and on a daily schedule, and reject enclaves whose most recent quote is stale. This is a small operational detail with practical consequences for any long-lived confidential-computing deployment. Deterministic builds of the underlying SDK (used per enclave) are also an essential requirement for attestation. C4: Schema evolution. Once a pool is sealed under a schema, that schema is effectively immutable. Changing it would either invalidate sealed records or require a re-encryption step that exposes the records to whoever performs it. The prototype handles migration by opening a new pool under the revised schema and inviting contributors to re-deposit, which preserves the integrity of the original pool but loses the historical contributor base unless every member re-engages. This is workable for the data classes we target but genuinely costly at scale, and we flag it as an open problem.
Verifiable computation with TEEs and On-Chain DRTs
15
C5: Authorisation of programs. Even with hash-bound execution, a contributor can be socially engineered into joining a pool whose DRTs contain a malicious program. Hardware-based attestation can prove which program ran (i.e., the underlying SDK runtime), but it cannot decide whether the program referenced by the DRT is benign. The DRT library makes this risk visible at admission rather than at execution, although eliminating it lies outside the remit of any single protocol layer (Section 2.4, T2).
B
Output Resale and Composition Risk
Output resale. Once a DRT is redeemed and a result is returned, the analyst possesses a digital artefact that the protocol cannot itself prevent from being copied or resold (i.e., the computation result). This is intrinsic to control-centric privacy: we govern computation, not the downstream handling of derived outputs. Two mechanisms mitigate the impact. First, supply-bounded DRTs cap the number of times any computation runs against a pool, so resale of a result does not enable unbounded re-execution. Second, output policies (DRTs) chosen by the pool creator bound the value of a single result to a would-be reseller. Compositional reconstruction. A pool creator who admits a sufficiently expressive set of DRTs may enable reconstruction of individual records by combining outputs across redemptions. Our design surfaces this risk at admission by making the full DRT set, code references, and supplies public on-chain before any contribution. Creators are therefore responsible for choosing computations whose joint output channel is acceptable, and contributors observe this set before redeeming an AppendDRT. Formal composition analysis (e.g., differential-privacy budgets across DRTs, or query-set auditing) is a natural extension but lies outside the scope of this paper.