Build with
Nouns Money.

There are no HTTP payment-intent endpoints, developer API keys or webhook delivery in this release. The OpenAPI document describes the two HTTP paths that exist; sandbox methods have their own local contract below.

The SDK source lives in packages/nouns-money-sdk in the PointCast repository. Use the source directly or the browser ES module; this release does not publish an npm package. Download the TypeScript source ↓.

import {
  NounsMoneySandbox, MemorySandboxStore,
} from './packages/nouns-money-sdk/src/index.ts';

const sandbox = new NounsMoneySandbox(new MemorySandboxStore());
const intent = await sandbox.createIntent(
  { label: 'Two-note art demo', noteCount: 2, mode: 'test' },
  { idempotencyKey: 'my-demo:create:0001' },
);
const confirmed = await sandbox.confirmIntent(
  intent.id,
  { noteIds: ['nm100-000', 'nm100-001'], mode: 'test' },
  { idempotencyKey: 'my-demo:confirm:0001' },
);
console.log(confirmed.status, confirmed.receipt);
// succeeded — a local demo receipt, no settlement

import { NounsMoneySandbox } from
  '/nouns-money/sdk.js';

// Same-origin browser ES module; no build step required.
// The default store is IndexedDB, on your app's origin.
const sandbox = new NounsMoneySandbox();
const intent = await sandbox.createIntent(
  { label: 'One-note art demo', noteCount: 1, mode: 'test' },
  { idempotencyKey: 'browser:create:0001' },
);
const result = await sandbox.confirmIntent(
  intent.id,
  { noteIds: ['nm100-000'], mode: 'test' },
  { idempotencyKey: 'browser:confirm:0001' },
);
console.log(result.receipt);

Read the public catalog from any HTTP client: GET https://pointcast.xyz/nouns-money/catalog.json. For example, run curl --fail https://pointcast.xyz/nouns-money/catalog.json. The response includes schema, mode: collectible-art, count: 100, notes and a provenance path. Each note has id, name, nounId, image and svg.

// Run in a signed-in browser on pointcast.xyz.
const currentResponse = await fetch('/api/me/nouns-money');
const current = await currentResponse.json();
if (!currentResponse.ok) throw new Error(current.reason);

const response = await fetch('/api/me/nouns-money', {
  method: 'POST',
  credentials: 'same-origin',
  headers: {
    'Content-Type': 'application/json',
    'X-PointCast-User': current.userId,
  },
  body: JSON.stringify({ noteId: 'nm100-000' }),
});
const collection = await response.json();
if (!response.ok) throw new Error(collection.reason);
console.log(collection.storage, collection.noteIds);
// account [ ... ]
// To remove the same note: method: 'DELETE', same JSON body.

import { NounsMoneyClient } from
  '/nouns-money/sdk.js';

// Same-origin browser session; never copy the session cookie.
const client = new NounsMoneyClient();
const catalog = await client.getCatalog();
const displayed = await client.getCollection();
const saved = await client.collectNote(
  catalog.notes[0].id, displayed.userId,
);
const removed = await client.removeNote(
  catalog.notes[0].id, displayed.userId,
);

NounsMoneySandbox runs local methods and stores local records. mode: 'test' is required for creation and confirmation. A request for live mode fails. Confirming demo notes does not consume, move, lock or debit any collected art.

                    confirm valid notes
requires_notes ──────────────────────────→ succeeded
      │                                      │
      │ cancel                               └ stable demo receipt
      ↓
   canceled

succeeded and canceled are terminal.

{
  "schema": "pointcast.nouns-money.intent/v1",
  "id": "nmpi_<uuid>",
  "mode": "test",
  "label": "Two-note art demo",
  "noteCount": 2,
  "status": "requires_notes",
  "noteIds": [],
  "receipt": null,
  "createdAt": "<ISO-8601 timestamp>",
  "updatedAt": "<ISO-8601 timestamp>"
}

Intent IDs begin nmpi_ and use a UUID. Receipt IDs begin nmr_ and derive from that intent UUID. A succeeded intent contains a receipt with id, intentId, mode: test, label, noteCount, sorted noteIds and issuedAt. Dates use ISO 8601. A canceled intent has no receipt.

The receipt records the selected design references in a demo. It is neither a cryptographic receipt nor server-verified settlement. It grants no right to goods, cash, backing assets, tokens or later allocations.

Each sandbox mutation requires { idempotencyKey: "your-key-here-0001" }. Keys must contain 16–128 ASCII letters, digits, periods, underscores, colons or hyphens. Generate one key for a deliberate action and reuse it when retrying that action.

1. Same key, same normalized operation and payload: returns the original result. A retried create produces the same intent ID and original creation snapshot. Use retrieveIntent to inspect the intent’s current state after later actions.
2. Same key, another operation or payload: fails with idempotency_conflict. Keys share one namespace within the store.
3. Repeated confirmation with the same note selection: preserves the receipt, even with a new key. Note order is normalized; IDs are unique and sorted.
4. A terminal intent: cannot change to another terminal outcome or accept a different note selection. Inspect its state instead of assuming a retry can undo it.

The browser store uses IndexedDB transactions to serialize mutations across tabs using the same origin and database. The memory store protects operations using the same store instance. Neither coordinates a different device or a different browser database.

Collection HTTP mutations use set membership instead of an Idempotency-Key header. Collecting an already collected design or removing an absent design succeeds with changed: false. Removing then recollecting records a new collection timestamp. There is no quantity or balance to increase through repeated clicks.

Collection API failures return {"ok":false,"reason":"code"} with the relevant non-200 status. The collection SDK client reports API failures as api_error, with status and reason when a server response exists, and malformed responses as invalid_response.

import { NounsMoneyError } from
  './packages/nouns-money-sdk/src/index.ts';

try {
  await sandbox.retrieveIntent(
    'nmpi_00000000-0000-4000-8000-000000000000',
  );
} catch (error) {
  if (error instanceof NounsMoneyError) {
    console.log(error.code, error.message);
    // not_found ...
  } else {
    throw error;
  }
}

Failed account reads show an unavailable state; they do not silently substitute device preferences as account-saved. The sandbox has no account authentication. Signing out does not erase local demo receipts, and another person using the same browser can see them. Use public demo labels; do not put secrets, customer data or payment details in a label.

A store holds at most 250 intents and 1,000 mutation keys. There is no silent eviction. Preserve any useful demo records before intentionally clearing the browser’s sandbox data. Exported or edited local files remain untrusted demo data.

Existing PointCast sign-in remains the account boundary. The generic profile-state PUT route rejects this collection slot with collection-endpoint-required; use the dedicated endpoint. The SDK does not create sessions, link wallets, ask for wallet signatures, change credentials or request spending approval.

The source-100 catalog uses authentic numbered Nouns #0–99. Read the source-set provenance for file evidence and exact-source verification. Catalog IDs label collectible designs; they do not imply ownership of the corresponding NFTs. Earlier ten-design art and generated studies retain their own provenance and labels.

Nouns artwork is available under CC0; using it does not imply Nouns DAO endorsement or NFT ownership. See the official Nouns brand and art resources. The exact artwork claims apply to verified flat masters, not to generated scenes or material effects.

This release does not grant a blanket license over the repository or every third-party asset. Check the existing license or provenance of each code component, font, image and source before reuse. Keep author credits and asset-specific terms with copies. Open documentation and a public specification do not change those terms.

A possible first Tezos companion could use an issuer-funded FA2 mint to a verified recipient. FA2 supports multiple token types and defines transfer and operator behavior; a mint entrypoint is contract-specific, not guaranteed by the standard. Tezos FA2 documentation ↗

1. Establish consent and recipient control. A future wallet challenge would bind an explicit recipient, application domain, nonce and expiry. Verify it on a server before considering issuance. Arbitrary-data signing exists in wallet tooling; the challenge and verifier still need their own reviewed implementation. Octez Connect signing reference ↗
2. Authorize the sponsor’s operation. A reviewed, contract-specific mint could issue to the recipient from an authorized issuer account. The official SmartPy tutorial shows administrator-controlled minting to recipients; it is a reference, not a Nouns Money contract. Minting reference ↗
3. Pay and reconcile. The sponsor would pay authorized fees and storage costs, enforce a budget and duplicate-claim rules, and reconcile the operation’s observed result before recording delivery. “No collector gas” means sponsored costs, not a zero-fee chain. Octez operation reference ↗
4. Keep later actions separate. An issuer-sponsored mint would not automatically sponsor later transfers. Permits or relayed interactions need a compatible contract and their own authorization, replay protection and review. A future adapter must distinguish requested, submitted, confirmed and failed delivery from today’s local demo receipt.

Before activation, a separate owner authorization must cover the contract, signer, fee budget, abuse controls, recovery and real-chain testing. Issuer, backing asset, merchant network and legal setup are undecided. Nothing here promises issuance, allocation, future value, redemption or an airdrop.

Webhooks also remain proposed. A future delivery service would need authenticated events, event IDs, retries and reconciliation; no callback URL can be registered and no webhook is sent today.

A future agent-service request could bind a short scope, output constraints, one acceptance-test description, and an expiry. Approval of service work is a separate decision from any future payment. A provider would return an artifact reference and digest; verification would record its method and outcome. The user acceptance decision would remain a separate field.

import {
  approveLocalAgentServiceJob,
  createLocalAgentServiceReceipt,
  createLocalAgentServiceRequest,
  sha256Hex,
} from './packages/nouns-money-sdk/src/index.ts';

const request = createLocalAgentServiceRequest({
  scope: 'text-report',
  constraints: { maxOutputBytes: 256, mediaType: 'text/plain' },
  acceptanceTest: 'Compare the returned bytes to local expected text.',
});

// Separate local job approval. This authorizes no payment.
const approval = approveLocalAgentServiceJob(request, { approved: true });
const expected = new TextEncoder().encode('Local result.\n');
const bytes = new TextEncoder().encode('Local result.\n');
const receipt = await createLocalAgentServiceReceipt({
  request, approval, providerId: 'local-demo',
  resultRef: 'local://artifact/result.txt', bytes,
  expectedSha256: await sha256Hex(expected),
});
console.log(JSON.stringify(receipt, null, 2));
// unsigned/unverified · acceptance pending · payment not requested

Possible x402 V2 adapter boundary

As checked on 2 October 2026, the official HTTP guide describes the x402 V2 exchange through PAYMENT-REQUIRED (server requirements), PAYMENT-SIGNATURE (client payment payload) and PAYMENT-RESPONSE (server settlement-attempt result). These messages can carry payment requirements and settlement information; they do not define this proposed service-receipt schema or a user-acceptance contract. Read the HTTP 402 guide ↗, client/server flow ↗, and payment-identifier extension ↗.

A future adapter would require its own approved asset, network, scheme, facilitator and settlement implementation. It would keep request approval separate from payment approval and keep service result, payment status, reconciliation and user acceptance as distinct records. Any replay-protection extension must be explicitly advertised and implemented server-side; the SDK’s local idempotency keys do not substitute for x402 payment identifiers.

No Nouns Money x402 route, automatic payer, payment signer, facilitator connection, payment credential, network setting, HTTP intent endpoint or webhook delivery is present. Do not reuse existing PointCast X402_MODE=test as a dry-run switch: it labels receipts but does not prevent the settlement call. OpenAPI includes a descriptive proposed-integration extension only, with no new HTTP paths.