AxiomWorking Draft v0.1 · Independent Research

Axiom Research Mapping

A Semantic Mapping of ERC-8183

Demonstrating how a production agent-commerce protocol can be described through the Axiom semantic reference architecture.

Semantic ArchitectureAgentic CommerceImplementation Independent

This document presents one possible semantic interpretation of ERC-8183 through the Axiom reference architecture. It does not claim that ERC-8183 implements Axiom, nor that Axiom requires ERC-8183.

01 · Abstraction Boundary

One semantic layer. Multiple implementations.

Axiom defines stable economic roles. ERC-8183 demonstrates one concrete implementation of similar responsibilities on Igra.

Axiom Semantic Layer

Stable roles for autonomous commerce.

Economic Intent

Objective, scope and constraints

Authorization

Actors, permissions and mandates

Economic Primitives

Escrow, payment, verification and settlement

Implementation Layer

Concrete technical realization.

ERC-8183 on Igra

EVM contracts · USDC · UUPS proxy · ThoughtProofEvaluator

Covenant-native pathway

Covenant actors · Atomic transitions · Self-custodial settlement

The two branches represent different implementation models, not competing claims.

02 · Semantic Mapping

From shared roles to concrete functions.

Each Axiom primitive describes a stable semantic responsibility. The mapping distinguishes protocol-native correspondence from relationships that depend on the selected ERC-8183 implementation.

Mapping discipline

A useful mapping must be allowed to show friction.

ERC-8183 aligns directly with intent, authorization, information, escrow, payment and settlement. Verification and audit are represented here through the selected evaluator, contract events and recorded proof data; their exact form remains implementation-dependent.

Semantic relationship

Direct

Direct semantic correspondence with an explicit protocol responsibility.

Conditional

Correspondence exists only in a specific mode, state or execution path.

Implementation-dependent

The relationship emerges through a concrete implementation rather than the protocol core alone.

Not applicable

No meaningful semantic correspondence is present in the protocol.

Axiom Semantic Namespace

Axiom describes economic meaning, not software architecture.

The .igra namespace denotes semantic primitives defined by the Axiom Reference Model. It is independent of any specific execution environment and does not imply implementation dependencies.

Protocols may be mapped to these primitives regardless of how they are implemented. ERC-8183, for example, is a concrete protocol whose economic responsibilities can be described through Axiom's semantic vocabulary; the namespace does not imply that ERC-8183 implements or depends on Axiom.

Intent

intent.igra

Direct

Defines the objective, scope and constraints.

createJob()

The client sets provider, evaluator, expiry and description.

Authorization

auth.igra

Direct

Establishes roles, permissions and mandates.

Client / Provider / Evaluator

ERC-8183 assigns explicit on-chain roles.

Information

data.igra

Direct

Carries job metadata and submitted artifacts.

Description + deliverable hash

The job and submitted work are recorded.

Escrow

escrow.igra

Direct

Secures funds before release.

fund()

The client approves USDC and funds the job.

Verification

oracle.igra

Implementation-dependent

Validates delivery through external attestations.

ThoughtProofEvaluator

Multiple AI verifiers submit signed, threshold-based attestations that are recorded on-chain.

Payment

pay.igra

Direct

Distributes escrowed funds according to the configured fee split.

Automatic escrow distribution

On completion: 96.5% provider · 2.5% treasury · 1% evaluator.

Settlement

settle.igra

Direct

Finalizes the economic outcome.

complete() / reject() / claimRefund()

The job reaches a final state.

Audit

logs.igra

Implementation-dependent

Records events, decisions and proofs.

Contract events + verification records

The execution history remains inspectable.

03 · Lifecycle Mapping

From job creation to final settlement.

ERC-8183 provides a concrete lifecycle that can be restated through Axiom's semantic roles.

Open

Intent

Funded

Escrow

Submitted

Delivery

Verified

Oracle

Completed

Payment

Settled

Audit

Alternative outcomes: Rejected or Expired → Refund.

04 · Shared Concepts

Reusable roles across execution environments.

The alignment suggests that agent commerce can be decomposed into reusable protocol responsibilities independent of a specific chain or contract model.

Explicit Intent

Objectives, conditions and constraints are expressed before execution.

Role-Based Authorization

Participants receive explicit rights and responsibilities.

Escrow Before Payment

Funds are reserved before work begins.

External Verification

Delivery is validated before economic finality.

Deterministic Settlement

Valid outcomes produce predictable state transitions.

Verifiable Audit History

Events and proofs remain inspectable after execution.

05 · Different Design Assumptions

Different scopes, not better or worse.

These differences reflect distinct design goals and abstraction levels.

Topic	ERC-8183	Axiom
Purpose	Production protocol	Semantic reference architecture
Execution	EVM smart contracts	Implementation-independent semantic vocabulary
Settlement	Upgradeable proxy escrow	Semantic settlement primitive
Identity	Addresses and assigned roles	Identity and authorization vocabulary
Governance	Platform and implementation specific	Intentionally unspecified
Upgradeability	UUPS proxy	Implementation dependent
Verification	ThoughtProofEvaluator	Oracle and truth primitive
Verification Governance	Multisig / optimistic acceptance (implementation choice)	Implementation dependent
Extensions	Whitelisted hooks	Composable semantic primitives

06 · Research Boundaries

What this mapping does — and does not — claim.

The purpose is to compare economic responsibilities without turning semantic correspondence into an implementation or endorsement claim.

Semantic interpretation, not protocol identity

The mapping does not claim that ERC-8183 implements Axiom primitives or that Axiom requires ERC-8183.

Relationships may differ in strength

Not every economic function is expected to appear equally in every protocol. This mapping distinguishes direct, conditional and implementation-dependent correspondence rather than forcing completeness.

This mapping references one concrete realization

ThoughtProofEvaluator is the verification design examined here. Other ERC-8183 implementations may realize evaluator logic and governance differently.

Auditability is derived from implementation evidence

Contract events, attestations and proof records make execution inspectable, but their exact format and persistence are implementation choices rather than a universal Axiom domain.

07 · Architectural Observation

“Axiom is not a competing protocol. It provides a semantic vocabulary through which concrete protocols such as ERC-8183 can be described and compared.”

Axiom does not prescribe a single execution environment. Its purpose is to provide stable semantic language across different technical implementations.

08 · Why This Matters

A common language improves comparison.

A shared semantic layer makes different protocols easier to describe, compare and analyze without treating them as identical.

Shared Vocabulary

Comparable Protocols

Reusable Research

Cross-Protocol Analysis

09 · Future Research Mappings

One method, many systems.

Potential future mappings are research directions only. They do not imply that these projects implement or endorse Axiom.

Portrait

Planned

Igra Name Service

Planned

Kaskad

Planned

Multitude

Planned

Kaspa covenant applications

Planned

Related Research Mapping

Compare the x402 mapping.

Explore payment-native autonomous commerce without escrowed job execution.

Compare x402 mapping