Twelve Permissions MCP Server

Twelve Permissions — verification apparatus

Twelve NFTs on XRP Ledger mainnet. Each one mints only when a human authorizes an AI agent to do something real, and something real ships because of it. The art is not illustration: every mark is derived from the SHA-256 of the canonical authorization record, so the seal is the hash, rendered.

This repository exists so you don't have to take any of that on trust. It holds the generator, the canonical records, and the server source. Re-run them yourself.

Collection: https://twelve-permissions.tsharpe.workers.dev/ Issuer: rHEiuaYLNQ4UdLqeUrnE9AwEHqsDMr9g9R (taxon 12, 5% royalty)

Verify a seal from first principles

No dependencies. Node only.

node generate.js            # regenerates every seal from events.json
git status                  # should report no changes

The second line is the test. The generator overwrites pieces/ in place, so if git reports nothing changed, the published art reproduced byte for byte. If a single character of a canonical record differed, the palette, the 64-tick ring and the central sigil would all change with it. Forging a seal means breaking SHA-256.

To check one piece end to end:

1. Read its canonical record in events.json.
2. Take the SHA-256 of that record — it is committed in the NFT's on-chain URI.
3. Re-run the generator and compare the art, byte for byte.
4. Look up the mint transaction in records/minted.mainnet.json on any XRPL explorer.

VERIFY.md has the long version.

What's here

PNGs are omitted because they are large and reproducible from the SVGs. Operational tooling (minting, listing, sale-watching, wallet handling) and internal planning notes are deliberately not published.

The MCP server

The collection is installable as a tool. Streamable HTTP, stateless:

POST https://twelve-permissions.tsharpe.workers.dev/mcp

Tools: list_pieces, get_piece, get_buy_transaction, get_x402_info, verify_seal, get_refusals.

The x402 seller, and what it cost to learn

src/x402.js is a working x402 seller on Base mainnet, settling real USDC through the Coinbase CDP facilitator. Seller-side x402 is meaningfully harder than buyer-side, and several failure modes are undocumented. If you are building one, these cost us time:

• outputSchema: null is rejected. The facilitator's schema is not nullable. Omit the field entirely rather than sending an explicit null.
• Verdicts arrive with HTTP 400. Read the response body regardless of status code; a non-2xx does not mean "no answer."
• A piped secret can upload empty. A stray blank line produced a binding that existed but was falsy. Length-check what you upload.
• 402 challenges must not be cacheable. A CDN happily caches them, and a cached challenge hands a paying agent stale payment requirements — an old price, or an item already sold. Send no-store.
• Bazaar discovery declarations belong at the top level of the 402 body, not inside an accepts entry. Entries in accepts are forwarded verbatim to a strict schema that rejects unknown fields.

Licensing

No licence is granted at this time; all rights reserved. The code is published for inspection and verification. If you want to reuse any of it, ask.

A note on the origin

This collection was built in response to a widely-told story about an AI agent that sold twelve NFTs and bought a robot dog with the proceeds. It takes no position on that story and makes no claim about it. The point here is narrower and checkable: every authorization in this collection resolves to a transaction you can look up yourself, and the art re-derives from the record in front of you.

Nothing here asks to be believed.