Whitepaper / Network and Trust

Distribution and Integration

A Capability, in the proposed design, is the interface other agents, applications, and APIs would call when they want one private service rather than a copy of the workflow. Every door would show the same identity, the same claim version, and the same history. Ghast Protocol is in development, so there is no endpoint to call. This chapter says what that interface must carry and what it must not reveal. It is not a developer quickstart for Ghast Workbench.

Workbench already has its own connections: model providers through 0G Compute, plugins, skills, and MCP servers. Those help a person work on their own machine. They are not a Capability distribution network. The user guide covers how to add them. This chapter covers a different object, one that cannot exist until Protocol does.

Unit of distribution

An integration exposes:

• the Capability’s canonical identity and version;
• its Defined Claim, purchase conditions, and required inputs;
• permitted outputs and evidence requirements;
• Verification and Settlement state; and
• the ability to file a Challenge during the public window.

The list is the contract of the interface. A caller that can invoke a workflow but cannot read the claim is not distributing a Capability. It is running a tool. A caller that shows a price but not the evidence requirements is asking for payment without the basis of verification. Defined Claims and Evidence and Verification are the chapters those fields come from. Capability Lifecycle is why verification state and settlement state are part of the surface and not an afterthought in a dashboard.

The ability to file a Challenge is on the list because the three-day public window is useless if a channel hides it. Challenges and Disputes specifies the bond and the outcomes. An integration that only offered a “buy” button would drop the recourse the design treats as part of the purchase. Actors and Core Objects names the Challenger as a role. The interface has to leave room for that role during the window, and only during the window.

The interface exposes the service terms and the transaction state, not the Creator’s underlying method. The Privacy Model defines the disclosure boundary. Prompts, private knowledge, memory, data logic, and execution strategy stay Creator-controlled. An integration that logged those for “debugging the marketplace” would break the boundary the rest of the book is built on. Public metadata during the challenge window is already specified. It is not a license to stream the raw execution to every caller.

Channel-neutral trust

Agents, applications, and APIs would preserve the same canonical identity, the same claim version, the same evidence rules, the same accountability, and the same settlement path. That gives the service one Capability History across participating channels. Identity and Provenance is the identity those channels must share. Reputation and Delivery History is the history they must not fork.

Channel-neutral does not mean the channels look the same. A chat agent, a web application, and an API can present different controls. They cannot present different claims for the same version, and they cannot keep private side books of “successful” runs that never enter Capability History. A summary label on one channel still has to identify scope, versions, time window, and calculation basis. Otherwise the channels have reintroduced the account-level reputation the design rejected.

A common integration surface carries identity, authentication, permissions, purchase terms, payment state, lifecycle events, and the claim and history a buyer needs in order to assess the service. Authentication and permissions are how a caller proves it may supply inputs and receive outputs. They are not a substitute for the claim. Payment state is the commercial half of settlement, distinct from proposed $GHAST bonds. Payments and Fees separates buyer payment from those commitments. An integration may display both. It may not merge them into one balance and call it the price of the work.

Lifecycle events are how a channel stays honest while a purchase is open. A provisional verification result is not a final settlement. A channel that showed only a success checkmark during the Challenge Window would hide the deadline the privacy model makes public. Events have to be able to move from purchased, to executed, to provisionally verified, to challenged or settled, without the channel inventing a shorter story.

What stays in Workbench

Creating the workflow stays in Ghast Workbench. Chat, Coding, and Agent Team are where a Creator would develop the private method. Ghast Workbench and Ghast Agent Team describe that work. Distribution begins only when a specific service is packaged as a Capability. Packaging is a Protocol action. It is not live. Installing a plugin or connecting an MCP server does not list a Capability, and it does not put Workbench telemetry into a delivery history.

Capability Examples are useful here as a test of the interface. Each example is a bounded outcome. An integration for one of them would show that outcome’s claim and evidence, not the domain in general. A “legal agent” or a “coding agent” is too coarse to be the unit of distribution. The example chapters keep the unit small enough that the fields in the list above can be filled in.

Boundaries an integrator would still carry

Security and Risk does not let distribution absorb runtime risk. A channel can pass through a verified claim and still be a compromised client. Sandboxing, permissions, and secret handling remain necessary on the side that runs tools. Governance and Upgrades does not let a channel apply a new protocol rule to an open purchase. The integration has to honor the version and the rules bound at purchase, including any migration rule the upgrade actually published.

Economic accountability travels with the service, not with the channel’s brand. A Creator Bond in the utility design is posted against the Capability. A channel does not become the party who is slashed merely by displaying the service, unless the design’s roles say so for that transaction. This chapter does not create a new liable intermediary. It requires intermediaries to preserve the roles the protocol chapters already name.