> For the complete documentation index, see [llms.txt](https://canopy-network.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://canopy-network.gitbook.io/docs/build/terminal-launch-economics.md).

# Terminal Launch Economics

Building a new blockchain typically means solving a distribution problem before anything else:

## Terminal Launch Economics

This page explains the economics of launching an application through Canopy Terminal. It covers the Terminal bonding curve, creator and Terminal fees, founder allocation choices, Terminal graduation, and the staking model available after a successful launch.

It does not define Canopy-wide token economics, CNPY supply, or the requirements for becoming an independent Security Root. Those topics belong to [Canopy Economics](https://canopy-network.gitbook.io/docs/canopy-network/canopy-economics) and the protocol documentation.

Most importantly, the Terminal graduation threshold is a Terminal launch mechanic. It applies to a project using the Terminal bonding curve. It is not a general condition of building on Canopy, operating a Canopy chain, or progressing toward sovereignty.

### What Terminal is designed to solve

Launching an application usually creates several cold-start problems at once. A project needs users, liquidity, contributors, and economic activity before it can show that the application has real demand. Builders are often expected to solve these problems through private fundraising or institutional support before the product is live.

Canopy Terminal offers another path. A builder can launch an application and its native token together, allowing the market to discover the project from its first session of activity.

The application should still be real. Terminal is not a substitute for building a useful product, explaining how it works, or earning community trust. It provides a transparent launch and market structure for a project that is ready to meet users.

### Scope and terminology

Terminal launch graduation and protocol sovereignty are separate concepts.

| **Concept**            | **Meaning**                                                                                           |
| ---------------------- | ----------------------------------------------------------------------------------------------------- |
| Terminal launch        | A project launches through the Canopy Terminal bonding curve.                                         |
| Terminal graduation    | The project completes the Terminal bonding-curve phase after reaching the configured threshold.       |
| Canopy chain operation | The application runs with Canopy infrastructure and its configured network model.                     |
| Protocol sovereignty   | A separate, longer-term architectural question about a chain’s security and root-chain relationships. |

Do not describe Terminal graduation as automatic full independence from Canopy. Completing a Terminal bonding curve does not, by itself, make an application a Security Root or change the protocol’s broader chain architecture.

### Launch lifecycle

A Terminal launch moves through four economic stages.

| **Stage**           | **What happens**                                                                                                                  |
| ------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Create              | The builder launches an application and its native token through Terminal.                                                        |
| Bonding curve       | Participants buy and sell the project token through the Terminal curve. Creator fees accrue and Terminal charges its trading fee. |
| Terminal graduation | Once the configured threshold is reached, the bonding curve closes and the project transitions to the post-launch environment.    |
| Operating network   | The application has a liquid token, a holder base, DEX liquidity, and access to staking mechanics.                                |

The current Terminal graduation threshold is **50,000 CNPY**. This is a Terminal parameter and may change through the applicable governance or product configuration. It should always be presented as a current value, not as a permanent protocol constant.

### The bonding curve

A bonding curve is an automated market mechanism. During the Terminal launch phase, participants can buy and sell the project token through the curve. The price changes according to supply and demand.

Early buyers access lower curve prices. As tokens are purchased, the curve price rises. When tokens are sold back, the curve price falls. The mechanism is transparent and does not require the builder to negotiate a private price with each participant.

A bonding curve provides price discovery, not a promise of appreciation. A project token can move in either direction, and participation does not guarantee liquidity, graduation, or a return.

The intended role of the curve is to give a working project a visible, rules-based way to develop participation before it moves into its post-launch environment.

### Creator and Terminal fees

Terminal applies two fees to trading activity during the bonding-curve phase.

| **Fee recipient** | **Current rate**   | **Purpose**                                                                                                   |
| ----------------- | ------------------ | ------------------------------------------------------------------------------------------------------------- |
| Creator           | 0.5% of each trade | Compensation for the project creator, accrued during the bonding-curve phase and paid at Terminal graduation. |
| Canopy Terminal   | 1.0% of each trade | A Terminal fee charged on trading volume. It belongs to Terminal, not to the launched application.            |

A creator does not need to purchase their own token to accrue creator fees. Creator fees are based on trading activity in the project token, not on the creator’s token balance.

Creator fees are accrued during the bonding-curve phase but held until Terminal graduation. If the project does not reach the Terminal graduation threshold, the creator should not treat accrued fees as paid or available operating revenue.

The Terminal fee is separate from the creator fee and separate from any application treasury a builder may choose to create. It is not controlled by the launched application, its creator, or its token holders.

### A simple fee example

Assume a project records **1,000,000 CNPY** of cumulative trading volume during its bonding-curve phase.

At the current rates:

| **Fee**      | **Calculation**       | **Amount**                         |
| ------------ | --------------------- | ---------------------------------- |
| Creator fee  | 1,000,000 CNPY × 0.5% | 5,000 CNPY accrued for the creator |
| Terminal fee | 1,000,000 CNPY × 1.0% | 10,000 CNPY charged by Terminal    |

These amounts illustrate the fee calculation only. They do not predict token price, future trading volume, graduation, creator proceeds, or the treatment of Terminal revenue.

### Creator access at launch

The creator has priority access before the bonding curve opens to other participants. They may buy project tokens at the initial available curve price.

This is optional. A builder can launch without purchasing any tokens and still accrue creator fees from trading activity if the project reaches Terminal graduation.

Tokens acquired through creator priority access are separate from creator fees. They are a token position held by the creator, with the same market exposure as any other token position. Their value can rise or fall with the project token’s market.

A creator who chooses to buy at launch should document that decision clearly. Community trust is stronger when the project’s ownership, treasury, and founder participation are easy to understand.

### Founder allocations and distribution

Terminal does not automatically create a founder allocation, team reserve, advisor pool, or application treasury. Those are application-level decisions.

A builder can establish a founder allocation in two ways:

1. Purchase tokens through creator priority access at launch.
2. Implement an allocation mechanism in the application’s own code.

The first approach gives the creator immediately liquid tokens acquired from the curve. The second approach lets the application define its own rules for balances, allocations, vesting, lockups, transfer restrictions, treasury controls, or burn conditions.

Application-level controls can support a range of use cases:

* Founder and contributor allocations
* A project-controlled treasury
* Advisor or partner allocations
* Grant programs
* Community incentives
* Lockups and vesting schedules
* Transfer restrictions
* Buyback or burn rules

These controls should be designed before launch, implemented in the Template, tested, and communicated publicly. They are not Terminal settings that a creator can change after the fact without application logic and the appropriate governance process.

A technically possible allocation is not necessarily a credible one. Large undisclosed allocations, unclear unlocks, or discretionary minting can make it harder to attract users, contributors, validators, and long-term holders.

### Token controls and lockups

A project can implement lockups, release schedules, whitelists, blacklists, transfer conditions, or burn logic in its own application code.

These features should be treated as protocol rules. They need a clear specification, deterministic execution, test coverage, and an explanation of who can change them.

At minimum, a project should disclose:

* The initial and potential future token supply
* Founder, team, advisor, community, and project-treasury allocations
* Lockup and vesting schedules
* Any minting authority and its limits
* Any transfer restrictions or blacklist authority
* Governance rights and upgrade controls
* The destination and control of any application treasury

Terminal’s 1% trading fee is not part of an application’s allocation or treasury. It is Terminal revenue and should be described separately.

Transparent disclosure is more useful than a vague statement that an allocation is “community aligned.” Users should be able to understand the rules before they participate.

### What Terminal graduation means

Terminal graduation occurs when a Terminal launch reaches the configured bonding-curve threshold. The current threshold is **50,000 CNPY**.

At Terminal graduation, the project moves out of the bonding-curve phase with:

* A liquid project token
* DEX liquidity
* A holder base that has participated in the launch
* Creator fees eligible for their Terminal payout
* Access to post-launch staking mechanics
* Wallet and explorer support for the operating application

Terminal graduation is evidence that the launch reached the required curve demand. It is not a guarantee that the application will retain users, that liquidity will remain deep, that token value will rise, or that the project has achieved long-term product-market fit.

It is also not a protocol-level sovereignty event. A project’s security model, governance, validator participation, and root-chain relationship remain separate architectural and operational questions.

### What the builder controls after graduation

The builder and application community retain responsibility for the project after Terminal graduation.

| **Area**                            | **Who defines it**                                    |
| ----------------------------------- | ----------------------------------------------------- |
| Application features                | The builder and application contributors              |
| Application state rules             | The Template implementation and its upgrade process   |
| Token allocations and lockups       | Application logic and documented governance           |
| Application treasury, if one exists | The application’s governance and controls             |
| Governance rules                    | The application’s protocol design                     |
| User experience                     | The builder, contributors, and ecosystem integrations |
| Validator and staking participation | The operating network and its participants            |
| Terminal trading fee                | Canopy Terminal                                       |

Terminal provides the launch mechanism. It does not remove the need to operate the application responsibly after launch.

### Staking after Terminal graduation

After Terminal graduation, native token holders can participate in staking mechanics. The model is designed to align application participants with the network that supports the application.

The intended reward model is dual asset. Eligible participants can earn rewards connected to both the application’s native token and CNPY.

A project’s native token gives participants exposure to the application itself. CNPY rewards connect the application’s active network participation to the broader Canopy reward system.

The actual reward outcome depends on the active network configuration, total stake, validator participation, the application’s economics, and governance-controlled parameters. Staking is not a fixed-yield product.

### Default reward distribution

Canopy’s current default reward distribution allocates a committee’s rewards as follows:

| **Recipient**                           | **Default share** |
| --------------------------------------- | ----------------- |
| CNPY staker acting as block producer    | 70%               |
| CNPY staker acting as delegator         | 10%               |
| Native-token staker acting as validator | 10%               |
| Native-token staker acting as delegator | 10%               |

This default distribution is protocol configuration, not a promise of a fixed annual return. Reward amounts depend on block production, committee participation, stake distribution, and active parameter values.

For the current protocol-level reward structure and CNPY economics, see [Canopy Economics](https://canopy-network.gitbook.io/docs/canopy-network/canopy-economics).

### Why someone would stake a project token

Staking gives a token holder a role in the application’s network economics. Depending on the application’s structure, a participant may stake as a validator or delegate stake to an active validator.

A holder may choose to stake because they want to:

* Support the application’s active network participation
* Earn eligible native-token and CNPY rewards
* Align with the project over a longer time horizon
* Participate in the application’s validator and governance ecosystem

Staking also has tradeoffs. A participant should understand lockups, withdrawal conditions, validator selection, reward distribution, token volatility, and any applicable slashing or operational risks before committing tokens.

Projects should explain their staking rules in plain language. A good staking page explains what is being secured, how rewards are allocated, how a delegate chooses a validator, when stake can be withdrawn, and what risks apply.

### Builder responsibilities

A Terminal launch gives a project a transparent economic starting point. It does not make economic design automatic.

Before launch, a builder should be able to answer:

* What does the application do today?
* Why does the token exist?
* What does holding or staking the token enable?
* How is initial supply allocated?
* Who controls any application treasury and upgrade authority?
* Which rules are immutable, and which can change?
* What happens if the project does not reach Terminal graduation?
* What are the risks of participating in the bonding curve or staking after graduation?

The strongest launches pair a working application with a clear answer to these questions. Token activity should support the product and community, not substitute for them.