# Towns protocol

## Recent Posts

- [Bringing x402 Payments to Slash Commands on Towns](https://paragraph.com/@towns-protocol/bringing-x402-payments-to-slash-commands-on-towns): We’ve been thinking a lot about what a real agentic internet looks like inside Towns.
Bots in Towns already do far more than reply to messages. They moderate channels, react to events, call out to external services, and move money onchain. Each bot runs with a dedicated treasury wallet for receiving funds and a separate gas wallet for executing transactions. This unlocks a world where bots can transact with one another instead of only acting on behalf of users. 

The question was simple: 

How do you let bots charge per command, natively and safely, without wiring up a separate Web2 billing system?

So we’re introducing paid slash commands in Towns, powered by x402.

This article breaks down what 402 Payment Required actually is, what x402 does and why it suddenly matters, how Towns is using x402 to power paid slash commands, why this model benefits builders, users, and agents, and how this connects to future standards like ERC 8004 and well-known bot metadata files.1. What is “402 Payment Required”?
Whenever an app or an AI agent talks to a backend, it usually does it over an HTTP API.
The pattern is simple:
Client (app, website, bot, AI agent) sends a request → Server replies with:
• A status code (what happened)
• Some data (the actual response)
You’ve probably seen common HTTP codes like:
200 OK → everything went fine
404 Not Found → what you asked for doesn’t exist
500 Internal Server Error → something broke
But there is another status code that almost never gets used: 402 Payment Required.

It has been in the HTTP spec since the beginning, intended for payments on the web, but it never had a real standard for handling payments inside a request flow. It stayed a placeholder until x402 came along2. What x402 actually does
x402 gives 402 Payment Required real power by turning it into a complete payment negotiation protocol inside the request itself.
Instead of a vague error like Payment required, go figure it out somewhere else, an x402 response tells the client exactly what to pay, in what asset, and to whom.
The flow works like this:
A client calls an API.
The server replies with a 402 plus an x402 payload specifying the price, asset (usually USDC), and recipient.
The client signs a payment authorization.
A facilitator processes the authorization and executes the onchain transfer.
Once payment is confirmed, the server continues the request as if it were a normal 200.
A facilitator is a helper service that verifies the signature, executes the payment onchain, and returns proof of settlement to the API. This removes the need for API builders to write their own transaction plumbing. They speak x402, plug into a facilitator, and they can charge per-request/per-action in a standard way.
This model is perfect for agents because it removes credit cards, API keys, and human billing flows. The agent only needs the ability to sign.3. Why x402 is perfect for AI agents (and bots in Towns)
Today, using a paid API usually looks like:
Sign up for a dev platform
Add a credit card
Get an API key
Manually plug that key into your app or agent
Hope you don’t leak it somewhere
This doesn’t work well for autonomous agents:
They can’t easily open accounts or type credit card numbers
They end up being tightly coupled to one account’s billing setup
Every new API means more humans in the loop
x402 changes how that works entirely: 
No API keys — the “key” is effectively the agent’s ability to sign payment authorizations
No credit card forms — just stablecoin balances and cryptographic signatures
Pay-per-use, native to the protocol — not a separate billing platform
For Towns, this is powerful because bots naturally behave like agents:
They respond to slash commands
They call out to other services
They often need to do work that has a real cost (compute, data, premium content)
x402 gives us a clean way to make those interactions paid, without duct-taping a Web2 billing UI on top.4. How Towns integrated x402 for paid slash commands
We’ve added native payment processing for slash commands in the Towns bot framework using the x402 pattern and an in-house Towns x402 facilitator.

At a high level:
A bot defines its slash commands.
If a command has no paid block, it is free.
If a command includes a paid block, the framework automatically turns it into a paid command backed by x402 and USDC on Base.
The SDK manages the entire payment flow before your handler runs.4.1. Define your commands
You declare all your commands in one place. Free and paid commands share the same type and differ only by whether they include a paid configuration.// src/commands.ts
import type { BotCommand } from "@towns-protocol/bot";

export const commands = [
  {
    name: "free",
    description: "A free command",
    // no `paid` block → this stays free
  },
  {
    name: "premium",
    description: "Access premium content",
    // `paid` is an x402 RouteConfig under the hood
    paid: {
      price: "$0.50",
      network: "base-sepolia",
    },
  },
] as const satisfies BotCommand[];The SDK does the rest:
If a command has no paid block, it behaves like a normal, free slash command.
If a command does have a paid block, the framework automatically treats it as a paid slash command and hooks it into the x402 flow.4.2. Register handlers for free vs paid commands

Free commands work exactly like before:

typescript
// Free commands – register on the base bot
bot.onSlashCommand("free", async (handler, { channelId }) => {
  await handler.sendMessage(channelId, "This is free!");
});
Paid commands use the wrapped bot. The framework ensures payment succeeds before your handler runs: 

typescript
// Paid commands – register on the wrapped bot
paidBot.onSlashCommand("premium", async (handler, { channelId }) => {
  // This only runs AFTER the USDC payment is verified and settled
  await handler.sendMessage(channelId, "Welcome to premium content!");
});
The key idea:
- You write your business logic as if payment already happened.
- The SDK guarantees that’s true before your handler is called.4.3. What the user experiences

Inside Towns, the flow is straightforward:
The user types /premium in a channel.
The bot replies with a payment request, for example: “Pay $0.50 USDC to run this command.”
The user approves the request in the Towns app using an EIP-712 signature, with no external checkout or extra login.
The Towns x402 facilitator verifies the signature and executes the USDC transfer onchain.
Once payment is confirmed, the bot completes the command and returns the result.
In short: type /premium → approve → done.5. Why this is good for Towns builders and communities
For builders & creators
New business models
Pay-per-command (e.g. /summarize, /generate-image)
Unlock premium content (e.g. /alpha-report)
Time-based access (e.g. /join-private-room for a day)
No Stripe dashboards or Web2 headaches
You don’t need to become a payments SaaS company to charge a few cents for a powerful action.
Composable payments
Charge per request today; in the future, combine that with subscriptions, reputation, or yield flows.
For users
Clear, predictable costs
You see exactly what you’re paying for each action, in a stable asset (USDC).
No credit cards or extra signups
Your Towns identity + your wallet is enough.
Safer than sharing API keys
Commands are mediated by bots and facilitators; your private credentials don’t end up scattered across random services.
For the ecosystem

Standardization
Using x402 means Towns plugs into an emerging shared standard for agent payments rather than inventing a custom one-off.
Future-proof for agents
As more agents live inside Towns, they’ll be able to call paid APIs on their own. 
6. Looking Ahead: ERC-8004, Well-Known Bot Metadata & the Agentic Internet
x402 answers the hard part of payments: how bots charge, settle, and proceed.
The next question is just as important:
Who am I interacting with, and can I trust them?
That’s where ERC-8004 comes in.
ERC-8004: A Trust Layer for Networked Bots
ERC-8004 is an onchain A2A standard that introduces three lightweight registries:
Identity — prove a bot is a legitimate, recognized entity
Reputation — track behavior, reliability, and performance over time
Validation — confirm that a bot can actually do what it says it can do
Up to now, bots have operated in silos:
no shared discovery surface
no portable trust or track record
integrations gated behind closed systems
ERC-8004 changes this. Bots can now:
discover one another
assess identity and reputation
decide who to work with based on shared trust rules
This unlocks open coordination across services inside Towns.Well-Known Bot Metadata
The internet uses .well-known files to expose structured metadata. Towns brings the same idea to bots.
A bot can publish a metadata file describing:
its capabilities
its x402 payment requirements (pricing, assets, facilitators)
its ERC-8004 identity and reputation references
its safety boundaries and allowed operations
This becomes a predictable, machine-readable entry point for any bot or client to understand how to interact.
The Full Interaction Stack
When you combine these layers, you get a clear, standardized framework:
Metadata: what the bot does and how to interface with it
ERC-8004: who the bot is and why it can be trusted
x402: how to pay for the work it performs
Together, they give bots a shared language for coordination.
What This Enables in Towns
With these pieces in place, more complex multi-party workflows become streamlined.
A portfolio bot can:
discover reputable yield bots using ERC-8004
read their metadata for capabilities and pricing
negotiate a strategy
execute multi-step onchain flows (borrow → swap → deposit) powered by x402 as one compressed intention
For the user, an entire multi-step operation collapses into a simple interaction: approve once and the job is done.
7. Where this leads us 
Paid slash commands in Towns mark the beginning of a new tier of capability. They introduce native, protocol-level payments for bots using x402 and USDC on Base. They create cleaner incentives for builders and communities. They establish agent-friendly infrastructure that operates without any Web2 billing layers.
What comes next becomes even more compelling. Bots can start to experiment with richer pricing models and revenue sharing. Integrations with ERC 8004 deepen the trust and coordination layer across agents. Standardized well-known metadata files make bot capabilities and payment terms discoverable and interoperable.
Taken together, these pieces shift the model from bots that simply answer messages to agents that can be trusted to act, coordinate, and pay their way across the network. Towns is becoming one of the first environments where that future feels concrete and usable, starting with something as simple as a slash command.

## Blog Information

- [Homepage](https://paragraph.com/@towns-protocol/): Main blog page
- [RSS Feed](https://api.paragraph.com/blogs/rss/@towns-protocol): Subscribe to updates

## Optional

- [All Posts](https://paragraph.com/@towns-protocol/): Complete post archive
- [Sitemap](https://paragraph.com/@towns-protocol/sitemap-index.xml): XML sitemap for crawlers