Comparing Implementation of NFTs and Verifiable Credentials in Calaxy

7 min readOct 22, 2021

Authored by: Paul Madsen, Head of Identity

Introduction

Non-fungible Tokens (NFTs) and Verifiable Credentials (VCs) are emerging as key components of the Web3 architecture. As they share a number of similarities there is sometimes a tendency to force-fit the application of one into a use case better served by the other. This post will explore the similarities between NFTs and VCs, argue how they are designed for fundamentally different use cases, and will explain how the Calaxy architecture will use both.

Overview

Non-Fungible Tokens

A non-fungible token is a unique piece of data stored on a DLT or blockchain. Critically, one NFT is not directly interchangeable or equivalent with another (unlike a fungible token like a currency). An NFT can represent the ownership of digital assets like photos, videos and audio, as well as real world physical objects like rare shoes, a painting, or office building. The ownership (both current and history) of an NFT is tracked on a (typically) public DLT.

Verifiable Credentials

Verifiable Credentials are a W3C standard for digital assertions or credentials. VCs allow one entity to assert identity attributes (such as citizenship, age, etc) of another entity in a tamper proof and verifiable manner. The subject of the VC chooses when and to what other parties those credentials are presented and is able to securely prove to those parties that they are indeed the Subject of the VC.

Similarities

NFTs and VCs share the following similarities

Both provide support to an entity making the claim ‘I own X’ and allow that claim to be cryptographically verified. Specifically, ownership is demonstrated by proof of knowledge of a particular private key.
Both enable a degree of disintermediation — a NFT is tracked on a public DLT, with no single party acting as gatekeeper for approving or censoring transactions. While a VC may be issued by a centralized authority, they do not control nor dictate (nor even have visibility into) when and where the VC is used.
Both may be ‘stored’ in a mobile wallet application. Specifically, the mobile wallet stores a private key by which the right to lay claim to an NFT or a VC is demonstrated by a digital signature. Wallets also typically provide a UI by which NFTs and VCs can be viewed and managed.
Both are ‘standardized’, ERC-721 describe how to build NFTs on Ethereum and the template and model for creating and interacting with NFTs has been copied on other platforms. VCs are undergoing more formal standardization in the W3C.
Both are issued by some entity that is in some sense ‘authoritative’. As an example, Leonardo da Vinci would be authoritative to issue an NFT for the Mona Lisa as he painted it. Similarly, only the Government of Canada is allowed to issue a VC attesting to the citizenship of Canadians. Both NFTs and VCs can be issued by non-authoritative entities, but it is unlikely that they would be accepted by others.

Differences

Notwithstanding the similarities listed above, NFTs and VCs are fundamentally very different.

Ownership

An NFT attests to an entity owning some scarce resource — an NFT belongs to an entity.
A VC attests to an entity owning some identity attribute or characteristic — a VC describes an entity.

Proof of ownership

For an NFT, proof of ownership is demonstrated by a signature applied to a transaction submitted to a DLT. The nodes of the chain verify that signature in order to authorize the transaction.
For a VC, proof of ownership is demonstrated by a signature applied to some challenge string created by the party to whom the VC is being presented. That party verifies the signature (possibly using a DLT to lookup up the relevant metadata, such as public keys).

Relevance of DLT

An NFT by definition? requires a DLT to track ownership and transfers. An NFT is stored on a (typically) public DLT. Anyone can in principle view an NFT and determine what account owns it, even if not necessarily being able to determine the real world identity of that owner. The history of that NFT, when it was created, the list of previous owners, is also visible. Note that the metadata for an NFT may be stored off-chain, for instance in Filecoin or IPFS, but the NFT itself lives on the DLT.
A VC can leverage a DLT to facilitate verification by timestamping key lifecycle moments (e.g. issuance, revocation, etc) but VCs do not presume a DLT. A VC is typically stored locally by the entity it describes and was issued to — the VC’s Subject. While it would be possible to store a VC on a DLT, it would generally be non-optimal from a privacy PoV (even if the DLT were private).

Trust

Entities can trust an NFT because they have confidence in a) crypto b) the collective DLT and the consensus protocol on which it runs c) the account owner’s private key was not compromised.
Entities can trust a VC because they have confidence in a) crypto b) the Issuer c) the Subject’s private key was not compromised.

Economics

For NFTs, there is an expectation of a market and opportunity for sale.
There is no comparable economic model for VCs, ie no expectation that the value will go up or that the VC could be transferred beyond the entity to whom it was issued. On the other hand, it may well be the case that the issuance or presentation of a VC has an associated cost and payment but that is external to the VC.

Scarcity

As an NFT represents value, the more scarce an NFT, generally the greater its value.
As a VC represents the identity of an entity, its value is intrinsic and not dependent on scarcity.

Custody

An NFT can be either custodial or non-custodial. In the latter model, some other entity such as a crypto exchange controls the private key by which the NFT is managed or sold.
A defining characteristic of VCs is that the user controls the private key by which ownership of the VC is demonstrated. While a Subject of a VC could delegate the authorization to present to some other entity (e.g. a CEO delegating certain signing rights to an executive assistant), this would be best achieved by explicit delegation and not merely sharing the VC’s private key.

Royalties

NFTs can support a royalty model by which the original issuer of an NFT can earn revenue from future secondary transfers.
The W3C VC standard does not support the semantic of royalties, specifically what it means for a VC to be passed beyond the original entity to whom it was presented. More fundamentally, any fee or charge for the issuance or presentation of a VC manifests at some other layer in the application architecture.

Calaxy implementation

Calaxy will implement both NFTs and VCs in our architecture.

NFTs will be used in the Calaxy architecture to represent collectibles — unique assets that are provably scarce. A collectible NFTs can be created by any Creator from any third-party application, or directly on the Hedera network, via the Hedera Token Service (HTS).

Nb: there are of course much broader opportunities for NFTs in the wider Creator Galaxy. NFTs can be used to represent music, physical goods, and even specific events such as a fan attending a sports game.

Calaxy will use VCs within the architecture to represent and capture the identity attributes of participants, e.g. creators, fans and applications such that all participants can be confident of the authenticity of each other.

The following scenario illustrates the above. A musician Creator will be performing at a licensed event. The Creator has set aside a front-row seat and made it available to their fans on Calaxy for 100 of their Creator tokens. Afterwards the fan that purchases the seat is offered the opportunity to receive an NFT for the song list for that concert.

Below is a representative model by which the use case is supported by Calaxy and the wider ecosystem

A FT for the Creator Social Token. When a Creator joins Calaxy, a social token is minted by them. The supply of this token going forward will depend on deposits of a stablecoin. It is by owning some specified number of this social token that fans would be able to purchase interactions with the Creator. The Creator will control the prices (in their own social token) for different engagements.
A VC for an attestation to the Creator’s legitimacy. The fan will want to be confident that this is the real Creator they will be listening to and not some impostor. It would be inappropriate for the Creator to transfer this VC to someone else (though it might be useful for a Creator to be able to issue new VCs to their influencer peers).
An NFT for the ticket to the concert. It should be possible for the fan to sell that ticket should they choose to not attend the concert.
A VC for a proof of age for the fan as alcohol will be served at the concert. It is inappropriate for the fan to be able to transfer this VC to someone else.
The fan can choose to purchase an NFT for the song list collectible.

Conclusion

It would be possible to use an NFT to capture a Creators’s qualifications, e.g. that they have 3M TikTok followers etc. Similarly, it would be possible to use a VC to describe a professional athlete’s game worn jersey. But neither would be using the technologies for the use cases for which they were designed.

Fundamentally, NFTs are optimized for recording ownership and transfer of value. VCs are optimized for recording ownership and presentation of identity attributes. Calaxy will implement both NFTs and VCs as they were designed — NFTs to track ownership of assets for which transfer is appropriate, and VCs to track ownership of identity attributes.

But there are also opportunities within Calaxy for integrating and combining the worlds of NFTs and VCs (and the wider decentralized identity standards).

We’ll explore those scenarios in the next post.