# Nano for AI — nano133.com

Everything nano133.com offers for AI agents and AI coding tools to use Nano (XNO): an MCP server, payment tools with step-by-step specs, a public node, and the agent patterns we are exploring.
Status words: Live (works today), Built (finished, not public yet), Planned, Idea. A tool shows its stage instead (Pre-alpha, Alpha or Beta), and a demo of an idea shows Concept: see https://nano133.com/stages.

## MCP server

Nano tools for any MCP agent: Claude, Cursor, Grok and others.

### Nano MCP server — Pre-alpha

Ten tools that let any MCP agent read Nano, price in dollars, take payments with invoices, and send from a capped wallet.

A Model Context Protocol server under the MIT license. Its package name is @nano133/mcp, but it is not on npm and its repository is private, so it cannot be installed yet. An agent connects to it and gets Nano tools: no integration code, no SDK to learn.

Receiving needs no key: invoices only need your address, and payments go straight to your wallet. Sending is off by default and works only from a separate, small wallet with caps.

| Tool | Key | What it does |
| --- | --- | --- |
| nano_balance | – | balance and receivable of an account, in XNO and raw |
| nano_account_info | – | frontier, representative, block count, voting weight |
| nano_history | – | latest sends and receives, with paging (before = a block hash) |
| nano_receivable | – | sends waiting to be received, largest first |
| nano_rate | – | XNO in USD (median of public feeds), with conversion |
| nano_create_invoice | – | an invoice in USD or XNO: an exact amount, a nano: link, an expiry |
| nano_wait_for_payment | – | waits up to 120 s: paid, pending or expired |
| nano_verify_payment | – | checks an invoice, or any block by hash + to + amount (+ since) |
| nano_wallet | wallet | the send wallet's address, balance, limits and what is left today (never the seed) |
| nano_send | wallet | sends XNO from the capped wallet, once per idempotency_key |

Build it (needs the private repository):

```sh
git clone <repository>  # not public yet
cd nano133-mcp && npm install && npm run build
```

Claude Code:

```sh
claude mcp add nano -e NANO_PAY_TO=nano_your_receiving_address -- node /path/to/nano133-mcp/dist/index.js
```

Claude Desktop (claude_desktop_config.json) or Cursor (.cursor/mcp.json):

```json
{
  "mcpServers": {
    "nano": {
      "command": "node",
      "args": [
        "/path/to/nano133-mcp/dist/index.js"
      ],
      "env": {
        "NANO_PAY_TO": "nano_your_receiving_address"
      }
    }
  }
}
```

Turn on sending (a NEW, small wallet only):

```json
{
  "NANO_SEND": "on",
  "NANO_WALLET_ADDRESS": "nano_your_send_wallet_address",
  "NANO_SEND_MAX_PER_CALL_XNO": "0.01",
  "NANO_SEND_DAILY_CAP_XNO": "0.05"
}
```

Put the send wallet's seed in a local file (your own terminal, never a chat):

```sh
mkdir -p ~/.nano-mcp && pbpaste > ~/.nano-mcp/seed && chmod 600 ~/.nano-mcp/seed
```

Ask your agent:

```
Make a $5 Nano invoice for the logo design, show me the exact amount and link, and tell me when it is paid.
```

Note: Built and tested, not public yet: the repository and the npm package come later. The nano133 Kit is public now on its own.

### MCP server settings — Built, not public yet

Every setting: the node, the invoice address, the state folder, and the send wallet's caps.

Settings are environment variables in the agent's server entry. The caps can be lowered, never raised above the hard ceilings in code.

| Setting | Default | What |
| --- | --- | --- |
| NANO_RPC_URL | https://node.nano133.com/rpc | the node for reads, checks and publishing (use your own for real money) |
| NANO_WORK_URL | NANO_RPC_URL | where proof of work comes from (work_generate) |
| NANO_PAY_TO | – | the address invoices are paid to (no invoices without it) |
| NANO_INVOICE_MINUTES | 15 | how long an invoice is open |
| NANO_INVOICE_GRACE_MINUTES | 60 | how long after that a late payment still counts |
| NANO_STATE_DIR | ~/.nano-mcp | invoices and the send journal |
| NANO_SEND | off | on = allow sending |
| NANO_WALLET_ADDRESS | – | the send wallet's address; no send unless the seed gives exactly this address |
| NANO_WALLET_SEED_FILE | ~/.nano-mcp/seed | a file with the seed (hex or a 12/24-word phrase), chmod 600; never paste a seed into a chat |
| NANO_WALLET_SEED | – | the seed itself, instead of the file (the file is safer: it stays out of config files and logs) |
| NANO_REPRESENTATIVE | the first sender's | the representative for a new send wallet |
| NANO_SEND_MAX_PER_CALL_XNO | 0.01 | the most one send may move (ceiling 1) |
| NANO_SEND_DAILY_CAP_XNO | 0.05 | the most all sends may move in 24 hours (ceiling 10) |
| NANO_SEND_ALLOWLIST | – | if set, the only addresses the wallet may pay |

### Custody and safety — Built, not public yet

Who holds what: keyless receiving, a capped send wallet, exactly-once sends, fail closed.

The server is built so a mistake by an agent, a node or a person costs cents, not a wallet.

- Receiving is keyless: the server never holds the money it invoices for.
- Sending is off unless NANO_SEND=on, the wallet address, a seed (a file, or NANO_WALLET_SEED) and caps are set; the seed must give exactly that address. Use a separate wallet with a few cents in it.
- Caps before every send: per call (default 0.01 XNO), per 24 hours (default 0.05 XNO), an optional allowlist; hard ceilings of 1 and 10 XNO in code.
- Every send is written to a journal before it is published: a restart keeps the cap, and a retry with the same idempotency_key never pays twice.
- The wallet checks the node's balance against the latest block itself before it signs, so a wrong answer can't make it send more.
- When the node does not answer, nothing is credited and nothing is sent. The seed is never returned or logged.

### Remote MCP endpoint — Planned

A hosted, keyless version of the server for bots and connectors that can't run local programs.

Grok bots and Claude connectors reach MCP servers over HTTP. The hosted endpoint will offer the read, invoice and verify tools only: no send tool, no keys, per-IP limits.

## Kit tools

Payment tools for websites, each with a prompt and a step-by-step spec an AI can follow.

### Nano Checkout — Beta

Unique-amount checkouts, a payment check on your own node, a signed receipt. No key on your server.

Runs nano133.com's arcade rounds, Unlock, Ӿ Tips, Ӿ Fans and ad skips. The AI prompt and the spec set it up in another site's codebase.

Prompt for your AI coding tool:

```
Add "Nano Checkout" to this site: let people pay in Nano (XNO) with a unique
amount per checkout, check the payment on a Nano node, and give a signed
receipt. Use the npm package @nano133/checkout and follow its SPEC step by step:
https://nano133.com/build/nano-checkout/SPEC.md
Ask me for the receiving address and the node to use. Never print, log or
commit the receipt secret. Test with the package's mock ledger first.
```

[Feature page](https://nano133.com/build/nano-checkout) · [SPEC.md](https://nano133.com/build/nano-checkout/SPEC.md)

Note: Live on nano133.com; the package is public with the nano133 Kit.

### Late Payment Return — Beta

A payment that arrives after its checkout closed goes back to its sender, exactly once.

Runs nano133.com's till and rewards wallet. It needs the wallet's key on the server: a hot wallet, kept nearly empty.

Prompt for your AI coding tool:

```
Add "Late Payment Return" to this site: Nano (XNO) payments that no checkout
claimed must go back to their sender automatically, exactly once.
Use the npm package @nano133/late-returns and follow its SPEC step by step:
https://nano133.com/build/late-payment-return/SPEC.md
Ask me before you choose where the wallet key lives. Never print, log or
commit the key. Test with the package's mock ledger before any real payment.
```

[Feature page](https://nano133.com/build/late-payment-return) · [SPEC.md](https://nano133.com/build/late-payment-return/SPEC.md)

Note: Live on nano133.com; the package is public with the nano133 Kit.

### Sign in with Nano — Alpha

Sign in with a Nano wallet: the wallet signs a short message. No password, no email, no payment.

A signature sign-in is also how an agent can prove it holds an address.

Prompt for your AI coding tool:

```
Add "Sign in with Nano" to this site: people sign in with their Nano (XNO)
wallet, which signs a short message. No password, no email, and no payment.
Use the npm package @nano133/signin and follow its SPEC step by step:
https://nano133.com/build/sign-in-with-nano/SPEC.md
Ask me for the site's domain. Never print, log or commit a key or secret.
Test with the package's memory store first.
```

[Feature page](https://nano133.com/build/sign-in-with-nano) · [SPEC.md](https://nano133.com/build/sign-in-with-nano/SPEC.md)

Note: nano133.com's own sign-in works the same way, but it does not run the package yet. The package is public with the nano133 Kit.

### Nano for Three.js games — Alpha

Pay the winner of a Three.js game the moment a round ends: one rule file for the game and the server, a replay before the server pays, and limits.

The npm package @nano133/three (MIT) does the server part: npm install @nano133/three. The page also has the same pattern as code to copy (plain three.js and react-three-fiber). The demo on the page plays a real round and checks it; its payout is pretend.

Prompt for your AI coding tool:

```
Add "pay the winner" to this Three.js game with Nano (XNO): when a player
wins a round, my server sends a small prize to the player's Nano address.
Follow this spec step by step: https://nano133.com/build/three/SPEC.md
Rules: the game's rule must be one pure file that the browser and the server
both run; the server makes the seed, replays the inputs and decides the win;
the wallet key stays on the server in a secret manager and is never printed,
logged or committed; add a prize limit for each player and for each day; make
each prize send exactly once. Ask me for the prize amount, the limits, the
node to use and how players sign in. Test with no real money first.
```

[Feature page](https://nano133.com/build/three) · [SPEC.md](https://nano133.com/build/three/SPEC.md)

Note: A pattern and a demo. nano133.com itself does not pay prizes in Nano.

## AI channels

Where AI coding tools find our instructions.

### SPEC.md per tool — Live

A step-by-step implementation spec for each kit tool, with a check after every step and a "done when" list.

Served as plain Markdown so an AI coding tool can fetch and follow it.

[Nano Checkout](https://nano133.com/build/nano-checkout/SPEC.md) · [Late Payment Return](https://nano133.com/build/late-payment-return/SPEC.md) · [Sign in with Nano](https://nano133.com/build/sign-in-with-nano/SPEC.md)

### Claude Code skills — Live

One skill per kit tool (add-nano-checkout, add-late-payment-return, add-sign-in-with-nano).

Claude Code loads a skill when the task matches, then follows the tool's spec.

[Skills in the nano133 Kit](https://github.com/nano133-com/kit/tree/main/skills)

### AGENTS.md — Live

One section per kit tool, for Codex, Gemini and other coding agents.

The short rules an agent must keep for each tool: where keys live, the rate limits, the safety checks.

[AGENTS.md in the nano133 Kit](https://github.com/nano133-com/kit/blob/main/AGENTS.md)

### llms.txt — Live

An index of the kit for AI assistants: each tool's page, spec and package, and the hot-wallet warning.

Served at /llms.txt, in the llms.txt format, for any AI assistant to read.

[/llms.txt](https://nano133.com/llms.txt)

### This page as Markdown — Live

Everything on this page as one Markdown file, for an AI to read in one fetch.

Give your AI the link and ask it to use whatever fits your task.

Prompt:

```
Read https://nano133.com/ai/docs.md and tell me which of these Nano tools fits my project, then set it up.
```

[/ai/docs.md](https://nano133.com/ai/docs.md)

## Public node

A Nano node any agent can read from, with limits.

### Public Nano node — Live

Our own Nano node's RPC, open to anyone for reads and publishing, with per-IP limits.

An agent can call it directly, or through the MCP server (its default). It allows a list of actions, and gives proof of work within a budget.

For real money, run your own node: its answers decide what you credit.

A balance:

```sh
curl -s https://node.nano133.com/rpc -H 'content-type: application/json' \
  -d '{"action":"account_balance","account":"nano_your_receiving_address"}'
```

A block:

```sh
curl -s https://node.nano133.com/rpc -H 'content-type: application/json' \
  -d '{"action":"block_info","hash":"<64 hex>","json_block":"true"}'
```

[Node status](https://nano133.com/network)

## Agent patterns

New ways for agents to use instant, feeless payments. Ideas we are exploring.

### Agent identity and reputation — Idea

An agent's Nano address is its ID; its paid invoices are public proof that it delivers.

The agent proves it holds its address with a signature (Sign in with Nano). Others read its history to judge it.

### Price as a rate limit — Idea

A service charges 0.0001 XNO per call instead of issuing API keys: no signup, and abuse costs money.

Only feeless transfers make prices this small possible.

### Bonds for good behavior — Idea

An agent posts a small bond to use a resource and gets it back when it leaves cleanly.

The refund is automatic (Late Payment Return). A bond is kept only by a rule both sides can check.

### Pay per verified step — Idea

A job split into many small steps, paid a fraction of a cent after each one is checked: no escrow, no trust.

Hundreds of payments per job are practical only when each one is free.

### Micro-payments to people — Idea

An agent pays a person anywhere a few cents at once for a label, a photo or a quick check.

Card and bank fees are larger than payments this small.

### A hard budget — Idea

A small wallet as an agent's allowance: it weighs cost against value before each action.

The MCP server's daily cap already enforces it.

### Refundable stamps for agent inboxes — Idea

A request carries 0.001 XNO; the receiver returns it if the request is useful and keeps it if it is spam.

A fee on the deposit and the refund would cost more than the stamp.

### The amount as a message — Idea

The last six digits of an exact amount carry a reference, a choice or a vote.

Nano has no memo field; our invoices already use the amount this way.

## Bots

Public chat bots (Grok and others) built on the MCP server. Ideas we are exploring.

### Tip this post — Idea

"Tip the author of this post 50¢": the bot finds the author's Nano address (bio or QR code) and makes an exact invoice.

The user pays from their own wallet; the bot waits and confirms. It never touches the money.

### Nano Cashier — Idea

"Invoice @alice $5 for the logo": the exact amount and link, then "paid" when it arrives.

Anyone can take a payment from a chat, with no app and no account.

### Is it paid? — Idea

Paste a hash or an address: the bot explains who paid what, when, and whether it is final.

Support questions and scam checks in seconds.

### Agent handshake demo — Idea

A Grok bot and a Claude agent invoice and pay each other per step, in public.

Shows per-step payments between two AI companies' agents.

### nano133 Arcade bot — Idea

Daily scores, challenges, and "pay 1¢ to enter the leaderboard" from a chat.

Brings chat users to the nano133.com arcade.
