avatarAndrew Hong

Summarize

Lucidity: A public project/procurement bidding and funds management platform

Ethereum Hackathon

Six Lessons Learned as a Prize Winner from the ETHOnline 2020 Hackathon

A month long Ethereum hackathon is extremely tiring, yet rewarding. Follow along as I recount the technical and team challenges, and what I would’ve changed about our approach.

Since late 2018, I’ve actively participated in various crypto conferences in NYC and played around with DeFi. I think I tried cryptozombies.io back when they had only two or three lessons, but never really got that deep into Solidity development. However, earlier this September I attended an Ethereum Dev Onboarding session after finding Linda Xie’s tweet offering to help new developers get acquainted with the ecosystem. I highly recommend watching the recording of the panel, as the web3 fullstack tools and resources the panelists suggested helped save me likely hundreds of hours of frustration otherwise (three that are absolute musts to check out for beginners are eth.build, scaffold-eth, and solidity-by-example).

Trent, one of the panel organizers, informed us all about ETHOnline (a 30 day hackathon hosted by ETHGlobal) and showed us the list of sponsors — among which were the largest DeFi projects and infrastructure providers I’d heard of including Aave, Yearn, Gnosis, theGraph, and more. My background is in sustainable finance, so I was determined to tackle an ESG (Environmental, Social, Governance) related blockchain project. I quickly was able to find a team of five focused on one of the largest governance issues facing the world today: corruption in public projects and procurement.

The first slide of our pitch deck, drawing heavily from this WEF research report

Now here comes the first lesson: don’t even npm init until you’ve broken down the problem as much as you can. While we had a basic four step framework above to work from, we should have spend more time splitting out old corruption cases to better understand the patterns and issues of the bidding and project management process. Our approach relied on identifying the key players (a project owner, a bidder, an auditor, and a funder) and architecting all of the interactions between them, instead of choosing focus areas. Jumping into the code to “figure it out after the first week” was a mistake, and led to at least a few days wasted. We also tried too hard to implement as many sponsor technologies as we could to try and win bounties, instead of fitting them in only where necessary — leading to a really messy developer and user experience. Here’s where we ended up after retracing our steps:

A much cleaner framework to build off of than a feature/interaction mapped framework

Now the second mistake was probably unavoidable given we were fairly new to writing smart contracts in Solidity, but please iterate and test your contracts in small portions as you go (I like to use hardhat, waffles, and ethers). Writing your smart contracts in large chunks will end up leading to headaches such as code length limits or stack-too-deep storage errors, and then refactoring into smaller contracts becomes a struggle (though when you do, look into libraries and interfaces). The following contract flow took probably seventeen iterations, with quite a bit of wasted code in the process.

We essentially used three factory contracts: one for bidding, one for funding, and one for milestone management/escrow

Number three goes hand-in-hand with number two: it’s called a money legos ecosystem for a reason, so don’t reinvent the wheel. While it might be fun and a great learning experience to write every smart contract your project will use — it’s probably a waste of time and may have security loopholes. There is already a lot on-chain that you can build off of, and tackling the project like this makes it easy to tweak only part of your contract later instead of rewiring the whole thing. For us, we came across this issue with our escrow contract. Managing many milestones was difficult to figure out, and our initial approach with having an auditor somehow change the ERC20 allowances between the bidder and the funder for each milestone felt clunky and unreliable. Adding another milestone would require rewriting part of the contract, and adding a feature would require rewriting most of the contract. After a week of fiddling around with it, we found Gnosis Conditional Tokens to be the perfect fit to our escrow contract. If we had more time, we might have re-written the funding contract to incorporate mechanisms such as Aave Credit Delegation or Balancer pools instead of our non-flexible version. And if you aren’t already using this solidity package, make sure to check out Open Zeppelin for all your standard token contract needs.

At this point we were in week three, closing in on the end of the hackathon. Any teams still in the running at this point were in a mad dash to build out the UI, finish all the smart contract flow testing, or incorporate any other sponsor technologies with the project. Here’s lesson four: choose your technical battles wisely, and project that it will take longer than you think even with many people. Looking back, assuming two days for integrating each feature was optimistic. It takes time to understand the documentation, figure out how to implement it in your code, and also debug with others over discord. Having each team member take on a different feature/sponsor will save you time, but may lead to larger issues if someone remains stuck alone. There are a lot of tradeoffs to consider, so make sure to keep an open channel of communication and switch roles or tasks if necessary. We went from integrating seven sponsors to three, which saved us a lot of stress and also improved our quality of integration.

Now we’re onto the last few days — it was time to put together the pitch and demo video. At this point, it’s good to take a step back and look at your project holistically. What benefitted me here was creating a project roadmap, and pretending that launch was only a few months away.

Having a roadmap will make your message and project more clear to both yourself and the judges, and also help point out any logical holes in the work done so far.

Lastly, before making the video, try to walk a friend or family member who has little to no knowledge of the blockchain through your project. If you are able to get them on board and understand what you are working on, then you are guaranteed to have a strong and clear message when presenting to others. This part may be frustrating but it will help with refining the messaging in your video, as well as priming you on potential blind-spot questions that might get asked in judging.

Conclusion

Here are my key takeaways:

  1. Plan and scope carefully and choose your focus areas based on the process to replace, not just on what might be fun to make in blockchain.
  2. Write your solidity contracts in small portions, and test as you go.
  3. It’s called “money legos” for a reason, understand composability and flexibility of your project’s flow.
  4. Chose your technical battles wisely, and budget for time spent debugging and getting help especially amongst members of your team. Know your team’s weaknesses early.
  5. Have a roadmap for the future of your project to help give the team and others a vision of what the more complete product would look like.
  6. Try to communicate your project/demo to friends and family who are outside the blockchain ecosystem to get feedback

One last piece of advice: pace yourself. Many teams start out with a bunch of spirit, but fizzle out after two weeks. Understand that members of your team may work better in sprints while others in a marathon, and adjust the work assigned accordingly. Overall, I had a blast in this hackathon thanks to my team, the event organizers, and the sponsors — can’t wait for the next one!

Also, Read

Blockchain
Ethereum
Hackathons
Smart Contracts
Product Management
Recommended from ReadMedium