preapprove v1.0.0

PreApprove

On-chain registry for pre-approvals of ERC721 transfers.

Useful for pre-approving contracts in your dApp ecosystem to manage NFTs without individual approvals.

Deployments

Please open an issue if you need help to deploy to an EVM chain of your choice.

Contracts

src
├─ PreApproveChecker.sol — "Library for querying the pre-approve registry efficiently"
├─ PreApproveLister.sol — "Ownable lister contract that can add/remove operators"
├─ PreApproveListerFactory.sol — "Factory to deploy lister contracts"
├─ PreApproveRegistry.sol — "The pre-approve registry"
├─ example
│  └─ ExampleERC721A.sol — "ERC721A example"
└─ utils
   └─ EnumerableAddressSetMap.sol — "Library for mapping of enumerable sets"

Examples

Installation

You can use the src/PreApproveChecker.sol library in your NFT contracts to query the registry efficiently.

To install with Foundry:

forge install vectorized/preapprove

To install with Hardhat or Truffle:

npm install preapprove

Glossary

• Collectors

  NFT collectors.

• Operators

  Externally Owned Accounts (EOAs) or Smart Contracts that can manage NFTs on behalf of collectors.

• Listers

  Externally Owned Accounts (EOAs) or Smart Contracts that can add or remove operators.
  Collectors can subscribe to listers.

• NFT Contracts

  ERC721 or ERC1155 compliant contracts that can override
  isApprovedForAll(address collector, address operator) to consult the registry,
  returning true if the operator is pre-approved by the specified lister which the collector is subscribed to.

• Registry

  The PreApproveRegistry which can allow collectors to subscribe to listers, and listers to add/remove operators.

Security

• Collectors can subscribe and unsubscribe to listers. Subscription is opt-in.

  • The NFT contract developer has to specify which lister on the registry is queried by the NFT contract.
    We recommend that the lister address is hardcoded as a constant in the NFT contract's code, for security (if the lister is created via our factory) and gas efficiency.

• A lister can add operators, but takes 7 days to take effect.

• A lister can remove operators immediately anytime, even if the operator is not yet in effect.

• The list of operators managed by a lister can only be modified by the lister.

• A lister can be an EOA or a smart contract.

  We highly recommend using our pre-approve lister factory to create a lister contract with the following security benefits:

  • Ability for a separate locker address to lock the lister anytime, in case the lister's owner is compromised.

  • Once locked:

    • No more operators can be added by the lister's owner.
    • The list of operators can be emptied immediately by any account (flight back to default safety).

  • We highly recommend using a multisig for the lister's owner, and an EOA for the lister's locker.
    This is because a multisig's signers may be changed immediately if it is compromised.
    The locker EOA should not be part of the lister's owner multisig.

  • A backup locker is configurable by the lister's owner in case the locker cannot be accessed (e.g. private key lost).
    We recommend setting it up as soon as the lister contract is deployed, if possible.

  • The lister's owner, locker, backup locker, cannot be changed once initialized.

Safety

The codebase has gone though intensive internal reviews by a16z crypto and soundxyz engineers.

Nevertheless, this codebase is provided on an "as is" and "as available" basis.

We do not give any warranties and will not be liable for any loss incurred through any use of this codebase.

Acknowledgements

This repository is inspired by and directly modified from:

• Seaport
• ClosedSea