Token-Based Communities & NFTs in Practice

Section VII: Ethereum Framework

Army Cyber Institute

June 3, 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]

Case Study: Friends With Benefits

• Friends With Benefits (FWB) is a social DAO for Web3-focused creators, builders, and cultural organizers.

• Purpose: coordinate cultural production, events, writing, collaborations, and member-to-member social capital around Web3.

• FWB (ERC-20) functions as a social token: applicants are reviewed, then token ownership gates membership spaces and participation.

• Members use Discord, IRL events, editorial work, and governance to co-create the community’s direction.

• The core tension: curation can protect culture, but application review plus token thresholds creates a selective and price-sensitive gate.

Overall Slide Concept This slide establishes Friends With Benefits as the clearest social-token example in the deck. It matters here because FWB shows token ownership being used less like a protocol vote and more like a membership credential, reputation signal, and contribution incentive for a cultural community. Emphasize that access depends on both social review and token ownership.

Key Points - FWB combines application-based admission with token-gated participation. - The token coordinates identity, rewards, governance voice, and access rather than representing a single asset. - Define social capital briefly as reputation, trust, and access to relationships inside a community.

Walkthrough None

Sources Friends With Benefits, “Join” (https://www.v1.fwb.help/join); Friends With Benefits, “Redesigning the FWB Token System” (https://www.fwb.help/stories/redesigning-the-fwb-token-system); [7]

Case Study: Bored Ape Yacht Club

• Bored Ape Yacht Club (BAYC) is a 10,000-piece Ethereum NFT collection that became a membership club and entertainment/IP brand.

• Purpose: turn collectible identity into access, events, commercial licensing, and an expandable cultural ecosystem.

• BAYC (ERC-721) gates member experiences and links each holder to a specific Ape identity and artwork license.

• APE (ERC-20) is a separate ecosystem governance and utility token; holding APE, not BAYC, determines ApeCoin DAO voting.

• The core tension: NFT ownership, IP licensing, brand management, and DAO governance are related but not the same control surface.

Overall Slide Concept This slide establishes BAYC as a brand-driven membership NFT case. It matters here because BAYC is often described as a DAO or community in general terms, but operationally it layers NFT ownership, licensed art rights, exclusive access, company-led brand development, and a separate ApeCoin governance system. Emphasize the distinction between the BAYC NFT and APE governance token.

Key Points - BAYC shows how NFT identity can become a membership, licensing, and brand coordination mechanism. - ApeCoin DAO governance is adjacent to BAYC but uses a separate ERC-20 token. - Define control surface briefly as the part of a system through which a holder can actually exercise power.

Walkthrough None

Sources BAYC License (https://boredapeyachtclub.com/bayc-license); Made By Apes (https://boredapeyachtclub.com/activations/made-by-apes); ApeCoin official token information (https://apecoin.com/); ApeCoin DAO Discourse introduction (https://forum.apecoin.com/t/welcome-to-the-apecoin-dao-discourse/7)

Case Study: Doodles

• Doodles began as a colorful Ethereum NFT collection and evolved toward a broader media, entertainment, and collectibles brand.

• Purpose: build a character-driven creative universe with holders as early collectors, community members, and brand participants.

• Doodles (ERC-721) establishes collectible ownership and links holders to artwork/media license terms and community benefits.

• Community governance centered on Doodlebank, a treasury used to fund holder-facing campaigns, experiences, and experiments.

• The core tension: holders may expect participatory governance, but brand direction, licensing, and product execution depend on off-chain company decisions.

Overall Slide Concept This slide establishes Doodles as a membership NFT project that moved toward a company-led entertainment brand. It matters here because Doodles helps students distinguish token-enabled community participation from full decentralized control. Emphasize that the NFT can grant identity, access, and limited media rights while the surrounding brand still depends on corporate execution.

Key Points - Doodles illustrates how NFT communities can become brand and media ecosystems. - Holder participation and treasury voting do not automatically mean holders control every brand, licensing, or product decision. - Define media license briefly as the off-chain legal terms that specify how a holder may use token-linked artwork.

Walkthrough None

Sources Doodles Digital Collectibles Media License Agreement (https://www.doodles.app/legal/digital-collectibles-licenses/digital-collectibles-media-license-agreement); Doodles Terms of Service (https://www.doodles.app/legal/terms); Doodles legal documentation (https://www.doodles.app/legal)

Case Study: Gitcoin

• Gitcoin funds open-source and Web3 public goods through grants, matching pools, and governance.

• Purpose: direct capital toward public goods that are valuable to the ecosystem but hard to monetize through ordinary markets.

• GTC (ERC-20) governs Gitcoin’s decentralization work, grants processes, disputes, and treasury stewardship.

• Gitcoin popularized quadratic funding, where broad community support can receive more matching weight than a few large donors.

• The core tension: public-goods funding needs open participation, but open participation creates sybil, collusion, and identity-verification pressure.

Overall Slide Concept This slide establishes Gitcoin as a public-goods DAO rather than a membership club or collectible brand. It matters here because Gitcoin uses tokens and governance to allocate resources toward ecosystem work that markets underfund. Emphasize that Gitcoin combines token governance with mechanism design, especially quadratic funding and sybil resistance.

Key Points - Gitcoin shows token governance used for public-goods funding and stewardship. - GTC voting and grants governance are distinct from the quadratic funding mechanism used in grants rounds. - Define sybil resistance briefly as defenses against one actor pretending to be many independent participants.

Walkthrough None

Sources Gitcoin GTC overview (https://www.gitcoin.co/gtc); Gitcoin Governance Manual (https://manual.gitcoin.co/); Gitcoin Governance Overview (https://manual.gitcoin.co/governance-processes/governance-overview); Gitcoin Voting documentation (https://manual.gitcoin.co/governance-processes/voting); Gitcoin funding mechanisms (https://www.gitcoin.co/mechanisms)

Case Study: ENS DAO

• Ethereum Name Service (ENS) maps human-readable names to addresses and other records; the DAO governs the protocol and treasury.

• Purpose: maintain decentralized naming infrastructure for Ethereum users, wallets, dApps, and protocols.

• ENS (ERC-20) designates voting weight; holders must delegate voting rights before voting or creating proposals.

• Governance spans off-chain signaling, on-chain executable proposals, working groups, and a written constitution.

• The core tension: a token vote can update contracts and move treasury funds, but legitimacy also depends on delegates, stewards, norms, and emergency controls.

Overall Slide Concept This slide establishes ENS DAO as a protocol-governance example rather than a social club or collectible project. It matters here because ENS governs public naming infrastructure used across Ethereum applications, so token voting affects a shared utility rather than only access to a community space. Emphasize that the token is only one part of a wider governance stack.

Key Points - ENS DAO shows token governance applied to live protocol infrastructure and treasury management. - ENS votes can be delegated, and proposals may be social, executable, or constitutional depending on what they change. - Define delegation briefly as assigning voting power to an address without transferring token ownership.

Walkthrough None

Sources ENS DAO documentation (https://docs.ens.domains/dao/); ENS Token documentation (https://docs.ens.domains/dao/token/); ENS Governance Process (https://docs.ens.domains/dao/governance/process/); ENS DAO Constitution (https://docs.ens.domains/dao/constitution/)

Case Study: Nouns DAO

• Nouns DAO mints and auctions one new Noun NFT roughly every 24 hours, with proceeds deposited into the DAO treasury.

• Purpose: fund open-ended public goods, art, software, events, and brand experiments that spread the Nouns identity.

• Each Noun (ERC-721) is an irrevocable DAO membership unit and carries one vote in governance.

• The model links identity, funding, and governance: the NFT is the member badge, voting asset, and source of treasury growth.

• The core tension: daily issuance broadens participation over time, but high auction prices can still concentrate governance among wealthy buyers.

Overall Slide Concept This slide establishes Nouns DAO as a clean example of NFT-native governance. It matters here because Nouns uses the NFT itself as the governance unit rather than pairing a collectible with a separate fungible governance token. Emphasize that the auction mechanism continuously creates both new members and new treasury capital.

Key Points - Nouns connects an ongoing NFT auction to DAO treasury formation and one-NFT-one-vote governance. - The same token acts as identity, membership, and voting power. - Define treasury growth briefly as the process by which auction proceeds add resources for later community-approved spending.

Walkthrough None

Sources Nouns DAO documentation (https://docs.nouns.wtf/); Nouns DAO official site (https://nouns.wtf/); Nouns governance overview (https://www.nouns.com/learn/nouns-dao-governance-explained)

Case Study: ConstitutionDAO

• ConstitutionDAO formed in November 2021 for one purpose: collectively bid on a rare first printing of the U.S. Constitution.

• Purpose: pool capital quickly around a shared cultural acquisition that no individual participant could easily pursue alone.

• The group raised roughly $47M in ETH, but did not win the $43.2M sale once fees, custody, and refund obligations constrained its bid.

• Contributors could claim PEOPLE tokens or redeem them for ETH at the original contribution ratio.

• After wind-down, the official project stated PEOPLE had no governance rights or utility beyond redemption — but the token continued to trade and carry social meaning.

Overall Slide Concept This slide establishes ConstitutionDAO as a single-purpose DAO that succeeded at rapid coordination but failed at the off-chain objective it organized around. It matters here because the case shows that tokens can coordinate capital and identity faster than legal, auction, custody, and refund systems can necessarily absorb. Emphasize that the token’s social life outlasted the project’s stated mission.

Key Points - ConstitutionDAO demonstrates the power of token-enabled crowdfunding and the limits of token ownership when real-world assets and institutions are involved. - PEOPLE became a claim/refund mechanism and later a social symbol, not legal ownership of the Constitution. - Define single-purpose DAO briefly as a DAO organized around one concrete objective rather than ongoing protocol governance.

Walkthrough None

Sources ConstitutionDAO refund page (https://www.constitutiondao.com/); Sotheby’s press release on the Constitution sale (https://www.sothebys.com/en/press/newsflash-newsflash%20%28Sothebys.com%20-%20Permalink%29); Axios, “A billionaire’s crypto win” (https://www.axios.com/2021/11/20/crypto-constitution-trading)

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
ENS DAO	Protocol DAO	ENS (ERC-20)	Protocol and treasury governance	Token voting around public naming infrastructure
Nouns DAO	NFT DAO	Nouns (ERC-721)	One NFT = one governance vote	Daily auction continuously funds treasury
ConstitutionDAO	Single-purpose DAO	PEOPLE (ERC-20)	Refund claim; proposed governance	Token meaning persisted after project ended

• 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.v1.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/); ENS DAO documentation (https://docs.ens.domains/dao/); Nouns DAO documentation (https://docs.nouns.wtf/); ConstitutionDAO refund page (https://www.constitutiondao.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]

(1) Attacker calls withdraw(amount) (2) DAO checks balance → passes balance was never decremented (3) DAO sends ETH to attacker balance STILL not updated (4) Attacker fallback() fires → calls withdraw() again (6) balances[msg.sender] -= amount NEVER REACHED during the loop should run next — never reached RE-ENTRY → back to ② balance still unchanged (5) Gas runs out → loop stops 3.6M ETH ($60M) drained

eventually

:::
`</figure>`{=html}
::::
:::::
::::::
:::

::: {style="border: 2px solid #2ecc71; color: black; padding: 0.4em 0.8em; margin-top: -1.em; font-size: 0.50em;"}
**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.
:::

::: {.notes}

**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**
@siegel_understandingdaoattack_2016; @l34_ethereum_dao_vulnerability_2016

:::

-->

## Centralization Chokepoints {style="font-size: 0.83em;"}

- 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.

::: {.notes}

**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**
@l31_infura_ethereum_api_2026; @l31_alchemy_docs_2026; @l31_coindesk_multichain_fantom_2023; @l31_bis_crypto_ecosystem_risks_2022

:::

## Hidden Infrastructure Growth

::: {style="font-size: .75em;"}

- 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.

:::

::::::{.cell fig-width="7.5" fig-height="2.4" layout-align="default"}

:::::{.cell-output-display}

::::{}
`<figure class=''>`{=html}

:::{}
```{=html}
<svg width="720" height="230" viewbox="0.00 0.00 568.65 151.63" xmlns="http://www.w3.org/2000/svg" xlink="http://www.w3.org/1999/xlink" style="; max-width: none; max-height: none; display: block; margin: auto auto auto auto">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 147.63)">
<title>decoupling</title>
<polygon fill="white" stroke="transparent" points="-4,4 -4,-147.63 564.65,-147.63 564.65,4 -4,4"></polygon>
<!-- SPEC -->
<g id="node1" class="node">
<title>SPEC</title>
<polygon fill="#6b1a1a" stroke="black" points="316.81,-80 163.25,-80 163.25,0 316.81,0 316.81,-80"></polygon>
<text text-anchor="middle" x="240.03" y="-67" font-family="Arial" font-size="10.00" fill="white">Speculative Layer</text>
<text text-anchor="middle" x="240.03" y="-55" font-family="Arial" font-size="10.00" fill="white">──────────</text>
<text text-anchor="middle" x="240.03" y="-43" font-family="Arial" font-size="10.00" fill="white">PFP collections</text>
<text text-anchor="middle" x="240.03" y="-31" font-family="Arial" font-size="10.00" fill="white">Secondary market trading</text>
<text text-anchor="middle" x="240.03" y="-19" font-family="Arial" font-size="10.00" fill="white">Price speculation</text>
<text text-anchor="middle" x="240.03" y="-7" font-family="Arial" font-size="10.00" fill="white">STATUS: Collapsed -37% YoY</text>
</g>
<!-- UTIL -->
<g id="node2" class="node">
<title>UTIL</title>
<polygon fill="#1e6e42" stroke="black" points="560.61,-126 430.76,-126 430.76,-34 560.61,-34 560.61,-126"></polygon>
<text text-anchor="middle" x="495.69" y="-113" font-family="Arial" font-size="10.00" fill="white">Utility Layer</text>
<text text-anchor="middle" x="495.69" y="-101" font-family="Arial" font-size="10.00" fill="white">──────────</text>
<text text-anchor="middle" x="495.69" y="-89" font-family="Arial" font-size="10.00" fill="white">Digital Product Passports</text>
<text text-anchor="middle" x="495.69" y="-77" font-family="Arial" font-size="10.00" fill="white">Supply chain records</text>
<text text-anchor="middle" x="495.69" y="-65" font-family="Arial" font-size="10.00" fill="white">Tokenized loyalty</text>
<text text-anchor="middle" x="495.69" y="-53" font-family="Arial" font-size="10.00" fill="white">SBT credentials</text>
<text text-anchor="middle" x="495.69" y="-41" font-family="Arial" font-size="10.00" fill="white">STATUS: Growing quietly</text>
</g>
<!-- SPEC&#45;&gt;UTIL -->
<g id="edge3" class="edge">
<title>SPEC-&gt;UTIL</title>
<path fill="none" stroke="#f39c12" stroke-dasharray="1,5" d="M316.8,-51.95C349.6,-57.12 387.89,-63.16 420.52,-68.3"></path>
<polygon fill="#f39c12" stroke="#f39c12" points="420.03,-71.77 430.45,-69.87 421.12,-64.85 420.03,-71.77"></polygon>
<text text-anchor="middle" x="373.7" y="-81.5" font-family="Arial" font-size="9.00" fill="#f39c12">same primitive</text>
<text text-anchor="middle" x="373.7" y="-70.7" font-family="Arial" font-size="9.00" fill="#f39c12">different application</text>
</g>
<!-- ANA -->
<g id="node3" class="node">
<title>ANA</title>
<ellipse fill="#4a3500" stroke="black" cx="63.2" cy="-40" rx="63.39" ry="22.76"></ellipse>
<text text-anchor="middle" x="63.2" y="-43" font-family="Arial" font-size="10.00" fill="white">Most analysts</text>
<text text-anchor="middle" x="63.2" y="-31" font-family="Arial" font-size="10.00" fill="white">watching here ↑</text>
</g>
<!-- ANA&#45;&gt;SPEC -->
<g id="edge1" class="edge">
<title>ANA-&gt;SPEC</title>
<path fill="none" stroke="#e74c3c" stroke-dasharray="5,2" d="M126.82,-40C135.27,-40 144.06,-40 152.83,-40"></path>
<polygon fill="#e74c3c" stroke="#e74c3c" points="153.1,-43.5 163.1,-40 153.1,-36.5 153.1,-43.5"></polygon>
</g>
<!-- OPS -->
<g id="node4" class="node">
<title>OPS</title>
<ellipse fill="#1a3a5a" stroke="black" cx="240.03" cy="-121" rx="68.89" ry="22.76"></ellipse>
<text text-anchor="middle" x="240.03" y="-124" font-family="Arial" font-size="10.00" fill="white">Operational reality</text>
<text text-anchor="middle" x="240.03" y="-112" font-family="Arial" font-size="10.00" fill="white">building here ↑</text>
</g>
<!-- OPS&#45;&gt;UTIL -->
<g id="edge2" class="edge">
<title>OPS-&gt;UTIL</title>
<path fill="none" stroke="#2ecc71" stroke-dasharray="5,2" d="M302.65,-111.51C335.37,-106.42 376.25,-99.98 412.73,-94 415.37,-93.57 418.07,-93.12 420.79,-92.67"></path>
<polygon fill="#2ecc71" stroke="#2ecc71" points="421.43,-96.11 430.72,-91.01 420.28,-89.21 421.43,-96.11"></polygon>
</g>
</g>
</svg>

::: :::: ::::: ::::::

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]; [13]; [14]; 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 [15]; [9]; [16]; [17]

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]

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

[14]

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

[15]

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

[16]

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

[17]

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.