Rethinking NFT Security: What Standard Tokens Actually Provide

In 2022 I filed a provisional patent with BlockFi titled "Systems and Methods for Enhanced Non-Fungible Tokens." The premise of that work was that standard NFT implementations, specifically ERC-721 and ERC-1155, are adequate for many use cases and deeply inadequate for others, particularly anywhere the stakes involve financial value, legal ownership rights, or institutional custody. This post is about the gap between what these tokens actually provide and what people commonly assume they provide, the attack surface that gap creates, and what a more robust architecture looks like.

What ERC-721 Actually Gives You

The ERC-721 standard, finalized in 2018, defines a minimal interface for non-fungible tokens on Ethereum: a mapping from token IDs to owner addresses, transfer functions, and an approval mechanism. That is substantially the complete list.

What it does not provide:

• Any guarantee about the content the token points to
• Any access control beyond "the owner can transfer this token"
• Any on-chain record of where the token came from, who created it, or what chain of custody it passed through
• Any revocation mechanism
• Any way to enforce rights or conditions on transfer

The tokenURI function returns a string, typically a URL pointing to a JSON metadata file. That URL might point to IPFS, to a centralized server, or to anything else. The standard does not specify. The token is on-chain and permanent; what it points to may not be.

When someone says they "own" an NFT, they own the on-chain record that their address controls a particular token ID in a particular smart contract. They do not necessarily own the image, the intellectual property, the legal rights to anything the image represents, or even a reliable reference to the image itself if the metadata is hosted on mutable infrastructure.

This gap between on-chain ownership and real-world ownership is not a flaw in the token standard per se, because the standard was not designed to solve those problems. The flaw is the widespread assumption that it does.

The Attack Surface

Operating at the intersection of blockchain technology and financial services made the following attack categories impossible to ignore.

Smart Contract Vulnerabilities

The NFT contract is code, and code has bugs. Reentrancy vulnerabilities in NFT marketplace contracts, where a malicious receiver contract calls back into the marketplace during a transfer, have produced significant losses. The ERC-721 safeTransferFrom function calls onERC721Received on the recipient if it is a contract, which is the hook that reentrancy exploits target.

Overflow and underflow bugs, access control mistakes (functions that should be owner-only left unprotected), and logic errors in auction or sale mechanics have all produced exploitable contracts. The immutability of deployed contracts means that once a vulnerability is in production, the only remediation is migration to a new contract, which requires every token holder to take an action, and which is frequently not completed before exploitation occurs.

Metadata Mutability

If the tokenURI for your NFT points to a centralized server, the server operator can change what it points to. They can replace the image with something else, point it to a 404, or take the server offline entirely. This has happened repeatedly. The NFT you paid for becomes a pointer to nothing.

IPFS is commonly cited as the solution to this problem. An IPFS content identifier (CID) is a hash of the content, so if the content changes, the CID changes. If your tokenURI is an IPFS CID, the content it references is immutable. The limitation is that IPFS content is only available if at least one node in the IPFS network is pinning it. If the original uploader stops pinning and no one else does, the content becomes unretrievable even though the CID is permanent. Pinning services address this, but they introduce a centralized dependency.

Truly immutable metadata requires the metadata and the asset to either be stored on-chain (expensive) or stored with credible long-term persistence guarantees. Currently, neither option is well-standardized.

Approval Exploits

ERC-721 includes setApprovalForAll, which grants a specified address unlimited permission to transfer every token you own in a given contract. This function exists for legitimate reasons: it is how NFT marketplaces operate without requiring a separate transaction per token. It is also the mechanism behind a large class of phishing attacks.

The attack pattern: a user is tricked into signing a setApprovalForAll transaction (often disguised as something harmless, or executed as part of a malicious site interaction) granting an attacker's address operator status. The attacker then drains all NFTs from the victim's wallet. Because this is a valid approved transfer, it is indistinguishable from a legitimate marketplace transfer at the contract level.

The fundamental problem is that the approval model in ERC-721 is binary and unbounded. You approve an address for all tokens or none. There is no mechanism for time-limited approvals, value-limited approvals, or approvals conditioned on specific downstream transfers.

Wash Trading and Price Manipulation

On-chain ownership records make wash trading straightforward to execute and difficult to detect algorithmically. Wash trading works by cycling assets between controlled addresses to create artificial price history. Two addresses controlled by the same entity can exchange an NFT back and forth at escalating prices, creating a false sales history that influences perceived value for genuine buyers. The blockchain records these transactions as indistinguishable from legitimate transfers.

The Provenance Problem

Provenance, meaning the documented chain of custody and origin, is what makes ownership claims credible for high-value assets. A painting's provenance traces it from creation through every owner. For NFTs, on-chain ownership history records every transfer, which looks like provenance but is not.

The on-chain record tells you who has controlled the token. It does not tell you whether the original minter had the right to mint it, whether the content is authentic, or whether transfers represent genuine arms-length transactions. An NFT minted from someone else's artwork, traded between wash-trading addresses to build fake sales history, has a rich on-chain record that provides zero meaningful provenance.

What Enhanced NFT Systems Require

The provisional patent I filed described architectural approaches to address these gaps. At a high level, the needed components are:

Immutable and verifiable metadata. The link between a token and its referenced content needs cryptographic guarantees. Content-addressed storage where the token itself commits to the hash of the content, combined with credible persistence guarantees, is the foundation. On-chain storage of at least the critical metadata attributes, not just a pointer, adds another layer.

Access control layers beyond ownership. The binary owner/not-owner model is insufficient for financial-grade assets. Real applications need conditional transfer rights, operator permissions with explicit scope and expiration, and the ability to encode legal or contractual conditions into the transfer logic. This points toward more expressive token contracts that separate the concepts of ownership, transfer authorization, and operational rights.

On-chain provenance records. Provenance needs to be a first-class data structure, not an inference from transfer history. This means recording the origin of the token in a verifiable, tamper-evident way at mint time: who created it, what authority they had to do so, and what the creation event was linked to. Subsequent custody transfers should be recorded with attestations, not just address changes.

Revocation mechanisms. For certain use cases, including regulatory compliance, fraud remediation, and stolen asset recovery, the ability to revoke or freeze a token is a necessary feature. Standard NFTs have no revocation. Adding it without compromising the trust model requires careful design: a revocation authority that is itself governed, auditable, and resistant to abuse.

Lessons from Financial-Grade Custody

Working in crypto financial services at BlockFi shaped how I thought about these problems. In traditional financial systems, custody infrastructure is separated from trading infrastructure deliberately. The custodian holds the assets; the broker executes transactions; independent audit verifies the custodian's records against the expected holdings.

NFT infrastructure today conflates these roles entirely. The same private key that holds your NFTs is the one you use to interact with marketplaces, sign transactions, and connect to web3 applications. A single compromised signing operation can empty a wallet.

Financial-grade systems separate these concerns. Hot wallets for active operations hold minimal value. Cold custody holds the bulk of assets and requires multi-party authorization for any outbound transaction. The private keys for custodied assets never touch internet-connected systems in normal operation.

Applying these principles to NFTs at institutional scale required rethinking the entire interaction model, not just the token standard. Multi-signature custody, hardware security modules for key operations, policy-enforced transaction limits, and reconciliation processes comparable to traditional financial controls were all necessary pieces.

Where the Problems Remain Unsolved

The NFT security space has made progress on some of these issues and essentially no progress on others.

Phishing and approval exploits have gotten worse, not better, primarily because the user experience of signing transactions remains opaque. Most users cannot reliably distinguish a benign signature request from a malicious one, and the financial incentives for attackers are high.

The metadata persistence problem remains structurally unsolved for anything other than fully on-chain storage, which remains expensive enough to preclude for most use cases.

Cross-chain asset bridging is introducing an entirely new attack surface as it matures, and early bridge exploits like Wormhole and Ronin show that the security properties of these systems are not yet well understood. Bridge contracts have been among the largest exploit targets in the space.

The provenance problem is the deepest unsolved issue. The technical infrastructure for on-chain provenance attestation is achievable, but it solves only the integrity half of the problem. The other half requires off-chain verification processes and legal frameworks that no technical solution can fully replace: verifying that a real-world claim (this artist created this piece, this entity has the rights to mint this asset) actually corresponds to an on-chain record.

Building any serious financial product on top of these foundations requires treating the gaps as engineering constraints, not inconveniences. The enhanced architecture the patent describes is one approach to raising the floor. The ceiling of what is achievable is still determined by the ecosystem around the chain, not just the chain itself.