Token-Based Communities & NFTs in Practice

Section VII: Ethereum Framework

Army Cyber Institute

April 9, 2026

Agenda

1. Foundations — What is a token? The on-chain primitive, its anatomy, and the fungible vs. non-fungible distinction.

2. Token-Based Communities — How token ownership enforces membership, access, and governance — with real-world case studies.

3. Minting — How tokens are created on-chain, contract patterns, metadata storage, soulbound credentials, and the permissioned contrast.

4. Adversarial & Failure Cases — Rug pull forensics, the Decentralized Autonomous Organization (DAO)s re-entrancy attack, and centralisation chokepoints hiding inside decentralised systems.

5. Operational Implications — Five capabilities this infrastructure enables — and why each one cuts in two directions.

Overall Slide Concept This agenda slide establishes the lesson arc from token primitives to communities, minting, adversarial cases, and analyst-facing implications. It matters here because the lesson combines technical and operational material that benefits from a clear roadmap. Emphasize that the same primitive will be examined as infrastructure, social mechanism, and failure surface.

Key Points - The lesson moves from what tokens are to how communities and institutions use them in practice. - Adversarial cases are not side topics; they are part of understanding how deployed token systems actually behave. - Define DAO briefly as decentralized autonomous organization.

Walkthrough None

Sources [1]; [2]; [3]

What Is a Token?

• A token is a programmable claim enforced by code on a shared ledger — not a coin, not an image.
• Three properties every token carries: unique or fungible ID, verifiable ownership, immutable transfer history.
• The ledger enforces the rules; humans and institutions supply the meaning behind those rules.
• Same primitive, radically different applications: stablecoin, supply chain record, membership pass.

Overall Slide Concept This slide establishes the token as the underlying primitive before any specific use case is discussed. It matters here because the rest of the lesson depends on separating what the ledger enforces from what humans interpret. Emphasize that meaning sits on top of the token; the chain only enforces identifier, ownership, and transfer history.

Key Points - A token is a programmable claim with an identifier, owner, and transfer history enforced on-chain. - The same primitive can support currency, membership, credentials, or supply-chain tracking depending on surrounding rules. - Define programmable claim briefly as a claim whose transfer and state changes are governed by contract logic rather than manual intervention.

Walkthrough None

Sources [1]; [2]; [3]

Fungible vs. Non-Fungible

Standard	Token Type	What the contract tracks	Transfer unit	Typical use
ERC-20	Fungible	Balances per address	Any amount	Governance token, stablecoin, social currency
ERC-721	Non-Fungible	Owner per token ID	One whole token	Art, deed, membership pass, supply chain record
ERC-1155	Multi-token	Balance per (address, ID) pair	Amounts per ID	Gaming inventory, enterprise asset catalogue

• Standards are social and technical contracts — wallets, markets, and indexers all speak them.

• Choosing the wrong standard is an architectural decision — it constrains what the system can ever do.

Overall Slide Concept This slide establishes the mechanical difference between fungible and non-fungible token standards. It matters here because later community, minting, and operational examples depend on what the standard can track. Emphasize that standard choice determines identity, transfer granularity, and downstream integration patterns.

Key Points - ERC-20 tracks balances, ERC-721 tracks unique ownership by token ID, and ERC-1155 supports mixed token types under one contract. - Standards are coordination tools for wallets, marketplaces, and indexers as much as they are code interfaces. - Spell out ERC as Ethereum Request for Comments.

Walkthrough None

Sources [2]; [1]

Token Standard Design Considerations

Overall Slide Concept This slide establishes standard selection as an architectural choice rather than a cosmetic one. It matters here because the token model chosen at design time constrains future wallet support, market behavior, and application logic. Emphasize that a token standard is part of the system’s long-term operating model.

Key Points - Designers should choose standards by asking whether units are interchangeable and whether mixed token types are needed. - Wrong standard choices create downstream friction that is expensive or impossible to undo after deployment. - Define architectural commitment briefly as an early design choice that constrains many later integration options.

Walkthrough 1. Start with the top question: are all units interchangeable? 2. Follow the branch toward ERC-20, ERC-721, or ERC-1155 based on identity and mixed-use needs. 3. End on the warning that standards lock in downstream expectations.

Sources [4]; [2]; [1]

What Tokens Don’t Guarantee

• The chain verifies: signatures, balance changes, contract execution, event logs.

• The chain does not verify: file contents, legal ownership, identity of the wallet holder, or meaning of metadata.

• tokenURI points to a JSON file — that file lives somewhere else, with its own integrity model.

• A token on an immutable chain pointing to a mutable server is only as trustworthy as the server operator.

Overall Slide Concept This slide establishes the central analytical boundary of the lesson: tokens enforce some facts on-chain, but not the full meaning people attach to them. It matters here because many user and analyst errors come from assuming the chain guarantees more than it does. Emphasize the difference between state enforcement and interpretation.

Key Points - The chain guarantees signatures, state transitions, and event logs, but not metadata truth, legal rights, or real-world identity. - tokenURI is only a pointer, so token integrity can still depend on off-chain infrastructure. - Define tokenURI briefly as the metadata pointer a contract returns for a token.

Walkthrough None

Sources [2]; [5]

On-Chain vs. Off-Chain

Overall Slide Concept This diagram slide establishes the visual split between on-chain guarantees and off-chain meaning. It matters here because the rest of the deck keeps returning to this boundary when evaluating communities, credentials, and evidence claims. Emphasize the dashed arrow as the point where trust assumptions re-enter.

Key Points - Ownership, IDs, and transfer history are on-chain; metadata, files, rights, and identity usually are not. - The metadata pointer is the bridge, but it does not make off-chain content consensus-enforced. - Define off-chain briefly as depending on systems or institutions outside the blockchain’s consensus process.

Walkthrough 1. Point to the on-chain cluster and name the specific facts consensus enforces. 2. Point to the off-chain cluster and name the claims the chain does not directly verify. 3. End with the pointer from tokenURI to metadata as the core integrity gap.

Sources [2]; [6]; [5]

Token-Based Communities

• A token-based community enforces membership, access, and/or governance through token ownership.

• Three things token ownership can gate: who gets in, who gets to speak, who gets to decide.

• The chain enforces the gate; humans supply the community, culture, and purpose behind it.

• Key question: what exactly does the token enforce — and what does it merely signal?

Overall Slide Concept This slide establishes token-based communities as systems where ownership controls access, speech, or decision rights. It matters here because the lesson now shifts from primitive definition to social and organizational application. Emphasize that tokens can enforce gates, but not culture or legitimacy by themselves.

Key Points - Token ownership can gate membership, permissions, or governance participation. - Communities still rely on off-chain communication, norms, and moderation even when access is token-gated. - Define token gate briefly as a rule that grants or denies access based on ownership of a specified token.

Walkthrough None

Sources [1]; [7]; [2]

Two-Layer Community Architecture

Overall Slide Concept This slide establishes the two-layer model behind token communities: enforced on-chain mechanisms and social off-chain coordination. It matters here because many claims about decentralization blur those layers together. Emphasize that the chain can enforce treasury or voting logic while still relying on centralized communication or moderation channels.

Key Points - Access control, treasury execution, and formal voting can be enforced on-chain. - Communication, culture, and moderation usually stay in off-chain services or social processes. - Define treasury disbursement briefly as contract-controlled release of funds according to encoded rules.

Walkthrough 1. Identify the on-chain layer that enforces entry, treasury, and governance mechanics. 2. Show the off-chain layer where discussion, moderation, and social cohesion actually occur. 3. End with the arrows connecting them to show that token ownership gates access to social spaces.

Sources [1]; [7]

Three Patterns: DAOs, Membership NFTs, and Social Tokens

• Decentralized Autonomous Organization - DAOs — token-weighted control of a shared treasury and protocol; governance is the core function.

• Membership NFTs — access control; the NFT is a key that unlocks content, events, or community spaces.

• Social tokens — community currency; rewards contribution and aligns incentives around participation.

• These patterns mix freely — most real communities combine elements of all three.

Overall Slide Concept This slide establishes the three major design patterns for token-based communities. It matters here because students should learn to classify these systems by what the token is doing socially and operationally. Emphasize that governance, membership, and social-currency functions create different risk and incentive profiles.

Key Points - DAOs, membership NFTs, and social tokens use the same infrastructure but emphasize different community mechanics. - The most useful analytical question is what power or privilege the token actually controls. - Define social token briefly as a fungible token used to coordinate identity, status, or participation around a community or creator.

Walkthrough None

Sources [1]; [2]; [8]

Token Community Examples

Community	Pattern	Token	What it enforces	Notable feature
Friends With Benefits	Social + DAO	FWB (ERC-20)	Discord membership threshold	Token price creates plutocratic entry barrier
Bored Ape Yacht Club	Membership NFT + DAO	BAYC (ERC-721) + APE (ERC-20)	Event access, IP rights, ApeCoin governance	Layered: NFT = identity; APE = treasury control
Doodles	Membership NFT + DAO	Doodles (ERC-721)	Doodlebank treasury voting	Community launchpad funded $300K+ in grants
Gitcoin	DAO	GTC (ERC-20)	Quadratic funding allocation	Open-source grant funding; sybil resistance required

• Each community answers: what does holding this token actually let you do?

• Each also illustrates a structural tension that token governance alone cannot resolve.

Overall Slide Concept This slide establishes concrete case studies so students can compare token communities that look similar on-chain but operate differently in practice. It matters here because examples reveal the gap between token design and lived community behavior. Emphasize what each example enforces versus what it merely signals socially.

Key Points - Community examples help distinguish governance-driven, access-driven, and brand-driven token ecosystems. - Similar token mechanics can support very different cultures, economic incentives, and abuse patterns. - Define case study briefly as a real example used to test how theory behaves in deployed systems.

Walkthrough None

Sources [1]; [2]; [7]; Friends With Benefits, “Join” (https://www.fwb.help/join); Gitcoin Governance Manual (https://manual.gitcoin.co/); Doodles Digital Collectibles Media License Agreement (https://www.doodles.app/legal/digital-collectibles-licenses/digital-collectibles-media-license-agreement); ApeCoin DAO Governance Working Group materials (https://forum.apecoin.com/)

How Token Gating Works

• Flow: user connects wallet → signs a message (no gas) → contract checks token balance → access granted or denied.

• Implementations: Discord bots (Collab.Land, Guild.xyz), web apps (wallet auth), physical events (FWB Gatekeeper).

• No passwords. No accounts. No central database. Ownership is the credential.

• Analytical split: membership list is public (on-chain); community content is private (off-chain).

Overall Slide Concept This slide establishes the practical mechanics behind token gating so students see it as an authentication pattern rather than just a social label. It matters here because many token communities depend on wallet checks more than on formal governance contracts. Emphasize that ownership verification and session-level access are still distinct steps.

Key Points - Token gating checks wallet-controlled assets before granting access to a forum, app, or service. - The gate verifies ownership, but the protected resource usually still lives in an off-chain platform. - Define wallet authentication briefly as proving control of an address by signing a challenge.

Walkthrough None

Sources [2]; [7]

Token Gating: Access Flow

Overall Slide Concept This diagram slide establishes the flow of a typical token-gated access check from wallet to verifier to service. It matters here because students should be able to reason about where the gate can fail or be bypassed. Emphasize that the token check is only one component in a larger access-control chain.

Key Points - Access flow usually combines wallet signature, on-chain ownership check, and application-side authorization. - Failure or compromise at the verifier or application layer can undermine a correct on-chain check. - Define authorization briefly as the application’s decision to grant access after successful identity or ownership verification.

Walkthrough 1. Start with the user proving wallet control through a signed message. 2. Show the ownership check against the relevant token contract. 3. End with the application granting or denying access based on the result.

Sources [2]; [7]

What Is Minting?

• Minting is a state-writing transaction that produces a new token ID and assigns an initial owner.

• On Ethereum: a function call to a smart contract; the contract emits a Transfer event from address zero.

• The minter controls: who can mint, how many exist, what metadata the token points to.

• After minting: the token enters the standard ownership and transfer lifecycle.

Overall Slide Concept This slide establishes minting as the act of creating new token state on-chain rather than merely listing or revealing an asset. It matters here because token supply, ownership history, and project economics begin at mint time. Emphasize that minting is a contract operation with security and fairness implications.

Key Points - Minting creates or assigns token records according to contract-defined rules. - Supply control, payment rules, and access restrictions during mint shape later market behavior and trust. - Define minting briefly as creating a new token entry or balance on-chain.

Walkthrough None

Sources [4]; [2]

Minting on Ethereum

• Public mint — anyone can call mint(); supply cap is the only control. Risk: bot front-running.

• Allowlist (Merkle proof) — a hash tree commits allowed addresses; callers prove membership without storing the list on-chain.

• Signature-based (lazy) mint — deployer signs a voucher off-chain; buyer submits voucher + payment to mint on demand.

• Royalty signaling (EIP-2981) — contract declares royalty recipient and basis points; marketplace enforcement varies.

Overall Slide Concept This slide establishes what minting looks like in Ethereum specifically: a contract call that writes supply and ownership state, often alongside metadata linkage. It matters here because students should tie abstract minting to concrete EVM-based state changes. Emphasize that mint logic is where distribution policy becomes code.

Key Points - Ethereum minting typically updates ownership or balances, emits events, and may initialize metadata references. - Contract design determines who can mint, under what conditions, and at what cost. - Define minter briefly as the address or role allowed to create new tokens under the contract’s rules.

Walkthrough None

Sources [4]; [2]; [3]

Metadata, IPFS, and the Pointer Problem

• At mint, tokenURI is set — a string pointing to a JSON file containing name, image URL, and traits.

• Content addressing (IPFS CID, Arweave TX ID): address is a hash of the content — change the file, address changes.

• Location addressing (HTTP URL): address is a server location — server operator can change or delete the content silently.

Storage	Address type	Mutable?	Permanent?	Trust model
On-chain	State variable	No	Yes	Chain consensus
IPFS	Content hash (CID)	No (hash changes)	Only if pinned	Pinning network
Arweave	Content hash (TX ID)	No	Paid permanence	Arweave protocol
HTTP URL	Location	Yes	Server-dependent	Server operator

Overall Slide Concept This slide establishes the metadata pointer problem as the core integrity issue behind many NFT misunderstandings. It matters here because minting a token does not automatically make the associated content durable or immutable. Emphasize that storage choice determines whether the pointer is a commitment or just a location.

Key Points - IPFS and similar systems improve integrity by referencing content through hashes rather than mutable URLs. - A token can be permanent while the referenced metadata or media remains mutable, unavailable, or misleading. - Spell out IPFS as InterPlanetary File System and define CID as content identifier.

Walkthrough None

Sources [6]; [2]; [5]

Soulbound Tokens

• A Soulbound Token (SBT) is minted with transfer disabled — bound to one wallet permanently.

• Use cases: identity attestations, academic credentials, membership records, on-chain reputation.

• Two standards: ERC-5192 (locks ERC-721 transfer functions) and ERC-4973 (account-bound; holder can relinquish).

• The open problem: non-transferability binds the credential to a wallet, not a person.

Overall Slide Concept This slide establishes soulbound tokens as a credential-oriented design that deliberately rejects normal transferability. It matters here because identity and reputation uses change both the purpose and the threat model of tokens. Emphasize that non-transferability solves some problems while creating others around privacy, recovery, and coercion.

Key Points - Soulbound tokens are intended to represent credentials, reputation, or attestations rather than tradeable assets. - Preventing transfer changes incentives, but it does not automatically solve identity or legitimacy questions. - Define soulbound briefly as designed to be non-transferable once issued.

Walkthrough None

Sources [9]; [10]

Minting on Hyperledger Fabric

• On Fabric, asset creation is chaincode execution within a consortium — identity is known at the protocol layer.

• Asset = composite key (type:id) + JSON value (owner MSP, metadata hash, URI).

• Endorsement policy defines which organizations must co-sign a mint — governance is explicit.

• Fabric adds: known identities, multi-org sign-off, private data. It removes: permissionlessness, public verifiability.

Overall Slide Concept This slide establishes a permissioned contrast by showing how token-like issuance can work in Hyperledger Fabric. It matters here because students should see that minting patterns exist outside open public networks. Emphasize how membership control and institutional trust reshape the system’s assumptions.

Key Points - Fabric-based minting relies on known organizations, permissioned identities, and chaincode-governed state updates. - The token idea remains, but governance and trust move from open consensus toward consortium control. - Define chaincode briefly as application logic executed by Hyperledger Fabric peers.

Walkthrough None

Sources [1]; [3]

The Frosties Rug Pull

• The same minting primitives that enable open creation also enable rug pulls — projects that launch, collect mint funds, then abandon, sending value to zero.

• Frosties (Jan 2022): 8,888 NFTs sold at 0.04 ETH each — $1.1M raised and drained within hours of sellout. Website deactivated, Discord deleted, Twitter posted “I’m sorry.”

• Operators transferred proceeds through multiple wallets designed to obfuscate the source — but every transfer was publicly recorded on-chain.

• When arrested, the same operators were preparing a second project (“Embers”) expected to raise $1.5M — the wallet reuse was the forensic link.

• Broader pattern: study of 758 rug pulls across 10 marketplaces found wallet reuse is the dominant forensic signal; one cluster attempted 37 rug pulls in three months.

Overall Slide Concept This slide establishes the Frosties case as a real-world failure where token infrastructure was used to extract value and abandon a community. It matters here because rug pulls are one of the clearest examples of how social trust can be abused on top of technically valid token mechanics. Emphasize that on-chain transparency does not prevent bad intent.

Key Points - A rug pull occurs when project operators use user trust and token demand to extract value before disappearing or changing the rules. - The chain records the flows clearly, but that does not automatically protect buyers before the harm occurs. - Define rug pull briefly as a project-driven exit scam or abandonment after collecting user funds or value.

Walkthrough None

Sources [11]; [12]

Rug Pull Operator Wallet Graph

Overall Slide Concept This graph slide establishes how wallet-flow analysis can reveal operator behavior behind a rug pull. It matters here because token systems leave an evidentiary trail even when identities are pseudonymous. Emphasize that graph structure is often the bridge from visible transactions to actionable forensic hypotheses.

Key Points - Wallet graphs help analysts trace fund movement, clustering behavior, and relationships among project-controlled addresses. - Pseudonymity slows attribution, but it does not erase observable flow patterns. - Define wallet graph briefly as a network view of addresses and the transfers between them.

Walkthrough 1. Identify the main operator or treasury node in the graph. 2. Follow the outbound flows to secondary wallets or cash-out points. 3. End by noting what additional attribution data would be needed beyond the graph itself.

Sources [11]; [12]

The DAO Re-Entrancy Attack

• April 2016: Christoph Jentzsch launches The DAO on Ethereum — a decentralized investment fund. $150M raised from 11,000+ investors in history’s largest crowdfund at the time, representing ~14% of all ETH in circulation.

• June 12: Stephan Tual, a DAO creator, announces a “recursive call bug” has been found — but claims “no DAO funds at risk.” Programmers begin working on a fix. Over 50 project proposals are awaiting token-holder votes.

• June 17: An unknown attacker exploits the unfixed flaw. The withdraw() function sent ETH before updating the caller’s balance — the attacker’s contract used its fallback function to re-enter withdraw() recursively. 3.6 million ETH (~$60M) drained into a “child DAO” before anyone could intervene. ETH price crashes from $20+ to under $13 in a day.

• The response: A “white hat” counter-strike group used the same exploit to race the attacker and rescue remaining funds. But the back-and-forth could have continued indefinitely — so the community voted to hard fork on July 20, 2016 (block 192,000), rewriting history to return stolen funds. A minority refused — that chain became Ethereum Classic (ETC), which still runs today.

• The lesson: The cryptography held. The chain worked as designed. The contract code was wrong. And when it mattered most, the community proved that blockchain immutability is a social commitment, not a physical law.

Overall Slide Concept This slide establishes the DAO exploit as the canonical reminder that tokenized governance and treasury systems inherit smart-contract execution risk. It matters here because the lesson is about communities in practice, and the DAO shows how governance, code, and money can fail together. Emphasize that the chain executed the flawed logic faithfully.

Key Points - The DAO attack was caused by a sequencing flaw, not by a cryptographic or consensus failure. - The incident shows that token-governed systems are only as safe as their contract logic and patch discipline. - Define re-entrancy briefly as reentering vulnerable contract logic before earlier execution has completed safely.

Walkthrough None

Sources [13]; [14]; [15]; [10]

Re-Entrancy Drain Loop

FIX — Checks-Effects-Interactions: Set balances[msg.sender] = 0 before sending ETH. Re-entry hits zero balance → reverts. Order of operations is the entire vulnerability.

Overall Slide Concept This diagram slide establishes the recursive loop that made the DAO exploit work. It matters here because seeing the order of operations makes the vulnerability easier to remember than a verbal description alone. Emphasize that the entire attack depends on external control being yielded before balances are updated.

Key Points - The attacker repeatedly reentered before the contract could decrement the recorded balance. - The fix is to update state before sending value outward. - Define checks-effects-interactions briefly as a defensive ordering pattern that updates internal state before external calls.

Walkthrough 1. Start with the initial withdrawal call and the successful balance check. 2. Follow the ETH transfer to the attacker’s fallback and back into withdraw. 3. End with the loop continuing until gas runs out or funds are exhausted.

Sources [13]; [15]

Centralization Chokepoints

• Most users reach Ethereum through Infura or Alchemy — two centralized API providers. When Infura experienced an outage in 2020, dApps failed; the chain did not.

• Bridges are controlled by multisigs far smaller than L1 consensus — the 2023 Multichain collapse proved it.

• Oracles aggregate off-chain data through networks with their own, weaker security assumptions.

• Although Ethereum L1 operates in a decentralized manner, the infrastructure layers many users actually depend on — RPC providers, bridges, and oracles — reintroduce the single points of failure that decentralization was designed to eliminate.

Overall Slide Concept This slide establishes that many real Ethereum users interact first with centralized service layers rather than with decentralized base-layer infrastructure directly. It matters here because system resilience and trust can be undermined at those chokepoints even when Ethereum L1 remains healthy. Emphasize that decentralization claims should be evaluated across the whole dependency stack.

Key Points - RPC providers, bridges, and oracle systems often concentrate power or operational dependency above the base layer. - Failures at those chokepoints can deny access or freeze value without any failure in Ethereum’s consensus itself. - Spell out RPC as remote procedure call and define bridge briefly as infrastructure that represents assets or messages across chains.

Walkthrough None

Sources [16]; [17]; [18]; [19]

Hidden Infrastructure Growth

• NFT secondary market volume fell ~37% year-over-year by late 2025 — the speculative layer collapsed.

• Simultaneously: over 40% of Fortune 500 companies integrated token infrastructure for operations.

• Institutional use cases: Digital Product Passports (EU mandate), supply chain traceability, tokenized loyalty, fractional real estate.

• The speculative layer and the utility layer have decoupled — most analysts are watching the wrong one.

Overall Slide Concept This slide establishes the structural decoupling between speculative NFT trading and quieter institutional token infrastructure growth. It matters here because many analysts overfocus on visible market bubbles while missing less glamorous operational adoption. Emphasize that the primitive can decline in one sector while growing in another.

Key Points - Secondary-market collapse does not imply token infrastructure has stopped expanding in utility-oriented environments. - Analysts should track operational deployments such as provenance, loyalty, and product-passport systems separately from speculative volumes. - Define decoupling briefly as two related trends moving independently instead of rising and falling together.

Walkthrough None

Sources [3]; [8]; [20]; [21]; Coinbase, “Fortune 500 Moving Onchain” / State of Crypto survey coverage (2024); Cointeeth, “Analysis of NFT Market Growth Data in 2025”

Analyst Implications

1. Open membership enumeration — any token-gated community’s membership list is publicly readable on-chain; no special access required.

2. Pseudonymous coordination at scale — token-based governance enables decision-making and value transfer among parties who never identify themselves.

3. Permanent, auditable financial records — every token transfer is timestamped, signed, and immutable; the forensic substrate is always present.

4. Credential and identity systems outside traditional institutions — SBTs and on-chain attestations create verifiable records with no central issuing authority.

5. Infrastructure concentration as leverage point — RPC providers, bridges, and oracles are concentrated dependencies; disruption or compromise has outsized downstream effects.

Each capability cuts in two directions: it enables legitimate coordination and adversarial coordination with the same mechanism.

Overall Slide Concept This closing slide establishes the practical intelligence and operational consequences of token infrastructure. It matters here because the lesson is ultimately about what these systems enable, not just how they are built. Emphasize that every capability listed has both legitimate and adversarial applications.

Key Points - Token systems enable public membership mapping, pseudonymous coordination, durable financial records, credentialing, and targeted leverage through infrastructure chokepoints. - Analysts should evaluate both the benefits and the abuse potential of the same mechanism. - Define forensic substrate briefly as the persistent transaction record that supports later tracing and analysis.

Walkthrough None

Sources [22]; [9]; [19]; [23]

References

[1]

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.

[2]

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

[3]

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

[4]

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

[5]

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.

[6]

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

[7]

Collab.Land, “Collab.land Token Gating Tutorial.” Accessed: Mar. 27, 2026. [Online]. Available: https://docs.collab.land/docs/tutorials/token-gating-tutorial

[8]

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.

[9]

P. Ohlhaver, E. G. Weyl, and V. Buterin, “Decentralized Society: Finding Web3’s Soul,” SSRN Electronic Journal, 2022, doi: 10.2139/ssrn.4105763.

[10]

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.

[11]

U.S. Department of Justice, “United States v. Ethan Nguyen and Andre Llacuna: Complaint,” United States District Court, Southern District of New York, Mar. 2022. Accessed: Mar. 27, 2026. [Online]. Available: https://www.justice.gov/d9/press-releases/attachments/2022/03/24/us_v._ethan_nguyen_andre_llacuna_complaint.pdf

[12]

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.

[13]

D. A. Siegel, “Understanding the DAO Attack.” 2016. Available: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3014782

[14]

M. Mehar et al., “Understanding a Revolutionary and Flawed Grand Experiment in Blockchain: The DAO Attack.” Accessed: Oct. 21, 2025. [Online]. Available: https://papers.ssrn.com/abstract=3014782

[15]

Ethereum Foundation, “Critical update re: DAO vulnerability.” Accessed: Mar. 23, 2026. [Online]. Available: https://blog.ethereum.org/2016/06/17/critical-update-re-dao-vulnerability

[16]

Infura, “Ethereum API.” Accessed: Mar. 23, 2026. [Online]. Available: https://www.infura.io/product/ethereum

[17]

Alchemy, “Alchemy documentation.” Accessed: Mar. 23, 2026. [Online]. Available: https://www.alchemy.com/docs

[18]

CoinDesk, “As multichain wobbles, some fantom-based DeFi projects flee bridged tokens.” Accessed: Mar. 23, 2026. [Online]. Available: https://www.coindesk.com/business/2023/06/01/as-multichain-wobbles-some-fantom-based-defi-projects-flee-bridged-tokens

[19]

Bank for International Settlements, “The crypto ecosystem: Key elements and risks.” Accessed: Mar. 23, 2026. [Online]. Available: https://www.bis.org/publ/othp72.htm

[20]

C2PA, “C2PA.” Accessed: Mar. 23, 2026. [Online]. Available: https://c2pa.org/

[21]

U.S. Food and Drug Administration, “FSMA final rule on requirements for additional traceability records for certain foods.” Accessed: Mar. 18, 2026. [Online]. Available: https://www.fda.gov/food/food-safety-modernization-act-fsma/fsma-final-rule-requirements-additional-traceability-records-certain-foods

[22]

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

[23]

G. Zhu, D. He, H. An, M. Luo, and C. Peng, “The governance technology for blockchain systems: A survey,” Front. Comput. Sci., vol. 18, no. 2, p. 182813, Apr. 2024, doi: 10.1007/s11704-023-3113-x.