Watt ServiceNet: Decentralized Agent Registry & Gateway

Watt ServiceNet is a decentralized registry and execution gateway for AI agent networks. Register providers, publish A2A agents, and invoke them at scale.

Watt ServiceNet is a decentralized registry and HTTP execution gateway for AI agent networks. It gives developers building agent-powered systems a single place to register provider identities, publish A2A-compatible agents, enforce invocation policy, and collect cryptographically-anchored execution receipts — all without a centralized authority. Every node in the network can replicate the registry state it needs, validate records locally, and federate with peers it trusts.

What you can do with ServiceNet

Register providers

Anchor your agents to a stable provider identity backed by a DID key. Rotate keys without changing your provider ID, and optionally prove ownership with a signed challenge.

Publish agents

Submit an A2A-compatible agent card together with a deployment config and review profile. Valid submissions are auto-approved and immediately discoverable across the network.

Invoke via gateway

Send a single HTTP request to ServiceNet. The gateway enforces provider status, auth, region, cost, and risk-level policy before forwarding the call as an A2A JSON-RPC SendMessage to the agent’s registered endpoint.

Verify receipts

Every invocation produces an ExecutionReceipt with SHA-256 digests of the request and result. Query, verify, and audit receipts at any time. Medium- and high-risk agents trigger an automated verification sweep.

Architecture overview

ServiceNet is built around four core abstractions that work together to give you a trustworthy, auditable agent network.

Provider

A provider is the identity anchor for every agent it publishes. You register a provider with a human-readable provider_id (for example, acme-labs) and a provider_did — a did:key URI that holds your Ed25519 public key. Providers can be in one of two states: active or revoked. An active provider whose DID key you control can publish agents, rotate its key, and receive invocations. A revoked provider’s agents become uninvokable, but all historical records remain auditable.

Agent

An agent goes through a two-phase lifecycle. First you submit an AgentSubmission — a bundle that includes an A2A-compatible agent card, a deployment config pointing to your endpoint, a review profile describing risk level and data handling, and a signed attestation from your provider DID. Once the submission passes validation (signature, schema, binding proof, and optional smoke test), it becomes a PublishedAgent: a public, discoverable record that the network can replicate. The agent card follows the Google A2A standard, so any A2A-aware client can discover and interact with your agent directly.

Gateway

The gateway is ServiceNet’s policy-enforcement and protocol-translation layer. When you call POST /v1/agents/:agent_id/invoke, the gateway checks provider status, blocklist entries, auth, region restrictions, cost budget, and risk-level confirmation before forwarding the request as an A2A JSON-RPC SendMessage call to the agent’s registered endpoint. It records an ExecutionReceipt whether the invocation succeeds or fails, giving you a tamper-evident audit trail.

Receipt

An ExecutionReceipt is created for every invocation — both synchronous and asynchronous. It carries the receipt_id (a UUID), SHA-256 digests of the request and result, the invocation status (running, succeeded, failed, or rejected), and a verification verdict. Low-risk agents receive a not_required verdict immediately. Medium- and high-risk agents start as pending and can be moved to verified or failed through an automated verifier sweep or manual adjudication.

Deployment modes

ServiceNet ships with three storage backends so you can match your environment:

Mode	When to use	How to activate
In-memory	Local development and testing	Default — run the node with no extra config
JSON file	Small deployments that need simple persistence across restarts	Set SERVICENET_REGISTRY_FILE=.data/registry.json
PostgreSQL	Production — full persistence, receipt indexing, and audit logs	Set SERVICENET_DATABASE_URL and SERVICENET_SECRET_BROKER_KEY

PostgreSQL-backed deployments automatically enable ownership challenges and encrypted auth-context storage. See the quickstart and Docker Compose setup for full configuration details.

Next steps

Quickstart

Register a provider, submit an agent, invoke it, and check the receipt in five steps.

Core Concepts

Dive deeper into providers, agents, the gateway, receipts, auth contexts, and the P2P layer.