fix(audit): tighten ERC-721 decode to require empty data#48
Merged
Conversation
Audit M-4 follow-up against #46. The Transfer selector `0xddf252ad…` is shared by: - ERC-20 `Transfer(address indexed, address indexed, uint256)` — three topics + 32-byte unindexed data carrying amount. - ERC-721 `Transfer(address indexed, address indexed, uint256 indexed)` — four topics, no unindexed data. Custom events with three indexed args + unindexed data (eg. `Transfer(address indexed, address indexed, address indexed, uint256)`) hit the same selector. The original decoder distinguished only on topic count, so any such custom event got recorded as an ERC-721 with a fabricated `amount = 1` and a token_id taken from whatever the third indexed argument happened to be. That polluted `token_transfers` with false NFT rows and broke balance aggregation on the indexer's `/accounts/{addr}/tokens` endpoint. Per ERC-721 spec the Transfer event has NO unindexed data. Add a data-must-be-empty gate to the ERC-721 path; return `None` if data is present so the row drops out of the index entirely. Real NFT contracts emit empty data and continue to decode correctly. Real custom events with three indexed args fall through silently — the cost is missing them from `token_transfers`, but they weren't meaningfully decoded before either. Adds a regression test (`skips_three_indexed_args_with_nonempty_data`).
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR adds a validation check to the ERC-721 decoding branch in Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Audit M-4 follow-up against #46.
Problem
Transfer selector
0xddf252ad…is shared by ERC-20, ERC-721, AND any customTransfer(addr, addr, addr, uint256)-shaped event. The original decoder distinguished only on topic count, so custom 3-indexed events got recorded as ERC-721 with fabricatedamount = 1and a token_id taken from whatever the third indexed argument was. False NFT rows pollutedtoken_transfersand broke balance aggregation on/accounts/{addr}/tokens.Fix
Per ERC-721 spec the Transfer event has NO unindexed data. Add a data-must-be-empty gate to the ERC-721 path; return
Noneif data is present.Test plan
token_decodetests pass including newskips_three_indexed_args_with_nonempty_datatoken_transfersrows appear for non-NFT contracts emitting 3-indexed eventsSummary by CodeRabbit
Bug Fixes
Tests