ERC-6982: Default Lockable Proposal

[0xCLARITY]

@sullof

  // This event MUST be emitted upon deployment of the contract, establishing 
  // the default lock status for any tokens that will be minted in the future.
  // If the default lock status changes for any reason, this event 
  // MUST be re-emitted to update the default status for all tokens, including the
  // ones already minted.

I think that’s sufficient to clear it up - but I might even go with something like this (but realize this is a minor nit)

  // This event MUST be emitted upon deployment of the contract, 
  // establishing the default lock status for this contract's tokens.
  // If the default lock status changes for any reason, this event 
  // MUST be re-emitted to update the default status for all tokens,
  // including the ones already minted.
  // 

@sullof

About your EIP, you could have posted here your suggestions and we could have worked together on it. I think that it is always a good practice to participate in the existing proposal, instead of making a new one just for a detail. Initially, I asked for changes in the ERC5192, but it was already in final state when I saw it, and than I was forced to start a new one, but if not I would have definitely tried to improve 5192 if it was not finalized.

Makes sense - I wasn’t sure what the best practice was here. Since this proposal is incompatible with ERC-5192 though, I do think it might still make sense to have a separate proposal that merely extends that, especially since 5192 has some adoption already (supported by OpenSea).

@sullof

interface ERC7558 is ERC6982 {
  event RangeLocked(uint256 _fromTokenId, uint256 _toTokenId, boolean locked);
}

You proposed this in the other thread - but perhaps it should be a part of the core ERC-6982 proposal? I think having all of [defaultStatus, individualTokenStatus, tokenRange] would make this proposal even more flexible.