> 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/web0-how-it-all-connects/scenarios.md). # Real Scenarios *** ## 1. Permanent Banned Creator A podcaster with 400,000 subscribers gets deplatformed at 11 PM on a Tuesday. YouTube removes the channel without notice. Spotify follows within 48 hours because they are using a third-party content moderation service that acts on YouTube signals. The creator's livelihood — years of content, their audience's bookmark, the URL they printed on merchandise — evaporates. This happens constantly. It is the defining vulnerability of building an audience on platforms you do not own. The Web0 path: the creator registered `theirshow.null` before any of this happened. Their episode archive — audio, transcripts, show notes — was uploaded to Arweave via Turbo, bundled into a path manifest. The manifest transaction ID was written into the `.null` PDA via `UpdateContent` (instruction `0x03`) on the `null_registrar` program at `H4wbFJucY9shJt95N8Bra532Z4nnkKhGEfqWvLcYfuDm`. The moment the upload confirmed, the content became immutable. Not backed up. Not mirrored. Immutable. Arweave's endowment model means the files are stored permanently for an upfront one-time fee — no subscription, no renewal, no company to call. To deplatform this creator now, an attacker has to simultaneously convince Solana's validator set to reverse a confirmed transaction — which would require taking over the network — and convince Arweave's mining pool to unpublish content from a system designed specifically to reject deletion. Neither is practical. The audience types `theirshow.null` in a browser with the Web0 Chrome extension installed (or goes through the extension's resolver page directly). The extension derives the PDA from the name, fetches the `arweave_txid` field at byte offset 97 of the 314-byte NullDomain account, and routes to `https://arweave.net/`. The content loads. No platform made a decision. No CDN decided whether to serve it. What is live: the `null_registrar` program is on Solana mainnet. `parad0x.null` already resolves through this exact mechanism — a real `.null` name pointing to Arweave content. The Chrome extension intercepts `.null` navigation and handles both direct URL entry and Google search redirect. Upload tooling via `@ardrive/turbo-sdk` works today. The registration fee is off during the current pilot — registration costs only Solana rent (\~0.002 SOL); the fee is config-set (SOL or NULL) and flips on when we go live. Updating content after registration is live and costs no additional fee beyond the transaction. *** ## 2. Autonomous Agent That Pays Its Own Bills Most "autonomous agents" have a human with a credit card somewhere in the loop. The agent calls an API, the API charges the company's billing account, someone reviews the invoice at the end of the month. The agent is autonomous in name only — every dollar it spends traces to a human approval event, and the whole chain collapses if that human stops paying. The architecture for actual autonomy: an agent registered as `worker-7.null` on Solana holds its own keypair. It has an `x402_endpoint` in its PDA — any other agent or service knows how to call it and how to pay it. It has a Dark Passport commitment in the `passport_hash` field — a Groth16 ZK proof summarizing its track record, generated from its own NULLA mesh history, stored on-chain at byte offset 257. When it completes inference tasks in the NULLA mesh, the `CreditLedger` in `core/mesh/credit_ledger.py` records `earn` entries with SHA-256 proof hashes. Those credits convert to USDC via the x402 settlement rail. The agent's `x402Fetch` wrapper (with a hard `maxSpendPerCall` and `maxSpendPerHour` cap) pays for data it needs, services it calls, compute it rents — all without a human signing any transaction. The critical part is the spend cap enforcement. No existing Solana x402 implementation does this. AgentPay MCP and Harvey Budget have spend caps, but both are EVM/Base only. The `x402-pay` client in this stack enforces caps locally before the payment transaction is signed — it checks the running hourly spend total against the configured limit and refuses to sign if the limit would be breached. This is not advisory. The transaction does not get submitted. The agent controls its own risk without an external guardian. It earns in one part of the mesh, spends on the services it needs, and the only human touchpoint is the initial keypair setup and the initial collateral deposit. What is live: the NULLA mesh task router, credit ledger, and proof-of-work system are running. `.null` PDA registration and `x402_endpoint` storage are live on mainnet. The `passport_hash` slot exists in every PDA at offset 257 and is initialized — ZK circuit development and on-chain verifier integration are in progress, gated on SIMD-0302 (native BN254 curve operations on Solana). The `x402-pay` and `x402-gate` packages are in development; the underlying `@x402/svm` and `@x402/express` packages from x402-foundation are at v2.3.0 production-grade. Credit-to-USDC settlement wiring is the current build target. *** ## 3. GPU Arbitrage An RTX 4090 owner is currently losing money. They pay for the GPU and the electricity. They get paid by Vast.ai, which takes a platform cut and sets the price. They get paid by RunPod, which takes a different cut and sets a different price. There is no auction. There is no market. The platform decides what the compute is worth and the node operator accepts it. This is not arbitrage. This is sharecropping. The NULLA mesh operates differently. When a requester broadcasts a `TASK_OFFER`, it goes to all known peers. The RTX 4090 node — running `nulla-local`, auto-detected via `nvidia-smi` at \~170 tokens/second — submits a signed `TaskBid` that includes `model_name`, `estimated_tokens`, `credits_requested` in NULL units, and an Ed25519 signature over the bid. The node sets its own price. If the bid wins, credits are escrowed via `CreditLedger.spend()` before work starts. The node executes inference, submits the result, and `submit_result()` in `core/mesh/task_router.py` computes `SHA-256(task_id + result_text + node_id)` as proof hash, anchors it to Solana via SPL Memo, and records `CreditLedger.earn()`. No platform took a percentage of this. The transaction was between the requester and the node. The proof is on-chain. At scale, this creates real price discovery. A node with an RTX 4090 competing against CPU-only nodes at \~12 tokens/second will win jobs where speed matters and lose jobs where price matters — that is how a market is supposed to work. The mesh router picks the cheapest valid bid, not the fastest, not the node the platform prefers. If a node consistently delivers faster, it will set higher prices and still win bids because the requester values throughput. The receipts from every completed job feed into the credit ledger and eventually into the Dark Passport proof — the more work the node completes without disputes, the stronger its reputation commitment becomes, which can unlock higher-value jobs that require minimum reputation thresholds in `x402-gate` configuration. What is live: the task router, bid auction, credit escrow, and proof-of-work anchoring are running in `nulla-local`. Hardware detection via `nvidia-smi`, `psutil`, and platform detection is live. Rental market broadcasting to the full mesh is in development — currently, peer discovery is local only. The x402 cash settlement wire (converting NULL credits to USDC for withdrawal) is the current build target. NULL as a payment token in x402 is V2; V1 settles in USDC. *** ## 4. Pay-Per-Alpha API A quant has a signal. It is not a strategy — it is a raw predictor. Edge decays if it is widely distributed, so the quant cannot post it publicly and cannot give it away. They want money per call, not a subscription, not an annual contract. Every existing distribution path requires either trusting a platform with the signal or building their own billing infrastructure. Neither is acceptable. The setup: register `alphasource.null`. Set the `x402_endpoint` field in the PDA to the API server URL via `UpdateEndpoint` (instruction `0x06`). Configure `x402-gate` middleware on the server with a per-call USDC price — for example, `amount: 0.50` per inference call. Any agent or human that calls `https://alphasource.null/api/signal` receives an HTTP 402 with `X-Payment-Details`. They pay on-chain via Solana USDC SPL transfer. The facilitator cosigns a receipt binding the payment to the specific request hash. The server verifies the receipt, processes the call, returns the signal. The receipt is written to the receipt-DAG as an immutable record: `receipt_id -> task_id -> payment_tx -> on-chain anchor`. The receipt is the proof. Not a log entry in a database the quant controls. Not a platform usage report that could be altered. An SPL Memo transaction on Solana — visible to any auditor, immutable, timestamped. If a client disputes that they received alpha on a specific call, the auditor walks the receipt-DAG backward from the on-chain anchor: payment happened, request was made, signal was returned. No oracle decided this. No support ticket required. The receipt-DAG is the settlement layer. Agents can call this endpoint autonomously, paying per call out of their own USDC balance, with receipts feeding their own credit history. A trading agent that consistently pays for accurate signals accumulates a receipt history that demonstrates it operates with discipline — that history strengthens its Dark Passport commitment. What is live: the `x402_endpoint` field is live in every PDA and can be set via `UpdateEndpoint` today. The x402 protocol is at v2.3.0 on x402-foundation with \~165M cumulative transactions and \~$50M volume as of April 2026. The `x402-gate` middleware wrapping `@x402/express` is in development; the underlying packages are production-grade. Receipt-DAG data structure linking x402 receipt ID to task\_id to WorkProof to SPL Memo is the next build target — the credit ledger stores proof hashes today but does not yet link them to x402 receipt IDs. *** ## 5. Agent-to-Agent Subcontracting A complex task arrives at `orchestrator.null`: analyze a large dataset, generate a report, translate it into three languages, and produce an audio summary. No single model or single node does this efficiently. The orchestrator agent needs to subcontract. In every current agentic framework, subcontracting means the human operator controls the billing account for all subagents. The orchestrator coordinates but a human is paying everyone's bills. The Web0 version: `orchestrator.null` receives payment via x402 for the full task. It then calls `analyst.null`, `translator.null`, and `narrator.null` — each with their own `.null` PDAs, `x402_endpoints`, and Dark Passport reputation commitments. The orchestrator's `x402Fetch` wrapper pays each subagent per call from the USDC it received for the master task. Each payment generates a receipt. Each receipt is added to the receipt-DAG. The orchestrator's `CreditLedger` records `spend` entries for each subcontract. The subagents' ledgers record `earn` entries. Every completed subcontract anchors a proof to Solana via SPL Memo. When the full job is done, the orchestrator's receipt-DAG entry references the original task payment and all downstream subcontract receipts — a complete audit trail of who did what and what it cost. No human touched this after the initial call. The reputation effects compound in both directions: the orchestrator's Dark Passport commitment strengthens every time it successfully coordinates a complex multi-agent job. The subagents' commitments strengthen every time they complete work without disputes. A calling agent can inspect `analyst.null`'s `passport_hash`, verify the Groth16 commitment against a minimum threshold — "this agent has completed >500 analysis tasks with <1% dispute rate" — before routing any work to it. Bad actors in the mesh are self-defeating: a sybil node that wins bids and then delivers garbage accumulates dispute events that weaken its passport commitment, making it progressively less competitive for high-value jobs that require reputation gating. What is live: the NULLA mesh task routing and credit ledger are live. The `.null` PDA x402\_endpoint and passport\_hash fields exist on mainnet today. The Dark Passport ZK circuits are in development; the passport\_hash slot is in every PDA and initialized to zero pending on-chain verifier deployment. The receipt-DAG linking x402 receipts across multi-hop agent transactions is the next build target. Full autonomous agent-to-agent settlement without human involvement requires the x402-pay to x402-gate wire and credit-to-USDC settlement, currently in development. *** ## 6. Sybil-Proof Reputation Every reputation system built on stake or tokens fails the same way: buy enough tokens, create 1,000 wallets, and your sybil ring has 1,000 units of reputation. The cost is proportional to the token price, which is manipulable. This is why governance attacks work. This is why wash trading inflates DeFi volume. Stake-weighted reputation is not sybil-proof — it is sybil-expensive, and expensive enough to attack at scale if the target is valuable enough. The NULLA proof-of-work challenge-response system flips this. The issuer generates a random 32-byte nonce and publishes only the `challenge_hash` — not the nonce. The worker must commit a `challenge_response = SHA-256(nonce + result_bytes)` in the `WorkProof`. The issuer then reveals the nonce; the verifier checks whether the response is valid. This means there is no shortcut. You cannot precompute the response because you do not know the nonce until after you have committed. You cannot fake the result because the response binds to the actual computation output. The only way to accumulate reputation is to do real work, repeatedly, for real requesters who are paying for it. A sybil attack on this system means running 1,000 nodes that each complete real inference tasks. The attacker pays electricity costs for 1,000 nodes doing real GPU compute. The mesh receives 1,000x the compute capacity it would otherwise have. The "attack" is indistinguishable from growth — the attacker is literally providing the service the network needs, and getting paid for it. Sybil resistance via proof-of-work does not prevent sybils. It makes sybils economically equivalent to legitimate participants. The attack surface disappears because the attack becomes the product. The Dark Passport Groth16 commitment then aggregates this work history into a proof that can be verified without revealing which specific jobs were completed, which clients paid, or what the actual earnings were — the commitment proves the track record, the on-chain anchors prove the work, and the ZK proof keeps the details private. What is live: the two-phase challenge-response proof-of-work system is running in `core/credits/proof_of_work.py`. Proofs anchor to Solana via SPL Memo when a keypair is configured. The ZK aggregation step — compiling the full work history into a Groth16 commitment stored in the `passport_hash` PDA field — is in development. The `passport_hash` slot is live and initialized in every PDA. On-chain verifier deployment for the Groth16 proof is gated on SIMD-0302 reaching Solana mainnet. *** ## 7. Censorship-Resistant Storefront An independent hardware store sells products that some platforms do not want sold — legal products, but inconvenient ones. They have been removed from Shopify twice. Their payment processor dropped them once. Their domain registrar threatened non-renewal. Every layer of their business infrastructure is a potential choke point, and they have learned this the hard way. The Web0 storefront: register `thestore.null`. Build the store as a static site — product listings, cart, checkout. Upload the build folder to Arweave via `@ardrive/turbo-sdk`, getting a manifest transaction ID back. Write that ID into the PDA with `UpdateContent`. Set an `x402_endpoint` pointing to the checkout server. The product catalog and all static content now live permanently on Arweave — no hosting bill, no CDN contract, no platform that can remove the files. The checkout flow handles payments via x402: the customer's agent or browser pays USDC on Solana, the receipt is verified, the order is processed. The store's USDC receipts feed a Dark Passport commitment that serves as its merchant reputation — verifiable proof of transaction volume and dispute history without revealing individual customer data. To shut this store down, an attacker must simultaneously take over the Solana validator network to reverse the PDA registration and the content pointer update, and convince Arweave's mining network — a system specifically designed to make deletion economically irrational — to purge the files. The Solana network processes \~65,000 transactions per second across hundreds of validators. Arweave's endowment model makes storage permanent by design. These are not corporate decisions. They are not support tickets. They are not terms of service violations. They are math. The payment rails run on Solana USDC — no payment processor in the middle, no merchant account to terminate, no chargeback dispute resolution controlled by a third party. The store's reputation accumulates as a Groth16 commitment anchored in its own PDA, portable across any future platform that can read Solana accounts. What is live: `.null` registration, `UpdateContent`, `UpdateEndpoint` are all live on mainnet. Static site hosting via Arweave resolving through a `.null` PDA is live — `parad0x.null` demonstrates this today. The x402 checkout rail is in development; `@x402/svm` and `@x402/express` are production-grade at v2.3.0, and the `x402-gate` middleware wrapper is being built on top. The Merchant Dark Passport use case — ZK commitment over transaction history — requires the on-chain verifier which is gated on SIMD-0302. NULL as a payment token is V2; V1 checkout settles in USDC. --- # 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/web0-how-it-all-connects/scenarios.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.