Is it possible to create a non transferrable ERC721 token? For whatever reason that some tokens I intend not to be transferrable, could I perhaps implement transfer in such a way that it could read a variable, e.g: require that bool transferable = true when attempting to call transfer?

5 Answers 5


It's just an interface - you are free to implement it in any way you want. People assume the transfer function would transfer the token, but it's up to you to decide if it actually does it. So, yes, you can for example use a boolean to check whether the transfer should be allowed.

  • 1
    Only correction I would make to this answer, for other people reading, is that the ERC721 standard isn't just an interface. There are requirements of the standard which aren't expressed in the function definitions such as when certain functions must throw, and how some of them must behave. See the ERC721 EIP: github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md Jun 9, 2018 at 0:36
  • Strictly speaking, the interface is just the functionality which the interface enforces. It can't enforce functionality such as "should throw if X" as the actual implementation is not there. But, yes, it should behave in a certain way. Jun 11, 2018 at 5:51

Yes. The ERC-721 standard explicitly makes this point.

The transfer and accept functions' documentation only specify conditions when the transaction MUST throw. Your implementation MAY also throw in other situations. This allows implementations to achieve interesting results.

And more specifically, it cites the example:

Read only NFT registry — always throw from unsafeTransfer, transferFrom, approve and setApprovalForAll

Reference https://github.com/ethereum/EIPs/pull/841


Yes, it is possible.

I would first suggest looking into modifiers in Solidity - as I believe that this would be a reasonable approach to solving the problem.

I would also suggest looking at OpenZeppelin's Pausable contract as conceptually this is similar.

One way of achieving this would be to create a new contract that contains a Storage variable to track whether transferring of the token is allowed or not (as you suggested bool transferable), a setter that only allows the Owner to update this and to create a modifier that enforces this guard. You could then have your ERC721 token extend your new contract and add the modifier to the transfer function - and where ever else you feel necessary.


Update: A Non-transferrable ERC721 is now referred to as a Soulbound NFT: https://vitalik.ca/general/2022/01/26/soulbound.html. There are a couple ways to achieve the same transferability goal, and here are a few ways those are accomplished: https://github.com/BrightID/BrightID-Soulbound-NFT/blob/main/contracts/BrightIDSoulbound.sol (DID solution), https://github.com/mouseless-eth/SoulBound-Profile/blob/c9663738dd29b9109677b8a791d36bced231a798/src/SoulBound.sol


Why use ERC-721 if you don't want to be able to transfer the token? That seems to defeat the purpose of using that standard. You can store your own NFTs internally to your contract, you don't have to use ERC-721.

  • The benefit of using a standard is so that it will be compatible with interfaces from other software vendors. That said, per SE customs it would be best if this conversation were comments onto the original question rather an "answer". Dec 4, 2018 at 3:08

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.