For theerc721_enumerable_component to work, its logic must be included in the contract, adding sensitive code into mint(), burn(), and re-implementing functions transfer_from() and safe_transfer_from (). The erc721:: enumerable_mintable_burnable preset exemplifies it.
This logic should be insideerc721_enumerable_component, and not exposed to the contract creator. Any changes to that could make the components behave erratically.
Proposed Solution
By using existing SRC5 introspection, erc721_balance_component can understand if the contract is using erc721_enumerable_component or not, and ask it to do what it has to do inside transfer_from() and safe_transfer_from (). Contracts that do not require this component should still include them, but not expose its functions.
Enable SRC5 introspection on all ERC-721 components.
Include the enumerable component on all components that access erc721_balance_component.
Include the enumerable component on all contracts, even the ones that do not use it, like presets::erc721::mintable_burnable.cairo. Enumerable functions must not be embedded on these contracts.
Add initialise() function to erc721_enumerable_component, calling sr5.register_interface(IERC721_ENUMERABLE_ID). Contracts that make use of erc721_enumerable_component need to call that function at construction time.
Add after_transfer() function to erc721_enumerable_component, with the logic currently at the preset, updating its models accordingly.
Check if the contract makes use of erc721_enumerable_component by calling sr5.supports_interface(IERC721_ENUMERABLE_ID), and call erc721_enumerable_component::after_transfer() if it does.
Remove internal calls from the erc721:: enumerable_mintable_burnable preset.
Remove transfer_from() and safe_transfer_from () from the erc721:: enumerable_mintable_burnable preset, and expose the original functions from erc721_balance_component.
Alternatives
Adding before_update() and after_update() hooks to erc721_balance_component, like OpenZeppelin does. but implementing that inside another component is not possible, and should be included inside the token contract, which takes us back to the original problem we're trying to solve.
Related Code
No response
Additional context
No response
If the feature is accepted, would you be willing to contribute it?
Feature Request
For the
erc721_enumerable_component
to work, its logic must be included in the contract, adding sensitive code intomint()
,burn()
, and re-implementing functionstransfer_from()
andsafe_transfer_from ()
. Theerc721:: enumerable_mintable_burnable
preset exemplifies it.This logic should be inside
erc721_enumerable_component
, and not exposed to the contract creator. Any changes to that could make the components behave erratically.Proposed Solution
By using existing SRC5 introspection,
erc721_balance_component
can understand if the contract is usingerc721_enumerable_component
or not, and ask it to do what it has to do insidetransfer_from()
andsafe_transfer_from ()
. Contracts that do not require this component should still include them, but not expose its functions.erc721_balance_component
.presets::erc721::mintable_burnable.cairo
. Enumerable functions must not be embedded on these contracts.initialise()
function toerc721_enumerable_component
, callingsr5.register_interface(IERC721_ENUMERABLE_ID)
. Contracts that make use oferc721_enumerable_component
need to call that function at construction time.after_transfer()
function toerc721_enumerable_component
, with the logic currently at the preset, updating its models accordingly.erc721_enumerable_component
by callingsr5.supports_interface(IERC721_ENUMERABLE_ID)
, and callerc721_enumerable_component::after_transfer()
if it does.erc721:: enumerable_mintable_burnable
preset.transfer_from()
andsafe_transfer_from ()
from theerc721:: enumerable_mintable_burnable
preset, and expose the original functions fromerc721_balance_component
.Alternatives
Adding
before_update()
andafter_update()
hooks toerc721_balance_component
, like OpenZeppelin does. but implementing that inside another component is not possible, and should be included inside the token contract, which takes us back to the original problem we're trying to solve.Related Code
No response
Additional context
No response
If the feature is accepted, would you be willing to contribute it?