Whitepaper / Reference

Token Allocation

Part of the proposed $GHAST supply would be allocated to growing the Capability Economy. $GHAST has not been issued, and Ghast Protocol is in development. This chapter describes how a future supply would be divided and what each part would be for. What a unit of supply would do inside the protocol is described in $GHAST Utility.

Allocation

The growth share would be split across two categories:

• Capability ecosystem. Funds the Creators, Capabilities and integrations that bring services to market.
• Community and usage rewards. Goes to the people and agents who buy and use those services.

The rest of the supply would cover the protocol treasury, liquidity, and the contributors who build and support Ghast Protocol. A category-by-category breakdown and its terms are not published while $GHAST has not been issued.

The categories are names for proposed uses. They are not wallets a reader can inspect, and they are not balances that exist today.

What the growth share is for

The two growth categories are named after the market they would serve. Capability Economy describes that market: AI services sold under a written claim, each building its own delivery history, distribution and access to financing. Supply assigned to growth is supply assigned to that loop, not to a general marketing budget.

Capability ecosystem. A market of defined services needs services first. In the design, this category supports the supply side: Creators who turn a repeatable workflow into a Capability, the work of stating a testable Defined Claim, and the integrations that let agents, applications and APIs offer a Capability under one identity, as Distribution and Integration describes. It is not a grant program that is open today, and this whitepaper lists no recipients.

Community and usage rewards. A market also needs buyers who come back. This category is the demand side: people, and agents acting within the budget their owner approved, who buy and use Capabilities. “Usage” here means use of Capabilities through Ghast Protocol. It does not convert Workbench accounts, inference or compute into a reward balance, and the hackathon result in Recognition and Traction is not one either. Using the product is not a point in an allocation.

Both growth categories meet the same constraint the rest of the protocol uses. Volume is easy to fake. Reputation and Delivery History separates independent demand from Creator-controlled, related-party, circular and refunded activity. Any growth incentive built on top of Capability activity would have to read the same filtered record, or it would pay for the activity the filters exist to remove.

What the rest of the supply is for

Protocol treasury. In the design, a treasury is supply held for the protocol rather than assigned to a participant. Governance and Upgrades says how proposed rule changes would be authorized and who may hold administrative authority. This chapter does not add a spending policy, a signer set or a live treasury.

Liquidity. The category describes a proposed use related to market liquidity once a token exists. It is not a promise of a listing, a pool or a price. Nothing in this whitepaper should be read as a market for $GHAST.

Contributors. The people who build and support Ghast Protocol. This chapter does not name them, and it states no compensation, lockup or sale.

What is not published

This chapter gives no category-by-category breakdown, no vesting or unlock schedule, no price and no round terms. Those details belong to an issued token, and $GHAST has not been issued. Where $GHAST Utility needs parameters, such as bond sizes or the Delivery Burn Reserve, it states that parameters and framework details are published before mainnet. They are not published here as a live schedule.

How allocation relates to utility

Allocation answers how the proposed supply would be divided. $GHAST Utility answers what a unit of that supply would do, apart from buyer payment. There are three proposed functions:

• Burn. A Delivery Burn Reserve is quoted and reserved at purchase, and burned only after a delivery is protocol-final and its Defined Claim is met.
• Lock. A Creator Bond stands behind an active Capability, and a Challenge Bond stands behind a dispute, as Challenges and Disputes describes.
• Stake. A junior underwriting position in Capability Financing.

Each function is tied to a delivery, a service or a risk position, not to holding alone. Burn follows a verified delivery. A bond is posted against a specific Capability or a specific dispute and can be slashed if the claim behind it fails. A stake absorbs first losses on a specific financing facility. None of these functions run today, and a share of supply does not become a burn, a bond or a stake until a live protocol exists.

Buyers pay for the work itself separately, in fiat or an approved stablecoin, as set out in Payments and Fees. A Buyer does not need $GHAST to purchase a Capability.

Reading the growth share as a yield is a mistake. The line says two categories of a proposed supply are assigned to Capability Economy growth. It does not say a holder receives a share of anything. There are no holders of an issued token.

What this page is not

Not a term sheet. Not a whitelist. Not a countdown, and not a line that says the token is “live after” some event. The whitepaper overview states the product status in one place: Ghast Workbench is live, and Ghast Protocol is in development. Token chapters stay inside that status. Security and Risk says financing capital remains at risk and returns are not guaranteed. This page does not soften that boundary, and it does not add a return.

This chapter describes a proposed design. It is not an offer to sell, or a solicitation to buy, any token, and it states no price or sale. Ghast AI is not affiliated with other projects or tokens that use the Ghast name.

The Glossary holds the terms the rest of the whitepaper uses. Installing Ghast Workbench is how you use the live product. Using it does not allocate $GHAST, and it does not purchase a Capability.