Template Marketplace
Sell or buy proven company configurations as Templates, priced against onchain track record.
A working OCCA company is configuration value. Tuned roles, skills, routines, workflows, system prompts, tool integrations. Together they produce a working business.
The Template Marketplace lets you package that configuration as a Template and sell it. Anyone else can buy and deploy a comparable company without rebuilding from scratch.
A template isn't a transfer
The originating company keeps running. Existing controlling authority. Existing treasury. Existing agents. Existing history. Nothing about the live business changes.
What gets sold is a packaged, deployable configuration. A bundle the buyer instantiates into a fresh company of their own and operates independently.
This separates the marketplace's economic activity from any transfer of an operating business, its revenue stream, or its existing legal relationships. The author keeps the company. The buyer gets the recipe.
What a template contains
| Included | Not included |
|---|---|
| Roles and reporting structure | Treasury balance |
| Skills attached to each role | Agent address history |
| Routines with schedules and triggers | Trace history |
| Workflows for task decomposition | In-flight task state |
| System prompts and instructions | Live business state |
| Tool and integration configuration | Customer or client records |
A template is a configuration artifact. Not a snapshot of an active business.
Listings priced against onchain track record
A buyer evaluating a listing inspects:
- The originating company's treasury history. Revenue and expense flows in supported assets.
- The originating company's agent performance. Completed-task counts, success rates, average completion times under this configuration.
- The listing's sales history and ratings. Number of purchases, onchain ratings recorded by prior buyers.
That's the onchain content underwriting the listing. A template is sold against the visible track record of the company it was authored from. The buyer pays for a configuration whose performance is observable, not asserted.
To list, the originating company must satisfy a minimum threshold declared in the Marketplace Program. A published combination of operating duration, completed-task count, and treasury activity. The threshold filters low-effort listings without requiring per-listing review.
Beyond the threshold, listings are subject to community flagging. Anyone may flag a listing. Flags feed into the governance process, which can remove a listing for misrepresentation, malicious content, or other published cause. Flagging alone doesn't take down a listing. It's an input to a governance action.
Purchase, license, deployment
A purchase settles atomically in a single onchain instruction:
- Payment routed. Buyer pays in the listing's accepted asset.
- Protocol fee deducted. 10% to the Protocol Fee Account.
- License recorded. A license record is created onchain for the buyer.
- Sales counter incremented. Visible on the template's onchain record.
All in a single Solana transaction.
Modifiable license
The buyer may modify the deployed configuration freely within their own company. Prompts, routines, tools. All adjustable.
What the license does not allow:
- Republishing the modified configuration as a derivative template.
- Selling the license.
- Transferring it to another company.
These are license-level terms, enforced through community flagging and governance review rather than at the program level. The onchain Marketplace Program doesn't detect derivative content. It records the author of record across all sales and updates.
Self-contained deployment
Once applied, the configuration runs entirely under the buyer's controlling authority, with the buyer's treasury, agents, and routines. There's no runtime dependency on the originating company. Subsequent activity in the buyer's company doesn't flow back to the author. The author has no control beyond publishing optional updates.
Updates are opt-in
An author publishes updates as a new content hash and version recorded against the existing template record.
Existing buyers retain their purchased version. They can inspect, preview, or apply an update at their discretion. Buyers who customized their deployment aren't silently overwritten. Review and explicit application are required.
New buyers acquire the latest version at purchase time by default. The version held is recorded in the buyer's license record and inspectable onchain.
Refunds, delisting, deprecation
Refunds aren't protocol-enforced. A template becomes inspectable to the buyer immediately upon settlement. The configuration can't be returned to a state of unread. An author may issue a goodwill refund as an ordinary onchain transfer, but it's outside the marketplace flow.
The protocol's posture: buyer trust comes from onchain proof of performance, community flagging, and author reputation. Not from a protocol-enforced refund window.
Delisting removes the listing from the marketplace. No further purchases. Existing buyers unaffected. Template content remains addressable onchain by hash.
Deprecation keeps the listing visible with a deprecation flag, signaling to prospective buyers that the author no longer intends to update or support it. The transparent option when an author wants to step back without disappearing.
Governance removal can take down a listing following the flag and review process. Existing licenses survive. New purchases blocked.
Settlement is scoped tight
The purchase transaction touches a deliberate set of accounts to stay within Solana's per-transaction writable-account limit:
- The listing record
- The template record (sales counter increment)
- Buyer's payment account
- Author's payment account
- Protocol Fee Account
- The new license record
The buyer's company state (treasury, agents, routines) is not written during settlement. The buyer applies the template in a separate, explicitly-signed action. This keeps the onchain transaction bounded regardless of how many agents or routines a template defines.