Azeth Testnet is Live

Azeth is live on Base Sepolia. Seven smart contracts are deployed and verified. The TypeScript SDK (@azeth/sdk), 32 MCP tools (@azeth/mcp-server), and CLI (@azeth/cli) are published and working against them. Everything you need to give an AI agent a non-custodial wallet with spending limits, a verifiable identity, x402 payments, and reputation that can't be faked.

For the market context behind this launch, see Agents Have Money. They Don't Have Trust..

This post covers what shipped, how it works, and how to start building on it today.

Architecture

Developer / AI Agent
    |
    +-- @azeth/sdk          (TypeScript SDK)
    +-- @azeth/mcp-server   (32 MCP tools)
    +-- @azeth/cli          (CLI commands)
         |
         v
    Azeth Server             (Hono API)
    +-- x402 Facilitator     (USDC settlement)
    +-- Registry API         (identity + discovery)
    +-- Reputation Engine    (auto-feedback)
    +-- XMTP Relay           (encrypted messaging)
         |
         v
    On-Chain Contracts       (Base / Base Sepolia)
    +-- AzethFactory         (deterministic deployment)
    +-- AzethAccount         (ERC-4337 smart account)
    +-- GuardianModule       (spending guardrails)
    +-- TrustRegistryModule  (ERC-8004 identity)
    +-- PaymentAgreementModule (recurring payments)
    +-- ReputationModule     (payment-gated reputation)
    +-- AzethOracle          (Chainlink USD pricing)

Three layers. Developers interact through the SDK, MCP tools, or CLI. The server handles authentication, payment facilitation, and discovery. Smart contracts enforce all security rules on-chain — spending limits, agreements, and reputation cannot be tampered with by any off-chain component.

The server is a convenience layer. It coordinates operations and provides REST endpoints. But every economic commitment — account ownership, spending limits, payment agreements, reputation scores — lives on-chain and is independently verifiable by anyone.

Smart Accounts — Wallets That Enforce Their Own Rules

An externally owned account is a single private key with no spending limits and no recovery path. If the key leaks, the entire balance is gone. For a human managing a MetaMask wallet, that risk is tolerable. For an autonomous agent executing transactions 24/7, it is not.

Azeth smart accounts are ERC-4337 accounts built on ERC-7579 modular architecture. The account itself is a minimal proxy. All behavior comes from four pluggable modules, each handling a specific concern:

• GuardianModule (Validator) — spending limits, token and protocol whitelists, timelocks
• TrustRegistryModule (Executor) — identity registration and management on the ERC-8004 registry
• PaymentAgreementModule (Executor) — on-chain recurring payment subscriptions
• ReputationModule (Executor + Hook) — payment tracking and reputation feedback

The GuardianModule is the gatekeeper. It validates every UserOperation before execution, enforcing five constraints:

1. Token whitelist — the account can only transfer approved tokens (USDC, ETH, etc.)
2. Protocol whitelist — the account can only interact with approved contract addresses
3. Per-transaction USD limit — no single transaction can exceed the configured ceiling
4. Daily spend limit — cumulative spending resets per 24-hour epoch
5. Oracle freshness check — the Chainlink price feed must be current; stale feeds trigger guardian co-signature requirements

Changes to guardrails follow a timelocked discipline. Loosening any constraint — raising a spending limit, adding a token to the whitelist — requires a 24-hour timelock. Tightening any constraint takes effect immediately. Emergency withdrawal routes funds to a pre-designated address with a 1-hour timelock.

Even with a compromised key, an attacker cannot drain beyond the current daily limit.

import { AzethKit } from '@azeth/sdk';
import { parseEther } from 'viem';

const kit = await AzethKit.create({
  privateKey: process.env.AZETH_PRIVATE_KEY as `0x${string}`,
  chain: 'baseSepolia',
});

const result = await kit.createAccount({
  owner: kit.address,
  guardrails: {
    maxTxAmountUSD: parseEther('100'),
    dailySpendLimitUSD: parseEther('500'),
    guardian: kit.address,
    emergencyWithdrawTo: kit.address,
  },
  registry: {
    name: 'My Agent',
    entityType: 'agent',
    description: 'A demo agent',
    capabilities: ['price-feed'],
  },
});

console.log(`Smart account: ${result.account}`);
console.log(`Registry token: ${result.tokenId}`);

Single atomic transaction. Deploys the account, installs all four modules, registers the agent on the trust registry, and permanently revokes factory access. The factory can never redeploy or modify this account — ownership is final from the first block.

Trust Registry — Machine-Readable Identity

Agents need to find each other. Not through hardcoded URLs or API keys passed over email, but through a queryable registry where capabilities, endpoints, and reputations are published on-chain.

The Azeth Trust Registry implements ERC-8004. Every registered entity — agent, service, operator — gets an on-chain identity token with structured metadata: name, type, description, capabilities, and endpoint. Any agent can query the registry to discover services by capability, filter by reputation, and resolve endpoints.

// Publish a service
await kit.publishService({
  name: 'PriceFeedBot',
  entityType: 'service',
  description: 'Real-time crypto prices',
  capabilities: ['price-feed', 'market-data'],
  endpoint: 'https://mybot.com/api',
});

// Discover services by capability
const services = await kit.discoverServices({
  capability: 'price-feed',
  minReputation: 50,
  limit: 10,
});

Address resolution is flexible across the SDK, CLI, and MCP tools. You can reference participants by:

• Ethereum address — 0x1234...abcd
• Participant name — resolved via the registry (e.g., "PriceFeedBot")
• "me" — resolves to the caller's own account
• Index shorthand — "#1", "#2" for your first, second account

This means an AI agent can discover and interact with services using human-readable names, not raw addresses.

x402 Payments — Commerce at the Protocol Layer

HTTP 402 ("Payment Required") has existed in the HTTP spec since 1997. It was reserved for future use. x402 puts it to work for machine-to-machine commerce.

Agent                          Service
  |  1. GET /api/data            |
  |----------------------------->|
  |  2. HTTP 402 (pay 0.05 USDC)|
  |<-----------------------------|
  |  3. Sign payment on-chain    |
  |  4. Retry with payment proof |
  |----------------------------->|
  |  5. Validate + deliver data  |
  |<-----------------------------|

The agent requests a resource. The service responds with 402 and a payment requirement. The agent signs an on-chain payment, resubmits the request with proof, and the service validates and delivers. No API keys, no OAuth, no billing dashboards. The payment is the authentication.

Four access methods handle different scenarios:

1. x402 Payment — one-time per-request payment. The agent's EOA signs an ERC-3009 authorization for USDC transfer.
2. Smart Account Payment — the payment routes through the smart account, so all GuardianModule guardrails are enforced. Per-transaction limits, daily caps, and whitelists all apply.
3. SIWx Session — a wallet signature proves prior payment, enabling session-based access without re-paying per request.
4. Payment Agreement — an on-chain subscription. The service can pull payments at agreed intervals without per-request authorization.

The SDK wraps all of this into one call:

const smart = await kit.smartFetch402('price-feed', {
  autoFeedback: true,
  maxAmount: 100_000n,
});

console.log(`Service: ${smart.service.name}`);
console.log(`Response time: ${smart.responseTimeMs}ms`);

One call. Discovery (find a service with the price-feed capability), payment (negotiate and sign x402), and reputation feedback (rate the service based on response time and success). The autoFeedback flag submits an on-chain reputation opinion after each successful interaction.

Payment-Gated Reputation — Trust You Can Verify

Open rating systems collapse under Sybil attacks. If creating an account is free and leaving a review is free, the ratings mean nothing. Azeth solves this with a simple constraint: rating costs money.

The mechanism:

• $1 minimum on-chain USDC payment to submit a rating for any agent or service
• Weight scales with spend: $10 of payments gives 4.6x weight. $100 gives 21.5x. $1,000 gives 100x.
• Sublinear dampening using x^(2/3): doubling your spend does not double your influence. This makes Sybil attacks economically irrational — splitting $100 across ten accounts yields less total influence than spending $100 from one account.
• Sibling-rating prevention: accounts sharing the same owner cannot rate each other. The ReputationModule checks on-chain ownership to enforce this.
• Auto-feedback via smartFetch402(): every successful payment interaction can automatically submit a reputation opinion based on response time and HTTP status.

Every dollar spent to manipulate reputation also enriches the target. An attacker trying to inflate their own score must pay real money, and that money flows to other participants in the system.

const rep = await kit.getWeightedReputation(42n);
console.log(`Score: ${rep.weightedValue}`);
console.log(`Raters: ${rep.opinionCount}`);

Reputation scores are fully on-chain. Any agent can query them before deciding whether to interact with a service. The discoverServices method accepts minReputation as a filter, so agents can programmatically avoid low-reputation providers.

32 MCP Tools for AI Agents

Azeth ships as an MCP server, which means any MCP-compatible host — Claude Desktop, Claude Code, or any client implementing the Model Context Protocol — can use all Azeth capabilities through natural language.

Add to your Claude Desktop or Claude Code config:

{
  "mcpServers": {
    "azeth": {
      "command": "npx",
      "args": ["@azeth/mcp-server"],
      "env": {
        "AZETH_PRIVATE_KEY": "0x..."
      }
    }
  }
}

32 tools across 7 categories:

Category	Tools	What They Do
Account (6)	create account, check balance, view history, deposit, list accounts, whitelist tokens	Deploy and manage smart accounts
Transfer & Payment (5)	send tokens, x402 payment, smart discovery+pay, create agreement, subscribe	Move money and pay for services
Agreement (5)	execute, cancel, view, list, find due	Manage on-chain payment subscriptions
Registry (5)	publish, discover, lookup, update, batch update	Identity and service discovery
Reputation (4)	submit opinion, get score, check payment history, check existing rating	Query and submit reputation data
Messaging (5)	send encrypted message, check reachability, read messages, list conversations, discover capabilities	XMTP-encrypted agent communication
Guardian (2)	view guardrails, whitelist protocols	Inspect and modify security constraints

Your agent can deploy a smart account, pay for a service, and rate it — all through natural language. No code required on the agent side. The MCP server translates intent into signed on-chain transactions.

Security Posture

The test suite covers the full stack:

• 742 unit tests across contracts, SDK, and server
• 10,000 fuzz runs on smart contract inputs
• Formally verified with Halmos — symbolic execution over all guardian constraint paths

Core security properties:

Non-custodial. Azeth never holds signing keys or funds at any point in the lifecycle. The AzethFactory deploys accounts and then its access is permanently revoked. There is no admin key, no multisig, no upgrade path that could give Azeth access to user accounts.

Timelocked changes. Loosening any guardrail — raising a spending limit, adding a protocol to the whitelist — requires a 24-hour timelock. Tightening any guardrail takes effect immediately. This asymmetry means security can always be increased instantly but can never be silently weakened.

Sibling-rating prevention. Accounts with the same on-chain owner cannot rate each other. The ReputationModule enforces this at the contract level.

Oracle staleness fallback. If the Chainlink price feed is stale beyond the configured threshold, the GuardianModule escalates to requiring guardian co-signature on all transactions. The account does not freeze — it falls back to a more conservative security posture.

Standards

Standard	How Azeth Uses It
ERC-4337	Smart accounts with UserOperations and gas sponsorship
ERC-7579	Modular smart account architecture — validators, executors, hooks
ERC-8004	Trust registry for identity, capabilities, and reputation
x402	HTTP-native machine-to-machine payments
ERC-3009	USDC gasless transfer authorization (transferWithAuthorization)
XMTP v3	Encrypted agent-to-agent messaging

Deployed Contracts

All contracts are verified on BaseScan. These are the live testnet addresses.

Contract	Address	BaseScan
AzethFactory	0x28e808DD688F722631482C276488289a6A8ea3e3	View
AzethAccount (impl)	0xCEEf6Aff7f08b9902198203E2F1a07A2b10885AD	View
GuardianModule	0xC12043Ba3D58e5959E683bfFf8D94e21C8C6533C	View
TrustRegistryModule	0x9A199eeFFd9A4837556139474eaf8420B6ED71bD	View
PaymentAgreementModule	0xa3e51F13CF6B74170f8Bb6CcA2c2835563179C89	View
ReputationModule	0xB8C98ace6bdB25f5AEb2031150A5944F3135ccC0	View
AzethOracle	0x64Da6aEbE4121CE9CE8145d97950495A45BB72be	View

External contracts used by Azeth:

Contract	Address
ERC-8004 Identity Registry	0x8004A818BFB912233c491871b3d84c89A494BD9e
ERC-8004 Reputation Registry	0x8004B663056A597Dffe9eCcC1965A193B7388713
EntryPoint v0.7	0x0000000071727De22E5E9d8BAf0edAc6f37da032
USDC (testnet)	0x036CbD53842c5426634e7929541eC2318f3dCF7e

Get Started

Install the SDK and generate a testnet key:

npm install @azeth/sdk viem
export AZETH_PRIVATE_KEY=0x$(openssl rand -hex 32)
export AZETH_CHAIN=baseSepolia

Deploy your first smart account:

import { AzethKit } from '@azeth/sdk';
import { parseEther } from 'viem';

const kit = await AzethKit.create({
  privateKey: process.env.AZETH_PRIVATE_KEY as `0x${string}`,
  chain: 'baseSepolia',
});

const result = await kit.createAccount({
  owner: kit.address,
  guardrails: {
    maxTxAmountUSD: parseEther('100'),
    dailySpendLimitUSD: parseEther('500'),
    guardian: kit.address,
    emergencyWithdrawTo: kit.address,
  },
  registry: {
    name: 'My Agent',
    entityType: 'agent',
    description: 'A demo agent',
    capabilities: ['price-feed'],
  },
});

console.log(`Smart account: ${result.account}`);
console.log(`Registry token: ${result.tokenId}`);

On testnet, gas is sponsored — you don't need your own Pimlico API key.

Full documentation:

• Getting Started — 15-minute quickstart
• Architecture — deep dive on the stack
• SDK Reference — full TypeScript API
• CLI Reference — command-line interface
• MCP Tools — AI agent tool reference
• Smart Contracts — on-chain details
• Configuration — environment variables
• x402 Service Provider — build your own x402 service

What Comes Next

This is testnet. We are building in public. Try it, break it, tell us what is missing. Mainnet is next.

Docs | GitHub | X