> For the complete documentation index, see [llms.txt](https://docs.projectcatalyst.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.projectcatalyst.io/open-funding/funding-basics/technology-readiness-levels.md).

# Technology Readiness Levels

## Technology Readiness Levels (TRL): what we ask, and why

### What TRL is

Technology Readiness Level (TRL) is a 1-to-9 scale for how mature a technology is, from a bare idea (1) to a proven, in-production system (9). It was created by[ NASA](https://www.nasa.gov/directorates/somd/space-communications-navigation-program/technology-readiness-levels/) and is used widely in innovation funding, notably[ EU Horizon Europe](https://ec.europa.eu/info/funding-tenders/opportunities/docs/2021-2027/horizon/wp-call/2023-2024/wp-13-general-annexes_horizon-2023-2024_en.pdf), as a common yardstick so everyone means the same thing by "early-stage" or "ready." We use it here to set a clear entry bar and to help you place your own work honestly.

Sources: the formal level definitions come from[ NASA's TRL definitions](https://esto.nasa.gov/files/trl_definitions.pdf) and the[ Horizon Europe General Annexes](https://ec.europa.eu/info/funding-tenders/opportunities/docs/2021-2027/horizon/wp-call/2023-2024/wp-13-general-annexes_horizon-2023-2024_en.pdf). The Cardano interpretations below are ours, adapted for on-chain software.

The one translation that makes TRL concrete for Cardano: the scale talks about a "relevant environment" and an "operational environment." Read **relevant environment as a public testnet (Preview or Preprod)** and **operational environment as mainnet**. Hold those two anchors and the levels are easy to place.

### What we ask, and what we gate on

This pilot is for **teams with a mature product** who want to add a Cardano area of interest (an oracle, a stablecoin, CIP-0113 programmable tokens, or CIP-0170 identity) to it. So we ask two readiness questions, and only one of them is a bar:

* **Your existing product's TRL, this is the gate**. Your product must already be real: validated on a public testnet or live, in the Cardano ecosystem or another. In TRL terms, **TRL 5 or above**. This is how the pilot funds established teams rather than idea-stage ones. Your product does not need to be on mainnet, and it does not need to be on Cardano; a testnet-validated product or a product live in another ecosystem both qualify.
* **Your proposed integration's status, this is context, not a bar**. The integration is the new work this grant funds, and when the grant is announced it usually doesn't exist yet. That is expected. We ask where it stands so we understand how much ground the grant covers, but we do not gate on it. Its feasibility is judged by your architecture and your milestone plan, not by a readiness number.

In one line: **you qualify on your product's maturity; the grant funds your new integration**.

### What the grant pays for

A mature team (product TRL 5+) is funded to build a new Cardano integration **from the ground up to mainnet**, and then rewarded on the real usage it earns. Mapped to the three payments:

* The **build payment** funds carrying the integration from wherever it starts, often nothing, to **mainnet (TRL 7)**. Reaching mainnet is Milestone 1.
* The **adoption payment and kicker** reward it climbing from mainnet-live to **real, sustained usage (TRL 8-9)**, measured as network fees from real users.

The grant buys the climb, not the starting point. Mainnet is not an entry requirement; it is the finish line for the integration.

### The nine levels, and where you sit on them - readiness of your product

<table data-header-hidden data-search="false"><thead><tr><th width="77.2578125"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>TRL</strong></td><td><strong>Standard meaning</strong></td><td><strong>What it looks like on Cardano</strong></td></tr><tr><td>1</td><td>Basic principles observed</td><td>You've spotted that a Cardano primitive could solve a real problem. Idea and research only, no code.</td></tr><tr><td>2</td><td>Technology concept formulated</td><td>You've designed the approach: the architecture, which primitive, how transactions flow. A spec or design doc; no working code yet.</td></tr><tr><td>3</td><td>Experimental proof of concept</td><td>A core mechanism actually runs in isolation, a validator, script, or key function does the thing in a test harness or local devnet.</td></tr><tr><td>4</td><td>Validated in the lab</td><td>The pieces work together end-to-end in a controlled development environment (a local node or private devnet).</td></tr><tr><td>5</td><td>Validated in a relevant environment</td><td>Deployed and working on <strong>a public Cardano testnet</strong> (Preview or Preprod), or live in another ecosystem, under realistic conditions. <strong>◀ Your existing product must be here or above.</strong></td></tr><tr><td>6</td><td>Demonstrated in a relevant environment</td><td>A full working prototype or MVP on public testnet: realistic flows, test wallets, perhaps first outside testers.</td></tr><tr><td>7</td><td>System prototype in an operational environment</td><td><strong>Live on Cardano mainnet</strong>, real transactions. ◀ <strong>Where your integration reaches at Milestone 1.</strong></td></tr><tr><td>8</td><td>System complete and qualified</td><td>The product is complete, security-reviewed or audited, deployed on mainnet, ready for general use.</td></tr><tr><td>9</td><td>Proven in an operational environment</td><td>Live on mainnet with real users at real volume, proven in production. ◀ <strong>Where sustained adoption points, and your fee target with it.</strong></td></tr></tbody></table>

Product vs integration, at a glance.

Your **existing product** sits somewhere at TRL 5 or above, that's what qualifies you. Your **integration** usually starts low (an idea or a design, TRL 1-2) and the grant is what carries it up the ladder: to mainnet (7) by Milestone 1, and toward real usage (8-9) across the measurement window.

### How to place your product honestly

Judge your existing product by the strongest thing you can **demonstrate today**, not by what you plan to build. The test for each level is evidence: can you show the testnet deployment, the live product, the real users? If your product only exists as a design, it is TRL 2 and not yet eligible; if it runs and is validated on a public testnet, or is live somewhere, it is TRL 5+ and through the door. Pick the level whose evidence you could put in front of a reviewer, and link that evidence, curators verify claims from what you link.

A note on building with a maturing standard: CIP-0113 and CIP-0170 are themselves still evolving, but that does not affect your product's TRL, which is about your product's maturity, not the reference standard's. The standard's status is a build-plan risk you address separately (see each area's "Readiness & constraints").

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.projectcatalyst.io/open-funding/funding-basics/technology-readiness-levels.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.

TRL	Standard meaning	What it looks like on Cardano
1	Basic principles observed	You've spotted that a Cardano primitive could solve a real problem. Idea and research only, no code.
2	Technology concept formulated	You've designed the approach: the architecture, which primitive, how transactions flow. A spec or design doc; no working code yet.
3	Experimental proof of concept	A core mechanism actually runs in isolation, a validator, script, or key function does the thing in a test harness or local devnet.
4	Validated in the lab	The pieces work together end-to-end in a controlled development environment (a local node or private devnet).
5	Validated in a relevant environment	Deployed and working on a public Cardano testnet (Preview or Preprod), or live in another ecosystem, under realistic conditions. ◀ Your existing product must be here or above.
6	Demonstrated in a relevant environment	A full working prototype or MVP on public testnet: realistic flows, test wallets, perhaps first outside testers.
7	System prototype in an operational environment	Live on Cardano mainnet, real transactions. ◀ Where your integration reaches at Milestone 1.
8	System complete and qualified	The product is complete, security-reviewed or audited, deployed on mainnet, ready for general use.
9	Proven in an operational environment	Live on mainnet with real users at real volume, proven in production. ◀ Where sustained adoption points, and your fee target with it.