Jesse Walden of Variant Fund, and Robert Leshner of Compound explain all of the problems associated with the decentralizing process in terms of governance and compliance, pulling from their own lessons and their commentary on other projects. We cover:
- Why projects must start with some level of centralization
- How projects can both monetize and not put their code at risk of being forked
- How they can decentralize while also maintaining security, especially for composable DeFi projects that may become vulnerable as new technology and new protocols are introduced
- How and when to distribute the token so as not to attract only speculators and also not trip regulatory wires
- How Compound’s current governance works, how it is decentralizing, why they decided to use a governance token, and what Compound (the company) will do after full decentralization
- Why open-sourced projects are still able to extract profits, even after a fork
- Whether or not teams should have admin keys, such as what was used in response to the bZx attacks
- Whether or not projects should be upgrade-able
- What Block.One, which raised $4 billion in an ICO, did right to only pay a $24 million fine to the SEC
Take our survey!
Tell us what would you like to see from Unchained! Please take a moment to fill out the survey to let us know what you’d like from the show: surveymonkey.com/r/unchained2020.
Crypto.com has offered our survey respondents a chance to win a metal MCO Visa card — and Crypto.com will stake these cards indefinitely! Ten lucky winners will enjoy card benefits including free Spotify, free Netflix and 3% back on all spending, and they’ll earn extra interest on their crypto deposit and more! Thanks, Crypto.com! Again, take the survey now: surveymonkey.com/r/unchained2020.
Unchained is hiring!
Come work at Unchained! We have an opening for a remote editorial assistant — find out more about the gig and apply here: https://unchainedpodcast.com/seeking-remote-editorial-assistant/
Thank you to our sponsors!
Kelman Law: https://crypto.law
Jesse Walden: https://twitter.com/jessewldn
Robert Leshner: https://www.linkedin.com/in/rleshner/
A16z Crypto startup school: https://a16z.com/crypto-startup-school/
Progressive Decentralization playbook: https://jessewalden.com/progressive-decentralization-a-playbook-for-building-crypto-applications/
What recent moves by the SEC say about mutability when it comes to crypto networks: https://a16z.com/2019/10/22/mutability-sec-recent-cases/
Compound’s $COMP token: https://medium.com/compound-finance/compound-governance-5531f524cf68
More on Compound’s governance token: https://www.coindesk.com/compound-extends-defi-ethos-to-itself-launches-governance-token
Unchained discussion about bZx attacks: https://unchainedpodcast.com/the-bzx-attacks-unethical-or-illegal-2-experts-weigh-in/
Eric Wall tweet storm on admin keys: https://twitter.com/ercwl/status/1229198599264907264?s=20
tBTC shutting down: https://twitter.com/keep_project/status/1262483526437556228
Unchained interview about tBTC in which Matt Luongo explains the admin key: https://unchainedpodcast.com/tbtc-what-happens-when-the-most-liquid-crypto-asset-hits-defi/
Is the SEC trying to kill the SAFT? https://www.coindesk.com/with-kik-and-telegram-cases-the-sec-tries-to-kill-the-saft
Hi, everyone. Welcome to Unchained. Your no-hype resource for all things crypto. I’m your host, Laura Shin. Before we begin, a couple notes. First, I’m doing another survey to find out what you guys want from the podcasts and how I can make them better. Last year, we heard you loud and clear on the news front and so have begun including a weekly news recap at the end of every Unconfirmed. This year, what would you like to see from Unchained? Please take a moment to fill out the survey to let us know what you’d like from the show. The link is in the show notes or you can just go to Surveymonkey.com/r/unchained2020. Again, that’s Surveymonkey.com/r/unchained2020. And guess what, Crypto.com has offered our survey respondents a chance to win a metal MCO Visa card and Cypto.com will stake these cards indefinitely. Ten lucky winners will enjoy card benefits including free Spotify, free Netflix, and three percent back on all spending, and they’ll earn extra interests on their Crypto deposits and more. Thanks, Crypto.com. Again, take the survey now. Surveymonkey.com/r/unchained2020. That’s Surveymonkey.com/r/unchained2020.
One other thing, Unchained is hiring. I am looking for a remote editorial assistant to start working later this summer, as one of my staff is leaving to go to grad school. This role handles numerous editorial tasks from booking to proofreading to social media and deals with everything from the show itself to the show notes to the newsletter. If you love crypto and have journalism experience, get in touch. I have a link to the job posting in the show notes and the listing is also available on my site and there it explains what you should send in and how.
Did you invest in a crypto project ICO that promised innovation but delivered nothing? You might have recourse, but statues of limitations are quickly approaching. Kelman PLLC, run by some of the first lawyers to enter the crypto space back in 2013, is here to help.
In response to the challenging times, Crypto.com is waving the 3.5 percent credit card fee for all crypto purchases for the next three months. Download the Crypto.com app today. Download the Crypto.com App today.
The Stellar network connects your business to the global financial infrastructure whether you’re looking to power a payment application or issue digital assets like stablecoins or digital dollars. Stellar is easy to learn and fast to implement.
Today’s topic is how projects should decentralize. Here to discuss are Jesse Walden, founder of Variant and Robert Leshner, founder of Compound. Welcome, Robert and Jesse.
I think the topic for today’s discussion can be centered around one basic problem, which is the fact that when teams are building decentralized projects they start out as a team, which means that the project will start out as centralized so then the question is how do they eventually decentralize? We’ve seen a number of ways that various teams have tried to solve this conundrum but before we get into that, let’s dive into your background so people have an understanding of where you’re coming from on this topic. Jesse, do you want to start?
Yeah. Sure. I guess I first got involved with crypto as a founder of a project called Media Chain back in 2014, and our goal was to build what we called sort of a universal media library. So kind of like bitcoin aims to be a universal store of value, we wanted to do the same for a different type of digital asset. Instead of a financial asset we wanted to focus on images, songs, and videos or media assets and make them discoverable anywhere they were distributed on the internet. That project was acquired by Spotify in 2017 where I went on to lead blockchain R&D, and I was there throughout the sort of crazy run up in the markets in 2017 and then left to join Andrews & Horowitz, where we spun out a dedicated crypto fund and I worked on the investment team for the last two-and-a-half years.
Now, at Variant, I’m planning to work with entrepreneurs at the earliest stages in their journey and help them solve problems like the question of how to decentralize.
Robert, you were on Unchained before and you did talk about your background then but for people who didn’t listen to that episode, especially because it was a while back, how about you? Let us know what your background is in crypto and before.
Yeah. So I started my career in the traditional finance space. I was an interest rate economist and I was focused on traditional financial markets. I started Compound in 2017 to create interest rate markets for crypto assets. When I was on the show last time, I think I probably was forward-looking about the ideals of decentralization but Compound as a protocol was in a very early phase where it was still being worked on by a core team that was taking it from the very early stages of being an idea into the first working prototypes of being an application that the community can start to use.
Since that point, we’ve seen widespread growth in the compound protocol. It manages hundreds of millions of dollars of assets and it provides interest rates for many different applications in the space that are looking to earn an interest rate on the crypto that their application hold and provide additional functionality to decentralized applications.
So now let’s dive into the details of our topic and talk about the difficulties of building a decentralized project. Jesse, you wrote about this in your progressive decentralization play book. So how would you describe the challenge here?
Yeah. You touched on it earlier in saying that there’s sort of a dissonance between building a product and then the sort of ultimate goal or crypto networks, which is to become sufficiently decentralized and I think it’s important for sort of addressing the question of why crypto project aimed to be decentralized in the first place and from there sort of back out how to get there.
So I guess maybe to start, the reason for decentralization in many of these projects is that decentralization is sort of a proxy for trust. You can trust that a crypto network is going to behave as specified if there’s many sort of independent parties running code on independent machines and that’s sort of what’s at the core of networks like bitcoin and Ethereum.
As the community starts to develop sort of more complex applications, there tends to be a shift from deterministic protocols or protocols that conduct sort of verifiable computation to protocols or applications that require more subjective inputs and human decision making. For those types of applications, Compound being one of them, there needs to be a sense of sort of community ownership over how those decisions get made. Community ownership is important because it allows for the community to ensure that their sort of interests are being reflected in the decision making that goes on in these applications. That’s very different from traditional internet platforms, which are owned by investors and shareholders, whose interests are not always aligned with the interests of end users.
So that’s all to say decentralization matters because it’s a way for the community of users who build on top of these platforms or use the applications built on top of these platforms to feel as if the platform is aligned with their own interests. So that’s why decentralization matters and then I would argue that the path to getting there isn’t an immediate one but rather sort of a step by step process and breaking it out into these three steps isn’t obvious to everyone. There are a lot of projects, especially back in the sort of early days of crypto that strive for decentralization out of the gate because it offers the benefits I just described.
But to start, I would argue that teams really need to think about first building a product that people actually want. The goal isn’t very different from that of a traditional startup because without a product that people want, you don’t really have much to work with. You probably will have a hard time building a community that ultimately wants to sort of take control or build on top of what it is that you’re building.
So the first step is finding product market fit, building a product that people want and thereafter, building a community around that product such that you can get to the third and final step, which is turning ownership over to the community.
I actually just for a moment want to step back to what you were saying about the differences between a decentralized protocol versus a decentralized application. So you did say in your playbook that blockchain protocols…I’m going to quote you here. That they require a sufficient decentralization from inception in order to be useful. So why is there that distinction again? You might have explained it briefly but I just want to explore that a bit further.
Yeah. So my playbook really sort of aims to speak to entrepreneurs and founders building at the application layer and that means applications built on top of smart contract platforms like Ethereum. At the lower layers in the stack, so layers like Ethereum or other smart contract platforms, arguably, you need decentralization out of the gate in order for the platform to be useful. That is because platforms like Ethereum, the promise of the platform is that they do computation that can be trusted. Again, that trust derives from a decentralized network of physical machines that are running all over the world that result in this single virtual machine that developers can build on top of knowing that the code that they write and deploy to the platform is going to execute as specified because if one machine goes rogue there’s many other machines that will sort of behave correctly and ensure that the application that a developer writes continues to run as specified.
So at layer one you sort of need decentralization and those many machines running the network to get those trust guarantees that make the platform usable by developers who need to build applications or who need that trust in order to build useful applications like compound.
So earlier you did go over the stages of decentralization starting with product market fit and also going into community participation and then eventually reaching the stage of sufficient decentralization. I was curious to know about some of the ways that teams are moving along these stages. For instance, one of the ones that you mentioned in your playbook was something called Calvin versioning. I just wanted you to maybe kind of describe some of the ways that teams are trying to move from stage to stage.
Yeah. Well, I mean I think Robert is probably the best person to answer this question because he’s been living it over the past couple of years with Compound, and he can give you his own experience. Maybe before I turn it over to Robert to answer that, I would just note that recently Reddit sort of made a play in the crypto space that I think validates the hypothesis of this playbook, which is they just announced community currencies and so a couple of sub-Reddits, I think one is called Our Fortnite VR, which is the bit Fortnite sub-Reddit and then Our Crypto Currency are both getting their own sub-Reddit currencies. I think bricks and moons respectively. What’s interesting is those cryptocurrencies did not launch in a vacuum. They launched after Reddit built product features that they felt had product market fit with those communities, namely the ability to tip and sort of access premium features in each of these sub-Reddits respectively using those currencies. So Reddit, I would argue, sort of built a product that they felt had early signs of product market fit.
Of course, there was sort of a robust community in each of these sub-Reddits already so there was a good amount of community participation and then at the time that they actually launch these community currencies they effectively are now in the process of turning ownership of the community over to the contributors directly through this token. So I think that’s a very good example of a sort of high profile platform executing this playbook step by step. Robert’s been doing a similar thing and I think can probably speak best to how he’s been thinking about it.
Actually, Robert, before you start I just wanted to ask one more thing which either of you can answer. So Reddit and Kik are somewhat similar in that both of them did have these communities to start with and then introduced a token. Is the main difference simply that Kik had an ICO and that Reddit didn’t or what would you say is the distinction there? Because obviously as we know now, the SEC has gone after Kik and they’re still in a court battle.
Yeah. I think that’s a big one. I think tons of projects, not just Kick, they started out trying to achieve decentralization through a token sale. That is sort of seeding a community by issuing a token and distributing it in exchange for funding. I think what we’ve learned is not only is that a way to potentially trip regulatory wires, it can also be a way to sort of invite a community of speculators rather than a community of real contributors or people participating in a productive way.
So my view is that if you start product first and build validation around product market fit and you sort of naturally move from there to a sort of active community whom you can then confer ownership to and that’s a better way to sort of build a community of engaged participants who are excited to sort of inherit ownership of the platform and sort of take it over from there and that’s a healthier way to grow a community from inception rather than the other way around.
All right. Robert, why don’t you talk about Compound and how you guys are trying to decentralize.
Yeah. So I think this question starts with why decentralized in the first place. Why build an application using a blockchain and smart contracts when you can build it alternatively using a database and by acting as a centralized business. I think there’s an important difference because you could build a compound-like product not using smart contracts. There’s a number of companies out there that have the same types of financial use cases that aren’t built on a blockchain and aren’t built using smart contracts.
I think long-term the biggest advantage of decentralization is that it allows an application to run forever, to be censorship resistant, to be open to users anywhere and to be able to be improved and expanded on by the community. But obviously starting there is extremely hard. Launching a decentralized application is difficult from a coordination standpoint. Just building it is hard. As Jesse touched on earlier with the decentralization playbook, it’s overkill in a lot of ways. Unless there’s a reason for an application to run forever it doesn’t need to be decentralized. When there’s no users it doesn’t matter whether it’s fully centralized or fully decentralized.
So at Compound we’ve always viewed a decentralized product as being the end goal. That it can be the very best version of the product possible if it’s fully decentralized, but we started with a lot of components being centralized, the development of Compound and the control of it and the governance decisions. So in our experience what we’ve done is over time, step by step by step and month by month, we’ve tried to shed as much responsibility as possible to the point where we’re now in a position where the protocol is actually run by a governance system that’s coordinated through a governance token instead of through a centralized business and the protocol is upgraded and improved through a governance process.
So we’ve had a lot of steps and we can…this interview drill into different steps that we’ve experienced but it’s really been this gradual transition where we’ve iterated into removing as much responsibility as we can over time.
And the way that you have decided to more progressively decentralize is to now introduce a governance token which has the ticker Comp. Why did you decide to go that route?
So there as really two guiding principles in creating a governance token to run the protocol. The first one was to remove our team as a point of failure. You can think of this governance token in the aggregate as like a giant multisig that’s required to make changes to the protocol. I’ll be very honest when I say I don’t actually like having administrative control over something. I don’t like worrying that someone’s going to come up to me on the street with a wrench and try to steal a key. Having a huge community share responsibility for approving changes to a protocol prevents, right out of the gate, a huge amount of accidental or malicious errors that can occur.
The second reason is it allows a much wider audience to actually suggest changes. A centralized team only has so much creative throughput and engineering capacity. If it was left to us, we can only make one or two changes to the protocol in any given month, week, quarter, year, etcetera. By rolling out governance to a much larger audience and designing it in such a way that the community can actually suggest and implement changes themselves it allows a much wider surface area for creativity and improvements. We’re already seeing stakeholders in the community actually implement and merge in changes to the protocol itself.
So I view this as the tools required to allow it to run forever and to continuously upgrade now that there’s a lot of applications and users that care about seeing the protocol succeed.
And one other thing actually that I just wanted to ask about because it almost seems to go in the opposite direction of your arguments is that, as we all know, recently there was a hack of the LendfMe protocol and the team behind that, dForce, appears to a copy of the original Compound code and in a discussion that I had on Unchained about that attack, some people were saying essentially that the Compound team was really up on security and that was why you had prevented something similar happening on Compound because essentially certain technical decisions that the dForce team had taken is what enabled that attack. So in that sense it almost seems like you were able to protect yourselves because you are still somewhat centralized. Would you agree with that or what’s your take on it?
Yeah. That’s a great question and it’s one of the most important trade-offs as you start to decentralize and start to hand off responsibility for the community. So I do think that because our team has historically spent so much effort, time, and money focused on security that we were able to prevent something negative from happening. We now have a responsibility of teaching and handing off those expectations to the community and aligning the incentives such that the community that winds up taking over the protocol demands the same rigor before a change is implemented. I’m speaking personally as an individual not as somebody at Compound.
When I vote my Comp tokens the first thing I look for is has the code been audited and peer reviewed and is it safe or does it not make any changes to the code of the protocol at all and it’s just changing a parameter doesn’t need to be peer reviewed and audited in the same way. My first decision as a token holder on whether or not to approve a change does come down to security. I hope and expect that over time the community starts to enforce the exact same standards as they vote on upgrades to Compound.
Yeah. There’s this concept, it’s called Linus’s Law, which is the idea that given enough eyeballs all bugs are shallow. So given that Compound’s now in this mode of sort of open development you would assume that it’s not just the eyeballs of the core team but the eyeballs of all those who have a say in how Compound moves forward when reviewing any proposal made and presumably the more eyeballs the better in terms of security.
Yeah. Something that blew my mind a little bit about that story is that that attack vector was written about the previous summer before the attack happens. So it was widely known so you would have thought the team would have by then absorbed the lesson and known to not allow ERC77 tokens on their contracts. But anyway, the other thing that is remarkable is that it takes somebody that long to exploit it. But anyway, just to go back, I also wanted to ask you, Robert, so when you guys were deciding for Compound to further decentralize, what metrics were you looking at to say to yourselves, okay, this is now the time to take this step or that step? Was it something about your developer community or the community in general? What were you looking at to make that decision?
That’s a great question. So we were looking at the protocol being in a position where it needs to harden and become more predictable for the applications built on top of it. When a team has complete centralized control they can change a product or take it in whatever direction they want. At Compound, we really think of the primary user as an application developer, another exchange or custodian or wallet or extremely creative product that someone in the community is building.
I actually look at bitcoin as in some ways the best analogy in that it’s very hardened. It’s very predictable. You know exactly what you’re getting. It’s something that’s worthy of developing on top of because you know where it’s going to be next month. We didn’t want to really harden Compound until it was at a place where we saw that there was widespread adoption. For us, a lot of the decision came down to seeing a number of applications built on top of Compound before deciding that it needed to have the sort of guarantees of decentralization.
So for us, it was really like do we want to create something more predictable and stable for the developers and that was the lens that we were using. Version one of Compound lived for about a year, and we actually saw almost no widespread adoption and developer integrations of it even though that was the goal all along. So for us, we said we need to improve the underlying protocol. We need to make changes, we need to modify the way it works and have the nimbleness of a centralized team. We put all of that into version two of Compound, which launched almost exactly one year ago today, saw the adoption, saw the integrations occurring and said to ourselves now is the time that we’re able and should and we need to think responsibly about handing off that control to the developers built on top.
So what is the system of governance in Compound today?
Well, it’s based on simplicity. So it’s actually a relatively straightforward governance mechanism. There’s a number of comp tokens. Currently, we’re testing the comp governance system with a limited number of stakeholders. There’s about 60 or 70 and the way it works is anybody that has 100 thousand comp that they’re able to vote with can propose a change to the protocol. Changes are actual executable code. It’s not a suggestion for a centralized foundation or team somewhere to go and do something. It’s actually a modification to the protocol and then over a three-day period, anybody with comp votes can say for or against. That’s the only parameters yes or no and if a minimum threshold of votes as well as a majority of votes are cast for the proposal it goes into a two day waiting period where if you don’t like the change you can opt out of being a user and after two days it’s executed and the protocol is upgraded.
We’ve seen a number of proposals. The first one was proposed by our team. We’ve had two others proposed by members of the community and all three passed were executed and modified the way that the Compound protocol operates over the last six weeks. The only additional layer that makes this even more exciting is out of the gate the governance system runs on this concept of liquid democracy and delegation. So anyone with the comp token can either participate in this governance process themselves. They can propose changes or vote on proposals or if they want to take a more passive role they can delegate their votes to anybody else in the community. This could be an expert. This could be an application. This could be a Dow. This could be Laura Shin. This could be anybody that you trust with your votes that you think is going to be more active than you.
It allows people to participate as much or as little as they want and to channel good decision making to the place where they think good decisions will be made. That’s the system in its entirety. It’s a core part of the protocol itself and so it in itself can be upgraded through governance. So if the comp token holders says, hey, we can optimize this or calibrate in some way, that’s possible. So a year from now it might work in a slightly different fashion, but the system is designed for simplicity and it’s currently live and it’s completely transparent.
So anyone out there listening to this show can actually look at the governance system of Compound, see every vote that was cast, see every vote that’s ever been delegated, see all of the participants in the ecosystem and see how it’s operating. It’s available at Compound.finance/governance, and it’s a really cool system that’s extremely transparent and liquid.
One thing I had to ask you about is that the governance proposals need to be submitted in code I believe, is that correct?
That’s correct, although we’ve created a GUI or a dashboard that makes certain proposals extremely trivial for a non-technical user. So the last proposal that was created was to change what are the properties of an asset market? How good is the asset as collateral and how does an interest rate work with it? It was as simple as dragging and dropping, so to speak, for the individual that created the proposal. There was no code written by them and they were able to go to a dashboard that’s only visible to those with enough votes to create that proposal.
Okay. I’m sure you know where I was going with that because as a non-technical person myself, I was like oh, my gosh, it gives a leg up to everybody fluent in the smart contract coding but all the noncoders are sort of shut out.
But then there’s delegation. So in spite of the fact that there’s a dashboard but separately, a nontechnical person could delegate votes to someone more technical to propose something. I think that’s a really great way to sort of scale governance because you can have people specialize in different areas that they’re strong in.
That’s exactly right.
All right. So in a moment, we’ll talk a little bit more about how Compound is decentralizing and also talk about some other projects and how they’ve gone about it but first a quick work from the sponsors who make the show possible.
The Stellar network connects people to global currencies and assets. Stellar lets you make near-instant payments in any currency with anyone, anywhere. It’s an open blockchain network that acts as payment rails for applications and institutions around the world and designed so that existing financial systems can work together on a single platform.
Transactions powered by Stellar are low-cost, transparent, and fast, saving both businesses and end-users the time and money associated with traditional payment networks. With Stellar, your business can issue digital dollars or exchange existing fiat currencies without the need for complicated smart contracts or new programming languages. Its robust documentation, toolkits, and multi-language support let you quickly integrate Stellar into your existing products and services. Learn more about Stellar and start building today at unchained.stellar.org
In response to the challenging time, Crypto.com is introducing 3 measures to help the community. First, the 3.5% credit card fee for all crypto purchases will be waived in the next 3 months. Second, you could get up to 10% back by using the MCO Visa Card on food delivery and grocery shopping at merchants like Uber Eats, McDonald’s, Domino’s Pizza, Walmart and more.
Don’t have a card yet? Buy gift cards on the Crypto.com App from merchants like Whole Foods, Safeway, Burger King, Chipotle, Papa John’s, Domino’s and more, and get 20% back on food and 10% back on groceries. This is a global offer so check out what merchants are available in your country. Download the Crypto.com app today.
Kelman Law is run by true crypto OGs and based in New York and Taiwan. They were already operating since way back in 2013. And of course, they accept crypto as payment. The founding partners are known for having drafted bills and crypto regulations submitted to US Congress, as well as working in the Mt Gox civil rehabilitation case.
If you participated in a token offering and have not been able to get back your funds then you should contact Kelman Law. Kelman Law is staffed with lawyers with expertise in ICO litigation, dispute resolution, anti-money laundering and US and international corporate structuring for crypto businesses. So if you have a dispute with an ICO project, or you just need solid legal advice related to crypto, send a message to email@example.com or just go to their website at www.kelman.law. “When you think Crypto, think Kelman.
Back to my conversation with Robert Leshner and Jesse Walden. So how have you been distributing the token?
Yeah. So in creating the distribution of the token we’ve held a couple principles and some of the pieces we’re saving for future announcements but what we’ve done is we’ve decided to allocate the tokens between those who originally built the protocol and the users of the protocol. So our goal is very soon to begin distributing over half of all tokens to the users of the protocol and we believe that by aligning those who are using the protocol on a daily basis with governance, it will lead to the best governance of the protocol.
The token’s not an economic token. There’s no cash flows associated with it. It’s purely for the purposes of governing how changes are made to the protocol and we believe that by splitting it between the original developers and the people that back the original developers and the community, it’ll lead to a long-term incentive of those who want to see us succeed, of folks that want to see it upgraded in the right ways to maintain the stability of the protocol.
So what were some of the things that you did just to make sure that the token would not run afoul of regulations?
So we believe that regulators have the right intention and that projects could learn a lot from what the regulations are and why they exist in the first place. We’ve done a number of things to try to fit into the expectations of regulators perfectly. So the first is that we waited until the governance system was fully built, the protocol was fully built and that the token could be used to participate in governance before introducing it.
For us, this meant introducing a token three years after beginning the project. The second is that these tokens aren’t used as a fundraising device. We’re not selling them. We’re creating them after the protocol is fully live, and they’re really being distributed in a non-fundraising mechanism. Lastly, we’re distributing them to users only once all of the pieces are in place so that users are able to further the decentralization of the protocol and of the token. So the end result is one in which the protocol should be able to run with community input, community management, and community control with no reliance on the original developers at all and be able to effectively run the protocol.
Just out of curiosity, once you achieve your goal and Compound is decentralized, what will happen to Compound the company?
Yeah. That’s a great question. We get asked that a lot. I see us continuing to build on top of the protocol but not building the underlying protocol itself. Similar in a lot of ways to if we were Sitoshi and we created bitcoin and then we went out and created CoinBase. We want the community to be solely responsible for the protocol itself, how it operates and to participate as just any other member of the community on a completely fair basis with no advantages. But to build some new things on top the protocol now that we’ve ushered it into existence.
Interesting. Now let’s talk generally about other ways that projects can decentralize and this sort of goes back to some of the things that Jesse outlined in the playbook but there are these other ways that projects are trying to keep their DAPs sort of alive and yet some of them also run the risk of opening the way for a competitor. So for instance, if a DAP starts charging fees, can you just outline the pros and cons of doing that and how it is that such a project could prevent any other open source project from coming in and just swooping away all their users by lowering or dropping the fees?
Yeah. I think it’s helpful to think of crypto networks as marketplaces. Bitcoin, for example, has a fee associated with every transaction and part of that fee is used to reward the miners for ordering the transaction in the blockchain. Of course, in bitcoin and Ethereum there’s also miner rewards to sort of subsidize the fee but over time those rewards are meant to diminish and at the end of the day what you’re left with is a marketplace where users pay fees and those operating the network earn those fees.
Now, anyone can come along and fork the bitcoin network or fork Ethereum and what they’re doing is they’re forking the code and sort of the state of the network but they’re not necessarily forking the community with it. When I say forking the community, that’s sort of a social idea. You need to get all the people, all the humans that use this network to move from what they view as the canonical instantiation of the bitcoin or Ethereum network to your fork and there’s a cost to doing that. The social cost of coordinating everyone is a switching cost.
The concept of switching costs is nothing new when it comes to marketplaces or networks. Uber, Airbnb, traditional web two marketplaces, the value of those marketplaces is due to the switching costs of moving to an alternative. So anyone can build a competing Airbnb service or competitor to Uber but it’s hard to get all the users that those platforms have amassed to switch over. So switching costs is what’s at the core of defensibility of web two platforms. It’s also what’s at the core of defensibility of crypto networks.
Switching costs are lower in crypto because everything is open source. You can’t take Uber’s database of drivers and fork it over to your platform. You can do that in crypto but the cost of forking is still non-zero. As I mentioned, you have to get all the people involved to move over. So that switching cost does allow for some margin of defensibility that allows for these marketplaces to extract a fee. I think hopefully that highlights the business model for crypto networks. It was actually quite similar to web two but what’s different about crypto networks is there’s this new potential to take that fee stream and distribute it directly to the users who generate the network effects of a platform, who make the platform valuable in the first place.
If you do that effectively, you reinforce the network effects because now the users have a stake in the platform and want to see it continue to grow. So I think that sort of validates the idea that these networks are marketplaces, they have a business model, which is fees, and the new thing is just defensibility is created by distributing that fee stream to the actual users and that’s very different from web two.
Yeah. Something else that we’ve kind of been talking about here and there but not really dived into is the issue of token distribution. Some of you have mentioned it in some of your answers about Reddit or about how Compound is doing it, but as you mentioned earlier, some of the ways that teams have been doing this have invited speculators so what are some of the best ways to do it in a way that’s fair but also in a way that invites real users and what is also a fair amount to allocate to the initial team and cap table?
Yeah. I mean I think it’s going to vary case by case depending on the specific application and the specific community in question. That said, I think what you don’t want to do is sell all the tokens up front to a community of folks that may not have any interest in actually using what you’ve built. So I think one of the things that Compound has done really well is first find a community of developers to build on top of the protocol, understand their needs, adapt the protocol quickly to make it more useful to them and then sort of promise a distribution of ownership over the protocol over time so that community can feel confident that the rules of the platform are not going to change from underneath them and that increases their incentive to build and contribute.
So I would encourage, again, sort of selling out to unknown community of speculators at the outset and that’s of course what happened in 2017. That said I think speculation isn’t all bad in that it does give community members a way to sort of have a stake in platform growth, and I think that’s ultimately sort of the big unlock that crypto enables. It’s sort of surfaced this latent demand that everyday internet users actually do want to own a piece of the platforms and services they interact with every day. Tokens are a way to sort of effectuate that because we can now move value in the way we move bits of information. So some degree of ownership by the community is important. It just needs to happen at the right time and sort of in response to real contribution. Again, that will depend largely on the application in question, the community’s values. So it’ll be different case by case.
Oh, even for something like the allocation to the initial team? There’s no kind of convergence around what is the proper amount?
I mean I think we’re starting to see more and more teams sort of break it down where it’s roughly 50 percent goes to core team and investors that’s sort of bootstrap the thing and 50 percent to the community and then over time, that split may shift. For example, through increased inflation over time but maybe you start sort of 50/50 and then the role of the core team sort of diminishes as the community sort of takes over and new tokens are minted. Again, this is something that the community has a say in because, for example, in Compound the community can change pretty much every aspect of the system through governance. So you can imagine that over time the community decides we need to start rewarding new contributors to the protocol as opposed to the initial team and one way to do that might be by allocating those new contributors additional tokens.
So one thing that we’ve talked about here and there is regulation, but we haven’t actually named the exact regulation that a lot of people are concerned about. I feel like this has been a theme basically since the early days of cryptocurrency even going back to the first event that we would now call an ICO, even though that term didn’t exist then, which was Master Coin. At that time even, people were concerned that the tokens would be considered securities and the way in the US that that is determined is by something called the Howie Test. Hopefully listeners know what this is by now but if you’re new, I’ll just say it’s this four-pronged test in which a token would have to meet all four prongs to be considered a security.
Those four prongs are, number one, it’s an investment of money. Two, into a common enterprise. Three, with an expectation of profits, and four, dependent on an identifiable third party. So in your work with teams, are you seeing them like actively trying to build their strategies in such a way so as not to hit the four prongs? In general, what are some of the kind of maybe rules of thumb that are emerging when it comes to thinking about the Howie Test and how it applies in these situations?
Yeah. So with Howie you need to hit all four prongs in most cases in order to trip the securities regulation, and there are good reasons those regulations exist. It’s to protect investors. What comes with that though is there’s a ton of overhead and generally it’s a lot for early-stage startups to manage being sort of a regulated security. All that sort of overhead gets in the way of building the product that people want. So that’s why I think it’s advisable for early teams to not worry about a token from the outset, especially when there is sort of a large dependence on the efforts of others, namely the efforts of the core team.
As Robert mentioned, when he started out, when others started out it’s really important that the core team is able to iterate quickly. At that point, you probably don’t want to have a token because you might then trip the Howie test. So I think the prong to really zero in on is this prong of the efforts of others. Once you can sort of demonstrate that the product or service that you’ve built is in fact owned and operated by the community and thus no longer has a dependence on others or the core team at that point. You may not be running afoul of securities regulation and you then don’t have to necessarily deal with the overhead of being a regulated security. That’s great because it means that the community can start to contribute and add value without having to file all kinds of regulatory paperwork and so on. It makes the system much more sort of internet native, and I think that’s really important for innovation to continue.
So then would you say that it seems like one of the rules of thumb is to not issue a token before the network is live like when you said early?
Definitely. Yeah. I think the right time to do it is, again, once you’ve built about product that people want demonstrated, that the community is sort of excited about it and the way to measure that is whether they’re building on top, whether they’re contributing ideas or code and at that point you might want to stand up some sort of governance process wherein you can demonstrate that the community has in fact taken over control of the project from the core team. At that point, there is no dependence on the core team. The project is, hopefully, sufficiently decentralized. At that point, there can be a token that doesn’t trip this prong on the efforts of others.
All right. So let’s talk about some of these controversial issues that have come up with how decentralized or not decentralized certain projects are. One of the ones that comes to mind is the recent BZX attacks where after the attacks occurred people were up I arms about the fact that the BZX team had an admin key which they used to pause the protocol. I guess this was a surprise to some people who thought BZX was decentralized. So what’s your take on what happened there? What would have been the appropriate action for the team to take and in that case do you think that team should have had an admin key?
I’ll jump in on this. I believe that any system should be documented and transparent. I the incongruency that you’ve highlighted is that the community didn’t know how it worked and so their expectations were shattered. I think whether or not there’s an admin key is not the important piece. It’s is it documented? Do people know how things work? Is the code available to inspect and audit and does the community have a general understanding of how it works? There’s always going to be an incredible gradient of decentralization. What you don’t want is for there to be a mismatch between how decentralized the community thinks it is and how decentralized it actually is. I think the way they responded was probably totally appropriate. Pausing the protocol when there’s a horrific loss of funds makes a lot of sense.
I think they should have prepared for that by documenting their systems more and being more transparent.
Yeah. I wholeheartedly agree with that. I think being radically transparent about the state of the system is actually a ways to build trust even if it’s the case that the system is still centralized at the outset. Again, in the early stages of a product, it’s all about finding product market fit. At that point there probably should be no pretense of decentralization. You should just focus on building a product that people want to be transparent about where control in the system exists and doing so is actually a way to build trust with the community, whereas if you obfuscate the control that exists in the system, once it’s unearthed you will very quickly sort of undermine any trust that you might have built on false pretenses.
So I think transparency is paramount and part of how you build trust towards progressively decentralizing the protocol.
This is an interesting perspective you guys have. I did see that Eric Wahl had a tweet storm on admin keys and this is also really interesting his perspective there, but he said that people tracking the DeFi teams with…sorry, that people attacking the DeFi teams with admin keys and saying that they’re no different from centralized exchanges, that that attack is “the cheap, boring, fast track to crypto Twitter wokeness.” His stance was that a DeFi key to pause or freeze a contract was not really like a centralized exchange because it would not allow the team to confiscate individual user balances. I didn’t talk to Eric but just from the way that tweets were phrased, he seemed to be saying that these types of admin keys are probably okay, at least to him. He said some admin keys have built in time delays so that users can withdraw their money from the contract before any change goes into effect such as an upgrade. So he said that that’s obviously different from a centralized exchange.
He said that some other smart contracts are opting to not have admin keys at all and instead require that if they make an upgrade that everybody move their funds to the new contracts. So what’s your take on any or all of these options and what it is that admin keys should be used for.
So this goes to the progressive decentralization. For even a single project can evolve considerably. A great example is when Compound launched, there was an admin that could make any change to any contract with no notice at will and that’s because when there’s very few users the stakes are low and you need to be flexible. Over time, there’s lots of tools that you can use to decrease the potency of an admin key. So one example is a time delay for any change where a user, as you mentioned, could opt out. That is a significant improvement in reducing the potency of an admin key.
The second is changing what an admin key can do. Reducing the ability to make a unilateral change is an improvement. So there’s all of these steps along the way. Not having an admin key at all is even better. We’re finally at the point where any change to the protocol not only requires a delay but also to go through a governance process and there’s no admin key that can make a unilateral change to the code base right now. There’s all of these steps in between and any team can, in some ways, pick and choose and mix and match how they reduce the potency of an admin key starting from a very centralized point and leading all the way to a very decentralized point. Every team has a different set of standards.
One thing that I am so curious about is as we’re seeing, these DeFi protocols are very interoperable and there’s constant change and new developments. So as the technology keeps improving we’re just going to end up with a lot of situations like the LendfMe attack where we have this new technology, the ERC777 token where when it operates with older protocols introduces a vulnerability, and I can’t imagine that that’s not going to happen time and again. Just the sheer proliferation of new DeFi protocols, it just means that it’s going to be incredibly difficult for teams to keep up to make sure that their project doesn’t interact with another project in a way that introduces vulnerability. So the idea that you would get to the point where it’s not upgradeable, what are we going to see? Just every single time there’s a new DeFi project a bunch of projects are like we’re going to shut down for two weeks or whatever and then switch everybody over. How is this all going to work?
Zooming out you’ve got to look at the big picture. What you’re describing is an ecosystem evolving through what’s called composable building blocks where each application or each DeFi protocol is a building block that other developers are building on top of and extending and sort of adding new functionality, too. The positive view of this is that’s awesome because it means developers can build way more with fewer resources because they don’t have to build everything from scratch. They can sort of build on top of the work that others have done.
The negative view is that means that there’s all these dependencies on the work that others have done and if there’s a vulnerability the whole thing can come crashing down. I tend to think that that negative outcome is certainly something that will happen. There are bugs in code but over time these protocols, the good ones will demonstrate that they’re actually resilient and trustworthy and the sort of positive sort of effects of the ecosystem composing one application into another and compounding innovation more rapidly will far outweigh the sort of short-term negative effects of bugs and creating negative dependencies that weaken the system overall.
So long-term, I think this is a much more resilient ecosystem because of the composability of these protocols and it’s a system where you can trust that what you build on top of is not going to get yanked from underneath you because all the code’s open. You can trust the code’s going to run as specified because it’s running on a decentralized computer and that’s very, very different than the sort of web two era that came before where you had a similar phenomena of developers building on top of platforms like Twitter and Facebook and Spotify and there were these rich developer ecosystems but eventually each of those platforms had admin keys and decided we’re going to change the rules, shut off our APIs and bring down this entire developer ecosystem to bring all that product innovation in-house.
So that’s the risk of having admin keys or having control by one central party. I think the long-term risk of that single point of failure is much greater to developers than the risk that the short-term there’s a bug that can ultimately be fixed over time.
Okay. But hopefully during that time nobody’s funds will be lost.
That’s true. There will definitely be painful problems along the way, but I do think the sort of fundamentals here are stronger and over time these protocols will prove to be more resilient than platforms that came before.
All right. Well, one other thing, in the days before recording this podcast, TBTC had to pause deposits for 10 days, which basically means they’re just going to drain the funds from the smart contracts. I presume they’ll just try again later because the key that they had only allowed them to pause the protocol once for that expressed purpose of draining the funds. They made it so that they could not upgrade the contract. We did mention that it is possible to create upgrades through governance. Why is it that some of these teams are opting to not make their projects upgradeable?
So I think there’s a lot of reasons why and it also comes down to the fact that every project is unique and different. I don’t think there’s a one-size fits all solution because different projects need different governance mechanisms in different ways. If you’re building a platform that is meant to be a very simple building block, you might want less upgradeability than a platform that’s meant to evolve a little bit over time. So I think for something like TBTC where they’re creating an asset it makes a lot of sense that you want a very limited amount of upgradability.
If you’re building a tool that looks more like a decentralized financial product, it has more complexity to it, you might want there to be some upgradability even if it’s only for simple purposes. A great example in some ways is Compound. There’s certain assets that we need to be upgradable, that need to be able to have governance there because the assets can evolve in unexpected ways. So you have to have the ability to make changes and make improvements but if we were building something that’s a very straightforward building block like bitcoin on Ethereum we might have elected to have almost no upgradability.
All right. So one last question I want to ask about a specific project is just about Block One. Clearly, this was a token team that somehow did things right. Block One, or depending on your perspective, I don’t know if right is the exact word but anyway, Block One raised 4.1 billion dollars in an ICO and they only had to pay the SEC a penalty of 24 million dollars for conducting an unregistered securities offering. So what is it that Block One did right?
I think they told a really good story and narrative is really important when building a community. You’ve got to get the community excited about the journey that they’re going to go on with the product that they’re using. So if they did anything right, I think they told a really good story about sort of community-owned platform and they got the community excited about buying in to own a piece of it. Now, that doesn’t mean that the platform itself, the technology is the best or the winning one but I think they did a good job of galvanizing community interest and getting the community to buy in.
I would argue that today you can take the narrative piece, go build the best technology, the best product and then give the community ownership once you’ve demonstrated the product is in fact best in class and the community is getting real utility out of it.
I’ll take the opposite view real quick. I don’t know if they did anything right because I measure what’s right by usage and adoption. So I think time will be a true test to judge whether they did things right by building a blockchain that is a platform for lots of new applications and usage and it’s possible they did do things right. It’s possible it becomes an extremely successful blockchain and it’s possible it goes nowhere. I think we have to reserve judgment for probably a few more years.
Yeah. Clearly, when I said right I mean because I think most people were shocked at how small the penalty was compared to how large their ICO was. All right. So going forward, what trends or experiments are you guys watching in terms of how teams decentralize and are there any particular projects or strategies that are intriguing to you?
So at layer one, I think the celo team just launched Main Net recently. I think they’ve done a really good job of progressively decentralizing their community and their product. They have a core team that built a layer one blockchain and then they recently ran a sort of incentivized test net program where validators who will run the layer on blockchain could register to participate and sort of earn tokens at the point that the main net actually launched. So I think that’s a good example of build the technology, build the product that people want, build a community around the product, mainly the validators in this case, and demonstrate that the validators can actually stand up the network through a test net.
Once you’ve done that and demonstrated the test net’s running then you move to main net and effectuate the distribution of ownership through tokens to the validators that actually are running the network. So all that just happened. I think it was executed on really, really well and so now of course the next step is to see beyond the validator community can you get a community of developers building on top of the platform. So I’m actively watching to see what happens there.
Well, I’m excited by the pace of education around governance increasing exponentially. I think teams are getting a lot faster at decentralizing. I think they’re also getting to the process of giving tokens to users directly more rapidly. I’ve seen a number of DeFi projects in the past couple weeks embrace the idea of distributing tokens to users through their protocol. I think we’re going to see more and more projects run by the community in a shorter amount of time. I don’t want to say we’ve done a poor job but it took Compound three years to get to the point of legitimate decentralization. I think a lot of other teams are going to be able to stand on the shoulders of giants and get there a lot faster having seen what works and what doesn’t work.
Agreed. One thing I would add to that is I think this phenomena is likely going to play out across many more verticals. So of course it’s happening in DeFi today and Compound is sort of pioneering best practices but I do tend to think this phenomena of community ownership and control over internet products and services is going to play out more horizontally.
So it probably starts with more technical communities, the communities that built bitcoin and Ethereum are largely technical communities. I think you could argue that still today DeFi, it’s technical folks and financially oriented folks that are maybe more quantitative driven. But over time, we may see this start to see this play out in more consumer-facing marketplaces, for example why isn’t it the case that hosts on Airbnb are drivers and Uber can’t own the platform or own a piece of the platform and have a say in how it evolves.
Crypto tokens I think make it way easier to distribute value very granularly to users of internet platforms and services at internet scale and so I do think that this phenomenon is going to play out beyond just technical crypto communities but eventually across all sort of consumer market places. So that’s sort of the exciting thesis on where all this goes.
Yeah. We’ll have to regroup in a few years and see if that turned out to be the case. All right. Well, it’s been great having you both on the show. Thanks for coming on Unchained.
Thanks for having us.
Laura, thanks for having us. Yeah.
Thanks for tuning in. To learn more about Jesse, Robert, and the path to progressive decentralization, be sure to check out the links in the show notes of your podcast player. Don’t forget to take the Unchained survey at Surveymonkey.com/r/unchained2020 to have your say in how we can improve the show. Again, you can have the chance to win a metal MCO Visa card that Crypto.com will stake indefinitely and that offers free Spotify, free Netflix, and three percent back on all spending plus extra interest on your crypto deposit. For your chance to win, fill out the survey at Surveymonkey.com/r/unchained2020.
Unchained is produced by me, Laura Shin, with help from Fractal Recording, Anthony Yoon, Daniel Nuss, Josh Durham, and the team at CLK Transcription. Thanks for listening.