[RFP #002] Validator Watcher in Typescript


To validate Cartesi DApps, validators use validator nodes. The current implementation, written in Rust, is responsible for ensuring that the Cartesi DApp (defined in the node’s configuration settings) is correctly settling in the baselayer. Given the critical nature of providing validation to a DApp, we need to adopt a multi-client strategy to safeguard against implementation-specific bugs. Therefore, we are looking for an implementation of the validator node in a different programming language to reduce the likelihood of such bugs occurring.

We are seeking proposals from builders to develop the initial steps towards realizing this multi-client strategy. Specifically, we want a Validator Watcher in Typescript. The goal of this RFP is to encourage proposals that provide a clear roadmap for the development of a Typescript-based Validator Watcher that can double check the results given by the existing Rust-based validator node.

Your proposal should provide a detailed explanation of the technical approach you intend to take, along with a project plan that outlines milestones, timelines, and budget requirements. Additionally, we require that you highlight any potential risks or challenges that may arise during the implementation process, and provide contingency plans to mitigate these risks.

We encourage all interested builders to submit their proposals and join us in making this multi-client dream a reality.

Scope of the work:

The team will be responsible for building a client, written in Typescript, that is capable of calculating the claim hash of a Cartesi DApp deployed on a blockchain. The program should adhere to the following requirements:

  • Accept a configuration file containing the template hash of the Cartesi DApp, the addresses of the Cartesi DApp, the chain to which the DApp was deployed, and the epoch duration.
  • Accumulate “Input Added” events for the Cartesi DApp specified in the configuration file.
  • Connect to the Server-Manager using GRPC (grpc-interface).
  • Start a session with the correct parameters using the Server-Manager.
  • Replay a DApp’s history by sending “advance requests” for each input added and “finish epoch” requests based on the epoch duration and input timestamp.
  • Calculate the claim hash for each “finish epoch” request and provide it as output.

In addition to the above requirements, the proposal should outline any additional features that the team intends to include, as well as a detailed project plan outlining milestones, timelines, and budget requirements. The proposal should also highlight any potential risks or challenges that may arise during the implementation process and provide contingency plans to mitigate these risks.

The team will be expected to deliver a fully functional client that meets the specifications outlined above within the agreed-upon timeline and budget. The client should be well-documented, thoroughly tested, and include user-friendly instructions for deployment and use.


  1. An executable program that receives a configuration file and generates the claim hash for each finished epoch. The program should be fully functional, well-tested, and adhere to the specifications outlined in the RFP.

  2. Source code of the program with a permissive license (open source). The code should be well-structured, easy to understand, and fully documented to facilitate future maintenance and development.

  3. A comprehensive README document outlining how to install, configure, and use the program. The README should include clear instructions on how to run the program, how to specify the configuration file, and any additional information that may be useful for end-users.

  4. A test suite that includes unit tests, integration tests, and end-to-end tests to ensure that the program is robust, secure, and reliable. The test suite should be well-documented, and the results should be included in the technical report.

  5. A user manual that provides step-by-step instructions on how to use the program and troubleshoot common issues that may arise. The user manual should be written in plain language and be accessible to non-technical users.

Tech Requirements:

  1. The program should be written in Typescript, with a well-organized and documented codebase that adheres to industry best practices and coding standards.

  2. The program should have comprehensive test coverage, including unit tests, integration tests, and end-to-end tests, with a minimum code coverage of 80%. The test suite should be automated and should run as part of the build process to ensure that any code changes do not break existing functionality.

  3. The program should implement error handling and logging mechanisms to facilitate debugging and troubleshooting.

  4. The program should be scalable and able to handle a large number of input added events and finish epoch requests without degrading performance.

  5. The program should implement a backup and recovery strategy to protect against data loss or system failures.

  6. The program should be compatible with Cartesi’s server manager and be able to communicate with it using the GRPC interface.

Submission Requirements

  1. A detailed technical proposal that includes a description of the validator node, its architecture, and how the proposed solution will integrate with the existing Cartesi ecosystem.
  2. An overview of the development team, including their relevant experience and expertise in software development, blockchain technology, and any other relevant fields. This should include resumes or CVs of team members and a summary of their roles and responsibilities in the project.
  3. A detailed project plan with a timeline for the development and delivery of the program, including milestones, deliverables, and estimated completion dates.
  4. A detailed cost estimate and budget breakdown that includes all costs associated with the development of the DApp, including salaries,software costs, and any other expenses. The budget breakdown should be transparent and should include a justification for each cost item.
  5. Any additional information or materials that may be helpful in evaluating the proposal, such as whitepapers, case studies, or technical specifications.

By providing these submission requirements, you will help Cartesi to evaluate your proposal more effectively and make a more informed decision about selecting a development team for their project.

Bidding instructions

Interested teams should confirm the intention to submit a proposal and express their needs to the Cartesi Foundation.

The Cartesi Foundation is happy to help address any questions, share helpful resources, or advise on formulating the team’s proposal.

We are excited to see your proposals and work together towards the growth of the Cartesi ecosystem!


Hello. How do I submit a proposal for this?

You can submit a proposal here:

Just create a new thread with your proposal :slight_smile:

UPDATE: At the moment, the Grants Council is no longer pursuing proposal submissions for this RFP. In the meantime, teams and contributors can apply to receive a grant through any of the four areas of focus for Wave 1. Learn more about Wave 1 here.