You’re building a DAO governance contract. Founding members get double voting weight, but you want to lock it to wallets that actually held the founding NFT since genesis, not people who bought in last week after the floor pumped from $80K to $200K. The logic is simple: call ownerOf(tokenId), check if it matches, done.
Except ownerOf() returns today’s owner. The original holders sold at the bottom three months ago. The wallets that should qualify are gone from the contract’s perspective.
So you go looking for the Transfer events. That’s when you hit the architectural wall.
The event log is not accessible to smart contracts
Transfer events exist. Every ERC-721 transfer emits one. But event logs live in a separate trie from contract state, and the EVM has no opcode for reading them at runtime.1 A contract executing on block 22,000,000 cannot inspect a Transfer event from block 19,500,000. There is no GETLOG opcode. There is no way to read log data without an external call to something off-chain.
This is not a bug. It is a deliberate architectural choice: logs are cheap to write precisely because they are not accessible to contracts. But for provenance use cases, it creates a hard composability gap. A running contract cannot answer “did this address ever own this token?” without trusting something outside the chain.
The three most common workarounds each have failure modes.
Merkle trees. Compute an off-chain snapshot at a fixed block, build a Merkle tree, store the root on-chain. Wallets submit proofs at claim time. This works once, for one block, with one trusted snapshot. Any history before or after that block is excluded. The snapshot itself requires trusting whoever computed it.
Off-chain indexers. The Graph, Alchemy, custom subgraphs: all read event logs and expose them via API. The contract calls an oracle that queries the indexer. Now your governance contract has a runtime dependency on an indexer that can go down, be censored, or return stale data. Archive node costs for eth_getLogs on large collections are non-trivial.
On-chain snapshot at mint time. Record the minter’s address in storage during _mint(). You get one data point: who created the token. The original buyer, the third custodian, the charity auction winner: none of that is captured.
For a DAO airdrop, a perpetual royalty contract, or a provenance marketplace, all three workarounds add external trust assumptions to what should be a pure on-chain operation.
EIP-8042: ownership history as a first-class primitive
EIP-8042, proposed by Emiliano Solazzi in February 2026, adds ownership history directly to the ERC-721 interface.2 The design is a three-layer model that extends the standard without breaking it.
| Layer | Name | Mutability | What it stores |
|---|---|---|---|
| 1 | Immutable Origin | Write-once | Creator address + mint block |
| 2 | Historical Trail | Append-only | Chronological (address, blockNumber) pairs |
| 3 | Current Authority | Mutable | Standard ownerOf(), unchanged |
Layer 3 is exactly the ERC-721 you already know. Existing integrations, marketplaces, wallets, display tools, continue to work with no changes. Layers 1 and 2 are additive.
The core interface:
// Layer 1 , Immutable Origin
function originalCreator(uint256 tokenId) external view returns (address);
function mintBlock(uint256 tokenId) external view returns (uint256);
function isOriginalOwner(uint256 tokenId, address account) external view returns (bool);
// Layer 2 , Historical Trail
function hasEverOwned(uint256 tokenId, address account) external view returns (bool); // O(1)
function getOwnerAtBlock(uint256 tokenId, uint256 blockNumber) external view returns (address); // O(log n)
function getOwnershipHistory(uint256 tokenId) external view returns (address[] memory, uint256[] memory);
function getHistorySlice(uint256 tokenId, uint256 start, uint256 count) external view returns (address[] memory, uint256[] memory);hasEverOwned() is the core primitive. It answers the question that breaks Merkle trees and indexer dependencies in a single call. Any contract can call it, with no external trust, at runtime. The DAO governance example becomes:
// What you have to write today
function isFoundingMember(address wallet) public view returns (bool) {
// Returns false for original holders who sold , ownerOf() is current only
return foundingNFT.ownerOf(GENESIS_TOKEN_ID) == wallet;
}
// What EIP-8042 makes possible
function isFoundingMember(address wallet) public view returns (bool) {
return foundingNFT.hasEverOwned(GENESIS_TOKEN_ID, wallet);
}The second version is composable. The first one is wrong.
Engineering the append-only guarantee
The value of the historical trail depends on it being unmanipulable. If an attacker can flash-loan an NFT through a hundred addresses in one block, they can fabricate a provenance trail that qualifies dozens of wallets for airdrops they should not receive.
EIP-8042 addresses this with a two-layer sybil defense built into _transfer().
Intra-transaction guard. Using EIP-1153 transient storage, the transfer function sets a flag marking the token as transferred within the current transaction.3 A second transfer of the same token in the same TX reverts with TokenAlreadyTransferredThisTx(). Flash-loan cycling in a single transaction is blocked.
Inter-transaction guard. After recording a history entry, the contract checks whether the last entry in _ownershipBlocks[tokenId] matches block.number. If it does, the transfer reverts with OwnerAlreadyRecordedForBlock(). One entry per token per block, maximum.
// Intra-tx guard: transient storage flag
if (TransientStorage.getTransferred(tokenId))
revert TokenAlreadyTransferredThisTx();
TransientStorage.setTransferred(tokenId);
// Inter-tx guard: block-level deduplication
uint256[] storage blocks = _ownershipBlocks[tokenId];
if (blocks.length > 0 && blocks[blocks.length - 1] == block.number)
revert OwnerAlreadyRecordedForBlock();The spec uses block.number, not block.timestamp. Validators can manipulate timestamps within roughly 15 seconds. Block numbers are canonical.
Self-transfers (from == to) are also blocked. They would append a history entry without changing ownership, a way to inflate getTransferCount() or pollute provenance reports with no-op events.
The storage layout enables efficient queries. _ownershipBlocks is monotonically increasing (each new entry is a higher block number than the last), so getOwnerAtBlock() can binary search in O(log n) rather than scanning the full array. hasOwnedToken[tokenId][address] is a separate O(1) boolean map. It trades storage space for constant-time lookup on the most common query.
The cost
Provenance is not free. The gas benchmarks from the reference implementation (Solidity 0.8.30, 200-run optimization) make the trade-off explicit:
| Operation | Overhead vs. standard ERC-721 | Reason |
|---|---|---|
| Mint | approximately 6-7x | Three layers initialized, sybil guards, arrays allocated |
| Transfer | approximately 3-4x | Two SSTOREs + guards + O(1) lookup map update |
| Burn | Comparable or lower | Layers 1 and 2 are NOT cleared |
| View calls | Zero | All free, no gas cost |
A 3-4x transfer overhead translates to roughly 60,000-80,000 gas at current ERC-721 baseline costs. That is not viable for high-volume gaming items or consumer NFTs with frequent trading. It is acceptable for provenance-sensitive assets: digital art, founding member tokens, high-value credentials, anything where the history is part of the value.
Burn not clearing history is an intentional design decision. The provenance record is the point. Burning the token does not erase the chain of custody, which is correct for art authentication and dispute resolution use cases, even if it creates permanent public exposure of every address that ever held the token. There is something genuinely unsettling about that last part: your address is in the history forever, even after you sell and burn. Users who want address separation should use fresh wallets before they acquire anything under this standard.
There is also an unbounded growth concern. Each transfer appends two array entries (one to ownershipHistory, one to ownershipBlocks) at approximately 20,000 gas per SSTORE. For tokens that trade frequently over years, storage costs accumulate. The spec notes that implementations may add a maxHistory cap. The reference implementation does not enforce one by default.
One deprecated function worth flagging: getOwnerAtTimestamp() appears in some early drafts but is explicitly deprecated in the current spec. It returns address(0). Only getOwnerAtBlock() is canonical.
What this changes, and what it does not
Block explorers are currently the only user-facing tool for NFT ownership history. Ethernal indexes Transfer events and displays them as a readable timeline. That works for humans examining a token’s past owners. It does not work for contracts.
EIP-8042 creates a new on-chain surface that changes the contract composability picture.
Perpetual royalties to original minters. A royalty contract can call originalCreator(tokenId) at settlement time and route 2% to whoever minted, not to the current owner, not to the marketplace. No oracle. No snapshot. The minter address is write-once and permanently available.
Governance weight tied to earliest ownership. A DAO contract can call getOwnerAtBlock(tokenId, genesisBlock) to find who held a token at launch and weight their vote accordingly. Earlier holders can get more weight using the block number in the history entry.
Airdrop qualification without Merkle trees. Deploy an airdrop contract that calls hasEverOwned() directly. Any wallet that ever held the target token qualifies. No off-chain snapshot, no Merkle proof submission, no trusted computation step.
What EIP-8042 does not solve: collections that already exist. Migration path is wrapAndMint(uint256 originalTokenId), which creates a new EIP-8042 token wrapping an existing one. But prior history, everything before the wrap, is not captured retroactively. A collection launched in 2021 cannot backfill six years of Transfer events into on-chain storage.
Status and what to watch
EIP-8042 is a draft. The PR was initially filed in the ethereum/EIPs repository, which now routes ERC-related content to ethereum/ERCs. The specification itself is technically complete: 423 tests across 16 contracts validating the behavioral requirements. The procedural routing issue does not affect the specification quality.
The underlying constraint EIP-8042 addresses is not going away. Event logs and smart contracts occupy different worlds by design. Any system that needs on-chain composability with ownership history will hit this wall. EIP-8042’s three-layer model is one coherent answer: make the history a queryable primitive at the point of origin, pay for it in gas at transfer time, and let contracts access it natively forever after.
Adoption depends on whether NFT platforms and protocol teams decide the provenance use cases are worth the gas overhead. For collections where the history is the value, art, credentials, founding member tokens, the math likely works. For high-velocity consumer NFTs, it probably does not. That distinction is itself useful signal: EIP-8042 is not trying to replace ERC-721 for all use cases. It is adding a dimension for the ones where history matters.
References
1. Ethereum Foundation. “Ethereum Yellow Paper: Formal Specification.” ethereum.github.io, 2025. https://ethereum.github.io/yellowpaper/paper.pdf
2. Solazzi, E. (@emilianosolazzi). “Add EIP: Historical Ownership Extension for ERC-721.” GitHub EIPs, February 2026. https://github.com/ethereum/EIPs/pull/11342
3. Ethereum Foundation. “EIP-1153: Transient Storage Opcodes.” Ethereum Improvement Proposals, 2024. https://eips.ethereum.org/EIPS/eip-1153
4. Ethereum Foundation. “EIP-721: Non-Fungible Token Standard.” Ethereum Improvement Proposals, 2018. https://eips.ethereum.org/EIPS/eip-721
