So, a few upfront thoughts…
ERC-721 is a proposed change to the set of technologies included in the Ethereum ecosystem that specifically allows for deeds, or as they are sometimes called non-fungible tokens.
KYC is the general term for laws around the requirement to Know Your Customer. These are widely applied to the financial industry and are used to positively establish the identity of known parties to a financial transaction.
Micro Identities are PKI-based secrets that allow one party in a transaction to assert that they are the same person they were before. There are many potential uses for this as discussed in my blog post here.
The interesting confluence of these technological concepts comes from entitlements, as one possible connection.
In existing ERC-20 or ERC-721 smart contracts, the concept is that you can create an electronic deed that can convey ownership of a real-world asset through custodial management by a trusted intermediary.
As a specific example, there is work being done to sell precious artwork via an auction house via an ERC-721 token. This would allow for a single buyer to interface with the initial auction holder and then the token is transferred to a new buyer electronically. The token holder can then present the token to the auction house for physical redemption.
While this isn’t a meaningful interaction on it’s own, it can be seen how this lowers transaction friction and creates other opportunities for more wide-scale implementation.
So, changing thoughts to an identity problem, the concept of KYC creates a potential trust anchor (a risk anchor with low risk – high trust). If a trusted party follows KYC protocols to positively identify a client with an electronic identity, making that a non-fungible token has specific advantages.
For example, if CoinBase were to get a new user, their first task is to risk rate that user by Coinbase’s knowledge of the user, including a positive authentication of their identity (KYC laws).
Should they be able to tokenize that identity, they could then allow the user to reuse that identity in future transactions, therefore creating a trust anchor and defacto social reputation on the blockchain.
This necessarily extends the ERC-721 payload in a specific way. That is, the deed identifier of a digital asset is self-attested. Meaning that if the custodian says this deed is to a ’68 Falcon with a VIN number ‘5’, then it is up to the custodian to ensure that there is only one deed floating around to that physical asset. If they are the originator of the digital deed, then this may be an acceptable situation. However, if the digital deed is to survive the custodian and truly be transferable, then it must have an identity that also survives a transaction or a custodian.
The best way to accomplish this is to create a PKI Public-Private key pair that is specific to the asset. The public key is included in the deed and the private key is held by the owner. In this way, the holder of the deed (custodian or other) is responsible for transferring the private key when the physical asset is conveyed.
This type of transfer is necessarily off-chain unless it can be encrypted with the recipient’s public key.
Two obvious applications come from this. The first is that our artwork digital asset is created as part of the digitization of the asset and persists throughout the lifetime of the asset. The public key for this would be included in the ERC-721 deed as a method for validation. If the asset were transferred to a custodian, the digital private key would follow the transfer of the physical asset. This allows the ERC-721 NFT to be archived or burned at the conclusion of the custodian’s engagement with the asset, but the physical asset and its digital equivalent would survive and be conveyed to the new owner.
For our second use case, this would refer to the public-private key pair that relates to the KYC identity and could be included in ERC-721 transactions as an account micro-identifier.
In either case, it would make sense for the asset identifier to be available as a DAO that could issue subordinate certificates for specific actionable uses. For example, you wouldn’t include a certificate that you wouldn’t want to not be able to revoke in a transaction.
Thanks to Cody Marx Bailey and Will Entriken for their guidance and work on ERC-721.
Thanks again to Will Entriken for his post on AML/KYC laws that drive solutions like this.