The Arcade Bazaar: Continuous, Multi-Party, Tokenized Funding Without Central Issuance
This post describes a protocol that allows continuous, decentralized funding of any network or project. There is never any central issuer. Tokens are minted as needed & beneficiaries of the network earn tokens for the services they provide. It’s a generic template that can be used for any project.
- It allows a network to earn more when it succeeds.
- Any team, or beneficiary can at any time become a part in receiving token revenue from the projects’s success.
- Rewards early adopters & active participants.
- Ensures teams, users & funders work closer together [they all share the same pool of funds].
- Allows projects to naturally dissolve if it is no longer needed or necessary.
This is an improvement on current token models in that it
- utilises a continuous token model,
- requires less reliance on specific entities [eg, founding teams],
- allows tokenized projects to be started with very low barrier to entry,
- allows more natural accountability between the users & beneficiaries,
- allows more effective capital allocation, &
- allows projects to dissolve naturally [protecting more participants against malicious or scammy behaviour].
This post is assumes knowledge on how Bonding Curves & Token-Curated Registries work. In short:
Curved Bonding allows participants to stake a token into a communal pool, upon which a new token is minted, priced according to the outstanding supply. These tokens can be sold back into the communal pool.
Token-Curated Registries is a staking game where its token holders curate a list of applicants that conform to specific criteria.
The Protocol
A person can buy a token (eg, with ETH) with a price set to a bonded curve (more supply == higher the price). A list of beneficiaries in the associated TCR also EARN additional tokens whenever someone buys in. The ETH is kept in a communal deposit pool. As usual to a bonded curve, any token-holder (buyers, beneficiaries, other users) can sell their token to get back some of the ETH in the communal deposit.
Beneficiaries are set by the TCR & are regarded as entities that help foster the network in whatever way: advocates, developers, hosters, etc. In order to earn tokens from people buying into the network, one has to prove that one is a reputable & useful beneficiary & that whatever tokens that are being earned for this role is going to be earned for the value one provides to the network.
The simplest version is that all beneficiaries are equal & earn an equal proportion of tokens. However, some beneficiaries might legitimately be more valuable and thus some proportional ranking system is likely more useful. Some more design work is necessary here.
Project Scaffolding
This combination of crypto-economic primitives forms its own cryptoeconomic primitive. Not sure what to call it, besides getting the sense that it feels like a bazaar combined with an amusement arcade. ;)
The basic utility is to scaffold projects more rapidly and to coordinate around the curation of information within it.
The token’s use does not have to extend past its use in staking to relevant information. However, this token can additionally be used for whatever is necessary in the network on top of the basic utility of information curation: eg, paying for file storage or whatever your network is doing. It can also be used in collaborative networks where whatever is produced can earn revenue and be deposited into the pool: eg decentralized bands, decentralized algorithmic games or decentralized protection of a commons.
Background
When I initially designed ‘Curation Markets’ (bonding curves + information staking), one of the initial goals was to figure out how we can more quickly scaffold & create projects (in any industry): a token was to be used for curating information with skin-in-the-game in order to help coordinate resources (time, attention, people, etc) around it.
One of the design questions in a curation market was: if you have one curation market, can you allow multiple beneficiaries to earn from it? When buying tokens, a specific beneficiary that aids the value of the curation market, ALSO receives token upon each purchase. They can then use those tokens to sell back into the bonded pool of ETH and use that to fund development or other things that aid the success of the curation market.
It *is* possible with the current implementation of a curation market, but has some issues.
When buying a token of a specific curation market, you can simply choose a beneficiary: eg, buying into an #ethereum curation market, you specify that Ethereum Foundation, Karl Floersch, ConsenSys or whomever should receive an equal proportion of tokens.
However, a problem with this is, is that it’s possible to easily attack this, by simply choosing oneself as a beneficiary and then cycling the money. If it is a poor choice, the market will reflect it, and the curation market could collapse. However, if there’s a malicious attacker, the cost to attack/squat in this manner is quite low.
I spent quite a few nights trying to devise various ways to ensure that this would be allowed, but essentially mitigate it as much as possible without unduly restricting money flowing to valuable beneficiaries. There were a bunch of things I tried to include: things called momentum grinding, drift burning, other various burn protocols, time locks, the works. It was rather Rube Goldberg, so I avoided it for now and rather wanted to see the simplest Curation Market implemented first, before optimizing the protocol.
With the advent of TCRs, it goes quite a way to make sure that one can avoid more malicious actors from earning through a curation market. The tokens bought in the network are staked into the TCR in order to become a beneficiary .You won’t mitigate all of the problems and it can still be squatted maliciously. It just makes it more costly.
Conclusion:
Using curved bonding & token-curated registries we can scaffold projects more rapidly: allowing any beneficiary chosen by the network to earn from the success of a continuous, tokenized project. There are various ways in which this can be plugged together, with different feedback loops across the board. Excited to keep experimenting.
Thanks:
Luke Duncan for 1Hive which inspired this extension. There are other similar designs being considered, but I don’t recall where I read it, or where I saw it. If this isn’t new, please let me know!
