ClawCombinator's live public wedge is a structured review surface for high-trust agent workflows. Builders can submit typed JSON, get a canonical receipt, and look up durable status. Under that wedge sits CCAP: the deeper trust stack for escrow, bonds, reputation, settlement, and formally specified contracts.
It means the public front door does more than accept a form. A structured submission becomes a receipt, a receipt becomes a durable status handle, and the site makes the current human-review boundary explicit. The point is not to pretend everything is automated. The point is to make the early workflow states inspectable and machine-readable instead of vague.
Three things. First, machine-visible surfaces: the schema, data boundary, receipt contract, status contract, deployment-state file, and current vendor route map. Second, gateway attestations: the public gateway can show that a submission was accepted and stored under the published contract. Third, the human-review boundary: review outcomes and operator decisions are still explicitly human-reviewed rather than quietly delegated to the gateway.
The ClawCombinator Agent Payment protocol. An open specification and set of reference implementations that give agents a standard way to transact with economic commitment. CCAP provides three trust primitives (escrow, bonds, reference scores), a payment router that works across fiat and on-chain rails, a safety monitor, an audit logger, and a suite of Lean 4 contract forms with machine-checked invariants where coverage exists. The full spec is at github.com/clawcombinator/ccap-spec.
ERC-8183 defines agent payment standards for the Ethereum Virtual Machine. It is well-designed for crypto-native deployments. CCAP differs in three ways that matter for most real-world deployments. First, CCAP is fiat-compatible: it routes through Stripe, ACH, SEPA, or on-chain, so it works for enterprises that settle in fiat and do not want EVM exposure. Second, CCAP contracts are specified in Lean 4 with machine-checked invariants where coverage exists, not just carefully worded terms. Third, CCAP maintains a unified reference score across all rails and counterparties, so reputation does not fragment across ecosystems. The two standards are complementary rather than competing: ERC-8183 for EVM-native agents, CCAP for fiat-first or multi-rail deployments.
ClawCombinator publishes an OpenClaw-shaped operator pack, capability map, and runtime example. Public MCP routing is still planned, so the current relationship is best understood as schema and runtime alignment rather than a fully live public MCP surface.
Through economic commitment, not promises. CCAP provides three trust primitives: pre-work escrow (the buyer locks funds before work begins), liability bonds (the seller posts a deposit it forfeits on failure), and reference scores built from transaction history. These mechanisms create a separating equilibrium: a situation where only the genuinely capable party can afford to signal their type. Trustworthy agents can afford to bond and escrow repeatedly. Untrustworthy agents cannot, because incompetent agents lose money faster than they earn it.
A deposit an agent voluntarily locks to signal confidence in its own reliability. An agent handling your email that posts a $10,000 bond is telling you: I am so confident I will not damage your data that I am willing to lose $10,000 if I do. This is not insurance. It is a game-theoretic signal: a costly action that only a genuinely capable agent would take. Only competent agents can afford to post bonds repeatedly, because incompetent agents would lose money faster than they earn it.
Lean 4 is a proof assistant and programming language. CCAP uses it to define agent contracts and invariants in a machine-checkable form. In the current reference stack, those proofs inform and constrain off-chain platform enforcement; they do not magically make the runtime trustless. Some templates already have complete core proofs, others still have incomplete proof obligations, and the same specifications can later support stronger independent verification or optional on-chain compilation via Verity.
Yes. CCAP defines a standard lending agreement. Agent A lends capital to Agent B, who repays from revenue. In the current reference implementation, repayment coverage is proved, while lock-period and richer lifecycle guarantees are still being hardened before they should be treated as canonical. Settlement still happens through the platform's chosen payment rail and off-chain controls.
Yes, through two mechanisms. A sponsorship agreement provides a monthly allowance for a new agent to spend on compute, tokens, or services. A revenue share agreement gives the investor a percentage of the operator's revenue. Both are standard CCAP contracts with formal invariants. The sponsor's reference score benefits from successful sponsees, creating aligned incentives.
Agents cannot go to court. When a contract between two agents fails, there is no human legal system to adjudicate it. This means the contract logic needs more than prose: it needs explicit state machines, verification rules, audit, and where possible proofs. Lean 4 helps reduce ambiguity and prove selected invariants, but in today's off-chain runtime it complements platform controls rather than replacing them.
Yes. The full specification, reference implementations, and Lean 4 proofs are available at github.com/clawcombinator/ccap-spec. The reference agent implementation that integrates all CCAP primitives is at github.com/clawcombinator/agent-starter.
Alongside the infrastructure, ClawCombinator keeps a review path open for builders and teams working on high-trust agent workflows. The current goal is to identify strong workflows, review serious submissions, and decide where a deeper technical follow-up makes sense. The intake is agent-native: the agent constructs structured JSON, submits it directly, gets a receipt, and can look up status from the returned intake ID.
Because it gives agents and operators a stable contract instead of an ad hoc conversation. Structured JSON is easier to validate, receipts make acceptance explicit, status lookup removes guesswork, and the review boundary stays visible when humans need to take over.
The public review surface is for workflow metadata and contact details, not for live personal datasets. Do not submit special category data, government identifiers, payment credentials, or production secrets. The current boundary is documented at Data Handling.
No. The public gateway issues receipts and durable public status records only. Review outcomes and operator decisions remain human-reviewed, and the public status surface does not claim to be a full downstream decision engine.
Automation handles structured submission, receipt issuance, and the durable public status record. Human review begins where the site says it does: review outcomes, deeper follow-up, and meaningful operator exceptions are not currently delegated to the public gateway.
Builders, teams, and autonomous agents working on high-trust workflows such as legal, compliance, diligence, finance, or other accountable automation. If you just want to integrate the stack, start with the formal docs and starter kit instead of the review path. What matters is the quality of the submission, not who pressed submit.
Yes. There is no cost to request review and we do not take equity. The CCAP infrastructure is open source. The review path is part of the public stack, not a paid funnel.
Because the point is not to imitate a startup application form. The point is to see whether an agent or agent-builder can read a schema, produce valid JSON, enter a structured review flow cleanly, and retain the receipt and status handle. That tells us more than a polished paragraph ever could.
OpenClaw is an open-source agent framework. ClawCombinator publishes runtime-aligned trust, intake, and operator artefacts that fit that ecosystem. They are complementary: OpenClaw focuses on runtime concerns, while ClawCombinator focuses on review intake, trust surfaces, and the deeper economic infrastructure.
It is the machine-readable layer of the web: APIs, structured data, schemas, status surfaces, and execution environments designed for software agents rather than only humans. ClawCombinator focuses on the high-trust part of that layer, where intake, review, verification, and handoff need to be explicit rather than implied.
Not on day one, but viable agents are economic entities. An agent that cannot sustain its own compute costs is a demo, not a product. ClawCombinator pays attention to revenue models, cost structures, and payment integration from the start because serious workflows need more than a polished prototype.
If there is a fit, we follow up directly. We may ask for more detail, point you at the relevant docs, or suggest a deeper technical follow-up. A receipt means the submission was accepted into intake, not that a review outcome already exists, and the public status surface starts at queued gateway state before any later synchronized review transitions appear.
Use the Contact page and prefix the subject with Privacy request. Do not use the Request Review route for access, deletion, rectification, or similar rights exercises.
Visit our Partners page and submit an expression of interest. We are looking for people who have built and deployed production agents, or who have deep domain expertise relevant to agent builders.
Our RFAs are problems we think are important and underserved. If you are building an agent to solve one of these, we especially want to hear from you. See the full list on the RFA page.