# Build the Swap, Design the Protocol — Sasha Kazachenko | CoW DAO

- Channel: [ETH Belgrade Community](https://streameth.org/eth-belgrade-community)
- Date: 2026-10-06
- Duration: 20:17
- Topics: People & Blogs
- Watch: https://streameth.org/watch/yt-gzApp_SIqgs
- YouTube: https://www.youtube.com/watch?v=gzApp_SIqgs

## Transcript

Hi everyone, thanks for introduction. Today uh my talk goal is to tell you what are fundamental mechanisms and approaches in modern defi uh dexes projects like you know uh cow protocol 1 in u unis swap and any others and I'm going to bring you through a process of building and intentbased decks. So nowadays almost every Dex is intent based. What does it mean? It means that uh user doesn't act uh directly on chain. It doesn't execute a transaction. It only signs an intent and a primitive flow will look like that. So we have an intent. Interesting why T went down. Anyway, so it has an uh authorized an intent and we put it into some audio book. It's just a collection of intents. We have a solver which is an actor which takes a bunch of intents and put them into blockchain calling settlement smart contract and the intent itself it looks like just an object. Yeah, let's represent it like that. We define intent owner assets you want to sell and buy amounts uh deadline and so on. And first fundamental thing is ECDSA elliptic curve digital signature in EVM. Uh we have EIP712 data hashing and signing. Basically you can sign any data let's say some object in our case it's a intent and you can verify it on smart contact level or anywhere else. That's a uh very very basic and primitive thing we're going to use. So please keep in mind we can sign something and verify it to it means we can prove that it belongs to some account. In this flow we have almost everything offchain. Yes. So we sign intent using some wallet uh using your private key. Yeah. So uh it's it doesn't touch uh blockchain yet. We have audiobook which is can be just a database posgress anything else and we have a solver is just a logic defined by someone. The only thing we have is uh on chain is settlement smart contract which actually holds the logic of transferring funds from the source to the user. Okay, that's a primitive flow and the first question how to extend X. Yes. So the intent model is quite narrow one. We have only a few fields there and let's start from some scenario. For example, we have an integrator of our decks and they ask us like uh I would like to see how much volume I generate. So I integrate your decks and I want to see which orders are mine. How would you implement it? I would go with something simple and stupid. So we can add another field to intent model. Yeah, obviously and update order book and settlement contract basically like that. So we just add another field partner ID which is a number. It will work but it requires smart contract update every time. So every time we want to change our intent model we have to update smart contract because it uses verification logic hashing and it it depends on the data and of course it's not scalable. Let's try again. We can create an offchain database table. Basically wiring up partner ID and intent. Yes. So a pair of keys partner ID or ID also will work. But this is trustless because DB owner can manipulate data do everything they want. Do you trust them? Up to you. Okay. Are there many better ideas? Uh I have a one approach. We call it app data. Doesn't say anything so far. Yeah. Uh let's just take it as a set of bytes in our intent. So it's not something specific. Yeah. It's just a set of bytes. And those bytes are actually a hash of some JSON object which can be stored to IPFS or anything else. And the document itself can be extendable. So we can put as many data as we want like a slippage, partner fee. So any metadata and how we build the hash quite simple one yes we can take JSON object uh deterministically stringified it's important yeah to have uh deterministic output and just hash it using some algorithms like uh kitak 256 and when we post our intent now to audiobook uh along with that we put the updated document to some storage let's say IPFS With that we can easily verify that this document object is coupled with the intent. Basically we just hash it and compare if it matches the app data hash in the intent which is signed your with your private key. Cool. With this approach also works and it's scalable. Once we define app data field in our intent model we can extend it easily. We don't have to change uh settlement contract or anything else and of course yeah at verifiable we are hashing. Okay cool. So now we have some storage some extension of our intent and there's another thing you have to deal with anyway uh in uh EVM blockchains those are C20 allowances I hope many of you uh already know what is that but basically in order to transfer your token to give to make some smart contract transferring your tokens you have to allow time to do that. And there are two main ways. There are actually more like a permit to and anything else. But let's consider uh the basic ones. Before submitting your intent to order book, you could you can make a onchain transaction calling approve method of sell token. It works but you have to do two steps. Yeah. So first make a transaction then submit your intent. But there is also ESC 2612 permit. That's a method of uh ESC20 smart contract which receives a set of parameters like a holder of token spender who you allow to spend uh like a value, how much uh deadline and so on and your signature. So those parameters are actually same as in it's a EIP 712 data signed with your uh account. And we can like uh encode it into some uh onchain call. Yeah. Defining what smart contract we're going to call, sell token address and uh the payload itself. Which method and which arguments the method implementation it looks like that quite simple one. So basically again similarly to how we verify intents we can verify permit and yeah if it matches it basically gives an allowance and what's the most powerful thing of this approach is that anyone else can execute the transaction on behalf of you. So basically you only sign data you don't have to pay gas for executing this uh permit call. So it it allows us trading gously once you create an account. It only handles uh ESC20 tokens and non-native token you can trade it. Okay. We can use that we could change uh settlement contract. Yeah. To support permit method alons specifically for this case. But let's think ahead. Uh so we would want to have any other smart contract call not only per media before trading or after that way we can design our settlement contract like that. So basically we can add like uh executing calls smart contract calls before and after transferring funds. Yeah that's very very primitive example. Yeah please uh take it as just a uh primitive example. In practice, it must be much complicated to make it secure. But it makes our settlement chainable. So we can put it in the middle of some flow. And since we already have app data, we don't have to think where we should put these hooks into intent or somewhere. So there's a storage, there are some metadata of intent. And I will remind you about uh one programming design principle, open close principle. Yeah, if there are uh developers who remember solid, yeah, you probably know. Basically, it says uh software entities like classes and smart contracts, I can also apply here should be open for extension but closed for modification. So, implementing hook hooks mechanism, we make our settlement extendable but is still closed for modification. Perfect. It already works. We already have something. But let's uh consider more use cases. We would want our decks uh work like that. Withdraw funds from liquidity pool and then swap or we can swap and then bridge tokens to another chain or even have something more complicated like uh sell automatically every hour or implementing trading strategies like a stop-loss. I will start from something uh primitive not primitive but not so complicated as other cases swap and bridge. Yeah. So basically we swap and then we bridge. There are various of bridging providers nowadays with beautiful designs in academical reasons. I would uh make it simple. Let's say our bridge provider is just a smart contract with one method deposit and it just takes funds from messenger uh from the transaction sender and put it into some wa since it uses AC20 tokens it needs we need to give an allowance first of course and deposit caller must handle this swapup output as you might remember uh it transfers from the messenger sender okay first think like I need to give an allowance first. It's uh quite solvable. Yeah, we have permit uh ERC 2612. Okay, can be applied here. But what about the second one? We cannot act uh on behalf. I mean we cannot use our EO account after uh the swap. Yeah, we could do but it will be just a separate step. We cannot do it uh atomically within a settlement. And yeah that's a problem but there is also solution account abstractions like hot topic nowadays. Yes we have a lots of wallets implementing this design. Basically I will take it as a smart contract which acts on behalf of you. You authorize it to do something and we can design it again uh like we designed hooks. So we can make it abstract to run uh arbitrary uh smart contract calls. That way we can deploy an account production uh smart contract. We can specify its address as a recipient of intent. Yeah. So the funds will go there and we add a post hook to our intent uh saying call this account abstraction and execute the calls like approve deposit and we actually can encode more uh different steps with this approach. We don't touch settlement contract at all. Yeah. So we don't update it. We use existing hooks and we have reusable account abstractions that can be used not only for swap and bridge but anything else. Cool. I would consider one more uh primitive to build uh scalable decks. Uh I call it program programmatic orders. Those might be different trading strategies. let's say uh DCA stop-loss uh t-up and others. I will start with tup time wished average price order. It's basically an order splits a large trade into smaller equal parts. The smaller slices execute automatically at regular time intervals over a set period. In short, for example, you say I want to sell 0.1 R bit Bitcoin for USDC every 20 minutes 10 times. It means you are going to sell one bitcoin within uh next 200 minutes in equal parts. How would you implement it? Again, let's start with simple and stupid. You can send your private key to an API which will run a job which periodically will create an intent and put into order book signing it with your private key. Yeah, of course joining. No, never do that. Never send your private keys to anyone else. Uh but so what's the problem? We need to authorize intent uh on behalf of your yourself somehow. Yeah. Programmatically. And here I have a question. Can a smart contract authorize an indent? So we know that uh smart contracts uh they don't have any private key. So they cannot actually sign anything. Yes, there's a solution. There's a standard EC 1271. That's a quite a simple uh design. It says that the smart contract should implement is valid signature method with two arguments hash and signature. This standard says that verification logic is up to you. So you can program program code it uh as you want. It doesn't dictate you. And the signature it's not actually a signature. It's not a uh output of cryptographic algorithms. Those are just byes which encode like a parameter proofs or approvals. Let's see it on practice. I hope it's readable. So uh the smart contract of for TVAP orders might be designed like that. So we have a authorization state. Yeah. With two keys uh owner and hash of your TV parameters. It's like a number of parts assets and so on. And we define two methods create and isal signature which is implementation of ERC 1271. When we create we basically authorize this tap orders rising into state and we trigger an event. We will need it in the next slide. Just keep in mind that we trigger an event to uh have a signal that tap was created. And while signature verification looks like that it's again very primitive uh example in practice it will be more complicated. Basically since signature is just a set of bytes you can decode it take a intent from that like a hash it and read authorization and say if it works. There is one more method we should define which is uh view call. It's not a it's not supposed to be to call it as a transaction. So basically it's a generator of part orders of intents. Uh we would call it periodically to check if we can create another part or not. And of course it uses ERC 1271 to sign intent. With that approach we can run an indexer offchain service which will watch onchain events. You remember we trigger t up created event and once we got it we can start pulling the view call get particle order and when it gives us another part as the logic might be call it arbitrary up to you we uh put it into order book yes settlement contract must support 1271 it's something that you must think in advance yeah that's a very basic thing with this approach We can have various of trading strategies like a stop-loss and anything else and we keep uh the full secure. We don't reveal private keys or something. We just use uh C1271 to authorize intents. Yeah. And the beauty of this solution that once you authorize it, you can generate multiple particle orders. Yeah. Up to your logic. Okay, that's not all. Of course, the dexes are more complicated. There are much more uh things uh you should do. But those four we just went through are really basic and if you take them into account when you develop your decks or integrate it or use it uh will make you more flexible in the flows you choose. So we the first one is EIP 712 which is super basic. Yes. uh implementation of cryptographic algorithms. We have app data which is a hash uh makes your intent extendable hooks which makes your uh settlement chainable. um not even settlement but uh the protocol itself and of course uh ESC 1271 which uh gives authority to do smart contracts to make intents. All this mechanism are in use in cow protocol and they are implemented in cow protocol cow SDK which is type library. You can using this tool you can uh use swaps, limit orders, tap, crosschain orders and many other things. Uh yeah, as I said it's a typescript library quite lightweight ones. So it's reshakable. You if you don't want to use uh tlop or crosschain swaps, you can just import specific package you need. Uh it's provider agnostic. You can use it with VM eer 5 eer six uh libraries. So you don't have to upgrade your front end. For example, if you use eer 5 and it has layer facet, it means you can go into deep details and do some low lowle stuff uh using like uh signing utils or order book API or for your convenience there are classes like order book trading SDK where you can just call get quote and swap. That's it. Yeah, you can use it even this week. Yeah. To build something if you want to learn more about how it works, about the concepts in depth. Yeah. So, we didn't go deep during this presentation obviously and yeah, you can go to uh cow.fi documentation portal and see it there. Thank you. Thanks.