The Evolution of Dharma, 2017 — Present
Last week, we rolled out a new version of Dharma — a version that I believe is the most authentic for Dharma and useful for the world.
I wanted to take time to reflect publicly on the journey that got us here, and the lessons we learned along the way. I’ll also discuss how Dharma’s approach to open source has changed, and about some of the the challenges we’ve encountered at the application and protocol levels. You’ll also get a sense of what it’s like to work in an engineering org that has a protocol layer.
Dharma the Protocol
Nadav Hollander, Dharma’s founder and CEO, described the Dharma Protocol in a whitepaper published in November 2017, at a time when ICOs had raised $2bn. Nadav argued that debt use-cases (lending and borrowing) would eventually outpace equity, and had built a prototype of a peer-to-peer lending protocol during a summer at YC. He recruited some engineers — myself included — to help finish coding it and deploy the protocol to the Ethereum mainnet.
Dharma did not do a token sale, nor did it raise a large VC round during the ICO boom, at a time when platforms like EOS raised $4bn without a live product. Instead, we worked within the bounds of a traditional seed round, seeking product-market-fit for our protocol and developer libraries.
All of our code was open-source, audited by multiple third-party companies, and had thorough test-coverage. Our approach was to add developer features — such as ERC-721 token collateralization (get a loan with a Cryptokitty as collateral!) — to the protocol, and then attend conferences and hackathons to help developers use those features in the products they were building. We highlighted the trustless, open, permissionless, and generic nature of the protocol.
But by late 2018, only a few projects had successfully developed on top of our protocol, and it was clear that the products we were most excited about (e.g. the world’s first global, decentralized bank) were not going to be built anytime soon. The hype in the space was dying down, and as the price of ETH dropped from $1,000 to $600 to $300, both investor and developer interest started to dwindle. We decided to take matters into our own hands and build the consumer product that we were most excited about, on top of our own protocol.
Dharma the Product
In November, 2018, we created a Github repo called Lever, and started building a full-stack web interface for Dharma. This was a dark time for the space, and there was a lot of uncertainty and frustration. In December, a video circulated of Fred Wilson (a longtime investor in the space) ripping into Ethereum’s management, while the price of ETH fell to $80. We quietly deprecated the public protocol repo, as we focused on Lever.
After two months of working privately, we posted a landing page for a margin-trading product built on Dharma Protocol. It was called Dharma Lever. We added a waiting list and quickly attracted a few thousand emails.
Our team was thrilled to finally have real users and real stakes. Could the protocol we built be the foundation for a real business?
Our battle cry became “Dharma is the easiest place to lend and borrow crypto-currencies,” and we took simplicity and elegance to heart. We hired the best UI designer in the space (Matt Vernon from Sydney, Australia). We launched with only ETH and USDC — neglecting 50+ currencies that the core protocol supported. No MetaMask, no private keys or recovery codes; we were out to prove that through simplicity, the crypto experience was better than traditional finance.
Our engineering architecture was now divided into three layers — frontend (ReactJS), backend (NodeJS), and blockchain (Ethereum). It felt like the architecture of the future. One day every web company could have a blockchain layer.
After launching our private beta, our community helped popularize memes like #dopefi (a play on #defi) to describe the experience. Everyone was loving what we had built, and the space was lightening up. We chose a hugely ambitious goal for the public launch; to get $1 million into the system by the end of April. We surpassed it within 24 hours of launch. Within the week, we reached $8 million.
At this point, we knew decentralized finance was real and we were energized by the potential of what we — and others around us — had built. We decided to go all in on product, and rebranded Dharma Lever to be, simply, Dharma.
Protocol Bugs and Bounty Programs
It’s hard to imagine onboarding millions to your product and asking them to install a third party chrome extension. So instead of requiring MetaMask, we gave each of our users a unique address, and forwarded funds from there into Dharma Protocol. To achieve this, we created a new contract for every Dharma user with the ability to relay funds (we call these “Relay Contracts”). Those contracts didn’t do anything except wrap/unwrap ETH and forward funds to and from Dharma Protocol.
One day, upon entering the office at Dharma, Nadav called me into a room to gravely announce that a third-party white-hat bug-bounty hunter had discovered a vulnerability in our relay contracts.
Contract vulnerabilities are the biggest fear of a crypto company. Businesses will rise and fall overnight because of the rate at which funds can flow into and out of contracts. You cannot, under any circumstances, tolerate bugs in smart contracts.
We quickly diagnosed the issue. It appeared that there was a way, in specific situations, to grief users by replaying transactions — which would only be problematic for withdrawals. To “grief” a protocol means to abuse its mechanics in a way that irritates users, but doesn’t cause users to lose funds.
Here’s a scenario in which the grief would occur:
- Alice deposits an amount, let’s say $10, into their relay contract.
- Before the $10 is matched with a loan, Alice withdraws some amount less than half of the total balance, let’s say $5, leaving $5 in the relay contract. Replay attacks have to replicate the exact transaction, so if Alice withdraws more than half of the total balance, her relay contract is not susceptible to replay attacks.
- An attacker replays the withdraw transaction, so that Alice’s relay contract sends her another $5 to the exact same address from step 2. Alice didn’t want this, and is annoyed, but the funds remain in her control.
Out of the thousands of relay contracts that we created for our users, we only discovered a single case where a replay attack was possible, and the hacker had found it by arbitrarily replaying many transactions in the system.
Even though we considered the risk to be fairly minimal, we decided that even the minimal risk was too important to ignore, and immediately launched a process to migrate all of the relay contracts to new and improved contracts. It was an expensive, arduous process, and we learned a lot from it. In the end, no users were ever vulnerable to a loss of funds.
I want to thank Naumov Lab (http://naumovlab.com) for their work in identifying this bug. We worked within the guidelines of our bug bounty program to reward them for finding the bug, but they were also patient as we attempted to understand what was happening in the system.
Smart Contract researchers like Naumov have done tremendous work in keeping projects in Ethereum secure, and deserve to be recognized and remunerated appropriately.
Bugs in the Application
We built the application using modern web tools — a Postgres database to hold account information, ReactJS to render our frontend components, AWS to run our infrastructure, etc.
We moved fast in building and shipping features, knowing that the protocol was always the source of truth; funds were never at risk due to bugs in the application layer. However, we did on occasion have some bugs in the application layer — disconcerting to users because they were indistinguishable from a severe protocol bug, since some of our contracts were closed source.
During the relay contract migration mentioned in the previous section, we had a moment where our Postgres database was out of sync with the blockchain, and it caused some users not to be able to withdraw funds through the app. Obviously this was a critical bug, and we immediately set to work to fix it. But unfortunately we could see something our users couldn’t; we could distinguish between a protocol bug (which absolutely should never happen) and an application bug.
I think this separation is something that everyone would benefit from being able to perceive in crypto products, both within the company and in the community. We’ve learned that it’s better to be fully transparent on the protocol layer, and so we’re planning to open-source all smart contract code. Keeping our contracts private in our previous product iteration was a mistake.
Moving onto Compound
Even in the very early days of Dharma, the idea that excited our team the most was creating the world’s first borderless bank. Our lending protocol was an implementation detail towards that vision.
Compound has done great work to provide a simple and elegant system for lending and borrowing pooled funds. This turned out to be a model that works well. While it’s true that Dharma was formerly competing with Compound Protocol on rates and liquidity, we were never competing in vision. We’re now more focused than ever on bringing DeFi to the mainstream, using our team’s unique strengths.
Towards that end, we’ve built an application, currently in beta, that has a scalable and reliable backend, and a beautiful frontend. It’s something that everyone in the world can use to save US Dollars — all they need is an internet connection. We have dedicated engineers specializing in frontend, backend, SRE, and smart contract protocols to make this a world-class finance product.
Ethereum will become more useful as protocol companies like Dharma and Compound become more collaborative. Although this has always been a conviction in the space, until now we haven’t seen much of it. I’m ready for our focus to turn towards providing value to the mainstream. That’s what we always wanted to do, and we look forward to serving everyone in this mission.
Graeme Boy is the Director of Engineering at Dharma.
