Utility Credit — Fixing Crypto's Tragedy of the Commons Problem
Background
The tragedy of the commons is an economics problem in which every individual has an incentive to consume a resource, but at the expense of every other individual—with no way to exclude anyone from consuming.
Restated to fit the context of dapps with tokens (and taking a page out of FT):
A problem where everyone wants to benefit from the success of a project — expressed in its token — but most are unwilling to risk anything or put in tangible effort to achieve that goal because they believe it's "someone else's problem" while still (feeling entitled to) actively extracting any value generated by the few.
This piece will have a somewhat atypical structure. That is intentional.
The Solution
This proposes a superset of standard ERC20 token that has an added internal meta-currency — credit — that controls transferability of the token based on each holder's utilization of the associated dapp. Hence, Utility Credit.
There are three key components involved:
credit
credit source(s)
the utility token (UT)
Credit
The internal meta-currency, tracked similarly to account ERC20 balances, that distinguishes this token type from a standard ERC20 token.
Transferability of a UT is altered depending on if it's to/from a credit source and also if it's by an externally-owned account (EOA) or contract account (CA). Generally:
An EOA/CA must have a credit balance equal to or more than the amount of tokens being transferred
The sender's credit balance is always reduced by the amount of tokens transferred, or down to zero
If the sender is an EOA, the recipient's credit balance increases by the amount of tokens sent
If the sender is a CA, the recipient's credit balance is unchanged
Things changes a bit when a credit source is involved, explained in the next section
An optional but strongly recommended feature is credit transfer fees. Similar to transfer fees in some tokens today, this involves levying fee on the credit amount being transferred i.e. the recipient receives some amount of credit minus the fee. This serves to prevent entities like CEXs, which (allow people to) perform "transfers" off-chain, from bypassing the need to utilize a credit source.
Credit Source
A credit source is a CA that grants credit to users (CA or EOA) when utilized. There can be multiple credit sources.
In practice, there is one credit source that is not a CA: the deployer. Tautologically, the deployer is a credit source by virtue of being the deployer. The deployer creates all CA credit sources users are expected to utilize, as well as implementing the actual logic of how much credit a user earns from an interaction.
Being granters of credit, credit sources have infinite/limitless credit, and also affect transferability of a UT in other ways:
A credit source can transfer any amount of its token balance regardless of its credit balance
An EOA or CA, regardless of its credit balance, can transfer any amount of a UT to a credit source
Unless by design (in the case of a CA) or by choice (in the case of an EOA), transfers from a credit source grant the recipient full credit for the amount received
Utility Token
The superset of the standard ERC20 with an internal meta-currency, credit, that alters how transferability works.
Of note, a Utility Token cannot exist for its self i.e. there must be some utility, from which credit can be earned, hence Utility Token. Without that, it would simply be a non-transferable token.
Being a superset of the standard ERC20, the UT inherits all of its basic functionality. However, it modifies them where necessary — such as transfer(), mint(), and burn() — to account for the credit internal meta-currency. A UT also provides an interface to query the credit balance of accounts.
Benefits
There are many benefits to this design and perhaps more to be discovered than will be listed here.
User Alignment
As will be further explained in The Problem below, tokenized dapps today broadly have 3 distinct groups: users, "community members", and token holders. All things being equal, users are the group that makes any dapp that hopes to have a chance at genuine success tick. Despite this, users are consistently outnumbered by the latter groups that contribute comparatively little value yet (feel entitled to) extract it. Squeezing anything remotely sustainable out of such a system becomes a Sisyphean task that's almost guaranteed to fail sooner or later.
This proposal doesn't eliminate these latter groups as that is neither practical (in a decentralized fashion) nor necessary. If you've been paying attention, you've probably also noticed this also proposal doesn't quite "fix" the ToCP. No. What it does is a bit more subtle: it eliminates the negative externalities that arise from allowing non-contributing token holders run free. Simply, only users — who've generated tangible, objective value — can extract it. Non-contributing/tourist token holders are entirely neutered.
MEV & Grift Capture
A common issue, at least with respect to tokenized dapps, is MEV. The most prevalent example of this is sandwich attacks.
This design does not eliminate this problem. What it does, though, is essentially erect a retractable wall in-between these activities and, to the extent that the perpetrators are unwilling to play by the same rules, have that value be captured by real users. Where a "large" acquisition of a basic ERC20 would be trivially sandwichable by some MEV bot — resulting in said bot extracting value at the expense of the buyer and preexisting users — a UT would capture this and retain the value for actual users.
This also applies to drive-bys — entities with no interest in the project but, perhaps because of some 3-eyed raven signal on some chart, pick the token to quickly extract some value.
Robust Tokenomics
What are known as "utility tokens" today have quite a few issues. Chief among them is the fact that whatever tokenomics they propose is inherently leaky — it is not enforced programmatically across the entire token supply. Instead, there's a lot of reliance on coaxing people to "do the right thing" but this is as flawed as a novel consensus model with a core assumption of "assume honest actors".
The design proposed here removes the subjectivity of what constitutes contribution of tangible value from the equation, plugs the leaks, and programmatically encodes a level playing field for all actors in the system. With that as a base, more robust and non-leaky tokenomics that are actually about utilization rather than dealing with free-riders can be actually be built on top.
Stickier Incentivization
Airdrops, liquidity mining, "yield farming", etc. There's a lot people do today in an attempt to turn token holders of normal ERC20s into users, especially for more than the latest trend.
In traditional liquidity mining, the usual strategy is some sort of inflation-based compensation scheme. But it need not be reiterated here that all that does is engage in a race to zero and almost exclusively attract mercenaries. A tweak of this is often some partnered "yield farming" program with DEXs but the end result is the same or worse. More recent alternatives involve so-called bonding systems with debatable efficacy.
From the design proposed here, a third path (that might be obvious already to astute readers) emerges: earning credit. The existence of liquidity is a core feature every user should be concerned with, not one that should be "othered" to someone else to worry about.
On the matter of airdrops, there is the sybil problem. Sybils are, however, a natural consequence of decentralization and cannot be eliminated without compromising on this. What this design offers instead is ensuring that, should one do this, they will need to pay the cost for each sybil as though they were distinct parties.
Conclusion
Aaaaand that's enough talk for now. To see a first, practical implementation of a utility credit token, check out Wrapped USD. It is, again, a first case, so caveat emptor.
The Problem
To reiterate the point made in Background:
A situation where everyone wants to benefit from the success of a project, expressed in its token, but few are willing to risk anything or put in any tangible effort to achieve that because they believe it's "someone else's problem", and yet have no qualms (feeling entitled to) extracting any value that arises
Tokenized "dapp" projects have a tragedy-of-commons/free-rider problem.
The lifecycle of a somewhat model dapp project with a token (sans external/corporate funding) is roughly:
ideation
building
launch + token distribution
You're likely familiar with what comes next — the "wen?"s and "why?"s. "wen liquidity", "wen marketing", "why no users?", "wen roadmap", "why dump?", etc.
The absurdity of this is generally (and perhaps unsurprisingly) lost on the people asking but there's something uniquely ridiculous about what should be the core "stakeholders" of a project expecting "someone else" to take on risk on their behalf. Yet they aren't entirely at fault as this allowance is afforded by the design of current tokens, captured exquisitely by the entitled mantra: "don't marry your bags". You see, despite the oft-repeated claim that "great tokens align incentives across all stakeholders"
it takes for granted the disparate "stakeholders" that exist, which are generally:
users — actually use the dapp; may have tokens
"community members" — exist in/form the socials of the project; generally hold tokens but rarely use the dapp
token holders — self-explanatory; rarely, if ever, use dapp
If one is merely a token holder — perhaps due to a 3-eyed raven signal on some chart — or simply a "community member" that spends the bulk of their time repeating the usual trite commentary in a chat, and still get to benefit from by being allowed to extract value produced by actual users, what's the incentive to take on tangible risk by becoming a user?
Expecting people to do so because "it's the right thing" and "everyone benefits" is a naïve proposition — on par with a consensus model that is based on "assume honest actors" — because you leave yourself open to being taken advantage of by opportunists and grifters passing through simply looking to make a quick buck. Because tokens, as designed today, do not programmatically enforce the need to use in order to extract value, would-be users are encouraged to be free-riders, and free-riders so entitled that they expect benefits for simply existing. Make no mistake, this is hardly unique to crypto; on the contrary, there is a name for this from the torrenting space: leeching
Since there is no dedicated server distributing the content, everyone wishing to obtain the file relies on the fact that there will be some subset of users who already have the file and remain active to “share” (upload) with everyone else. In other words, these people, who initially sought to obtain a copy of the file for themselves, do the “right” thing and continue distributing the file to others.
Today, BitTorrent is one of the most widely used protocols for sharing files via P2P networks, or “torrenting”. As a result, the most significant threat it faces is something know as the free-rider problem. In P2P systems, a free-rider is a user who obtains the file from the network without contributing any of it back. This prompts questions of unfairness to the remaining participants who actually contribute ... although most users are altruistic and end up contributing back without much hesitation, there are always those who will “leech” — obtain the file for themselves and then leave without giving back.
Attempts to paper over this fundamental flaw yields things like the form of "staking" that is really a euphemism for paying people to not sell
obviously illegal securities that effectively give people money for doing and/or contributing nothing of value, and various other absurdities. None of these band-aids fix the problem and can only, at best, delay the inevitable.
Most people would agree that it's logical for (legal) onchain securities to enforce KYC requirements on the entire token supply, that fiatcoins enforce ~1:1 convertibility for the entire token supply, that native tokens of platforms are a prerequisite for transactions, and that even NFTs enforce uniqueness. Yet what we call "utility tokens" today are hardly anything of the sort — there is no enforcement that they actually be utilized within the context of their associated applications. This isn't without consequence as it is especially bad for real users and people that actually do care about the projects. In that sense, there is wisdom in the mantra: "don't marry your bags".
Last updated