Two-transaction note delegation

1. A creates a custom note committed to B's signing key.
2. B chooses C and signs an authorization offchain, without submitting a transaction.
3. C consumes the original note using B's signature.

The note ID and recipient commitment do not change. This requires a custom note from the start; it does not reassign an existing P2ID note. The assets never enter B's account.

Run

Requires Node.js 22.18+ and npm. SDK: 0.16.0-rc.7, supporting macOS ARM64/x64 and Linux x64 with glibc for this Node example.

npm ci
npm start          # Local execution against devnet, no submissions
npm run devnet     # Fund fresh accounts and submit the two transactions

Node runs the TypeScript files directly. Use npm run typecheck to check types.

Local mode uses a synthetic note. It needs devnet access but does not request tokens, prove, or submit transactions.

Devnet mode uses fresh accounts, free faucet tokens, and the remote prover. It logs the confirmed transaction IDs and C's balance. Faucet issuance and A's funding-note consumption are setup, excluded from the two-transaction count. Both application transactions pay fees; C pays from the assets it receives.

Files

• src/main.ts: the complete flow, with separate clients for A and C.
• src/delegation.ts: note creation, signing, JSON authorization, and consumption.
• src/delegable.masm: the note's spending conditions.
• src/devnet.ts: faucet, fees, and transaction submission.

C is chosen after the creation transaction is confirmed. B's dedicated signing key stays outside both clients. All roles run in one process for convenience; in an integration, keep B's key in its own signer. C receives only the JSON authorization and fetches the public note by ID.

The signature binds the note and consuming account:

Poseidon2(NoteID || [consumer_suffix, consumer_prefix, 0, 0]
                || [20260904, 1, 0, 0])

The last word is an example domain/version marker, not an expiry or network ID. The note script reads the actual IDs from execution context and verifies B's signature before releasing assets.

Limits

B can authorize more than one consumer. Only one can spend the note, so the offchain handoff does not give C irrevocable ownership before consumption.

This is an unaudited proof of concept, without authorization expiry, revocation, key rotation, or explicit network separation. Transaction expiry is not authorization expiry.

The SDK creates temporary databases and keystores; never share them. Reruns use fresh accounts. The pinned SDK may emit MASM diagnostic-source and deprecated-dependency warnings; this is not a production template.