Projects
![]()
No projects found
Investors
New
DAO Treasuries
DATs
Lend / Borrow APRs
Chains
Categories
Spaces
Tokenomics for Builders: Open Source Launch
Recorded: Aug. 25, 2023 Duration: 0:30:49Space Recording
Full Transcription
Hey, Matty, how are you doing?
Congrats on a big day.
Thanks, Nate.
How's it going?
It's going pretty well.
Just morning here, and yeah, it's a good day.
Awesome.
Also got Trevor.
Nice to see you, Trevor.
Let's see if I can get him up here.
Yeah, I guess we could just hop right into it.
Trevor, I sent you an invite to join us as a speaker.
I don't know if it went through.
But yeah, let me set the context here, right?
So I'm Matty.
I have been working a while on a tokenomics guide.
My background is in crypto for a number of years, traditional finance before that, tokenomics at the Stacks Foundation, more recently, tokenomics for status, one of the earliest Ethereum ICOs in 2017 and projects they're working on.
And I'm happy to be joined by yourself, Nate.
I think you've got a great perspective and spoken at numerous big conferences in Denver, right, where you gave your initial demand-side tokenomics talk, if I remember correctly.
Yep, yeah, that one.
Yeah, it's a pleasure to be here.
It's really an honor to be helping you launch this and co-hosting this space today.
I'm really glad to be here.
And yeah, without further ado, let's launch into it.
I'm really excited about this one.
Nice, yeah.
We've got Trevor here, too, who is a big investor, VC.
I don't know, Trevor, if you want to just give a really brief introduction just so people understand your perspective.
Yeah, good morning, everybody.
I'm excited for this launch.
And I'm Trevor.
I'm the Trevor Owens.
I'm the managing partner of the Bitcoin Frontier Fund.
And I've worked with Matty, I think, for at least a year and a half now and have had him as an expert in residence in our accelerator program and with our fund, working with our portfolio founders.
And he's just one of the top people in this field.
So I'm very excited to see this.
And I think this tokenomics is a kind of like alchemy.
You know, it's like kind of like voodoo in the level of maturity the space is at today.
So I hope that we can spread the word and get more education out on the topic so that people can build more sustainable protocols in the future.
Yeah, definitely.
I mean, I think that's definitely a key point that Nate focuses on on the demand side that I like to focus on is the sustainability aspect.
Speaking of, you know, involvement with Accelerator, I've got a I'm actually doing a talk reviewing some of this tokenomics design canvas with with the Bitcoin startup lab at the top of the hour.
So we got about half an hour.
So we can dive right in.
I think it's a bit of a dark day, a bit of a dark day because of the OFA or the updates on on tornado cash.
Right. Some of these rulings that are making it kind of difficult to foresee, you know, how how defy, at least in the U.S., will play out.
But I'm excited to release the guide.
And I think, you know, one of the one of the many behavioral kind of biases that people have that influences tokenomics and investing in all sorts of aspects of life is loss aversion.
Right. The the fact that we're not the fact, but the the empirical observation that in evidence, it tends to be that people are more avoidant of losses than they are willing for a gain.
You know, they feel the impact of a loss more than they do an equal size gain.
And for that reason, I like to focus on when I speak to builders about mistakes to avoid.
Right. Because mistakes to avoid or give them concrete things to avoid.
It's it's it's learning lessons from previous projects.
And so I think each of us could give, you know, our brief thoughts on the top mistakes, protocols and builders can avoid, because that is really like the 80 20 rule of like getting 80, you know, 80 percent of benefit for 20 percent of the work is just learning from history.
So you don't repeat it. I don't know, Nate, if there are any particular ones that come to mind, if you want to kick us off.
Yeah, sure. Yeah, I'd love to.
You know, it's it's funny. I'm going to go with the three, maybe three canonical mistakes that I see often, and they're going to correspond to the three principles of tokenomics.
So and then I have a fourth that's related to tornado cash.
So I think first mistake is not leveraging the unique properties of a blockchain.
And this is going to be pretty common sense to most of the people in this space that are listening to Matty here.
But for most crypto projects, we see that people are not actually using unique properties of a blockchain.
A lot of them are saying we're going to use this as a distributed database that's public for everyone to see.
And they're they're mistaking openness is the primary quality of a blockchain, where I would say censorship resistance is the main value proposition of cryptocurrencies and of blockchains and decentralized applications.
So I'd say leverage, you know, there are other properties, but that's going to be the main 10x that that is your value proposition of your project.
So make sure that you're using unique properties of a blockchain.
One, two is going to be capture value up front.
Don't wait until later.
So Matty likes to talk about Uniswap as an example of capturing value, the need to capture value up front, where Uniswap has failed to capture a significant amount of value.
And because of that, it's had to upgrade multiple times and it still hasn't captured any.
So the Uniswap governance token is fundamentally far less valuable than it's trading for right now.
And that leaves it susceptible to large supply shocks or other factors that might reduce its price drastically.
You want to give your protocol fundamental value by capturing some of the value that you create.
So that's the second mistake to avoid.
The third mistake to avoid is hard coding any kind of variables or parameters if you can help it.
Try to make your protocol as flexible as possible so that it can meet all of the possible demands that your users might have in any configuration of variables.
So try to avoid hard coding a number anywhere in your protocol, you know, a hard limit for any reason, because if that hard limit ever gets hit, then you might have a problem.
So be wary of anything that you're hard coding into your protocol.
Consider that it's going to be very difficult.
It's not impossible to change later.
And Maddie, where I thought you were going with Tornado Cash, a mistake, you know, and the loss aversion, I think a mistake right now is to get scared and to be wary of putting something out that you know is a good thing.
And for builders who are building censorship resistant protocols, I think this is especially important.
And I would say there are many approaches, and I'm not a lawyer, to launching protocols.
But the one that resonates the most with me is build something that you think needs to be built and make sure that you capitalize yourself well enough that you can afford to take the risks that come with it.
And that's going to tie into value capture.
And this is one of those things that both Maddie and I hit on a lot is the need to capture value because you are taking on immense risks in putting out censorship resistant blockchain based applications.
You need to be compensated for that.
And I think the best approach going forward for builders is going to be to capture as much value as possible of the value that you're creating and enable your applications to go out into the world that way.
Yeah, those are great points, Nate.
I mean, I think that's a tricky one.
I would certainly agree that, you know, navigating regulatory aspects has become more and more important.
And it's definitely a mistake.
I mean, just a simple mistake is you see teams or builders that kind of look at other models.
They look at, you know, the quintessential example is they look at Binance and it does, you know, buybacks of the BNB token.
And they say, oh, if Binance does it, then we can do it, right?
No problem.
And, you know, that is that is completely, you know, just not very realistic.
Your protocol that is just starting is not Binance, right?
You are not CZ.
There's not even a guarantee that, you know, CZ and Binance are getting away with it.
So you need to take risks seriously, right?
Be capitalized, speak to lawyers.
It can be expensive, but that's also, you know, one of the reasons that that that building a crypto project
is almost more analogous to building hardware than a software product.
Trevor, to go over to you from from an investor's point of view, from a VC's point of view,
what are some of the top mistakes, in your opinion, that builders make when it comes to their token?
Or, you know, as it relates to the general kind of economic incentives of their protocol?
Yeah, I think I would say there's probably two in my book.
I think the first one is just like rushing, doing a token.
I think that, again, a token is not necessarily a good thing.
It's not necessarily an advantage unless it's done the right way.
And so making sure that you have a thoughtful design and model behind your token is key.
A lot of founders rush it and try to do it in like the first inning of what they're doing.
And that's a huge problem and a huge red flag.
You always want to make sure that you involve your early investors in the thought process,
because otherwise you'd hate to like, you know, launch a token, then go out and look for investors
and then find out that you did it wrong or that you missed something or that the investor market doesn't really like what you've done.
And so you want to be really careful, like measure twice, cut once kind of thing with launching a token.
Make sure that it really makes sense.
You know, I also would be wary of VCs who focus only on tokens.
Those tend to be the VCs that are going to dump your token immediately.
I also see people, you know, do like ridiculously short vesting cycles for tokens.
I just think the industry, you know, when I came to the industry and like first saw this,
where they have like three months until a token generation event and they have, you know, three-year vesting on a token.
And for me, it's just kind of ridiculous considering, you know, founder, like most 99% of founders have like a one-year cliff
and a four-year vesting period for their equity and they still can't even sell it.
But, you know, I would say, you know, question those assumptions there for like and be cautious of VCs
who are like pushing you to do a token or only invest in a token, et cetera.
Probably not the best long-term thing for your business.
And so, you know, that's like I think the biggest one is just like making sure that you do it right
because it's a button you can't unpress.
It's like you can't put the toothpaste back in the tube after you have a token.
It would be very difficult and costly to do so.
And the second thing is just overcomplicating things.
I mean, I think that people, a lot of people think tokens are far more magical than they are or capable of being.
Like, sure, there's a few, you know, versions of magic out there.
But like at the end of the day, you know, a token is, you know, an accelerant or a token is a, you know,
more an additive or, you know, more of like a multiplier than it is like a fundamental value in and of itself.
And so I think that with a token, I've seen some really harebrained ideas and designs for tokens.
And Matty, I'm sure you've seen, and Nate, I'm sure you've seen a ton of them too.
But it's like if I can't understand it, it most certainly is bullshit.
So it's like it has to be able to be understood simply.
Otherwise, it's probably like a Rube Goldberg machine.
So that's kind of the two biggest thing I'd say is like try to keep it as simple as possible.
Like as soon as it's like difficult to explain, if I need to spend like more than 30 minutes to understand it,
it probably doesn't work.
Like that's been my experience over and over and over again.
And then the first one, of course, being like make sure you measure twice, cut once,
and be very cautious and careful how you're going to do this if you want your company to be sustainable in the long term.
Yeah, those are great points, Trevor.
I mean, I think I'd like to say, you know, a token is not, there are rare exceptions to this rule,
but a token is largely not a product.
A token improves a product, but it ideally improves the product and too often, you know, tanks the product.
But it is not a product itself.
And I'm pleased to hear a lot of what you touched on is actually topics, content that is directly in this guide,
a checklist for teams to evaluate, you know, whether a token may make sense for them,
a checklist to evaluate, even if a token does make sense at some point, is now the right time to launch, right?
Which is a whole separate question to launch a token, right?
And Uniswap, many protocols launched a successful product literally a year or more before they launched a token.
So you don't need to rush into a token, even when it is the right fit for you,
which is not necessarily the right fit for everyone.
Before jumping over to Resh here, I just wanted to touch on some other mistakes.
I mean, a lot of this content is in the guide itself, so I won't rehash it too much.
But I think you guys are hitting on good points.
You know, not knowing why builders need a token or what type of token they're issuing is probably my biggest pet peeve.
You see builders launching a token, then just blindly assuming that it's going to serve as a medium of exchange or store of value type of token.
And this is just wildly optimistic at best, if not, you know, fraudulent behavior.
I think a lot of people got spoiled by the beautiful simplicity and magic of Bitcoin and seeing Bitcoin go up.
And it has a very special, you know, the first popular crypto, very special narrative,
particularly around limited supply and retaining purchasing power that gives it a monetary premium.
But even then, it's wildly volatile, right?
And subjective what degree that monetary premium really exists in a sustainable way.
And then you're saying that you're going to launch a token that's, you know, tiny compared to it in market cap,
comes much later, many years later.
And assuming that it's going to have a monetary premium in a similar way is, you know, largely a myth.
So that's one of my biggest pet peeves.
But there's a lot more.
There's a whole chapter, actually, in the guide devoted just to general principles for designing a tokenomics and mistakes to avoid.
Resh, you wanted to come up and speak.
So do you have any questions, thoughts, comments?
Yeah.
So maybe a question, Matty.
I mean, you know, I'm a big fan of your work and I have the privilege to work alongside with you on a few tokenomics.
I mean, one tokenomics in particular.
So I would like to ask more about me, to be honest.
I really like what you mentioned that do not hard put any variables in terms of your design for your tokenomics.
But then, interestingly enough, I also agree with Trevor that do not overcomplicate your tokenomics.
The harder it gets to understand, the users won't appreciate what's been built.
And I remember speaking to Matty a while back.
Well, at least I came to a conclusion that there's no one tokenomics model that fits a situation.
In a whole market, a certain form of tokenomics would work perfectly well compared to when what we call a bear market would work very well.
But how do you design a tokenomics that actually makes sense?
Because no matter how I came about thinking about this, and I remember speaking to Matty like, ultimately, the model you're designing is going to be very similar to what the current fiat system looks like in terms of how the Fed runs the economy.
Because it has to be flexible enough to restart and kickstart the engine of your tokenomics in a bear market once a bull market starts compared to just having one form.
So I would love to hear your insight on that in terms of how you picture a variable tokenomics and how to make it actually not seem abusive to what the founders are.
Because it's very easy to become centralized at some point then.
Yeah, I'm not sure if that was directed toward anyone in particular.
Yeah, me.
Okay, great.
Yeah, so I think the question was, you know, how do you design your tokenomics and like general principles, you know, considering there are bulls in bear markets.
And I think that the way that I'd answer that is just, first of all, that Matty's going to have a lot of info on this in the book.
But the second, you know, to answer your question directly, I would say design your token as if you're launching right before the top, because that kind of volatility is the most extreme that you're going to have.
So imagine you launch your token, it goes up 300%.
And then right after that, it goes down 90% in a week.
Think about that.
You know, think about is your protocol tolerant to that kind of volatility?
And if it is, it's a pretty good sign.
And so I would say, like, as a general guiding thought experiment rather than principle and scenario rather than principle, have that in mind.
Think about extreme volatility and can your protocol handle it?
And if not, why not?
And then check your security assumptions.
Think about these kinds of, you know, drastic scenarios that actually do happen in crypto pretty regularly.
And on the topic of bull market versus bear market tokenomics and certain projects outperforming others, yeah, there's a type of project that will drastically outperform others in a bull market because it's a Ponzi and it will fall apart as soon as the market turns.
So Ponzi-nomics is an entire sub-study in tokenomics.
And there's a lot of VC firms and individuals that are pioneering these kinds of models.
And Maddie and I like to tear those to shreds lightly when they come on our radar.
Yeah, definitely.
Well said, Nate.
I mean, I think it's frustrating that these type of Ponzi-nomics still exist when we see them.
So we get a little bit, feel a little bit personally attacked sometimes when these come out.
But, you know, it's well past the point of like people, people know at this point what they're doing, right?
It used to be kind of attributable to ignorance.
And now we've been through enough cycles where people are absolutely designing these mechanisms intentionally.
So I think also to your point, Resh, like the guide also touches on, you know, approaches to modeling, et cetera.
But just to share some quick thoughts, I mean, there's basic, you know, deterministic like spreadsheet style modeling, right?
Where you as a human can do, you know, more like hard-coded scenario analysis.
But you also need to do things like boundary analysis, right?
Like testing, pushing these things to the limits, right?
Like if you have a collateral position or your protocol requires, makes use of collateral, right?
What happens if there's an Oracle bug and the price is reported as being, you know, infinite dollars per token, right?
Or zero dollars per token, right?
So doing boundary analysis, doing more manual scenario analysis, but also doing, you know, market data informed stochastic analysis, right?
So observing real world data, plugging that into Monte Carlo simulations and things like that.
So you can start to quantify risks and actually optimize for a given objective within a given context, right?
No protocol is ever going to be free of risk or free of downside.
Every product, whether it's a Web 2 or Web 3 product, will have some constraints and limitations.
I think we need to be thinking more about tokenomics as an optimization problem than as just like a fundraising mechanism, which it so often is.
To briefly circle back to something Trevor mentioned about, you know, builders using a token purely to raise funds.
Now more than ever, there are ways to raise, you know, via token warrants, for example, from investors.
So you say, you know, you're investing via safe notes, you get equity in the affiliated entity and a one-to-one token warrant.
So a token warrant at equivalent pricing terms.
But the token warrant doesn't obligate you to launch a token.
And that doesn't obligate you to launch a token, you know, next week or ever.
So you can get the benefit of the token for fundraising purposes without having to rush into a token or potentially launch one that's ill-fit for purpose and end up burning your community and destroying your product's credibility in the long run.
Thanks, Manny.
That's really helpful.
Yeah.
We've got a few more minutes here.
Anybody who wants to hop up, ask a question, please raise your hand.
Let me know.
But, Nate, any other general advice or Trevor, any other general advice?
Maybe moving, you know, outside of just literally tokenomics to kind of the next realm around it of economic incentives and related topics.
Yeah, Trevor, take it away.
Yeah, I was going to say, Matty, are you going to like, is the book available now?
Could you talk a little bit about like the actual book here and kind of like call back?
Sure.
Yeah, I will.
My intention was basically to I've got a I've got a tweet ready to go.
So hit send at the end of this spaces and everybody who's interested can go and dive into the dive into the guide.
Yeah.
OK, I'll speak a little to the guide itself.
So essentially it was it started actually, Trevor, after speaking to one of your accelerators cohorts of companies.
And I was speaking to them and pretty much everybody had a great product, but a lot of them were they were all trying to answer the same questions in parallel, essentially.
Right. They're all researching like what's best practices for vesting and team allocation and maximum supply and emissions rate and all this stuff.
How do we fundraise? Right. Should we use governance?
You know what? How do we think through incentive?
A lot of them didn't even know where to start.
And so it kind of dawned on me that they needed from a founder, from a builder's point of view, a framework, a guide, a process to follow.
And so that was kind of the light bulb moment that I got started on this.
It has since then taken on, you know, gotten much more involved than I originally thought.
It's been battle tested by protocols I've worked on and worked with protocols at the accelerator and incubator.
So I would say at least a few dozen real world teams have used this guides like teachings and its workflows and frameworks at this point.
And I'd also like to thank, you know, there's a couple of people here from token engineering, token commons communities, tokenomics DAO as well.
Those communities had a bunch of early readers and contributors who helped, you know, everything from as simple as proofread to suggest how to rearrange topics.
Nate as well was helpful in that.
And so it's not just my work here.
It's a lot of time and effort and references to collecting, you know, the best papers, the best Twitter threads, the best memes out there and compiling it, condensing it all into one book that is aimed at builders.
So the guide is largely broken down into two parts.
The first part is more of the fundamental concepts and the history that every builder in this space should be familiar with.
And then step two or excuse me, part two is an actual step by step process that founders can more or less follow directly along with to design and optimize their tokenomics.
So there's accompanying frameworks and deliverables for every step.
There's an accompanying YouTube playlist with examples and tutorials of completing the steps.
So I think that part in particular will be very useful for teams, as well as part one for, you know, teams who want to do like a deeper dive into a given topic.
So just to quickly go through the table of contents, basically starts with in part one, touching on why does tokenomics matter?
What is tokenomics?
The good, the bad and the ugly, you know, case studies of tokenomics.
Evaluating does every project need a token, right?
Those checklists of helping builders actually evaluate in a formulaic way.
Do they need a token?
Is it helpful?
And do they need one now, even if they do?
Talking, looking at types of tokens in chapter 1.5 and then chapter 1.6, which took quite a while to compile, is a must know history of tokenomics, starting from the very beginning with Bitcoin and going up to present day.
Touching on all the big topics that people, the projects that people constantly are copying, Curve, GMX, you know, Olympus DAO, and many, many others.
And then part two gets into general principles and mistakes to avoid in the design process, objectives and requirements, value accrual, lifecycle patterns of the token, incentive mechanisms, supply policy, which I'm sure everyone will be excited about.
Actually, there's actually, there's actually hard data analysis of optimizing your supply policy and emissions, modeling and optimization.
There's a whole chapter with lots of real world examples of Excel models or Google Sheets models, Python models of real world projects like Ethereum itself, Liquidy.
And finally, chapter, the last chapter, chapter 2.7 is on legal opinion and structure.
I'm not a lawyer.
I don't delve too much into those topics on my own, but I've curated quite the extensive list of resources from actual lawyers and experts on everything from how you should, you know, structure your DAO's actual legal setup to governance concerns to, you know, securities law, all that, all that, all those aspects.
So that is a brief overview of the guide.
Thanks for, that's a good, that's a good point, Trevor.
Yeah, awesome.
And so people can just download it, like, where do they get it?
Yeah, it will be a Notion, it's a Notion document.
People can access it, make a copy of the, or at least of the canvas, of the things that people need to make copies of, they should be able to make a copy.
It will be linked forever via the link on my Twitter profile.
So if you're listening to this after the fact, you can find it there.
But I'm also going to just tweet out now, I think it's looking ready to go, unless anyone has any objections.
Let's just hit play on this, on this thing.
Let's do it.
And Matty, are we going to inscribe this on ordinals as well?
Ooh.
After this?
Yeah, yeah.
I can't do that immediately, I got a call, but that would be awesome.
We should definitely do that.
Here we go.
All right.
Thread is going out, so should see it on my profile any second now.
I would appreciate, you know, if you're listening, if you're in this, if you're in this spaces, if you want to throw out a comment, a like, a retweet, those are all appreciated.
Let's see.
Yeah, if you guys enjoyed this space, go retweet this book by Matty, because the things that we've been talking about are a fraction of all of the things in this book.
Yes, absolutely.
There it is.
It's out there.
I will add the post to this spaces.
And I'll pin it also to my Twitter profile, so everybody here right now can find it very easily.
It's pinned to my Twitter profile.
Now, like I said, I got to hop to a call with founders actually working on projects right now, but this has been a pleasure.
Thank you so much for joining, Nate, Trevor.
Thanks for your questions, Resh, and look forward to touching base with anyone who has any future questions or just wants to, you know, offer feedback or comments on the guide.
Thanks, guys.
Love it.
Catch you later.
All right.
Cheers, everybody.
Take care.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
Cheers.
