# Compliant Cross-Chain Lending With ZK Pre-Checks | Kacper Koziol - Amish Protocol

- Channel: [Ethereum Denver](https://streameth.org/ethereum-denver)
- Date: 2026-03-09
- Duration: 16:23
- Topics: ETHDenver, Crypto, Web3, Blockchain, Event, Conference, ETHDenver 2025, ETHDenver 2024, Bitcoin, Ethereum
- Watch: https://streameth.org/watch/yt-zv2LUOEz1Bw
- YouTube: https://www.youtube.com/watch?v=zv2LUOEz1Bw

## Description

Kacper Koziol is Co-Founder of Herodotus and leads institutional strategy at Amish, a novel cross-chain lending protocol powered by Herodotus's ZK coprocessor. He's the architect behind Sentinel, a new kind of defense infrastructure that brings provable compliance and criteria enforcement to protocols deployed on permissionless blockchains. Through Amish, he designs how these primitives can enable DeFi products that meet the needs of institutions seeking compliant ways to deploy capital, transact, and participate in the open Ethereum ecosystem.

## Transcript

All right, I'm excited for my next speaker. We have Casper Kosiel, institutional solutions lead at Amish Protocol. He's going to be talking about compliant crosschain lending with ZK PreChecks. Really excited. Please welcome Casper. Hello everybody. So let's begin. Uh my name is Casper. I'm the co-founder of Heroditus. Uh I'm the institutional solutions lead at Amish Protocol. Uh where we're working on a new type of lending on Ethereum. And today the the title of my talk is essentially compliant crosschain lending with ZK pre-checks. And I'll dive deeper into this in a moment. So before we begin, we need some background context. And we're going to go look at the big picture over here. So in the Tradfi world, the playbook is flipped. So historically in Tradfi institutions have always had deep access to deeper liquidity, better tooling, better networks, better connections and so on. And although in recent years like we've seen a lot of like rise of neo banks and so on trying to give access to this like the things that they've already had access to for the many many many years back. It's only now that that's happening and essentially DeFi became too big to ignore where it became something that these institutions now want to basically participate in. they want to become members of this uh of this marketplace of this economy and um so far this has been happening through permission forks and um permissioned layer twos, layer ones and so on where they have control over the criteria, the compliance uh rule sets and so on that are imposed onto them by their respective regulators. And um yep that's basically been uh the the response of the industry and what they got so far is through these permission forks is essentially they got the technology stack they got access to automation of things that normally they would have basically been doing manually uh within their um organizations. They got access to the smart contract infrastructure, the settlement mechanics, but the key factors that have been left out of this are essentially access to unified liquidity, market depth, competitive rates, and broad participation. Basically, the definition of an open economy. So, uh I have a quote here that says you can fork a repo in five minutes. Honestly, these days with an LLM of your choice, you can probably do that much faster. Uh, but you can't fork the liquidity itself. And looking at this, uh, drives me to basically introduce Amish lending. So the traditional form of lending in DeFi is through pools. Amish does things differently. So essentially, Amish lending is an intentbased order book. We have per market pairs and participants sign intents of what they intend to what kind of position they intend to basically enter into. We have an off-chain matching uh matching engine that finds counterparties uh whose terms overlap. So as in any market you got buyers and sellers and lending we have lenders and borrowers. From the perspective of Amish, we in the lending markets as a lender when you're onboarded, you basically are able to provide a clear overview of what your individual risk parameters are, what assets you accept as collateral, what assets you are willing to provide, what rates you're willing to provide, what LTVs you're comfortable with for those asset pairs, what durations of loans are you comfortable with, as well as any other arbitrary criteria that you can come up with. As a borrower, the user experience is pretty simple. You go on a website and you basically connect your wallet and you see exactly what assets you have across all the various chains that you you deployed capital on and you're able to basically check mark exactly which ones you want to be able to use as collateral. Then you basically put inside inside like a box of like what do I want? Let's say I want 100 USDC on arbitrum. I click submit. This is an intent. I showcase the intent of what I want and where I want it. This intent is sent to a backend with the signature. And basically the backend checks if there's any overlap between what this user wants and whether there's any overlap with what any of the existing lenders um have or are willing to provide. If there is any overlap, a trade is executed. So, it's essentially peer-to-peer with fractional fills. We have isolated risk, which is a big benefit compared to uh the traditional pool model. This unlocks access to things like exotics, longtail assets, and so on. And you have fixed terms that match, which are optional, but you would be able to have like variables terms as well. So, what are sentinel pre-checks? This is the modern solution to to this to unlock institutions to participate on public permissionless blockchains. We're able to combine intents and pre-check criteria inside this protocol. So with Sentinel's intent carry cryptographic pre-check criteria alongside the standard parameters. So the standard parameters are things like collateral, principal, LTV, APR, duration, and which chain you're on. But we're able to add additional criteria which is specific to one of these counterparties. So for example, one of these pre-checks can be something like sanctions. Hey, I want to make sure my specific account is not a member of this set of this data set. And we're able to do that by verifying proof of non-inclusion inside an off-chain accumulator. So we have like an off-chain accumulator that's basically growing everyone that's member of that set and we verify that you're not a member of that set. We can also have pre-checks for things like KYC. I want to make sure that you are a member of that says that you have completed KYC with some sort of provider. Then maybe you have an NFT that represents that and uh that's that's the proof. Next another example is something like risk scoring. So you can have an like a module that calculates a numerical risk score that can take into account various factors and ensure that you're above some sort of threshold. All of these together we can verify these accumulator rows on chain before match execution. Why is this critical is because if you don't fulfill the criteria the transaction reverts. It never enters the protocol. It never becomes a protocol's problem. Uh which is very powerful. So this introduces a new concept of something we call visible but inaccessible liquidity. So so far when you have like permission forks of uh various different DeFi protocols all of them basically start from scratch they has to build up their own network effects market participants attract them um in various manners. But with this unified orderbook approach, essentially what we have is we have a unified order book where everyone submits orders to the same order book. However, you provide pre-checks for the criteria that is specific to you, not the counterparty. It could pertain to the counterparty, but it's you're in a specific uh like jurisdiction. You have specific criteria that you need to follow and that is included as part of your intent. And if there is overlap that matches that your order is executed. If there's not, then it basically is not. And the terms at which you're basically um matched have to be basically available inside this order book. So the order book is shared. The fulfillment is selective. This introduces a very significant incentive shift where additional constraints that may exist beyond the compliance baseline which we're going to define as something that's like fundamentally important and necessary to include. Uh in this diagram over here you have this uh shown as like sanctions and KYC. We'll include that as like a baseline. Anything above that that's additional. So for example like scoping by region, risk scoring, some sort of other exposure criteria, some sort of white list, a jurisdiction like scope. Um they continue to restrict this the size of the set that's available inside that order book. But the order book itself is unified and the order book is crosschain. The order book represents intents that are aggregated from the whole Athereum ecosystem. So reducing constraints essentially unlocks new liquidity. So what's behind the root? So there's two types of accumulators we have. We have trusted accumulators and provable accumulators. Trusted ones are essentially managed by a centralized or external party. Um humans or like uh corporations maintain the data. Some sort of centralized actor maintains the data and enforcement is cryptographic via like Merkel proofs. These are inclusion proofs based off the data they provide you. So these can be things like government sanctions list uh KYC attestations institutions own approved list of who they want to collaborate with. You could have a peer-to-peer relationship inside this kind of like marketplace where like you have a unified order book and you're like I want to participate with this specific counterparty. You basically add them as a specific like uh counterparty you only want to execute trades against. You could also have internal blacklist of non-inclusion. I was like, I want to make sure I never interact with these these folks. Next, you have provable accumulators. And this is something at that like at Heroditus we've been working on with our ZK co-processor where we can offchain construct accumulators that um are built using a predefined pre-committed criteria. So you could have multiple actors that construct the same accumulators offchain and then prove that these accumulators have been constructed correctly and then you just post those roots on chain. So what can you what would be the scope of something like this? For example, if I ever wanted to prove like everyone that historically has interacted with tornado cache, I can do that. Uh I can prove that like everyone that has ever like held an NFT or like has currently holds an NFT. I could construct this accumulator which is essentially like just a data data structure u offchain. Um things like rolling volume. So I could have an accumulator that as every single block is produced we have like a rolling run running balance of what is the volume that that account has done in the last 24 hours. So uh keeping them current can be done offchain. you basically post those roots of like what's the latest status on chain based on your like uh use case requirements um and so on. So both both of these basically produce a route that they have different security properties but the pre-check mechanism is essentially the same for both um yeah so here's some pseudo code essentially just to give you intuition of what it looks like from a smart contract developer. If you're a smart contract developer and you have any some sort of like criteria that you want to basically enforce, uh you would basically do like a pre-check. You would basically put who the counterparty you're trying to interact with is. You would put the root of the accumulator that you're trying to verify criteria against as well as a proof. So this could be like a Merkel proof uh against uh an offchain uh data structure that you've generated. And then you basically require them to basically fulfill that requirement. So inside Amish lending essentially what we'd be able to do is be able to provide institutions with a way to participate engage with each other on public permissionless blockchains without having to basically launch their own instances of such. So uh a sentinel pre-check it fires up before any state changes. If you don't fulfill the criteria it simply reverts. It never becomes a part of the state. Um you verified marker proofers at the root. If it fail there's a revert there's no side effects. Uh criteria can be arbitrary. You can have counterparty identity volume risk market volat volatility bounds portable and any protocol with a transaction boundary can integrate this. What's the outcome of this open economy? So essentially what this allows us to do is it allows us to have instit institutions to participate and tap into uh a unified liquidity liquidity uh set. I don't want to say liquidity pool because it's essentially a unified order book um on on on a on a public permissionless blockchain while fulfilling the the criteria that's required by them by their jurisdiction of operation. So historically we've had protocols that basically define their own rule set and deploy deploy their own instances and they've always been accustoming the whole protocol to their requirements. Here we kind of like turn tables where you as a participant impose those requirements onto yourself and the protocol itself remains permissionless. And this is very very very powerful because it has this self uh restricting factor where like over time it incentivizes like decreasing the the amount of constraints that are uh that are imposed on you because that unlocks more liquidity uh larger market access while still remaining compliant to the jurisdiction that's specific to you. Um so yeah so constraints enforce at a transaction level with a shared public market without fragmenting it for anyone else. So the three main takeaways of this talk are compliant constraints are real. So market fragmentation to enforce them is a regression. Solving that that as a transaction level preserves the thing that makes public defi valuable. Number two the accumulator framework supports both trusted and provable data sources. sanctioned list, KYC at the station, onchain behavioral data, internal white list, all produce roots all feed the same pre-check mechanism. Three, the Sentinel pre-check calls pattern is portable and criteria can be arbitrary. Identity risk parameters, market conditions, anything representable as an accumulator. This is infrastructure. So, I'm going to leave you with this quote. Uh, essentially compliance is non-negotiable. It's going to exist either way, but fragmenting markets to enforce it is a choice. And at Omish Market uh lending protocol, we're essentially trying to basically make this division of what we're trying to build. So, thank you everyone for listening and um I'm I'll be around to answer any questions.