How to Build Secure and Successful Web3 Protocols | Harikrishnan Mulackal - Spearbit, Cantina

[Music] hello my name is Hari and today I want to talk about how to build uh safe and successful webt protocols first of all why am I talking about it and why should you listen to me so I used to help build the soled compiler or the programming language a while ago I'm one of the founders of uh spe and cantina we are an industry-leading security company working with uh projects building in crypto and because of that we have worked with over 250 customers directly and we have interacted with over, companies building in in crypto and we've seen it all when it comes to like you know building and deploying smart contracts and building your own protocols we work with uh people all the way from like young startups who are trying to build like a massive protocol all the way to people like Unis Swap coinbase all the big players and I want to share a lot of thoughts based on what we have seen what works and what doesn't work so let's start about like let's start talking about one way of building things which is very common in the vtu space which is like build fast and break things and this is something that really was popularized by Facebook because they have this philosophy of like you know shipping fast moving quickly even at the expens of like things breaking it's very common in web to startups as I said but this doesn't work in crypto unfortunately and the main problem it doesn't work in crypto is because of security if you're a Founder building a protocol in in crypto the moment you have assets or value um in your protocol you will have blackhe hat hackers that is looking after your protocol trying to find bugs and steal money I don't want to sound alarming but but this is the reality of building in crypto the moment you have use of funds there are malicious actors who are trying to steal steal money this is not the case in web web2 companies and I want to talk about I want to highlight this by saying that web2 hacks are not catastrophic and I want to talk about an example of rol which is a $3 billion company it's very successful company they sell an application that connects with your database and they will help you build dashboards and other uis without using much code so a lot of companies including many companies inside Fortune 500 uses three tool to like use to build like analytics or like Syle tools um for admin dashboards they had a compromise they had a hack back in 2023 where an employee was spear fished and a malicious actor was able to gain access to all their systems this is like you know the worst of the worst when it comes to like web to hacks you know your entire system is compromised turns out that all the sensitive data was leaked and in rol's case what you're giving retool is access to your own database so imagine you being like a for 500 company and you give access to your database to like this other company and now that company get compromised and now your database is also compromise this is exactly what happened with retool um but fortunately or unfort fortunately after a single month of the hack it was business as usual rol is now still alive and kicking it's a very successful company nothing really happened to them except for the fact that okay they had to like make a public disclosure maybe they lost one or two customers maybe they did not but nothing really happened to rol as a company on the contrary if you look at web three hacks they are catastrophic a single hack can end your company Give an example I want to talk about Nomad so Nomad was a a multi-chain bridge which is built by a very highly technical uh Team of Engineers it was one of the best teams out there when it comes to like building multi-chain projects and they had a single hack where there was a simple bug in one one of the smallart contracts and they ended up losing $190 million they end up recovering some of it but the initial impact of the hack was $190 million and this hack K the company you know the company doesn't exist anymore um and and that's like a good like comparison to like retool where a similarly catastrophic hack happened for the company but it's still alive and kicking in fact if you look at what the hackers did with retool they try to go after their crypto customers they didn't even try to go after their web customers they try to see which companies in crypto ended up using retool and they try to see H how much information you can extract from this crypto uh company's databases so that is the kind of like sophistication that a lot of hackers in the space are going after even when they hack a web to company they're going after their crypto customers because that's where the money is so I know like these big hacks become very public but there are often like small hacks that doesn't really like you know come up in public you have to be in the industry you have to be in security space to understand this smaller hacks these smaller hacks also kills a company companies if you choose to continue as a as a product that underwent a hack you often have to like fill the hole with your own funds or you have to like shut it down there's like no other way to continue if you are a small company that had a hack so this is the biggest difference between like building in web 2 and web 3 where a single hack can kill your company so moving fast and breaking things it doesn't work so let's look at the complete opposite opposite of like moving fast and breaking things which I call as you know moving slow and not breaking things unfortunately this also doesn't work and I'll tell you why so we speak with a lot of customers building in crypto and the number one feedback we get after these customers go into mainnet is that they often learn more of about the problem they're trying to solve in like one week of going live than like spending six months like building this is such a common problem if you're a young startup building in crypto building a new Innovative product the best way to learn some learn about the market and your uses and your problems you trying to solve you to ship something out there and if you fall into this trap of like spending months and years Building without really like getting real customer feedback by going into the market you're probably building something that is not correct so we see this common pattern among like customers we talk to which is that the second version of the protocol is often times the protocol they wanted to build initially so I want to now talk about what does it look like what does what does success look like when you're building in crypto and I want to bring like an extreme example which is unisab so if you look at unisa V1 it is a protocol that was extremely simple you know unisa for those of you who don't know it allows you to swap from one one token to another token like you can you can have like USD DC and you can buy eat using Unis swap so Unis swap V1 was dead simple you can swap ethereum for one other token that's it that's all it did of course like you know if you can swap from ethereum to another token you can now also swap from one token to another token because you can go through ethereum to do that so but the way unisoft V1 implemented it was like having like a single Swap and they like kind of like you know made it made like two swaps work by batching these calls if you look at Unis swap V2 now you can swap between any pairs you not restricted to like ethereum pools alone you can have a pool of say USD usdc and usdt and swap between the two without dealing with ethereum as an intermediate your asset so anyone sitting here who is trying to get better at building a protocol I highly recommend you check out unisa V2 it's an extremely well-designed protocol it's very very simple and that's that's the reason I want people to check it out it's very very simple and unisoft V3 ended up increasing the efficiency if you look at unisa V2 and and and the pool I just talked about which is usdc and usdt turns out that it wasn't very efficient to do swaps this way and Unis swap V3 improved on this by making you know stable coins and other things to be more efficient and Unis swap V before ended up shipping better programmability into the unisa protocol so if you look at the evolution of unisa protocol it started off as something extremely simple and they realized that okay they have clear product Market fit with their problems and they clearly understood what their problems were for example that it wasn't efficient and they ended up shipping like newer iterations that solve more and more problems and now I want to talk about a framework for shipping secure and successful crypto products which is based on like our experience working with all those customers first of all you have to ship fast there is no other way around it but you also cannot break things so I think the best way to do both is by shipping your V1 by stripping down as much as possible so the question I tell Founders these days like what is the absolute minimum set of features that you have to ship that you believe the uses want and then try to build something something that's like less than 50% of what you believe is the absolute minimum features this is the level of like stripping down that you have to do if you're building a protocol that is a you know the V1 um stage and then security is important but if you have a small protocol it means that it's easier to secure you don't have to like invest a lot of time money and resources into security when you are small so you can get a security review with one security searches you can do a security competition ition you can also like host a bubani program none of this will break a bank unlike like building like a massive protocol where you have to now invest a lot of resources into security and think about building a V2 with more effort into engineering more effort into security like the protocol that you want to ship is is the V2 protocol it's not the V1 so this is the mindset that I want more Founders to have when they're building in crypto and in my opinion from our understanding this is going to help you ship safer and also like be successful building a product in crypto and now I want to like you know share some general advice General thoughts on like what I just said okay first of all this advice is most relevant to like 90% of the startups building in crypto because we talk with a lot of companies building like new and Innovative products but if you are building a product that already have like an incumbent player uh you probably need to like ship something that's already better than what's out there so if you're building something that's that already has like a competitor or like an incent in the market you probably have to ship something way better than them from from day one but if you're building something new you're much better off shipping something small and starting off there the other thing I want to talk about is that building a protocol is very hard solidity is very simple solid is a very simple programming language and it's always it's it's very like deceivingly simple you think it's simple but turns out that there is a lot of nuances that you did not take care of compare that to like building like a crude app which is like you build like a web 2 application which has to deal with the database some authentication some apis building a solid contract is like 10x harder even though it doesn't look like that so I want you to get into this mindset that what you're building is actually like harder than it looks and the last thing I want to talk here which uh which which is very controversial is that starting with upgradable contracts are okay you know if you listen to people on crypto Twitter you would often hear a lot of idealism about like how you should build protocols they would tell you that you have to decentralize everything there shouldn't be any like admin admin functions but these are often relevant to like protocols at the end stage of iterations not the beginning St of of of the iteration and I see too many Founders who fall for the strap of like listening to like how your protocol should like end up instead of like how you should start building so it's okay to have upgradable contracts but make sure that you know you put some effort into securing these private keys that are securing any admin functions a mistake I've seen some Founders make is that they may have like a private key that's lying around and they their laptop as a environment variable and sometimes they get compromised and it's just very easy to like you know upgrade and like steal uh use of funds by doing that so there are some risks to it but the risks are easily manageable if you use a MC and you know don't screw up your opsac so that's that's mostly it for my talk and I just want to like summarize the point I just mentioned just so that everyone gets it so moving fast and breaking thing it doesn't work in crypto security is the big problem here security issues can kill the product if you're shipping something with use of funds in it people are going to come and try to steal it I don't want to sound alarming but that is the truth moving slow also doesn't work you'll have a harder time building a successful product if you're taking a long time going to the market the reality is that you probably don't know what your customers want until you ship it and I want to propose a framework to build and ship successful product which is ship something for the V1 that's extremely simple think about unisoft V1 extremely simple think about what is the minimum number of features that your users want to have try to ship something that's like 50% there you probably are always shooting a day one think about V2 being the real launch of the product and once you go from V1 to V2 you can scale your engineering you can scale your security you can scale your book boundary program you can do all these other things by the time you're getting to V2 that's all for my talk we have a few more minutes so I'm happy to take any questions if you have I know there is not a mic so you have to shout okay okay the mic is coming I'll yeah hi what do you mean by um stripping down youru V one so the mistake I think a lot of Founders make is shipping a V1 with a lot of features and you probably need to ship fewer features than you think for your V1 and like keep it simple like I said like think about what is the minimum number of features that you have to ship to make the product useful for your users and you probably should be shipping only like 50% off it so does that make sense yeah uh so agree with you uh especially on the security part like especially for prodal companies the security can kill the company so uh uh on your view like at what stage should a company have a dedicated a secure member secure engineer or secure team like fulltime dedicating on make sure that this doesn't kill the company yeah like the he of view okay that is that is a great question and I think the answer varies like company to company so if you look at unisp as an example I think unisoft started having a dedicated person after they shipped V2 so around like V3 time that's when they started like thinking about having in-house security people and in my opinion like that is the stage where you need to start thinking about like having an in-house Caesar or like a security team um you can get away with a lot in V1 if you can get some external help I would say for v2 like invest a lot more into security at V3 better start thinking about like having an in-house security team because today the threats are very different today people are trying to compromise you know your laptops I mean you know what happened with bip it like people are going to come to like you know hack your laptops hack your devices and when you are a large company that manages a lot of use of funds there are usually ways to like compromise it so like definitely after like having clear product Market fit and a bit after like you know your V2 that's when you start thinking about inhouse ESO hi Hari you mentioned uh I got some question go here dropping the phone you mentioned you have uh 6 months in development and that would be too slow because you would hit your customers and you would re re get uh people engaged on it what is h in your experience the timeline from V1 to V2 that would make it a uh so I think I think V1 to V2 you can invest as much time as you want like I've seen protocols invest like a year from doing this transition but the but the goal really is to ship a V1 where you can really understand from your customers what I've seen people do is like they spend a lot of time shipping this V1 and in one week of sh shipping this they learned that okay all those features that they thought users wanted that's not what they wanted they wanted this other things and I want you to like spend as little time as possible in V1 and invest time after V1 really understanding what people really need because before that you're just guessing to be honest so it looks like we're at time but I'm going to be around the event if you just want to have a chat but yeah I really wanted to talk about this after like seeing a lot of companies making the same mistakes over and over again it's expensive it's not going to help you become successful and my opinion if you use this framework you're going to have far more success and far less like issues with security thank you