reading time: 5 minutes
I've been on holiday for a few weeks. And while I've been AFK climbing rocks, I haven't stopped thinking about this one topic (it's not AI). I think it's going to be huge.
If you're a fan of money, memes, and positive-sum games, maybe you'll find it interesting too.
Retailism is a new business framework proposed by Jango. It describes a novel approach to corporate fundraising and growth that aims to maximize incentive alignment between a project's builders, users and investors, while minimizing trust and admin overhead.
I know, it's a lot.
But it could prove to be the most viable fundraising and growth solution for many projects out there.
All is to say: it's worth a look!
In this article, I'll try to explain what a project operating under Retailism actually looks like.
tl;dr:
- A Retailist project has a Treasury that issues Tokens to investors.
- The Treasury has no privileged access; funds only leave the Treasury when tokens are redeemed.
- A Retailist project sets 3 'taxes' to incentivize early investment, long-term holding and builders building.
- Once launched, none of these rules can change, ever (immutable).
- Thesis:
- If investors, users and builders all have the same token, they are all equally incentivized to grow the project organically.
- Projects with only 3 variables is easier for investors to understand and build projections for verses alternatives.
- Treasuries with no privileged access, and whose variables can't change, minimizes 'rug-pull' risk and treasury management overhead.
Anatomy of Retailism
Let's consider a project - the thing being built, consumed, and invested in (an enterprise software business, a mobile app, music, t-shirts. whatever). A project has three stakeholders:
- Builders - the team building the project.
- Investors - the people funding the project.
- Consumers - the people consuming the project (users, clients, audience, etc.)
The lines between stakeholders can get blurry. Run with it for now!
Treasury and Tokens
A Retailist project has two components:
- The Treasury ("shared bank account").
- The Token.
Investors contribute funds to the Treasury. In return, they get some Tokens.
Example: You put $1000 in, you might get 1 Token in return.
Tokens are kind of like equity in traditional investing. They represent an investor's ownership of the Treasury.
When an investor wants to 'cash out' (get their money back), they redeem their tokens for their share of the Treasury.
Example: There is $3000 in the Treasury. You have 1 Token, and two other investors have 1 Token each (3 Tokens in existence). If you redeem your Token, you'll get $1000 from the Treasury. There will be $2000 left in the Treasury.
Tokens can be redeemed whenever. There is no 'waiting for a liquidity event' in Retailism.
A Treasury has no privileged access. No one - not even the Builders - can ever take money out of the Treasury for any purpose (unless they're redeeming their tokens).
The only way funds leave the Treasury is when Tokens are redeemed.
Taxes
The Token-issuing Treasury is a great base. But we need a few more ingredients to get the juices flowing. We need to design for the following:
- Incentivize early investment. Early investors should have more upside than later ones.
- Incentivize long-term investing. Investors who redeem their Tokens early should be taxed. In other words, investors who hold for the long term should be rewarded.
- Incentivize builders. We need to pay the people doing the work!
And so, we get the 3 Retailism Taxes: Entry Tax, Exit Tax, and Dev Tax.
These are variables. Each Retailism project will set their own 3 Taxes at launch. After launch, these can never be changed.
1. Entry Tax
The "invest early" incentive. The idea: give less tokens to investors who invest later than others.
Venture capital raises occur over a series of rounds (Series A, B, etc.). Investors who join later rounds will get less equity than earlier ones for the same $ investment.
In Retailism, a project's fundraising happens over generations.
A project must set the following:
- Length of each generation (e.g. 28 days, 2 years, etc.)
- The % Token issuance decrease each generation.
Example: Generation 1 might get 10 tokens per $. Generation 2 might get 8 tokens per $. And so on.
2. Exit Tax
The "hold for the long term" incentive. The idea: early redeemers get less $ per token redeemed, and later redeemers get more. If you redeem earlier than me, then my tokens will be worth more than what yours were.
A project must set the 'redemption rate' for the Exit Tax, which defines how the magnitude of this incentive.
3. Builder Tax
The "builder" incentive (called Dev Tax in Jango's original piece). The idea: Give builders Tokens up-front, and drip-feed them more Tokens over time. The goal being to incentivize builders to keep building and growing the project for as long as necessary.
The project should set the following:
- The builder pre-mint - how many tokens to pre-mint to some specified addresses?
- The builder reserved token rate - for every token minted, how many of those should we reserve for devs?
- The builder reserved rate cut-off date (optional) - when (if ever) should the drip-feed stop?
There's a whole lot more to say on this topic. But that's enough to wrap our heads around for now.
Keep an eye on Jango's blog and this blog.