Add EIP: Efficient Default Lockable Tokens

[sullof]

We suggest a solution that is applicable in most scenarios, saving gas.

pragma solidity ^0.8.9;

// ERC165 interfaceId 0x6b61a747
interface IERC6982 {
  // 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.
  // Note that emitting a new DefaultLocked event does not affect the lock 
  // status of any tokens for which a Locked event has previously been emitted.
  event DefaultLocked(bool locked);

  // This event MUST be emitted whenever the lock status of a specific token 
  // changes, effectively overriding the default lock status for this token.
  event Locked(uint256 indexed tokenId, bool locked);

  // This function returns the current default lock status for tokens.
  // It reflects the value set by the latest DefaultLocked event.
  function defaultLocked() external view returns (bool);

  // This function returns the lock status of a specific token.
  // If no Locked event has been emitted for a given tokenId, it MUST return 
  // the value that defaultLocked() returns, which represents the default 
  // lock status.
  // This function MUST revert if the token does not exist.
  function locked(uint256 tokenId) external view returns (bool);
}

The primary limit in existing proposal like EIP-5192 is that

1. it has 2 events for Locked and Unlocked, which is not optimal.
   To make a comparison, it's like in the ERC721 instead of Transfer(from, to, id) used for mints, transfers and burns, there were Transfer(from, to, id), Mint(to, id), Burn(from, id), etc.

2. it forces you to emit an event even when the token is minted, causing a waste of gas when a token borns with a status and dies with it.

Take for example most soulbounds and non-transferable badges. They will be locked forever and it does not make sense to emit an extra event for all the tokens.

[eth-bot]

✅ All reviewers have approved.

[poojaranjan]

@sullof
With the allocated time of EIP Editing Office Hour, the editor could review 14/19 PRs added to the agenda. Most likely, the rest of the proposals will be reviewed and merged before the next meeting by one of the editors. If not, we will add them for review to the next agenda.

[SamWilsn]

Looks like you're defining a requirement here:

the DefaultLocked event may

Requirements should go in the specification section.

Plus I believe this is directly contradicting the comment above the DefaultLocked event definition.

[sullof]

Thanks, I will move that requirements it the specification section.

About the apparent contradiction, there are tokens that are locked during the pre-reveal phase and so would emit a DefaultLocked(true) event, that will be unlocked after the reveal. In that case, forcing the contract to emit a Locked(tokenId, false) for every tokenId would go against the primary goal behind this proposal, i.e., saving gas when a locked/unlocked status is applicable to all the tokens. I think that if that happens, emitting a single DefaultLocked(false) event would be better.

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...