When adding a new attester to the attester array by calling addAttester()
, it is not ensured that the attesters are “in order”. This will result in a revert of the function “createAccount()” when the registry function “trustAttesters()” is called. The result will be that no new accounts can be created with the RegistryFactory.
The RegistryFactory is used to create new Smart Accounts. Users can add specific modules to such a Smart Account to e.g. automate specific task. For a module to be addable to a Smart Account, it needs to be seen as “trusted” in a registry. For a module to be “trusted” it needs to have enough attestations from specific attesters in the registry. The factory determines which attesters are considered and how many attestations are needed.
The registry used to check if a module is trusted or not will follow ERC-7484 for maximal compatibility.
When the factory creates a new Smart Account, it first checks if the modules are trusted in the registry and adds all modules to the account. As a final step, the registry for the account is set and the array of attesters as well as the number of needed attestations is saved in the registry by calling registry.trustAttesters(threshold, attesters);
.
According to ERC-7484, when calling trustAttesters
, the provided array of attesters “MUST be unique and sorted and the Registry MUST revert if they are not.”
The issue arises from the fact that when the owner of the RegistryFactory
calls addAttester()
, the new attester is just pushed to the end of the array, thereby (in most cases) breaking the sorted nature of the attesters array.
Since the array is used to call registry.trustAttesters(threshold, attesters);
, this function call will revert (because the array is not sorted) and will thereby prevent any new Smart Account from being created.
Make sure, when adding a new asserter to the asserter list, that the array is still sorted afterwards. This can be for example done by taking the existing attesters array, determining at which position the new attester should be added and “pushing” all attesters one slot further.
Invalid, similar issue to #151 and duplicates - Addition of attesters are admin only functionalities so if duplicate addresses are added it would consitute admin input/call validation. - ERC-7484 is in draft mode so we should not take it as the final EIP configuration yet. - In the [documentation](https://github.com/bcnmy/nexus/wiki#problems-nexus-solves), it is not noted that Nexus suite will be ERC7484 compliant.
Invalid, similar issue to #151 and duplicates - Addition of attesters are admin only functionalities so if duplicate addresses are added it would consitute admin input/call validation. - ERC-7484 is in draft mode so we should not take it as the final EIP configuration yet. - In the [documentation](https://github.com/bcnmy/nexus/wiki#problems-nexus-solves), it is not noted that Nexus suite will be ERC7484 compliant.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.