Hey TBD folks , Alex here - Product Manager and Governance lead over at cheqd. I stumbled across your incubator announcement today, and well, I think there may be an excellent opportunity for TBD and cheqd to collaborate and build together.
In this thread I will explain how I believe TBD and cheqd to be complimentary, and where cheqd’s Resource Module and Payment functionality could help accelerate the adoption of Web5.
cheqd is a blockchain network that sits at Layer 1 of the ToIP stack. cheqd acts as a Verifiable Data Registry for anchoring DIDs (and resources as discussed further down). cheqd has a native token, CHEQ, for paying for identity writes to the network, as well as being used to facilitate payment rails for Verifiable Credentials (as discussed further down).
There are three main ways cheqd and TBD could benefit from each others’ products and work together:
- Improving existing paradigms for schemas, trust registries and revocation registries;
- Creating Payment Rails to accompany the flow of Verifiable Credentials;
- Striving towards Interop and multi-network support.
I will discuss these three benefits in turn:
One area cheqd has spent a lot of time working in the previous few months is in improving how ‘Resources’ associated with Web5 ecosystems can be stored and retrieved in a more decentralised and resilient way.
Schemas, for example, are generally still stored on schema.org, which although has its merits, is hosted on a web server, which may act as a centralised point of failure for Web5 ecosystems.
Similarly, revocation models such as StatusList2021 use Verifiable Credentials hosted on a central server to store the relevant bitstring for checking Credential status. Again, if this goes down, so does the Web5 ecosystem.
cheqd has pioneered a new approach for storing and referencing Resources associated with Web5 ecosystems in a more resilient way, using the security features of DIDs and extensible DID URLs.
Let’s take a simple DID to explain:
^ This DID resolves to a DID Document, identifying the Verification Method keys used to update/manage the DID.
When creating a resource on cheqd, you must associate a Resource with a ‘Parent’ DID - in a way which organises Resources into Collections, which can be managed using the same Verification Method keys used to update/manage the Parent DID Document.
This is an example of a Resource syntax:
You can click the link below to resolve the DID or the resource itself to fetch the resource or associated metadata.
Via this extension of DIDs, TBD would be able to create more robust and resilient schemas, trust registries and revocation registries as resources, referenced via DID URLs. This could also be used to store visual representations of Verifiable Credentials, like those worked on at OCA. I’d love to discuss this further and explore opportunities to innovate with Resources ft. DID URLs together.
There is a chicken and egg problem in Web5: Large volumes of Verifiable Credentials in circulation will reduce costs for enterprises and incentivise more organisations to issue/consume them. However, prior to large volumes of Verifiable Credentials in circulation, there is little incentive for enterprises to shift their existing data management systems to Web5.
The of the fundamental goals of cheqd is to solve this chicken and egg problem by making it commercially beneficial for issuers to switch to Web5 and begin issuing VCs by providing payment rails to accompany the flows of VCs.
A Verifier may pay a small fee each time they check a revocation status within a VP. This fee gets accumulated and paid back to the issuer in batches (to preserve privacy and prevent correlation). The issuer therefore gets a recurring revenue stream, and the verifier saves costs in doing KYC.
A Holder may pay a small fee to purchase a VC off an issuer. For example, this could be useful for purchasing a digital University degree, or a Digital Drivers’ License. This gives the holder greater sovereignty and control of their data, and provides the Issuer a recurring revenue stream.
A Verifier may pay a Holder a small fee for sharing extra preference data in the form of a VP. The Verifier benefits by getting higher quality data, and the issuer benefits by making profit / taking ownership of their own data.
cheqd’s payment rails could be layered on top of TBDs existing SDK and technical stack. TBD would not even need to use cheqd DIDs, but could continue using the existing DID methods supported. This is because cheqd is building towards a payment gated (and privacy preserving) Revocation Registry, which could be specified when issuing VCs using TBDs existing SDK.
Payments is a huge unknown in the Web5 space, and I would love to explore the potential of discussing this further and expanding on our approach.
In the world of Web5 there will not be 1 network to rule them all. Instead, multiple different networks and technical stacks will need to work simultaneously, a bit like how VISA, Mastercard, Amex etc., can all work seamlessly together using functional middleware.
I am of the opinion, therefore, that TBD should strive to support:
- As many different Layer 1 networks as possible, each maybe with different USPs; and
- As many different Verifiable Credential types and exchange methods as possible.
Through a partnership with cheqd, TBD could, firstly, give its customers another option in terms of the network layer, with benefits such as payment rails.
(The AnonCreds support has been facilitated by being able to store Credential Definitions and AnonCreds Revocation-based accumulators on cheqd via the Resource Module.)
While TBD currently only focusses on the former, it could extend its SDK to support the latter Credential types for clients/customers with more nuanced preferences (such as predicate proofs with AnonCreds, or BBS+ sigs). Having decoupled AnonCreds from Hyperledger Indy, this is no longer as much of a vendor-lock-in problem.
Furthermore, we’d also love to explore the option of using the Decentralised Web Node model with our existing SDKs for storage etc. This could see greater adoption of both cheqd and TBDs product offerings.
I’ve rambled for a while here, but I hope there are some nuggets that resonate with the TBD team. Ultimately, the cheqd team and community would love to explore the possibility of a partnership, alliance or collaboration with what you’re building on Web5 and with DWN. There are many avenues we could go down, so looking forward to hearing your thoughts!