Hello everyone. Thank you for being here. I'm Deepti, Co- CEO of O(1) Labs. We are the CEO of O(1) Labs. We are the team behind Mina Protocol, one of the first zero- disclosure ZK blockchains.
But this report is not so much about blockchains. It addresses a problem that many of us in this room will be facing for several years, right? Whether you are a security professional, work in operations, or simply run a business, right? You're, um, increasing...There's an increasing, um, dependence on systems, on vendors, and now on AI agents that you can't really test, right?
So, my argument for this report is contained in one line, namely in the statement under the heading: make trust verifiable. Right? You don't put evidence above promises because you want to go beyond the promises of what your systems can do , what your systems can deliver, and instead of providing, you know, building more and more trust, you start providing more evidence. So, let me, um, show you what it is . Let me dig deeper and also share the reason.
Good. Um, first of all, I want to address one concern that most people have when they maybe hear about zero-disclosure proofs is that maybe it's a cryptographic document or maybe it's document or maybe it's something like private tokens, but zero-disclosure proofs have, you know, quietly become mainstream, right? Google now offers zero- disclosure age verification in Google Wallet, which allows you to confirm that you are over 18 without revealing your identity. Microsoft is also integrating a ZK-based credential system into its identity offering, and the EU has introduced mandatory digital identification for its member states, and they have a ZK-based design on their roadmap. And on top of that, just like cryptocurrency, it has been proven over the years and continues to be battle-tested.
So, you know, that's where it all started, right? We know that in cryptocurrency, zero- disclosure proofs have been used to achieve mainly two things, right? Privacy and scalability. Privacy allows you to make transactions without revealing who you are making them with, without disclosing the amount. This way, you can have transaction-level privacy as well as application-level privacy.
You can build zero-knowledge applications, run them off- blockchain, secure your data, and then verify public statements on the blockchain. This is what confidentiality is. And the second use second use is scalability. So ZK aggregations compress thousands of transactions into a single proof, and then, you know proof, and then, you know , they send that proof to the blockchain. So you can scale, ahem, a lot of systems in Ethereum.
In fact, some of the largest some of the largest Ethereum L2 systems are based on ZK, right? So we're proposing, um, a third use, which is verification, right? And verifiability is right? And verifiability is not something that needs to be built into ZK systems. This...
this is an inherent property of zero-knowledge systems, right? SNARKs right? SNARKs are essentially verified calculations. You provide proof that you performed a certain calculation, and, uh, a third party can verify that proof and doesn't have to perform that calculation themselves. So ZK gives you verified computation, and that's what allows you to, you know, some of these applications like privacy and scalability.
So, uh, we want to suggest using the verification feature verification feature , but we pointed to corporate workflows. Right? We want to define workflows within corporate systems that include policies that ultimately govern high- stakes transactions. And we want to start using ZK to provide the same guarantees as blockchains and other use cases use cases , but within this problem area. And it makes corporate transactions more provable, not just fast or, uh, private, but provable.
Okay, so why now? Right why now? Right ? Uh, and by that I mean that the two forces seem to be moving in the same direction. Uh, on the one hand, you have AI on the attack.
Uh, attackers are now using AI throughout the entire attack lifecycle, right? And the first cases of zero-days generated by AI are reported. And there were so many reported last year, and there are even more happening now, right? Hmm, the surface of systems is being explored faster is being explored faster than some of us can realistically react to it . Hmm, and that's worrying.
The second is AI as an actor, right? Now we empower agents to do things on our behalf, to use our data, to go out there and do agency things. Hmm, and for such a system, existing, hmm, existing, hmm, existing, protective barriers and trust mechanisms do not scale well not scale well , because, hmm, you are dealing with software that multiplies by the week, so the common thread here is that you are dependent on actors that you cannot verify. And the solution is not more trust, but, um, evidence that you can verify. Steeply.
So, what do we offer? Hmm, how do we use provenance? We're saying we need to move away from this model where you trust the systems, you trust the agents, you trust the operators to follow the rules to follow the rules , who are then allowed to act, um, after that, right after that, right ? So we want to move from this system to another system where the action that you want to protect is recorded until there is evidence that says, "Okay, this is real. We have implemented all the policies, and here is the proof of this implementation or enforced implementation."
And regardless of who asks, something that helps me think about ZK is this notary who cannot be bribed. So you just, you know, code the rules and say this has to be done, and then it has to be done. And so the change here is that proof becomes part of what authorizes these high- stakes transactions. And so you can think of it as an additional layer in your existing controls, you know, that protects high- stakes transactions. Um, one thing stakes transactions.
Um, one thing I want to mention here a little bit before I, uh, go into more detail on the next slide is that this isn't exactly abstract, is it? This, uh, this is happening now, so you can, for example, think about this, imagine this world where you want to transfer funds to your treasury. I'm sure every one of us here would do some version of this. And of course you have, uh, a list of roles, policy list of roles, policy , you know, who has the right to authorize, who has the right to set restrictions, and imagine that all of that is proven and also verified, you know, the way it's usually verified today. So, in addition to that, you have proof that these, uh, policies were applied, and that's what , uh, will decide whether you want to make the transfer or not, right?
Hopefully this use case is a bit closer to home. And it will all start to make sense, but, uh, I'll talk more about that . Okay, so what is this , right? Uh, this is essentially a proven workflow. Mechanically, it's actually three steps.
More like two. The first is how it exists, but the first step is you have an existing policy, your rulebook, your enterprise application policy mechanisms, uh, and/ application policy mechanisms, uh, and/ or processes. You code them, or we code them for you, in a ZK application or ZK schema. So you have this little piece of evidence that runs in parallel with your policy enforcement. So you have an existing policy enforcement, you run another parallel one that is based on ZK.
And that creates proof. It's a self-contained artifact that you can then, um, send to another component of your workflow where it actually checks whether, um, the rules have been followed. Right? And this is the second step. You have another component, um, that checks if the proof is valid.
And, um, it's not just that it's valid, there's, um, a statement that it tests, and that's also what you expect. Right? And that's what will then execute the high- stakes transaction, whatever it is , whether it's a transfer or an agency move. Um, this...This is the last step.
Cool. So, um, what can we do with this new, um, additional layer that you're going to have in your existing workflow? Right? The first is that you have a receipt. It's a cryptographic receipt that, uh, confirms that the rules have been followed.
Right? And, as I said, it is an independent artifact independent artifact . This is proof, and there is a claim about this proof, and you can send this proof to anyone who wants to check it. Right? And in one case it's your own system because you want to check the proof and then take action; but otherwise you, uh, send this proof to your auditors, maybe even your clients, to show, uh, um, you know, to give them extra assurance that you've followed, uh, all the policies that you've agreed to with your clients.
Uh, it gives you an audit log for every action, right? This is for each transaction you would execute this workflow. So every transaction or every, uh, every instance of the workflow will go through this. And so, you have an audit trail with a more detailed audit trail versus something like, you know, random checks over a period of X days, right? So, you have more detailed information.
And this again can be used for audit purposes, for greater certainty, the same thing. And finally, this, um, probably not as well researched, but ZK is used in the blockchain environment blockchain environment because, you know, there are inherent assumptions about trust. And so when you cross that line of trust, you need more confidence. So when you apply this similar concept to enterprises, your organization might have workflows that span, uh, multiple organizations, right? And if you want to get full confirmation of all the policies that have been applied, then you can start involving multiple parties in this workflow.
And they provide proof along with a statement of what policies were applied. And you can combine them into one proof, which is then verified at the very end. This kind of layout, uh, you know, is achieved using the ZK infrastructure. I don't want to go into technical details, but if you're interested, be sure to come and talk to us and we can share more information. So, yes.
Now, uh, like I said, uh, sorry, I think it's okay. One objection I hear when I talk to people is that, um, you're suggesting copy and replace, replacing an existing attack surface with a new one. But that's not what we're proposing, and ZK actually makes it very easy. We offer an extra level, right? We want this to be a complement to your existing streams.
So adding this extra layer gives you a different kind of, ahem, workflow than any other systems any other systems out there on the market. So you have a heterogeneity of, you know, um, security systems that you implement. Hmm, and even better is how incremental ZK can be, or just this framework, because you can pick one very narrow, high-value, hmm, flow, code it in ZK, run, hmm, run a proof, generate a proof, verify it, and incorporate it into your workflow. If this works, start adding more and more policies to this system. So now you have a whole, uh now you have a whole, uh , system, or an additional layer of all the policies that you've created.
So it really allows you to... really allows you to... It's the aspect of composition, or the aggregation of evidence, that allows you to do that. So, I would say that such a system is easier to implement, even if it's, uh, it's new in the corporate environment. Okay, now this pattern that I showed you is like a quick overview of a very small use case, as you can imagine can imagine , but it kind of changes a lot of areas, right?
If you start talking about institutional finance institutional finance , anytime there's a movement of money, there's definitely a rulebook, there 's definitely a policy, and depending on how big the transaction is, you have stricter rules. And so, you know, you have all these processes in place to ensure that these policies are followed. So ZK-based policy mechanisms can be very useful in institutional finance. AI and agents. Let your AI agent prove that it followed policy without sacrificing the data it acted on.
And this becomes more noticeable when you start running systems with multiple AI agents. They all interact. One AI agent delegates a task to another agent. So you're starting to see, um, delegation of the information workflow. And now you go back to, you know, existing systems trying to apply them to agent systems and they don't really work well.
So, um, the identity of AI agents. The I identity is, in my opinion, the simplest use case for this. You are verifying your identity. You get access to some. You gain access to your system or some data.
So, this is the simplest example of how you can implement policies implement policies , which in this case are identity-based, into your corporate workflow. And you can combine other policies with IDs, credentials, and other credentials to start creating complex policies. And then, more broadly, in corporate operations, for example, whenever there's a vendor integration or any policy that needs to be implemented, um, you can run a parallel, um, validated workflow alongside it. Good. So, if there's one thing I want you all to take away from this conversation, it's that whenever there's a high-stakes transaction in any system that you want to protect and safeguard, and you have a set of rules that govern it, then you need to create an additional layer of assurance and safeguards using a proven ZK-based workflow.
Right? So the next time you have a problem like this, where you have follow-through and you have policies, they might be, you know, systems or processes to enforce those policies, but you can add a layer of ZK to make those policies auditable to create full proof that your policy was followed. And when you do, be sure to come see us. If this resonates with you, definitely come to us, you know, bring a real workflow that you've encountered, and we'll, um, show you where you can add verified evidence, where verified evidence, where , uh, and what you'll get out of it , right? Based on your existing systems, what value will you get from this.
So, we have a booth here, so be sure to come and talk to us. And if not, if that doesn't work, you can also email us at partners@omenlabs or, um, reach out to me on Twitter. Good. Thank you.
Automatic transcript — names and jargon may be misspelled.