You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
3 of our Registries have arrays to keep track of the number of items they registered.
While this can be useful to easily get the number of items they registered, this data can easily be accessed off chain via the subgraph.
Also, this can lead to "Gas-Griefing Vulnerability" in some cases.
Tasks
While we can't just delete the variable itself (the Registries being Upgradeable), we should keep the variables but stop using them (pushing into the arrays, reading from the arrays, deleting from the array, etc.)
Stop supporting the moduleAddresses array in the ModuleRegistry
Stop supporting the portalAddresses array in the PortalRegistry
Stop supporting the schemaIds array in the SchemaRegistry
Change the getModulesNumberfunction of the SDK to rely on the subgraph instead of the contract
Change the getPortalsCountfunction of the SDK to rely on the subgraph instead of the contract
Change the getSchemasNumberfunction of the SDK to rely on the subgraph instead of the contract
The text was updated successfully, but these errors were encountered:
3 of our Registries have arrays to keep track of the number of items they registered.
While this can be useful to easily get the number of items they registered, this data can easily be accessed off chain via the subgraph.
Also, this can lead to "Gas-Griefing Vulnerability" in some cases.
Tasks
While we can't just delete the variable itself (the Registries being Upgradeable), we should keep the variables but stop using them (pushing into the arrays, reading from the arrays, deleting from the array, etc.)
moduleAddresses
array in the ModuleRegistryportalAddresses
array in the PortalRegistryschemaIds
array in the SchemaRegistrygetModulesNumber
function of the SDK to rely on the subgraph instead of the contractgetPortalsCount
function of the SDK to rely on the subgraph instead of the contractgetSchemasNumber
function of the SDK to rely on the subgraph instead of the contractThe text was updated successfully, but these errors were encountered: