Skip to content

Poor sequence of actions in updateCanvas#

Low Risk

In Create.sol the updateCanvas function is used to update a canvas. When updating, it stores isImmutable property first, then it reads it from storage to check if it is immutable, and only if it is not, other properties can be updated. This can cause you to lock wrongly configured canvas.

Example#

  1. User A has a canvas with feeBps equal to 100.
  2. He wants to change feeBps to 200 and lock the canvas.
  3. He executes updateCanvas with feeBps = 200 and isImmutable = true.
  4. The isImmutable property gets stored first, therefore the canvas is now immutable.
  5. Because canvas is immutable, feeBps is not saved.

User A locked his canvas, but feeBps is still 100. He can't change feeBps, unless the DAO unlocks his canvas.

Recommendation#

Move part of the code, that changes canvas to immutable, to the end of the function. This way you are locking the canvas after making all the other changes.