Writer’s note: this may not exactly be a “cryptoeconomic” mechanism, but this category seems like the best fit for now, and I wanted to get this idea down in writing.
Suppose that we have a bond mechanism whereby users lock up a token in a long-duration bond which they cannot immediately withdraw. Proof-of-ownership of this locked bond can potentially be used as a Sybil-resistant authentication mechanism for service requests which require some (moderate) resource consumption to process, such as network relay, storage, compute, and transaction processing. A candidate mechanism could work roughly as follows:
- Suppose a fixed period length P, a fixed “service credit cap” C of C “service credits” per period P, and a minimum bond threshold B tokens.
- Any bondholder with a bond of at least B tokens can then compute up to C service request authentication tokens per period P by using (a) knowledge of their bond, (b) knowledge of the current service credit nonce of that bond (reset to 0 each P), and (c) knowledge of the service request which they wish to authorize.
- Any service provider can validate a service request authentication token which they receive along with a service request, which ensures that service request was authorized by a bondholder with at least B tokens who still had unused service credits for period P.
- Note: technically, this requires a canonical ordering of service request authentication tokens. This could be achieved by publishing those tokens to some specific ordering location, but this might be expensive. Instead, we can probably just use the bond amount which is already at stake to secure these requests (where conflicting token use would be slashable).
Now, why would service providers be willing to accept these tokens? The only baseline guarantee provided here is Sybil resistance. There might be different reasons, for example:
- Service providers might want to support the network as a whole.
- Service providers might want to offer “trials” of their service to bondholders to build their reputations (where more serious service requests would require separate purchases).
- The network as a whole might agree to deals with service providers where the network would pay for a service provider to offer a minimum level of services to all qualifying bondholders (which theoretically should provide more predictability for the service provider and thus potentially a better price for network bondholders).
From a user perspective, I think the primary benefit of this kind of approach would be simplicity of the overall offering – if you hold a token bond of a sufficient amount, you could receive basic storage, compute, network message relay, and transaction ordering for free (at least from the bondholder’s perspective). This is similar to the guarantees that banks etc. will typically offer of “X free transactions per day/month” which covers most users’ actual usage.
Could bondholders sell these service authentication tokens to third parties? Yes, but they’d have to run an online service (to accept requests and generate authentication tokens), as the authentication tokens are bound to the specific requests. If the services themselves are not terribly expensive, the transaction costs and risks of doing this probably wouldn’t be worth it. Even if some bondholders choose to do this, the basic guarantee (of free basic services) for others would remain.