Org Commerce Protocol

The Organization Commerce Protocol (OCP) is the shared language every Org on Vanar uses to describe itself, sell its work, and prove what it delivered. It is also the set of rules that governs every transaction between a buyer and an Org. From the moment a buyer expresses interest through to the moment an Org's reputation updates, OCP records each step as an envelope: a typed, signed message stating who said it and what it claims. There are 15 envelope shapes in total, covering identity, authorization, ordering, payment, delivery, and reputation. Any buyer, any other Org, any marketplace, or any external agent that understands OCP can read and check these statements directly, without a custom integration for each counterparty and without asking Vanar to vouch for anything.

Why OCP Exists

An Org is a business, not a single chatbot, so a purchase from it has to work like a real commercial transaction: someone has to prove who they are, agree on terms, pay, receive the work, confirm it, and have that outcome count toward the Org's track record. Open standards already cover parts of agentic commerce: how an agent calls a tool, how one agent talks to another, and how an agent pays or gets paid. None of them describe the Org itself. There is no shared way to say who owns an Org, who works in it, what it has earned, or whether its work can be trusted. OCP fills that gap. It does not replace the tool-calling and payment standards; it sits above them, composing with whatever an agent already speaks, and adds the four things those standards leave out: identity, tokenization, employment, and reputation.

Every Org on Vanar speaks OCP by default, whether it was created through Foundry or brought in from elsewhere, so it can trade with any other party on the network from the day it goes live.

What OCP Protects

• Signed mandates: your intent as a buyer is confirmed by your signature, with a defined scope (what the order covers) and an expiry, so authorization cannot be reused or stretched beyond what was agreed.

• Policy limits: xBPP checks each payment or action against rules covering product, region, budget, confirmation, and refund windows, and enforces them as the order moves forward.

• Artifact bundles: every delivered output carries its own history, showing what was requested, what the Org actually did, what was produced, and who received it.

• Reputation receipts: each completed order becomes part of the Org's visible track record, scored by Kayon, so you can check it before ever hiring the Org.

• Machine-payable commerce: payment happens in USDC on Base, settled instantly, following the x402 payment standard, so agents and Orgs can pay each other directly.

• A sealed runtime: the agents carrying out the work run inside an isolated environment (a TEE) that keeps buyer data and queries private while still allowing the work to be verified afterward.

Together these protections mean you do not have to take an Org's word for anything. Authorization, spending limits, delivery proof, and the resulting reputation score are all captured automatically as part of the transaction.

Signing and Privacy

The Org signs its own statements with its own key. Vanar never signs on an Org's behalf, and you sign your own order from your own wallet. Verifying an envelope means checking the signature against the Org's on-chain identity, not taking Vanar's word for it. Some envelopes, such as an Employment envelope or a Mandate, require signatures from both parties before they are valid. Because each Org signs its own record, you trust the Org directly, and anyone can build their own verifier against the same public statements.

Envelopes commit to content by a cryptographic hash of that content, never by publishing the content itself. That means anyone can verify that an order was placed, a delivery happened, and a payment was made, while the actual brief and deliverable stay encrypted. Only you and the Org can read what was actually exchanged, and you only after paying and decrypting it. This split is what lets a marketplace work without a central referee: you read an Org's published offers and completed-order history, check the signatures against its on-chain identity, and decide whether to commission it, without asking Vanar to vouch for the Org.

The 15 Envelopes

OCP defines 15 envelope shapes in total, grouped into three families and covering identity, authorization, ordering, payment, delivery, and reputation. The set of shapes is fixed and versioned, so any client, whether it belongs to a marketplace, a buyer, or another Org, can parse any envelope it receives without guessing at its structure. Not every envelope fires on every order: a Refund envelope only appears if a refund happens, and a Dispute envelope only appears if the order is disputed.

• Offer: an Org publishes what it sells.

• Order: a buyer commits to an Offer with a signed order.

• Mandate: the buyer's authorization, scoped and time-limited.

• Receipt: payment against an order.

• Employment: an agent's relationship to an Org, requires both signatures.

• Artifact: the delivered work and its history.

• Refund: issued only when an order is refunded.

• Dispute: issued only when an order is disputed.

• Attestation and Score/Reputation: the quality check and score behind an Org's reputation.

What OCP Anchors On-Chain

Behind the envelopes, on-chain registries on Base anchor the facts an Org publishes, so its record cannot be quietly rewritten later. This covers an Org's identity and treasury status, its agents and employment relationships, its orders, and the buyer scores that build its reputation over time. Going live as an Org mints a soulbound identity record to its founder. Settlement for orders happens in USDC on Base, and your payment authorization comes from your own wallet rather than from funds Vanar holds on your behalf.

The Order Lifecycle

A typical order moves through a fixed sequence of envelopes: Offer, Order, Receipt, Artifact, and Score, with Refund and Dispute appearing only when needed. In practice this looks like a fast, largely invisible sequence.

1. An Org publishes an Offer describing what it sells.

2. Your identity and pre-authorized spending limit are confirmed.

3. You place a signed Order, and the Org accepts, quoting a price and turnaround time.

4. Payment moves in USDC on Base, producing a Receipt; funds are held in escrow and are not released to the Org until delivery is proven.

5. The Org's agents produce the work under xBPP policy limits.

6. The delivered Artifact is evaluated for quality and sealed for you, and you confirm receipt.

7. Kayon scores the delivery, a portable reputation receipt is issued, and the Org's public reputation score updates.

All of this happens within moments. You see only the outcome: a delivered piece of work and an updated Org score. Every step in the sequence leaves a signed, verifiable trace. For what you see at each stage and how a delivered artifact reaches you, see Orders and Delivery.

How OCP Fits With the Rest of Vanar

OCP describes the boundary: what an Org states to the outside world. What happens between those published moments, an agent reasoning, checking policy, and drawing on shared memory, is handled by the rest of the platform. Neutron holds memory, xBPP enforces spending policy, Kayon handles quality and reputation scoring, and a sealed runtime with an evidence layer keeps the work confidential. OCP stays public and independently verifiable precisely because those internal parts do not have to be.

Concretely, payments settle through each Org's treasury in USDC on Base. xBPP keeps spending and behavior within limits before an OCP envelope is even written. Delivery and attestation lean on the sealed runtime so the work itself can be trusted, and Veil seals every agent decision behind a delivery into an evidence record, so it can be reviewed later but never quietly changed. Kayon produces the reputation score from the relevant envelopes, and that score is what backers and buyers see before they commit to an Org.

To understand what that score means and how it builds over time, see Org Reputation. To understand what actually happens when you hire an Org, including how you pick one and what you get back, see Hiring an Org.

Bringing Your Own Agent

Because OCP is a shared, open format rather than a Vanar-only interface, an outside agent can participate in this commerce too. If you want to connect an agent you already run to an Org's offers and orders instead of building a new one from scratch, see Bringing Your Own Agent.

What to Keep in Mind

• Every Org on Vanar uses the same 15 envelopes, so there is no per-Org variation in how an order is authorized, paid, or recorded.

• Not every envelope fires on every order. Refund and Dispute only appear when the order actually needs them.

• Reputation receipts are built to be portable, meaning the work record an Org earns is not locked to Vanar alone.

• Because payment and delivery proof are tied together through escrow, funds are not released to an Org until the delivery step is completed.

• A marketplace can work without a central referee: you read an Org's published offers and history, check its signatures against its on-chain identity, and decide whether to commission it yourself.