Digital Assets, Tokenization, and NFTs

Section VII: Ethereum Framework

Army Cyber Institute

April 9, 2026

Digital Assets, Tokenization, and NFTs

• Digital assets are items of value or rights expressed in digital form.
  • Some exist within centralized platforms (game items, licenses, domain names).
    
  • Today’s focus is on assets cryptographically controlled on blockchains.
    
• Tokenization represents digital or real-world claims as on-chain tokens.

Overall Slide Concept This opening slide establishes the broad landscape of digital assets before narrowing to blockchain-enforced tokens and NFTs. It matters here because students need to distinguish generic digital goods from cryptographically controlled on-chain claims. Emphasize that tokenization is about who enforces ownership and transfer rules.

Key Points - Digital assets include many kinds of value-bearing data, but this lesson focuses on blockchain-controlled forms. - Tokenization maps a right, claim, or representation into an on-chain object with programmable behavior. - Define fungible briefly as interchangeable and non-fungible as uniquely identified rather than interchangeable.

Walkthrough None

Sources - [1] - [2] - [3]

A Taxonomy of Digital Assets

• Native coins (e.g., ETH): secure the chain; pay for computation and data.

• Fungible tokens (ERC‑20 class): interchangeable units (stablecoins, governance).

• Non‑fungible tokens (ERC‑721/1155 class): unique identifiers with metadata.

• Asset‑backed and reference tokens: real-world assets (RWAs), wrapped assets, receipts.

The key distinction is what the token references and who enforces it. Purely on-chain assets are defined by code and consensus. Asset-backed tokens are only as trustworthy as the custodian or legal structure behind them.

Overall Slide Concept This slide establishes a working classification system for the different token types students will encounter. It matters here because later design and risk discussions depend on knowing whether a token is native, fungible, non-fungible, or asset-backed. Emphasize that the asset’s trust model depends on what it references and who stands behind that reference.

Key Points - Native coins, fungible tokens, NFTs, and asset-backed tokens solve different coordination problems. - Standards such as ERC-20, ERC-721, and ERC-1155 make these categories legible to wallets and applications. - Spell out RWA as real-world asset and note that asset-backed tokens depend on off-chain custodians or legal structures.

Walkthrough None

Sources - [3] - [4]

Why Tokenize? Problems and Promises

• The problem: traditional asset systems rely on siloed ledgers, manual settlement, and intermediaries that add cost, delay, and opacity.

• Programmability: assets as APIs, enabling automation and composability.

• Provenance: append‑only ownership history and verifiable scarcity.

• Market access: fractionalization and 24/7 settlement across borders.

• Risks: custody & keys, market manipulation, off‑chain dependencies, regulation.

Overall Slide Concept This slide establishes the engineering case for tokenization by translating popular promises into actual system properties. It matters here because students should learn to separate technical capabilities from hype. Emphasize provenance, programmability, and composability while being explicit about custody, legal, and market risks.

Key Points - Tokenization can improve automation, visibility, and composability when blockchain properties are actually relevant. - Benefits are strongest when open verification or programmable settlement matters more than the added complexity. - Define provenance briefly as a verifiable history of ownership or state changes over time.

Walkthrough None

Sources - [3] - [4]

Tokenization History — Early Experiments

• Colored Coins (2012): proposed tagging Bitcoin outputs to represent non-BTC assets; relied on off-chain agreement to interpret the tags.

• Mastercoin / Omni (2013): layered token issuance on Bitcoin via OP_RETURN; added simple logic but hit script and metadata limits.

• Counterparty (2014): enabled user-defined assets and early collectibles on Bitcoin; demonstrated interest in richer on-chain representations.

• Lesson learned: these projects showed that some builders wanted richer asset primitives, but adoption remained narrow. The friction — limited scripts, inconsistent off-chain indexers, and minimal composability — revealed that the substrate itself needed to support stateful logic natively.

timeline
  2012 : Colored Coins (metadata on Bitcoin outputs)
  2013 : Mastercoin / Omni (token layers on Bitcoin)
  2014 : Counterparty (assets, early collectibles)
  2014 : Namecoin experiments (names/identities)

Overall Slide Concept This historical slide establishes that tokenization predates Ethereum standards and emerged from earlier attempts to represent assets on Bitcoin-like systems. It matters here because students should see NFTs and tokenization as continuations of older design efforts, not sudden inventions. Emphasize that early demand existed, but the substrate was too limited for rich asset logic.

Key Points - Colored Coins, Mastercoin, Omni, and Counterparty showed there was interest in representing non-BTC assets on-chain. - Those experiments depended heavily on off-chain interpretation and lacked the composability later platforms offered. - Define OP_RETURN briefly as a Bitcoin transaction field used to carry small pieces of metadata.

Walkthrough None

Sources - [1] - [5] - [6]

From Experiments to NFTs — A Combined Timeline

timeline
  2017 : CryptoPunks & CryptoKitties popularize NFT scarcity and provenance
  2018-2019 : Marketplaces (OpenSea, SuperRare) and metadata standards mature
  2020-2021 : Fractional.art, NFTfi, Aavegotchi integrate NFTs with DeFi & gaming
  2021-2023 : Beeple's $69M sale, BAYC boom, brand & celebrity adoption; market correction
  2024+ : Utility & identity NFTs (POAPs, Lens, ticketing, loyalty, credentials)

Overall Slide Concept This timeline slide establishes the arc from early token experiments to mainstream NFT attention and then toward utility-oriented use cases. It matters here because students need to understand that NFTs evolved through both technical standards and social adoption cycles. Emphasize that market behavior and infrastructure maturity moved together.

Key Points - NFT history combines protocol and marketplace progress with changing cultural demand. - Later phases shifted from pure collectibles toward finance, gaming, identity, and loyalty use cases. - Define utility NFT briefly as a token whose value depends on access, participation, or functionality rather than only collectibility.

Walkthrough None

Sources https://ethereum.org/en/developers/docs/; https://ethereum.org/en/whitepaper/

Fungible vs Non-Fungible — Design Implications

• Fungible assets: track balances and allowances; code optimizes for arithmetic safety, batch transfers, and spending permissions.
  
• Non-fungible assets: track unique identifiers; design centers on metadata integrity, ownership transfer hooks, and provenance tracking.
  
• Multi-asset contracts: combine both patterns; shared logic with type or ID differentiation for games, marketplaces, and multi-currency systems.
  
• Design priorities diverge: efficiency and allowance safety dominate fungible design; metadata integrity and transfer correctness dominate NFT design.

Overall Slide Concept This slide establishes that fungibility is not just a classification label; it changes accounting, interface design, and user expectations. It matters here because token standards are built around those assumptions. Emphasize how interchangeable units and unique items lead to different transfer, pricing, and metadata models.

Key Points - Fungible assets are tracked as balances, while non-fungible assets are tracked as unique identifiers with distinct metadata or rights. - Design decisions about divisibility, rarity, and identity flow directly from whether the asset should be interchangeable. - Define divisibility briefly as whether a unit can be split into smaller equivalent parts.

Walkthrough None

Sources - [7] - [8] - [9]

NFTs: What Are We Actually Buying?

• Token ownership ≠ intellectual property ownership by default.

• Token points to metadata which may reference media (image, model, etc.).

• Rights live in licenses/terms; on‑chain standards rarely encode legal rights.

  • Owning Real World Assets (RWA) NFTs does not grant ownership of real-world items without a separate, legally recognized agreement.

• Good practice: clear licensing combined with content hashes to anchor files.

• Example: Bored Ape Yacht Club granted commercial rights to holders via an explicit license, while many other projects granted nothing at all. When Yuga Labs acquired CryptoPunks, one of the first actions was to grant IP rights that the original project never provided — illustrating how token ownership alone was insufficient.

Overall Slide Concept This slide establishes the core caution around NFTs: token ownership is not automatically the same thing as owning media, copyright, or broad commercial rights. It matters here because many user misunderstandings and project failures come from that confusion. Emphasize the distinction between on-chain ownership of a token and off-chain legal or platform rights.

Key Points - Buying an NFT usually means acquiring control of a token, not automatically acquiring copyright or unrestricted usage rights. - The practical meaning of the asset depends on linked metadata, license terms, and surrounding platform norms. - Define license briefly as the explicit grant of permissions governing how the associated content may be used.

Walkthrough None

Sources - [8] - [7] - [6]

Metadata and Storage Models

• On-chain storage: metadata or media bytes are written directly into the smart contract’s state.
  • Immutable and permanent as long as the chain exists.
    
  • Gas costs make this practical only for small files or manifests.
• Off-chain, content-addressed storage (IPFS, Arweave): files stored outside the blockchain but addressed by their hash rather than a fixed location.
  • The hash acts as a fingerprint: if the file changes, the address changes.
    
  • Tamper-evident and verifiable, but requires someone to “pin” or pay for long-term availability.
• Off-chain, location-addressed storage (traditional web servers / HTTPS URLs): data retrieved from a specific domain and path like https://example.com/file.json.
  • Cheap and flexible but mutable — the host can change or remove the file without detection.
    
  • Depends entirely on the operator’s honesty and infrastructure.

Overall Slide Concept This slide establishes that the trustworthiness of an NFT often depends as much on metadata and storage choices as on the token contract itself. It matters here because on-chain ownership can still point to mutable, missing, or misleading off-chain content. Emphasize the difference between the token record and the media or metadata it references.

Key Points - Metadata may live on-chain, in IPFS, in Arweave, or behind conventional URLs, and each choice changes integrity assumptions. - Content-addressed storage improves confidence because the reference is tied to the data’s hash rather than just a location. - Spell out IPFS as InterPlanetary File System and explain content addressing as referencing data by its hash.

Walkthrough None

Sources - [10] - [11] - [6]

Royalties, Economics, and Marketplace Realities

• Royalties are signals, not rules. Standards like EIP-2981 let creators publish a preferred royalty percentage on-chain, but marketplaces choose whether to honor it. Some pay creators on every resale; others bypass royalties to attract traders with lower fees.

• Primary vs secondary markets work differently. Primary sales (mints) are event-driven — allowlists, fixed prices, or auctions set initial distribution. Secondary markets discover ongoing demand through open trading, but liquidity is never guaranteed.

• Wash trading distorts signals. A wallet buying from itself inflates volume and price history. Thin markets mean a few large orders can swing prices dramatically. Provenance proves history, not value — a long chain of sales does not imply healthy demand.

Overall Slide Concept This slide establishes that creator royalties and secondary-market economics depend on incentives and marketplace behavior, not just token standards. It matters here because students should not assume that a metadata field or interface standard guarantees payment. Emphasize the gap between signaling a preference and enforcing it across markets.

Key Points - Royalty standards can communicate intent, but marketplaces decide whether and how to honor them. - NFT economics are shaped by liquidity, attention, fees, and coordination among platforms and users. - Define secondary market briefly as trading that happens after the initial mint or sale.

Walkthrough None

Sources - [8] - [11] - [7]

Minting and Market Design Patterns

• Allowlists and phases: staged mint windows that control who can mint and when; used to shape demand and reward early community members.
  
• Auctions: Different methods of offering NFTs
  • English: ascending bids until highest bidder wins.
    
  • Dutch: price starts high and falls until enough buyers commit.
    
  • Batch: many bids collected, one clearing price for all winners.
    
• Reveals and fairness: if token traits are visible before or during minting, insiders can selectively mint rare items. Commit–reveal schemes (hash a secret at mint, reveal later) and verifiable random functions (VRFs) ensure trait assignment is both fair and auditable after the fact.

Overall Slide Concept This slide establishes that NFT project outcomes are heavily shaped by mint mechanics and market design choices before a community even forms. It matters here because launches can create fairness, congestion, or manipulation problems depending on the chosen pattern. Emphasize that mint design is both a product and a security decision.

Key Points - Allowlists, auctions, fixed-price drops, and staged sales each manage distribution and congestion differently. - Poor mint design can amplify bots, gas wars, or unfair allocation. - Define allowlist briefly as a preapproved set of addresses allowed to participate under special rules.

Walkthrough None

Sources - [4] - [3]

Real‑World Assets (RWAs) and Tokenization

• Reference tokens for fiat, commodities, or securities rely on off‑chain enforcement.

• Custody, auditing, and legal agreements determine safety—not just code.

• Benefits: fractionalization, 24/7 settlement, programmable compliance.

• Risks: jurisdictional complexity, oracle/data integrity, redemption gates.

• Examples in practice: Ondo Finance tokenized U.S. Treasuries (OUSG) to offer on-chain yield exposure backed by BlackRock funds. Paxos issues PAXG, a gold-backed token where each token represents one troy ounce held in London vaults. Centrifuge tokenizes real-world invoices and loans as collateral for on-chain lending pools. In each case, the token’s trustworthiness depends on the custodian and legal structure, not just the smart contract.

Overall Slide Concept This slide establishes the special complexity of tokenizing real-world assets because the token’s meaning depends on off-chain institutions as well as code. It matters here because students need to understand that RWAs are not purely technical objects. Emphasize the gap between on-chain transfer and legally recognized ownership or redemption.

Key Points - RWA tokens often represent claims on assets that still depend on custodians, registries, or legal contracts. - Technical transparency can help, but it does not replace off-chain enforcement and compliance requirements. - Spell out RWA as real-world asset and define redemption briefly as the process of exchanging the token for the underlying claim or asset.

Walkthrough None

Sources - [4] - [3]

Enterprise Tokenization and Permissioned Ledgers

• Permissioned ledgers (e.g., Hyperledger Fabric, Corda): known participants, authenticated identities, governed access.
  
• Assets as chaincode: unique tokens represent equipment, documents, or credentials within controlled networks.
  
• Use cases: provenance tracking, maintenance records, certification, or supply-chain assurance.
  
• Pros: high throughput, privacy channels, auditability, clear governance.
  
• Cons: limited openness; trust rests on consortium operations rather than public consensus.

Overall Slide Concept This slide establishes that tokenization also exists in permissioned and enterprise settings with different trust and governance assumptions. It matters here because students should not equate tokenization only with open public markets. Emphasize that enterprise systems usually prioritize auditability, access control, and workflow integration over permissionless composability.

Key Points - Permissioned tokenization systems often restrict participation while using ledger techniques for provenance and coordination. - The design goal is typically controlled interoperability and auditability rather than open tradability. - Define permissioned briefly as requiring approved participants rather than allowing unrestricted public access.

Walkthrough None

Sources - [12] - [4]

Critiques and Misunderstandings

• Environmental impact: proof-of-work once consumed vast energy; post-Merge proof-of-stake cut usage by >99%, but energy and sustainability questions remain relevant to system design.
  
• Speculation and hype: early markets often priced art and collectibles irrationally, leading to bubbles, scams, and disillusionment.
  
• ‘Right-click save’ critique: copying an image ≠ owning its token; NFTs record provenance, not exclusivity or copyright.
  
• Ownership vs access: tokens reference off-chain media; control of the token does not guarantee control of the file or rights.

Overall Slide Concept This slide establishes the major criticisms around NFTs and tokenization as a mix of valid technical concerns, outdated assumptions, and social confusion. It matters here because students should be able to respond with precision rather than hype or dismissal. Emphasize that careful explanations require separating chain guarantees from surrounding ecosystem behavior.

Key Points - Critiques often focus on environmental cost, speculation, user harm, storage integrity, and unclear rights. - Some concerns have changed over time as Ethereum’s consensus and infrastructure evolved, while others remain active design problems. - Define misconception briefly as a claim that sounds plausible but mixes up protocol facts with marketplace behavior or legal assumptions.

Walkthrough None

Sources - [1] - [2] - [6]

System Architecture — Where Everything Lives

• On‑chain state is canonical for ownership; metadata may be off‑chain.
• Events drive discovery; indexers reflect, not define, truth.
• Wallets sign; contracts enforce; markets render.

Overall Slide Concept This slide establishes the full system map behind tokenized assets, from creator and wallet to contract, metadata, indexers, and marketplace rendering. It matters here because token ownership and user experience are produced by multiple cooperating layers. Emphasize which pieces define truth and which pieces merely present or interpret it.

Key Points - On-chain state is the canonical record of ownership and approvals, while metadata and market interfaces may live elsewhere. - Events and indexers help discovery and rendering but do not replace the underlying contract state as the source of truth. - Define indexer briefly as an off-chain service that reads chain data and organizes it for search, display, or analytics.

Walkthrough 1. Start with the creator deploying the token contract and users signing interactions through wallets. 2. Trace how the contract updates on-chain ownership state and points to metadata or media. 3. End with events feeding indexers and marketplaces that render the asset for human use.

Sources - [2] - [6] - [10]

Common Pitfalls in NFT Projects

• Mutable metadata without disclosure — changing assets after sale erodes buyer trust.

• Centralized hosting with no content hashes — link rot and silent content swaps.

• Over-broad approvals and compromised marketplaces — poorly scoped permissions let attackers drain wallets.

• Ambiguous or missing rights — no license means buyers cannot know what they are permitted to do.

• Verification discipline: always check the contract address and token ID before trusting an NFT. Verify metadata hashes and storage locations (IPFS CID or Arweave TX). Use provenance graphs to spot fakes. Beware spoofed domains, fake collections, and phishing signing prompts.

Overall Slide Concept This slide establishes the recurring project mistakes that erode user trust even when the token contract technically works. It matters here because product, storage, and permission choices often determine whether a collection is safe and credible. Emphasize that many NFT failures come from sloppy assumptions around metadata, approvals, and rights disclosure.

Key Points - Mutable metadata, centralized hosting, excessive approvals, and vague rights are common avoidable risks. - Verification discipline requires checking the actual contract, token ID, and referenced content rather than trusting branding alone. - Define approval briefly as permission granted to another contract or marketplace to transfer assets on a user’s behalf.

Walkthrough None

Sources - [8] - [11] - [12]

Real World Examples

• CryptoPunks (2017): 10,000 algorithmically generated avatars on Ethereum. No explicit IP license at launch — rights were retroactively granted after Yuga Labs’ acquisition. Demonstrates how token ownership alone does not confer rights.

• Starbucks Odyssey (2022–2024): loyalty NFTs on Polygon granting members access to exclusive experiences. Showed enterprise interest in utility-based tokens, but was discontinued — illustrating that even well-resourced projects can fail to find product-market fit.

• Propy (2017–present): tokenized real estate transactions. The on-chain record represents a legal transfer processed through traditional title and escrow — the blockchain layer adds transparency but does not replace the legal framework.

• U.S. DoD supply-chain pilots: permissioned ledger experiments tracking aircraft parts and maintenance records as unique tokens, prioritizing auditability and provenance over public tradability.

Overall Slide Concept This slide establishes that tokenization and NFTs have produced a variety of outcomes across art, loyalty, real estate, and enterprise tracking. It matters here because students should see both successful patterns and limits in practice. Emphasize that the same token primitives can support very different trust and governance models.

Key Points - Real examples show that tokenization can support collectibles, loyalty programs, property workflows, and controlled provenance systems. - Outcomes depend on product-market fit, legal structure, and clarity about what the token actually represents. - Define case study briefly as an example used to test whether theory holds under real deployment conditions.

Walkthrough None

Sources - [4] - [6]

Looking Forward: Dynamic Assets

• Dynamic NFTs and programmable rights; evolving metadata schemes.

• Royalty signaling standards and market enforcement debates.

• Cross‑chain identity and portability; wallets as identity hubs.

• Data availability advances enable richer on‑chain assets at lower cost.

• Central Bank Digital Currencies (CBDCs): many central banks are exploring or piloting tokenized sovereign currency. CBDCs apply the same tokenization logic — programmable, auditable digital claims — but under centralized issuance and policy control. They represent a major design space where the concepts from this lecture (token standards, metadata, on-chain vs off-chain enforcement) intersect directly with monetary policy and national security.

Overall Slide Concept This slide establishes the next frontier for tokenized assets: tokens that evolve with data, identity, access, or broader policy systems. It matters here because the space is moving beyond static collectibles into more functional and politically significant designs. Emphasize that richer assets also bring richer trust and governance questions.

Key Points - Dynamic metadata, identity-linked tokens, and CBDC-style systems expand what tokenization can represent. - Future designs will depend heavily on standards, data availability, and explicit policy choices. - Spell out CBDC as central bank digital currency and define dynamic asset as one whose displayed state or rights can change over time.

Walkthrough None

Sources - [8] - [3] - [6]

Key Takeaways

• Tokenization maps claims to on‑chain objects with programmable control.

• NFTs provide provenance and uniqueness; rights depend on explicit licenses.

• Storage choices (on‑chain/IPFS/HTTP) determine integrity and trust.

• Standards enable composability; design discipline prevents common harms.

Overall Slide Concept This summary slide establishes the durable framework students should retain for evaluating digital assets and NFTs. It matters here because later implementation work will be much easier if students already separate on-chain guarantees from off-chain promises. Emphasize tokenization as a programmable claim whose trustworthiness depends on storage, standards, and surrounding institutions.

Key Points - Tokenization encodes claims on-chain, but the meaning of those claims depends on what is enforced technically versus socially or legally. - NFTs combine uniqueness and provenance, but storage, approvals, and licensing choices determine how trustworthy the overall system is. - Standards help interoperability, but disciplined design is what prevents user harm.

Walkthrough None

Sources - [3] - [4] - [8]

Microlab: Token Autopsy

Time: 10–15 minutes

1. Setup (2 min): Each pair receives a short description of a fictional token project: its name, what it claims to represent, its metadata storage method, and its approval model.

2. Analysis (5 min): For your project, answer:

   • What does the chain actually guarantee vs what is an off-chain promise?
   • Where is the metadata stored and what are the integrity risks?
   • What approval scope does the marketplace require, and what could go wrong?

3. Prescription (3 min): Write one concrete improvement the project should implement before launch.

4. Share-out (3 min): Two pairs present their most important finding. Class identifies common patterns across projects.

Overall Slide Concept This lab slide establishes a structured way for students to audit a token project by separating chain guarantees from off-chain promises and user-risk decisions. It matters here because the lesson’s concepts become more durable when students apply them to a concrete fictional project. Emphasize that the exercise is about identifying assumptions and improving design before launch.

Key Points - Students should inspect what the project truly guarantees on-chain, how metadata is stored, and what approval risks exist. - The goal is to surface one practical improvement that would materially reduce user confusion or harm. - Define autopsy here as a systematic review of design choices, dependencies, and likely failure modes.

Walkthrough None

Sources [8]; [7]; [13]; [3]; [14]; [15]; [16]; [17]; [4]; [18]; [1]; [2]; [9]; [19]; [20]; [21]; [22]; [23]; [24]; [10]; [11]; [25]; [6]

References

[1]

V. Buterin, “Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.” Ethereum.org, 2014. Available: https://ethereum.org/content/whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf

[2]

G. Wood, “Ethereum: A Secure Decentralised Generalised Transaction Ledger, EIP-150 Revision.” 2016. Available: https://ethereum.github.io/yellowpaper/paper.pdf

[3]

G. Wang and M. Nixon, “SoK: Tokenization on blockchain,” in Proceedings of the 14th IEEE/ACM International Conference on Utility and Cloud Computing Companion, Leicester United Kingdom: ACM, Dec. 2021, pp. 1–9. doi: 10.1145/3492323.3495577.

[4]

P. Tierno, “Tokenized Assets,” Congressional Research Service, Washington, D.C., In Focus IF12670.3, Jan. 2025. Accessed: Sep. 12, 2025. [Online]. Available: https://www.congress.gov/crs_external_products/IF/PDF/IF12670/IF12670.3.pdf

[5]

ethereum.org, “Ethereum history.” Accessed: Mar. 27, 2026. [Online]. Available: https://ethereum.org/en/history/

[6]

Ethereum.org, “What are NFTs?” Accessed: Mar. 18, 2026. [Online]. Available: https://ethereum.org/en/nft/

[7]

L. Ante, “The Non-Fungible Token (NFT) Market and Its Relationship with Bitcoin and Ethereum,” FinTech, vol. 1, no. 3, pp. 216–224, Sep. 2022, doi: 10.3390/fintech1030017.

[8]

B. Hammi, S. Zeadally, and A. J. Perez, “Non-fungible tokens: A review,” IEEE Internet of Things Magazine, vol. 6, no. 1, pp. 46–50, Mar. 2023, doi: 10.1109/IOTM.001.2200244.

[9]

F. Vogelsteller and V. Buterin, “EIP-20: Token Standard.” Accessed: Oct. 27, 2025. [Online]. Available: https://eips.ethereum.org/EIPS/eip-20

[10]

IPFS, “IPFS.” Accessed: Mar. 18, 2026. [Online]. Available: https://ipfs.tech

[11]

OpenSea, “OpenSea help center.” Accessed: Mar. 18, 2026. [Online]. Available: https://support.opensea.io

[12]

S. Aramonte, W. Huang, and A. Schrimpf, “DeFi risks and the decentralisation illusion,” BIS Quarterly Review, Dec. 2021, Accessed: Mar. 18, 2026. [Online]. Available: https://www.bis.org/publ/qtrpdf/r_qt2112b.htm

[13]

S. L. Schwarcz, “Next-Generation Securitization: NFTs, Tokenization, and the Monetization of ‘Things’.” Accessed: Oct. 21, 2025. [Online]. Available: https://papers.ssrn.com/abstract=4044101

[14]

F. Regner, A. Schweizer, and N. Urbach, “NFTs in practice – Non-Fungible Tokens as Core Component of a Blockchain-based Event Ticketing Application,” in 40th International Conference on Information Systems, Munich, DE, Dec. 2019. Available: https://www.researchgate.net/publication/336057493_NFTs_in_Practice_-_Non-Fungible_Tokens_as_Core_Component_of_a_Blockchain-based_Event_Ticketing_Application

[15]

J. Scharfman, “Non-fungible token (NFT) fraud, hacks, and controversies,” vol. 2. in Springer books, vol. 2. pp. 307–325, Dec. 2024. doi: 10.1007/978-3-031-60836-0_11.

[16]

T. Sharma, R. Agarwal, and S. K. Shukla, “Understanding Rug Pulls: An In-Depth Behavioral Analysis of Fraudulent NFT Creators.” Accessed: Oct. 17, 2025. [Online]. Available: http://arxiv.org/abs/2304.07598

[17]

W. A. Kaal, “Digital Asset Market Evolution,” J. Corp. L., vol. 46, p. 909, 2020, Accessed: Sep. 12, 2025. [Online]. Available: https://jcl.law.uiowa.edu/sites/jcl.law.uiowa.edu/files/2021-08/Kaal_Final_Web_0.pdf

[18]

M. Dowling, “Fertile LAND: Pricing Non-Fungible Tokens and Virtual Real Estate.” 2022. Available: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4044101

[19]

N. Szabo, “Smart Contracts: Building Blocks for Digital Markets.” 1996. Accessed: Sep. 12, 2025. [Online]. Available: https://www.truevaluemetrics.org/DBpdfs/BlockChain/Nick-Szabo-Smart-Contracts-Building-Blocks-for-Digital-Markets-1996-14591.pdf

[20]

D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain technology overview,” National Institute of Standards and Technology, Gaithersburg, MD, NIST IR 8202, Oct. 2018. doi: 10.6028/NIST.IR.8202.

[21]

K. L. Howard, “Blockchain: Emerging Technology Offers Benefits for Some Applications but Faces Challenges,” United States Government Accountability Office, Washington, DC, Technology Assessment GAO-22-104625, Mar. 2022. Accessed: Oct. 27, 2025. [Online]. Available: https://www.gao.gov/assets/gao-22-104625.pdf

[22]

D. Sun, W. Ma, L. Nie, and Y. Liu, “SoK: A Taxonomic Analysis of DeFi Rug Pulls: Types, Dataset, and Tool Assessment,” Proc. ACM Softw. Eng., vol. 2, pp. 550–572, Jun. 2025, doi: 10.1145/3728900.

[23]

Y. Zhou, J. Sun, F. Ma, Y. Chen, Z. Yan, and Y. Jiang, “Stop Pulling my Rug: Exposing Rug Pull Risks in Crypto Token to Investors,” in Proceedings of the 46th International Conference on Software Engineering: Software Engineering in Practice, Lisbon Portugal: ACM, Apr. 2024, pp. 228–239. doi: 10.1145/3639477.3639722.

[24]

Legal Information Institute, Cornell Law School, “U.S. Code Definition: Digital Asset.” 2024. Available: https://www.law.cornell.edu/definitions/uscode.php?def_id=26-USC-2050229528-298491989

[25]

Chainalysis, “Chainalysis reports.” Accessed: Mar. 18, 2026. [Online]. Available: https://www.chainalysis.com/reports/