Wen Open Lab: Open IntegrationStage 0 · Roadmap
- 0 · Roadmap
- 1 · Receipts & warranty
- 2 · Creator royalties
- 3 · B2B invoices
- 4 · Payments bridge
- 5 · Simulator
- 6 · Devnet: repeat it
- ✓ · Trust chain
- ★ · Benefits & use

Knowing what Wen is was the first step. The Lab is the second: we take the open tools behind Wen — the WNS token layout, Solana Token-2022 and Solana Pay — and build free, working models that a developer, a shop, a fintech team or a bank can study, test and reuse. Everything is open, step by step, in public.
Why this exists
The almanac explains Wen in depth: the poem, the airdrop, the WNS standard, the link with Jupiter and Solana. But description alone is not utility. Utility starts when someone can take a model, run it, check it and build on it. The Lab does exactly that, and does it in the open, so that the value of Wen's technical heritage is shared freely rather than locked away.
Where it applies
| Sphere | What the Lab gives | Stage |
|---|---|---|
| B2C e-commerce | Tamper-proof receipts and warranty cards as NFTs, payment links and order confirmation | 1, 4 |
| Creators and marketplaces | Royalties enforced by the token itself, not by a platform's goodwill | 2 |
| B2B trade | Settlement with a built-in fee, approved counterparties only, mandatory invoice number | 3 |
| Acquiring and fintech | A technical bridge from on-chain payment to the merchant's order system, plus a cost and speed model | 4, 5 |
| Everyone | A clear map of benefits, limits and next steps | ★ |
The roadmap, built in the open
- 0 · Roadmap and rules. This page: purpose, spheres, open use policy, verification log. live
- 1 · Receipts and warranty. A Token-2022 NFT with the WNS layout: proof of purchase without personal data, optional soulbound warranty. 12 checks passed
- 2 · Creator royalties. Read which program enforces royalties on an NFT and transfer it so the hook runs. hook read verified
- 3 · B2B invoices. Transfer fee, approved counterparties, mandatory invoice memo. 9 checks passed
- 4 · Payments bridge. Solana Pay link, payment watcher, validation, webhook to the shop. link verified
- 5 · Simulator. Compare card acquiring and on-chain payments with your own numbers. interactive
- ★ · Benefits and use. Who gains what, where it fits, and where it does not. live
- 6 · Devnet: repeat it yourself. A published script runs Models 1 and 3 on public devnet and prints explorer links. Anyone can repeat it with a new, empty wallet. ready to run
- ✓ · Trust chain. Every key claim with its status and sources: verified, reported, opinion, unverified or conflicting. live
- 6b · Public devnet run. Run the script in public and publish the addresses on the devnet page. next
- 7 · Pay in WEN, the shop receives USDC. The buyer pays in WEN, a Jupiter swap in the same transaction converts it, the shop receives a stablecoin. Builds on Stage 4. next model
- 8 · WNS group registration. Add receipts to a WNS collection through the official program, built from the official repository's IDL. planned
- 9 · Royalty hook program sample. An Anchor transfer-hook program with tests, compared line by line with WNS royalty distribution. planned
- 10 · Threat model and audit checklist. Compute limits, account substitution, zero-price transfers, key management. planned
- 11 · Merchant plugin sketch. How an online store connects the payments bridge to its order system through a webhook. planned
Verification log
Models 1–4 are executed inside LiteSVM, a local Solana virtual machine that runs the real SPL Token-2022 and Memo programs, without network access and without real funds. The negative cases matter as much as the positive ones: a soulbound receipt must refuse to move, a payment without an invoice number must fail. Output of the last run (October 10, 2026):
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
PASS M1 receipt minted (soulbound=false)
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 transferable receipt can be resold or gifted
PASS M1 nobody can mint a second copy
PASS M3 settlement mint created (fee 0.25% cap 50, frozen by default)
PASS M3 seller account requires an invoice memo
PASS M3 issuer funds the buyer account
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 invoice INV-2026-0042 paid with memo to approved company
PASS M3 invoice number is recorded on-chain (memo in logs)
PASS M3 seller received amount minus fee; fee withheld for the platform — received 997.5, fee 2.5
PASS M3 fee cap works (fee on 100,000 is 50, not 250)
PASS M2 NFT mint created with a transfer hook
PASS M2 hook program read from the mint = WNS royalty distribution — diste3nXmK7ddDTs1zb6uday6j4etCa9RChD8fJ1xay
PASS M4 payment link round-trips: recipient, amount, token, reference, memo — solana:WENWENvqqNya429ubCdR81ZmD69brwQaaBYY6p3LCpk?amount=10…
PASS M4 every order gets a unique reference
ALL CHECKS PASSED
Two real pitfalls were found while building, which is exactly why the rule is "verify your own model": the npm package @wen-community/wen-new-standard has been removed as malicious, and recent versions of @solana/spl-memo point to a different memo program than the canonical one Token-2022 checks. Both are handled in the code.
Run it yourself
# get the files from lab/code/ (package.json, tsconfig.json, src/, test/)
npm install
npm run typecheck # TypeScript, strict mode
npm test # local Solana VM, no network, no real funds
For devnet: create a wallet with the Solana CLI, request devnet SOL, then set KEYPAIR and optionally RPC_URL before calling the send functions in each file. Start with a fresh, empty wallet.
Background reading
- Wen Open Lab review — the whole section in one story, with the devnet plan and the next model
- Wen Program Library review — the code behind WNS, section by section
- SPL, Token-2022 and WNS explained
- Solana Token-2022 and WEN: compliance and testing
- WNS 0.0, explained — the January 2024 proposal every Lab model builds on
- The launch-day stress test — how the WEN airdrop tested Solana and gave birth to WNS adoption
- More than a meme — mint, authorities and supply: what to verify in any token
- On-chain numbers, explained — public data as a public service
- Most integrated programs — usefulness counted in Solana programs
- The WNS standard, Wen by Solana 2024–2026 (PDF)
Wen in pictures





Where Wen fits in this model
Wen is the reason this Lab exists. The WEN token was the first live, mass-scale test of the Token-2022 and WNS structures these models use. Each model below shows an optional, honest place for WEN: as a payment or tip option, a loyalty reward, or simply the community signature of the work. The rails themselves are open and work with any token.
The Wen thread: one contract, everywhere
Every model in the Lab is free and open, and every one carries the same signature: the $WEN token contract. Copy it, repeat it in your own docs, and always verify it against an explorer before use.
WENWENvqqNya429ubCdR81ZmD69brwQaaBYY6p3LCpk
Open use policy
- Free and open. All Lab code is released under the Apache License 2.0, the same license as the Wen Program Library. Use it, change it, ship it, commercially or not; keep the license notice.
- Open tools only. Built on public, documented tools: Solana SPL Token-2022 (Token Extensions), the token layout of the Wen New Standard (WNS), Solana Pay, and LiteSVM for local testing.
- The rule: always verify your own model. Run the tests, start on devnet, read the official documentation, review every account and amount, and get an independent audit before any mainnet use. A model that is not checked is not a model, it is a guess.
- Not audited, not advice. These are educational examples. They are not financial, legal or tax advice, and not a licensed payment or banking product. Payments, stablecoins and acquiring are regulated activities in most countries.
- Security. Never paste a private key into a website. Do not install the npm package
@wen-community/wen-new-standard: npm removed it as malicious. Build from official sources.
Spoken by Wen, for the community. More in our editorial and data policy.
Wen Open Lab · roadmap · all code · Wen Program Library on GitHub