Permissionless Governance with Institutional-Grade Security: The Gearbox Approach

Transcript

Because previously we have a value spend and trust crypto your money you are ready to loss and with institutional upgrades we are really now focusing on the way how to make a things safe how we can really achieve this institutional grade safety at the same time do not lose our decentralization so let's go can you show slides is oh perfect. So today we will talk about this permissionless governance. How we build and how we start from a Dow managed markets which were really very very hard to manage to fully

permissionless system and keep the same level of security. Before we go show wait for Yes. So just a brief uh remind what gearbox 6 we are building a lensing protocol which built on totally different way than other lensing protocols. In usual poolsbased lensing like hour or more for the first part of the system you lock your asset then it's lock on a smart contract and then you can borrow asset against it. Gearbox works differently. So you as a user could open a credit account and this is a smart contract wallet which could

really execute transaction on behalf of you. When the credit account is open, you deposit your money, you borrow some funds from the pool and then you can really send different transactions which could be executed on behalf of this smart contract wallet. How we achieve security quite straightforward because when you execute a transaction we provide some safe approvals then you really interact with third party protocol and after that we have a post execution hook which checks that you have enough collateral. So literally if you try to steal money if you try to do something against the policy such transaction is reverted. So we really

keep all time your credit account is consistent and of course it's a pretty brief explanation but why we are decided to go to permissionless model because we have pools we have a multiple collaterals we have a multiple uh assets in our system and still it's a pretty hard for DAO like in our to manage risk parameters and it was really high limitation for scale another part I totally support the idea of Italic that we can grow when we can really involve more players. So institutional players would not trust DAO uh DAO managed uh pools. They will decide to switch and manage themsel. So we found it's a kind

of straight motivation to do something new and switch the system from existing pools working on with around 400 million CVL into permissionless one without really forcible migration and there are a few of challenges. So what we really want to achieve the first part when you allow someone it permission way to manage your markets you have to solve a few issues. The first one you want to really limit somehow ways how market curators could rugg users. It's not only related to the way you want to set time lock etc. The biggest problem is how to find the way how curators could do this in a flexible way and at the same time

have enough power to really interact in emergency situation. There are a few examples why permissionless uh and what the issues were faced by permissionless adopters. There are a few issues with morpha and oiler when misconfiguration in price oracle ended up with huge losses because there are a lot of exploiters who could found that your collateral is overpriced and then you want to try the market uh as exit liquidity. So what we do and how we achieve this institution of great safety in a fully permissionless mode. We started from pointing out all possible edge cases. We really have a few months

of discussing how curators could and especially malicious curators could do some steps to build a honeypot for LPS for borrowers and then decide to steal money. We really also designed a full emergency tool set which really works well during this XUSD collapse and helping variant group to avoid 30 million loss. And you can see an example you have a multiple way of this emergency tool set. So in gearbox you can forbid token you can redistribute interest rates and ramping liquidation threshold as a part how you can worry avoid toxic ass toxic assets. The second step which is really crucial. We make a

clear separation about roles and scope. So in gearbox right now DAO is very limited and even if a DAO ving system will be fully uh hacked there is no direct way to end users and curators. We also add additional layer additional kind of uh committee which is called instance managers or instance owners who manage price fit white list to really eliminate all possible risk with risk uh with price fits configuration and all stuff related to users and their terms etc are now under the control of risk curators. No one can really change

anything and they could change markets which could affect some users only via time log. So we also decided to build a full onchain system which could connect all EVM chains. And to achieve this we introduced a new concept which is called crosschain uh multi-seek. So literally when DA make awards these words packed into a batches and then they could really replicate it on each connected chain. This crosschain multic is works as entry point have the same address on all networks. So literally all D decisions could be really distributed across multiple chains and executed there. So we limit decisions but we

create a robust mechanic how they could be delivered and executed on any chain. And what is also cool that all these batches for which DA watted is packed into batches and we use the similar idea like in normal blockchain. So it's connected by previous hash. So there is no way how someone could change the order of batches and really hug the system. And you can see this is a working interface. So right now it's a kind of historical way the technical multi. Now we have a six person voted to uh connect a few networks. It's Monat, Nibiru and Somia. And this is signed batches which then were really redistributed across

multiple chains. And we do that just to be ensured that these chains are configured properly. We just set a um address of rap token, native token, we set up address of gear token and the treasury which collect fees. So it's a very good way how we can achieve really flexibility and still take a control of things which could break the system. The second part and I really enjoy to present it. It's a quite unique and novel concept which is called bite code repository and the easiest way to explain it it's onchain GitHub for smart contracts. So what does it mean and how it work? So we decided to eliminate

fully all possible risk when developer machine could be hacked during deployment. And if you heard correctly the lighter presentation, the deployment process is the same level of significancy that you really do in your normal audit stage. So what we did, we built a and put all our bite code onchain. Literally we introduced the system that each contract has a different way how we can uh keep the type of the contract and version control to understand what this butcoid means and which part of the system it reproduce. So literally you can see a

small extract from our linear interest rate model. It have a two constants. The first one is version and then a contract type. And it has a very good typing system implemented on the smart contract level. So we have a domain and domain represent a programmatic interface. So literally we assume that each domain and if the contract really inherits this domain should support this interface. The second part is type and it also really help us to understand what this contract do. So in interest rate model you can have a elinear model, fixed race model or any others wherever you want.

You have a version control. We have a major version which really related to uh breaking backward compatibility in many cases. We have a minor updates which also take about feature extents etc. which could also require some different ways to produce. And for small security patches we have a uh patch version and these things is recognized on gearbox permission smart contracts automatically. For example, if you really uh upload the smart contract in bite code which is has a patch version this version will be suggested as the latest update to risk curators automatically when they build this markets. But if you update others it would be all time uh in uh opt

indecision by them. And then we build a life cycle to achieve a really sustainability. So it starts from development and uploading your bite code into byte code repository. When your contract is upload you as a developer should sign it cryptographically. The same logic like an implemented in Apple app store. So you can't just upload an app. you should really sign it and then we attract a third party auditor. So even a core team and we as developers could not upload any smart contracts and go to production. Auditors and external auditors should check the code add a cryptographical signature and after that only after that it could go to

production. So it could really help us to achieve amazing stuff. So right now gearbox is maybe the first lensing protocols which achieved full autonomy. There is nothing should be done from developer side. Even if we stop operation tomorrow curators could use it the same way they could also really replicate the gearbox protocol on any new EVM compatible chain. The best stuff here that we make a step further and we open this gearbox bytec code repository for any contributor. If you want to build a plug-in, if you want to add a price feed adapter to interact with other contracts, we you are not limited

with our team and special keys. You can also make a suggestion. You can really connect with domain. What I already told add your own implementation for some feature. For example, you build a price feed to price correctly Pendle tokens or balance LP or whatever you want. You upload it. We have a white list of auditors. So you pass the audit and it becomes available for curators. So right now the protocol itself and whole code base leaves on chain. And I know how many developers in the here can you hands up? Yeah. Do you remember this painful stuff when you need to verify contracts and then go to the website and

check that the really real code you deploy to the system is the same you have in the GitHub. It's a very very painful way. So we did it a lot and if you have smart contract like a 27 files it become a nightmare. You can't make a mistake but you should do this with bite code repository. Everything is computed and checked automatically because one developer uploaded it to byte code repository and then external auditors did the same. They also compile on their machine then compare by code once and then it stores onchain. So no one can change it and you can see how it looks.

So literally it's a list of our contracts version sizes and who outditted them. So you can find all information about each contract the system. You can change the source code which is also stored there. You can find all deployed contracts. So if some kind of questions you have related to functionality, you can open it on any network and immediately find what's going on. And the second and the third part of this permissionless stack what I also proud of it's a price oracle manager. If you really work somehow with price feeds, you know it's alltime nightmare because the price feeds could be manipulated. A lot of security audits told about that. Hey guys, take your

attention. This price feed could be manipulated. But it's not only related to the uh incorrect or incorrect contract or misconfiguration. The biggest problem that all time these prices are aggregated value and as you know in uh there are a few uh hacks when price got pumped and then it ends up with collateral uh collateral uh recmputation with higher price and the attacker was able to steal the money. In gearbox we use a safe prices. So we use a uh pretty straightforward formula is just we pick the minimum between two alternative price feeds when we compute collateral

but to trigger liquidation we use only main feed and altogether it breaks a great shield for LPS at the same time it also create a good way which really protects from manipulation. We built like in our team all possible case how things could goes wrong and especially for tokens with low liquidity. It's a very useful case because all time people try to manipulate uh the value and the best way and use case of such a system you can combine really fundamental oracles and market oracles because fundamental oracles itself could really deliver uh some values pretty slow

because the smart contracts could be get hacked and market reacts faster. So if you know right now with XUSD collapse luckily Gearbox were able to avoid it the price fit still delivers the price of asset is $1.2 when for example a real market price is 16 cents when you pick the minimum you really protect your LPS and borrowers of such price manipulation or lack of updates. And you can also find a real example which happened on oiler when it was a half million loss when chain link oracle get a spike and exploiter immediately it. So even a chain link a

very strong brand a very good maybe one of the best oracles in industry could be manipulated somehow when you pick two alternative opinions and pick the minimum value it really solves the problem and you can see so how it looks like. So as a price fit store, it's a really cool idea. We connect each asset listed in gearbox on a particular network with possible um price feed. So literally all time you can see the value different value and this price feed connected to each asset has a different methods how they could get value. for example fundamental market oracles maybe it could be some external oracle or

computed value inside the system and then this catalog is available for market curators. So we have a instance owners who really filter all malicious activity who really do not allow and check it securely. We also work with auditors teams like mix bites and accuracy to make an additional check and then the and then our market curators could check from a really pre-checked uh possible oracles. But if for example such oracle would be removed also markets would not be affected because it's like one-time decision when you use it and then of course until curator make

any change it would be still the same and the market management the last topic I want to talk I think it's also a very good effort and it's very very crucial to make things understandable for humans when you see a lot of call data when you see bite code etc It's a very complicated to understand what's going on and to do that we really make a good interface and each change is showing by really like a values what was changed and what the new value to make a clear picture for curators what they do because it's like kind of multiple maybe more than 100 settings per one market.

The second part we built a simulation and test net. So before going to production we have a multiple checks. We really launch a node and this node really replicate all things in this batch and then we run test not only test related to unit test or integrational test. The most significant we want to understand is there is enough liquidity maybe to pass all liquidations in this pool. Are there way to open credit account for users and a lot of them. So literally you can see there is a lot of detailed reports what was done and what was wrong. So our goal is to make a clear vision for curator that everything

will go smooth and there is no one user account would be affected. If curator is malicious and such kind of data and reports go publicly because we are a good friends for transparency. We vote for transparency. Of course, people has enough time to really close their position or check uh what they do. And the last but not least, it's a very good way how we really do not trust anything. This interface I showed you, it's a system which has a front end and back end. And in my assumption, each back end could be really compromised. We should not try not tr we should not trust any solution like in the web two

because as you know by bit hack the biggest hack ever for 1.5 billion was not related to smart contract it's how the potential attacker were able to really implement some changes in web two so we built a way that this system is just generated batches and then we store them on IP IPFS IPFS really gets your immutability and then we use another system which is called permissionless safe and it's a just static front end there is zero dependency with back end it's all time have a version on IPFS also to achieve this way and during the signing process all transactions all the

parts into human readable format so if someone would be able to really hack our back hand and then people who sign them could find the sum in correct way. So only after that these transactions goes to time log and even so when the transaction goes thumb lock each resiscurator and we as well has a robot which monitors what's going there and could also alert that some malicious things come to come onchain. So this is what we built and I hope we can see more solution because what I can see right now that people really tell hey this is a problem of user they should do due diligence or it was a problem with price

oracle and lending stay away. I think if you want to really achieve institutional level of security we should not really remove our decentralization vibe. We can really do it together. So thanks very much. Thanks for your attention. Really great to talk on DSS.