DeFi Safety and Transparency - Rex Hygate

all right we're going to move right into our next content i've got to get back to my uh my gamer type friends here i've been in the space running around this rainbow buff corner if you want to come talk to me um but we've got uh rex with defy safety how are you doing i'm good rex i like your uh your your turquoise shirt there thank you that means that you staked and attended eat denver in 2019 2019 and i have the 2018 one but that looks like a jammies i only you only had very large at the time oh sorry about that well go to buffacorn.com and get the new gear all right i'll do that for sure see ya good luck all right thank you much so uh good morning and uh i'm rex highgate from d5 safety we're going to talk about mostly transparency and a little bit on process quality so transparency is what you show publicly to allow strangers to trust your code and the reason why you're transparent is to bring trust uh which drives users and drives more tvl into your protocol i mean a lot of what i say is applicable to any d5 any ethereum app but our focus is on defy and just an example imagine a c5 investment firm that wants to get into d5 they love the rewards uh so the boss goes to one of his people and says prove to me that our investors money will be safe he reads up he gets some uh hires a coder not an auditor trusted coder and he says prove to me that uh the investment is safe and show me how it's going to work transparency is the information that that developer will use in order to um in order to prove that and uh we should consistently be transparent as an industry and this is something that defy safety is really trying to promote because when the talking heads start talking about defy in the near future they're gonna pounce on the weakest links you only have to look at the silly double spend story that was going on about bitcoin to have an idea of uh how this works and then even once defy is a big part of the establishment uh finance ecosystem transparency will remain as a way to prove the way the um transactions work if you have a system that runs on transparency there it's impossible to have a panama papers event so um what we are um at this point i will flip over to our actual website so our website comes up uh with uh we've got about 60 odd um reviews that we've done we've done pretty much all of the d5 pulse list except for the layer twos which will be our next step and if you go to one of our um click on one of ours you'll see we break down the review uh on code and team documentation testing and audits and that's i'll be talking about uh those um parts and you'll uh everything's nice and color-coded so that the idea is you don't have to dig just to get an idea of how safe through our process or a um a protocol is but if you click again you can get the actual detailed report uh which um uh has here you can see it we have a fixed process we go through we get reviews we have um uh screen captures we have uh sections of text we do um uh uh slots and uh test counts and such so it's a very detailed process that we have and because we follow a very strict process the scores can be compared one to another so the number one thing that you want to show to the world for a transparent protocol is your smart contract addresses so this is a list of all of the addresses that you're executing with publishing your smart contract addresses is absolutely number one for transparency or to flip it around failing to publish implies that you're hiding something if you if you're going into a protocol and you're you know you're gonna hit the commit but you can't see the code that you're going into it um it makes you feel nervous and that's the last thing you want the actual addresses can be in a website a website page they can be in a git book they can be in a repo though please not in the json file which we have found so uh here you can see the urine v2 uh page it's in their their git book and they go through and they clearly enunciate where all of the um uh you know all of the different pools what the addresses are how it's all together there's details there because what yearns a big contract but the details give people confidence and even if a protocol doesn't hire a developer simply putting all of this information out there is 24 7 365 daring them to come in and check and that's exactly the type of confidence you want to give to people that will bring them into defy and bring them into investing so uh if you go back to the example the smart contract developer this gives them exactly the contracts that they have to do and then you give them documentation documentation is vital for transparency if you think of the example there it's vital so that the developer knows how the code is supposed to work now this is more than just a white paper which describes the math and the logic and um the way uh you you give rewards this is documentation at the software function level um it also has a lot of other exa good good advantages it tells people that you're planning to stay for the long term it says that you're ready for personnel changes i can't lose my lead developer and suddenly not be able to improve on my thing and it says you made an effort even in hiring when you're competing to try and get a good solidity developer for your protocol having good documentation gives them a very strong feeling about confidence that the um that your protocol is going to be a good place to do it now if you look at the gold star for documentation is synthetic this gap these guys knocked it out of the park they have uh a system overview which you know they go through the architecture um and then they've got uh uh descriptions with the code there all the variables all the constructors the details um for the um external functions internal functions it's just fantastic these guys put a lot of effort into this mint is another good example um they're using here uh a a self built um documentation using that spec they've got code snippets in here which is just wonderful because it allows what uh is called traceability i'm an aerospace guy that's how an aerospace takes software quality extremely seriously and at denver 2018 when i was scratching my head on how i could contribute how my experience could really help things software quality ended up being the way that uh i felt i could add the most so the next thing is testing now honestly testing is something that i've looked at now 60 odd uh protocols and virtually always people put a tremendous amount of effort into the test and you can see it and you know that they're running the test regularly as they um as they're developing the software then they deploy the software onto the main net and there is not a single piece of documentation that says whether or not the test pass i mean what is up guys if you consider the effort you've done in developing and using the tests writing a simple report when you deploy which is not very often is not too much to ask and when a third party like me comes in and looks it is a tremendous assistance when i talk to the auditors that have been supporting me um one of the things that they said is don't try and run the tests yourself from the github it's a rabbit hole there's always some little detail so a report really helps so what should be in a report well the types of tests and the number of tests we have this many unit tests we have this many system tests describe what the system tests do these tests are normal operation these tests are abnormal operation things like that describe the tools that you used i use slither i use mithril i use some mythics say it and give it a little bit these are all just small areas now coverage i would say 25 of the um uh protocols that we review have coveralls and that i understand that's a developer's decision but at least with coveralls we have a coverage report the number of times where you sit back and you're looking at the scripts in the test and you go i'm sure these guys have got great coverage but i have absolutely no evidence of it so coverage gained and not just coverage gain now going into my aerospace rules why are some lines missed did you take the time to look at the lines that you didn't get the coverage and figure out you know what the reason is now there are perfectly valid test reasons why some code can't be it can't be gained give a little indication of that i mean dead code is obviously something that is very strong because when you consider how much you have to pay to put code onto the blockchain getting rid of dead code is something that really pays you which we don't have in the in aerospace something else if you're used or will you continue to use a test net put a paragraph on there saying what the test net was what it did and some references if you sat back and looked at your protocol and looked at similar protocols and said i saw a hack uh on say harvest i know what happened and we've done these subtle things which means that that similar hack won't happen a coverage test is a coverage the test report is a great place to say that type of stuff so my main point is please write test reports and i might add even if your protocol is already deployed you can write you can put a test report on afterwards also so audits um audits are obviously a big part of our review but if you think about it audits are technical reports commissioned by and for the protocol the audience of the report is the developers of the protocol not the general public using the reports but audits are the main badge of quality for a protocol on deafy pulse they have a list of the audits that are in there they've started to add that that the audits are the main um badge of quality right now this is uh something that we started in the ico days and it's just a habit that we've retained so as i was writing this uh presentation which is actually the first presentation i've done um the epiphany came to me that we hope that a rating like d5 safeties will replace audits as badges of safety so in this case it our reports are written for with the intention of being read by the users of d5 we are independent we're not paid by the developers when we do it which of course is not the case with the auditors and uh so effectively our reviews or reviews like ours are designed to be a badge of quality that is uh better and more um more mature than simply saying uh it's been audited so what do we look for when we review an audit well one when was the audit done with respect to when the code was deployed obviously you um you get more points if the code if the audit is done before the deployment but you still get points even if it's done after next you look at the scope the duration the complexity and uh does the audit report fit for the protocol if you have a complex financial instrument that will be interfacing with a dozen other instruments and the audit report checks for um uh math errors and basic reentrancy they've missed a lot of elements that in a complex d5 protocol should have um we look at the quality of the audit report you know is the details in there um does it explain even if there's no virtually no findings does it say we ran these tests we went through this process and give some evidence that you can see that definitely these guys did look at it we look at the quality of the auditor um there are good auditors and there are bad auditors i would say three of the 60 odd audits that we've seen are pure audits that were just commissioned to say we passed and generally the biggest immediate red flag is if you look at an audit report and it has a great big past on it that automatically starts to raise red flags so there are there is one auditor that's doing that but they do great audit reports so that's not always finally we look at the findings the severity are things resolved um and all of that we put into a um a score which is obviously a very big part of the complete defi safety score so that goes through the four main parts of um of transparency that we look for and that we score and one thing that i didn't say but should be clear transparency is saying it to the world so often like after we do a report we'll send it confidentially to the developers mostly saying did we miss anything uh you know is there anything you disagree with and we have a discussion there then telling us oh our audit is over here you don't get scored for the audit until the audit is there publicly so we don't in a sense score the process quality steps we score the transparency of the process quality steps because as i said the biggest advantage that defy has is our transparency how much we show what we're what we're doing to the world so going back to process quality i mean if you look at the definition especially for manufacturing it's monitoring and improving a defined process to improve efficiency we're not at that level what we're trying to do now is to develop rules for consistent uh deliverables that the public can see on a protocol that instills trust on a decentralized network and implicitly with that we're trying to develop a standard for the public information set that protocol developers can look at and say this is what i've got to see now clearly transparency is in a sense a crutch for doing the incentivizing to do the steps of quality but it's also immensely important so um just sort of a philosophical end point defi is speaking to the world small voice but it's getting louder among many other things the world expects for more quality and it should be in a language that they understand now we're super young now and not many people are looking at us so we have the opportunity to define how we're going to talk quality to the world and when they start seeing that we have a process and it's consistent it's public it's quantitative it's auditable they're just going to accept it so our effort now and what we're trying to do is to bring up a quality standards that people work on uh so that this one aspect is something that we agree on and then finally once we've got a quality language that as a group as an industry everybody agrees on and i might add at the moment we wrote our own process because there isn't one and there isn't a public group to um to develop it and in fact in 2018 when the f security was just starting and i started secure which was a product of denver 2018 we tried to get working groups together and it was just too early the industry wasn't ready i'm not sure if it's ready now we're definitely closer so eventually the quality processes the rules they should be public standards that are sort of developed by industry not by a single organization so once we've got a quality language like that we iterate it we improve it we bring it keep it up to the technology we're up to the sixth iteration of our process we're doing the work for version seven um in the background and that'll be coming up in the next couple of months so this is basically it for us what we're trying to do is to bring a language of quality into the deafy space and uh with that a little bit to the entire um ethereum space and if as our funding uh improves we're going to start uh doing adapt safety which would be the same thing on all the other types of uh adapts so um that's pretty much what i've got any questions yeah rex it doesn't look like we have questions but uh definitely inspiring people with your talk thanks much