DEV Community: Wen cat

Read a Solana token's real rules with one RPC call (no SDK)

Wen cat — Wed, 11 Nov 2026 11:34:53 +0000

A token page can say anything. The mint account cannot lie. This post shows how to read a Solana token's real rules with one standard RPC call: no SDK, no wallet, no keys. We use it every Monday to re-check one token, and it recently corrected our own documentation.

The one call: getAccountInfo with jsonParsed

Every SPL token has a mint account. Ask any Solana RPC node for it with encoding: "jsonParsed" and the node decodes it for you:

// read-mint.mjs · Node 18+ (built-in fetch) · read-only
const MINT = process.argv[2];
const RPC = process.argv[3] || 'https://api.mainnet-beta.solana.com';

const res = await fetch(RPC, {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({
    jsonrpc: '2.0', id: 1, method: 'getAccountInfo',
    params: [MINT, { encoding: 'jsonParsed', commitment: 'finalized' }],
  }),
});
const { result, error } = await res.json();
if (error || !result?.value) throw new Error(JSON.stringify(error ?? 'account not found'));

const v = result.value;
const info = v.data?.parsed?.info ?? {};
const exts = info.extensions ?? [];
const has = name => exts.find(e => e.extension === name);

console.log('slot              ', result.context.slot);
console.log('owner program     ', v.owner);
console.log('account type      ', v.data?.parsed?.type);
console.log('decimals          ', info.decimals);
console.log('mint authority    ', info.mintAuthority ?? 'none (revoked)');
console.log('freeze authority  ', info.freezeAuthority ?? 'none (revoked)');
console.log('extensions        ', exts.map(e => e.extension).join(', ') || 'none');
console.log('transfer fee      ', has('transferFeeConfig') ? JSON.stringify(has('transferFeeConfig').state.newerTransferFee) : 'none');
console.log('transfer hook     ', has('transferHook') ? JSON.stringify(has('transferHook').state) : 'none');
console.log('permanent delegate', has('permanentDelegate') ? JSON.stringify(has('permanentDelegate').state) : 'none');

Run it:

node read-mint.mjs WENWENvqqNya429ubCdR81ZmD69brwQaaBYY6p3LCpk

How to read the answer

Field	What it tells you
`owner program`	`Tokenkeg…` = the original SPL Token program, which cannot carry extensions. `TokenzQd…` = Token-2022, where extensions are possible. Anything else is not a token mint.
`mint authority`	If set, more tokens can be created.
`freeze authority`	If set, a holder's account can be frozen.
`transferFeeConfig`	Token-2022 only: a fee withheld on every transfer, rounded up by the program.
`transferHook`	Token-2022 only: a program that runs on every transfer.
`permanentDelegate`	Token-2022 only: an address that can move or burn tokens from any holder.

None of these is good or bad by itself. A settlement token should have a freeze authority. The point is to know before you hold or integrate.

A real result

Read at finalized slot 468049071 for the WEN mint:

owner program      TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
account type       mint
decimals           5
mint authority     none (revoked)
freeze authority   none (revoked)
extensions         none
transfer fee       none

The owner is the original SPL Token program, so a transfer fee is not just absent; it is impossible.

This corrected us. Our almanac had said that WEN's January 2024 launch "stress-tested Token-2022". The mint says otherwise: WEN connects to Token-2022 through its history (the poem behind it was minted as an NFT with WNS, a standard built on Token-2022), while the fungible token itself lives on the original program. The launch stress-tested Solana and Jupiter's launchpad. We fixed 23 sentences in the open and kept a public note of what changed.

Make it repeat itself: a weekly GitHub Action

A check you run once is a screenshot. A check that reruns is evidence. Put the script in your repo and add a workflow:

name: Check mint
on:
  workflow_dispatch:
  schedule:
    - cron: "23 5 * * 1"   # every Monday
permissions:
  contents: read
jobs:
  mint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v5
        with:
          node-version: 22
      - run: node read-mint.mjs WENWENvqqNya429ubCdR81ZmD69brwQaaBYY6p3LCpk

In our version the script also appends its output to $GITHUB_STEP_SUMMARY, so the result appears on the run page for anyone to see, with the slot it was read at.

Two habits

Read the program before the page. One call tells you whether extensions are even possible.
Re-read on a schedule. Authorities can be revoked or, on some tokens, changed. A dated, rerunnable read beats a claim.

Read-only code. No wallet, no keys. Educational content, not financial advice.

The full script and the weekly job (Apache-2.0):
https://github.com/wen-watt/wen-watt.github.io/blob/main/tools/check-wen-mint.mjs

Two Token-2022 edges our tests missed: fee rounding and memo content

Wen cat — Mon, 09 Nov 2026 19:37:22 +0000

Two readers looked at one of our open Token-2022 examples and found two things our tests had missed. Both are easy to get wrong in any Solana payment code, so here they are, with the reproduction and the fix.

The example is Model 3 of the Wen Open Lab: a B2B settlement token with a transfer fee, accounts frozen by default, and a receiving account that requires a memo on every incoming payment.

Edge 1: Token-2022 rounds the transfer fee up

TransferCheckedWithFee makes the client pass the fee it expects. The program computes its own value and rejects the transfer if the two differ.

Our helper looked reasonable:

// before
export function expectedFee(amount: bigint): bigint {
  const pct = (amount * BigInt(FEE_BPS)) / 10_000n;   // integer division: rounds DOWN
  return pct > FEE_CAP ? FEE_CAP : pct;
}

Token-2022 uses ceiling division. With a 25 bps fee:

Amount (base units)	amount × 25 / 10,000	Token-2022 fee	Our old fee
400	1.0000	1	1
401	1.0025	2	1
1,000,000	2,500	2,500	2,500

At 401 base units the program expects 2, we passed 1, and the transaction failed:

Program log: Calculated fee does not match expected fee

Our original test paid a round amount where both formulas agree, so it never saw the difference. The fix uses the same formula as the program:

// after
export function expectedFee(amount: bigint): bigint {
  if (amount === 0n || FEE_BPS === 0) return 0n;
  const raw = (amount * BigInt(FEE_BPS) + 9_999n) / 10_000n;   // ceiling division
  return raw > FEE_CAP ? FEE_CAP : raw;
}

Two new tests guard it: a real payment of 401 base units now goes through, and expectedFee is compared with calculateFee from @solana/spl-token on ten edge amounts, including both sides of the fee cap.

Takeaway: never compute a Token-2022 fee with plain integer division. Use the library's calculateFee with the mint's fee config, or the exact ceiling formula, and test an amount that does not divide evenly.

Edge 2: Required Memo checks that a memo exists, not what it says

The receiving account has the Required Memo (MemoTransfer) extension. A transfer without a memo instruction right before it is rejected:

No memo in previous instruction required for recipient to receive a transfer

It is tempting to read that as "no invoice number, no payment". It is not. The program only checks that the previous instruction is a call to the Memo program. It never reads the text. In LiteSVM, with the real Token-2022 and Memo programs:

Memo before the transfer	Result on-chain
none	rejected
`invoice:INV-2026-0042` (correct)	accepted
`invoice:INV-WRONG-999`	accepted
`invoice:hello`	accepted

That is the design, so the architecture stays. What has to change is where the invoice number is checked: off-chain, at reconciliation. The Memo program logs Program log: Memo (len N) and then the text on the next line, so the memo can be read back from the transaction logs:

export function memosFromLogs(logs: string[]): string[] {
  const out: string[] = [];
  logs.forEach((l, i) => {
    const m = /Memo \(len (\d+)\)(?:: "(.*)")?$/.exec(l);
    if (!m) return;
    if (m[2] !== undefined) out.push(m[2]);                       // older format
    else if (logs[i + 1]?.startsWith('Program log: ')) out.push(logs[i + 1].slice(13));
  });
  return out;
}

export function matchInvoicePayment(logs: string[], invoiceId: string): boolean {
  const inv = memosFromLogs(logs).filter(m => m.startsWith('invoice:'));
  return inv.length === 1 && inv[0] === `invoice:${invoiceId}`;
}

Two more tests: the wrong-number payment passes on-chain (documenting the limit), and reconciliation accepts the right invoice and rejects the wrong one.

Takeaway: an on-chain rule proves exactly what it checks and nothing more. A required memo is a good guard against payments with no reference at all; matching the reference to an invoice is your job.

What changed

41 checks in LiteSVM now, all green (37 before).
The model page says plainly what the memo rule does and does not do.
Both questions are recorded with their tests on a "reader findings" page: one question, one accepted answer, an honest status (fixed or known limit), and the test that proves it.

If you write payment code on Token-2022, two cheap habits catch both edges: test an amount that does not divide evenly, and reconcile references off-chain.

Example code, not audited. Devnet only, with a new empty wallet.

The model, the four new tests and the full diff (Apache-2.0):
https://github.com/wen-watt/wen-watt.github.io/tree/main/lab/code

Checking a warranty card like a machine: a Token-2022 verifier

Wen cat — Fri, 06 Nov 2026 12:13:53 +0000

A customer walks into a repair shop with a phone and says: "It's under warranty, the card is in my wallet." The shop's software has one second to decide whether to believe it.

An earlier walkthrough built that card: a soulbound Token-2022 token with its details stored inside the mint. This one builds the other half, a verifier that checks the card the way a machine would, from public chain data only. No screenshots, no PDFs, no trust in the person holding the phone.

⚠️ Educational example, not audited. Devnet only. A warranty decision still follows the shop's policy and consumer law; the verifier only answers "is this card genuine?".

The eight questions

#	Question	How it is checked
1	Is this a Token-2022 mint?	the mint account's owner is the Token-2022 program
2	Is it one of one?	supply 1, decimals 0, mint authority removed
3	Is it soulbound?	the `NonTransferable` extension is present
4	Is the metadata inside the mint?	the `MetadataPointer` points to the mint itself
5	Did this shop issue it?	the metadata update authority is the shop's key
6	Is the warranty still valid?	`warranty_until` is today or later
7	Is it for this order?	`order_hash` equals SHA-256 of the buyer's order (optional)
8	Does this wallet hold it?	the holder's associated token account holds exactly 1

All eight must pass. Any single "no" makes the card not valid, and the verifier says which question failed.

A pure function first

The core takes raw account data and returns a list of checks. It does no network calls, which makes it easy to test and easy to reuse in a server, a wallet or an agent:

export function verifyReceipt(mint: PublicKey, mintInfo: AccountInfo<Buffer> | null, holderAta: PublicKey,
  ataInfo: AccountInfo<Buffer> | null, exp: Expected): { valid: boolean; checks: Check[] } {
  const checks: Check[] = [];
  const add = (name: string, ok: boolean, detail = '') => checks.push({ name, ok, detail });

  if (!mintInfo || !mintInfo.owner.equals(TOKEN_2022_PROGRAM_ID)) {
    add('mint is owned by Token-2022', false, mintInfo ? mintInfo.owner.toBase58() : 'not found');
    return { valid: false, checks };
  }
  add('mint is owned by Token-2022', true);
  const m = unpackMint(mint, mintInfo, TOKEN_2022_PROGRAM_ID);
  add('one of one: supply 1, decimals 0, mint authority removed',
    m.supply === 1n && m.decimals === 0 && m.mintAuthority === null);
  add('soulbound: NonTransferable extension present',
    getExtensionTypes(m.tlvData).includes(ExtensionType.NonTransferable));

  const ptr = getMetadataPointerState(m);
  add('metadata pointer points to the mint itself', !!ptr?.metadataAddress?.equals(mint));
  const raw = getExtensionData(ExtensionType.TokenMetadata, m.tlvData);
  if (!raw) { add('metadata stored inside the mint', false); return { valid: false, checks }; }
  const md = unpackMetadata(raw);
  const f = Object.fromEntries(md.additionalMetadata);
  add('issued by the expected shop (update authority)', !!md.updateAuthority?.equals(exp.merchant));

  const today = exp.today ?? new Date().toISOString().slice(0, 10);
  add('warranty still valid', typeof f.warranty_until === 'string' && f.warranty_until >= today);
  if (exp.order) add('order hash matches the buyer\'s order', f.order_hash === orderHash(exp.order));
  // ...then: the holder's associated token account must hold exactly 1 of this mint

Two choices worth copying:

Check the owner program before parsing. Parsing a random account as a mint "works" more often than you would like; checking the owner first rules out look-alikes.
Return every check, not just true/false. A person at a counter needs "expired" or "issued by someone else", not "invalid".

Then a thin network wrapper

export async function verifyReceiptOnChain(mintAddress: string, exp: Expected) {
  const connection = getConnection();
  const mint = new PublicKey(mintAddress);
  const ata = getAssociatedTokenAddressSync(mint, exp.holder, false, TOKEN_2022_PROGRAM_ID);
  const [mintInfo, ataInfo] = await connection.getMultipleAccountsInfo([mint, ata]);
  return verifyReceipt(mint, mintInfo, ata, ataInfo, exp);
}

One RPC call for two accounts. From the command line:

npx tsx src/05-verify-receipt.ts <MINT> <SHOP_KEY> <HOLDER_WALLET>

The tests try to fool it

Inside LiteSVM (a local Solana VM with the real Token-2022 program) the test suite issues real cards and then attacks the verifier from six sides:

PASS  M5 genuine soulbound card passes every check — 8 checks
PASS  M5 a different order is rejected (hash mismatch) — order hash matches the buyer's order
PASS  M5 a card from another issuer is rejected — issued by the expected shop (update authority)
PASS  M5 an expired warranty is rejected — warranty still valid
PASS  M5 a wallet that does not hold the card is rejected — held by the expected wallet
PASS  M5 a transferable (not soulbound) card is flagged — soulbound: NonTransferable extension present

The text after each dash is the name of the check that caught it. Each attack fails for exactly the reason it should.

Why this matters

For people: a warranty that cannot be lost in an inbox and cannot be faked with an edited PDF.
For shops: a check that runs in one RPC call and needs no customer database.
For agents and robots: a proof they can verify themselves, without trusting a screenshot or a human in the loop.

Limits worth stating plainly

The verifier trusts the shop's key. If that key is stolen, fake cards can look genuine; key management is the real security boundary.
warranty_until is compared as an ISO date string in UTC. Time zones and grace periods are policy decisions, not code.
The merchant can still update metadata (for example to extend a warranty). If that is not wanted, remove the update authority when issuing.
Not audited.

The verifier, the card it checks, the tests and five more Token-2022 models (Apache-2.0) are open in one place:
https://github.com/wen-watt/wen-watt.github.io/tree/main/lab/code

Card fees vs on-chain fees: five formulas instead of opinions

Wen cat — Fri, 06 Nov 2026 11:54:03 +0000

A customer walks into a repair shop with a phone and says: "It's under warranty, the card is in my wallet." The shop's software has one second to decide whether to believe it.

⚠️ Educational example, not audited. Devnet only. A warranty decision still follows the shop's policy and consumer law; the verifier only answers "is this card genuine?".

The eight questions

#	Question	How it is checked
1	Is this a Token-2022 mint?	the mint account's owner is the Token-2022 program
2	Is it one of one?	supply 1, decimals 0, mint authority removed
3	Is it soulbound?	the `NonTransferable` extension is present
4	Is the metadata inside the mint?	the `MetadataPointer` points to the mint itself
5	Did this shop issue it?	the metadata update authority is the shop's key
6	Is the warranty still valid?	`warranty_until` is today or later
7	Is it for this order?	`order_hash` equals SHA-256 of the buyer's order (optional)
8	Does this wallet hold it?	the holder's associated token account holds exactly 1

All eight must pass. Any single "no" makes the card not valid, and the verifier says which question failed.

A pure function first

The core takes raw account data and returns a list of checks. It does no network calls, which makes it easy to test and easy to reuse in a server, a wallet or an agent:

export function verifyReceipt(mint: PublicKey, mintInfo: AccountInfo<Buffer> | null, holderAta: PublicKey,
  ataInfo: AccountInfo<Buffer> | null, exp: Expected): { valid: boolean; checks: Check[] } {
  const checks: Check[] = [];
  const add = (name: string, ok: boolean, detail = '') => checks.push({ name, ok, detail });

  if (!mintInfo || !mintInfo.owner.equals(TOKEN_2022_PROGRAM_ID)) {
    add('mint is owned by Token-2022', false, mintInfo ? mintInfo.owner.toBase58() : 'not found');
    return { valid: false, checks };
  }
  add('mint is owned by Token-2022', true);
  const m = unpackMint(mint, mintInfo, TOKEN_2022_PROGRAM_ID);
  add('one of one: supply 1, decimals 0, mint authority removed',
    m.supply === 1n && m.decimals === 0 && m.mintAuthority === null);
  add('soulbound: NonTransferable extension present',
    getExtensionTypes(m.tlvData).includes(ExtensionType.NonTransferable));

  const ptr = getMetadataPointerState(m);
  add('metadata pointer points to the mint itself', !!ptr?.metadataAddress?.equals(mint));
  const raw = getExtensionData(ExtensionType.TokenMetadata, m.tlvData);
  if (!raw) { add('metadata stored inside the mint', false); return { valid: false, checks }; }
  const md = unpackMetadata(raw);
  const f = Object.fromEntries(md.additionalMetadata);
  add('issued by the expected shop (update authority)', !!md.updateAuthority?.equals(exp.merchant));

  const today = exp.today ?? new Date().toISOString().slice(0, 10);
  add('warranty still valid', typeof f.warranty_until === 'string' && f.warranty_until >= today);
  if (exp.order) add('order hash matches the buyer\'s order', f.order_hash === orderHash(exp.order));
  // ...then: the holder's associated token account must hold exactly 1 of this mint

Two choices worth copying:

Check the owner program before parsing. Parsing a random account as a mint "works" more often than you would like; checking the owner first rules out look-alikes.
Return every check, not just true/false. A person at a counter needs "expired" or "issued by someone else", not "invalid".

Then a thin network wrapper

export async function verifyReceiptOnChain(mintAddress: string, exp: Expected) {
  const connection = getConnection();
  const mint = new PublicKey(mintAddress);
  const ata = getAssociatedTokenAddressSync(mint, exp.holder, false, TOKEN_2022_PROGRAM_ID);
  const [mintInfo, ataInfo] = await connection.getMultipleAccountsInfo([mint, ata]);
  return verifyReceipt(mint, mintInfo, ata, ataInfo, exp);
}

One RPC call for two accounts. From the command line:

npx tsx src/05-verify-receipt.ts <MINT> <SHOP_KEY> <HOLDER_WALLET>

The tests try to fool it

Inside LiteSVM (a local Solana VM with the real Token-2022 program) the test suite issues real cards and then attacks the verifier from six sides:

PASS  M5 genuine soulbound card passes every check — 8 checks
PASS  M5 a different order is rejected (hash mismatch) — order hash matches the buyer's order
PASS  M5 a card from another issuer is rejected — issued by the expected shop (update authority)
PASS  M5 an expired warranty is rejected — warranty still valid
PASS  M5 a wallet that does not hold the card is rejected — held by the expected wallet
PASS  M5 a transferable (not soulbound) card is flagged — soulbound: NonTransferable extension present

The text after each dash is the name of the check that caught it. Each attack fails for exactly the reason it should.

Why this matters

For people: a warranty that cannot be lost in an inbox and cannot be faked with an edited PDF.
For shops: a check that runs in one RPC call and needs no customer database.
For agents and robots: a proof they can verify themselves, without trusting a screenshot or a human in the loop.

Limits worth stating plainly

The verifier trusts the shop's key. If that key is stolen, fake cards can look genuine; key management is the real security boundary.
warranty_until is compared as an ISO date string in UTC. Time zones and grace periods are policy decisions, not code.
The merchant can still update metadata (for example to extend a warranty). If that is not wanted, remove the update authority when issuing.
Not audited.

The verifier, the card it checks, the tests and five more Token-2022 models (Apache-2.0) are open in one place:
https://github.com/wen-watt/wen-watt.github.io/tree/main/lab/code

Testing Token-2022 in LiteSVM: 37 checks, no network

Wen cat — Fri, 06 Nov 2026 11:51:30 +0000

Every Token-2022 tutorial says "test on devnet first". Devnet is great, but it is slow for a test loop: airdrops get rate-limited, transactions take seconds, and a failed test leaves junk accounts behind.

LiteSVM runs a Solana virtual machine inside your test process. The real SPL Token-2022 and Memo programs are loaded, transactions execute in milliseconds, and nothing touches the network. This walkthrough shows the small harness behind the Wen Open Lab tests: 37 checks across six Token-2022 models, run in one command.

⚠️ Educational example, not audited. LiteSVM proves your instructions do what you think; it does not replace an audit or a devnet run.

1. The whole harness is five helpers

import { LiteSVM, FailedTransactionMetadata } from 'litesvm';
import { address, lamports, getTransactionDecoder } from '@solana/kit';
import { Keypair, PublicKey, Transaction, type TransactionInstruction } from '@solana/web3.js';

const svm = new LiteSVM();
let failures = 0;
const check = (name: string, ok: boolean, extra = '') => {
  console.log(`${ok ? 'PASS' : 'FAIL'}  ${name}${extra ? '  — ' + extra : ''}`);
  if (!ok) failures++;
};

Helper	Job
`send(ixs, signers)`	build, sign and execute a transaction; return `ok`, `err` and logs
`fund(keypair)`	airdrop test SOL instantly
`rent(space)`	rent-exempt minimum for an account size
`account(pubkey)`	read an account back in the shape `@solana/spl-token` expects
`check(name, ok)`	print PASS / FAIL and count failures

2. `send`: one bridge between web3.js and LiteSVM

The models are written with @solana/web3.js v1 and @solana/spl-token, the libraries most tutorials use. Current LiteSVM speaks @solana/kit types. One decoder joins them:

function send(ixs: TransactionInstruction[], signers: Keypair[]) {
  const tx = new Transaction().add(...ixs);
  tx.feePayer = signers[0].publicKey;
  tx.recentBlockhash = svm.latestBlockhash();
  tx.sign(...signers);
  const kitTx = getTransactionDecoder().decode(tx.serialize());
  const res = svm.sendTransaction(kitTx);
  svm.expireBlockhash();
  return res instanceof FailedTransactionMetadata
    ? { ok: false, err: res.toString(), logs: res.meta().logs() }
    : { ok: true, logs: res.logs() };
}

Two details matter:

expireBlockhash() after every send. Two identical transactions with the same blockhash have the same signature, and the second one is rejected as a duplicate. Expiring the blockhash keeps repeated steps independent.
Failures are values, not exceptions. A rejected transfer is often the expected result, so send returns it with its logs instead of throwing.

3. Reading accounts back

const fund = (k: Keypair) => svm.airdrop(address(k.publicKey.toBase58()), lamports(10_000_000_000n));
const rent = (space: number) => Number(svm.minimumBalanceForRentExemption(BigInt(space)));
function account(pk: PublicKey) {
  const a = svm.getAccount(address(pk.toBase58()));
  if (!a.exists) throw new Error('missing account ' + pk.toBase58());
  return { data: Buffer.from(a.data), owner: new PublicKey(a.programAddress),
           lamports: Number(a.lamports), executable: a.executable };
}

The object returned by account() is what unpackMint and unpackAccount from @solana/spl-token expect, so the same parsing code works locally and against a real RPC.

4. Test the "no", not only the "yes"

Token-2022 extensions are mostly about refusing things. The useful tests are the ones that expect a rejection and check why:

const noMemo = send(buildPayInvoice({ mint: mint.publicKey, from: buyerAcc.publicKey, to: sellerAcc.publicKey,
  payer: buyerCo.publicKey, invoiceId: null, amount: 1_000n * unit }), [buyerCo]);
check('M3 payment WITHOUT invoice number is rejected',
  !noMemo.ok && (noMemo.logs ?? []).some(l => /memo/i.test(l)),
  (noMemo.logs ?? []).find(l => /memo/i.test(l)) ?? '');

Matching the program log matters: a transaction can fail for an unrelated reason (wrong account, missing signer), and a test that only checks !ok would still pass.

5. What 37 checks look like

PASS  M1 soulbound receipt cannot be transferred — rejected by Token-2022
PASS  M1 nobody can mint a second copy
PASS  M3 payment WITHOUT invoice number is rejected
        — Program log: Error: No memo in previous instruction required for recipient to receive a transfer
PASS  M3 payment to a NOT approved company is rejected (account frozen)
        — Program log: Error: Account is frozen
PASS  M3 fee cap works (fee on 100,000 is 50, not 250)
PASS  M5 a card from another issuer is rejected — issued by the expected shop (update authority)
PASS  M5 an expired warranty is rejected — warranty still valid

ALL CHECKS PASSED

The full suite covers a soulbound receipt, a royalty transfer hook, an invoice-only settlement token, a Solana Pay payment link, a receipt verifier and a mint inspector.

6. Run it

npm install
npm run typecheck
npm test        # LiteSVM: local, no network, no funds

When everything passes locally, the same instructions go to devnet with npm run devnet, which prints Solana Explorer links for every step.

Limits worth stating plainly

LiteSVM runs the programs you load. A hook program that is not loaded (for example a third-party royalty program) is not executed; test what you can see, and say what you cannot.
Clock, slots and rent behave as you set them. Time-dependent logic needs explicit tests.
Local green is not mainnet-ready. Devnet, review and audit still come after.

The harness, the six models and the full test log (Apache-2.0) are open in one place:
https://github.com/wen-watt/wen-watt.github.io/tree/main/lab/code

How to read a Token-2022 transfer hook before you move an NFT

Wen cat — Mon, 26 Oct 2026 20:02:00 +0000

A creator sells a drawing as an NFT. Months later it changes hands on a marketplace the creator has never heard of. Does the creator still get a share?

For years, the honest answer on most chains was "only if the marketplace chooses to pay". Solana's Token-2022 program changes where that rule lives. A mint can carry a Transfer Hook: the address of a program that Token-2022 calls on every transfer. If that program says no, the transfer does not happen, whichever wallet or marketplace started it.

The Wen New Standard (WNS), the open NFT standard that grew out of the Wen community on Solana, uses exactly this extension for creator royalties. This walkthrough shows the part every buyer, wallet and marketplace should do first: read the rule before moving the token.

⚠️ Educational example, not audited. Devnet only, with a new, empty wallet. Never paste a real seed phrase into a script.

1. What a transfer hook is, in one table

Piece	Where it lives	What it does
`TransferHook` extension	inside the mint	stores the hook program id and the authority that may change it
Hook program	its own on-chain program	runs on every transfer; can reject it
Extra account list	a PDA of the hook program	tells clients which extra accounts the hook needs
`TransferChecked`	Token-2022	performs the transfer and calls the hook

A plain Transfer is not enough for a mint with a hook. Clients must use TransferChecked and add the extra accounts the hook asks for.

2. Step one: is this even a Token-2022 mint?

Never assume. The owner of the mint account tells you which token program it belongs to:

export async function detectTokenProgram(connection: Connection, mint: PublicKey): Promise<PublicKey> {
  const info = await connection.getAccountInfo(mint);
  if (!info) throw new Error(`Mint ${mint.toBase58()} not found on this cluster`);
  if (info.owner.equals(TOKEN_2022_PROGRAM_ID)) return TOKEN_2022_PROGRAM_ID;
  if (info.owner.equals(TOKEN_PROGRAM_ID)) return TOKEN_PROGRAM_ID;
  throw new Error(`Account ${mint.toBase58()} is not a token mint`);
}

Classic SPL tokens have no extensions at all, so a classic mint simply has no hook.

3. Step two: read the hook

export async function inspectRoyaltyHook(mintAddress: string) {
  const connection = getConnection();
  const mint = new PublicKey(mintAddress);
  const program = await detectTokenProgram(connection, mint);
  if (!program.equals(TOKEN_2022_PROGRAM_ID)) {
    return { mint: mintAddress, hook: null, note: 'Classic SPL token: no transfer hooks' };
  }
  const info = await getMint(connection, mint, 'confirmed', TOKEN_2022_PROGRAM_ID);
  const hook = getTransferHook(info);
  const hookProgram = hook?.programId ?? null;
  return {
    mint: mintAddress,
    hook: hookProgram?.toBase58() ?? null,
    isWnsRoyalty: hookProgram ? hookProgram.equals(WNS_ROYALTY_PROGRAM_ID) : false,
  };
}

WNS_ROYALTY_PROGRAM_ID is diste3nXmK7ddDTs1zb6uday6j4etCa9RChD8fJ1xay, taken from the official Wen Program Library README. Always copy program ids from the source, never from a screenshot or a chat.

Run it against any mint:

npx tsx src/02-royalty-transfer.ts <MINT_ADDRESS>

4. Look at the authority too

getTransferHook returns two fields: programId and authority. The program id is today's rule. The authority is who can change the rule tomorrow.

authority set → someone can point the hook to another program later;
authority null → the hook is fixed for the life of the mint.

Neither is "good" or "bad" in itself; a collection may need upgrades. But a buyer deserves to know which one it is, and a wallet can show it in one line.

5. Step three: transfer so that the hook runs

export async function transferWithRoyalties(mintAddress: string, to: string) {
  const connection = getConnection();
  const owner = loadKeypair();
  const mint = new PublicKey(mintAddress);
  const recipient = new PublicKey(to);
  const source = getAssociatedTokenAddressSync(mint, owner.publicKey, false, TOKEN_2022_PROGRAM_ID);
  const destination = getAssociatedTokenAddressSync(mint, recipient, false, TOKEN_2022_PROGRAM_ID);

  // resolves the hook's extra accounts on-chain
  const transferIx = await createTransferCheckedWithTransferHookInstruction(
    connection, source, mint, destination, owner.publicKey, 1n, 0, [], 'confirmed', TOKEN_2022_PROGRAM_ID,
  );
  const tx = new Transaction().add(
    createAssociatedTokenAccountIdempotentInstruction(owner.publicKey, destination, recipient, mint, TOKEN_2022_PROGRAM_ID),
    transferIx,
  );
  // if the hook rejects the transfer, the whole transaction rolls back
  return sendAndConfirmTransaction(connection, tx, [owner]);
}

The helper createTransferCheckedWithTransferHookInstruction reads the hook's extra account list from the chain and appends those accounts for you. If you build TransferChecked by hand and forget them, the transfer fails: that is the hook doing its job, not a bug.

6. Proof, locally

The example repository checks the reading step inside LiteSVM, a local Solana VM with the real Token-2022 program: no network, no funds. It creates an NFT mint with a TransferHook pointing to the WNS royalty program, then reads it back:

PASS  M2 NFT mint created with a transfer hook
PASS  M2 hook program read from the mint = WNS royalty distribution — diste3nXmK7ddDTs1zb6uday6j4etCa9RChD8fJ1xay

What the test does not do: it does not run the WNS royalty program itself (it is not loaded into the local VM). It proves that the rule is stored in the mint and can be read by anyone, which is the step a wallet or marketplace needs before every transfer.

Why this matters beyond NFTs

Creators keep a rule that travels with their work, instead of a promise that depends on each marketplace.
Buyers can see the rule before they pay, in one RPC call.
Wallets and agents can check it automatically: a transfer hook is machine-readable, a screenshot is not.

The same pattern fits any token whose transfers must follow a rule: tickets that only move between verified holders, licences, or royalties on music and photos.

Limits worth stating plainly

A hook enforces whatever its program says, including mistakes. Read the program's source and audits, not just its name.
Hooks add accounts and compute to every transfer; some older tools still use plain Transfer and will fail on hooked mints.
Not audited. Treat this as a model to learn from and test.

The code (Apache-2.0), the LiteSVM tests and the other Token-2022 models (a soulbound warranty card, B2B invoices, a payment link bridge) are open in one place:
https://github.com/wen-watt/wen-watt.github.io/tree/main/lab/code

How to model a warranty card as a soulbound Token-2022 token (devnet walkthrough)

Wen cat — Tue, 20 Oct 2026 11:42:15 +0000

Paper warranty cards get lost. PDF receipts sit in an inbox nobody searches. And a warranty is tied to one buyer, so it should not be resold together with a "second-hand" receipt.

Solana's Token-2022 program can express all of that with built-in extensions, without a custom on-chain program:

Need	Token-2022 tool
One unique card per purchase	0 decimals, mint 1, then remove the mint authority
Card details on-chain, no extra account	`MetadataPointer` + `TokenMetadata` stored inside the mint
Warranty stays with the buyer	`NonTransferable` extension (a "soulbound" token)
No personal data on a public ledger	store a SHA-256 hash of the order, not the order

This is the same light-NFT layout used by the Wen New Standard (WNS): zero decimals, supply locked at 1, metadata in the mint. Everything below runs on devnet only.

⚠️ Educational example, not audited. Use a new, empty devnet wallet. Never paste a real seed phrase into scripts.

1. The order, and why we hash it

export interface Order {
  orderId: string;
  sku: string;
  priceMinorUnits: number;   // e.g. cents
  currency: string;
  purchasedAt: string;       // ISO date
  warrantyMonths: number;
}

export function orderHash(order: Order): string {
  return createHash('sha256').update(JSON.stringify(order)).digest('hex');
}

The chain is public forever. So the card carries only a hash: the shop (or the buyer, who keeps the order JSON) can later prove "this card belongs to this order" by re-hashing it, while nobody else learns what was bought, by whom or for how much.

2. Size the mint before creating it

Token-2022 extensions change the account size, and the metadata is variable-length. Two numbers matter:

const extensions = [ExtensionType.MetadataPointer, ExtensionType.NonTransferable];
const mintLen = getMintLen(extensions);                                // space at creation
const metadataLen = TYPE_SIZE + LENGTH_SIZE + pack(metadata).length;   // grows later
const rent = await connection.getMinimumBalanceForRentExemption(mintLen + metadataLen);

A common bug: creating the account with mintLen + metadataLen as space. The account must be created with mintLen only; it is funded for the full size, because the metadata initialization reallocates it.

3. The metadata: name, hash and warranty date

const metadata: TokenMetadata = {
  mint, updateAuthority: merchant,
  name: `Receipt ${order.orderId}`,
  symbol: 'RCPT',
  uri: opts.uri,   // public JSON with non-personal details
  additionalMetadata: [
    ['order_hash', orderHash(order)],
    ['warranty_until', '2027-10-10'],   // purchasedAt + warrantyMonths
    ['sku', order.sku],
  ],
};

additionalMetadata is a list of free key/value pairs. A service desk only needs warranty_until and order_hash; wallets and explorers display the name and symbol.

4. The instruction order is the whole trick

const instructions = [
  SystemProgram.createAccount({ fromPubkey: merchant, newAccountPubkey: mint,
    space: mintLen, lamports: rent, programId: TOKEN_2022_PROGRAM_ID }),

  // extensions are initialized BEFORE the mint itself
  createInitializeMetadataPointerInstruction(mint, merchant, mint, TOKEN_2022_PROGRAM_ID),
  createInitializeNonTransferableMintInstruction(mint, TOKEN_2022_PROGRAM_ID),
  createInitializeMintInstruction(mint, 0, merchant, null, TOKEN_2022_PROGRAM_ID),

  // metadata lives inside the mint (the pointer points to itself)
  createInitializeInstruction({ programId: TOKEN_2022_PROGRAM_ID, metadata: mint,
    updateAuthority: merchant, mint, mintAuthority: merchant,
    name: metadata.name, symbol: metadata.symbol, uri: metadata.uri }),
  ...metadata.additionalMetadata.map(([field, value]) =>
    createUpdateFieldInstruction({ programId: TOKEN_2022_PROGRAM_ID, metadata: mint,
      updateAuthority: merchant, field, value })),

  // give exactly one to the buyer...
  createAssociatedTokenAccountIdempotentInstruction(merchant, buyerAta, buyer, mint, TOKEN_2022_PROGRAM_ID),
  createMintToInstruction(mint, buyerAta, merchant, 1, [], TOKEN_2022_PROGRAM_ID),

  // ...and make sure there will never be a second one
  createSetAuthorityInstruction(mint, merchant, AuthorityType.MintTokens, null, [], TOKEN_2022_PROGRAM_ID),
];

Three rules that save hours:

Extensions first, InitializeMint after. Mint extensions such as MetadataPointer and NonTransferable must be initialized on the uninitialized account.
Metadata after InitializeMint. The metadata instruction needs a live mint and its mint authority.
Remove the mint authority last. Zero decimals + supply 1 + no mint authority = a real one-of-one.

The whole thing fits in one transaction, signed by the merchant and the new mint keypair.

5. Prove it, locally, before touching devnet

The example repository runs every claim inside LiteSVM, a local Solana VM: no network, no airdrop, results in a second.

PASS  M1 receipt minted (soulbound=true)
PASS  M1 supply is exactly 1, decimals 0, mint authority removed
PASS  M1 metadata inside the mint: name, order hash, warranty date — warranty_until=2027-10-10
PASS  M1 buyer holds the receipt
PASS  M1 soulbound receipt cannot be transferred — rejected by Token-2022
PASS  M1 nobody can mint a second copy

The same test also builds the card with soulbound: false and checks that it can be transferred. That is useful when the shop wants the warranty to follow a gifted or resold product.

Reading the card back is plain unpacking:

const m = unpackMint(mintAddress, accountInfo, TOKEN_2022_PROGRAM_ID);
const md = unpackMetadata(getExtensionData(ExtensionType.TokenMetadata, m.tlvData)!);
// m.supply === 1n, m.decimals === 0, m.mintAuthority === null
// md.additionalMetadata -> order_hash, warranty_until, sku

6. Run it on devnet

solana-keygen new -o devnet-wallet.json            # new throwaway wallet
solana airdrop 2 $(solana-keygen pubkey devnet-wallet.json) --url devnet
npm install
npm test                                           # LiteSVM first
KEYPAIR=./devnet-wallet.json npm run devnet        # then devnet

The devnet script refuses to run against any non-devnet RPC and prints Solana Explorer links (?cluster=devnet) for the mint and the buyer's account, so anyone can open the card and check the metadata themselves.

What this model does not do

It does not replace consumer law. The token is a proof; the warranty terms still live in the shop's policy.
Soulbound is not "unlosable". If the buyer loses the wallet, the card is lost with it. A shop can reissue a card to a new address after its own checks; the old one stays as history.
Update authority is still the merchant. That allows corrections (for example, extending warranty_until). If you want the card frozen forever, remove the update authority as well.
Not audited. Treat this as a model to learn from and test, not production code.

The code (Apache-2.0), the LiteSVM tests and three more Token-2022 models (creator royalties, B2B invoices, a payment link bridge) are open in one place:
https://github.com/wen-watt/wen-watt.github.io/tree/main/lab/code

DEV Community: Wen cat

Read a Solana token's real rules with one RPC call (no SDK)

The one call: getAccountInfo with jsonParsed

How to read the answer

A real result

Make it repeat itself: a weekly GitHub Action

Two habits

Two Token-2022 edges our tests missed: fee rounding and memo content

Edge 1: Token-2022 rounds the transfer fee up

Edge 2: Required Memo checks that a memo exists, not what it says

What changed

Checking a warranty card like a machine: a Token-2022 verifier

The eight questions

A pure function first

Then a thin network wrapper

The tests try to fool it

Why this matters

Limits worth stating plainly

Card fees vs on-chain fees: five formulas instead of opinions

The eight questions

A pure function first

Then a thin network wrapper

The tests try to fool it

Why this matters

Limits worth stating plainly

Testing Token-2022 in LiteSVM: 37 checks, no network

1. The whole harness is five helpers

2. send: one bridge between web3.js and LiteSVM

3. Reading accounts back

4. Test the "no", not only the "yes"

5. What 37 checks look like

6. Run it

Limits worth stating plainly

How to read a Token-2022 transfer hook before you move an NFT

1. What a transfer hook is, in one table

2. Step one: is this even a Token-2022 mint?

3. Step two: read the hook

4. Look at the authority too

5. Step three: transfer so that the hook runs

6. Proof, locally

Why this matters beyond NFTs

Limits worth stating plainly

How to model a warranty card as a soulbound Token-2022 token (devnet walkthrough)

1. The order, and why we hash it

2. Size the mint before creating it

3. The metadata: name, hash and warranty date

4. The instruction order is the whole trick

5. Prove it, locally, before touching devnet

6. Run it on devnet

What this model does not do

2. `send`: one bridge between web3.js and LiteSVM