Allow Cartesi DApps to access base layer state

Cartesi DApps advance their state when they receive inputs, which currently correspond to arbitrary payloads sent via the InputBox contract on the base layer (L1).

In order to process any data from the base layer, currently the only possibility is to add a smart contract to explicitly relay information to the DApp in a trusted manner. For instance, to acccess the price0CumulativeLast variable of a UniswapV2Pair contract, you currently would need to deploy a UniswapRelay smart contract, with a method like relayPrice0CumulativeLast(address pair, address dapp). This method would then retrieve that variable from the specified pair, and add an input to the DApp with that information. The DApp back-end would have also have to be coded to explicitly trust inputs coming from UniswapRelay’s address, and know how to process them.

This approach dramatically limits the amount of integration that Cartesi DApps can have with the base layer. Allowing more general access would open up a wide range of capabilities for Cartesi DApps, including the following:

  • DApps that take advantage of the Cartesi Machine’s computing and programmability power to do all kinds of analytics over base layer data. This is particularly rich for DeFi, allowing things like DEX analysis tools (like this proposal) and all sorts of risk analyses (e.g., to enable smart lending with conditions calculated according to each client’s profile). It may also be very interesting for base layer governance, since it would trustlessly allow thorough inspection and analysis of its own state. Maybe even things like TheGraph could be done via a Cartesi DApp.

  • DApps that respond to transactions that are not explicitly aware of them. It would become possible for DApps to receive base layer block hashes as their inputs, and from there access any desired general base layer state from that block or prior blocks. This way, DApps could respond to activity on e.g. Uniswap, without that activity having to be aware of the existence of Cartesi!

  • Allow sequencers such as Espresso to be properly used. When using those, inputs generally arrive from outside the base layer (e.g., from an Espresso network). However, inputs that relay critical information from the base layer, such as deposits, still need to be processed. The correct way for a Cartesi DApp to process data from both sources is to have it access the sequencer commitment on L1 as well as any other base layer input of interest (e.g., the InputBox). Without general access to base layer data, we would need to have some client observing sequencer commitments, and explicitly relaying every commitment to the DApp

Implementation-wise, the way forward to achieve this funcionality is clear: a dehashing device with a namespace for the base layer (e.g., namespace “ethereum”). The most basic primitive would be for the device to return block data given a block hash, and allow navigation from there throughout the blockchain state. However, there are open questions as to how to make this more usable for DApp back-end code, including whether we would allow access to contract storage, blockchain events, or both.


I fully support this vision! Making it a reality could transform Cartesi into a powerful choice for today’s web3 developers.


This also could allow to access data from different networks too, right? It sounds like a first step into making multi chain DApps possible.

From my view, I was always troubled by how dApps out of the “same ethereum busbar” could properly read information and identify inputs, rather than only the ones available on the input box.
Such capacity is paramount for developers to build useful applications to serve the baselayer as well.

I fully support this initiative

Great post! I fully support the initiative.

One possible first step towards this vision could be to just use the dehashing device as an input oracle in the beginning.

This would not bring all the benefits you mentioned (it would basically give no extra features yet). But it would be much more modular. People could experiment with different oracles (like Espresso, Uniswap…) without much difficulty (if the API is well designed). @GCdePaula made a very nice proposal for such an API.

From there we could start getting everything through dehashing of block hashes (including inputs).

Great thanks for the comment @Augusto !

Could you give a pointer to this API specification? I’m curious!

DApps that respond to transactions that are not explicitly aware of them

One nice consequence of this is that applications could be aware of deposits without the need of specialized relay contracts, the so-called portals. Users could simply transfer assets to the application contract, and the back-end would be able to detect deposits through events emitted by token contracts after the last processed block. This way, users wouldn’t need to explicitly set an allowance to the portal contract beforehand.

1 Like

This is the one, I think:

Added a specific entry for the Dehashing Device itself, comments welcome!