# Why ERC 7683 is broken and how to fix it by Vaibhav Chellani | Devcon SEA

- Speakers: Vaibhav Chellani
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-09
- Duration: 21:16
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-TOkUi0asAd0
- YouTube: https://www.youtube.com/watch?v=TOkUi0asAd0

## Description

While I appreciate the authors spending time on this problem statement and thinking about standardising flows, ERC 7683 is deeply flawed it still forces offchain agents to understand the order they are trying to fulfill and it doesnt give users any guarantees of execution or understanding of whats happening under the hood, I think its because its standardising things on the "intent" layer where instead we need to standardise more downstream so information like security can be better presented

Speaker(s): Vaibhav Chellani
Skill level: Intermediate
Track: Layer 2
Keywords: Appchains, Cross-L2, Token bridging, Accessibility, erc-7683, intent

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] thank you so much for sticking through I know everyone's hungry for lunch so am I uh hopefully this this will be a solid one after which you think you will need a break um super glad that you are still like up and Alive um sweet guys I think to get into it um um I sort of like wanted to talk about this upcoming thing called intents which is supposed to sort of like change how we interact with chains going forward and a bunch of like projects are starting to look at it in a pretty deep level including people at Unis swap cow Swap and a bunch of like other protocols um so I just wanted to chat about an upcoming proposal there and talk through some of the design choices that have been made and why those might not be right and how could we potentially fix it uh this is not a diss track this like I'm using the EIP or ERC as like U sort of like a channel to talk about this stuff not really uh talking about this specific uh implementation right I work at socket I'm web of also go by VC you can you can find me after the talk but if you want to check out the exact proposal I'm talking about here there's a quick QR code uh I think this is by Mark T from Unis Swap and this is what Unis swap is going to be using for the crossing swap stuff generally speaking um I think we always begin this topic with what really are intents right um unfortunately that is something I don't want to get into for this particular dock right it always sort of like goes into like something you don't want to get into right but I think broadly speaking you want to do something on chain you specify it someone else takes care of it that's like the rough mental model you can have in mind and this is different than transactions because in transactions you sort of like send a transaction on chain saying exactly what you want to do but here you just talk about the end goal you want to achieve and someone else sort of like takes care of the execution that's like roughly how to think about it um so I'm going to talk about like a particular sort of like design pattern here um goals of this particular ERC 7683 are about how do we make it such that uh fillers aren't fragmented this probably doesn't make sense right away so let me give you guys a quick like walk through about what really is happening here so you see a nice farmer Emoji there that is the that is our normal blockchain user today who is sort of like signing something that looks like a struct where he's sort of like talking about what chains he want to go between what's the input asset what's the output asset things like that right and he sort of like Signs this stuff and sends it onchain to a particular settlement contract on some Source Network where a bunch of like these robots these Bots sort of like look up to this Source chain contract for what are pending intents that need to be filled right and then they sort of like fill it on the destination and then there's a Oracle that sort of lets the settlement contract on Source chain know that hey the request that you had has been fulfilled by this particular bot on destination right so really simple um user sends funds on Source the Bots fill it on the destination and then the Oracle sort of like conveys the message that you know things are done really I think filler fragmentation starts here right so now we have two structs which basically means like now we have like two intent protocols the only difference between the first one and the second one is that the second one has an extra parameter called call data let's assume everything else is same this is the only difference right um due to which now we have these two separate contracts and earlier while we had like eight fillers solving for this particular intent protocol as soon as we have two intent protocols these are now split in two right as more and more intent protocols go live sort of like fillers get fragmented because they need to do more work they need to do more Integrations and stuff like that right super annoying stuff um this is harmful for everyone not not exactly harmful but like really undesirable specifically because there aren't too many fillers anywhere in the space right there are there are probably like 15 to 20 entities that are sort of like operating in this particular role and if you sort of like start fragmenting those we don't know where we'll end up right so we want competition over here so we want as many fillers as possible so fragmentation is something we want to avoid here fragmentation is bad for all three of these parties it's bad for the user because if people aren't competing you're going to get the worst possible price right it's um and if you don't have like an intent standard then you don't actually understand what you are signing so someday you might sign something that give someone authority to pull all of your funds away forever right so you know like chances of rug pull we hear about fishing attacks with like permit to Witnesses all the time right so we want to like standardize on this layer for sure it's bad for intent protocols because we had eight fillers you launch an you you launch an intent protocol and you have to like sort of bribe four of them to sort of like Port over to your thing and then as more and more of these protocols launch it becomes even more more expensive because these fillers aren't commoditized uh they are sort of like specialized and you have to like get into like specific agreements with them and whatnot so ideally you want to commoditize and have a lot of fillers so you have high competition if you launch an intent protocol you have fillers for your user requests and for fillers um they just want access to more autoflow without doing a lot of work so as a like just as put on your Market maker hat what you want to do is like if there's an opportunity out there I have capital I want access to that opportunity for the least amount of work possible so I think all in all it sounds highly beneficial that we should like standardize this part of the layer for all three of these parties and that's what the CIP is trying to do the ideal world is where I launch a new intent protocol and all filler start filling on my protocol on day one with like close to zero effort that's the idle world that's the world the CIP is trying to take us to um again put your Market maker hat on imagine you are participating in one of these intent based protocols how does a filler decide to fill like what is the decision Tree on their end right um you receive an intent the the first thought you have or the first thing your program does is do I understand this aut type and like how do I interact with it uh with this particular onchain contracts and stuff like that like really like generic interpretation uh second is like do I understand how does this particular protocol work can I fill for it stuff like that so users and fillers are sort of like entities on both ends and we need to give them like a way to sort of like communicate think about it like sending a mors code right like you are stuck somewhere and you're trying to send like a morse code through to someone so that they can come and rescue you you want to make sure they understand your Morse code otherwise you're sending signals they just think it is like a faulty bulb or something like that right so you you want to make sure your signal can be understood and interpreted correctly and you also don't want to mean situations where you're sending something like hey um I have an apple but what they interpret it as I have a bum right that's that's also a a bad place to be in so this interpretation needs to be on point especially in this context because we are talking about financial contracts uh wrongful interpretation here means you lose money so this is the first thing that you think about as a filler can I interpret this thing okay the second thing you think about can I fulfill meaning if the user is saying hey I have some a over here um if the user is saying I have 100 a over here give me like 200 a on this chain this is something that is simply not possible or like why would you give anyone free money unless you're getting more free money down the lane why some airdrop or something so you after you interpret you just make sure you can fulfill what the user is asking for um basically sort of like making sure you understand the terms and conditions and you are like opting into it all right so once you interpret you understand the terms and condition now now you are like okay uh how much am I going to make on this thing and do I participate on this thing or not so now you start calculating profit loss and all of those things so this is like how a market maker or a filler will sort of like think about your intent as they sort of like flow through this is going to be like super important as we go about this stuff so I think um if you if you think about it like why does filler fragmentation like exist on a on a on a deeper level so every sort of like order or intent is basically like a shared language between a user and a filler how many languages do people in this room know I think I know maybe like four I don't think anyone in this room knows above 20 um so I think it's like hard for us to like think that uh fillers will know 20 25 different like intent protocols because those are also sort of like shared languages um and as I mentioned before right these are like Financial contracts and misunderstandings have a financial cost attached to it if you sort of like assume that this person wanted a million dollars but you send $10 million you are now down $9 million right so uh misunderstanding here has a financial cost so you want to make sure you're interpreting and your share language is tight um yeah I think as a filler in this space once you have your strategy once you have your Capital you spend most amount of your time sort of understanding how different protocols work and how you integrate with them and stuff like that um now we are finally getting to the EIP itself right if you think about it it is just a translator everything in sort of pink is standardized by the EIP and everything in green is sort of open for developers to build on so as a user you send a cross in order this settler contract it sort of like translates it into a resolved Crossing order which is standardized so that all fillers get the same resolved cross in order so this thing acts like a translator sort of what's inside a settlement contract like the thing in the middle in the last slide it receives a cross in order it in it sort of like has defined interfaces to receive the order but then it's open for developers to interpret it however they want and then Dev can do like whatever they want in the settlement contract and then they sort of like emit standardized events across the board right uh which which include the resolve cross in order that the fillers trust as like source of Truth almost um from a filler point of view right consider this intent protocol one that is 7 7683 compatible right so there is a crossan order that goes in and you can see a result cross in order order on the other side that exactly matches now I built another intent protocol that is also 7683 compatible but the devs did something on this one what they did was now if you look at the cross in order and the result cross in order you will notice that the destination chain ID has been manipulated so in the crossing order the two chain ID was 137 versus in the result Crossing order the destination chain is 420 because the dev did something what they did was they interpreted incorrectly so now the filler thinks that he's supposed to fill on chain 420 but actually the user wanted funds on 137 so now the filler is in in a in a tough spot even if he executes the intent he will never get fulfilled or never get his money back uh this is basically because you I think the the protocol is like too generic and gives developers or like this settler contract too much power and fillers don't get any assurances of like what exactly can happen in in the middle over here uh so yeah the the core issue is fillers can't trust data from like these unauthenticated contracts they have to go and sort of like audit read each of of these settler contracts uh these these contracts in the middle these are called settler contracts in the ERC they have to go and understand each of them and only then they will accept data from it so ideally we like the goal was to be able to work with just standardized resolved orders which you can find on that bottom there resolved cross in order idea was like all fillers will be able to work with this but not really people have to like fillers have to understand the result cross in order as well as the settler contract for them to actually start filling this stuff right so we are sort of like again in our present world where fillers are fragmented by like different intent protocols which is the world we trying to avoid so I think like uh getting to potential Solutions right otherwise I'm just like complaining on the stage for the last like 15 minutes uh some potential solutions to this is that we sort of have this like giant black boox in the middle called settler contract we sort of like break it down into smaller modules modules that provide sort of some guarantees to fillers on whatever settlement that they want to uh operate with right so we sort of like break down this like big giant blackbox that developers can do anything with into smaller standardized modules um one such module could be a standard escro implementation idea is like imagine the smart contract really really simple smart contract you put in funds with a key and with a time lock and you attach an oracle with it now funds can leave this lockbox either when the timeout happens or when the Oracle asks uh to sort of like withdraw so your trust model as a user is like very well defined and as a filler as well you know if the funds have reached the lockbox they are going to be unlocked for the user in 2 hours but you can unlock them VI the Oracle for the next like 2 hours or like whatever the time uh limit is um and this gives you like really strong guarantees now and you don't have to like care about what the settlement contract does as long as funds reach the lockbox and you have the ability to build a right key I'm I'm planning to write a little bit more about this potentially another EIP building on top top of 7683 but I think generally what I wanted to convey with this entire sort of like topic was uh intents are going to be super important intents are going to be the way we interact on chain intents are going to be the thing that you see on your metam mask when you sort of like go and sign something so it's super important for us to sort of have a shared language around it and for that shared language to be accurate um I'll be collaborating with a bunch of people in the space find me elsewhere and super happy to chat about it but yeah that's basically uh it thank you so much good stuff good stuff by Bob so we got a few questions if you want to ask more questions you can scan the QR send them up and they will um show up automatically um but the first question uh that'll come up slowly uh on the screen is to ask is that should cross-chain intents more explicitly include execution of arbitrary call data on the receiving chain on the level of the ERC spec I think like highly debatable um and we should sort of like debate about it um I think this as a use case generally makes sense um I would I would be in favor but I think there are Arguments for not doing it as well so I don't have a super strong opinion okay next question can we ever move away from the reputation based system for solvers fillers do a cross socket Etc currently actually slash their fillers or punish them I think the cool thing about this stuff is that it's quite different from all the consensus based models that we have seen in inter before how INR used to work before was you would send money into a smart contract you would have a bunch of validators and those validators would be your truth Oracle in some sense and then they would give you funds on the destination so you would trust this consensus or the this like Valor set to give you funds on destination and that's when like slashing and staking all of that became important because if not they would run away with your funds but why this thing is cool why in why intents are cool is that you don't have to trust the validator set anymore and there is no need for like uh slashing or anything like that you you send your funds they will either get fulfilled in the next two hours or you'll simply get your funds back and this is assured by smart contracts onchain so it's pretty pretty cool in that General sense okay so is it not possible to create the translation code for the different intent protocol languages I am I am bearish on it um I feel like standardization in this like intent world needs to happen like bottom up rather than top down because the application SP is like as wide as basically any smart contract ever built so I find it like super hard to sort of go top down when standardizing and talking about intents um I think my current best bet would be having some sort of like intent DSL like think evm but for building intents something like that sise at that generic level maybe that makes sense but I would I would honestly like go bottom up build like standardized escros build like standardized proof systems and sort of have these Legos available for developers to combine and build their intent protocols instead of having like a standardized intent and everything else below that is a blackbox all right one more question that just came in instead of the lockbox couldn't we have a user signature on the intent and an offchain mechanism that verifies that the intent output is in intact via that signature yeah I think the purpose of logb Bo is like slightly different um purpose of logbox isn't to sort of like prove that uh you got exactly what you wanted on destination that's the job of the Oracle Oracle is your Truth uh finder in this sort of scenario uh I think Oracle is just to give Assurance to uh fillers and users that if funds enter this particular contract they will exit only in these two conditions and based on that you can sort of like uh simulate stuff and have a guarantee that if funds are entering the this contract this contract is not poisonous and you can interact with it pretty much like how you do with erc20 is today uh even with erc20 is you can have like weird poisonous ec2s um rc20 is that charge fees on transfers but because we can do simulations on it you know that you know like if you send 100 usdc your balance is decreasing by 100 and someone else's balance is increasing by 100 so you can see like there's nothing poisonous there I think if you have something like an escrow there you can Sim and see that hey funds are reaching my escrow with the right key so no matter what is happening with the settlement or with the with the settler contract I don't have to be worried that it's poisonous or something like that okay probably the last question just popped up if solvers take the risk of finality how can we get high security in insurances with cross chain transfers priced at a few cents is it sustainable super solid question I think it is not sustainable able if you don't have a lot of fillers that's why we need a ton of fillers if you have more fillers we have more competition then I am quite bullish that we'll have uh people with capital fighting for pennies and our our Crossing transfers can remain like fairly cheap cool