Update EIP-6956: Move to Review #7903
Conversation
github-actions
bot
added
c-status
File
|
The removed "Security Considerations for DIGITAL ASSETS" section was a leftover and TODO-comments referred aspects already mentioned in other sections.
tbergmueller
force-pushed
the
erc6956_review
branch
from
e1e3b2b
to
c7f7789
Compare
|
The commit e1e3b2b (as a parent of a0aeda4) contains errors. |
|
Cleaned and ready |
|
I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually. As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process. If there is relevant history here, please link to this PR from the new pull request. On behalf of the EIP Editors, I apologize for this inconvenience. |
Corresponds to ethereum/EIPs#7903 - Remove links to draft/stagnant EIPs - Add recommendation for lockable() interface - Move to Review
Corresponds to ethereum/EIPs#7903 - Remove links to draft/stagnant EIPs - Add recommendation for lockable() interface - Move to Review
|
No worries, Pull request in ERCs repo: ethereum/ERCs#43 |
Corresponds to ethereum/EIPs#7903 - Remove links to draft/stagnant EIPs - Add recommendation for lockable() interface - Move to Review
The EIP is implemented and used for several months now. As far as we know mainly for customers of ours though and projects we're involved in.
Nonetheless, the draft can be considered stable and has also been reviewed by members of https://www.swissdao.space/
In this review no major or critical technical issues or vulnerabilites have been raised, but it has been recommended to simplify the EIP.
In review stage we intend to discuss the possibility of making the
anchor <> tokenIdmapping optional, which would reduce complexity and also reduce gas-fees.Besides Events, a backwards-compatible solution without this mapping should be possible enabling already existing contracts to still be supported. Not strictly in the ERC-165 sense, but uint256 (tokenId) and bytes32 (anchor) can technically be interchanged. This is possible by "just" using anchors as tokenIDs.
This merge-request: