diff --git a/EIPS/eip-721.md b/EIPS/eip-721.md
index c1c96ec4..adab99b9 100644
--- a/EIPS/eip-721.md
+++ b/EIPS/eip-721.md
@@ -241,6 +241,8 @@ This definition is consistent with the fact that ERC-721 contracts track ownersh
 
 The basis of this standard is that every deed is identified by a unique 256-bit unsigned integer within its tracking contract. This ID number MUST NOT change for the life of the contract. The pair `(contract address, deed ID)` will then be a globally unique and fully-qualified identifier for a specific deed within the Ethereum ecosystem. While some contracts may find it convenient to start with ID 0 and simply increment by one for each new NFT, callers MUST NOT assume that ID numbers have any specific pattern to them, and should treat the ID as a "black box". Also note that a deeds MAY become invalid (be destroyed). Please see the enumerations functions for a supported enumeration interface.
 
+The choice of uint256 allows a wide variety of applications because UUIDs and sha3 hashes are directly convertible to uint256.
+
 **Transfer mechanism**
 
 ERC-721 standardizes a two-step process for transferring deeds inspired from [ERC-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md). This requires the sender to approve sending and the receiver to accept approval. In the original ERC-20, this caused a problem when `allowance` was called and then later modified to a different amount, as [disucssed on OpenZeppelin](https://github.com/OpenZeppelin/zeppelin-solidity/issues/438). In this deed standard, there is no allowance because every deed is unique, the quantity is none or one. Therefore we receive the benefits of ERC-20's original design without problems that have been later discovered.