What it was like to win a Global Defi Hackathon at 17 years old

Myles Sherman
11 min readMar 5, 2021

What do dark alleys at night and the internet have in common?

Other than the fact that they’re both really good at sheltering cats, most people would agree that any sort of transaction taking place in both these places has a high element of risk.

The Ethereum Global MarketMake hackathon is one of the world’s largest decentralized finance gatherings every year. Moderated by EthGlobal, teams have one month to come up with and execute a real world application to various blockchain and Ethereum projects.

Hundreds of teams are able to join but the maximum team size is only five. That means that you are constrained in both time and manpower from the second the competition launches in early February. Each team is competing for specific cash and token prizes given by a series of sponsors. The sponsors consist of various defi projects that are already established in the field.

This year’s sponsors were as follows:

AAVE — An open source protocol that gives out interest to users depositing assets on their sites as well as lends out those deposited assets

ENS — The most widely integrated blockchain naming standard that allows users with wallets to skip long public keys and rather attach custom usernames

1Inch — One of the world’s biggest aggregated decentralized exchanges that allows anyone to swap between cryptocurrencies quickly

AAVEgotchi — A fun crypto-collectable that lives on the Ethereum blockchain and accelerates the blockchain gaming sphere

Chainlink — Literally brings real data from the real world onto the blockchain so that logic and mathematics can dictate other Defi applications (Dapps)

Matic — Helps to scale the current siege of Dapps on a side chain that allows for a huge increase in transactions per second while lowering transaction fees

The Graph — Stores data on a defi building platform that allows anyone to view blockchains called subgraphs without downloading large files

UMA — Allows developers to create synthetic assets using their platform meaning you don’t have to be looking at asset charts all day long

Some of these companies are literally worth billions of dollars and participants could interact with their teams throughout the hackathon via discord.

As a group of teenagers with minimal experience in both the frontend/backend of defi, we had a lot steeper of a hill to climb.

Going into the hackathon, I knew that we were given the same resources and time as everyone else. Although we had a long path, our hopes were high and we began to research.

My team and I spent the first five days of the challenge researching into specific demographics and feasibility of building out a blockchain project. We figured out that around one hundred thousand blockchain developers need a space to interact with and pay for each others’ skills.

We also embraced the original purpose of the hackathon which was to create a decentralized project. We knew that if we could create a completely decentralized and secure job site for blockchain developers, we could scale the project later on after the hackathon and open it up to jobs as a whole.

I found that the internet is one of the worst places to look for a job:

  1. People could just lie about job availability
  2. People could lie about their skills without any consequences
  3. People could simply not pay or not do the work
  4. Nothing is free! All the job sites were taking large cuts as premiums for “facilitating transactions”
  5. Customer service is the worst. No one likes to sit on hold just for a generic, unhelpful response to being scammed like “I’m sorry that happened” or “We’ll look into it”

I wanted to create something new that skipped the customer service and the scamming as a whole.

This combined with a minimal fee system would attract anyone who was looking to avoid anything scammy. On top of all that, I was building off of one of the safest and newest technologies up to date: blockchain. My team and I were off our minds psyched to start researching and building our project.

The first thing we did was set up a fool proof communications system between our team. Because of the pandemic, we were unable to meet in person throughout this entire experience.

We knew that the main mindset that would drive our success was team chemistry as well as solid 24–7 communication. From previous hackathons, I had picked up some useful tips to glue us together.

Discord is underrated. You can create task-specific channels as well as have video and audio meetings. Discord was the perfect place for us to share daily updates as well as have our daily 9pm meetings.

Having daily update meetings is by far the most important aspect of a strong team. When given a workload as big as we had, we knew we had to do it together. Have you ever been given a task that was too easy for the amount of time you had so you were just sitting around waiting to be assigned something new? Yeah, well we didn’t have that. In our daily meetings, we would discuss our research, progress, as well as ASK FOR HELP. We were relentless when delegating work and we all had a bias-toward-action mindset. Since we knew what the opportunity was as well as passionate about the topic, we were all wildly motivated and we were basically crawling over each other to do “work” during these meetings.

Having a backup mode of communication is key. A lot of the time, you’ll get that teammate or two that is MIA for a couple of days. By exchanging phone numbers as well as setting up a group chat, we knew we could always reach each other no matter the circumstance. (Because, come on, what teenager doesn’t have their phone with them around the clock?)

Next we started to come up with a generic blueprint/explanation of what we were building. When given a month to create something, you need to keep track of your thoughts. We decided to create version one of our whitepaper right off the bat.

This would allow us to not only have a good understanding of our project, but we could also use the whitepaper when actually building out our code/smart contracts.

Within our whitepaper, I came up with a system that combined game theory and blockchain to completely destroy any logical motivations/incentives for anyone to commit any sort of payment scams.

A “payment scam” is when one side of a transaction, buyer or seller, does not fulfill their end of the deal while the other side does.

Payment scams makeup 32.8% of all scams over the internet. Whether it is an email stating they’ll give you a free iPad for some information or someone on Ebay gives a counterfeit item, all of us at some point have fallen victim to these scams.

In the whitepaper, we discuss the current status quo that most large companies today use to protect their customers from this sort of scam. Written is:

“As of 2021, various large commerce companies such as Ebay and Amazon use a two pronged system for scam protection. The status quo currently relies solely on third party options that often include a team of unmotivated employees who take long processing periods for simple requests and a report button often left unattended to.”

The two pronged approach of a reimbursement team and a report button don’t get the job done well enough. Most of the time, victims will find themselves waiting days, weeks, or even months for adequate reimbursement or even a response.

This is because the large companies backing the system have way too many customers to have an unscalable system. Hiring a team is extremely expensive and oftentimes, the employees on those teams are not motivated enough to be efficient because they’re stuck in a cubicle answering hundreds of complaining people a day.

The system needs to change.

Our solution doesn’t do that. In fact, we don’t even change the system at all; we got rid of it. Here’s how it works

.

Escrow

First, we have to introduce the concept of escrow. Escrow is the use of a third party when transacting. In the case of cryptocurrencies, escrow is not controlled by anyone rather it is dictated by the smart contract or “rules” of the system.

When a contract between a buyer and seller is agreed upon, the balances of the two users are checked and corrected. There are two cases were the contract will not be put in place:

Smart contract sees employer does not have adequate (agreed upon) funds plus an additional 3.333%

Employee does not have 6.667% of the agreed upon funds in their wallet

The three and six percent are what we like to call an “agreement fee”. In our protocol, both users are tasked with answering a simple question during the final days of their contract:

Yes or No: Did the Employee/Seller meet the expectations of the contract?

If the two sides of the contract were ever to have conflicting answers to this question, the three and six percent will be lost in escrow.

Incentive

I created a system that is backed by game theory that, no matter the circumstance, it always makes sense for both the employer and employee to tell the truth. With just a simple “yes” or “no” question, we can guarantee no one will lie so long as they operate based on logic. This means that no random scammer will try to phish for money out of you yet there is a possibility that someone with a personal grudge can financially hurt the opposition so long as they are willing to be financially hurt in response.

Below are the payment matrices used to create the Contract smart contract. As you can see, in no situation are either parties ever incentivized to not fulfill their end of the contract.

Inter-party Communication

Before a contract is agreed upon and the employee starts the work, the two parties must negotiate a contract. This contract has all of the terms, the time stamps, and the outcomes agreed upon by both sides.

Before the contract is even decided on, both parties have access to speak to each other to negotiate. However, once a contract is agreed upon all communication is cut off between the two sides.

I made this decision because if the two parties could communicate during the work, then there could be complications with the contract as well as the scenario where an employee says to the employer, “I am not doing the work but if you ever want to see your money (103.333%) again, you have to say I did”.

When the communication is cut off, the last thing the employer hears from the employee (in a fully digital scenario) is that they agreed to the contract (which the employer created with them).

Building the actual project took a ton of planning. From the get go we were delegating the front end code and creating visuals in Figma to plan out what each page, button, and title would be.

We decided to make a rather simple website as we didn’t really need one hundred different pages for our various systems. Also, if this were to be completely open source, we wanted it to be relatively small in size and easily downloadable.

Developing the HTML took the majority of the month that we had for the hackathon so we were forced to split up our team into two different areas.

The front end developers would work on the design, code, and connectivity between the site and the smart contract while the back end developers would learn Solidity and create a smart contract.

To start off the smart contract, the first thing we needed to do was define our escrow. With this, we would be able to send all funds from the employee and employer to a wallet that the code could control.

Within this first part of the escrow function, the addresses (or wallets) corresponding to the buyer (employer) and seller (employee) are set up. This way, funds can be extracted from their accounts and put into escrow upon contract agreement.

Next, the escrow function is set up (keep in mind, still inside “contract Escrow”) and the buyer/seller variables are connected to their corresponding wallet.

Then, we get to the most important parts of the smart contract where we set up the outputs to the “Yes” or “No” question that is asked at the ending days of a contract. To confirm the fulfillment of a contract, we set it up so that each side must “accept” it. It’s really just a simple if/then statement that checks the balance given by the employer as well as inputs the answer of the employee.

Next we set up what a disagreement looks like. Within a disagreement, we “burn” or “throw” the funds so that they can never be seen again just like in our whitepaper.

Finally, we set up the “cancel” option which is really just both sides of the party inputting “no”.

Overall, I think this experience was and still is incredible. To be coding my own website application before I’ve even left high school and to win a prize for it amongst experts in the field is really mind blowing. I give a lot of credit to my team and our chemistry as throughout the entire process, we were simply motivated.

During the hackathon, we had a ton of trouble connecting this smart contract with our front end. For some reason, the integration between the two just wouldn’t happen. However, as a team we have been developing this even more after the hackathon. We have gotten interest from various different people in the De-Fi field who are interested in our project and who would be willing to help us out as we continue on.

--

--