Kiosk, receipts, Doofs · 08_nft_strategy/NFT_STRATEGY.md

NFT Strategy on IOTA — Full-Era Research + qalarc Brand Concepts

Research date: 2026-09-06. Verified via live fetches of docs.iota.org, iotaledger.github.io/tips, and iota.org. Anything not confirmed live is tagged [UNVERIFIED].

1. Legacy Era — Stardust UTXO NFTs (2021–2024)

Stardust was IOTA's UTXO-based tokenization protocol (shipped on IOTA mainnet in late 2023, and on Shimmer from 2022). NFTs were first-class ledger outputs, not smart-contract records.

1.1 NFT Outputs (UTXO)

Per TIP-27's practical section and TIP-18/TIP-20 (the Multi-Asset Ledger proposals), each L1 NFT was an NFT Output with: - nftId — unique protocol-assigned identifier (mandatory) - owner — an Address Unlock Condition; the NFT is itself an address that can own funds and other outputs (mandatory) - immutableIssuer — address (can be an alias or NFT address) set at mint; never changes - immutableMetadata — binary blob defined at mint; cannot be changed afterward - sender — address that sent the NFT to current owner - mutableMetadata — binary blob changeable by the last sender

Source: TIP-27 — IOTA NFT Standard IRC27

1.2 Metadata: on-chain vs off-chain

• On-chain: JSON (IRC27) packed into immutableMetadata. Costs more storage deposit (Stardust rents byte-space via TIP-19 deposit return mechanics) but needs no external storage. Deposit is refunded when the output is consumed/destroyed.
• Off-chain: immutableMetadata holds a pointer JSON with type: application/json and a uri using {id} substitution (clients replace {id} with the nftId, no 0x prefix). Typical hosts: IPFS, Arweave, or the creator's web server.

1.3 IRC27 (TIP-27) — the NFT metadata standard

Status Active, created 2022-03-04, authors Adam Eunson (AdamCroply) & Merul Dhiman (coodos). Required keys: standard ("IRC27"), type (MIME type, e.g. image/png), version ("v1.0"), uri, name. Optional/recommended: collectionName, issuerName, description, royalties, attributes (OpenSea-style trait_type/value array; spec says IRC27 "follows the OpenSea metadata standards").

Royalties: a map of bech32 addresses (iota1…/smr1…) to decimal percentages, e.g. "royalties": {"iota1...a": 0.05}. Total must not exceed 1.0 (recommended ≤0.5). Enforcement is social/marketplace-side — the ledger doesn't force payouts.

Collection system: a Collection NFT (an ordinary NFT output whose nftId becomes the collectionId) is the minting root. Member NFTs set immutableIssuer = collectionId. Burning or timelocking the Collection NFT locks/finalizes the collection; transferring it transfers brand control. Discovery via UTXO Indexer API (TIP-26): GET /api/indexer/v1/outputs/nft?issuer={collectionId}.

1.4 IRC30 (TIP-30) — native fungible token metadata (clarification)

IRC30 is not an NFT sync-state standard — it's the JSON metadata schema for native tokens minted via Foundry outputs. Required: standard, name, symbol, decimals; optional: description, url, logoUrl, logo (inline SVG). Stored in the Foundry output's immutable Metadata Feature. Foundries enforce tokenomics: maximum supply and circulating supply are protocol fields; melting reduces circulating supply; the foundry controls mint/melt authority. Source: TIP-30.

1.5 Shimmer (SMR) NFT history

Shimmer got this tokenization framework first (2022), with marketplaces built mostly on Soonaverse (NFT/DAO/space marketplace; later rebranded "Soon" and expanded toward its own L2/rails [UNVERIFIED — soonaverse.com was unreachable and its GitHub org has moved at time of research]) plus smaller IOTA/Shimmer markets and wallet-native transfers. Most Shimmer collections used IRC27 + IPFS.

2. Current Era (2026) — IOTA Rebased, Move Object L1

The network now runs the Rebased protocol (MoveVM, object-centric, docs explicitly adapted from Sui's). Mainnet RPC: https://api.mainnet.iota.cafe, explorer: explorer.iota.org. Sources: Network Overview, Object Model.

2.1 NFTs as Move objects

"Everything is an object and a unique, owned NFT" (iota.org Tokenization page). An NFT is any struct with key (identity via UID) + store (freely transferable) abilities:

public struct DevNetNFT has key, store {
    id: UID,
    name: string::String,
    description: string::String,
    url: Url,
}

(from the official tutorial Create an NFT). No ERC-721-style contract linkage is needed; ownership is object-level. The legacy Stardust types (aliases, NFT outputs, foundries, timelocks) survive as Move models in the stardust package; the migration snapshot converted UTXOs to objects, with complex assets claimable via wallet tools (Stardust Migration).

IRC27 lives on in Move: the SDK exposes 0x107a::irc27::Irc27Metadata "usually nested inside an Nft", with royalties, attributes, and non_standard_fields as VecMap fields (IOTA SDK reference). So the same metadata vocabulary carries over.

2.2 On-chain metadata & dynamic NFTs

• iota.org states Move supports up to 256 KB of on-chain data per ledger entry, and larger needs via dynamic structures (maps/linked lists = dynamic fields).
• Because object fields are mutable in module functions (update_description in the official example), dynamic NFTs are native: fields can evolve (stages, scores, state) while UID stays constant. Kiosk borrow_mut/borrow_val even allows mutating an NFT while it sits listed in a kiosk (except when LISTED).
• Immutability is now by design choice: fields set in init/mint and only exposed through copy getters, or immutable shared objects; Display and CoinMetadata are the canonical immutable-metadata precedents.

2.3 Display standard

Yes — IOTA Object Display exists (docs): an on-chain template engine mapping a type T to key/value templates (name, description, image_url, etc.), created by the type's Publisher. Wallets/explorers render NFTs from Display without custom code. The asset-tokenization reference creates per-type Displays via proxy::new_display.

2.4 Kiosk — native commerce primitive

IOTA has the Sui-style Kiosk, part of framework package 0x2 (docs): - Shared per-user Kiosk + owned KioskOwnerCap; place/lock/list/purchase/borrow; states PLACED/LOCKED/LISTED/LISTED-EXCLUSIVELY; extensions for auctions, rentals, lotteries, collection bids; ItemListed/ItemPurchased events as the marketplace indexing feed; buyer trades are mostly gas-less beyond their own purchase PTB. - TransferPolicy (per type, creator-held via TransferPolicyCap) resolves every trade. Rules confirmed in the asset-tokenization docs: addRoyaltyRule(percentage, min_amount), addFloorPriceRule, addLockRule, addPersonalKioskRule. Royalty enforcement is genuinely on-chain for kiosk trades: the TransferRequest only confirms when policy rules are satisfied, and lock rules keep assets kiosk-bound so policies can't be bypassed by P2P transfer.

2.5 Sponsored transactions — IOTA Gas Station

IOTA Gas Station is a shipped product (iota.org/products/gas-station, operator docs at docs.iota.org/operator/gas-station): a configurable module holding a pool of gas coins tied to a sponsor address, JSON-RPC APIs to reserve/return gas, access control, spend limits, KMS support. Use cases listed: single-dApp sponsorship, paid gas-as-a-service, ecosystem models. This is the mechanism for free (gasless) mints on the Move L1. Account Abstraction also exists in docs (passkeys appear in SDK references).

2.6 Closed-Loop Token standard

For regulated/crediting use cases there's the Closed-Loop Token standard (Coin Manager + token policies with deny lists, required-claims, per-type configs) — relevant to membership/credit designs where compliance matters (docs).

3. EVM Side

• IOTA EVM remains a listed product in 2026 (iota.org nav → Products → EVM). It's the ISC-based EVM L2 anchored to L1, running standard Solidity — so ERC-721 / ERC-1155 via OpenZeppelin work as-is. Standard NFT tooling (Hardhat/Foundry, Ethers-style SDKs) applies. [UNVERIFIED details — EVM docs subdomain unreachable in this session.]
• Move↔EVM bridging: the migration doc states IOTAEVM deposits/withdrawals paused during the Rebased genesis and re-enabled after — i.e., the EVM chain is bridge-anchored to the Move L1. Native L1 assets (coins, and per the migration flow, tokens) can move L1↔EVM; arbitrary object-level NFT bridging (Move object → ERC-721 twin) is not documented as a first-class primitive [UNVERIFIED]. Pragmatic path: mint on one layer, mirror representation on the other, or use the "From Solidity/EVM to Move" guides (ERC-721-like NFT in Move) to consolidate on Move.

4. Marketplaces & Tools (2024 → 2026)

Practical takeaway for 2026: there is no dominant consumer NFT marketplace on IOTA — but Kiosk makes the marketplace a thin index over shared infrastructure, so a brand can ship its own storefront cheaply and still interoperate.

5. CREATIVE SECTION — Six NFT Concepts for the qalarc Family

qalarc.com (AI agency), tradez.au (trading), doof.ing (fun brand); GPU rigs + AI agents; Australian heritage incl. the beloved gumleaf logo. All concepts below target the Move L1 (Rebased) as primary rail unless stated.

(a) "Doofs" — generative PFP collection (doof.ing)

• Standard: Move object NFT with Irc27Metadata + Display for renderer compatibility; Kiosk listing + royalty TransferPolicy (e.g., 5%).
• Metadata: on-chain trait VecMap (species, glow, habitat, didgeridoo-bpm), image on IPFS/Arweave with uri; a few dynamic traits mutate as holders attend "doofs" (events burn streak tokens → borrow_mut updates).
• Mint: Gas Station-sponsored allowlist mints (feeless UX), on-chain randomness for traits; collection locked via burnt mint-cap (echoes Stardust collection-NFT burn ritual).
• Revenue/utility: primary mint + royalties; holder-gated doof.ing events; Doofs double as avatars across the brand's sites.

(b) Compute-Receipt NFTs — proof-of-compute provenance

• Standard: Move object per GPU job (minirig/qalarc rigs). One receipt per job ID; fields: rig ID, model, watt-hours, duration, job hash, output hash.
• Metadata: fully on-chain (tiny JSON, well under 256 KB) so provenance never depends on external hosting — this is the killer differentiator vs ERC-721 + IPFS.
• Mint: automated by the rig's agent via Gas Station (machine wallet); no human gas friction.
• Revenue/utility: audit-grade provenance for client deliverables ("your render/model was computed on verified hardware at X kWh"); resellable as receipts-of-record; feeds an on-chain usage ledger for invoicing.

(c) AI-Art with Signed Provenance

• Standard: Move object; Irc27Metadata with extended attributes: model, model_version, prompt_hash, seed, sig (agent's Ed25519 signature over the image digest; Ed25519 is the chain's native scheme).
• Metadata: image on IPFS/Arweave; provenance fields on-chain; Display template renders "Model vX · seed N · verified signature" badge.
• Mint: PTB does verify_signature → mint → transfer; optionally lock in creator kiosk with royalty rule.
• Revenue/utility: collector-grade AI art with verifiable model/version lineage — anti-"slop" positioning for qalarc's agency work; secondary royalties enforced on kiosk trades.

(d) Membership / Credit-Tier NFTs (qalarc credit platform)

• Standard: two options — public: Move object NFT with tier field + Personal Kiosk rule to discourage uncontrolled resale; regulated: Closed-Loop Token with required claims for KYC'd enterprise tiers.
• Metadata: tier (Leaf/Bark/Canopy — gumleaf heritage naming), credit allowance, expiry; dynamic: credits drawn down mutate the object (state = balance, receipts as dynamic fields).
• Mint: sponsored mint at onboarding (Gas Station); tier upgrades = new field version, not new token.
• Revenue/utility: subscriptions/credits with on-chain auditability; tier-gated API access; discounts on tradez.au signals; transfer policy can cap secondary markup.

(e) Digital Product Passports for real products

• Standard: Move object per physical item (IOTA's RWA sweet spot — Orobo/ObjectID showcases prove the pattern; DPP demo at dpp.demo.iota.org).
• Metadata: immutable identity + materials/origin at mint; mutable service history appended via dynamic fields (repairs, ownership, EUDR/EU-DPP compliance fields); docs/photos via IPFS with on-chain hashes.
• Mint: one per manufactured item by factory agent (Gas Station); end-consumer claims passport by scanning NFC → sponsored first interaction.
• Revenue/utility: compliance product for Australian exporters (EU DPP regulation incoming); recurring "passport service" SaaS; resale-value certification.

(f) Agent Identity Seals

• Standard: Move object bound to each qalarc AI agent (Signal-hub bot, trading agents, rig monitors); Publisher-issued Display shows "verified agent".
• Metadata: agent pubkey (Ed25519), model card hash, operator (qalarc.com), scope of permissions, revocation status — dynamic revocation flag mutated by the master cap when an agent is compromised.
• Mint: minted by qalarc's admin cap; checkers (other contracts) verify seal is_valid() before accepting agent-signed messages on-chain.
• Revenue/utility: trust infrastructure — lets qalarc sell "agent-signed, on-chain-verifiable" actions to clients; the seal is the productized identity layer for every other concept above (signs (b), (c) receipts).

Recommended sequencing: ship (f) seals quietly first as infrastructure (small, high-leverage), then (b) compute-receipts as the public debut — it's cheap, fully on-chain, machine-minted via Gas Station, instantly legible ("GPU jobs → receipts → NFTs"), and it feeds real qalarc revenue rather than speculative art-market dynamics. Ship (a) Doofs when there's an audience to PFP with.

Source Index

• TIP-27 / IRC27: https://iotaledger.github.io/tips/tips/TIP-0027/tip-0027.html
• TIP-30 / IRC30: https://iotaledger.github.io/tips/tips/TIP-0030/tip-0030.html
• Object model: https://docs.iota.org/developer/iota-101/objects/object-model
• Create NFT tutorial: https://docs.iota.org/developer/iota-101/nft/create-nft
• Kiosk: https://docs.iota.org/developer/standards/kiosk · Display: https://docs.iota.org/developer/standards/display
• Asset tokenization (TransferPolicy rules): https://docs.iota.org/developer/advanced/asset-tokenization
• Stardust migration: https://docs.iota.org/developer/stardust/stardust-migration
• Irc27Metadata in Move SDK: https://docs.iota.org/developer/iota-sdk/references/swift/protocols/Irc27MetadataProtocol
• Tokenization product: https://www.iota.org/products/tokenization · Gas Station: https://www.iota.org/products/gas-station
• Networks: https://docs.iota.org/developer/network-overview