This PR aims to be the cutoff for audit-related contract revisions. I've provided comments on each identified issue, and have linked commits (if not included in this PR). A handful of additional minor changes have occurred, and diff checking would be recommended, though these will be addresses in this documentation as well.
Findings
[HIGH] Ownership corruption: Resolved in PR's 1, 7. Note that an incorrect shl was present in ownership retrieval, and resolved as test suite was improved.
[INFO] Conditional functionality for ERC20 and ERC721: Resolved in this PR.
[INFO] Front running approvals: Noted, but have decided not to move forward with this for the time being. We're trying to adhere as closely as possible to existing interface functionality, and are constrained in that regard: not necessarily looking to introduce this given current consensus around approvals. Will likely add this via an extension.
[INFO] Use OpenZeppelin's "@openzeppelin/contracts/interfaces/IERC721Receiver.sol instead of your own lib/ERC721Receiver.sol: Resolved in this PR.
[INFO] Use OpenZeppelin's "@openzeppelin/contracts/interfaces/IERC165.sol instead of your own lib/interfaces/IERC165.sol: Resolved in this PR.
[HIGH ] ERC721 owners should not be whitelisted: Resolved in this PR by adjusting ERC721 balances with whitelisting. Also added self-whitelisting to avoid centralization issues.
[MEDIUM] Whitelisted accounts can receive ERC721 tokens through minting: Resolved in PR 14
[INFO ] Use setters instead of togglers: Postponing for the time being, given extensions should have been out of scope for this audit. Will be addressed at a later date.
[INFO ] Unlimited allowance is undocumented: Resolved with documentation in this PR
[GAS ] Keccak256 constants: Given low volume of permits, we've decided to omit this for clarity
[GAS ] Unchecked loop increments: Resolved in this PR
[HIGH ] Self transfers may incorrectly adjust ERC721 balances
Additional Changes
Some renaming has occurred for clarity, and a couple of view functions have been introduced. Diff checking strongly recommended to ensure nothing is excluded from these audit notes.
ERC404Legacy was added, this is just the implementation used for Pandora.
ERC404U16 was also added, which packs token ids in _owned and the id bank under the assumption that they are less than 65535. This was introduced to optimize storage.
ID pathing has been adjusted such that all id's are prefixed by 1 << 255 to avoid conflicts within integrating protocols.
Introduced conflicting events. While signatures will conflict, this shouldn't be a substantial problem in practice and is easier to integrate around vs entirely new event sigs. It may not be a final solution here, though indexers typically look for a mix of topics + signature when handling these signatures (which in effect already do conflict, just not within the same contract).
@0xacme It seems like the ERC1155 standard is much more suitable for ERC404... It could get rid of the loops in minting operations. May I know why you prefer ERC721?
Audit Revisions
This PR aims to be the cutoff for audit-related contract revisions. I've provided comments on each identified issue, and have linked commits (if not included in this PR). A handful of additional minor changes have occurred, and diff checking would be recommended, though these will be addresses in this documentation as well.
Findings
Additional Changes
Some renaming has occurred for clarity, and a couple of view functions have been introduced. Diff checking strongly recommended to ensure nothing is excluded from these audit notes.
ERC404Legacy was added, this is just the implementation used for Pandora.
ERC404U16 was also added, which packs token ids in _owned and the id bank under the assumption that they are less than 65535. This was introduced to optimize storage.
ID pathing has been adjusted such that all id's are prefixed by 1 << 255 to avoid conflicts within integrating protocols.
Introduced conflicting events. While signatures will conflict, this shouldn't be a substantial problem in practice and is easier to integrate around vs entirely new event sigs. It may not be a final solution here, though indexers typically look for a mix of topics + signature when handling these signatures (which in effect already do conflict, just not within the same contract).