Closed Namaskar-1F64F closed 2 years ago
What would the benefit of this be over inferring this data? We get the same result by reading the IssuerAllowListEnabled and the TokenAllowListEnabled and setting them to the current values on _grantRole handler, or setting default value. This pattern seems a bit weird to me. Last time I talked with peteris he seemed to prefer having minimal events and using contract calls to get any additionally needed data
The graph data is hardcoding that default "true" value in because it's set on the contract. If we have two bond factories and one of the allow lists is set as false by default, the resulting state of the newly deployed bond factory would be incorrectly reflected in the graph.
The graph data is hardcoding that default "true" value in because it's set on the contract. If we have two bond factories and one of the allow lists is set as false by default, the resulting state of the newly deployed bond factory would be incorrectly reflected in the graph.
That's true but issue could also be elevated by reading the value via the grantRole
handler. I'd probably lean towards that.
This could go either way. I'd like to not do this based on my thoughts + peteris + auditors. Please re-open if you feel strongly about adding this!
The state variables
isIssuerAllowListEnabled
andisTokenAllowListEnabled
emit events when they are toggled throughout the bond factories' existence. During contract deployment the values are initialized totrue
, but this change isn't reflected through the eventsIssuerAllowListEnabled
andTokenAllowListEnabled
which usually signal the change. I propose we add the events to the constructor as such.Also, yes "the ability the ability" is a typo included in the current contract 🖌️