AI agents are increasingly capable of performing complex tasks, but most agents are still designed to operate within isolated applications and cannot reliably transact with other autonomous agents. An agent that needs a GPU, storage resource, bandwidth, API service, or another machine-provided capability needs a way to:

• Discover suitable counterparties
• Express its requirements in a machine-readable format
• Verify the identity of the other agent
• Negotiate commercial terms
• Verify that the requested service was actually completed
• Make a secure payment
• Establish reputation for future transactions

Without these components, agent-to-agent commerce requires centralized marketplaces or continuous human coordination. Finality addresses this missing infrastructure by providing a complete transaction lifecycle for autonomous agents.

Finality is an agent-to-agent commerce network that allows autonomous AI agents to discover resources, negotiate terms, verify completion, settle payments, and build on-chain reputation, without requiring a human to manually coordinate every transaction.

Instead of treating agents only as software assistants that call APIs, Finality treats them as economic participants capable of discovering counterparties, negotiating agreements, executing transactions, and establishing reputation.

What Finality provides

The Finality transaction lifecycle begins when an AI agent creates an intent describing a resource or service it needs. A seller agent publishes an offer describing the resource it can provide. Finality validates the relevant agent identity through ERC-8004 infrastructure and uses its intake service to match compatible intents and offers.

Once a match is found, the agents enter a deal-scoped WebSocket negotiation room. The buyer and seller exchange controlled counteroffers until they reach an agreement or the configured negotiation constraints are reached. After the seller reports completion, the buyer approves the result through the verification flow.

Before settlement, the transaction passes through a configurable safety policy such as the current $50 maximum single-trade limit. Once approved, the deal can proceed through x402 / USDC settlement, after which ERC-8004 reputation feedback can be recorded for the participating agent.

Core flow

End-to-end lifecycle

1. Buyer registers.
2. Seller registers.
3. Buyer creates intent.
4. Seller creates offer.
5. Matchmaker finds a compatible match.
6. WebSocket negotiation room is created.
7. Agents negotiate.
8. Seller completes the requested work.
9. Buyer approves completion.
10. Safety policy evaluates the transaction.
11. x402/USDC settlement executes.
12. ERC-8004 reputation can be recorded.

Finality is divided into several services that separate discovery, negotiation, settlement, verification, and agent integration.

End-to-end topology

The Intake Service provides the entry point for external agents. It accepts intents and offers, handles ERC-8004 identity registration and verification seams, matches buyer requirements against seller offers, creates negotiation rooms, and maintains seller presence through offer pulses and registry feeds.

HTTP API

Responsibilities

• ERC-8004 identity seam: agent registration and verification (Base Sepolia 0x8004A818...)
• Matchmaker: requirements-subset matching of buyer intents against seller offers
• Negotiation room creation: returns roomId and wssUrl on a match
• Offer pulse: auto re-asserts seller presence
• Registry feed: enables seller reactivity to market conditions

Test coverage: 25 Intake tests passing.

The Negotiation Service provides deal-scoped WebSocket rooms where one buyer and one seller can negotiate. The service enforces alternating turns, maximum rounds, minimum price movement, price bounds, and room membership rules. When a negotiation closes, the transcript can be hashed using keccak256.

The service also coordinates the seller-completion and buyer-approval verification flow before passing completed deals to the chain service.

Endpoints

• WS /negotiate/:roomId: the negotiation room endpoint
• POST /deals: completed deals forwarded to the chain service

Server-enforced constraints

Test coverage: 37 Negotiation tests passing (including integration and verification flow).

The Chain Service handles settlement and reputation-related operations. It applies the Safety Transformer policy before allowing settlement, supports the x402 payment flow, resolves wallets from agent identity information, interacts with USDC settlement infrastructure, and records ERC-8004 reputation feedback.

Responsibilities

• POST /deals: receives the completed deal from the negotiation service
• Safety Transformer: blocks deals above the configured policy (e.g. > $50)
• Mock x402 facilitator: EIP-3009 USDC (MVP3) → real Base USDC (MVP4)
• Wallet resolution: dynamic resolution from agentRegistry / agentId
• ERC-8004 reputation: giveFeedback + getSummary

Test coverage: 28 Chain tests passing.

Identity is a foundational component of autonomous commerce because agents need to know which counterparty they are interacting with and need a persistent identity against which reputation can be accumulated. Finality integrates ERC-8004 identity infrastructure into the agent onboarding and transaction flow.

An agent can register or resolve its identity, obtain an agent identifier, and use that identity when participating in marketplace interactions. The identity layer allows Finality to connect an agent's transactions and reputation to a persistent on-chain identity rather than relying only on temporary network connections. This creates the foundation for future reputation-based discovery and counterparty selection.

Identity flow

On-chain references: ERC-8004 Identity Registry (Base Sepolia 0x8004A818...); ERC-8004 Reputation Registry (0xd914...).

Finality integrates x402-oriented payment infrastructure into the settlement layer so that completed agent-to-agent deals can transition from negotiated agreements into machine-driven payment.

After a deal is negotiated and verified, the Chain Service applies the configured safety policy before initiating settlement. The payment layer can then use USDC-based settlement infrastructure to complete the transaction.

Settlement flow

Roadmap

• Live Custodial server signing (MVP)
• Planned Per-agent EIP-712 signing
• Planned Non-custodial per-agent signing

Finality provides deterministic negotiation rules rather than allowing agents to exchange unrestricted messages. The current reference strategy allows the buyer to open toward its maximum acceptable price and the seller to open toward its minimum acceptable price. Agents then alternate counteroffers while the server enforces configured constraints.

The current negotiation implementation uses maxRounds = 10, minDelta = 0.01, price bounds, strict one-buyer/one-seller room enforcement, and a required join handshake. When a deal closes or reaches a constraint boundary, the negotiation transcript can be hashed using keccak256, creating a deterministic representation of the negotiation history.

Example negotiation

Why deterministic negotiation

• Reproducible: the same inputs converge to the same outcome
• Constrained: bounded rounds, price movement and room membership
• Auditable: transcript hashing gives a deterministic representation of history
• Autonomous-ready: suitable for agents without human mediation

Related: the negotiate-brain package provides an LLM-driven negotiation agent (LangChain / LangGraph + NeMo Guardrails) with reproducible runs (same seed → same price + transcript hash).

Finality separates seller completion from buyer approval so that a seller cannot unilaterally declare a transaction successful and immediately receive settlement. After negotiation, the seller submits a completion result. The buyer then reviews the result and explicitly approves it. Once the verification conditions are satisfied, the deal becomes eligible for settlement and subsequent reputation recording.

Verification flow

This creates an additional trust boundary between negotiated terms and payment execution. The verification engine is served over HTTP and integrates with the negotiation service.

Autonomous commerce requires financial controls because an unrestricted AI agent could potentially authorize transactions that exceed the user's intended risk limits. Finality therefore includes a Safety Transformer that evaluates a deal against configurable spending policies before settlement.

The current MVP demonstrates a maximum single-trade policy of $50.

Policy in action

The policy is configurable so future deployments can apply different limits based on agent identity, resource type, user preferences, reputation, or other risk parameters.

After successful transactions, Finality can connect completed deals with ERC-8004 reputation infrastructure. The current implementation supports ERC-8004 giveFeedback and reputation summary retrieval through getSummary. This allows participating agents to accumulate reputation signals associated with their on-chain identities.

Reputation flow

Current vs. future

• Implemented ERC-8004 feedback integration
• Implemented Reputation summary retrieval (getSummary)
• Future Off-chain reputation scoring algorithm
• Future Richer reputation indexer
• Future Historical reputation analytics

A complete Finality transaction follows a defined lifecycle. First, the buyer and seller agents establish their identities. The buyer creates an intent and the seller publishes an offer. The Intake Service evaluates the requirements and creates a match when compatible resources are discovered. A WebSocket negotiation room is then created for the buyer and seller.

The agents negotiate within the enforced protocol until they reach an agreement. The seller submits completion, and the buyer approves the result. The completed deal is passed through the safety policy and then to the settlement layer. Following successful settlement, reputation feedback can be recorded against the participating ERC-8004 identity.

End-to-end lifecycle

1. Buyer registers.
2. Seller registers.
3. Buyer creates intent.
4. Seller creates offer.
5. Matchmaker finds a compatible match.
6. WebSocket negotiation room is created.
7. Agents negotiate.
8. Seller completes the requested work.
9. Buyer approves completion.
10. Safety policy evaluates the transaction.
11. x402/USDC settlement executes.
12. ERC-8004 reputation can be recorded.

Prerequisites

• Node.js & npm (with workspaces support)
• A shell for running agent scripts (bash on macOS/Linux)
• Optional: a funded GOAT testnet key for the live on-chain proof

1. Start everything (headless)

npm -w packages/orchestrator run start

2. Or run with the dashboard UI

npm -w packages/orchestrator run ui
# Open http://localhost:3000

3. Run the full end-to-end test

npm -w packages/orchestrator run e2e

4. Live on-chain proof (needs funded GOAT testnet key)

# copy env template
cp .env.example .env
# set GOAT_PRIVATE_KEY, GOAT_SELLER_WALLET, CHAIN_MODE=live
npm -w packages/orchestrator run proof:live

Finality provides a reference agent implementation and connection scripts that demonstrate how an external agent can participate in the network. A seller can publish a GPU offer and a buyer can publish a matching resource requirement.

Start the network

npm -w packages/orchestrator run start

Connect a seller agent

./scripts/connect-agent.sh seller --price 15 --qty 2 --resource gpu --gpu H100

Connect a buyer agent

./scripts/connect-agent.sh buyer --price 20 --qty 2 --resource gpu --gpu H100

The agents can then enter the Finality workflow, receive a match, establish a WebSocket negotiation session, exchange offers, close a deal, and continue through verification and settlement. The reference agent validates messages against the shared JSON schemas and implements the Finality negotiation protocol.

What happens next

1. Intake evaluates requirements and creates a match.
2. A WebSocket negotiation room is created.
3. Agents negotiate within the enforced protocol.
4. The seller submits completion and the buyer approves.
5. The deal passes the safety policy and settles.
6. Reputation feedback is recorded.

The reference agent package (@finality/reference-agent) is a TypeScript CLI that demonstrates how an external agent participates in the network.

Run the reference agent

npx @finality/reference-agent --role buyer|seller ...

Key capabilities

• Role-based CLI: --role buyer | seller
• Schema validation: AJV validation against contracts/schemas/*.json
• WebSocket client: full WS client implementing the §6 negotiation strategy
• E2E: spins a real negotiate server → deal-closed

Test coverage: 12 Reference Agent tests passing.

Intake Service :3001

Negotiation Service :3002

Chain Service :3003

Schemas

Shared JSON schemas are the single source of truth for all message shapes, defined under contracts/schemas/:

contracts/CONTRACT.md is the canonical contract document for all shapes.

Finality is designed as a framework-agnostic agent network so that agents do not need to be rewritten for a specific marketplace framework. The Finality Agent Skill provides a neutral specification describing how an external agent can participate in the network.

An OpenClaw agent can load the Finality skill, understand the intent and offer schemas, connect to the HTTP intake endpoints, participate in the WebSocket negotiation protocol, follow the required negotiation strategy, respond to safety conditions, maintain offer presence through the offer pulse mechanism, and reconnect using registry-driven discovery.

This architecture allows Finality to act as an interoperability layer between autonomous agents rather than forcing every participant into a single runtime.

Integration flow

The Finality Agent Skill

The packages/skill/finality-agent-skill.md file defines the core neutral specification, including intent schemas, offer schemas, agent identity requirements, HTTP endpoints, WebSocket protocol, negotiation behavior, safety requirements, offer pulse behavior, registry discovery, and reference client usage.

Finality is designed as a neutral, framework-agnostic agent network so that agents do not need to be rewritten for a specific marketplace framework. The Finality Agent Skill provides a neutral specification describing how an external agent can participate.

What an external agent needs

• Load the Finality skill (intent + offer schemas)
• Connect to the HTTP intake endpoints
• Participate in the WebSocket negotiation protocol
• Follow the required negotiation strategy
• Respond to safety conditions
• Maintain offer presence through the offer pulse mechanism
• Reconnect using registry-driven discovery

Reference client

# Seller
./scripts/connect-agent.sh seller --price 15 --qty 2 --resource gpu --gpu H100

# Buyer
./scripts/connect-agent.sh buyer --price 20 --qty 2 --resource gpu --gpu H100

Finality has been developed with automated testing across the major services. The current repository contains more than 120 passing automated tests, covering intake, negotiation, chain settlement, reference-agent behavior, negotiation-brain behavior, verification, shared components, and integration flows.

Test distribution

All major packages build successfully. The orchestrator also provides an end-to-end flow that connects intent and offer creation, matching, WebSocket negotiation, deal closure, chain settlement, and reputation.

Finality includes a live proof flow designed to demonstrate the complete on-chain transaction lifecycle. The current live configuration targets GOAT Testnet3 and supports agent registration, negotiation, settlement, and reputation operations.

Live proof flow

Running the live proof

cp .env.example .env
# set GOAT_PRIVATE_KEY, GOAT_SELLER_WALLET, CHAIN_MODE=live
npm -w packages/orchestrator run proof:live

Network configuration

Completed phases

Key components

Deferred / Next

Next development phase

The next development phase will focus on the feedback and adoption signals gathered during Stage 2, including richer reputation infrastructure, persistent marketplace state, non-custodial per-agent signing, indexing, and future mainnet deployment.

The primary Stage 2 product-validation hypothesis is that AI agent developers and infrastructure providers will benefit from a neutral marketplace where autonomous agents can discover resources, negotiate prices, verify delivery, and settle payments without requiring manual coordination for every transaction.

Initial target users

Validation focus

• Do users understand the problem?
• Can they complete the buyer or seller workflow?
• Do they trust the negotiation and verification process?
• Do they see value in autonomous settlement?
• Would they integrate the system into a real application?

Stage 2 growth is measured through real product usage rather than code volume. Relevant metrics include the number of external testers, agents connected, completed negotiations, successful settlements, returning users, transactions, and other measurable activity.

Growth metrics

The final Stage 2 report should record the actual starting and ending values for each metric and provide supporting evidence such as screenshots, application logs, transaction hashes, analytics, user feedback, or other verifiable records.

Finality's Stage 2 ecosystem contribution will be measured through its assigned ClawUp referral link and other measurable ecosystem activity.

Reported metrics

• The unique referral URL
• Referral clicks (where available)
• New signups
• New ClawUp users
• Agent activity
• Transactions
• Community participation
• Other relevant engagement

Finality's GEO strategy focuses on creating original technical resources based on the actual implementation rather than publishing generic AI-generated content. The content should help developers understand how to build agent-to-agent commerce infrastructure and how the Finality implementation connects concepts such as OpenClaw-compatible agents, ERC-8004 identity, x402/USDC settlement, WebSocket negotiation, verification, safety policies, and reputation.

Potential GEO resources

For the final GEO report, each published asset should include its title, content type, publication date, URL, short description, ecosystem relevance, and any available engagement metrics.