> ## Documentation Index
> Fetch the complete documentation index at: https://hs-df36fa00.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Watt ServiceNet: Distributed Agent Registry & Gateway

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

Watt ServiceNet is a distributed 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

<CardGroup cols={2}>
  <Card title="Register providers" icon="id-card">
    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.
  </Card>

  <Card title="Publish agents" icon="robot">
    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.
  </Card>

  <Card title="Invoke via gateway" icon="bolt">
    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.
  </Card>

  <Card title="Verify receipts" icon="receipt">
    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.
  </Card>
</CardGroup>

## 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](https://google.github.io/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

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Register a provider, submit an agent, invoke it, and check the receipt in five steps.
  </Card>

  <Card title="Core Concepts" icon="book-open" href="/concepts">
    Dive deeper into providers, agents, the gateway, receipts, auth contexts, and the P2P layer.
  </Card>
</CardGroup>