$1,000,000 in security audit grants are live now, Apply here →

Permissionless Podcast

Predicate: Bringing Policy Onchain for Institutions

With Nikhil Raghuveera of Predicate. Hosted by Owen Thurm.

  • 52 min
  • Onchain policy infrastructure

In short. Nikhil Raghuveera, co-founder of Predicate, explains how its policy network checks transactions before they reach a contract. The conversation covers stablecoin payments, AML checks, LayerZero and Axelar integrations, a Uniswap v4 hook for Paxos, and Predicate's roadmap.

Episode summary

Nikhil Raghuveera describes entering crypto through payments and financial inclusion, then leading ecosystem work at Celo. He expects US stablecoin adoption to come through backend payment systems, not peer-to-peer apps.

At Celo, he saw large projects lacking onchain mechanisms for regulatory, legal and business rules. Predicate is a general policy layer that teams integrate once and update without changing their contracts.

He walks through deployments with Aleo, Plume over LayerZero and a Uniswap v4 institutional hook with Paxos. Owen and Nikhil discuss how a dedicated DVN checks every message bridged into Plume.

The roadmap covers a policy language, multi-chain support and dashboards. Nikhil names engineering hiring and slow partner deployments as bottlenecks, and says onboarding is white glove for now.

Key takeaways

  • 14:24 The most common use case is anti-money laundering: a pre-transaction check that a user's assets do not come from a sanctioned entity or an exploit.
  • 14:46 Nikhil argues static blacklists and front-end API checks do little. An attacker moves stolen funds to new addresses or calls the contract directly.
  • 18:07 For LayerZero, Predicate runs a custom DVN used only for policy checks. Plume adds it beside its default DVNs, so every message into Plume is checked.
  • 28:55 Integration has three parts: define the policy and data providers, add a require statement for a Predicate signature, and fetch that signature, usually through an API call.
  • 35:07 Predicate avoids zero-knowledge proofs for now because they are slow and expensive. The goal is subsecond, cheap checks, with ZK providers such as Lagrange pluggable.
  • 37:00 Next at the time of recording (June 2025): a policy language for developers, support for chains beyond Ethereum, and dashboards for policies and operators.

“One of the things we realized is none of this is ever bulletproof. It can't be 100%, for AML at least. But what you can do is you can try to make it really difficult.”

Nikhil Raghuveera, Predicate · 21:08

Predicate on security and risk

  • 20:35 Owen notes users could bypass bridge checks through Arbitrum's delayed inbox. Nikhil agrees AML checks are never bulletproof, so the aim is layering, such as Plume's Nest product checking deposits too.
  • 24:06 From auditing LayerZero integrations, Owen notes how much can go wrong in DVN configuration. A policy DVN like Predicate's must be a required DVN so it cannot be bypassed.
  • 30:55 Owen asks whether exploit transactions could be stopped by simulating them against fuzzing invariants first. Nikhil says Predicate orchestrates the check, while a provider such as Hypernative or Forta runs the simulation.
  • 32:46 Asked what happens if Predicate or a provider goes down, Nikhil says Predicate must be high throughput and low latency so it is never the blocker. Data providers are a trust assumption, and teams can set backups.

Related reading

Chapters

  1. 0:00 Intro
  2. 2:28 Nikhil's path into crypto
  3. 3:55 Have remittances met the market need?
  4. 6:01 Stablecoin payment rails in the US
  5. 10:11 How Nikhil came to Predicate
  6. 13:24 Solving a shared problem for teams
  7. 14:16 The most common use case today
  8. 16:03 Who is building with Predicate
  9. 17:39 Using a DVN for onchain checks
  10. 27:50 Working with Uniswap v4
  11. 28:49 What integration looks like
  12. 28:58 Integrating Predicate into a stack
  13. 34:10 Plugging in other providers
  14. 36:02 Long-term vision and roadmap
  15. 40:05 The biggest bottleneck to adoption
  16. 43:05 Hiring strategy
  17. 44:53 KPIs and milestones
  18. 45:33 Where the team is focused
  19. 47:43 White glove versus self-serve
  20. 50:40 What developers can try today
  21. 51:15 How to reach Predicate
  22. 51:42 Upcoming releases and partnerships

About the guest

Nikhil Raghuveera

Co-founder and CEO, Predicate

Nikhil came to crypto around 2017 through payments and financial inclusion, then was head of strategy and innovation at Celo, leading many of its major launches.

About Predicate

Predicate is policy infrastructure that checks transactions against custom rules, such as AML checks, before they reach a smart contract. Offchain operators sign approved transactions, and the contract only accepts transactions carrying that signature.

Frequently asked questions

What is Predicate?

Predicate is policy infrastructure for onchain applications. Teams set pre-transaction rules, such as AML checks, and their contracts only accept transactions signed by Predicate's offchain operators after the checks pass. Policies can change without updating the smart contract.

How do you integrate Predicate?

A team defines its policy and data providers, adds a require statement so transactions need a Predicate signature, and sets up a way to get that signature, usually an API call from its UI. Predicate's operators check the transaction and sign it.

Who uses Predicate?

Predicate went live on mainnet in fall 2024. At the time of recording (June 2025), Aleo was its only live mainnet use case, with Plume, a Uniswap v4 institutional hook for Paxos and IntMax still to launch.

How does Predicate handle security and risk?

Nikhil says AML checks can never be fully bulletproof, so the goal is to make bypassing them as hard as possible with layered checks. Data providers are a trust assumption, and teams can configure backups if a provider fails.

Transcript

Transcribed from the episode's captions, with names corrected. Select a time to play the episode from that moment.

Read the full transcript 11,061 words

And welcome back to the permissionless podcast brought to you by the team at Guardian. And as always, we're going deep with DeFi teams building on the edge of what's possible with DeFi. And today we have really a fascinating conversation with Nikhil from Predicate and Predicate is doing I mean really exactly what the name says. It is a predicate which can be applied before a transaction reaches a chain.

So what does this mean? This means that you could add simple checks or really any kind of pre-processing for a transaction and testify that it can be recorded in a contract on chain. And so I mean really you could implement many many things with this. Of course, I mean, I think the first most obvious implementation which we discuss at length in the conversation that follows is of course KYC AML, which is of course not important to the existing DeFi user base, but this is of extreme importance to institutions and large players who are entering onchain.

And so, we get to talk about what kind of developments are being made on that front and also explore even more interesting use cases of the predicate protocol. But of course, we'll go deeper on this conversation in just a second. My name is Owen and over three and a half years ago, I founded Guardian based on the premise that DeFi would reach trillions in TVL and we would need a stepwise increase in the magnitude of security that we were able to provide and be able to ship confidently in such an environment.

And of course, I'm happy to say that at Guardian, we have reached this standard. He was not one but two independent auditing teams accompanied by a world-renowned lead researcher and a full-time dedicated fuzzing engineer for every engagement. And we're able to through this method gain so much confidence in the contracts that really we're able to put up our own funds as a bounty on the contracts on behalf of the project.

And so really at this point it's just a matter of time for DeFi to catch up. And now of course without further ado, let us get into this discussion with Nikhil from Predicate. Well, Nikhil, first of all, thank you so much for for taking the time to join us. And I mean, really, there's a lot for us to explore, but I think really the best place to start would just be how did you find your way into DeFi?

How did you come to familiarize yourself with crypto? What does that story look like? Yeah, and thanks for having me. Excited to excited to be here. so yeah my journey into crypto really started back in like 2017 2018. My first feray and interest in crypto was really around payments and financial inclusion opportunities through payments. So it was like hey like what if you can bypass traditional financial institutions that just don't make you know international remittances local payments all those things just possible because they have to take fees and all of that right and so when you start talking about smaller transactions it just doesn't work.

So that was really my interest and so that led me to Celo. So I was relatively early at Celo was head of strategy and innovation there essentially functioned as head of ecosystem and led a lot of the major launches on Celo but yeah that was really my my early journey. The other one that I should mention too is like I was also really interested in crypto as it relates to privacy and a lot of that is because I think we've gotten so used to large tech companies collecting data right we've just kind of accepted this model of data harvestation like harvesting and crypto seemed like a new opportunity where it's like wait what if your business model does not rely on actually collecting data what if you can just have a different business model entirely

So that to me was really interesting as well yeah of course and I mean coming from a background so obviously you're interested in remittances Initially there were a lot of different projects that were centered around that I think like Stellar was one obviously. Do you think that today we've like addressed and like met the market need of remittances and this kind of application or do you think there's like much more to address there?

Like what what's the state of that? I haven't really kept in touch with Stellar and projects like that. Yeah, I think there's still a lot. Right. So I think it was I'm trying to remember. Was it I'm blanking on who had posted this on Twitter recently, but they actually showed like stable coins being used for payments across countries.

It's actually gone up quite bit, right? Which is awesome. And that wasn't there when we first started like Celo was early on it. We had CUSD, Stellar with USDC. We were like working on humanitarian aid relief, all these kinds of things. And it was all like super early. But it's pretty cool now that like that adoption has picked up quite a bit.

And you're seeing the entrance of like more fintech companies as well, right? And I like Stripe is a big one. PayPal is thinking a lot about this. And I think now we're getting to a world of it's not just about the blockchain itself, but it's also about the stable coin asset as well. And I think that's a world that we're going to, but there's still a lot more that has to be done.

And it really is because like it's not been actually truly integrated into a financial system, right? It's still like a lot of stable coin payment systems, all these are kind of separate. they're not intimately tied to the core operations universally across your fintech companies, your banks, all of those kinds of things. And I think that's really where the world is that we're going to.

But it just takes time because it's not like like I don't know like Ripple was another one that was back then as well. And all of us were like were working on it at the time, but at that point, you know, individual like payment systems, but you over time want all of that integrated like intimately within your overall financial platform.

Yeah, I mean it was really all about the infrastructure buildout, right? And now I think it's coming to fruition. And so obviously there's a voracious need for dollars or at least you know dollar denominated assets like a stable coin or something in these like third world countries or a country that has like a super hyperinflating currency but there's not so much of the same demand or like at least there's not a voracious need for it in like the US and countries that have you know evolved banking systems.

Do you see the adoption of similar kind of payment rails or infrastructure on blockchains in countries like the US? What what do you think would drive the demand there since it's not exactly the same kind of need? Yeah, my hypothesis on stables in regulated markets like the US is I think actually the the adoption is a little bit of an inversion.

So it's not off of peer-to-peer payments because you already have in the US solutions like Venmo and Cash App. So we don't actually need that. The adoption of pay stable coins actually requires more of backend systems of hey wait like we can actually use stable coins as the backend mechanism for payments. So again like PayPal right right now free PYUSD you know like you have your balance on PayPal and it's really just kind of an accountbased system and a credit and debit system.

But if you have some of the fintech companies who are like, "Wait, on our back end, we're actually going to use stable coins for this because they're able to get additional cost efficiencies, additional like revenue generating opportunities, and for them, it's really just they're building a product." I think that's how this happens. I don't think that it's so much that we should be like, "Oh, I'm using one stable coin over another.

It's on the back end." That to me is like the the most seamless way of this happening. I hate the concept of having like multiple different coins and like assets that I need to be spending as much as that can be integrated on the back end is really where I think it starts getting more powerful and that's where you start getting larger transaction volume as well.

Absolutely. No, I think you're you're 100% right. It is like a B2B type implementation because really really if you think about it, the people who have the pain point are the businesses. They are the fintech companies that are transacting and they're paying Visa or Mastercard whatever is it like 3%. 3% sounds so ridiculous. That's massive. Like and and for any online business today like it just I think that value proposition is like hey do you want to make a extra 3% profit?

Like in some businesses that's like that's huge like pure profit is three like so I think that's a pretty good value proposition so I totally agree on that point I think over time some of this starts going to zero as well like I think so if you're going to be maybe you issue your own stable coin and so by doing that you can hold those fees for you know because it's backed by let's say a treasury and all of those kinds you're kind of basically operating like a bank or you go to other stable coin issuers who do that for you but I think over time they're going to say wait why are we why we holding more and more of the fees versus distributing it all out to kind of our our customers which

Is a B2B play of the customers who are using stables. But I think the difference here is it still ends up that maybe you're not earning like 3% 4% maybe you're earning 1% maybe it even goes to 0%. But you're not actually paying extra fees, right? Whereas right now you're paying extra fees on top. So if I'm a business I'm paying an extra fee to Visa.

I think ideally you're like look like it goes to zero but it doesn't go into now you're at a negative. Yeah. And I think another area where the card payment rail companies have a real strangle hold is like the whole like credit card type offers and the points and all the stuff and they've got I I can only imagine how like sophisticated their data models are for like giving points and like targeting specific people and their marketing efforts.

I think that's something we're going to have to overcome as well to get into the first portal. Absolutely. I think serendipitously DeFi has made the right sort of assessment that these third world like remittances those applications are like that's the easiest that's the low hanging fruit and I feel like it's a great case study to build out the infrastructure for that and then from there we can easily apply the same sort of infrastructure to I mean obviously well that's the beauty of the blockchain is you can apply it anywhere right so I think it's insanely opportunistic way to build out the infrastructure and actually like validate it with a market need and then we can hopefully you know build into it we can unlock like how do we actually bring businesses on board I think

Obviously there's a regulatory aspect there's like a business need aspect but yeah I mean suffice to say there's a lot of exciting stuff coming there it'll just take time obviously but we'll put a pin in in like the the stable coin adoption sort of conversation I want to hear like how did you go from working at Stella working on problem of like remittances and and cross-country payments and stuff like this.

How how does that bring you into predicate? What's the the bridge there? Yeah. So at Celo I was working pretty heavily across the ecosystem because I was essentially functioning as head of ecosystem. So that meant working with many of the large projects on Celo. So examples like Axelar, Uniswap, I led the development of Uniswap on Celo, Curve, A Circle, USDC, Tether, Opera, all these different groups.

And one of the things I kept coming back to was look, like we're going to have to scale all of this. Like we've actually started talking about this, right, of this isn't just like peer-to-peer systems anymore. This is actually we have to think about how is global capital going to move onto this because we need to pave the pathway for web 2 financial rails all of the existing financial system that's you know visa that is correspondent banking system that's swift all these different things have to be able to move onto blockchain like blockchain's become the global financial settlement system and if that's the case for us it was like wait like this means that you're going to have businesses and organizations and individuals navigating across regulated and unregulated markets it's not just unregulated ated markets

Anymore. You actually have to think about regulated markets and regulated assets. And so what we found was like a lot of those projects like the larger ones as you're scaling as like a Uniswap is like how do we think about FX markets stable coin pools LayerZero. How are we thinking about interop for financial institutions? Yeah.

Privacy protocols. How are they actually thinking about true scaling of privacy payments in a way that is compliant? All these things kept coming back to a question of we actually don't have the onchain mechanisms to be able to build all of this type of rule making system. And this goes across like business requirements, regulatory requirements, legal requirements, user requirements, all these different things.

And that was really what's led us to predicate was there has to be a way to programmatically build out into the application layer and within the stack, not just at a UI level, but within the technology all these different type of programmatic rules. and that really that's what led us to build predicate. Yeah. And of course there's so much and I think we're starting to realize more and more.

I mean obviously with L2s gas is like not as much of a concern but there's always like the block gas limit that you're going to run into and otherwise just like some stuff is just not meant for solidity and there's just a whole slew of stuff that you just you you physically cannot do on chain, right? So like checking if somebody's on like a sanctions list.

So is it from all your conversations with all these teams, you know, just kind of hearing about all these problems to do with regulatory to do with, you know, maybe even some other harder computational problems, you came to the conclusion that there has to be some kind of an off-chain aspect and and a way to verify and like tie these worlds together in like a cohesive way that not every team has to implement themselves.

Because if there wasn't something like a predicate that would be like a solution for this exact like communication layer, every team Uniswap would have to go and they've got to implement their own off-chain system and then they've got to implement the standard for communicating that onchain with some kind of attestation key or you know some signatures.

Yeah. So I mean like is that the the idea behind predicate is like solve the solution for every team and then work with them very closely to implement them for their Yeah, that's right. It is building a generalizable policy infrastructure that anyone can use around the world to be able to set their pre-transaction rules for what can go through their application and starting with that generalized infrastructure and having really really good tooling for a developer to say wait I need to build out my like custom rules and integrate that into my smart contract.

Having all that in place because otherwise the developer would have to say I'm going to have to start from scratch. I have to build out my entire system here. Yeah. And then then let's say they have to change some requirements. have to go and update their smart contract. Whereas in our case, it's like you don't need to update your smart contract.

Just integrate predicate once. Build your policy on predicate once and then if you ever want to change it, you can change it seamlessly. And so really creating that type of experience because we're only going into a world that's more and more complex. I'm interested what's like the most common use case that you're seeing today? I mean obviously that will change over time as regulatory gets clearer, but like what does it look like today?

I think the most basic use cases is around anti-moneyaundering. So, if I'm an RWA project or I am a stable coin issuant product like a stablecoin project or a privacy protocol, setting requirements that does a pre-transaction check before someone can submit their transaction to check if their assets are originating from a sanctioned entity or from an exploit.

And it's not just a static blacklist. Like that's the other thing is that thus far the only two solutions really were you use something at your UI your front end and that you know is making some type of API call to a TRM or a Chainalysis. The other solution is you just have a hard-coded list of addresses for your smart contract updated and it's like that literally does zero right like that does nothing.

So when you have an instance of like a Bybit exploit obviously I'm not going to use the initial address if I just stole a billion dollars. I'm going to start moving it to other addresses and start moving it through and there's just no real mechanism to solve for that. and the UI of course like you just don't use the UI.

You go and interact directly with the contract, spin up your own EI UI, whatever it is. And so yeah, the most common I think like simplest use case has been around anti-moneyaundering AML and how do you actually create like dynamic flow of funds checks before a transaction can be submitted in the contract. Yeah, exactly. And it's like so frontr runnable as well.

If you see like in the me pool some they're about to blacklist this contract or they're about to add it to the list, you just front run it and then get around it. I was just gonna say I think that's like another really important distinction is that it's not just on the front end level because I think that's kind of everything we've seen so far and like you said like there's definitely not even that complex ways to get around that.

But yeah, I guess another question is like how long has predicate been live and like who are some teams you know building with you guys right now? Yeah. So we went live on mainnet fall of last year and then started having some of our use cases go live recently. So the first one first one that went live is with Aleo.

So all transactions going to the Aleo privacy blockchain are powered by us and checked by us. That's the only one that's on mainnet right now. We have a few that are on test net that will be going into mainnet. So we are doing some work with so Plume is another one that Plume's mainnet hasn't launched yet but all transactions that go into Plume for their interop so with LayerZero and any other interop solutions that they have we checked by us on mainnet so that's another example another one that we're doing is with Uniswap we're building an institutional hook infrastructure for Uniswap v4 so that way let's say you're an asset issuer and you're like I need to create a 24/7 market for my asset and but I'm going to create the liquidity

Pool here because I'm a financial institution who's going to have control over my assets. How do they actually do that with the Uniswap? That was pretty cool that V4 actually allows for that customization. And I think that's really where the world goes is you have permissionless systems, but you actually then have custom vaults, custom hooks that allow for the needs of different types of organizations.

So, we're building that and then we're going to have we're working closely with Paxos as like a first user of that. So, those are some initial use cases. We have another announce we have one that's called IntMax that's on testnet. they have to launch their mainnet. That's a privacy protocol. Yeah, we have a lineup of a bunch of other projects that we've been announcing on on Twitter as well.

Okay. So, there's a lot we can we can get into off of all those. I guess first of all for like the interop sort of solutions with especially like a LayerZero. What does that look like technically? Are you guys implementing like a DVN that is performing some of these checks? What is that? Yeah, so it depends on the interop.

So the primary ones that we work with are LayerZero Axelar and Hyperlane. Axelar is not so example of LayerZero. So Plume works closely with LayerZero. I think layer 0 is their deacto interop solution. It's also being used for their nest product. All of those things. Yeah. So in the case of LayerZero. Yep. That's right.

It's a DVN. so in this case though it's a custom DVN that is responsible solely for policy checks. Yeah. So when I'm building, you know, I'm I'm on I'm Plume. I'm enabling my interop and I have LayerZero. I have my default DVNs which are LayerZero labs DVN and Google cloud. The other one I have to add is a predicate DVN.

Predicate DVN sitting there specifically just for policy checks for every transaction going from any chain over to Plume. So if that's going to be bridged to Plume, the message is being sent to Plume, it has to be checked by the predicate DVN. That's how it works with LayerZero, which is actually a really clean model because of their DVN architecture.

I like didn't fully appreciate it when we until we like got into it. And this was like I did a lot of the interop work at Celo and I worked closely with Axelar LayerZero and hyperlane but I didn't fully appreciate the LayerZero DVN model until more recently where I was like oh this customization is actually really cool.

Yeah. No, I mean neither did I. I just realized how powerful it is just now. Yeah. And then I think with something like Axelar it's a little different there. For Axelar it's actually the endpoint for their contract. So Axelar has their hub and spoke model right. So they have their hub. It's essentially kind of like a chain.

It's not a chain, but it uses a Cosmos SDK. And then all their different points for their chain or like for different L1's and L2s that use Axelar are spokes within that wheel. And so where you have predicate is within all those different spokes. So different L1's or L2s that need predicate checks basically add us at their at that at that point of connection.

So an example is like Axelar will be the interop for Aleo. So they haven't they haven't gone live yet, but when they do that's another point there, right? So in that case it's actually kind of for that Aleo component. Aleo has another bridge right now which is being used. So it's kind of it's basically a similar integration, but Axelar is a more complex one because it's a full hub and spoke system.

And I guess I mean I'm not as familiar with the those specific chains Plume and what kind of stack they are. But obviously this gets like a little bit blurred when you're talking about like an L2 that has like a native bridge. You can't exactly like insert any checks in between there. Depends on the type of chain.

So with when it's like an optimism super chain a little tougher because they have their own standards. But for example, Plume uses the Arbitrum stack. Oh, really? You actually can enable custom custom logic for your interop there for the the canonical bridge. That's right. You can do that. Yeah, I see. So So are you guys also inserting yourself like in between?

I guess we aren't not yet. And that's because it hasn't been a requirement for Plume just because I think they're anticipating their primary interop to actually be through LayerZero, not through the the canonical arbitrum bridge. Yeah. Well, I guess somebody might be able to get around those checks if they just use the delayed messaging box. That's right.

So then it's a question of like how robust do they want it and we're all true and then of course like what Plume will also do is enable that within different applications. So like for example like their Nest product will require AML checks before one can deposit. So even if you some way to bypass all of this, there's additional points.

So it's all it's none of I think one of the things we realized is like none of this is ever bulletproof. Like it can't be 100% for for AML at least. But what you can do is you can try to make it really difficult. you try to make it as difficult as possible for all these different pieces.

And so that's really what you can do and you can continue adding more components as you keep going further and further. And yeah, I think that's really like the best way to do it. I think you're right. Like there's when you get outside of a blockchain like blockchain is very nice. We have the luxury of being able to write in variance and like be and have faith in like okay this thing will always hold at the code level but when you get outside of this and you're dealing with like AML and stuff like this it's it like there is no specific invariant you can write and assert.

Yeah. So I mean really it's about like how do we make it as hard as possible. That definitely makes sense and as hard as possible like thinking about where liquidity sites like liquidity really sits. what are the assets for swapping into different pools. So you know like if you have wrapped assets but the the bridge is already covered for that wrapped asset you've kind of covered that pool and if your primary liquidity pool pick up certain assets is with the wrapped asset you've actually done a little bit more there than you would have done otherwise.

I think one of the other cool things is like with with blockchains unlike in traditional finances a programmability means that over time you're actually able to add a lot more sophistication than traditional financial systems and solely because of the programmability and the fact that they're all building blocks. so in my mind I'm like yeah we're just getting started on this.

Like really at the end of the day when we talk about onchain policies for any type of customization you're able to do a lot more solely because of the way that of just what blockchains really are. Yeah. I mean that I think that's the superpower of DeFi and blockchain. It's like we're in the right race with composability on our side because that it just takes time and it just compounds and it will continue to compound like I mean especially with I mean people are still using like Uniswap v2.

Yeah, that is like a fundamental like I don't even know how long will people continue to use that like it might be a decade from now and people are still using that piece of technology like that is so valuable to be able to have anybody anywhere go and create new primitives and they will exist and now anybody can build anything on top of them.

It's it's just insane to think about the value that will acrue on the DeFi layer like give that I mean DeFi has existed in in reality for like what like five five years really like and it's just compounding like imagine if we have this going for a decade like this is going to be man it's going to be way too valuable to ignore and of course once we I think the biggest problem DeFi has right now is like a market depth issue and I think giving the rails for institutions to come on and add the liquidity that only creates like an even bigger opportunity.

So yeah, I think this is unlocking like a big problem for DeFi, which is how do we get the rails to get this liquidity on board and then there's going to be more of an opportunity to build in DeFi. People are going to build more stuff. It's going to make DeFi more valuable. Then we're going to attract more liquidity.

It's just it's it's impending doom for the traditional financial system. But I think you guys are you're working on the right problem here to solve for this. And yeah, I mean going back to the LayerZero DVN architecture, I did not appreciate that like nearly as much. I actually kind of hated it because every time we have to audit like a LayerZero integration, you of course you always have to go and check the configurations for LayerZero because there's like so much that can go wrong with like the DVNs and you've got to make sure like if you're using like a DVN like you guys for AML that must be like a required DVN.

You can't get around it. you know of course like the confirmations and all this stuff. So I don't think I fully appreciated the DVN architecture and all the configurations but it's so cool to see the LayerZero team having that foresight that we're going to want in an institutional error era for interop we're going to want some kind of layer where we can put validations on.

So that's very cool. I think we're seeing the same kind of thing with Uniswap v4. Yep. I think we're seeing a world of hooks and expressivity. Exactly. And customizability. Yeah. And I think that was like what like when we were first raising like doing our fundraising like idating on this in like 2023 the question we would always get is like wait so why would an a include us and my response was I don't think it's about an a like or like they're like why is a why would a Uniswap v3 integrate this because Uniswap v3 needs to be fully permissionless and I was like this isn't actually meant for Uniswap v3 I think that's a wrong framing because I don't think that's actually this is my hypothesis is that and my

Co-founders as well is that we just don't think that the world sits only in a unisop v3 world or just an a world. I think where it actually goes is Uniswap v4 hooks LayerZero dbns morpho vaults lido lido v3 staking vaults I think it's those types of things and all of those are customized vaults in my mind they're like applications that sit on an open and permissionless infrastructure anyone can go into play a hook right like that's actually the piece anyone can go into play a hook and provide the liquidity set their own requirements these are all applications and I think that's the same way that L2s start looking right like anyone can go on an L1 and transact But anyone can go and build their own L2.

And some L2s can be highly highly rigid and highly, you know, like permission. Others can be incredibly open. There's an entire spectrum. And I think that's where we are, that's where the world is going. and I think that's how actually all of this starts getting even more unlocked. It's the expressivity. Absolutely. I think that's a perfect comparison too.

Like a Uniswap V3 very much was built for DeFi. Built for DeFi users. you know, you have of course like the additional granularity on, you know, marketmaking in that side, of course, but Uniswap V4 is built for institutions in some sense. It's of course it's still built for DeFi, but it also can apply to institutions and and players who need to have that customizability.

And I think we're seeing that with a lot more DeFi that's that's coming out like a LayerZero and like stuff like this. I I think that's definitely where we're starting to see DeFi go. And I think it's the right move because it feels as if we've tapped the market of people who are willing to like come on to their laptop, open up MetaMask and like interact with DeFi that way.

And I think where we get to the next level is institutions basically doing the marketing for us and just bringing all the capital on chain because if you think about everyday people like they don't manage their finances. They don't go and mess around with like financial apps. I think we've got everybody who wants to do that. So it's up to us bringing on the people who already have the money and then having them interact with the financial applications.

So yeah, I think you're totally right. It's really interesting to look at the the evolution of DeFi apps and how the the best teams in the space are designing them and you guys are right on the edge with that. But yeah, I mean I'm interested what what has your experience been with Uniswap V4? Are you working closely with it or is that anybody else on your team?

It's not me directly. It's our engineering team. So I can't I can't say I'm engineers working on it. We do have we do have a star engineer by the name of Unmole who has been like the closest on that and so yeah it's been integrating the predicate infrastructure and then as part of this also we're building a rebasing hook architecture for rebasing assets so take like Paxos's yield bearing asset USDL liftoff Uniswap v4 and Uniswap v3 did not allow for rebasing assets to actually be listed on there doesn't work and so actually lets you do that and so again like that's the customization right like there is a tyranny of fully permissionless from a V3 standpoint.

V4 allows you to just do things that you actually just fundamentally couldn't do. That was like important for a Paxos where they're like we can't list USDL on V3, but we can on V4. So we've been kind of pretty deep on that work, but it's not me personally. Okay. So we've got the offering of so predicate comes in and they integrate at the smart contract level and you have an off-chain processing service.

What does that look like when it actually comes to fruition? Like let's say you go to a team and you know they want to implement AML or something like this. What do they have to do to get predicate integrated with their stack? So it's two things. It's three things. One is they should define their policy and that just means they as an organization a team whatever that is they should know like exactly what rule they want to check for and as part of that it's determining what data solutions they want to use for that.

They can use historical onchain data. We've built a graph system. We work also with partners like TRM, elliptic, crystal for let's say risk score data, hypernet for anomaly detection, like weby for fraud detection, CLIC, any of those things. We create we have an open marketplace. So it's first defining their policy and saying here's what we want to solve for.

The next part is the actual like technical integration. So in that case what they need to do is they need to up if they already have their smart contracts they need to update their smart contract to basically have a require statement that a transaction only goes through if it is submitted with a predicate signature in the transaction object.

Y so that's a requirement. Then the other part is how do they how does a user or anyone interacting with the smart contract get the signature in the first place and so most commonly they might have a UI right? So take like a bridge in the UI. You can have it so that it makes a call. So when the user goes and interacts with the UI, it the the UI makes a an API call to the predicate network and says, "Hey, this user needs a signature for this transaction."

So that way when a the predicate operators, offchain operators, basically check the transaction. They say, "Okay, cool. This looks good. Here's a signature." So then when the user submits the transaction, it goes through because you have a smart contract requirement that you have to have a predicate signature. That's the two steps. So, smart contract level integration and then some way of getting the signature.

Yeah, absolutely. And and in terms of the require statement, is that like a modifier that you would add to every function or could you route it through a proxy that just checks and like delegate calls? What does that look like? It really just depends on how their system is set up to be honest. Like it could be a proxy, it could be their smart contract.

It really just depends on how their architecture is set up. No, that definitely makes sense. It's funny because I was thinking about this this same sort of idea of kind of like a coming from it from a security perspective of like how do we just stop exploit transactions before they even are able to touch the smart contracts specifically with us because when we do smart contract reviews, we have a heavy focus on like fuzz testing and invariant testing which lends itself very nicely to be able to like one monitor smart contracts and see like hey are any of these invariants broken?

And if they are, then something went wrong. And then you could just take the same invariance and you could like accept their call data. Like let's say user submits their call data like like with predicate, simulate the transaction, check the invariance and then everything is good, attest to the security of it and then submit it on chain.

I mean it sounds like all this could be done with predicate. That's right. So all that would require here for predicate is you need some type of provider who can check the transaction and say whether it's an anomaly or not. And so that's when a group like a Hypernative or Forta can come in and look like if a developer is like I want to enable these different rules.

One of the things I want to check for is invariance. Our system is simply the orchestration for that right it's simply the the underlying infrastructure to enable that transaction check to be processed. But you create in our marketplace setting its like the developer is like okay great I want to check for that and so then you have a provider who's actually doing that simulation and then saying this transaction is good to go tells predicate the predicate network that transaction is good predicate network issues a signature your transaction gets processed and now obviously you guys are becoming a very important piece of their infrastructure because if one of your servers goes down if one of your partner servers go down or you know there's some kind of a logical issue now you can't provide at testation

No use the app. So how do you guys go about like handling cases like that? Yeah. So I mean our job is to make sure our system is like high throughput, low latency. We can't be the blocker. There is of course a trust assumption on which data providers are they using for any of these checks, right? And so this comes down to their risk tolerance of how they want to do it.

So this could say look we have one if for whatever reason that organization's APIs go down or they're not giving a response you could have a backup right and so you can set those kinds of things and this is also valuable because normally you know any of these groups could also go and build their own system themselves but now you're completely vendor locked in if you're a developer you're like wait I have to integrate this one and I'm stuck with this if I ever need to change anything I can't without updating my smart contract for us it's like look you actually can change at any point in time you have multiple pieces all in one.

Those kinds of things. And that does matter a lot when we're talking about deep level integrations within your technology stack. This isn't just a UI type of question anymore. Yeah, absolutely. And I love that for you guys because of course it's very sticky for you guys as a as a service, especially once you get like integrated in their smart contracts directly.

So, I think that's that's very cool. You guys are becoming a a critical piece of application, especially when we talk about AML and and stuff like this. like that stuff you just can't turn off. So yeah, I mean that that's beautiful for you guys. And I mean you guys do other stuff as well. You do I think like a premputee as a service.

Is that just like another provider that you can plug in or is that Yeah, that's right. So at the moment we don't have as much stuff that's come out like on like more customized premputee like the things I would describe here are things like you can do stable coin like for stable coin minting requirements check if there's sufficient collateral rate limits for capital controls.

This could be for like checking for different identity solutions or at testations onchain, offchain, crosschain, all of those kinds of things. But in the end, like later on, it starts getting into more custom compute as needed. It really just depends on what the needs are for custom compute. But that's right. Yeah. I imagine like as more teams are looking to build with like ZK proofs and like take a lot of their logic offchain which I hear more and more and more teams are interested in like let's just take this out of the smart contracts and generate a ZK proof for this stuff and then and then the smart contracts become more of like a proving layer.

That's something as well that could be like basically built into predicate it seems. That's right. So either we could have so we're not using a ZK model right now because it's too slow and expensive. So our emphasis was how do you have this be subsecond and as quick as possible and as cheap as possible. ZKP started getting more expensive.

It's also more expensive for operators because you need to run like a bigger machine. We can of course also shift our system to ZK or we can have different providers. So for example like Lagrange does ZKPs that could be an information provider in our system as well where it's like cool like I need to integrate a few different pieces.

One of them is the ZKP. You can have Lagrange basically be the ZKP provider into our network also like ZKTLS. So take like an opacity. I need some type of ZKTLS proof. Great. Opacity is able to cover that and then predicate is really just checking to make sure that you have met that requirement. Very interesting. Yeah, I think on that note like we've talked a lot about what you know predicate is doing today.

But what do you see as you know the future of the protocol? What else are you working on? What's on the road map? You know what do you want to see predicate look like you know a couple years from now? So predicate a couple years from now. I'll start with that and then I'll talk a little bit more about what we're doing today as it relates to that.

The predicate in let's say that three to in like three to five years is our vision and our goal is that we are the rails for essentially regulated the the flow of capital across regulated unregulated markets. And so that is you know like the backend policy infrastructure that we've talked about but then from there it's actually all the different rails that sit on top.

So that is you know interop solutions on this hooks like vaults intense systems like we're working with a noma and colani so you can actually have like solver requirements basically we power like the regulated rails for all of that financial activity to happen to be processed and to settle. That's our vision in terms of like what we're focusing on like at the moment in the next like let's say 3 to 6 months is a few things.

One is that we are working on basically launching a policy language that it's called RIGO. has been around since like 2017, but actually bringing that as a system that you can use to express your own customized policies. So, how does a developer actually go and natively do that? Right now, we white glove and work directly with the team and issue it, but it's we want to have it that they can go and issue it themselves and all of those things.

So, that's pretty high priority. Another one is multi-chain support. We're getting a lot of questions around can you like right now we're just on Ethereum, but how do we add like capabilities on other chains particularly different like that starts mattering a lot. The other one is front like the front-end dashboarding and tooling as well. So being able to verify that a policy is actually being checked, who is the who are the operators, being able to select my operators, my quorum, actually issuing my policy itself.

So this fits in with the policy language as well as a front-end like dashboarding and tooling that you have. So those are kind of highest priority at the moment for us. And then the other thing we'll have to think a lot more about and continue building out will be the actual underlying network. And so the model that we've taken is a bit more of a progressive decentralization.

And I would say like not too different from LayerZero actually. Yeah. So I would say we've taken more of a LayerZero model over like an axle model in terms of how we built it out. And that's been a pivot for us. Initially we were taking a much more axel model and we said wait like we can execute much faster and we are able to start thinking about the customizability and that that that's going to be needed over time.

So adding of course like more sophistication to the backend protocol itself, being able to have more control over your your operator network, the task routing of all those things. Yeah. So that's kind of what we'll be that's what we'll be honing on like later later this year. Yeah, that definitely makes sense, especially on like the the policy language.

I don't know. To me, that's it feels like kind of like a Terraform for policy just like a DSL basically. Yeah. Yeah. Yeah. That's that's really cool. And I can imagine if you're doing a lot of that manually right now, you guys are probably bottlenecked on just a lot of like back and forth regarding that stuff. Yeah.

Back and forth or like that way like if they ever want to change it, they're not reaching out to us. They can just go and do it. Those things start mattering. And then it's also you start creating a library. So you know the policy Aleo's put in place is actually the same thing that Plume is going to use.

And so that way they don't have to think about it. And that was actually great for Plume because Aleo spent a lot of time on it because they're a privacy chain. They're like, "We have to really really think about this." And Plume was like, "We need something." And they're like, "Wait, what is Aleo using?" And they're like, "Perfect.

Let's just use the same thing." No, I think code is the right way to do it because it's like exactly explicit. Like it just like you define a rule set and then that is exactly what it is. There's no question about like that's the thing I hate about like legal contracts is it's like it's all in writing and it's like man if you like literally wrote this in a smart contract somehow that would be like just so parsible.

Yeah. Sometimes even when we write like internal docs or like processes, I'll like write a smart contract that like shows this is exactly the process. because everybody at our or like the vast majority of folks are technical. So it's just like this is the language that we use. So yeah, I love definitely like putting that into into code.

In terms of like other bottlenecks, what is what is the number one thing keeping you guys back from getting to that ultimate point of having institutional flow through you guys and having more partnerships? What's the bottleneck right now on predicate? Yeah, I think bottleneck for us will it'll always be engineering. We have to we're always hiring for more engineers and scaling.

So, it's a combination like we'll need more we'll probably need another distributed systems engineer like we need some full stack engineers as well. So, that's definitely a bottleneck. The other bottleneck I'll say is like some of these things just take time, right? Like it's even and like we've s we've seen this where it's like we're like confirmed like we're good on our end and like they just have to deploy, right?

So some of those things just take time and some of these aren't like easy questions that you're tackling either especially when you start going into the more of the world of like financial institutions and fintech which is where I think all of us want to go like more in that direction. It just takes time and so being able to do those cycles work with them like become like close thought partners.

So I'd say like that's the that ends up being the other bottleneck. Yeah, you guys more than anybody probably you've got to be patient. I can imagine with like some of the the regulatory front like that's that's getting sorted out, but it's going to take time. And then I imagine like just some of the big players that are coming in, the institutions that are interested and they're they're just playing around.

Yeah. I mean the amount of time that it's got to take to, you know, work like a JP Morgan like Yeah. Yeah. even like the I mean like I think that's where like the faster activations we have are like crypto projects but like larger crypto projects right like this is where a Paxos Uniswap a LayerZero a Plume all of those like those are ones that we move pretty like move much faster from but even then sometimes they take time to deploy right like like they don't all like immediately deploy either like I'm thinking Uniswap took a while for them to deploy Uniswap v4 and it's most sophisticated engineering teams out of in all of crypto like I have no doubt like the technical capacity of Uniswap labs But even they

Took time to deploy V4 and so some of these guys just some like many larger projects just take a little bit of time to deploy and you're just kind of time waiting for that a little bit. Yeah. And I mean to their credit like it makes sense to to take their time when it's a UNIS v4 like cuz the thing is like man UNISO v2 is still used today.

It will probably still be used in a decade. So it's like if you get it right the first time it's like the value is just immeasurable. But yeah, so bottleneck definitely makes sense. Engineering, I mean, I feel like that's a bottleneck for everyone for everybody in the industry. I think you guys are in an interesting spot because you have a lot that's offchain and I mean not as much onchain, but you've got to have a deep understanding of all these protocols that you're working with and some of them are even like at the like they are a chain themselves.

So that gets like core like blockchain engineering which is you know a different beast than smart contract engineering. So yeah, you've got a very diverse like range of technical pieces to fill. What's like what kind of strategies have you guys been using to try to hire out? Like how's that been working for you? Yeah, it's been a mix of like through our network as well as through recruiters.

Like I think it's pretty similar to what others are doing. I don't know if we're doing we're not doing anything dramatically different from what like most I think other projects do. Yeah. You know, one thing so I mean of course we had this we've experienced the same issue as everybody else especially in like security very niche like field.

There's like just not very many people who are senior and obviously we've been looking for a lot of senior people and it was like the hardest problem to solve. One thing we did is we put out like a big bounty where, you know, we'd put say like, you know, 20k bounty for whoever could refer us, somebody who, you know, ultimately ends up being a good fit.

And I mean, that worked insanely well for us. Like the funny thing is really we we just use it to get eyes on the offer and because everybody will like retweet it and comment and stuff like this. so it get like 50 100k views on the on the offer and then the people will reach out to you directly.

So you don't actually have to pay out the bounty. You could turn into like a sign on or you know whatever. but this is something that worked for us. So maybe if it's useful for you, you you could try that. But just something that you did you guys just like post that online on Twitter or did you do anything else to amplify it?

I mean we just Yeah, we posted it on Twitter and it it gets a lot of views because of the money. Yeah, good to know. All right, cool. Yeah, we might try that. That's a really good flag. Yeah, just a tactic. it I mean it ended up solving solving that problem for us pretty well but yeah I mean another thing is like content obviously but yeah I mean it's it's a hard problem regardless I mean for any or yeah just little tactics like that that's that's kind of helped us along in our journey but yeah I mean okay so so bottlenecks time on the regulatory front obviously the engineering org what are the next kind of like milestones what are the KPIs that you guys are like measuring day-to-day yeah our KPIs day-to-day that we're

Really honing in on is basically we're looking for number of like large projects that are going to be building policies on predicate. That's basically for us. In large projects, we define it as like expected transaction volume or dollar volume of like transaction. So could be a project with a large TVL or it could be a project with like large like volume of transaction flows.

Yeah. And then technically speaking like I mean obviously there's just so much you could do with this infrastructure that you guys have built. What is the focus area at this point in terms of the product? Like is it more regulatory stuff? Is it I mean obviously you're building out the the language for policy like what's one area that you guys are improving right now?

I would say one area we're improving right now will also be yeah I think it's actually just like it's the developer experience. I think it's make this like easy to to build on and and integrate. That's like maybe like the biggest focus from an engineering side and a product side. On a BD side, I think for us it's like primarily like large projects that we anticipate would need predicate.

And so the categories you can consider most relevant for that are usually like stables, RWAs, DeFi, like larger DeFi, interop, and like more of the RWA oriented L2s. Yeah, that's where we end up spending the most like time from a from a business development standpoint. And then on my end, I'm spending a lot of time in DC as well where it's like we can actually, hey, it's like, you know, the things you guys are talking about, whether that's like, you know, the SEC, Treasury, DOJ, FINRA, all these different groups, like here's the things you guys are talking about and wondering how it actually gets solved.

Solve that. and so doing a lot more of that as well. Yeah. And I can imagine you get to see a lot of like what the word is on the street and like get a feeling of like where the space is headed just by hanging around in in those groups. And then you can sort of, you know, position yourself when the market does like open up for for those players like exactly the messaging that they need.

You know, exactly the rule set they need to implement, etc. so that that's definitely a huge advantage. And also I I think there's really two ways you could take a product like this. You could either go mass market and selfs serve and try to have everybody spin up and use the architecture in their own way and they don't even have to talk to sales and they don't even have to interact with your engineering team.

Or you could go very white glove and you pick you know just a select few protocols and you work very closely with them and those are the ones that carry a ton of TVL and probably generate the bulk of your revenue. So I think there's and I I think both are like correct answers. They're addressing a different portion of the market.

What do you guys see as the approach that you're taking? Right now we're taking fully white glove. that's the approach we've taken so far. Over time I think what happens is you start having earlier stage projects and smaller projects that also need this and we can't white glove all of them, right? And so I think the approach we take is this is where having really good tooling matters.

One for your larger projects when you're white gloving and they're like all right the documentation here is really good. we're having a good experience working with you all. But then it starts like for the smaller projects as well, it starts becoming more self-s served. And then I think it's it's a combination of both and I think it's very similar to how blockchains operate or you know like Yeah.

I think actually a lot of blockchains or even projects like Chainlink or LayerZero where you'll have the self-s serve component. Yeah. And then you have like the labs entity and the foundation entity spending a lot of time on like the bigger ones. Yeah. And that is like as much as crypto likes to talk about like all this is permissionless and it just happens.

It doesn't. The biggest things usually happen white glove. It happens through like ongoing discussions and consensus. And I saw that at Celo as well. It wasn't like for any like major launches. It involved usually like close conversations and planning and all of those things. So I think we'll continue having to do that especially when it comes to the large projects and when it starts coming to like more of the web 2.5 groups, right?

Vintex of the world are not just going to go and self-s serve this. are going to say, "Wait, we need to talk to someone and we need to understand how this works and we actually want a team that we're working with on this." 100%. Yeah. I mean, I think Chainlink is the perfect example of that because obviously they've got, you know, bespoke deals and and they work very closely with some teams, you know, I mean, they've got a a deal with like GMX for their data streams and stuff like this and of course like nameless others, but they also have their probably most widely used aggregator contracts, which you know, I think what like probably 60% of protocols use a Chainlink aggregator as an oracle in some way.

Maybe it's a fallback Oracle or something, but like that type of structure just creates like I think a lot of excess value for the ecosystem because it makes sense for them to just have this publicly available Chainlink data feed structure and you don't have to pay for it. You don't have to like because you know Chainlink doesn't make try to make that much money, right?

Yeah. And I think but it still does create massive value for Chainlink from like just providing value to the ecosystem. You get an amazing reciprocal effect and of course they have an immense brand value associated with that so that they can you know then go and work with some of these bigger names and and build some of these like more adept solutions that are more customizable.

So yeah, I think that approach definitely makes sense and you guys are are headed in a in a great direction with that and I mean let me know when you guys spin up like a a self-s serve predicate solution maybe maybe guardian buzzing invariant predicate soon. Oh yeah that'd be awesome. So I mean beyond that is there anything that you're trying to push folks towards today?

Is there anything that would be available for anybody that wants to check out predicate? Can they play around with anything or is it all like white glove at the moment? What does that look like? It's all white glove at the moment. So if folks want to check out how it works, they can go take a look at our docs.

We will have some more open source stuff in the next few months, but not today. So the best thing I would say is if they want to learn more, they can go take a look at our website and our docs. Okay, sweet. So we'll definitely have the website down below. And then of course, I mean, we've got a pretty big technical audience.

So if anybody is like pretty bullish on what you guys are building and they want to solve some of these problems at different layers of the stack, where should they reach out? Yeah. So again, our website's great. I'm also on Twitter. Our organization is we're also active on Twitter. And then our website contact info and there's a contact button and there's also a a jobs jobs platform as well.

So any different ways that folks want to get in touch, they they'll see it. Excellent. Yeah, we'll make sure to to have those in the description below. Any big releases, any big partnerships coming up? Not other than the ones that we mentioned. So, the ones that were that we kind of went through. So, Plume with LayerZero, Uniswap with Paxos are probably the two biggest ones that are coming up.

Excellent. Awesome. Sounds good. Yeah, dude. Appreciate you coming on and and learning about Predicate and everything you guys are building. A lot of cool stuff in the pipeline and I'm excited to see what kind of institutional capital you guys can help sort of like bring into the the ecosystem. So, we're rooting for you guys and yeah, dude, appreciate you coming on.

This was a lot of fun. Thanks,

More episodes

All episodes →

Building onchain? Talk to Guardian.

Guardian puts two independent teams on your code, then keeps watch over every update after launch.