Time is all you need: optimizing Dutch auctions on Arbitrum | Devcon SEA

[Music] hi everyone my name is Allan I'm a protocol engineer at Unis swap Labs hi I'm Brad I'm a research scientist at Unis swap labs and today we'll be talking about optimizing Dutch auctions on arbitrum when we think about swapping on chain we typically think about trading against amms but using amm and onchain liquidity isn't always the best for every single trade this is because of reasons like liquidity fragmentation and me we want to be able to expand the realm of accessible onchain liquidity while also opening the door for offchain liquidity a pattern that's used to achieve this is using intents where a swapper assigns an intent to swap token a to token B and they don't care where the token B comes from they just want to come in a reasonable amount of time and get a good price for it so thinking from this perspective it's a simple problem that swappers want two things good pricing and fast execution today there are systems that get us good pricing and fast execution like RFQ systems but they often run into problems around complexity and fairness they're also relatively difficult to analyze and execute so today we'll be talking about a simple approach which is using Dutch auctions on chain a Dutch auction is an auction where the price starts high and it gets lower and lower until the price is taken this is called a price Decay so the price starts high and it decays lower and lower until Market competition fills the order if you set the price too high then the auction will take a while to fill but if you set the starting price too low then you'll just get a bad price so we're left with a simple question how do we set this Dutch auction optimally and the answer is time time is all you need so as Alan mentioned when you hold an auction it takes some time for your auction to get filled we can call this wait time we can actually design a system that depends on mainly this output metric weight time to give the user the best price possible so in other words we can avoid the problems of complexity fairness and difficult ulty to evaluate without compromising on execution quality for the user so to test this idea we made a simulation and this simulation depends on market prices amm prices um takes into account price impact to create reference prices and then we run multiple Dutch auctions across this price background on your bottom left corner you'll see um two output metrics fill rate and weight time and we tell this algorithm to aim for a weight time of 4 seconds on the right hand bottom right hand side you'll see the parameters of the Dutch auction tuning to try and achieve this weight time of 4 seconds and in particular in the bottom right um chart the xais is a parameter that can give you an approximate value of how much price Improvement you're getting and this value is Meaningful when it converges to roughly uh in this case 4 seconds so what I've shown you is that um oh and one thing is that the maximum price Improvement that I injected in the simulation was 25 basis points and as you can see it converges to this 25 basis points so I've shown you that I can only look at one simple metric and give the user um best price possible without com without um with the ability to evaluate what that price Improvement is so let me give you some intuition behind what's going on here so um the red dots here represent the auction prices changing with different parameterizations um your auction gets filled when the market price goes above the auction price when a user comes in to swap for example at block 10 um we can check the am price generate a reference price and use that to parameterize on our auction so what happens if you parameterize your auction too low if you start off too low you get fill instantly this is bad because it means you could have gotten a better price what happens if you parameterize the start of your auction too high you get filled much later this isn't necessarily bad but it makes your auction harder to evaluate so if you get filled within the first or second block or you know first couple blocks then um that period tells you that you parameterize your auction just right and you give the user you still give the user the best price possible so using this strategy we can compare it to other other strategies of um parameterizing Dodge auctions you can think about using sex prices if you use sex prices then you run into the problem of fairness um sorry you you guarantee fairness but you can't parameterize every token if you use RFQ you kind of compromise on fness but you can parameterize every token in all cases you compromise on ability to evaluate uh our strategy satisfies all these criteria so this is just the beginning we're testing this out in arbitrum and but this can work on any Dutch block based blockchainbased Dutch auction and we think this is a step towards testing out non-linear auctions in the future thank you [Applause] thank you guys so do we have any questions over here sorry shorts all right thanks so what does time boost do to your design so in time boost you pay extra to come in first right yes but imagine so we ignore that factor but there is one player who has this 200 millisecond Advantage uh I think the user gets better price I don't um that user that user yeah thanks no it's it's the the what's important is the filler it's a open market on the Dutch auction so it doesn't really matter and yeah don't think I understand it's open anyone can fill so yes but one party has time Advantage like so you're saying if the filler has time Advantage yeah let's say filler or the other um you yeah so if the filler has um first move in that block then um in that particular block where the price decays to where the true market price is where they would want to fill then yes they would be able to snatch that before other people we have one question right here hi so if I understood correctly it's you're running this auction for each token simultaneously or just one at a time so whenever a user um makes an intent to make a trade that trade itself is a single auction that's going to run on chain for people to fill but if there are multiple auctions running parall there is a lot of Arbitrage opportunity because the prices may not agree um each auction for each trade is unique right they have their own unique parameters they have um outputs that the users are expecting so they are distinct so let's say if if if there is a exchange between usdc and E going on um that's priced at 300 and there's somewhere else uh the opposite trade is happening at uh 1X 400 like there is a Arbitrage opportunity across these two places if somebody can submit two bids and profit yeah so um if the person who's filling that auction there would be an expectation if they're behaving rationally that they must have um sourced the liquidity somewhere else to in order to fulfill that chain on fulfill that trade on chain I think you're I think I put in an assumption in the simulation that you're probably saying it's not necessarily the market price that determines the fill um and what determines the fill is if some uh whoever is willing to give the best price and that's all we care about the best price we can capture for the user whoever decides to fill it so not necessarily at the market price we have one last question over here hi uh how do you account for the liquidity when you're doing the the testing since if you if you only test with like a small amount in your trade and it gets built quickly but then when you adjust it and you want to trade you want to swap more then you're going to get hit by equity you're going to get hit uhan you're like the change yeah the price um I think what I showed you is a simple version where the price impact is you take orders roughly the same size and you run this algorithm um you can either choose the bucket by trade size and run this algorithm or have a smarter algorithm I didn't really talk too much about how the algorithm was working just the intuition behind it okay well thank you very much um thank you Alan Brad please give them a nice round of [Applause] applause and now we're going to have the uh uh last uh talk for the cryptoeconomics track today uh so we're welcoming back the for his second um Talk of the day um and he going to talk about list uh inclusion list inevitable trade-offs please welcome back back down hello hi I'm back thank you and yeah so um this one is more again on inclusion this and it's more on the engineering side that as someone that has been um focusing on inclusion this over the last year and I also um started looking at fossil more and more and this is where my perspective in terms of engineering challenge with regards to inclusion this so today where we are right so today we have ethereum slot and each slot is 12 seconds and what are the constraint within the slot so as a proposer I want to propose a block and I will hate to have my block gets reorg and that's not nice so I want to propose uh my block on the strongest head that's possible right and after I propose a block everyone else on the network that's running a note will verify the block and compute what is the head and as a tester their job is to attest to the head of the block so this is where the four Choice follows if you use lmd ghost and then as a aggregator as optional you Aggregate attestations and then the proposer essentially follows the votes for the next slot and then it builds on top of the head right and then because of timing game you can see there is a phenomenon that today the attested cut up is at 4 seconds so basically everything is p push towards the 4 second Mark and that's kind of the equilibrium right now that everything happens between 3 to 4 seconds and then between four to 12 seconds of nothing typically happens unless you are the net slot proposer your desing transactions and your building block so where does inclusion this fit in into this picture so here I'm speaking in terms of fossil so fossil is um a EIP um 7805 I believe but go search it if you don't know what fossil is so fossil is probably the best inclusion this design that I have seen so far that is mostly bully proof in my opinion and then it has the same slot property and then so what fil does essentially is that it essentially allows a secondary runs of proposal that are allowed to send their local block and then such that it Con strain the next slot proposal essentially so what does that leave us in the picture right so because of that we have to essentially add this proposal in the middle of the 12 slots that means that as a proposer for the inclusion this I have to essentially verify the block beforehand such that I want to essentially propose the best inclusion this effort right and then and then as a constraint the next slw Builder or the proposer I have to essentially pack the inclusion this into the block and then if I Mis inclusion this then I may miss my block and uh and also as a tester I want to make sure that the block satisfi the inclusion this so there are three more constraints as a builder as a proposer as an tester which I cover here so where are some parameters that we can play in terms of tradeoff so for example how big is the size of of how big is is the size of an inclusion this right if the inclusion this size is so small that it may not be useful but the in this size is too big then you open up Network for do concern what is the size of the inclusion this a committee because we want committee size to be reasonable but then but then if the size is too big again you open up Network do concern and then how much overlapping are there within the inclusion this and then what is the satisfactory rule right so as a proposal for the next slot as a tester I'm verifying the block like what like basically like how much of the inclusion this the proposal has to satisfy for the block block to be validated so what are the concerns so first concern I think is the increase of bandwidth and computer for node like depends on how Bigg inclusion this size is and then then again the second concern is that proposer like how much time do I have to build a Blog and then as a tester how much time do I have to verify the block so here are some open questions for us to study if we're in interested in this inclusion space like how compatible it this with the future road map such as P does such as such as epbs how does inclusion this work with account abstraction and then like how can we add blob transactions into the inclusion this such that it doesn't open up those concerns and then how can we better utilize local manoo for inclusion this maybe we can just essentially send the transaction hash instead of sending the full transactions finally like will there be a aop prodal market for inclusion this and it's something that's we need to study more so yeah if you're interested to contribute definitely hit up Julian and then hit up me and then yeah definitely I'm I'm definitely very excited about this inclusion this design space thank you thank you so now we have time for a few Q&A please raise your hand if you have any question okay okay no questions okay it seems oh there's a question here um yeah super interesting I had a question so I don't know if you can answer this but um in any capacity are you thinking about doing fossil or inclusion list for l2s like arbitrum or yeah and how does that different from what's in the EIP and what could be on right so Layer Two today is most of the layer two or all of the layer two today they have just one sequencer right so the sequencer definitely have a lot of power say today if you want to force your transactions in there like if sequencer ignores you there's nothing you can do but then there's a lot of people say well you can force transaction through layer one but that's also not nice because you have to wait like 24 hours right but then like again I think like decentralized sequencer can of sset if you assume honest majority so I would say the space in terms of sensorship resistance on Layer Two is is definitely very different on layer one because on Layer Two you can essentially having like one million validators you could just have like 10 sequencers and then trust like on this majority and then as long as you assume some of them are honest and they were they like basically basically they have to include your transactions any other question okay well thank you very much for your talk uh please give some Applause to Terence