> For the complete documentation index, see [llms.txt](https://parad0xlabs.gitbook.io/parad0xlabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://parad0xlabs.gitbook.io/parad0xlabs-docs/technical-reference/wrapped_null.md). # Wrapped NULL **Our hard line, up front:** we will never launch another token. **NULL is the only coin — one supply, one chart, for everyone.** The *only* wrapped form we will ever ship is **wNULL: a 1:1 machine balance for NULL**, so software and agents can pay smoothly inside Web0. It is not a coin, it has no separate price, and it is always redeemable 1:1 for NULL. wNULL does not exist yet — this page is our thinking, in the open: why a balance earns its place, why a second *token* never will, and how we let people reach NULL from any chain. Tradeoffs written down plainly, not hand-waved. *** ## The question, stated plainly Web0 is trying to be a small economy: names are bought, auctions are settled, services are paid for per call, agents transact with each other thousands of times a day. Every economy needs a way to keep score and move value. The question is whether that should be: * **just the tokens people already hold** (SOL, USDC, NULL), or * **an internal unit** — a wrapped NULL — that everything inside Web0 runs on. It's tempting to say "a real universe needs its own money." But a universe is defined by its rules, not by how many coins it mints. So before adding anything, the first step is to ask what an internal money would actually *do* that we can't already. *** ## What "money" actually is (three jobs, not one) Money does three separate jobs. They're easy to blur together, and most "we need a token" arguments fall apart once you split them: | Job | What it means | What Web0 uses today | | -------------------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Unit of account** | the yardstick you price things in | US dollars — names and fees are priced in USD internally, then charged in the token actually paid; no USD token is minted | | **Medium of exchange** | what actually moves when you pay | any of SOL, USDC, or NULL, settled on Solana | | **Store of value / stake** | what you hold to belong to the system | NULL — the native token | The important insight: **a unit of account does not need to be a token.** Web0 already prices everything in USD internally without minting a "USD-credit." A wrapped NULL only earns its place if it improves the *medium of exchange* or the *stake* job — not the accounting one, which is already solved. *** ## What Web0 already has that looks like internal money Three things already function like the plumbing of an internal economy: 1. **USD as the internal yardstick.** Names and protocol fees are priced in USD and charged in whichever token is actually used (SOL or NULL); premium-name auctions set a market price for the most contested names. That's an internal accounting standard with no token attached and no peg to defend. 2. **NULL as the native asset and the advantage token.** NULL holders get home-team terms inside Web0 — you can pay registration and protocol fees directly in NULL today, and a bidding bonus for NULL-denominated auction bids is planned for v1.1. NULL is the thing you hold to belong. 3. **Receipts and the reputation layer as a credit history.** Every paid action leaves a signed receipt. Those receipts feed an identity/reputation proof. In a real economy this is the credit bureau — a memory of who pays and who delivers. It is arguably the most money-like thing in the stack, and it isn't a coin at all. So the real question is narrower than "should we have money." It's: **do we need a new medium of exchange (wNULL), or is multi-token-plus-USD-accounting enough?** *** ## The real reasons someone would wrap NULL There are exactly three reasons that hold up. Everything else is narrative. ### Reason 1 — Composability (the technical one) **Verified on-chain:** the NULL mint is owned by the **Token-2022** program (`TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`), not the legacy SPL Token program. The mint account's owner is the definitive way to tell which standard a token uses, and for NULL the answer is Token-2022. Token-2022 is the newer Solana token standard, and support for it across wallets, DEXes, and third-party programs is still uneven — the two token programs have different account layouts, and not every product handles both everywhere. We hit this ourselves: an auction vault that assumed the older standard had to be corrected to handle Token-2022. If our own code had to be adjusted, external integrations will hit the same edge. A **standard-SPL wNULL** — a 1:1 wrapper of NULL in the older, universally-supported token format — would simply work everywhere with no special handling. This is the cleanest, least controversial reason to wrap, because it is pure plumbing: it changes nothing about the economics, only about compatibility. The caveat: this is a *composability* fix, not an *economics* one. It only earns a public wrapper if integrators actually hit the Token-2022 wall. Inside our own stack we can simply handle Token-2022 correctly (we now do) and skip the wrapper. ### Reason 2 — Gasless, high-frequency agent payments (the strong one) An AI agent paying for 5,000 small API calls in a session does not want to sign and pay a separate network fee on every single one. That is the worst possible UX for the exact audience Web0 is built for. A **prepaid balance** — top up once (in NULL), then spend many times inside Web0 without signing each transaction, and withdraw the remainder later — fixes this. This is the model exchanges and prepaid cards use. It is the one place where an internal unit genuinely pays for its complexity, because it removes real friction that no amount of clever accounting can. And because you top up in NULL, it deepens NULL's usefulness rather than competing with it. The cost is real, though: a prepaid balance means *something holds the deposit while it's unspent*. That introduces custody and the responsibilities (and scrutiny) that come with holding other people's value. That tradeoff is the whole debate, and it's covered in Risks below. ### Reason 3 — One balance instead of three (the convenience one) A user who has to think "do I pay this in SOL, USDC, or NULL?" has more friction than one who just has a Web0 balance. A single internal unit can hide that choice. This is real but the weakest of the three, because the same smoothness can be delivered by auto-routing at the moment of payment without a persistent internal token. *** ## The options, laid out Four concrete shapes this could take, from lightest to heaviest. They are not mutually exclusive — A is the floor, and B/C can be added on top. ### Option A — No wrapper. Multi-token plus USD accounting. (Status quo) Keep paying in SOL, USDC, or NULL. Keep pricing in USD internally. NULL keeps its advantages. | Pros | Cons | | ------------------------------------------ | ----------------------------------------- | | Nothing new to build, audit, or defend | Token-2022 friction stays for integrators | | No liquidity split, no peg, no custody | Agents still sign every micro-payment | | Matches the "pay with what you have" pitch | "One balance" convenience never arrives | | Lowest regulatory surface | | ### Option B — wNULL as a pure composability wrapper A 1:1, mint-and-burn wrapper that converts Token-2022 NULL into standard-SPL wNULL and back. No new economics. It exists only so NULL works smoothly across the wider Solana ecosystem. | Pros | Cons | | --------------------------------------------- | --------------------------------------------------- | | NULL becomes usable in any wallet/DEX/program | Two representations of the same token to track | | 1:1 and deterministic — no price, no slippage | Minor liquidity fragmentation (NULL vs wNULL pools) | | Small, well-understood contract surface | Doesn't help agent gas friction by itself | | Reversible anytime | Another contract to audit and maintain | ### Option C — wNULL as a prepaid balance / payment channel A balance you top up in NULL and spend gaslessly across Web0 (x402 calls, auction deposits), settling on-chain in batches and withdrawing the rest on demand. | Pros | Cons | | --------------------------------------------- | --------------------------------------------------- | | Removes per-payment signing — huge for agents | Requires holding unspent deposits (custody) | | Deepens NULL utility (you top up in NULL) | Highest regulatory weight of the four | | Enables instant, fee-light micro-payments | More complex; needs careful settlement design | | Natural home for agent automation | If centralized, it's a trust point — must be earned | ### Option D — wNULL as the mandatory internal currency Everything inside Web0 is denominated and settled in wNULL. SOL/USDC only appear at the on-ramp and off-ramp. | Pros | Cons | | ----------------------------------- | ----------------------------------------------- | | Cleanest single internal accounting | Forces a conversion step on everyone — friction | | Strong "closed economy" narrative | Directly contradicts "pay with what you have" | | Every action reinforces one unit | Worst liquidity fragmentation | | | Heaviest custody + regulatory exposure | *** ## The part people get wrong: "frictionless wNULL ↔ NULL ↔ SOL" This is the heart of the ask, and it has two halves that behave very differently. Being precise here is what separates a real design from a wish. ### wNULL ↔ NULL — can genuinely be frictionless Wrapping is **1:1 and deterministic**. One NULL in, one wNULL out; burn one wNULL, get one NULL back. There is no price, no slippage, no counterparty risk on the rate. It is the same mechanic that wrapped SOL (wSOL) uses every day on Solana. This half of the ask is real and clean: **wNULL ↔ NULL can be as smooth as a checkbox.** ### NULL ↔ SOL — not "frictionless"; it's a market trade Converting NULL to SOL (or USDC) is a **market trade**, not a wrap. It goes through a liquidity pool or an aggregator, and it has a price, slippage, and a dependency on how much liquidity exists at that moment. No design can make a market trade "frictionless" in the strict sense — someone is always taking the other side at a price. What you *can* do is make it **feel** like one step: a one-tap "pay in SOL, land in NULL" flow that routes the swap through an aggregator behind the scenes. The user experiences one action; under the hood it's a wrap (free, 1:1) plus a swap (market rate). The framing for users is: **wrapping is free and exact; swapping is a trade at the going rate.** Promising "frictionless NULL↔SOL" without that distinction would be the kind of overclaim this project is trying not to make. ### The clean mental model ``` SOL / USDC <—— market swap (price, slippage) ——> NULL <—— 1:1 wrap (free, exact) ——> wNULL ^ ^ | external money, what people arrive with internal money, what Web0 runs on ``` The wrap boundary is smooth. The swap boundary is a market. A good product hides the *steps* but should never hide the *fact* that one side is a trade. *** ## Risks, stated without softening them * **Liquidity fragmentation.** Every representation (NULL, wNULL) splits trading depth. Thinner pools mean worse prices for everyone. This is the most common way wrapped tokens quietly hurt the thing they were meant to help. * **Custody.** A prepaid balance (Option C/D) means unspent value sits somewhere. If that somewhere is us, we are holding other people's money, with everything that implies — security, solvency, and trust that has to be continuously earned. * **Regulatory surface.** A thing everyone deposits into and spends from starts to resemble stored-value money. That invites scrutiny. The lighter the design, the smaller this surface. * **Peg and redemption.** A 1:1 wrapper is only as trustworthy as the guarantee that you can always unwrap. That guarantee has to be airtight and verifiable on-chain, or wNULL stops being "NULL" and becomes its own riskier thing. * **Complexity and audit cost.** Every new contract is new attack surface. The Web0 thesis is that fewer intermediaries is better; an internal money is, by definition, one more piece in the middle. It has to clearly earn its place. *** ## Precedent: this isn't new ground * **Wrapped SOL (wSOL)** is the cleanest example of Option B done right: a 1:1 wrapper that exists purely so the native asset works inside programs that expect the token standard. It carries no extra economics and nobody treats it as a separate currency. * **Exchange and app balances** are Option C: deposit once, transact many times off-chain-fast, withdraw later. Great UX, real custody. * **Layer-2 gas abstraction** (paying fees in a token other than the chain's native gas) is the same instinct as Reason 2 — remove per-action fee friction for high-frequency users. The lesson from all three: wrappers and balances are good *tools* and bad *identities*. They work when they quietly solve a specific friction, and they age badly when they're minted to feel like a bigger economy. *** ## Our hard line: NULL is the only coin we will ever launch NULL is the one public token our community holds and trades — one asset, one supply, one chart. We will never introduce a *second traded asset*. A wNULL with its own price would split liquidity, attention, and trust across two things that are supposed to be the same value, and that is the most common way a wrapper quietly damages the token it was meant to help. We're not doing it. So our rule is firm and permanent: > **NULL is the public asset. wNULL is the machine balance — not a coin.** 1 NULL in = 1 wNULL credit out. Withdraw = NULL back. No separate price. No separate supply. No second launch, ever. In the product we call it **"Web0 Balance."** We use the word *wNULL* only in technical contexts where the on-chain asset has to be named directly. Nobody should ever feel like they bought a second coin — they topped up an account. *** ## Multichain entry: one token, every on-ramp A single token does not mean a single front door. Most of the people we want — and most of the liquidity — are not on Solana yet. They're on Ethereum, Base, Arbitrum, BNB, and a dozen other chains. So the goal is simple: **let anyone jump into Web0 from whatever chain they already live on, and land on NULL.** The way to do that *without* breaking the one-coin rule is to keep NULL canonical on Solana and treat other chains as **entrances, not new issuances**: * **Bridge in, don't re-mint.** A user on Base bridges USDC or ETH through a battle-tested bridge; we route it to NULL (or straight into a Web0 Balance) on Solana. We never mint a "NULL on Ethereum" with its own supply — that would be exactly the second coin we just swore off. Canonical NULL stays one asset on one chain; bridged value is just value arriving. * **The Web0 Balance is the universal landing spot.** Whatever chain you come from, you end up with one balance you spend across `.null`, x402 calls, and auctions. The multichain complexity stays at the door; inside, it's one unit. * **We already have the first piece.** Our x402 layer has a cross-chain solver pattern — an agent on Base pays, and the receipt anchors on Solana. The same plumbing generalizes: pay from anywhere, settle and prove on Solana. * **Only bridges that have earned it.** Bridges are the most-attacked thing in crypto. We integrate established, audited routes (the kind that move billions and have survived real adversaries) — we do not roll our own bridge. If a chain has no safe route, it waits until it does. The caveat: every bridge we add is new surface and new dependency risk. So multichain is a *deliberate expansion* — one well-vetted route at a time, not a checklist race to brag about "20 chains supported." One token, many safe doors. *** ## Our decision **We're building an internal wrapped/balance form of NULL — and we are not shipping a second public token.** Concretely, the highest-value version is **Option C: a prepaid, gasless NULL balance** for agents and x402, with **Option B (a public 1:1 SPL wrapper) added later only if Token-2022 composability becomes a real blocker for integrators.** We avoid Option D. And we pair it with **multichain entry** (above), so people can reach NULL from any chain without us ever minting a second one. ### Rollout, in phases 1. **Announce the design, not a token.** Publish this note. Make explicit: not a new launch, not a relaunch, not a supply expansion. A 1:1 operating layer for agent payments. 2. **Build the prepaid NULL balance.** Deposit NULL once; the app shows "Web0 Balance." Agents spend from it across x402 calls, tips, premium rooms, domain actions, and auctions. Withdraw unused NULL anytime. 3. **Let receipts become the flywheel.** Every internal spend emits a signed receipt; receipts feed Dark Passport / reputation; reputation unlocks better access — which drives more NULL utility. The economy becomes identity and trust, not just payments. 4. **Add a public SPL wNULL only if integrations demand it.** If wallets, DEXes, or agent tooling genuinely struggle with the Token-2022 mint, deploy a 1:1 SPL wrapper. If not, keep the balance internal. ### The architecture ``` SOL / USDC │ one-tap swap — market price, slippage shown (a trade, not a wrap) ▼ NULL (public token, Token-2022) │ exact deposit, 1:1 ▼ Web0 Balance (wNULL — the machine account) │ gasless internal spends ▼ x402 calls · .null actions · tips · premium rooms · auctions │ ▼ signed receipts │ ▼ Dark Passport · reputation · access tiers ``` ### Core operations ``` deposit(NULL) → credit Web0 Balance 1:1 spend(balance) → signed receipt + balance decrease withdraw() → debit balance + return NULL 1:1 ``` ### Hard invariants (non-negotiable if this is ever built) ``` balance credited ≤ NULL actually held in the vault (fully backed, always) no admin mint of balance out of thin air unwrap / withdraw is always available unless the chain itself is down a pause may stop new deposits — it must never block withdrawals all vaults and reserves are visible and verifiable on-chain ``` These are what keep "Web0 Balance" exactly equal to NULL. Break any one of them and it stops being a receipt for NULL and becomes its own riskier thing. *** ## What to avoid * **Don't make the balance mandatory on day one.** Payments already accept the right token for the action — registration in SOL or NULL, English auctions settling in SOL (NULL settlement planned) — and that "pay with what you have" on-ramp is a strength. Forcing everyone through wNULL first would contradict it. * **Don't claim "frictionless SOL ↔ NULL."** NULL ↔ wNULL is exact 1:1. SOL/USDC ↔ NULL is a market swap with price and slippage. The product can make it one tap; the message must stay clear about which boundary is a trade. * **Don't mint a narrative coin.** No second chart, no second supply, no hidden peg. *** ## Where this lands, in one line **NULL is the public asset. Web0 Balance is the machine account. Receipts are the reputation layer.** The universe is the protocol and the receipt graph — not the coin count. Build wNULL the day it removes a friction the current design genuinely can't, keep it 1:1 and fully backed, and never let it become a second token. *** *This is a living design note. If you have a sharper argument for or against any option here, that's exactly what this document is for.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://parad0xlabs.gitbook.io/parad0xlabs-docs/technical-reference/wrapped_null.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.