Exploring Verifiable Data Provenance with Livy
Listen Now
About This Episode
In this episode of DevNTell, Narb sits down with Chris and Saul, the co-founders of Livy, to discuss their platform for verifiable compute. Livy allows developers to deploy software into Trusted Execution Environments (TEEs), making it verifiable and ensuring data provenance. The founders explain the limitations of zero-knowledge (ZK) proofs for certain media use cases and how TEEs provide a more performant alternative for verifying data origin and processing. Saul provides a live demo of the Livy console, demonstrating how a Rust application can fetch and verify data with cryptographic attestations. They also explore future use cases, including verifiable AI output and decentralized infrastructure.
Key Takeaways
Livy enables verifiable software execution by running code inside hardware-backed Trusted Execution Environments (TEEs).
A key focus of the platform is data provenance: providing cryptographic proof of where data comes from and how it has been modified.
Livy simplifies the deployment process for verifiable applications, aiming to be the 'Vercel for TEEs'.
The platform currently supports Rust and is expanding toward language-agnostic infrastructure and GPU support for AI workflows.
Livy intends to open-source its orchestrator to remove trust assumptions and make the entire verification process transparent.
Featured Guests
Chris
Co-Founder @ Livy
Saul
Co-Founder @ Livy
Timestamps(click to jump)
Episode Transcript
Read full transcriptHide transcript
GM GM and happy Halloween to all our viewers. Welcome to what's going to be another fantastic episode of DevNTell. So if you didn't know, DevNTell is a 30-minute podcast held every week, allowing founders, hackers, and anyone in between an opportunity to come on the show and showcase what they built. And today I'm ecstatic to welcome Chris and Saul, who are the co-founders of Livy. So if you didn't know, Livy makes it easy to verify where your data comes from. Deploy your code in one click and make your software verifiable, all through hardware-backed security. So if you stick around for today's episode, you'll get to meet Chris and Saul, learn about Livy, learn about data provenance, and a bunch more. All right, let's get into it.
GM GM. Welcome to the show, boys. Ecstatic to have you on. And happy Halloween. You guys got a killer date for your podcast appearance and I'm happy you guys are spending at least part of your Halloween with us here. But before we kind of get into all the great stuff you have planned for us, perhaps would you like to give a brief introduction about yourselves?
Sure. So you go on, protocol. Let's go.
No, you go. You go, you go.
Okay, you're another kid again, never mind. So a bit about me. I'm Saul, one of the co-founders of Livy. I'm a software engineer, I've done product, I've done UI, I've done Web3, I've done a bit of everything. Right now recently more focused into more the ZK side of things, provenance, verifiability for compute. And the last adventure has been Livy so far. So that's a bit about my background and super happy to be here and chat with you and be in the podcast. Thank you.
Sure. Well, I'm Chris. I've been a Developer DAO member for almost like 4 years I think. So I really love open source software as a whole and I'm a Rust developer. My academic background, I'm a computer scientist and I'm always keen to do open source development and more in the applied cryptography side. And now we are doing Livy. So yeah, it's really, really nice to be here.
Amazing. Yeah, and welcome back to the show, Chris. And welcome for your first time, Saul. Ecstatic to have you guys on. And yeah, Chris, you mentioned it, you guys have been DD members for a while. Just curious, like how did you guys find yourselves in the DAO and yeah, just curious to hear your experience there.
In the almighty BC5. So back in the day, I would spend a lot of time in the BC5, of course. So it was just randomly like daily checking in on us like just what we are doing in the day, like sharing our screens or what we're coding, and it kind of like just added up. Like each day you pop up in the BC5 just getting to know people, share what you're doing, getting feedback and getting ideas and what not. And that's how we met. And actually we met in real life in an Ethereum event. So I think it was Ethereum in Brussels. It was the first time that I...
Yeah, it was Ethereum Brussels. Yeah, that was the first time that we met in person after like chatting in the BC5 for almost like more than a year. No, two years. I think it was two years because we met like in 2021, that's when I think late 2021 is when I joined the DAO. And we met pretty much like first day, something like that. If not like a month later or something like that. So we've been talking for like two years online and then after you know being... well, he was coming to Europe, I was going to the hackathon mainly and we met having breakfast in Brussels. We wanted to get pancakes and there were no pancakes in that place. Don't you remember?
Yeah, yeah, I remember. You just unlocked me a memory. But yeah, it was also a great fit because there's not that much Spanish speakers in the DAO. So Saul and me, we both speak Spanish, so it was like, yeah, kind of a great fit.
That is cool. That's awesome. And yeah, I joined also around late 2021 and yeah, BC5 was the 'it' spot. And so for those of you who don't know, BC5 stands for Voice Channel 5. It is a voice channel in the DD Discord and it has basically come up as one of the more legendary activities to join that voice channel and just shoot the shit so to speak with just a bunch of developers building cool stuff. And it's actually vibes, the vibes call is kind of making a comeback. So for those of you watching, listening today, be on the look out for that. But coming back, coming back to Livy, yeah, why don't we just get into it. What is Livy? What is your elevator pitch for it?
Yeah. Livy is the verifiable platform for having any application developed and make it verifiable. So we take any software and we can make it verifiable by running that inside Trusted Execution Environments. So think of it as a new cloud provider that enables developers to very simply take their existing software and make it verifiable, having the guarantee where the information is used, what is getting executed, and what is the output for every application or for every execution that they make.
Well said. Well said. And yeah, I guess was there a particular moment in your day-to-day dev lives before you started Livy where you're like, 'Oh damn, this is like a real problem.' Was there something that kind of happened to you or something that you saw that inspired you to kind of start Livy?
This year in February, I was working on this verifiable image editor during a hackathon. So the idea of this hackathon was okay, we have images, we want to edit these images, but once we edit these images, let's say with Photoshop, we lost where it came from or we didn't have any way to prove that this was from this other image. So with ZK and using SP1, I hacked this idea on verifiable media. And then during the hackathon, I figured out, 'Okay, this doesn't work for videos, it takes too long with images, and there has to be a better way and a simpler way to have the performance, the developer experience, and overall a nicer platform or something that allows me or allows anybody to take their applications and make that verifiable.' In this case with a lot of focus in data provenance as well. So that's how everything began and then we started from that point on and here we are.
Something to add is that I really think the problem that we are solving is like you get this sentiment if you are like going to hackathons as a whole or what not and there's like people doing certain kind of stuff that will rely on hardware. Let's say yeah, I want to use some kind of, you know, face recognition in order to that I can sign transactions or what not. So it always comes that we have a bottleneck that is how we can solve this part, like how we can connect blockchain as a whole to the external world in a secure way. So then you have another options of course, you have ZK, you can do some things with FHE or other technologies. We are not biased into what we do. We see that there is enable technologies of that but the performance cost is really, really high. So there's where Livy have a point there, is how we can solve this in an efficient way. That's what we're trying to solve.
Amazing. And I know you guys have a bit of a demo planned or plan to show, but before we get into that, just for the audience members that might not be familiar with what data provenance means, could you guys kind of just do a brief explainer on what that is and why it's important for people to really take into consideration?
Sure. So the idea of data provenance in very simple terms is to know where something came from. When you are doing for example a photo, you are taking that, you're getting... you're recording that instant with your sensor, with the camera or with the device you're using. But there is no cryptographic way to prove that this image is actually real or not because we don't have a signature for this image. So that's sort of getting the information from the real sensor to sign where this information came from. If we are talking just on the digital matter, it's very simple because you can track a binary what is actually executed and as long as you have some sort of verifiable compute, for example with blockchains, blockchains are great for this use case. You have a state and every time you update this state, you're going to have a state transition. This is in a blockchain recorded and then you have the whole provenance of that state. But if you are having normal compute, if you are having hardware, if you're trying to interact with real things, it's very, very complex to have full data provenance and having verifiable compute is one way we can solve this.
Yeah, that's a great explainer and there's this whole rabbit hole for being able to verify AI output, AI inference that we can get into towards the end. I think it's a very interesting topic on its own. But in the interest of time, the floor is yours if you want to share your screen and give us a walkthrough of what you've been talking about.
Sure. So for this demo that we have, we are going to just have simple provenance for a URL. We're going to create an application that we already have developed. Let me show you the screen how simple it is. So, this is the console. Anybody can register here by going to console.livylabs.xyz/register. Also in our docs we have the guide on how to register, which is going to bring you once you login into this platform. To create an application, you can just have any Rust program at the moment in the platform. In this case, already have one repository connected which is this one. You can have any branches and then once you explore the files, this is going to compile any Rust application the same fashion that you would have let's say in a terminal CLI. You get to execute this application the same way. So this would be it. That's all the steps you need to have. You need to create an application just to avoid having to wait for the compilation, which is going to take a while. We can go to this example which is this one down here which is already compiled. And here we see that the program has compiled and we have an execution down here. So Livy essentially has taken this application that we have here and then we are able to execute this automatically. We can fetch the parameters for the URL for example and if we want to fetch information from let's say Google, we're going to be able to run that that simple. So in this case, we're making sure that this has been executed. This is the information, well this is the attestation and everything that is getting executed. And here we have in this case, it's just the HTML website from Google. But this information now that we have the attestation, we can verify this attestation and have not only the guarantee that this is actually executed from Google but also now we can verify here and have the report data which includes the input which is going to be this URL, the program which is the hash or the identifier of the binary, the output, the timestamp and in this case is the user as well. And this is going to generate this hash down here that then we can compare and have the full provenance data of an off-chain compute which in this case is verifiable compute. Just to have a nicer UI, we also have this example here where you can try this out. You can paste any API or any URL. Let's try Google for the same example and it's going to return basic information. This is the service ID that we have called, which is the fetcher. Here we have the HTML content and then we can do the same process verifying the attestation.
Awesome. Yeah, so you kind of ran through a couple of things there that I want to double click into. So the first one, so right as you were deploying, so are you guys pushing that deployment to, I guess where are you guys pushing that deployment to? Is it an AWS box? Is it deployed on decentralized storage? Like how does that work?
Yeah, we execute the compilation inside a Trusted Execution Environment and that binary gets stored in the hard drive of the machine itself. This is run in a cloud provider, so we don't have access to the devices, which is a key point for the Trusted Execution security. Nobody can access the devices. And then every time somebody executes the program, this binary identifier, which we use as the service ID, gets called, gets executed with the input of the user, and returns the output for that given binary.
Awesome. And this is programming language agnostic, right? Like any program written in any language should be able to be deployed this way?
On this demo we only support Rust, but we are working on the infrastructure and we have like the product completely, not only for stateless executions, which is the demo that we have so far, but for having any entire services with any programming language, web sockets and anything you could imagine.
Yeah, something that we achieved internally just for giving you like an example is that we ported into the FFmpeg so most people use it. So yeah, that's how we prove it like yeah, we are language agnostic at the end.
Amazing. So yeah, it kind of gives off the vibe of like a Vercel but for like Trusted Execution Environment deployments. Yeah. We get that a lot and I think one of the main goals is to provide that DevX for developers. I think that's one of our mantras is like really, really minimize how we execute this and then just like one click deployment or CLI.
Amazing. And the attestations themselves, like are these stored somewhere on a blockchain or again like a decentralized storage or is it just like something local that the end user can only see, the person who deployed the service?
It's really important that yeah, every time that we get attestation, of course the user will get it, but then on top of it, because you are just talking about the runtime, so what we are building on top of it is what we call provenance layer. So in the provenance layer what it makes sense is like for you to have data provenance, then you need to have a connection between each attestation, like which attestation came from each service ID and what it did between the input and the output. And then you do that, you know, the chain like okay this comes from this. So there's how it comes. So it will be stored in a decentralized way of course, the attestation and what not. A good question is if we're going to be an L2. That's for us to discuss, we're doing research. So yeah, maybe, maybe we will do it. So yeah, we'll see.
Sweet. Maybe a bit of alpha, early alpha there. We'll see, we'll see. Yeah, for Halloween, you know, spooky season. Yeah man, spooky season. Launching an L2. Awesome. Yeah, and just curious, sorry if you mentioned it already, but how long have you guys been in prod for? Like is it like a year, 6 months, or even earlier than that?
We started back in May. We were thinking all March into how to make everything. April was a bit like, 'Okay, we are closer but we haven't fully start implementing anything.' And once it came May, that's when we started working on everything. So far we haven't launched a product that's production ready. Everything that we have is on beta and we are trying to get the initial adoption. We have a couple of partners that we are working internally with them. P-layer is actually public, we are working with them already to integrate the TLS notary inside TEEs. But so far we are trying to prototype everything and having fully launched anything on production ready let's say yet.
And this is a perfect segue. I was going to ask how people can get involved. So you mentioned it's in beta. How's the process for people to register and yeah, start deploying their services?
100%. We do have a documentation where we cover an example on a price feed. The idea with Livy is that any or like the demo that we have deployed, you can get any console or CLI service that you already have developed working into Livy, into the demo working demo that we have, and that way you are going to make that let's say traditional service that you don't know how is getting executed or anything and make it verifiable with TEEs. So in that sense, we manage to take any software and anybody can essentially reach out to console.livylabs.xyz, register, and be able to have their service deployed.
Awesome. You already got some influx here. Billyjitsu wants to connect, so yeah, definitely you boys should get in touch. For people who don't know, Billy just launched Katana, so another DD win there.
But yeah, coming back to my earlier thing I mentioned about maybe potentially using this for verifying AI output, AI inference. A lot of we know a lot of DePIN networks use the distributed model for kind of providing hardware for end users to be able to run their inference jobs or maybe machine learning training. Have you guys thought about how Livy could potentially be used to solve one of the big problems I think in that space is just being able to verify that an end participant of that network actually did the work that they said they were going to do?
Yeah. Of course Livy enables that because besides Trusted Execution Environments can be run in CPU and GPU. It's very important that if we run this in GPU, then we get, you know, the GPU acceleration started for doing this. Talking about verifying, I think it's kind of a huge work because it depends because if the model is non-deterministic, maybe you know verifying like with multiple nodes or servers kind of going to be tricky. But if your model is deterministic, then of course that makes sense. Actually yeah, we are doing research on that. We are doing research with a partner that they have an ML that is deterministic and then you can verify that how that happens. But then you need to for it to be deterministic, so non-deterministic can be a little bit tricky. Yeah, exactly, it is very, very tricky. But it would be really cool if you guys are able to solve that, that's like multiple billion dollar business in itself. Sure. And also a good use case is Ethereum just launched an EIP that is in review, is the 8004. So they are talking about AI agents having kind of reputation. So I think that converges with what you said because then you can use TEEs, it's in the EIP, everyone can check it. So if you have Trusted Execution Environment that have some reputation on-chain, then of course it makes a lot of sense that you're going to trust it because then you know a lot of people is voting for that. So a great use case if you combine that with the X-force 02 is like you have multiple agents that can reward itself between each iterations. So then you have like a more complex systems and maybe you can do like crazy stuff with that.
Oh yeah, definitely you can. And just want to bring up Kemp. Kemp is asking 'wen storing on Arweave lads'. Yeah, right? Why not use Arweave? Yeah. There you go, Kemp. Awesome.
And yeah, I guess for the developers that are watching today, is Livy open source? Can people contribute to the project or if they do want to contribute to the project, is there opportunities available for them to do that? At the moment we have kept everything close source. We plan to have one of the key points which is the orchestrator that allows to make the provenance accessible. That should be public so the entire system is verifiable. So you don't even need to trust us, just you trust Intel. But yet we don't have the final version but we plan eventually to have this last piece also open source so anybody can contribute to it and make sure that what we are executing is what we are telling so. That way we remove an extra trust assumption as well. Awesome. And in terms of people that you're looking to start beta testing, are there particular types of applications that you're looking for versus others or just like anyone who has general interest reach out? We are mainly working into three branches. One is data as a whole. Let's say we need to prove that this data was come from here at a given timestamp. We can use that. The other one is infrastructure. And both directions can be working with us. So if you need for example data for DeFi, data for prediction markets, data for an indexer or any sort of feed, both of that directions you can like get it from an API if it's in a blockchain or writing in a blockchain if it's from the internet. We can help you doing that. And then if you just want to remove trust assumptions on your system and just execute something inside a TEE, we can help you with that as well.
I think a good example, yeah we're talking about reducing trust assumptions. We've seen a lot of push to use Livy for multi-party computation. So if we talk about TLS notary, there is in TLS notary there is like an assumption. I'm going to briefly recap what TLS notary do. So you are securing a TLS session but you have a notary that is the witness of it. So the witness will say okay I assure that this was correct. So the trust assumption in this model is that you need to trust the key that has the notary in order to that is the witness of the TLS session. So with TEEs, since you can spin up a notary server let's say for scratch and then you have attestation that has okay this kernel has been used, this configuration or what not, then you reduce the trust assumption of your notary server. So then it of course it makes a lot of sense that you're going to trust it more to do this in this way.
Interesting. Well I mean yeah, you guys are certainly doing some really fascinating work. And yeah I'm really keen to see Livy continue to evolve here. I guess can you guys share anything about your roadmap in 2026? What people can expect?
Yes. So far the key point that we are trying to have ready by end of the year is going to have the core infrastructure ready so we can support in a very, very simple way any service that auto-scales, that has different regions of availability so you don't depend let's say on AWS US East 1 who drop for like two days a couple of weeks ago, so you have different regions to have your software distributed as well. Also we are working on having GPUs very soon. We plan to have by end of the year early next, well Q1 2026 as well in order to provide not only support for software but also like for AI machine learning workflows, which is going to enable agentic solutions as well running in top of Livy. And then once we have this sorted, the next step is going to make the platform available for anybody with the best developer experience, which is one of the goals that we have as a company but obviously this can scale at the very beginning, we need to have the foundation that can scale later. Yeah man that's really exciting. Let's go. Awesome, awesome.
And yeah, just as we're about to conclude, I want to get you guys' I want to see are you guys going to be at DevConnect? Yes, we plan to be. I'm currently in Argentina, so of course it's always nice hanging with DD people and meeting in real life people that you talk online of course. Yeah exactly, I was just going to say for people who are listening today or maybe you're a DD member or maybe you're someone who's looking to become a DD member and going to DevConnect, we do have a IRL hangout called DevN'Vibes. I wonder who came up with that name? But we are hosting a get together in conjunction with Mimic Protocol. So definitely spots are limited so you'll definitely want to go and get your name on the guest list. You can find that at the Developer DAO events page on Luma. And yeah, I mean Chris and Saul met in real life and started a company together down the line, so you never know what happens when you go to these conferences. But yeah, I guess any final thoughts you guys want to leave with the crowd before we conclude?
Chris, you go.
No, I don't have anything in mind. I'm saying like if you are interested in Trusted Execution Environments or you have like this crazy idea that you want to share, of course just DM me. That's protocolwhisper in Twitter too and I would more than welcome to talk.
Amazing. And yeah, Saul and Chris's contact information should be in the description of this podcast so definitely if you are keen on starting with Livy, definitely reach out. And with that, I just want to wish everybody a happy Friday, happy weekend wherever you may be. Chris and Saul, thank you so much for taking the time out of your day to be with us here today. Thanks to you for having us. My pleasure. Happy Halloween. Exactly. Happy Halloween. And yeah, ecstatic you guys decided to spend a bit of your Halloween on the show here today. But yeah, hope everybody has a fantastic Halloween and we will catch you all back here actually in a little bit, in about 15 minutes where we are going to announce the winners of our DevConnect giveaway. So definitely don't leave your screens, maybe go for a coffee break or something, but yeah, you'll definitely want to stay tuned for this. All right, have a good one. Have a good day. Cheers.
Listen On
Resources & Links
Share This Episode
Share on XWatch Episodes Live!
Subscribe to our event calendar and never miss a live episode.
View Event Calendar