The universal provenance layer
Developers often struggle with the poor user experience and complexity of current blockchain systems. To address these challenges, Livy is introduced as the universal provenance layer, a language-agnostic execution layer for verifiable computing, leveraging Intel TDX (Trust Domain Extensions) Trusted Execution Environments (TEEs) to enable trusted off-chain computation using familiar languages like Rust, Go, and JavaScript.
Livy's approach compiles application source code within a TDX enclave and executes it with optional input parameters, producing both the execution result and a cryptographic quote (attestation) from the enclave. This TDX quote encapsulates the enclave’s identity, runtime integrity measurements (RTMRs), and a payload containing the compiled binary’s hash, the provided inputs, and the resulting outputs.
Blockchain smart contracts can verify the validity of this quote on-chain, confirming the computation’s integrity and correctness without rerunning the code. This design delivers near-native performance without requiring any domain-specific language, provides full provenance of the execution, and offers cross-chain compatibility, significantly simplifying the development of trustworthy off-chain services.
In verifiable computing, a Prover runs a function y=F(x,w) and generates a compact proof showing that the output y is correct for program F, public input x, and witness w. A Verifier can validate this short proof without re-executing the function. Every verifiable-computing scheme rests on certain trust assumptions about the underlying primitives or setup.
Engineers still face a steep learning curve when they step into the blockchain world. The hurdle grows even higher with cross-layer verifiable computation: it’s one thing to run a function once, but quite another to convince every chain that the result is correct.
Livy’s solution is a language-agnostic execution layer that slots any containerised compiler into an Intel TDX Trusted Execution Environment (TEE). The compiler turns source code into a native binary; the enclave executes that binary with optional runtime parameters and emits both the output and a signed quote.
No new DSLs: Rust, Go, JavaScript—anything that compiles—gets near-native speed and a hardware-level proof out of the box. The quote includes the enclave’s identity (MRENCLAVE), runtime-integrity metrics (RTMRs), and a hash binding binary, inputs, and outputs. Running transactions inside a TEE removes the need to wait for network consensus, delivering millisecond-level latency and throughput comparable to centralized systems. A trading engine, for example, can match orders and update balances almost instantaneously, providing real-time user feedback. Because the enclave deterministically seals both transaction order and execution, it also suppresses Maximal Extractable Value (MEV) by preventing any external reordering or front-running.
Livy lets developers use verifiable computation without forcing them to learn a new DSL. Keep your Rust, Go, or JavaScript code on GitHub; Livy fetches the repository, compiles it inside the Intel TDX enclave, and produces a native binary. When that binary runs with a given input, the enclave returns the program’s output plus an attestation packet. See Fig 2
We’ll hash the value and tuck it into the TEE’s 32-byte custom-data slot. When the enclave produces its attestation quote, that hash rides along capturing exactly what ran and with which inputs so anyone can later verify the execution.
During verification, the verifier decodes the hex-encoded TD10 quote into raw bytes, fetches Intel PCS collateral (PCK cert chain, TCB info, and QE identity), and validates the quote’s signature against that collateral to be sure the platform’s TCB is current and not revoked.
Once the cryptographic checks pass, the verifier pulls out the 64-byte report_data field, strips any zero padding, and recovers the payload typically a hash of the code and/or user inputs. If everything checks out, you’ve proved the enclave was genuine, uncompromised, up-to-date, and cryptographically bound to the exact data embedded in report_data.
The Provenance Layer serves as a trusted verification node within the attestation, executing compiled binaries with specified inputs while simultaneously capturing and validating hardware-backed attestations. This critical infrastructure component maintains an immutable record of all executions, including binary hashes, input parameters, execution outputs, and their corresponding TDX quotes, enabling deterministic reproduction of any computation.
By exposing a verification API, the Provenance Layer allows any third party to independently validate that a specific computation was executed within a genuine TEE without requiring access to the original hardware. This creates an end-to-end chain of trust from code submission through execution to verification, establishing cryptographic proof that the claimed outputs genuinely resulted from the specified inputs being processed by the attested code, effectively creating a tamper-evident, auditable trail of computational provenance.
Join the waitlist: https://newsletter.livylabs.xyz
Follow us on X: https://x.com/livylabs
Developers often struggle with the poor user experience and complexity of current blockchain systems. To address these challenges, Livy is introduced as the universal provenance layer, a language-agnostic execution layer for verifiable computing, leveraging Intel TDX (Trust Domain Extensions) Trusted Execution Environments (TEEs) to enable trusted off-chain computation using familiar languages like Rust, Go, and JavaScript.
Livy's approach compiles application source code within a TDX enclave and executes it with optional input parameters, producing both the execution result and a cryptographic quote (attestation) from the enclave. This TDX quote encapsulates the enclave’s identity, runtime integrity measurements (RTMRs), and a payload containing the compiled binary’s hash, the provided inputs, and the resulting outputs.
Blockchain smart contracts can verify the validity of this quote on-chain, confirming the computation’s integrity and correctness without rerunning the code. This design delivers near-native performance without requiring any domain-specific language, provides full provenance of the execution, and offers cross-chain compatibility, significantly simplifying the development of trustworthy off-chain services.
In verifiable computing, a Prover runs a function y=F(x,w) and generates a compact proof showing that the output y is correct for program F, public input x, and witness w. A Verifier can validate this short proof without re-executing the function. Every verifiable-computing scheme rests on certain trust assumptions about the underlying primitives or setup.
Engineers still face a steep learning curve when they step into the blockchain world. The hurdle grows even higher with cross-layer verifiable computation: it’s one thing to run a function once, but quite another to convince every chain that the result is correct.
Livy’s solution is a language-agnostic execution layer that slots any containerised compiler into an Intel TDX Trusted Execution Environment (TEE). The compiler turns source code into a native binary; the enclave executes that binary with optional runtime parameters and emits both the output and a signed quote.
No new DSLs: Rust, Go, JavaScript—anything that compiles—gets near-native speed and a hardware-level proof out of the box. The quote includes the enclave’s identity (MRENCLAVE), runtime-integrity metrics (RTMRs), and a hash binding binary, inputs, and outputs. Running transactions inside a TEE removes the need to wait for network consensus, delivering millisecond-level latency and throughput comparable to centralized systems. A trading engine, for example, can match orders and update balances almost instantaneously, providing real-time user feedback. Because the enclave deterministically seals both transaction order and execution, it also suppresses Maximal Extractable Value (MEV) by preventing any external reordering or front-running.
Livy lets developers use verifiable computation without forcing them to learn a new DSL. Keep your Rust, Go, or JavaScript code on GitHub; Livy fetches the repository, compiles it inside the Intel TDX enclave, and produces a native binary. When that binary runs with a given input, the enclave returns the program’s output plus an attestation packet. See Fig 2
We’ll hash the value and tuck it into the TEE’s 32-byte custom-data slot. When the enclave produces its attestation quote, that hash rides along capturing exactly what ran and with which inputs so anyone can later verify the execution.
During verification, the verifier decodes the hex-encoded TD10 quote into raw bytes, fetches Intel PCS collateral (PCK cert chain, TCB info, and QE identity), and validates the quote’s signature against that collateral to be sure the platform’s TCB is current and not revoked.
Once the cryptographic checks pass, the verifier pulls out the 64-byte report_data field, strips any zero padding, and recovers the payload typically a hash of the code and/or user inputs. If everything checks out, you’ve proved the enclave was genuine, uncompromised, up-to-date, and cryptographically bound to the exact data embedded in report_data.
The Provenance Layer serves as a trusted verification node within the attestation, executing compiled binaries with specified inputs while simultaneously capturing and validating hardware-backed attestations. This critical infrastructure component maintains an immutable record of all executions, including binary hashes, input parameters, execution outputs, and their corresponding TDX quotes, enabling deterministic reproduction of any computation.
By exposing a verification API, the Provenance Layer allows any third party to independently validate that a specific computation was executed within a genuine TEE without requiring access to the original hardware. This creates an end-to-end chain of trust from code submission through execution to verification, establishing cryptographic proof that the claimed outputs genuinely resulted from the specified inputs being processed by the attested code, effectively creating a tamper-evident, auditable trail of computational provenance.
Join the waitlist: https://newsletter.livylabs.xyz
Follow us on X: https://x.com/livylabs
Share Dialog
Share Dialog
The universal provenance layer
Subscribe to Livy
Subscribe to Livy
<100 subscribers
<100 subscribers
No activity yet