OASIS-0001 · v0.1 draft

The Open Agent Systems Interoperability Standard.

The technical interface through which autonomous agents discover, verify, pay for, and execute services. This page carries the working draft in brief; the specification text expands here as sections are ratified.

§1 · Scope

OASIS-0001 specifies how an autonomous agent finds a service, verifies it is talking to the legitimate endpoint, authorizes payment within delegated bounds, executes, and receives a verifiable receipt. It covers capability description, discovery, routing, authorization, settlement, and receipts.

It does not specify an implementation, a chain, or a vendor. Any party can implement any role in the standard, and conformance is defined by protocol behavior alone.

§2 · Capability classes

Every capability published to the network declares one of three classes, by the nature of its effect on the world. The class determines the verification an agent must perform before invoking it.

CLASS I · READ_ONLY: Returns information or computation without changing external state: analytics, research, inference, data access.
CLASS II · MUTATES_FUNDS: Acts on non-custodially delegated balances within verifiable constraints: trading, settlement, yield, payments, treasury actions.
CLASS III · EXTERNAL_SIDE_EFFECT: Causes off-platform or real-world outcomes beyond the network's state: bookings, orders, reservations, communications, fulfillment.

§3 · Request lifecycle

A request moves through eight signed, typed protocol states. No step depends on trusting an intermediary.

Intent. The agent expresses what it needs as a typed, signed intent.
Discovery. The intent resolves against published capability descriptions.
Selection. Eligible services are ranked by declared constraints, cost, and reputation.
Verification. Permissions, capability class, and delegation bounds are checked.
Authorization. Payment is authorized against a non-custodial delegation, with audit trail.
Execution. The service executes within the authorized scope.
Receipt. Results and verifiable receipts return to the agent, reconcilable against the authorization.
Rating. The agent rates the exchange on objective and subjective metrics; the rating commits to an openly readable distributed ledger.

§4 · Settlement properties

The standard requires seven properties of any conforming settlement layer, identified E1 through E7.

E1 · Stablecoin-native settlement: Obligations denominate and settle in fiat-referenced stablecoins, so a request clears without exchange-rate drift inside it.
E2 · Micropayments at protocol granularity: A request costing a fraction of a cent settles individually; the protocol assumes no batching.
E3 · Non-custodial delegation: Agents spend within verifiable bounds delegated by their principal. Keys never leave the principal.
E4 · Multi-chain operation: Settlement rides existing public ledgers; the standard binds to none of them and operates none itself.
E5 · Auditable authorization: Every payment authorization leaves a signed audit record that can be replayed and verified.
E6 · Composable service economics: Services price per call, per unit, or per outcome, and compose without a coordinating intermediary.
E7 · Receipts and verifiable execution: Execution returns a signed receipt reconcilable against the authorization that preceded it.

§5 · Governance

The specification is written in open working groups, ratified through the Agent Systems Improvement Proposal (ASIP) process, and versioned by the Technical Steering Committee. The governance section describes the bodies; the consortium staffs them.