NFTs, Tokenization, and Digital Assets Flashcards

A real estate company tokenizes a commercial building using a security token on Ethereum, issuing 10,000 tokens at $100 each. Six months later, 30% of token holders want to exit, but the secondary market has thin liquidity and tokens trade at a 22% discount to NAV. Which mechanism is MOST specifically designed to address this structural problem in real-world asset tokenization?

Answer: Implementing an automated market maker (AMM) pool seeded with a reserve fund from token sale proceeds

An AMM pool seeded with a reserve fund from the token sale directly addresses liquidity fragmentation by providing a continuous on-chain market. This is a proven mechanism used in real-world asset (RWA) protocols to reduce NAV discounts. A 12-month lock-up worsens the exit problem, ERC-1400 adds compliance controls but doesn't create liquidity, and CEX listing merely shifts the liquidity problem rather than solving the structural thin-market issue inherent in niche tokenized assets.

An NFT collection uses a 'dynamic metadata' architecture where the token URI points to an IPFS CID that can be updated by the contract owner after mint. A buyer argues this violates the principle of immutability. Which technical assessment is MOST accurate?

Answer: The NFT is mutable in practice because if the contract owner updates the URI to a new CID, buyers have no on-chain mechanism to prove what the original metadata was unless the original CID was emitted in a mint event log

IPFS is content-addressed, so each CID represents a unique, immutable piece of data — but the on-chain token URI is a *pointer* to a CID, and if the contract allows the owner to swap that pointer to a new CID, the effective metadata changes. The only way a buyer can prove original metadata is if the original CID was captured in an immutable on-chain event log (e.g., the mint transaction emitting a MetadataUpdate event). ERC-721 does not prohibit URI changes — ERC-721 Metadata extension simply defines tokenURI() as a view function. IPFS alone does not guarantee immutability if the pointer itself is mutable.

Under the ERC-1155 multi-token standard, a game developer mints 1 NFT (id=1, supply=1) and 1,000,000 fungible tokens (id=2, supply=1,000,000) in the same contract. A validator claims this approach has a critical hidden gas cost advantage over deploying separate ERC-721 and ERC-20 contracts. What is the MOST precise technical basis for this claim?

Answer: ERC-1155's safeBatchTransferFrom allows atomic multi-token transfers in one transaction, amortizing the fixed base gas cost (21,000 gwei) and the contract call overhead across all transferred token ids

The primary gas advantage of ERC-1155 is its safeBatchTransferFrom function, which processes multiple token type transfers atomically in a single transaction. Each Ethereum transaction carries a 21,000 gas base fee plus per-opcode costs. Batching amortizes this base cost and the contract call overhead (CALL opcode, ABI decoding) across all token ids transferred simultaneously. While ERC-1155 does consolidate balances in one mapping, the SLOAD advantage is secondary. ERC-1155 still uses approvals (setApprovalForAll). ERC-1155 does not store metadata on-chain by default — it uses a URI template.

A DeFi protocol allows ERC-721 NFTs representing fractionalized ownership of fine art to be used as collateral for loans. A borrower deposits an NFT valued at $500,000 and borrows $300,000 in stablecoins. The NFT floor price drops 45% in 72 hours. Which liquidation challenge is UNIQUE to NFT collateral compared to fungible token collateral in the same protocol?

Answer: The liquidation auction may fail to recover the loan value because NFT price discovery requires a willing buyer for a unique asset, unlike fungible tokens where the protocol can atomically swap using an AMM with near-continuous liquidity

The fundamental challenge of NFT-backed lending is illiquidity at liquidation. With fungible token collateral, the protocol can trigger an atomic liquidation via an AMM (e.g., Uniswap), converting collateral to repay the loan in the same block. NFTs have no equivalent continuous market — they require a discrete auction or sale to a willing buyer, which may take hours or days. During a 45% price drop over 72 hours, the protocol may be unable to liquidate at any price quickly enough to remain solvent, creating bad debt. This is not a legal prohibition, NFTs are absolutely saleable, and no standard lending protocol grants a right of first refusal to borrowers.

A musician uses the ERC-2981 royalty standard to set a 10% royalty on secondary sales of their NFT. Three years later, the NFT is traded on a new marketplace that ignores ERC-2981 and processes the sale without paying royalties. What does this scenario reveal about the FUNDAMENTAL architectural limitation of on-chain royalty enforcement?

Answer: ERC-2981 defines a royalty information interface but does not enforce payment — it is the marketplace's choice whether to honor it, making royalty enforcement dependent on marketplace policy rather than protocol-level guarantees

ERC-2981 (NFT Royalty Standard) is a signal standard — it provides a standardized way for contracts to communicate royalty recipient and amount via a royaltyInfo() function, but it does NOT enforce payment on-chain. Any marketplace can query this information and then simply choose not to forward the royalty split. True enforcement would require that value transfer be gated inside the NFT's transfer function (e.g., requiring the royalty payment before the safeTransferFrom succeeds), which introduces composability problems. ERC-2981 is a legitimate EIP adopted as a standard. There is no clawback mechanism. Ethereum validators have no awareness of royalty obligations at the consensus layer.

A sovereign wealth fund explores issuing tokenized government bonds as digital securities on a permissioned blockchain. Their legal team flags that ERC-1400 (Security Token Standard) supports 'transfer restrictions by partition.' In this context, what does 'partition' specifically enable that standard ERC-20 transfers cannot provide?

Answer: Partition enables a single token to represent multiple tranches with different transfer rules, lock-up periods, or investor eligibility conditions enforced at the token level without requiring separate contract deployments per tranche

ERC-1400's partition concept allows a single security token contract to manage multiple sub-balances (partitions) for the same token holder, where each partition can have distinct transfer restrictions — e.g., a 'Series A' partition locked for 12 months and a 'Series B' partition transferable only to accredited investors. This replicates how traditional finance structures bond tranches or equity classes within a single issuance vehicle, without needing separate contracts per tranche. Partitions do not create separate contracts, do not inherently add ZK-proof privacy, and do not enable unauthorized supply inflation.