We interviewed our very own Protocol Specialist, Viktor Bunin, about his experience as an organizer of the recent ETHDenver event in Denver, CO. He spoke with us about what makes ETHDenver special, some of the challenges organizers faced using DAOs for judging the hackathon, the bZx event, and his favorite moments from the conference.
ETHDenver is a hackathon for Ethereum hackers, designers, developers, and enthusiasts. Over the course of three days, people from around the country, and the world, coalesce around their desire to help build the global blockchain ecosystem. Attendees are in teams of 2-4 people, each with their own unique skills. They work together to build a decentralized app, write documentation or white-papers, design infographics, and so much more. In addition, blockchain experts give talks and host workshops. But in reality, ETHDenver is much more of a festival than a hackathon.
It’s not actually organized by ETHGlobal, but rather by a local team who is close to this community; the organizing team brings a unique culture, community, and flavor to the event. Ultimately the goal of ETHDenver is to bring the community together and foster innovation with decentralized technology.
About 2,500 people attended this year, which is a new record for us! This is only ETHDenver’s third year, and each year it gets better. We added more art, more experiences, and even more cutting-edge tech!
This year was a really big success. First, the space was really cool and an enormous upgrade from last year. A lot of love went into it. Second, there were a lot of talks, good engagement, and people had a ton of fun. Last, we were really pushing the envelope on using decentralized technology.
Each year we try to use new decentralized tech as it becomes available. Last year we used Kauri, a decentralized Medium which was awesome, but not perfectly equipped for a hackathon’s submissions and judging process. Although it wasn’t built for our use case, we tried it anyway and pulled it off. This year we tried to do that again with Decentralized Autonomous Organizations (DAOs).
DAOs are difficult because they are really new tech and not optimized for hackathon participation. This caused some definite strife, particularly around the submission process. But we were able to be flexible, change the process in real time, and find a solution. The organizers and judges were also transparent about the issues and, in the end, it’s safe to say that people had a really good time and built really awesome stuff. The quality of projects that got to the second round was noticeably higher than last year.
Participants know ETHDenver events are community organized and that we are constantly trying new things. I really love how gracious and understanding the community is, particularly when problems arise. Even though the judging part was a little rocky, everything else was smoother this year. All in all, it was a great success.
Gregory Rocco and I were actually the Judging and Bounties Stewards so we worked as a team to get everything done. So being a Bounty Steward meant that Rocco and I were responsible for making sure that all the sponsors submitted their bounties, that they were posted, and findable by participants. A bounty is when a sponsor incentivizes people to use their technology during the hackathon in order to win a prize. For example, MakerDAO might say, “Hey, teams, if you use DAI, our stablecoin, in your project, you could win some money by building the best hack.” It’s a nice perk beyond the main competition.
As Judging Stewards, Rocco and I were responsible for defining the judging process, essentially ensuring that after submission, all the projects were seen, evaluated, and things worked smoothly.
There were two rounds. The first round was supposed to be an equal vote. Because we did everything through DAOs, everyone at ETHDenver got some experience points (basically reputation). The more activities you did at ETHDenver, the more reputation you received. In the first round, we planned to have all the community members, two and a half thousand people, walk around and vote through the app. In addition, we planned for eighty judges to go around and evaluate the projects. The community and the judges would have an equally weighted vote. So if all community members had 10,000 experience points, then 10,000 points would be distributed equally amongst eighty judges. Our goal was to balance curation with community voice.
In the second round, we had celebrity judges but they didn’t actually decide the final winners. They gave out a “Judge’s Trophy” for their favorite project. The prize included $1,000, a cool jacket, and an actual trophy. The finalists were determined by the community.
The DAO worked for the second round but not the first. In the first round, the DAO wasn’t working because hackers submitted their project past the deadline or incorrectly which meant judges and community members couldn’t vote for those projects. Since we couldn’t be sure every project was available for people to vote on, we scrapped the community voting and only judges got to vote in the first round. There were only eighty judges, so we could ensure that all the teams would be evaluated four times.
We divided the judges into groups and each group judged eight to ten teams, and then submitted up to five of them. It went well but of course we ended up with some ties. So we had twenty-four teams in the final round rather than twenty. In the final round, there were two tracks for winners: open and impact. Open included any kind of hack, and the impact track were projects that met one of the guidelines for the UN sustainability initiatives. Five winners were selected by the community for each track.
There were up to sixteen possible winners out of twenty-four (six Judge’s Trophy, five open, and five impact) although there was some overlap. One thing I really wish is that we did a better job establishing the submission and judging process and communicating it out to the community. We’re working on a post-mortem now and are excited to share our learnings with the community so we can all do better going forward!
It was the talk of the town, you might say. Flash loans are a cool, new thing that we haven’t seen much of before except for arbitrage. This is the first time that we’ve seen a flash loan be very actively and aggressively used to drain funds. Because it happened during ETHDenver, when there was a huge amount of hackers in one place, the timing seemed so perfect that everybody assumed it had to be someone there but nobody knew who.
My main highlight is ETH 2.0. It is just so important for the crypto community and for the Ethereum community. Specifically with how the team is approaching launch. Most other protocols just have incentivized testnets; they don’t have anything live, with millions of users. They don’t have tens of billions of dollars of value at stake. So it’s really valuable to learn about the attention and meticulous process behind ETH 2.0 and how the team is learning from their earlier missteps.
Specifically, when Ethereum launched, they wanted to have multiple clients, but only the Geth client was really feature complete. The Parity client was not. It was trying to catch up. For the next five years, it was always catching up, which is not ideal. Ideally, we’d want to see two equal clients that the community can choose between.
One of the considerations the ETH team is making now is what number of clients are they comfortable with, that are in a good place, that they can launch with to avoid their previous fate.
ETH 2.0 also wants to implement correlated slashing. This means that if you commit a slashable offense at the same time as other people, you will be punished more heavily than if it was uncorrelated. The ETH 2.0 team wants to avoid people colluding or using the same infrastructure or the same setup. If there’s a bug that takes out one region, and 50% of the network goes down with it, that would be bad. They don’t want that. They want to incentivize people to use different cloud providers, bare metal setups, clients, configurations, and so on, specifically to create a dynamic and resilient environment.
There is something I’m grappling with personally and professionally. I am a perfectionist. So when all the problems started happening with the judging, I was getting down on myself and others. And John Paller, the lead organizer, gave a really important lens on how to consider the experience. He said, “There’s a difference between seeking perfection and seeking excellence. Seeking perfection comes from fear and anxiety and seeking excellence comes from hope.”
That had a big impact on me. I still want to find a place where everyone can be happy with the outcome and there are the least amount of mistakes. But I know I can discern a difference and recognize that people were really happy at ETHDenver. It was truly magical. So often, at crypto conferences or hackathons, people aren’t happy. They are working, focused, maybe satisfied, but I don’t think it would be fair to call them happy. And it’s not that there is less substance at ETHDenver. The best hacks are made there. The best coders attend. It isn’t low stakes at all.
The experience was just so good. There’s so much culture, music, art, games, community, conversation, openness, and acceptance that it seemed to me like people are genuinely happy. And that’s always so wonderful to see and why I am excited to be part of the ETHDenver community.
Bison Trails is an Infrastructure-as-a-Service company, based in New York City, specifically focused on blockchain participation. We’ve built a platform for anyone who wants to participate in new chains effortlessly (e.g. by running Cosmos Validators, Tezos Bakers, and Libra Validators, etc.)—without having to invest time and resources into developing any of the engineering, protocol, dev ops, or security competencies in-house. Our goal is for the entire blockchain ecosystem to flourish by providing robust infrastructure for the pioneers of tomorrow.