yNFT Lite Paper

Yield NFTs for Revenue-Sharing Real-World Assets

1. Executive Summary

yNFTs (yield NFTs) redefine what a non-fungible token can do by converting ownership stakes into ongoing income streams. Each yNFT represents a share of revenue generated by a business, and that revenue is delivered directly to holders without manual accounting or bespoke smart-contract engineering. The model is infrastructure-agnostic: any product capable of accepting digital payments can plug into the yNFT framework, stream value to its supporters, and give real-world assets a clear on-chain yield profile. By positioning NFTs as fractional revenue-bearing instruments rather than static collectibles, yNFTs unlock new possibilities for tokenized property, recurring subscriptions, creative royalties, and community-driven projects.

2. Why yNFTs Matter for Real-World Assets (RWAs)

Real-world assets are inherently productive. Buildings collect rent, software subscriptions renew, invoices pay down. Traditional tokenization has focused on ownership, not cash flow. yNFTs change that dynamic.

  • Income instead of speculation: NFT holders receive provable, auditable distributions whenever the underlying business earns revenue. A single card in a deck can now behave like a revenue share.

  • Suitability for regulated industries: The x402 protocol provides webhook gates where compliance, KYC, or reporting checks can be inserted before releasing funds. That means yNFTs can be adapted for domains like property rentals or recurring fintech fees.

  • Simplicity for operators: Businesses do not need to learn smart-contract programming. They issue NFTs through the OASIS API, configure x402 with their treasury wallet, and continue charging customers as usual. The yield mechanics run automatically in the background.

  • Liquidity for investors: Holders may sell their yNFT on secondary markets without waiting for contractual lockups. Yield accrues until the moment of sale; future payments then go to the new owner, preserving fluidity.

3. From Payment to Payout — A Walkthrough

Imagine a customer arriving at a SaaS page - in this instance, our Smart Contract Generator. They log in with a Phantom wallet, select a credit package, and approve a SOL transaction. Here is what happens next:

  1. Payment authorisation The frontend forwards the signed transaction to the .NET backend (ScGen.API). Using QuickNode’s devnet RPC, the API confirms that the payment actually hit the configured treasury address. The amount, payer, and signature are recorded in the credit ledger.

  2. x402 webhook trigger Once verified, the API calls the x402 service with the transaction details: how much SOL was paid, which credit pack was purchased, and which NFT collection should receive yield. This is nothing more than a signed HTTP POST; businesses can insert additional metadata (customer tier, invoice number, etc.).

  3. Holder discovery The x402 backend reads the mint address, calls the OASIS NFT API (or Solana RPC) to fetch every wallet holding at least one of the target NFTs, and compiles an ownership snapshot.

  4. Distribution calculation The service allocates the SOL that just arrived. A platform fee (2.5% in our demo) is siphoned to reserve, an optional treasury amount can be earmarked, and the balance is divided equally among holders. The calculation is logged for transparency.

  5. On-chain payout Using a pre-funded signer wallet (stored in devnet-signer.json during development), x402 submits a Solana transaction distributing the computed SPL amounts. If the signer does not have enough SOL or an RPC error occurs, the system flags the issue and records a mock distribution so UX testing can continue—no silent failures.

  6. Customer experience updates The Smart Contract Generator front-end polls the history endpoints exposed by x402. Within a few seconds, the customer sees a console entry confirming payout, a link to Solscan, the number of recipients, and the exact split. The dashboard also refreshes with the new treasury balance and historical entry.

This flow repeats for every purchase. From the business perspective, nothing changes: they continue collecting payments. From the holder’s perspective, the NFT has become a low-overhead revenue share that “pays rent” whenever the storefront earns money.

4. Creating yNFTs with the OASIS NFT API

The OASIS NFT API is a compact C# service that mints tokens on Solana with metadata tailored for yield. We used it to create the MetaBricks yNFT collection, but the same process applies to any asset class.

  1. Define asset tiers We prepared two classes: Legendary and Regular bricks. Each carries different imagery and can be marked as active or inactive for distribution. Real-world analogues might include flagship rentals versus secondary properties.

  2. Mint and configure Running dotnet run against the API mints NFTs on devnet and uploads metadata (either to IPFS/Pinata or local static hosting). Each metadata JSON includes x402-related fields such as the target webhook, treasury wallet, and revenue model (equal_split in our case).

  3. Register with x402 The x402 backend automatically ingests these settings into src/storage/x402-config.json. Operators can add new collections manually or via CLI scripts in x402/metabricks-integration/. Each entry determines which treasury wallet receives platform fees and which REST endpoint handles payouts.

  4. Distribute the NFTs After minting, NFTs can be dropped to team members, sold, or airdropped. Whoever holds them will be recognised when cash flow arrives.

The result is a living catalogue of yield-capable NFTs that businesses can distribute through any channel. No protocol changes or smart contract redeployments are required when adding new tiers—just mint more tokens through the API and register them with x402.

5. The x402 Protocol in Practice

x402 is the revenue distribution layer. It handles the complex bookkeeping that most projects hand-roll in scripts or spreadsheets.

  • Webhook-first design Because x402 listens for HTTP webhooks, any existing payment system (Stripe, manual invoices, marketplace sales) can be wired in. The only requirement is to send the amount, mint address, and a reference to the source payment. In our integration, the Smart Contract Generator backend handles this automatically after verifying SOL transactions.

  • Holder discovery and data accuracy The service queries Solana using QuickNode, but can also call back into the OASIS NFT API for richer metadata or cross-chain discovery. It supports flexible responses—equal splits, custom share tables, even dynamic filters based on metadata (e.g., only NFT holders who completed KYC).

  • Payout reliability Transactions are simulated before being sent. If a signer wallet is short on funds or the RPC endpoint fails, x402 logs the exact failure reason. We introduced a “mock distribution” fallback specifically for hackathon environments where rate limits or cold wallets are common. This ensures demo operators can still showcase the workflow while being transparent about the difference between real and simulated payouts.

  • Persistent history and analytics On completion, the service writes a record to x402-distributions.json, including transaction signatures, total amounts, per-holder allocations, and metadata like credit pack names. These records drive the frontend dashboards and can be consumed by external analytics or compliance systems.

In short, x402 converts a simple webhook into a full payment event: identify holders, calculate splits, distribute funds, and report on the outcome. It is the engine that makes yNFTs reliable rather than aspirational.

6. Smart Contract Generator as the “Business” Layer

To make yNFTs tangible, we needed an application that actually earns revenue. Our upcoming release Smart Contract Generator (ScGen) plays that role. It is a developer-facing product that charges SOL for generating, compiling, and deploying blockchain contracts.

  • Front-end interactions The Next.js UI lists contract templates, exposes a credit balance indicator, and launches Phantom for payments. A MiniConsole surfaces every step of the process: payment detection, distribution polling, confirmations, and fallback warnings if necessary. The console text was crafted to match terminal logs, giving judges confidence in the automation.

  • Backend responsibilities The .NET API validates wallets, issues credits, stores pricing, and triggers x402. We patched X402PaymentService.cs to account for changes in Solana RPC responses (string vs object account keys). We also added DefaultNftMintAddress support so payments without an explicit mint still route to the correct collection.

  • Treasury dashboards The x402-dashboard page and TreasuryActivityFeed component present the yield story visually: current balance of the treasury wallet, last payout time, total distributed amount, and detailed history. To avoid devnet RPC rate limits, we reduced on-chain polling and rely on the x402 API for most data, only checking the balance directly every minute.

This arrangement makes the product self-explanatory: customers pay to unlock features, and the community of NFT holders sees the benefit almost immediately.

7. Treasury Operations and Distribution Feedback

Transparency builds trust. Our architecture emphasises real-time visibility coupled with safety nets.

  • Treasury updates The treasury wallet receives the platform fee slice, visible moments after every payment. For demos, we host the wallet address in the UI so observers can verify on Solscan.

  • Distribution insights Each payout entry shows total SOL, platform fee, treasury allocation, per-holder amount, and the Solana signature. If the system had to switch to mock mode, the console explicitly states it. Otherwise, it celebrates the confirmed signature so demo operators can show the exact link.

  • Resilience During development we encountered RPC rate limits and signer wallets that ran out of funds. We hardened the stack by adding exponential retries, poll-based history fetching, and visible warnings. The fallback logic ensures that even in a constrained hackathon environment, our story stays cohesive—payouts either succeed with full detail or show precisely why they did not.

8. MetaBricks yNFT Case Study

MetaBricks supplies the creative concept. It is a gamified NFT storefront built around a 24×18 “brick wall” of 432 tokens. Every brick purchase removes a tile from the wall, reveals its rarity (Regular, Industrial, or Legendary), and unlocks guaranteed and surprise perks across the OASIS ecosystem—physical keychains, API tiers, virtual land, AR activations, and more. Converting this collection into yNFTs gave us a concrete testbed for yield: the same customers who buy bricks for perks now receive a share of ongoing revenue generated by the associated services.

  • Legendary Brick The flagship NFT. Its artwork is bundled locally (metabrick-legendary.png) to avoid IPFS throttling, and it remains the default mint for distributions (8b7jJB3QsyR1z7odturFSXR33g7FcWpyCTKjpXcfbNTb). In the demo, the sole holder of this brick receives the full per-holder distribution.

  • Regular Brick A secondary tier used to illustrate how multiple NFT classes can coexist. We renamed it “Metabrick yNFT Regular Yield (not active)” and pointed its image at metabrick-regular.png. The dashboard shows it for clarity, but it is marked inactive to prevent confusion about yield recipients.

  • Treasury and signer The treasury wallet (3BTEJ9uAND…) accumulates platform fees. The signer keypair (stored locally as devnet-signer.json) executes payouts; we documented the need to fund it with enough SOL before demos.

  • Customer outcome When a 1 SOL credit pack sells, the holder sees 0.975 SOL appear in their wallet within seconds, the treasury sees 0.025 SOL, and the console chronicles every step—payment recognised, holders found, distribution confirmed.

MetaBricks demonstrates how brand equity, technical tooling, and x402 distribution combine to make NFTs financially meaningful.

9. Implementation References (Without the Jargon)

For developers or auditors wanting to follow along, here are the key files by plain-language purpose:

  • Where configuration lives: contract-generator/api/.../appsettings.json — holds RPC URLs and placeholders for secrets; must be populated before production deployment.

  • How payments trigger yield: X402PaymentService.cs — verifies Solana transactions and calls the x402 webhook. CreditsService.cs — records credits after successful payouts.

  • How the front-end communicates the story: payment-modal.tsx, credits-purchase-modal.tsx, mini-console.tsx, treasury-activity-feed.tsx. These components guide the user through payment and display live distribution logs.

  • How x402 moves money: x402/backend-service/src/X402Service.js and src/distributor/X402PaymentDistributor.js perform holder lookups, compute shares, and send SOL. x402/backend-service/src/storage/x402-distributions.json keeps an audit trail of payouts.

  • How NFTs are minted: metabricks-nft-api/Services/NFTMintingService.cs and the scripts in x402/metabricks-integration/ handle minting, metadata upload, and collection registration.

  • Documentation to dig deeper: x402/x402_hackathon_pitch.md, x402/X402_SCGEN_END_TO_END.md, contract-generator/QUICKSTART_SERVICES.md.

10. Compliance, Testing, and Roadmap

  • Compliance-ready design: Because x402 uses webhooks, businesses can interpose KYC checks, rate limits, or tax calculations before invoking payout transfers. The architecture supports storing additional metadata per distribution for audit trails.

  • Testing approach: We manually exercised payments, rate-limit scenarios, and signer balance failures. The roadmap includes unit tests for payment verification and more robust integration tests for the x402 distribution pipeline. We already provide scripts (TESTING_INSTRUCTIONS.md) to reproduce the flow.

  • Next steps:

    1. Expand distribution logic to handle rarity-based splits (already outlined in x402/metabricks-integration/RARITY_BASED_DISTRIBUTION.md).

    2. Offer adapters for other chains (EVM, Move) so businesses can pay in their preferred currency.

    3. Turn the console and dashboards into a polished analytics suite with multi-collection support.

    4. Wrap the entire process into a “Create yNFT” wizard so non-technical operators can launch collections in minutes.

11. Conclusion

yNFTs are our answer to a recurring question: “How do we make NFTs do real work?” By linking the OASIS NFT API, the x402 revenue distribution protocol, and the Smart Contract Generator platform, we have shown a complete loop—from customer demand to holder payout—without bespoke smart contract development.

MetaBricks yNFTs validate the idea. The same toolkit can power tokenized property management, subscription revenue sharing, music royalties, or loyalty programs. Businesses keep their familiar workflows, communities receive real economic upside, and regulators gain transparent, auditable records.

PreviousOASIS White Paper (Nov 2024)NextYC Startup Ideas Response

Last updated