Securing DeFi Protocols

Transcript

hello hello everyone um we'll be waiting for some more people to join in um but thanks for those uh in time um basically we have mun from PowerUp today and uh from moreful Labs um so we'll be talking about securing D5 protocols um I'll very quickly introduce a um DSS which is a def security Summit uh we have some exciting news for that um I'll

be very quick but basically we will and we're very excited to announce that the DSs the defi security Summit will happen right before Devcon in Bangkok so that's a very exciting news on our side um and yeah last year it happened in that was the second edition last year in Paris um we did it at laimi right before and two years ago around the Stan Stanford blockchain conference um so yes this year around Devcon um it will be about the same format and we're very excited for this Edition to come um without further ado I will introduce Merlin as

our first Speaker he's a co-founder at morol Labs um they just released their new protocol blue that he will talk about and he will talk about security measures that they took and much more so I will give him um the mic and uh feel free to ask your questions in the chat and we'll take five minutes at the end of his talk to to go through them thank you very much Mel the floor is yours all right hi everyone um so as Nathan say I'm Merin one of the co-founder of mof labs uh we've built first the the mof optimizers uh that are

like a kind of Landing protocols built on top of a landing pools such as aan compound uh so there's close to to two billions uh of dollars um deposited on those those protocols so which make them the the third uh biggest Landing protocol on eperium and uh recently we deployed the M blue uh protocol that is totally independent so not built on top of over Landing pools uh so and it's uh we wanted it as like kind of a landing primitive and um so I guess I I share my screen and and give a few slides but uh when it comes to uh creating a primitive uh you need to

take drastic measures uh to make sure that everything is like is perfect and there's no bug in the code because like you you want to to have like people that are that you're sure that when they they are building on top of your protocal uh everything is safe so I share my screen uh do not hesitate to to ask questions I'm not sure I'd be able to to see them so maybe I don't know or um you can tell me like yeah we'll pull them there to do so um what I'll show you today is like um what security framework uh we use uh for mle blue and maybe I can say

also what are the the difference like uh compared to what we use uh when building M optimizers so as I say like we build the mor optimizers um I I think it the first one was deployed like two years and a half ago uh on the first one was Mor compound so Mor Optimizer build on on top of compound and uh during those two years uh that was super exciting but we realized a few things is like uh in fact when you um you build very close to other protocols um

you are exposed to all the things uh all the features all the Covenant decisions that are made on those IND those underlying protocols and uh what we realize is like in fact um a and compound were like very very large code base like a few thousand LS of codes so I think it's like 5 5,000 for compound and like 7,000 for a and uh because there are like very large Cod bases like uh sometimes there are a few bugs or um or like sometimes it the the protocol needs to be posed because there's kind

of a rounding somewhere uh so it needs to be upgraded uh the flash lone as system as a problem uh same thing um and there are also many features uh like s rate uh emote Etc within the same infrastructure and so which leads to frequent bugs in production and um what what happens like some some weekends or at some moment like uh the the a or compound operator will pose the the the the protocol and we need uh because we are buil on top uh we need to do the

same like pose uh to mirror what the underling pool is doing and this is um like it drain it drains energy it like uh it it un focuses your team from like building because like you need to monitor everything and in fact uh you uh we ended up like realizing that uh the current defy Protocols are are not trustless like it's like the whole defi values are about like a censorship resistance like systems Etc but in practice like there always like some operator that can like post things Etc

upgrades and and also there are like a kind of like a more risky system that um what they appear like you think like um the uh user experience when you come to Def protocol inur like very passive you deposit your uh tokens and it generates uh yeld and and you don't need to to do anything but in the background in fact you have some Risk Managers that are managing the whole thing and like deciding um like some race parameters but it's like a a one side fit all so even if they like you may be a de or like um a good Father's family um and

you have so you can have like very different risk profiles but you're still exposed to the same uh risk measures and uh as a pure for instance as a pure usdc lender uh you Expos to all the risky asset that are listed on the poll and so uh we realized that during those two several years building on top of those protocols and we ended up like conceptualizing secure protocol requirements based on like those drawbacks that we've noticed uh and witnessed in the uh current protocol so what we ended up like thinking about is like uh protocols uh when it comes to

create a primitive uh so kind of a base layer on which you want um everyone to build on top and is like fully trustless and they uh Builders don't need to worry about like whether they will shut down this feature or upgrade or whatever um you need you drastically need to uh decrease the attack surface and each time you add a feature or like a offensive thing like you just increase uh that attack surface so um whenever you you as a prodal builder designer whatever uh one one important question

is like um if I if I don't include that feature will user uh not use my protocol and if the the answer is like no they they'll still come and and use that protocol so uh a good thing is just to remove that feature because like you just uh if you keep it you're just increasing the overall complexity of your protocol and you might end up like just being hacked uh which is one one of the like starting a startup is very hard uh in the uh General word but in defi you also can get hacked and pretty fast so you're just increasing increasing

your likelihood to to to get wrecked and um which comes down to minimalism in fact and uh in our point of view atmo is like um a protocol uh can only be minimalistic and it cannot have like fancy feature and and and like a Overkill things um yeah so that's it so during so here we are still in the pral phase so we didn't write any code Etc so we are just like thinking about what what we want to to to have in in the protocol what are the thing that we

want to fix uh what what are the problem we want to solve and also before writing a single line of code like of course you have the partical design but during that prodal design like one thing that is important to do is like sometimes um you can see like um sometimes our people are referring to Fright modeling where like uh the the goal is like to raise what are the different threats uh what are the different stakeholders in the in in that protocol uh so I don't know like um on the lending protocol you have like borers lenders Risk Managers uh but you also have like strategies and the the

markets the orles that that can update prices Etc so you have multiple stakeholders uh that can affect all the lending particle behaves and fright modeling is like is about like uh just identifying first uh those all those stakeholders and like how can they affect uh your protocol and then raising concern before they Happ like how um here are the list of like if the the orle is broken like how can it affect my protocol and what are the steps um that or measures measures that can take to make the protocol um safer and like more

Rob robust and resilient compared to to that stakeholder and you can do that for all the stakeholders and uh we are not doing that very formally uh within M Labs but what we created instead this kind of culture where um any concern can be um so I'm I'm very uh speaking about like how how M Labs is working internally um so yeah let me come back so we have like kind of culture of debates so uh and open criticism so everyone can say like oh I think here

we're doing a mistake or I don't like this feature or I don't like like the design Choice uh choice that we we did and even like in turn uh in turn within the company can can can say that and it's like very open um and uh we try to keep that because uh then like everyone can bring their own point of view is like you can bet on like um I say like the intelligence of the collective to to end up and um and go toward like more Mindful and better decisions and yeah on the short term you think like a you losing time because

like maybe just one or two person could take the decisions and like you'd be way way faster and like that's true but you could be way faster but in in the wrong Direction like just going going straight to into a wall and uh that's not the thing that you you want to do but on the long term if you take even like the lifespan of the protocol which can like Take Years Etc uh you're just like saving a lot of of time because like U you'll make like a much more much better decision uh very early in the design process if you have like an open culture and and like everyone can can debate and we we yeah spending a lot of time like

debating like even even like tiny things and naming naming things is like small details then in fact after this um so let's say you have like designed your protocol um debated a lot uh now you you have the all the requirements you know where you're going uh then uh you enter the build and and test phase where you'll just write write the first line of lines of code and try to test the whole thing so uh of course like maybe like uh everyone know about it but I think it's is good to emphasize like that very

basic so um uh the first thing is like write a lot of unit and integration test uh so that that can be done on in parallel of the uh uh development of the the protocol why I think it's better to to do it in parallel and not like write the protocol and for and then try to test it it's like sometimes you realize like some design choices that you made in the the early process like during the pable phase in fact they are they don't hold that you made a mistake or like you realize that there are new issues that you didn't uh uh didn't think about so

like testing in par of building like will really raise bu issues very early in the process and I think it accelerates uh overall um the the different iterations um I think like um um yeah for integration test so just as a reminder uh I don't know like perhaps like everyone knows but you unit test is like a you test like a very small component like how single function phaves and um while integration test is like more testing uh a combination of like different uh different functions or

like the interaction of your contract with another contract um both are very important like um and uh and the integration test like I recommend if like if you want to deploy on the on on a network to to try it in in a fork um and not just like mock everything why because like sometimes you will end up like finding these small edge cases like I don't know for instance us has no Boolean return value um which is like the opposite of like the esc20 standard or it's opposite I don't remember exactly but if you do

uh some transfer in a fork then you see that if you try to um transfer usdt to reverse and if you don't do it like ever you you don't you already have this knowledge uh which I think it's an important knowledge as a security researcher but um um it's okay it's well known for us but you may may have over edge cases like if you integrate I don't know balancer or any other protocol so I really recommend like uh trying um doing integration test in for uh I did I didn't mention it but um one thing that is important is like

checking the coverage of your of your code uh I know that coverage is not like it does not mean uh it's not because like you have 100% of test coverage on your code that uh you're done like your job is done like you you won't have bugs in prod but I think it's like a still a good thing to make sure that you you are exploring all the benches um and one way to to do it is like with Foundry you have a uh you have Forge coverage which is nice uh you can create reports of that uh and identify like what are the misses missing branches um and also yeah there are like some

tools uh vertical RS and Gambit that are tools mutation tools and mutation tools is like a new thing that we tried this year uh for M do especially we did use it for uh optimizers but um this is cool tool because what they do is like they try modifying the code and running the running your testing suit uh Suite on that and if the the the mutations of the code pass the test while like they're literally changing is the behavior of your code and the test test pass it means that you're uh obviously missing a

test and this uh can like spot some whole in your testing suite and I think it's very cool uh there are some development uh around that and I really want to to have like some advancement to see some advancement this year on that that kind of tool uh of course you need to to you should use the uh you should F your test uh so sometimes it's like usess but um it's very good and and I mean it's very easy to set up especially with found so there's no excuse not to do it um yeah it's very important you'll spot plenty of BS with with that but um I go

fast on that uh internally what we have is like uh we have we have two teams in fact we have the protocol team that is like more focused on like designing the protocol writing the protocol um and testing also but and we have the integration team uh so now I'm leading this integration team that is more Focus about on supporting uh integrators and what we are doing is like we are conducting Security reviews for those integrators but also uh we are doing uh reviews for uh the protocol and it and sometimes we're writing contract and but the general rule is

like if one team is coding the other team is reviewing the the code and uh and uh and vice versa so that we always have like internally uh fresh eyes uh that can like criticize and review the code it's like kind of a red team blue team uh within mors and uh this has proven to be quite powerful to to find bugs and like um yeah and debates around design ches and um one one other rule is like everyone should review all uh the code that we deployed uh so that like

there's no single point of failure uh there's not uh no not a single person that has all the knowledge like every single Engineers uh that do like uh um solidity Engineers within the company should be aware of the the whole code base that have been deployed and this is very important like because over the year you can like people that are uh leaving the place or coming in and you don't want to to end up in a situation where you have like I don't know a bug and PR problem or something to update and the person that had uh had hold the knowledge is not is gone and is not there anymore so this is important to to

to have also um during the the build phase uh once uh the code is spretty um spretty down actually uh we we call advisors or VC uh researchers uh for peer review so which has a new layer of like security reviewer solidity Engineers looking at the the code that will challenge the the the design the code Etc it's very important to have the more eyes the better for you could uh obiously and then um about invariance and formal verification so uh EnV

variants are like um are quite easy to um to set up using uh using pundry uh it's quite it's very fast fast to to to implement so if you have like some invariance and like mathematical things like that should hold uh during the the whole lifespan of the the protocol then uh you should like just write some funding variance uh something that is more powerful is like um uh like use like a formal verification Point instance using C uh it takes a lot of time uh though so maybe with invance

you'll catch most of the bugs and uh that are related to inv vience uh but uh Satur like much more powerful fortunately in internally we have someone that has a PHD informal verification so he's doing like the whole thing um and also working with the ca team to do formal verification on M blue and and over uh contract that we ship it's a L Workshop because like obviously there like there can be an infinite number of envir so uh even after deployment uh we are still continuing working on the formal

verification aspect of the the protocol and continuing to to prove some some invariance um that's it for that part and then uh after when we have written all the all the code uh that we've secured it uh we have written a lot of test Etc what we do is like because it's like the protocol will be uh is like every year a year and a half even two years it's like a it's quite a particular event so what we do is like a before going into the audit process Etc what we do is like a

big boot camp with the whole team um and what we do is like we G gather everyone um just to to share uh a moment where it's not like a Cher moment we'll just like try hard we make make sure that everyone that's the the the protocol vision is ready for the launch uh but also like um the engine Engineers all the engineers will try to to break the code it's like U we we go in a remote place and we try like oh can I attack the code what what can I do and and try to yeah we try to to go into hacker mindset and and break things so

it's one of the most uh like one the best moment of the year then um so we've built the protocol now uh we are entering the predeployment um sorry predeployment phase so during the pre predeployment phase we've started with like a tier one um Security reviews um one from open zpp and one from spit spit um we yeah I'm a huge advocate of like SP team we've work a lot with them and it's like they have a pretty pretty good team um and the goal of those

securitys is like to have uh external security researchers looking at the code um to find like the major flaws in the code base also to receive some uh feedbacks on the the design choices U and and yeah um usually the security review should be long enough to give some uh to give time for security researchers to to look uh really deep into the code base and like to to make sure that they understand everything um the the the best what I would Advocate is like to do the security reviews uh sequentially so that

uh you do the first audit you uh you fix it and then after uh you do the second AIT uh sometimes uh sometimes you can't because you just just don't have the time or like a timelines that does not fit in a bur Market uh you'll see it's like way easier to like schedule one an AIT but when it's a bull market like everyone wants to deploy their new protocol is super crowded like price as super expensive and it it's very hard to uh to find a place uh after that um we did a contest

with canina um we put like a 200k at stake uh it was like um so I don't know if you know canina but basically it's like it's um I say C4 Cina competitor uh or Sherlock or whatever like they are all competing in the same space like like um security contest and uh this is very powerful because like how I see that is like it's kind of a giant human fer like where you have many people like trying to break your code it's like very efficient uh but usually it's like on a much shorter like um span and like it's a matter of it's like shorter than like

Standard Security reviews so sometimes like people won't uh spend as much time like as security researchers in like standard audit companies so it's kind of a different game so I think it's important to have like both and not just do one AIT and one contest but you but it's important to do both obviously uh it's it's something that you can do if you have enough money uh the limit uh for Securities uh security uh for you when you're building protocols like uh money and and time uh the larger part the more you

incentiv like the best uh to come and look at your code that's obious but um uh but so yeah try to have like a high high Po and also like to find a slot where there's not so many contests so that like it's not so crowded and and I hope like you you won't end up like doing your competition doing I don't know I I think like th s offer like a 1.1 million at stake in like a recently um blast of like 1.2 million the obvious is like if if you don't uh you put like 200k when there are those kind of competition like you may not have the

best looking at your code but it depends also during the competition and like um uh audit what we're doing is like uh thinking about the incident rment PL so incident respon plans is like uh it's kind of a Playbook a recite uh that you should follow uh when something bad happens like um and I think it's nent did like a super uh super good playbook that you can take inspiration from uh this is where also you can leverage uh what you did during the Fright modeling uh uh your fright modeling sessions it should be super

simple and efficient like you should not like think too much about what you're doing because like you're just running Against Time and what you you need to do is like I don't know pose your contract or like reach out uh every stakeholders I don't know Risk Managers or users um you want also maybe to contact authorities uh for instance like on our side like we we have direct contact with security researchers with Channel ises um so that like if something bad happen we can jump into a d dedicated Channel and like trigger all the authorities in the world or whatever so that they I don't know like usdc could be frozen on

on bance and so the guy they If he if he wants to exit like he can be blocked Etc and you can prepare a war room for for that in advance um I I don't know about the time so I don't know yeah yeah we we have five more minutes left a yeah I think it's it's good um and then after we did like a pre deployment back bount here with ad Finance um so it's like when you did all your Security reviews uh all your um all your competitions or whatever the code is frozen but it might

not be deployed yet because like I don't know your interface is not live yet or like there there are always things like that just push forward your uh releas state so what we do is like we put at stake some money is kind of a b Bounty but the code is not live yet so that you can incentiv you can still incentivize people to report some bugs before uh before you deploy um for instance like M blue is a immutable contract um you can't upgrade it so uh it would be very annoying like if someone uh find a bug just after the deployment when you did

like the whole launch and and and release uh and release so I think this is something that is it's at least um an added layer of security then um you've deployed congrats and you have like the the two two things uh to the most uh two sorry the most uh two most important things to do is like a monitor your contract um so imagine you have all your envir so this is very important like uh for instance to set up uh buts that are like running some invariant check and

you can do it like one that each transaction that uh that are sent to your contract just to make sure that this transaction has not broken any enires and and uh that can be quite easy to set up and this is something that you should do also uh what you can do is like at the very beginning you can even log like every transaction then just like to understand like what's the user Behavior Etc and after you can like create some spec specific um um specific sorry um monitoring where like oh it the transaction is like uh using more than 10 million or 100

million dollars like just rate the event uh you have also a bunch of Solutions in the in the space to have like some things like that are fully automated uh like fora um Defender Etc so that you can use and and set up on your side uh there are many things that we do internally because we really uh understand how well uh the the pro protocol behaves and so we really want to have also specific monitoring for specific things um and for more for Blue uh there's no it's governance minimized and imal so there's no secret barrier we we

can't pose anything so the only thing that we can do is like monitoring very closely and have like um very fast in incident treatment plant where we can like one users and risk rators uh that there's a problem if any and then um so uh put to bug Bounty so for now uh our predeployment bug Bounty is still alive uh we announc like uh the bug Bounty for for mff Blue uh the 500k B Bounty sorry for M blue in the in um in a matter of weeks I think uh there's on uh already one for Mo

optimizers it's very important to have that have one it has been useful for us for the optimizers um and uh and I I yeah I don't think it's possible to to add like a live protocol without the back bound it to be Hest like it's just like you just calling hackers to to hack your protocol um and uh and yeah you you should definitely do that and um also one thing that you can do uh is just like stay in in sync with what what's happening in the space like what are the new security measures Etc like there are a lot of thing happening like

new hack that are um the type of hack that are discovered Etc and so sometimes like um like a protocol or a kid base that was safe it's just like people realize like oh but in fact it's exposed to the same bug as this new uh rounding uh based attack and so you should like continuously learn about like new hacks Etc on our side like for instance we we have done something like every week or two week what we do is like a hack school where one engineer is just picking one one hack in the past and like it is just trying to explain it and

like uh uh really deeply understand like why this ha happened and how and and also like understand like and make sure that muff contract are not exposed to to to those kind of um attacks so I think it was like yeah I have the recap but uh so you have those four phases uh a bunch of things like you can do you have that image of like um I should should have uh put that but uh this image of like the the uh swiss cheese security layers where the whole um swiss cheese layers has um has whole but if you combine them and put them

together um at some point like it's like nearly impossible to to um to hack and and find the vulnerabilities of course like you can always find things but the more um lers you had uh the better for for your protocol and your users yeah questions I don't I don't see the chat so maybe thank you uh thank you for that that was uh really awesome yeah I'm uh sorry for for the late join here I'm I'm going to be moderating uh I'm uh

yeah I'm Elliot okay so the QA um so for testing would you rather use fors or any test net I imagine uh forking main gives you the latest vers dependencies or external Partners but appreciate having your input um yeah yeah to me like uh forking like um to to be honest like forking is really the the way to go so I think like at the beginning you can you can um use like a a local fork or whatever but I think like forking Manet is very important because like as um I said it during the um presentation is like I

think this is the best way you can discover some edge cases and it happens like uh not all standard or um um I'm met like okay there are some V that are es 4626 compliant but sometimes like you realize that they are complian and that sometimes like you have like something that are different and if you just um like you're just testing like your dream environment uh in practice uh it's not like that the real life is like uh is not nice and and you will yeah I definitely recommend to choose

four yeah I guess another question um is what are the biggest security Lessons Learned From building optimizers that you've applied on Blue yeah I think it's like the first thing that I mentioned is like about minimalism is just like if you really want to create uh A Primitive a protocol that is Stressless and that is supposed to like um be kind of the Internet Protocol it should be very simple it should have like the very strict minimum it should do one single thing but do it perfectly and and if you like adding many features like as I say you you're

just increasing the attack surface and like the likelihood that You' be hacked and what we saw is like your very large Cod basas are all had at some point one issue and I had been upgraded or whatever but uh they whole whole had issues so I think M blue to be honest like we have like between 600 7 700 lines of code compared to like a few thousands and we really worked a lot to minimize the amount of of lines lines of cod and it was like a yeah really important so minimalism if I just uh I

would keep one word yeah I think that's really important and when uh the code base was announced I took a look through it and I was uh yeah I was quite impressed with how few lines of code and how simple the architecture was um and I think that's yeah I think that's something you see a lot from Top teams is you want to reduce the amount of branches and the amount of States your contract can be in and you talked about ination testing with Foundry right if you test uh you want to test all the branches but actually even if you do like integration testing you know you may not even test all the states your system could possibly be in yeah yeah as you uh increase your complexity

so yeah okay so um we have another question here they want to know if you employ any uh penetration testing tools to simulate past hacking incidents on your um decentralized application um so we uh we are trying to um so in general is like a um scenarios that we identified during like writing uh code like I don't know uh during the preal phase like we realized oh we can apply that kind of hack or something that and then we'll write this attack and and make sure that it does not pass anymore

uh but we are not like um trying to uh pick one um uh say like I don't know cream Finance hack and trying to um to like pick that that uh that attack and use it on our protocol but we'll try to get some inspiration it's like u i talk about the hack school Etc and um this is where we try to find some inspiration because after in general what we debate and we we ask questions like oh okay could we apply that on our contract so obviously we do it when when hacks

happen but sometimes you forget and or you don't spend enough time so here's like a place where we can like we take and just thinking about like to what extent it can affect M yeah I think that yeah it's great to learn from the past mistakes so you don't uh you don't repeat them for sure um they're very expensive um so uh the next question is uh you mentioned you do invariant screening on transactions are you doing that um in real time while transactions are in the me pool or after a transaction has been no it's after after the the transaction has been processed so it's not like a proactive

detection um and um and so I think like first uh um like not like hacker sometimes also don't go to the say the public main pole so uh it's not obvious that we we would catch up anyway all the transactions but we have like a a for talk about FL but there hyper native in those tools and like they are kind of specializ and like threed detection Etc uh that are like more General Tool uh sometimes applying AI or not um but uh but for like invent testing is like after the

transaction awesome yeah well Merlin thank you for um coming up here and sharing your insights I think that you know a lot of a lot of teams could learn different parts of what you know and take certain parts away and apply that to their you know development life cycle I think that you know there's a lot of great things around having a cultural rigor doing as much testing as possible getting a lot of code reviews um lots of tests formal verification yeah one thing is like the content like that I said I think will release um an article on that that is summing up everything um and one thing is like I think it will help people like

um just like wab the builders to uh like to to have a clearer mind on like how to set up a good security framework but also like uh receiving feedback from like security researchers on like how can we uh improve things it's like just opening the debate um so I don't know when we'll we'll release that article but uh I I guess we can I share on the DSs telegram chat or and yeah I think it could be a cool starting point yeah please keep us posted and um yeah Marlin thank you so much for your time um thanks elot and thanks thanks

naan as well okay I don't know where to switch like maybe you shut me down and I'll do it thank you next um I want to introduce uh Monir from parisal he is the uh founder and CEO and uh manir the floor is all yours yeah thanks do you hear me well loud and clear okay perfect perfect let me share my screen I'll start with that uh my screen is

visible um it is loading I think I'm just seeing a black screen same on side ah okay one second let me check yeah I can just upload the slide very quickly just a second download PTX it was supposed to work but okay it's all

good there's definitely been a few technical hiccups in uh getting this set up so you're not alone okay loading okay how about no y perfect yes awesome okay perfect so hey guys uh thank you for for coming here uh I enjoyed the Marland talk it was really really great uh so I'm here to talk to you about um our experience with Paras

swap what we've learned around like four years and a half or more running Paras Swap and skny Paras Swap and also portugus uh the new intent protocol that we announced around two weeks ago and what are the opportunities and uh issues that we identified and what is our response our plans in order to to solve and to scale intent protocol protols so just very quickly about Paras swap uh so we are a ventralized exchange aggregator been running since late 2019 we process over $60 billion in volume and most of it come from came from uh third parties that use barop as a piece

of infrastructure or as a tool among their tool set in order to provide either the best uh trading experience for their users or maybe fulfill their own needs for trading or uh liquidity uh for their own purpose and uh I would like to spend some time talking about the architecture uh and some design choices at uh that we did in in Paras Swap and here it's a diagram that shows the user flow uh and also the two main components when using an aggregator in general not just Paras Swap and also some dexes that build routers like Unis Swap and Sushi

Swap and others that kind of use more or less similar architecture so you have the offchain components that you see on the on the top and the onchain components which are basically the smart contract for for trading so if you we started with the smart contracts um in our case in case of some some other taxes or aggregators we have two contracts one used for trading we call it Augustus in baros Swap and we have a second contract for approvals that gets the allowances for for the users and I would explain why we have this design choice and that's something that's going to be discontinued in the in the V6 it's because of I don't know how good you can see you can read but it's not very

important the most important is like how how this works uh we have a function called Simple swap in that's uh dates to the very first day that we launched the fire swap it allows for swapping tokens uh and we call it simple because it's swaps token without intermediary like you have like e to die it's going to use one or multiple exchanges uh to perform the swap without using in one or multiple intermediary tokens like a usdc or usdt thing is uh that simple swap as you can see on the right if you can see if you can read the code um it uses the uh external course like arbitrary course the big benefit is it allows to have a full offchain integration of txas so you

can take any Dex take the execution functions and Implement them on what we have is called Dex Tex s it's an open source library and uh the integration can go very fast so early days it allowed us to have Integrations that can take few hours to maybe one or two days uh the big downside is that we need to have two contract one for the allowance and one for the for the swap the reason is if you approve the same contract well for for the for the developers as you can see you can still uh pass arbitrary data that will have access to the allowances and uh well basically wipe out user user wallets and there are two major cases one is known and the other

one is less known the known one is an aggregator launched last year and the very very first day that they launched they went for a naive designed with one contracts in one only contract and they got hacked from day one I think they us just lost few few million dollars in the other case uh we found in 2019 in one of the competitors that they had the similar design and we were able to build the POC uh where we were literally able to wipe out the user wallets so that's okay but the point I'm trying to make is developer experience is very important because uh it's easy to make mistakes it can be from the Builders of the protocol like like ours where they may miss uh design a very critical design piece like

like this or also the integrators we found last year a developer that they didn't read the docs that we have a big warning that please don't approve Augustus you need to approve token transfer proxy but they just went ahead and approve Augustus and somebody was watching the blockchain and they took something like 80k from from them which is like quite significant um so I think this one of this is one of the motivations we decided in the V6 that should be coming in a few weeks to completely remove this design choice we found better ways uh to still have good gas competitiveness and uh speed of of delivery uh but yeah that was a big

lesson learned especially on the developer experience that was okay for us it allowed us to iterate quite fast but at the same time led into some issues uh especially on the integrators say as I said um but in general uh the architecture works like this it's a diamonds architecture where you have multiple routers so what we did that's a V5 design is uh each router has it own contracts and behind each router you have uh Dex Integrations what we call adapters and that's a design that's quite flexible that allow us to add new new new routers for for like I don't

know tomorrow we discover a new algorithm that we we can add quite easily uh and also one one example is balancer that we added last year and that turns out to be super gas efficient where it was added as a a router instead of as an adapter as you can can see here and that was quite beneficial for users and for for developers who integrate our our our text uh once also to spend some time on the offchain parts uh one on the performance and scalability and the other one also on security and what can go wrong with offchain Services especially especially uis um so the very first days uh we had a full onchain

Paras swop we had one smart contract that we called aelius in Augustus for for for swaps or Le I mean there were only four dexes at that time uh you can compute prices run the algorithm I mean there weren't that much liquidity pools anyway so it was more than enough and it was very fast and scalable nowadays we have hundreds of exchanges we have tens of thousands of liquidity pools uh so doing that on chain is just simply not possible at least it's going to be suboptimal so we end up with two choices either uh we'll build the Integrations we have Dex Le that I mentioned before that has like Integrations of the logic behind each Dex and representation

offchain representation of the state of each Tex um and uh or we uh use RPC calls uh like for instance take balancer and curve to compute a price well what you can do is like make a RPC call for a get price function and doing that is just simply not scalable that's why we built Dex lib which is like as I said uh rebuilding the state the whole state of chain so for in instance Computing a price of e to die it's not just an e to die computation it's e usdc usdt like a bunch of connectors where you need to compute the price in order to build some kind of a graph that will allow you as a

developer to find maybe a potentially best possible optimal price and doing that using RPC calls is just simply not scalable we know that's uh that's like it was a practice maybe few months ago like more than a year ago but nowadays as much as more more and more uh dexes and more innovation in the space it's just not possible so here with Dex lib we're able to have inmemory calls uh that are millisecond or sometimes submillisecond time to arrive into the most possible optimal price uh the rest of the time like the 100 or two 300 millisecond that is spend end to endend from the user and the back back and forth to the server uh is about

networking and not computation so that was something that was super super interesting and allowed us to scale we see this practice more and more happening in other in other places but yeah so running offchain offchain Services is cool uh we use some techniques that are very well understood for ages uh but a thing is in the web three web three variants or segments uh there are some things that are very specific and many things that can go wrong and the most known issues that we've seen so far is well users using uis and the giving allowances to the

wrong contract or trading with the wrong contracts there are things that we cannot do right if there is DNS hijacking but there's so much we can do because simply there is no more control obviously other best practices have to be adopted in order to avoid that problem in the first place but it's so much we can do but the things we can control at least uh in our side what we do is um hardore those addresses as much as we can uh obviously I'm not GNA talk about the best practices I think Baron had amazing talk about what are the best practices to implement in inside internally in order to avoid potential security issues uh but having admit admitting that this is the right right

practice in our side for instance for addresses for allowance and for the contract there are multiple checkpoints you have the API that has a hardc version uh you have the UI also that have another hardcoded version and they have to match if it doesn't match the UI Should Crash or like should not allow a trading to happen the same for the allowance there is the hardcoded versions address sorry that should be fixed that should be mutable but also it can be dynamic so you have three checkpoints to in order to make sure that the user cannot miss that address like at least the UI cannot miss that address in that s of practice we recommend everyone that will use our API or our like a tech to to adopt similar

practices but something else that look less like a security of a classical security issue but can lead to a huge fund loss and we've seen that a lot in the space is uh in trading in trading of course is a big price impact some people call it slippage in reality slippage is something that happens on chain post trade but price impact is I'm getting I'm selling something that's worth $11,000 and I'm receiving something that's worth $10 that's a huge huge slipage like more than 99% and sometimes what happens is you have apis like ours who you have a payload on the response that contains a USD amount of the from amount in two amounts but this API can

go wrong can have bux and it can lead to a UI that's blindly trusting that API to tell the user that hey this trade is fine just go ahead and trade and the user will be surprised to see a ler scan that they lost 80 90 50% I mean something that's quite substantial uh so what we recommend and at least what we've done on our side is you always uh independently on the user interface cross check or double check using an arbitrary Oracle can be a chain link Co or you name it that will double check the USD prices and compare it to whatever it received from from the API and also blocking trades when uh price impact is significant is is quite High

uh there are also various ways to compute price impacts there is the traditional Financial way uh which is taking the price of a small amount in comparing it to the amount that's received by the user for instance very simplest one is I'm sending something of 100 like 100 die so I will compare the price of one die uh versus 100 and see what is the impacts like is it a one or two or 3% it's hard to implement because there are lot of moving pieces and also API rate limits and all of those things so we take a very conservative approach of using a USD which is quite simple and it fulfills more or less the same objective and yeah and the rest is user experience that blocking trades at a

certain threshold displaying warnings things that have led to limiting mitigating those kind of issues that happen to us once and happen to other uh uis a lot of time and we see this still happening uh till till today uh in the space but we believe that those practices that we've learned uh were enabled us to never see any issue at least on our site for the last three years or more yeah so I think that's it for Paras swap um now going to talk about the intents and the work that we've been doing for the last few months that we started in around late summer of last year and and um so I guess many of you guys must have known how intents work

and what are intent basically um an intent is an expression uh of an intense uh for doing an action and delegating this action to a third party that will try to fulfill that action to the most optimal possible an example for trading like I want to trade a token a for b instead of using swap platform it can be Unis swap AR swap or anything else of me take going directly on the contract and swapping and fulfilling the the action and paying the gas I will put a third party or like delegate this to a third party in that third party its role is to provide me something that is better like a better price better execution better

execution in this context is especially me resistance uh and also great user experience like GES transactions and and all of those things example is swap you can be limit order optimization use cases now are popping up every now and then because it's simply something that's like a superior design compared to what we used to have before um and would like to talk more about what we we are yeah presentation I think is not showing quite well but anyways uh I'll do it already so the current wayway yeah sorry for the slides the load

didn't make it quite quite clear it looks much nicer in a in Google Slides but in general the way um intent protocol work today is they perfectly solve the user experience Problem by uh abstracting gas in making making the transactions uh M resistance um and the way they work you have a end user in intent API and a solvers what we call solvers some call them resolvers fillers F fillers there are many jargon in the space But at the end those are entities it can be individuals or market makers uh who have some skills or some liquidity and are able to compete to

provide the user the best possible price and they are the ones responsible for executing this trade and the way they will win the trade is through an auction that's run by a intermediary that's we call here an intent API and that intermediary is the one that will receive the intent from the user build like an offchain order book and forward or like create the auction for solvers and select the winner problem with that is that that entity well it's a centralize entity it can go down uh it can be biased towards who wins or who doesn't win uh it's not censorship resistance so it's fulfilling its needs to the Visa the end user the problem is

how this is defi or how defi is this or how scalable and decentralized is this we think that we can do much better so this is where um the design of portugus that we are working working on right now where we are introducing or replacing that centralized entity or that centralized API but what we call here DL decentralized layer we don't want to um give it a a characterization yet because there are various possibilities and we explored like the up chain up chain possibilities like Cosmos op you name it still looking into other possibilities but B the basic idea is that it's not up to an entity or a centralized entity or

a team to uh fulfill those user auctions the user incense and select who wins who doesn't win and be sensorship not be censorship resistance we want the opposite side of this is where the DL will play this key role but of course when you talk about DL if we suppose here that will be a an up chain up chain it means that there will be maybe a gas that has to be paid so the the Simplicity or the great user experience we introduced in the beginning we're going to remove it by introducing a new complex piece of architecture so this is where we thoughts of this new component called Rel layers that will make it look like as if nothing was changed like so

for a user they can still use a relayer that is an API a centralized API an OP chain API but the big difference here it will be that this API or this relay or this intent API is optional versus a a mandatory one where the user doesn't have any other recourse but to use that intent API so similar to like accessing ethereum uh today if you want to access the yes you can have a g and go to console and run your your RPC queries which is not something that normal users do um but what normal users do they will use a wallet which will use a Alchemy in sure you name it but it uses any of those Rel layers like it can use any any

any RPC provider it can fall back to another RPC provider there is not one RPC provider there are many and that's the idea and the philosophy behind the behind the relaters well very quickly uh also the way we like to build software that's also very cultural in in barop since the one is always going in and never trying to build everything from scratch from end to and always having an itation that simple swap that I showed in the beginning was a good example um so also being realistic and aligning with the user expectations so users we agree that they care more about what is it for them like the great

execution good user experience protection from MV all of this so this is where we built stages that's also inspired from ethereum optimism and code order to break down the deliveries into various phases so phase one will be a design that will be quite similar to the existing products uh and the end game will be to build in a fully decentralized uh layer that we call the DL for for now uh in order to deliver this fully decentralized trading experience can we call it intent today but yeah we would like to see it as this is the future of trading where uh everyone is self- Sovereign and there is no third party or entity

that can censor or can be biased or it can be just simply not decentralized yeah that's it for me thank you guys happy to answer any question sorry for the slides all good I think that's uh um yeah it was it it was tough getting things set up so um yeah and I think that there's definitely a lot of you know similarities between I feel like the philosophy that you and Morpho have in terms of like minimalism and user Centric design um yeah and making things as simple as possible I think that's a really important piece When developing

this kind of software um so we have a question from Andy he says um what security tools or mechanisms does Paras swap use today uh well we have the practice bet practice that yeah merland talked about few things that we haven't used like Sor I think we explored at some point U maybe it wasn't the best fit at that time also we don't have the same security profile like if you're holding user funds you have a much much bigger risk and you'd better also be very quite careful and maximizing on on the security on the security side also aggregators are quite simple and we try

also to oversimplify to make them even more simple and as we discussed before the higher the Simplicity the less the attack surface um the code that executes has like one entry point which is like the parameter for for for the the trading and you have a final check that checks if the user is received what it's supposed to so if I'm trading one e and I'm expecting 3K die doesn't matter what happen in between what matters is did I receive exactly 3K die if not I revert the trade and we get the guarantee that nothing is going to happen beside the guas that was that was traded so Simplicity is is important but yeah didn't want to bore you with like internal internal uh practices of review

internal review audits we also adopted recently with V6 um this sequential audit so we did the first audit of V6 was okay then we scheduled the second audit that's why we're taking extra time in order to we tested this model but it's funny to hear that yeah we're not the only one that went for this sequential a set of like making uh multiple Auditors in in competition awesome yeah and I think that in your talk you also addressed you know concerns around like yeah the slippage and uh yeah just allowances making sure that users aren't approving uh too much the protocol when they shouldn't be or making sure that uh the

arbitrary call data that the user is passing to these these contracts is uh you know is yeah doesn't doesn't allow any sort of U fund transfer that that shouldn't be happening um yeah I mean I would love to hear a little bit more about the uh the new system and like the the security you know practices you guys are taking there um we might have one more question yeah think I say question about relayer is a good place and or not not Nathan asked a question curious about the biggest security challenges in portus to bring or is there anything before I

don't see okay another a question came in here um how the white how is the white listing of dexes done in the aggregation do you choose to display Dex a and not Dex B um if this kind of white listing is done of course from so there are two kinds of white listing is this like for Integrations or for like adding support for a DEX or is it for like security um not Dex maybe this is for Price computation I guess yeah I think it's probably for like integration with the front end and yeah it's just like um uh you might be exposed to some risk uh when you're

uh roting uh user to a specific Tex and I I was curious like uh you say that you have internal check on your side like that you received the indeed receive the tokens so I guess like that should cover most of the the the problems uh but I was curious about like maybe uh it does not cover everything and uh you may want to uh to restrict um the uh the routing of tokens uh to some texit that you uh that are kind of legit and I was just wondering about that that there's kind of this kind of wh listing but um I don't think so

but um yeah I was just curious like I didn't dive into that much yeah that's correct because you always have a layer that will execute on the decks but always going to check the outputs and it's not going to rely on the outputs from the deex like say the deex has a function called swap you want rely on the output of swap we we will always check the balances and we don't check it Dex by deck we do it at the end of the trade because first of all it's not gas deficient second of all what you care about at the end is are we still fulfilling the expected amount of user and also sometimes swaps can be very complex like you go from token A to B to C to D so you care only about the D and it doesn't matter what happens in the

middle as long as it fits with what the user expects very C thank you yeah so we have the next question from Andy here is the relayer a good place to embed some additional Security checks on transactions there are some challenges yes that the Rel layers can solve besides simplifying user experience like for instance uh let's say we open the DL for everyone uh how do you prevent some span but those are still work in progress especially Game Theory uh challenges where for instance if the de is open uh it can get spam you can

protect that with with gas but you can protect that maybe with staking stacky staking slashing and those kind of mechanisms where the relays can have some skin in the game a relayer you can imagine what is a relayer like an API or like a DEX that want to be their own relayer and serve this to to their users so it will add this kind of security measures but also for the solvers uh where layers can spam spam that Network so maybe this is still something that's work in progress can protect from spamming there's no like risk that we have identified at Le so far of loss but it's a risk of locking of funds and making the system less Capital efficient for the the supply side which are the

the the the solvers in this case we have another question from uh Jean when considering the security activities including threat modeling waiting period for Audits and implementing audit recommendations within your development life cycle would you say um essentially he's asking what is the amount of time that is spent on the security portion of the software development life cycle I feel like it's for VX at least I feel like it's more than 50% because we take in extra time each time we will have a date we will always try to CH rechallenge the system and come up with

the edge cases so that's the moments we launch and we do that obviously mostly for smart contract like for UI if a button breaks or something like the user doesn't like it's not the end of the world but for smart contract yeah the risk is quite significant so for V6 I think we are more than 50 I don't know if we're that much as 80% but something like 50 60% of the time was spent only in testing it's still it's still work in progress I think that's a very good ratio um because Yeah the more the more time you spend I think the more Yeah the more more bugs you'll find um and obviously there's diminishing returns but uh yeah it's definitely great to see a a security focus and an emphasis on

that I think the frustration from Engineers when they're testing is not finding enough bugs uh which is the opposite side when when building it's funny to see the reaction also from Auditors when they don't find vulnerabilities it's funny to see the reactions but yeah it's good it's a good news if I put my entrepreneur hats it's great but uh yeah I think we're taking the right precautions and I believe this is now a common standard practice in in like most major project in the space yeah no and that's a that's a great problem to have you know like on one hand you could worry that the auditor didn't find the bug but on the other hand you know if you get you're having the top people come in and look at the

the code and they're saying it looks good you know that's a that's a that's a good sign so yeah awesome let me see if there's any other questions here um I think that is um all yeah thank you everyone so much for your time Monier thank you for uh sharing what you guys are up to and thank you Merlin for sharing what Moro has been up to um I am not sure exactly how want to end things here but yeah just want to thank everyone for coming out and feel free to uh follow everyone on on social media

and yeah follow along as these products go live yeah thanks cot thank n it was great and hopefully we meet you are you guys going to e Denver yes I'll be at Denver okay see you there all right thank you thank you everyone cheers thank you so much everyone that was amazing have a great rest of your day