Reader Node Marketplace


This proposal is about reader nodes only, not claim posting validators. So when thinking about end users or DApps, it’s useful to think of a front end website that wants to display information about one or more DApps.

Being an application-specific rollup, DApps deployed with Cartesi do not get a network of node runners ready to run and support the application out of the box. It’s up to the DApp developer to run its own node or seek the services of a professional reader node operator.

Right now, the only way to get professional operators is through a bilateral agreement, which brings some challenges:

  • Where to find node operators?
  • How to monitor the reliability of available operators?
  • How will node runners know what DApps will generate demand?
  • How to figure out what is a fair price to pay for read queries?

Proposal goals

We propose a reader node marketplace that matches reader demand (queries) to reader nodes, taking into account node capacity, reliability, and costs. This match should be accompanied by a reward system that incentivizes fair price formation and integrity of the information provided.

This proposal aims to describe the simplest components that achieves the stated goals so we can get a functional version out as soon as possible. Each component can grow in complexity and be replaced for future versions to achieve additional goals or improve the product according to community and stakeholders feedback.


  • Match nodes and applications (per demand).
  • Incentivize proper reporting.
  • Provide Fair price formation.
  • Incentivize participants that have vested interest in the Cartesi ecosystem.

This proposal is about convenience only: Participation by application/frontend developers or node runners is not supposed to be mandatory. It will always be possible to bypass the marketplace and run a node independently or agree bilaterally with a validator.


Additional read: The Graph documentation can provide more context for some concepts laid out for those components as there are a lot of similarities in what we are trying to accomplish.

Application discovery

Applications that are popular in the Cartesi ecosystem or more useful to the community should be prioritized. Also, they need to be on node runners’ radar so a lot of operators can be ready and available to run them at any time. We need to allow users to signal with their tokens what DApps should be on top of the list.

If those signalers get rewarded with part of the query fees, they are incentivized to report their true beliefs about the application’s usefulness and if we make the reward bigger for early signalers we can incentivize a network of users that scan the ecosystem for new DApps with potential and bring them notoriety.

Additionally, we can use CTSI as the currency to signal, ensuring that signalers have an incentive to choose applications that will be useful to the Cartesi ecosystem.

Reader node stake

To ensure that node runners will provide good information, they need to be liable for untruthful reporting. So there has to be a mechanism to financially punish nodes that misbehave. We propose a stake that can be slashed if needed.

The ability to fulfill queries of a node should be limited as a function of their stake, as the potential damages increased with the number of queries.

It’s also convenient to use the CTSI as the staked token, creating an additional incentive for good behavior since node runners will (literally) be stakeholders of the ecosystem.

Gateway/load balancer

The gateway redirects the queries from applications to nodes. The job of the load balancer is to receive a query, check what awaken nodes can run the necessary application, and distribute to the node according to some criteria: price, round robin, etc.

The gateway provides front end developers with a single entry point to send queries without needing to know individual validators.

1 Like

This is a great proposal! I believe that a robust marketplace framework for node runners is fundamental for Cartesi and app-chains in general.
Eager to hear more details about possible incentive mechanisms, and how you imagine payments being done.

There are a few things I really like about this proposal:

  • The ability to have a sort of prediction market for the popularity of a dapp, which can help a lot to navigate a scenario with lots and lots of appchains.
  • The match between demand and node supply, which will help deal with ghost chains - which, I guess, tend to be even more prevalent in the web3 space.
  • The existence of a mechanism to slash misbehaving readers, which is a real problem in the web3 reader space (infura, alchemy etc) afaik.

This will add quite a cool convenience layer for deployment of dapps and node running.

In the spirit of “getting a functional version out as soon as possible” what is the relation of such proposal with the definition of the authority validator of an application. Is the validator also under the gateway? Or is the validator outside of this proposal completely?

The cartesi rollups node 1.4 has capabilities to disable validation. So it’s possible to run a node without the validator “role”. But it does not have the capabilities of running a node only for validation. The reader role is always there.