System Guide

Plain English

A merchant is the person or company selling something. Cortex gives each merchant an onchain identity so agents know who they are buying from.

Benefit: Buyers and agents can discover real sellers, check their history, and pay the right payout address.

Technical View

Merchant profile JSON is published through the API and hashed. The CommerceRegistry stores the merchant owner, payout address, metadata URI, metadata hash, and active status onchain. The indexer mirrors those events into the API database for dashboards and agent discovery.

Plain English

A service is the thing a merchant sells, such as a data set, API call, report, license, or compute job.

Benefit: Agents can compare services by price, terms, license, and fulfillment rules before spending money.

Technical View

Service metadata and catalog documents are stored offchain with content hashes. Service registration events bind the merchant, service id, metadata hash, catalog hash, price, token, and active state. Agents read services through REST or MCP before requesting a quote.

Plain English

An agent is software that can shop or buy on behalf of a person or business.

Benefit: The system can separate the human owner from the automated buyer, which makes spending limits and audit trails much clearer.

Technical View

Agent identities are registered onchain with an owner and metadata hash. API/indexer records connect agent activity to policies, quotes, receipts, disputes, and fulfillment results.

Plain English

A policy is a budget rule. It tells an agent what it is allowed to buy, from whom, with which token, and how much it can spend.

Benefit: Agent owners can let agents act independently without giving them unlimited spending power.

Technical View

PolicyModule stores per-agent rules keyed by merchant or the zero address for any merchant, token, and facilitator. Exact merchant policies override any-merchant policies. Preflight APIs and MCP tools simulate these checks before a payment is prepared, and onchain recording enforces signed payment totals.

Plain English

A quote is the seller's exact offer: what the agent is buying, how much it costs, what rights come with it, and how it will be delivered.

Benefit: The agent can prove what it agreed to, instead of relying on a vague checkout page or chat message.

Technical View

Quote data is canonicalized and hashed. The quote hash can be committed onchain through the IntentBook and later matched against payment, settlement, receipt, fulfillment, and dispute records.

Plain English

A payment rail is the way money moves. Cortex supports simple transfers and facilitator/x402-style signed payment flows.

Benefit: Merchants can accept payments in the way that fits their product, while agents still get policy checks and receipts.

Technical View

Direct native or ERC-20 transfers can be paired with quote and receipt records. Facilitator/x402 flows bind canonical payment requirements to quote hashes, then record signed payment hashes and daily spend against PolicyModule limits.

Plain English

A settlement plan explains where the money goes. One payment can split between a merchant, supplier, tax reserve, platform fee, escrow, or other recipients.

Benefit: Agents can understand the full cost breakdown before buying, and merchants can support more realistic business models.

Technical View

The settlement plan is canonical JSON whose hash is bound into quote terms. SettlementAdapter executes native or ERC-20 split payouts from deterministic line data and emits execution events that the indexer uses for reconciliation.

Plain English

A receipt proves the purchase happened. Fulfillment proves the seller delivered the result.

Benefit: Agents and humans can look back and see what was bought, what was paid, and what was delivered.

Technical View

Receipt and fulfillment records anchor quote hashes, result hashes, payload hashes, and transaction metadata. Sensitive delivery content stays offchain or encrypted; the chain stores hashes and references for verification.

Plain English

A license tells the agent what it can do with what it bought, like whether data can be reused, stored, or shared.

Benefit: Agents can follow rules automatically instead of guessing what a purchase allows.

Technical View

License metadata is included in service documents and quote terms. Agents can fetch license records through the API/MCP and bind the accepted terms into quote and receipt evidence.

Plain English

A dispute is how an agent says the seller did not deliver what was promised.

Benefit: Bad outcomes become visible and reviewable, which builds trust for future automated purchases.

Technical View

Dispute records reference receipt ids and reason hashes. Resolution records can include refund or denial outcomes, and dashboards/API views connect the dispute to merchant, agent, quote, receipt, and fulfillment records.

Plain English

The API and MCP are how software agents use Cortex. The dashboards are how humans set things up and inspect what happened.

Benefit: Both agents and people can use the same commerce system without forcing everyone into the same interface.

Technical View

The REST API exposes indexed reads, hosted document writes, preflight checks, and transaction preparation. MCP exposes agent-friendly tools for discovery, policy checks, purchase preparation, reconciliation, and setup transactions. Dashboards consume the same API data.