How to Join the 80k Program and Build a dApp on Linux with Cartesi

The phrase 80k program refers to a funding and support initiative that has been associated with Cartesi, a framework for building decentralized applications. The name suggests a figure, but this guide does not treat any amount as confirmed. Public reporting used for this article did not return official program material, so the terms, eligibility rules and deadlines should be read directly from Cartesi's own published sources.

This guide is an explainer. It covers what Cartesi is, why its Linux-based approach matters to builders, how to check whether a program is current, how to prepare a solid application, and how to avoid common scams. It also describes the general steps a developer can take even if the program is closed or changed when you read this.

If you are new to dApps, it helps to separate three ideas. A dApp is an application whose logic runs on or alongside a blockchain. A framework is the toolkit you use to write and deploy that logic. A program is a support scheme, often with grants, mentoring or technical help, that a project may offer to selected builders. Each has its own requirements, so confusing them leads to wasted effort.

Cartesi is a development framework for decentralized applications. Its main idea is that application code can run inside a full Linux environment, so developers are not limited to a single chain-specific language. Instead, they can use mainstream tools and libraries that run on Linux, then connect that logic to a blockchain through a rollup design.

In practical terms, this approach can make it easier for experienced software engineers to reuse skills they already have. Teams familiar with common open-source languages and standard Linux utilities can often prototype faster than teams that must learn an unfamiliar execution model from scratch.

Rollups are a scaling approach where transactions are processed off the main chain and then posted or verified in a way that keeps the base chain as the source of final settlement. Cartesi uses this general idea, and readers should consult its documentation for the current architecture, supported features and limits, since these change as the project develops.

For a builder, the key question is fit. Ask whether your application needs heavy computation, existing Linux libraries, or logic that is awkward to express in a typical smart contract. If yes, Cartesi may be worth evaluating. If your project is a simple token or a standard lending pool, a native contract approach may be simpler.

Before you spend time on an application, confirm the program is current and read its terms in full. The most reliable source is the official Cartesi website and its verified social or developer channels. Public reporting, forum posts and reposted messages can be outdated, so treat them as leads rather than facts.

Use a simple checklist:

• Who runs the program, and is that organization clearly identified on an official Cartesi page?
• Is there a written application window with start and end dates?
• What does the program provide, such as funding, technical support, mentoring or visibility?
• Are there eligibility rules about location, age, legal status or project stage?
• Do you retain ownership of your code, and what licence applies to it?
• What reporting, milestones or obligations come after acceptance?

If any answer is unclear, ask through the official contact method listed by Cartesi, and keep a record of the reply. Do not rely on a summary from a third party when the primary terms are available.

Also check whether any payment is described in tokens, fiat, or a mix. Token-based rewards can change in value and may carry tax or regulatory consequences in your jurisdiction, so note that before accepting anything.

Programs like this typically look for builders who can show a clear use case and the technical ability to deliver it. Developers with some Linux experience, familiarity with backend or systems programming, or a background in blockchain tooling are often better positioned. Students and independent developers can also apply if the terms allow it.

The program name does not guarantee a place for everyone who applies. Reviewers usually weigh whether the idea solves a real problem, whether the scope is realistic for the time available, and whether the team can explain its architecture. A narrow, well-explained project often beats a broad vision with no prototype.

Consider these questions about your own situation:

• Do you have a specific user or workflow in mind?
• Can you build a minimal version within a few weeks?
• Have you used Linux command-line tools, containers or common build systems?
• Do you understand the basics of rollups and how state is posted or verified?
• Can you commit time for the duration of the program?

If you cannot answer most of these yet, spend time on the Cartesi documentation and small experiments first. That preparation usually improves an application more than rushing to submit one.

A reliable setup makes early progress much faster. Start with a Linux machine or a Linux virtual environment, since that is the platform your application will target. Install a current version of your chosen language toolchain, along with version control and a code editor you already know.

Follow the official Cartesi installation guide for the current toolchain and command-line tools. Install the exact versions the documentation specifies, because mismatched versions are a common source of confusing errors. Keep a short notes file that records each version, each install step and each problem you solved.

A practical setup often includes these steps:

1. Create a fresh project directory under version control.
2. Install the Cartesi tools as described in the current guide.
3. Run the example project included in the documentation without changes.
4. Confirm you can build, run and test it locally.
5. Only then begin modifying the code for your own idea.

Running the unmodified example first separates environment problems from your own bugs. It also gives you a known-good baseline. Save that baseline so you can return to it if an experiment breaks.

Your first build should be small enough to finish and test. Choose one function that shows the value of running Linux-based logic, such as a computation that would be expensive in a standard contract, or a workflow that uses an existing open-source library. Avoid building a full product, a token economy and a user interface in the first version.

A useful sequence is to define inputs and outputs first. Write down what a user sends, what the application must compute, what state it stores and what result it returns. Once that is clear, implement the logic in plain code and test it on your local machine before connecting it to a rollup.

Testing should cover normal inputs, invalid inputs and edge cases. Write automated tests where you can, and record the expected results. If your application depends on external data, decide how you will supply that data deterministically, because blockchain applications need predictable results to be verified.

Keep the prototype honest. Document what works, what is simulated, and what is not yet built. Reviewers and future collaborators will trust a clear limitations section far more than a claim of completeness.

A strong application reads like an engineering plan. Start with the problem in one or two sentences, then describe the users, the workflow and why a Linux-based approach is needed. If an existing dApp or tool solves part of the problem, say so and explain what your project adds.

Include these sections in your written application:

• Problem and target users
• Proposed solution and scope for the program period
• Architecture diagram or short description of components
• Current progress, with a link to a repository if the program allows it
• Milestones with realistic dates
• Risks, including security, dependencies and timeline
• Team roles and relevant experience

Avoid vague claims about performance or market size unless you can support them with evidence. Do not promise token prices, user numbers or partnerships. Describe what you have built, what you will build, and how you will know it works.

If the program asks for a demo, make it short and reproducible. Reviewers should be able to run it from your instructions without needing private access.

Scams often copy the names and logos of real programs. Protect yourself by following a few defensive habits.

Never share your seed phrase, private keys or wallet recovery phrase with anyone, including people claiming to be program staff. A legitimate program does not need access to your wallet. Do not install software or browser extensions sent to you by direct message.

Be careful with these warning signs:

• Requests to pay a fee, deposit crypto or buy a token to qualify
• Urgent deadlines designed to stop you from checking
• Links that do not match the official domain you reached directly
• Contacts who reach out first on social media or messaging apps
• Offers that promise guaranteed funding for any application

When in doubt, close the conversation and go to the official Cartesi website by typing its address yourself. Use a separate wallet with limited funds for any testing that involves transactions, and keep your development keys apart from holdings you cannot afford to lose.

Programs can be closed, renamed or changed. If you find that the 80k program is no longer accepting applications, you can still use the same path to build a Cartesi dApp. The skills, prototype and documentation you produce remain valuable for future programs, grants, or your own open-source work.

Start by re-reading the current official Cartesi documentation and community resources. Look for updated examples, changed toolchain versions and any new support channels. Frameworks evolve, so an example from an older article may no longer run as written.

A sensible plan for the next few weeks might include:

1. Confirm the current status of the program on official pages.
2. Build and run the official example on your Linux system.
3. Choose one narrow use case and write its specification.
4. Implement and test a minimal prototype.
5. Publish clear documentation with known limitations.
6. Track any future program announcements through official sources.

If you later want to connect your application to other parts of the ecosystem, research the tools involved before committing. Read each project's own documentation, check its current status, and understand the risks. Keep your focus on building something you can explain and maintain.