I just finished this article on the Open Zeppelin ERC721 token implementation:


I about to start implementing. The article states that the ERC721 token works with external contracts that handle the spend logic and the address for that "agent" contract ends up in the main contract's "allowed" map. If I understand things correctly, the ERC721 token acts as the managing entity for token ownership record-keeping and facilitating the integrity of token transfer and allowances.

So, should I assume that logic for whether or not a token is transferred (e.g. - a sale, or escrow release, etc.) should reside in an external contract instead of deriving a new contract from one of the ERC721 contracts and putting that logic in the body of the derived contract? If so, is there an Open Zeppelin contract that I should look at and use either as a template for my external "agent" contract that I should derive that contract from?

My situation, at least for now, is very simple where the price for a token is fixed and once the buyer pays for it, the token should be transferred from the current owner (the seller) to the buyer. The one major nuance I will need to handle is whether or not the buyer wants to put the token up for sale. If not, it should not be sellable to anyone until the current owner decides to put it up for sale.

1 Answer 1


Simple architecture design:


  • Implements ERC-721
  • Handles transfers
  • Handles security
  • Defines situations in which transfers are "turned on" or "turned off"


  • Takes custody of tokens
  • Implements escrow scenarios
  • Takes custody of vendable tokens and sells them*

In some architectures, for example Su Squares, the * item is implemented in the original first party NFT contract.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.