Unchained - How to Decentralize a Crypto Project Without Harming Security - Ep.175

Episode Date: June 2, 2020

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 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  Thank you to our sponsors!  Crypto.com: https://crypto.com Kelman Law: https://crypto.law   Stellar: https://www.stellar.org Episode links:  Jesse Walden: https://twitter.com/jessewldn Robert Leshner: https://www.linkedin.com/in/rleshner/ A16z Crypto startup school: https://a16z.com/crypto-startup-school/ Compound: https://compound.finance 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 More on tBTC: https://www.coindesk.com/bug-forces-shutdown-of-bitcoin-backed-ethereum-token-tbtc 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  Block.One settlement with SEC: https://www.coindesk.com/eos-maker-block-one-settles-with-sec-over-unregistered-securities-sale Learn more about your ad choices. Visit megaphone.fm/adchoices

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 unconferred. 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're going to be a new. you'd like from the show. The link is in the show notes, or you can just go to surveymonkey.com slash R slash unchained 2020. Again, that's surveymonkey.com slash R slash unchained 2020. And guess what? Crypto.com has offered our survey respondent as 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 deposits and more. Thanks, crypto.com. Again, take the survey now. Surveymonkey.com slash R slash unchained 2020. That's surveymonkey.com slash R slash unchained

2020. 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 rule 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 live 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 statutes of limitations are quickly approaching. Kelmman, PLLC, run by some of the first lawyers to enter

crypto in 2013, is here to help. Go to www.com.com. Go to www.com for all crypto purchases for the next three months. 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. Start your journey today at unchained.com slashore.org. 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. Hi, Laura. Hey, Laura. 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? And 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?

Sure, yeah. So 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 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. And 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 and Horowitz, where we spent out a dedicated crypto fund. And I worked on the investment team for the last two. and a half years. And now with 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. And 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, you know, traditional financial markets. I started compound in 2017 to create interest rate markets for crypto assets. When I was on the show last time, you know, 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, you know, 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 applications 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 playbook. So how would you describe the challenge here? Yeah. So I think you touched on it earlier in saying that there's sort of a dissonance between, you know, building a product and then the,

the sort of ultimate goal of crypto networks, which is to become sufficiently decentralized. And I think it's important first sort of addressing the question why crypto projects aim 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, you know, networks like Bitcoin and Ethereum. As you, as the community starts to develop sort of more complex applications,

there tends to be a shift from deterministic protocols or protocols that conduct a sort of verifiable computation to protocols that require or applications that require, that require more subjective inputs and human decision-making. And 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. And 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. And that's very different from traditional internet platforms, which are, you know,

owned by investors and shareholders whose interests are not always aligned with the, with the interests of end users. So that's all to say, you know, 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 a bit on 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, just described. But to start, I would argue that teams really need to think about first building a product that people actually want. And their, you know, 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. And you probably will have a hard time building a community that ultimately wants to sort of, you know, take control or build on top of what it is that you're building. So, so yeah, 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. And 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 DAP or application. Yeah. I just, so you did say in your playbook that blockchain protocols are, or that they require, and I'm going to quote you here, that they require 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 is really sort of really aims to speak to entrepreneurs and founders building at the application layer. And that means, you know, applications built on top of smart contract platforms like Ethereum. At the lower layers in the stack, so, you know, layers like Ethereum or other smart contract platforms, arguably you need decentralization out of the gate in order for the platform to be useful. And that is because, you know, platforms like Ethereum, the promise of the platform is that they do computation that can be trusted. And And again, that trust arrives from 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 a specific. 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. And 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. And I was curious to know about some of the ways that teams are moving along these stages. Like, for instance, one of the ones that you mentioned in your playbook was something called Kelvin versioning. And 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 even, you know, the best person answered this question because he's, he's been living it over the past couple of years with compound, and he can give you, you know, his own experience. But maybe before I turned it over to Robert to answer that, I would just note that recently Reddit sort of, Reddit sort of made a play in the crypto space that I think validates the, the hypothesis of this playbook, which is, you know,

they just announced community currencies. And so a couple of subreddits, I think one is called our Fortnite BR, which is the big Fortnite subreddit and then our cryptocurrency are both getting their own subreddit currencies, I think bricks and moons, respectively. And what's interesting is those cryptocurrencies did not launch sort of 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 subredits, 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 subredits already. And so there was, you know, a good amount of community participation. And then at the time that they actually launch these community currencies, and they effectively are now in the process of turning ownership of the community over to the contributors directly through this token. And so I think that's a very good example of a sort of high-profile platform executing this playbook step by step. And Robert's been doing a similar thing, and I think it can probably speak best to how

he's been thinking about it. And actually, Robert, before you start, I just wanted to ask one more thing, which either of you can answer. But so Reddit and KIC are somewhat similar and that both of them did have these communities to start with and then introduced a token. And is the main difference simply that KIC 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 KIC and they're still in a court battle. Yeah, I think that's a big one. And I think, you know, 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, you know, in exchange for funding. And I think, you know, 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. And so my view is that if you start sort of 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? And 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. And, you know, as Jesse touched on earlier with, you know, the decentralization playbook, it's overkill in a lot of ways. You know, 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. And 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.

And so we've had a lot of steps and we can over, you know, 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 decentralized is to now introduce a governance token, which has the ticker comp. Why did you decide to go that route? So there was 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 multi-sig 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, you know, a huge community share of 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, a year, et cetera.

By rolling out governance to a much larger audience and designing it in such a a way that the community can actually suggest and implement changes themselves, it allows a much wider surface area for creativity and improvements. And we're already seeing, you know, stakeholders in the community actually implement and merge in changes to the protocol itself. And so I view this is like the tools required to allow it to run forever and to continuously upgrade. Now that there's, you know, 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 Lendef Me protocol and the team behind that de-force appears to have copied the original compound code. and in a discussion that I had on Unchained about that attack, some people were saying, you know,

essentially that the compound team was, you know, really up on security. And that was why you had prevented something similar happening on compound. Because essentially like certain technical decisions that the DeForce team had taken is what enabled that attack. So in that sense, it almost seems like you were able to protect yourself. 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 tradeoffs as you start to decentralize and start to handoff 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, but 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. You know, my first decision as a token holder and whether or not to approve a change does come down to security. And I hope and expected over time, the community starts to enforce the exact same standards as they vote on upgrades to compound. Yeah, yeah.

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 compounds now in this mode of sort of open development, you know, 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 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 stack happens. So, you know, it was widely known. So, you know, you would have thought the team would have by then absorb the lesson and known to not allow ERC-777 tokens on their contracts. But anyway, and the other thing that is remarkable is that it took somebody that long to exploit it. But anyway, so just to go back, I also wanted to ask you, Robert,

So when you guys were deciding for compound to further decentralize, like what metrics were you looking at to say to yourselves, okay, this is now the time to take this step or that step? Like, you know, was it something about your developer community or the community in general or, you know, what were you looking at to make that decision? That's a great question. So we were looking at the protocol being, you know, in a position where it needs to harden and become more predictable for the applications built on top of it. You know, when a team has complete centralized control, they can change a product or take it in whatever direction they want. And 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. And, you know, I actually look at Bitcoin as, you know, in some ways the best, you know, analogy in that it's very hardened. It's very predictable.

You know exactly what you're getting. It's, you know, 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 out of 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. And so for us, you know, it was really like, do we want to, you know, 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.

And so for us, we said, well, 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. And we put all of that into version 2 of compound, which launched almost exactly one year ago today, saw the adoption, saw the integrations occur, and say, 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. And so what is the system of governance and 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,000 comp that they're able to vote with can propose a change to the protocol. Changes are, you know, actual executable code. It's not a suggestion for a centralized foundation or team somewhere to go and do something. It's actually like, you know, 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, you know, 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. You know, 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 and were executed and modified the way that the compound protocol operates over the last six weeks. The only additional layer that makes us even more exciting is out of the gate, the governance system runs on this concept of liquid democracy and delegation. So anyone with the COP 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. And it allows people to participate as much for as little as they want and to channel good decision making to the place where they think good decisions will be made. And 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 holder say, 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 ask. actually, you know, 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 slash governance. And it's a really cool system that's extremely transparent and liquid. One thing I have 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 one of the properties of an asset market. You know, how good is the asset as collateral and how does an interest rate work with it? And 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, like this is a huge. It gives a leg up to everybody fluent in smart contract coding, but all the non-coters are sort of shut out. But then there's delegation, right? So like, you know, in spite of the fact there's a dashboard, but but all separately, you know,

a non-technical person could delegate votes to someone more technical to propose something. And I think that's a really great way to scale governance because you can have people specialize in different areas that they're strong. 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 word from the sponsors who make this 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 access payment rails for applications and institutions around the world, and designs 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.

It's robust documentation, toolkits, and multilanguage support let you quickly integrate Stellar into your existing products and services. Learn more about Stellar and start billing today at unchained.stellar.org. In response to the challenging times, Crypto.com is introducing three measures to help the community. First, the 3.5% credit card fee for all crypto purchases. will be waived for the next three 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 which merchants are available in your country. Download thecropto.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 U.S. Congress, as well as working in the Mount Gok's 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. Kelman law is staffed with lawyers with expertise in ICO litigation, dispute resolution, anti-money laundering, and U.S. and

international corporate structuring for crypto businesses. So if you have a dispute with an ICO project or just needs solid legal advice related to crypto, send a message to info at kelman.law. That's k-el-m-m-a-n-law. Kelman with 1-L-N-2. Or just go to their website at at www.kelman. Dot law. Kelman. Dot 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 in mind. And some of the pieces, you know, 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, you know, very soon to begin distributing over half of all tokens to the users of the protocol. And we believe that, you know, 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 to change.

changes are made to the protocol. And we believe that, you know, 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 it succeed, of, you know, folks that want to see it upgraded in the right ways to maintain the stability of their protocol. And 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 can learn a lot from what the regulations are and why they exist in the first place. And 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. And lastly, we're distributing them to users only once all the pieces are in place so that

users are able to further the decentralization of the protocol and of the token. And 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. And just some of curiosity, so 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, you know, if we were Satogian, we created Bitcoin, and then we went out and created Coinbase. You know, 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 of the protocol now that we've ushered into existence. Interesting. All right. Well, let's now just 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 like 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. So, yeah, I think it's helpful to think of crypto networks as as marketplaces. You know, Bitcoin, for example, has a fee associated with every transaction. And part of that fee, you know, is used to reward the miners for ordering the transaction in the blockchain. And of course, in Bitcoin and Ethereum, there's also minor 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, there's many, 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. And 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, you know, 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. And the concept of switching costs is nothing new when it comes to marketplaces or networks. You know, Uber, Airbnb, traditional Web 2 marketplaces, the value of, those marketplaces is due to the switching cost of moving to an alternative. So anyone can build a competing Airbnb service or a competitor to Uber, but it's hard to get all the users that those platforms have amassed to switch over. And so switching costs is what's at the core of defensibility of Web2 platforms. It's also what's at the core of defensibility of crypto networks. Now, switching costs are

lower in crypto because everything is open source. So you know, it's it's, it's, you can't take uber's database of drivers and, uh, and fork it over to your platform. You can do that in crypto, but there's the cost of forking is still non-zero. As I mentioned, you have to get all the, the people involved to move over. Um, and so that switching cost does allow for some margin of, of, uh, defensibility that allows for these marketplaces to extract a fee. And I think so hopefully that highlights that the business model for crypto networks is actually quite similar to Web2. 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. And 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. And so I think that is, that that sort of validates the idea that these networks are marketplaces. They, 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 2. Yeah. And something else that we've kind of been talking about here and there, but not really dived into is the issue of token distribution, you know, some of you have mentioned it like in some of your answers like about Reddit or about how compound is doing it. But, you know, 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 on, depending on sort of the specific application and the specific community in question. That said, I think, you know, what you don't want to do is sell all the tokens up front to a community of folks that, you know, may not have any interest in actually using what you you've built. And so I think one of the things that compound's done really well is, you know, 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 that community can feel confident that the rules of the platform are not going to change from underneath them. And that gives them sort of, you know, increases their incentive to build and contribute. So I would encourage again, sort of, you know, selling out to unknown community of speculators at the outset. And that's, of course, what happened in 2017. That said, I think that, you know, speculation isn't all bad in that, you know, it does give the community members a way to have a stake in platform growth. And I think that's ultimately sort of the big unlock that crypto enables.

It sort of surfaced this latent demand that, you know, everyday Internet users actually do want to own a piece of the platforms and services they interact with every day. And 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, in response to real contribution. And again, that will depend largely on the application and question of the community's values. So it'll be different case by case.

Oh, even for something like the allocation to the initial team, like 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, you know, 50% goes to the core team and investors that sort of bootstrap the thing and 50% to the community. And then over time, that split may shift. For example, through, you know, increased inflation over time. But maybe that, you know, 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. And again, this is something that the community,

has a say in because, you know, 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, you know, 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. And 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. And 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 in,

which was MasterCoin. And at that time, even people were concerned that the tokens would be considered securities, and the way in the U.S. 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. And 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?

And in general, like, you know, what are some of the kind of maybe rules of thumb that are emerging when it comes to thinking about the Howey test and how it applies in these situations? Well, yeah, I think so with how you need to, you need to hit all four prongs, I guess, in most cases, in order to trip the securities regulation. And, you know, there are good reasons that those regulations exist. You know, it's to protect investors. And, you know, 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. and all that sort of overhead gets in the way of building a 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. And so, you know, as Robert mentioned, you know, when he started out, when others started out, it's really important that the core team is able to iterate quickly. and at that point you probably don't want to have a token because you might then trip the Howie test. And 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 a foul of securities regulation. You then don't have to necessarily deal with the overhead of being a regulated security. And 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. And 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 a product that people want, demonstrated that the community is sort of excited about it.

And that 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. And at that point, you know, there is no dependence on the core team that the project is hopefully sufficiently decentralized. And 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 in arms about the fact that the BZX team had an admin key, which they used to

pause the protocol. And I guess this was a surprise to some people who thought BZX was decentralized. So what's your take on what happened there? Like what would have been the appropriate action for the team to take and should, in that case, do you think that team should have had an admin key? I'll jump in on this. So I believe that any system should be documented and transparent. I think, you know, 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? the code available to inspect an audit? And does the community have a general understanding of how it works? You know, 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, you know, being radically transparent about the state of the system is actually a way to build trust, even if it's the case that the system is still centralized at the outset. Again, you know, in the early stages of a product, it's all about finding product market fit. And at that point, there probably should be no pretense of decentralization, you should just build, you know, 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 a system, you know, once it's unearthed, you will very quickly sort of undermine any trust that you might have built on false pretenses. So I think, you know, transparency is paramount and part of how you build trust towards progressively decentralized on the protocol. Oh, this is, this is an interesting perspective you guys have. I did see that Eric Wall had a tweet storm on admin keys. And this is also really interesting his perspective here. But he said that people tracking the defy teams with admin, or sorry, that people attacking

the defy teams with admin keys and saying that they're no different from centralized exchanges, that that attack is, quote, the cheap, boring, fast, to crypto-twethewokeness. And his stance was that a defy 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. And he said, you know, I didn't talk to Eric, but just from the way the tweets were phrased, it seemed to, he seemed to be saying that these types of admin keys are probably okay, at least to him.

He said, you know, 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. And so he said that that's obviously different from a centralized exchange. And 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 contract. 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, and this can, for even a single project, evolve considerably. A great example is when compound launched, you know, 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. And 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 help 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, right? 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, you know, 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,

you know, 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. And every team has a different set of standards. Well, one thing that I am so curious about is, as we're seeing, these defy protocols are very interoperable, and there's constant change and new developments. And so as the technology keeps improving, we're just going to end up with a lot of situations

like the LendafMe attack where, you know, we have this new technology, the ERC 777 token that when it operates with older protocols introduces a vulnerability. And I can't imagine that that's not going to happen time and again. And as we get more, like, just the sheer proliferation of new defy protocols, like, 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, like, the idea that you would get to the point where it's not upgradable, like, I'm a little But like, what are we going to see?

Just like every single time there's a new DFI project, like a bunch of projects are like, we're going to shut down for, you know, like two weeks or whatever. And then switch everybody over. Like, how is this all going to work? Well, so I think zooming out, you've got to look at the big picture. And what you're describing is sort of, you know, an ecosystem evolving through what's called, you know, composable building blocks where, you know, each application. or each DFI protocol is a building block that other developers are building on top of and extending and sort of adding new functionality to.

And the positive view of this is, you know, 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, well, that means that there's all these dependencies on the work that others have done. And if there's a vulnerability, you know,

the whole thing can come crashing down. I tend to think that that sort of that negative outcome is, you know, certainly something that will happen. You know, there are bugs in code. But over time, these protocols, the good ones will demonstrate that they're actually, you know, resilient and trustworthy. And the sort of positive sort of effects of the ecosystem composing one application into another and, you know, compounding innovation more rapidly will far outweigh. the sort of short-term negative effects of these of like bugs and creating you know 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 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, again, all the codes 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 2 error that came before, where you had a similar phenomenon of developers building on top of platforms like Twitter and Facebook and Spotify. And there were these rich developer ecosystems. But eventually, you know, each of those platforms had admin keys and decided,

you know what, we're going to change the rules, shut off our APIs, and bring down these entire developer ecosystems to bring all that product. innovation in-house. So, you know, that's the risk of having admin keys or having control by one central party. And I think, you know, 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, you know, that can ultimately be fixed over time. Okay, but hopefully during that time nobody's funds will be lost. That's true. I mean, I'm not saying there won't be, there will definitely be painful, you know, 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 than platforms that came before. All right. Well, one other thing, so in the days before recording, podcast, TBTC, had to pause deposits for 10 days, which basically means they're just going to drain the funds from the smart contract. And I presume they'll just try again later, because the key that they had only allowed them to pause the protocol once for that express purpose of draining the funds. And they made it so that they could not upgrade the contract. And, you know, we did mention that it is possible to create upgrades through governance. So, like, why is it that some of these teams are opting to not make their projects upgradable?

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 and 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. And 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 upgradeability. 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 upgradeability, 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. You have to have the ability to make changes and make improvements. But if we were building something that was a very straightforward building block like Bitcoin on Ethereum, we might have elected to have almost no upgrade ability. 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. is the exact word. But anyway, Block 1 raised $4.1 billion in an ICO, and they only had to pay the SEC,

a penalty of $24 million for conducting an unregistered securities offering. So what is it that Block 1 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 it's they told a really good story about a sort of community-owned platform, and they got the community excited about buying into 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 interests and getting the community to buy in. I would argue that today you can take the narrative piece, go build the best technology or the best product,

and then give the community ownership once you've demonstrated that the product is, in fact, best in class in 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, you know, 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, you know, we have to reserve

judgment for probably a few more years. Yeah. Yeah. Clearly when I said right, I meant because I think most people were shocked at how small the penalty was compared to how large their ICO was. All right. Well, so going forward, what trends or experiments are you guys watching in terms of how teams decentralized? And are there any particular projects or strategies that are intriguing to you? I think so at layer one, I think the solo team just launched Mainnet recently. And I think they've done a really good job of progressively decentralizing their community.

and their product, they, you know, they have a core team that built the layer one blockchain. And then they recently ran a sort of test net, incentivized test net program where validators who run, will run the layer one 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, you know, build the technology, build the product that people want, build a community around the product, namely the validators in this case, and demonstrate that the validators can actually stand up the network through a test net. And once you've done that and demonstrated the test that'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. And so all that just happened. And I think it was executed on really, really well. And so now, of course, the next step is to see, you know, 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. Robert. 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 defy projects in the past couple weeks, embrace the idea of, of distributing tokens to users through their protocol. And I think we're going to see more and more projects, you know, run by the community in a shorter amount of time. You know, 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. And 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, you know, having seen what works and what doesn't work. Agreed. Yeah, 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 defy today and compound sort of pioneering the best practices. But I do tend to think that this phenomenon of community ownership and control over, you know, internet products and services is going to play out more horizontally. So it probably starts with, you know, 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, it's technical, technical folks and

financially oriented folks that are maybe sort of more quantitative driven. But over time, we may start to see this play out in more consumer-facing marketplaces. For example, you know, why isn't it the case that that hosts on Airbnb or drivers and Uber can't own the platform or own a piece of the platform and have a say in how it evolves? You know, 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 marketplaces. And 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 the links in the show notes of your podcast player. Don't forget to take the Unchained Survey at SurveyMonkey.com slash R slash Unchained 2020 to have your say and how we can improve the show. Again, you can have a chance to win a metal MCO visa card that crypto.com will stake indefinitely, and that offers free Spotify, free Netflix, and 3% back on all spending, plus extra interest on your crypto deposit. For your chance to win, fill out the survey at surveymonkey.com slash R slash Unchained 2020.

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. Thank you.