Best Coding Practices With DAO Governance in Mind | John Huang - Decent Labs
Ethereum Denver·Thu, Oct 9, 2025, 12:00 AM
This technical workshop will explore the critical considerations when developing code governed by a DAO. We'll discuss how implementing upgradable contracts with proxy patterns is essential for long-term maintainability. While developers can directly deploy algorithms, proxy contracts should be under DAO governance to ensure proper oversight. We'll examine how founders need to understand DAO proposals and their interaction with smart contracts, particularly for deploying proxy contracts and modifying parameters. Additionally, we'll cover the evolution of DAO governance structures, from initial Multi-Sig setups for smaller projects to more complex token-based voting systems as projects grow. 🚀 Get Ready for ETHDenver 2025! 🚀 We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2025—it’s going to be epic! 🌟
Transcript
[Music] can start now hey everyone yeah uh this is the session about coding practices how many of the audience are developers give me a wave oh nice nice yeah if you are not a developer you should bring your developers here or pass on the uh this session so I'm going to talk about some battle tested coding practices that you should uh use when you code for evm and I've seen disasters because people misses some of those okay Al the title says in relation to establishing a doll this one has nothing to do with dolls believe or not when you write smart contracts people are going to send tokens to your smart contracts and if you don't handle it essentially then they burn their tokens this includes yeast usdc or any tokens they send so make sure you handles that right which means in your smart contract have those functions receive for ye token received for RC 223 on RC 721 received for nfts unfortunately there's no catch all for erc20 so if someone send you erc20 tokens they're screwed just one point that you should always use your C 223 when you create your own tokens all right next one when you write smart contract well when we develop for web to you can use magic numbers here and there just constant um remember in web 3 on evm contracts are immutable which means once you deploy it that that's the code that leave s chain for forever now how do you deal with that write settings right whatever you see like hey here's a algorithm I'm calculating something don't use magic numbers create a setting that you have Getters and Setters in your contract and example let's say you want to have a point system on chain and you use it to encourage users to get engaged right so um very simple depending on the action you give them points let's say it's D5 you give them 10 points when they deposit 20 points when they place an order and zero point when they withdraw simple in initia incentives and maybe give them air jobs after some period when you release something now look at you think about the algorithm I talk about what's the problem people can G it right they can deposit withd draw deposit withd draw accumulate the tokens so you want your contract to have a Setter on the action and the point system for each action so hey maybe give them 10 points when they deposit minus 10 points when they withdraw there's still problems but we're going to get to that but at least make your smart contract settings mutable so you can control whatever you want to do in the future when things happens that you didn't predict and you'll say hey I need to modify that all right I just said smart contracts are immutable very bad practice this in reality right in web tool you can change your backend any moment do a redeployment no problem in web three you deploy your contract that code leave unchain forever what if you have additional business logic what if in the previous example I'm going to get to that people keep on gting gaming your point system you need to be able to upgrade your smart contract well fortunately there's established pattern to deal with that uh essentially it's a proxy right you have your immutable contract which leaves unchain forever but you have a proxy contract in front of that which simply point to the immutable contract and you can modify the address of the immutable so you can make a new deployment and have the proxy contract point to the new deployment this is how you make smart contracts upgradeable and example back to the point system hey what's the problem if you say you get 10 points when you deposit minus 10 when you withdraw easy to gain right I can deposit like $1 every transaction and then after 100 transactions I withdraw $100 dollar and I again 90 well whatever 900 well I cannot even count how many points you can gain by doing that and also if you are D5 protocol just think about that um let's say it's a pool it's a you know is a pool on Unis swap let's pretend you're Unis Swap and you want to give people incentive to deposit into the pool however this initiative this incentive needs to adjust because if you have enough liquidity in the pool then there's no point to ask for more deposit into the pool so you need a dynamic point system I would say this is still very simplified you want to check the pool's liquidity and if it's a new pool have very little liquidity you want to give more points when people deposit into the pool or you want to in uh give incentive based on the amount someone depositing $10 is obviously different from the next guy depositing $1,000 and then there's the action so let's say you were on the previous formula and you want to upgrade to this one in this case you do need to upgrade your contract and the proxy pattern enables you to do that super important here uh there's a whole big issue with management when you upgrade contract so you want to be careful about that I'm not going to go into the details but like I said everything's battle tested I know of company doing contract updates and mess up the state because they couldn't import the state from the previous uh previous contract and then the whole contract is dead so be careful about that and make sure you test yeah we live in web three so what happens everything could be hacked will be hacked we all hope that when we write a smart contract is solid and uh nobody touch it and you get audited that's a good practice but still someday if there's any problem in your code any host it's going to get hacked now what happens when it gets hacked have a kill switch super super important because I know of D5 protocol which didn't have kill switch and it gets drained so it gets hacked and the hacks continues because it they don't have up upgradeability and they don't have a kill switch all they can do is sitting there watching their fund gets moved out of the contract their funds and their customers funds right you look at some examples uh on Salona pump. fund they got hacked several months ago and it was ongoing process but they did have a kill switch so after actually after a few hours they killed It upgraded the contract with fix and they were able to restart um web two example right we all know bybit got hacked just few days ago and save turn off their services to protect that's a web two example they simply they can do that like this web three you have to think about those kind of extreme conditions and make sure you protect yourself well I'm going to use D5 as examples at least okay kill switch can have two different kind of forms one is kill you simply turn down the smart contract completely so there's no way to turn it back on right and then you simply upgrade the contract to restart or you can pause it with which means you stop for that moment while you investigate and decide whether to upgrade the contract or simply okay it's not a big problem you restart and pause it so for D5 at least have those two you may have more you may pause trading but at least stop deposit and stop withdraw when something happens protect yourself and protect your customers all right this is tied to Dow so when you have contracts with multip settings and you can upgrade the contract who is the owner think about that right are you going to have a proxy contract that anyone can change the address to the master contract obviously no so in the proxy contract you have to set an owner which says hey If the message sender is from this address I let it through otherwise no reject now think about this we are in web three we are supposed to be trustless if someone is reading a smart contract code and they see this address what does it mean this involves trust do I trust this address do I trust the person behind this address even if I trust this person this developer can I trust that he doesn't get hacked right what if he seed phrases gets stolen and the hacker take over this address so here's an question like fundamental to web three that are we going to put in something required trust into this whole process into your smart contract now unfortunately when you have an upgradeable contract there will be an address and this involves trust and how can we make sure our customer trust that here I'm just going to give you big warning never use personal wallet as the owner of your smart contract just know right oops yeah don't use your wallet as the owner the right process is decentralize it establish a dow have the Dow control the smart contract and anyone who question hey what is this address they can find the doll no is controlled by the stakeholders behind the doll you can set it up with erc20 voting or nft voting or you know for startup like early stage you can use small TC and migrate to rc20 when it gets bigger or when you go live but don't use your wallet address set it up from the very beginning so customers can have confidence in you and have some level of trust right so this ties back to the uh previous examples here's the very basic suggestion I would give to everyone you have a erc20 or ERC 721 do to control the smart contract for regular settings there is an exception you need a separate owner for the kill switch because guess what when you do the proposal and vote normally seven days maybe you do three days or one days but for a regular Dow governance you do want give the voters enough time to discuss and reflect and vote so you don't want instant voting so for the Kure switch what can you do you can do a multi- subd do or fullback console which controls only this kill switch and then when something happens you just you have to do some off Line work call up the people who are the controller of the mtis and say hey I need two signatures to kill this flag to kill the protocol or pass the protocol so we don't get drained and in real life it may be way more complicated than this you may have different departments controlling different settings different group of settings in your smart contract totally reasonable but at least do this all right so that's very simple presentation from the technical side what you should do just a general practice we also have legal side discussion that's totally different aspect you know developers you want to get your business people to attend this just QR code scan it and you see our schedule cool um I have few minutes any questions cool yeah I hope everyone gets something out of this like I said everything I present here I have real story of disasters because things are not handled correctly I just hope that this will help people prevent go ahead sorry Mike is coming hello hello hey yeah thank you so much for the presentation I was wondering um you know over the last few days I've had a lot of conversations with people about uh the safe multisig you know downtime as a result or the safe wallet downtime as a result of the buybit exchange hack um and I was wondering how a dow governed uh protocol like you described with a multisig subd dow could I guess increase Security in organizations like that yeah yeah so one benefit a good point right one benefit of having a proposal that having multi seik to vote on it there safety reals like periods before you get to the vote voting period and then time lock after that's in general like rc20 or 721 or multi6 that give you a chance to exam the transaction and make sure it is what you expect it to see right like save or or by bit they are like doing Blind signing on the hardware wall it and the save youri show something supposedly we actually don't know the details supposedly save youri show something when you sent to the hardware wallet is something different that people signed blindly um when you have a proposal process first is there's a period that you don't vote on it you can exam the transaction and make sure it is what it is and then you can say okay time to vote multis Vote or rc20 or whatever right so in my example only the kill switch is controlled by by multis but bigger part is like upgradability you upgrade your contract that's so huge you don't want to get misled and upgrade your contract to someone else's code and just get everything stolen so when you when you before you vote someone in the community or your coure team should exam the transaction and make sure it's the right one then you vote or you simply say okay no don't touch it and then after your vote is not executed right away so there's a execution period that someone has to go there and click and say execute so also there's additional safety during that period that someone can look at the transaction and make sure it's the right way additional safety that bybit hacking could have been avoided very good point thank you all right 29 second thank you guys have a good show
Automatic transcript — names and jargon may be misspelled.