Capability Economy
Reading guide
The Capability Economy is the market Ghast Protocol is designed to create, in which each AI service builds its own delivery history, distribution and access to financing. Ghast Protocol is in development, so this market is not yet open.
Ghast Workbench creates the work, and Ghast Protocol is designed to bring it to market. The result is the Capability Economy, an open market where Capabilities are discovered, purchased, verified, and scaled, by humans and agents alike.
In the design, each Capability builds its own delivery history, reputation, and revenue, creating a path to wider distribution and growth capital. AI’s unit of value moves from access to models or agents toward completed, verifiable work. Each Capability carries its own claim, purchase terms, evidence requirements, accountability, distribution, and history.
Ghast Protocol is in development, so the market described here is a design. Ghast Workbench, where the underlying work is created, is live today.
From bundled access to service-level markets
| Function | Bundled model | Capability model |
|---|---|---|
| Buy | Access a general agent or platform that may offer many services | Purchase one service under one Defined Claim |
| Verify | Rely on ratings or broad account history | Evaluate Delivery Evidence against the service claim |
| Account for failure | Reflect failure mainly through reputation | Resolve payment and Creator accountability against the claim |
| Distribute | Keep the service tied to its original interface or host | Invoke a canonical Capability through agents, apps, and APIs |
| Build history | Aggregate results at account or platform level | Maintain Capability History for the service and its versions |
| Finance | Evaluate a product or project as a whole | Use service-level history and recurring revenue to assess Capability Financing |
The difference shows up in a single purchase. Consider a procurement team that needs supplier-onboarding records reviewed before a quarterly audit.
Under the bundled model, the team subscribes to a general operations agent, describes the job in a prompt and hopes the output is complete. If a stalled onboarding stage is missed, the team has no fixed promise to point to. The cost is a lower rating and a cancelled subscription, and a missed review of contracts by the same agent would look the same in its record.
Under the Capability model, the team buys the supplier-onboarding review under a written claim: flag every stage over an agreed threshold, link each finding to a source record, and deliver by a deadline. The evidence the report must carry is named in advance. A missed stage is a verifiable breach of that claim. Pending payment is refunded, and the Creator Bond can be slashed once the breach is confirmed. The outcome is recorded against that one service, and the same Creator’s other Capabilities keep their own records.
Each row of the table maps to a chapter of the specification:
- Buy: Defined Claims
- Verify: Evidence and Verification
- Account for failure: Challenges and Disputes
- Distribute: Distribution and Integration
- Build history: Reputation and Delivery History
- Finance: Capability Financing
Economic loop
Every execution contributes to Capability History. A final claim-met delivery also adds to Verified Delivery History and triggers the associated $GHAST burn. A legible service-level record supports distribution, while verified history and recurring revenue can support financing for additional execution capacity.
Each arrow carries a condition:
- Payment or refund. The Buyer pays in fiat or an approved stablecoin. Payment resolves to the Creator or back to the Buyer depending on the verified result, so refunded activity never counts as revenue. Payments and Fees sets out the order.
- Verified history and burn. Only a protocol-final, claim-met delivery reaches this branch. A claim-met result still inside the three-day public Challenge Window is provisional. An indeterminate or breached result releases the reserved $GHAST from the Creator’s Delivery Burn Reserve instead of burning it. $GHAST Utility gives the rule.
- Distribution. Agents, applications and APIs that offer the Capability show the same identity and the same history, so a strong record follows the service into every channel.
- Financing. A Capability with Verified Delivery History and recurring settled revenue can be assessed for a revenue facility. The assessment discounts Creator-controlled, related-party, circular and refunded activity, and the facility funds capacity for that service alone.
The loop runs in one direction. Distribution and financing follow a record and cannot be bought ahead of it. A new Capability can be published with a clear claim, but it starts with an empty history and earns everything downstream through deliveries.
The same Capability boundary governs what the Buyer purchases, what Verification evaluates, where Creator accountability applies, and which history the outcome updates. Performance remains attributable to the service that produced it rather than spilling across unrelated services.
Who gains what
| Participant | What the Capability model gives them |
|---|---|
| Buyer | A fixed claim, named evidence and a refund path when the claim is not met |
| Creator | Revenue from private work without disclosing the method, and a record that compounds per service |
| Distributor | A service it can offer under a canonical identity with a visible history |
| Capital Provider and Underwriter | Service-level history and settled revenue to assess before committing capital |
Actors and Core Objects defines each role. Capital in a financing facility is at risk, and participation does not guarantee repayment or yield.
Questions
How is buying a Capability different from subscribing to an AI agent?
A subscription buys access to an agent that may attempt many tasks. A Capability buys one execution of one service under a written claim, with named Delivery Evidence and a refund and Creator Bond path if the claim is not met.
Can a new Capability get distribution or financing before it has a track record?
It can be published and purchased, but its history starts empty. Verified Delivery History and recurring settled revenue are what support wider distribution and a financing assessment, so both come after deliveries.