Defined Claim
The service promise, written and fixed before anyone pays.
View definitionGhast Protocol · Proposed design
A design for verifiable AI services.
Ghast Protocol is the proposed commerce layer for private AI work, designed to make private expertise callable by agents. A Creator would publish one defined service as a Capability, a person or an agent would buy it, and payment would settle against evidence that the promise was kept. The method behind the work would stay with the Creator.
Ghast Protocol is in development, and the mechanisms on this page describe its design. Ghast Workbench, where the work is created, is available today.
Why Protocol
The work that earns the most is the work nobody publishes.
The prompts, the context, and the execution strategy behind valuable AI work are the advantage. Creators need a way to sell that work without showing how it is done. Buyers need a promise they can check.
The Capability
A defined service. A promise with money behind it.
In the proposed design, a Capability is one defined AI service a buyer could purchase and verify. The workflow and method behind it stay under the Creator's control.
Verifiable Delivery
Named evidence, measured against that promise after the work runs. Learn how evidence supports verifiable AI execution.
View definitionEconomic Accountability
The design would have the Creator lock $GHAST behind the Capability as a bond, slashed if a breach is confirmed.
View definitionAgents perform work. Capabilities define what a buyer pays for.
What a Capability looks like.
An execution desk will not publish its trading strategy. It can still sell a defined result, and the buyer can check that result without seeing the strategy.
The private workflow
Confidential trading logic, unchanged and unexposed.
The Capability
Execute a defined order across approved venues, within an agreed time window and predefined risk limits.
Delivery evidence
Amount completed. Price against benchmark. Fees. Rule compliance.
Lifecycle
From promise to settlement.
The proposed lifecycle has six steps, whether the Buyer is a person or an agent working within the scope and budget its owner approved. None of them would require the Creator to reveal the method.
- Publish
- The Creator would define the claim, the evidence and the price.
- Buy
- The Buyer would purchase one execution under that claim, in fiat or an approved stablecoin.
- Execute
- The private workflow would run without publishing the method.
- Record
- The execution would produce the evidence named at publication.
- Verify
- The evidence would be checked against the Defined Claim.
- Settle
- Payment and the Creator's bond would resolve against the same claim.
Disputes
What happens when delivery is disputed.
The design keeps a claim-met result open for a three-day public challenge window. Anyone could challenge it by posting a bond, so a weak delivery could be contested even if the buyer misses it.
No challenge, or the claim holds
Payment would settle to the Creator, and the result would enter the Capability’s verified delivery history.
Breach confirmed
The Buyer would be refunded, the Creator’s bond slashed and the challenger rewarded. A rejected challenge would lose its bond.
Payment, the Creator’s bond and the public record would all resolve against the same Defined Claim. Read the dispute design.
$GHAST
What $GHAST does.
Buyers pay in fiat or an approved stablecoin. $GHAST does not pay for the work. Its proposed roles are accountability and growth. $GHAST has not been issued.
Burn
Each protocol-final, claim-met delivery would burn a $GHAST amount reserved by the Creator when the purchase was made.
Lock
Creators would lock $GHAST behind their claims, and challengers behind their challenges.
Stake
Underwriters would stake $GHAST as first-loss cover when a proven Capability raises growth capital.
In the proposed financing model, a Capability with a verified delivery record and recurring revenue could raise stablecoin growth capital, repaid from a share of what it earns. Capital would be at risk.
Read about Capability FinancingValue attached to the service.
The design would attach delivery history, reputation and revenue to each Capability, not to the Creator’s account as a whole. Agents, applications and APIs would reach the same service under one identity and one history.
Buying access to an agent compared with buying a Capability. For the broader context, see the agentic economy overview.
| Agent or platform access | A Capability (proposed) | |
|---|---|---|
| What you buy | Access to an agent or platform | One service under one claim |
| The agreement | Terms of the access offering | A specific, testable promise |
| Delivery evidence | Set by each offering | Named before purchase, checked after |
| Track record | Attached to the agent or account | Attached to the service |
| If it fails | Depends on the offering | Refund, bond slash, challenger reward |
The Capability Economy overview explains the market these services form.
While Protocol is in development
Use Workbench, and read the guides.
Ghast Workbench is the desktop app where Capabilities start: the workflows you build and refine there are what a future Capability is made from. These guides cover what you can run today.