Appchain attention economics: ctsi holders as part of the solution

Co-authored by @felipeargento

Introduction

Appchains are trending, and for good reason. The industry, as a whole, is aware that you won’t scale blockchains by running all applications on a single layer, be it L1 or L2, just like you won’t scale the internet by running everything in a single server. Appchain rollups, such as Cartesi, have taken this position from the beginning - but shared rollups are now also conforming to such reality (i.e. elastic chain, superchain). Many UX problems arise from this shift in paradigm, some require newfound solutions but some can be solved by existing concepts.

Opposed to Ethereum, where infrastructure is already set up for any new smart contract to be deployed, run, and validated by a previously established network, in an application-specific rollup, DApps do not get a network of node runners ready to run and support their application out of the box. It’s up to the DApp developer, or its more concerned users, to run their own node or seek the services of a professional node operator. This difference poses a significant user experience issue for developers and a big challenge when onboarding new applications to Appchain projects.

Ultimately, incentives always come to validators being paid for storing data and running computations, but here we have some additional challenges.

  1. Where to find node operators and how to distribute the application software? With appchains, each application runs its own software stack that has to be downloaded by validators before they can run computations and validate results.
  2. How will node runners know what DApps will generate demand? When validators share all applications, single application demand does not matter. But with appchains, validators that spend computer power running applications that are not used spend resources without being economically viable.
  3. How to figure out what is a fair price to pay for validation services. Without blockspace auctions like Ethereum uses, applications and validators can not achieve price discovery efficiently.

Fortunately, those kinds of challenges are not completely new and also appear in regards to indexing web3 data in a reliable and decentralized manner. Some protocols, like The Graph, proposed solutions that we can take inspiration from and apply to our universe.

The Graph is a protocol that was built to help with the challenging problem of indexing and querying blockchains in a decentralized manner. It’s a challenging problem that was tackled by a complex economic layer capable of identifying critical data flows and incentivizing a network of stakeholders to serve them. For that reason, they got nicknamed “the google of web3”.

One of the coolest aspects of how The Graph works is how it allows users with different levels of technical aptitude to participate in the system. For all the talk about creating communities in Web3, the industry still has not figured out ways for non technical people to contribute beyond holding tokens and participating in governance. We plan to change that.

The role of CTSI token

We’re proposing a validator marketplace, which is not mandatory to deploy and run applications in the Cartesi SDK, it’s just a matter of convenience. If this convenience is built as a public good for the benefit of the Cartesi community, it makes sense for all of its participants to care for the growth and health of the Cartesi ecosystem.

One way to make sure participants remain aligned with the same objectives is to use the CTSI token as incentive and to use it in a way that provides roles to multiple kinds of users with different technical capabilities. In this spirit, there are 3 proposed roles for CTSI:

  1. Stake asset to determine validator skin in the game.
  2. Delegated Stake asset for holders to back validators.
  3. Asset used for the application attention market.

Skin in the game for validators

As in any blockchain, validators have a great deal of importance for Cartesi applications. Even with fraud proofs ensuring that no incorrect results become final, there is still a big benefit in the happy path, without disputes that are expensive and delay settlement.

To make sure validators have a long term commitment to the ecosystem, we limit the number of applications they can service through the marketplace according to a slashable stake in CTSI that needs to be locked. In case of misbehavior, this stake can be slashed. The rationale is: the stake a validator is willing to risk is a measure of confidence it has in its own software and capability to run a well maintained node.

A possible issue with this solution is gatekeeping people that have great technical prowess but do not have disposable funds to match the number of applications that they could reliably run. This opens the opportunity for another community role: those that have funds but dont have the technical requirements to run a validator.

Those users can recognize capable node runners and delegate stake to them, increasing the validator participation limit. Delegating stake awards the backer with a percentage of the fees paid to node runners.

The Attention Economics Problem in Appchains

Anyone in the world right now could be deploying an app chain using Cartesi SDK. Maybe it will be an application with thousands of users that will generate a lot of validator fees, maybe it will be just a proof of concept and it will fail to get traction, it’s impossible to know for certain. With an increasing number of applications being deployed, it gets even harder for validators to gauge and predict what will become popular.

But the Cartesi community can help: everyone can have an opinion on the usefulness of an application, as opposed to the technical expertise necessary to run and maintain a node. If we give the opportunity for the community to have skin in the game, to profit when they find the right DApps before they go exponential, we have the wisdom of the crowds signaling to validators what will be worth validating.

To incentivize participation in the signaling of applications, it needs to exist a system of incentives with the following properties:

  1. Users’ rewards increase with application usage.
  2. The sooner the user decides to signal the application, the biggest share of rewards he should be eligible to gain.

Those two properties ensure that signalers select applications that will be relevant and that they do it as soon as possible, before the DApp becomes mainstream and the signaling becomes less relevant.

The first property can be easily achieved by sharing part of the validator revenue paid by an application with its signalers. For the second property we need to weight the revenue share by how early the signal was cast. A bonding curve mechanism that creates a market for those shares is the perfect solution.

A bonding curve is a concept often used in economics and blockchain technology to describe how the price of an asset changes based on supply and demand. It’s a mathematical function that defines the relationship between the quantity of a token or asset in circulation and its price.

Instead of relying on order books like in traditional exchanges, bonding curves facilitate buy and sell transactions by adjusting prices based on the curve’s formula. Because the price is always determined by the curve, users can always buy or sell tokens, which can help ensure market stability. The price usually increases as more shares are issued, incentivizing early adopters who buy when the price is lower.

The increase in price as more tokens are issued allows early participants to potentially benefit from the asset’s appreciation.

Example

Imagine a bonding curve for shares is defined by a quadratic function: P(s)=a s2, where P(s) is the price and s is the number of shares issued.

When s is small, the price is relatively low.

As s increases, the price rises more rapidly.

Conclusion

We believe this proposal can greatly benefit the Cartesi ecosystem by creating the right incentives and signals. By using CTSI as the coordination tool, DApps, users, and infrastructure providers can easily connect and function smoothly together. This approach fosters collaboration and efficiency, helping all participants in the ecosystem thrive. Shared incentives can unlock the true potential of appchains

We welcome your feedback and comments on this proposal. Your insights are valuable to us, and together we can enhance the Cartesi ecosystem for everyone’s benefit.

6 Likes

I like a lot this idea! Some comments/ideas:

  1. This initial investment, to incentivize an app to be picked up by validators, could be made by the DApp developer, the Cartesi Foundation, or random investors, right? It’s really cool to have this incentive mechanism be streamlined like that, allowing investors to be rewarded for funding successful apps!

  2. How does this relate to the Reader Node Marketplace proposal (Node Marketplace)? There are signallers there too, but over there instead of a bonding curve the idea was to reward signallers by giving them a share of query fees. So is this proposal here complementary, meaning that we would still use that one for readers, and this one for validators? In that case, do you envision the same node acting as both validator and reader, and participating in both mechanisms to get incentives from both?

Nice, thanks for the feedback!

I’ll give a shot in answering the questions, but bear in mind that nothing is written in stone. The idea with this proposal is to set the general framework and align our community around the goals and the problem to solve. If this is well accepted and we get a green light to move on, we’ll have to debate/figure ou the technicalities.

  1. This initial investment, to incentivize an app to be picked up by validators, could be made by the DApp developer, the Cartesi Foundation, or random investors, right? It’s really cool to have this incentive mechanism be streamlined like that, allowing investors to be rewarded for funding successful apps!

I wouldn’t call this an investment! But yeah, the incentivized dapp curation can be done by anyone. And, through the bonding curve mechanism, the earlier they identify a promising dapp the cheaper it is to get a piece of it’s action. This also creates an interesting dynamic for spreading the word: if you find a promising app and get on it’s bonding curve, you’re now incentivized to let everyone know how cool that app is.

  1. How does this relate to the Reader Node Marketplace proposal? There are signallers there too, but over there instead of a bonding curve the idea was to reward signallers by giving them a share of query fees. So is this proposal here complementary, meaning that we would still use that one for readers, and this one for validators? In that case, do you envision the same node acting as both validator and reader, and participating in both mechanisms to get incentives from both?

I believe that we’re bundling together the validator and the reader. The logic is the following: if you’re offering reader services, you’re heavily incentivized to also validate those dapps (it’s basically free). So I believe the query fees still apply.
I believe the rational choice is for the service providers to be both readers and validators, as you suggested!