Skip to content

Events don't describe changes clearly#

Informational

Events are used to communicate changes in state to front ends. In this code base we can see a lot of events that do not give clear information on what has changed. In such cases, the front end or a back end service that keeps database up to date, has to figure out what has changed using other methods that make the process more complex.

Example#

Event NewCurator() is emitted when curator is changed. But it does not give information on whom the new curator is. It would be good to add the new curator's address to the event.

There are more events like this one that do not give information on what has changed:

  • ContractUpdate() - no information on what was updated.
  • NewDao() - no information on what the new dao address is.
  • NewAdmin() - no information on what the new admin address is.
  • CanvasCreate(uint256 indexed canvasId) - no information on what kind of canvas was created.
  • CanvasUpdate(uint256 indexed canvasId) - no information on what was updated.
  • CanvasAsset(uint256 indexed canvasId) - no information on what the new asset version is, new thumbnailUri and baseUri.
  • CanvasCreators(uint256 indexed canvasId) - no information on new creators addresses.
  • CanvasRefs(uint256 indexed canvasId) - no information on new refs addresses.
  • OneMinted(address indexed msgSender, uint256 indexed canvasId, Schema.MintRequest indexed quantity, uint256[] selectedTraits) - no information about the cost.
  • ApproveCanvas(uint256 indexed canvasId) - is used when curating and approving. No information on whether it is approved or curated.

Recommendation#

Add information to events, that would enable a back end service to reconstruct the contracts state just by looking at events. In some cases, you can make separate events to represent different changes. For example in createCanvasOne function you could change ContractUpdate event to something like CanvasOneCreated(address canvasOne, address canvasOneCurated).