Hello, hello, hello, hello, hello, everyone.
This is Pankaj from Hypersign. Welcome to these spaces on state of ID management in
web3. Exciting time for Hypersign. We have just launched our testnet, the final
version of our testnet a week back. Some of the things that are there in this testnet
are we have launched, what do you say, support for Kepler, Metamask, added
cryptographic keys like baby jab jab for zero knowledge, what do you say,
capabilities, we have launched a SSI API playground for developers to try out the
product, launch their own identity products, and also a command line interface
to quickly turn around your own notes and try out the product. So that's something
that is happening at Hypersign. Exciting times for us at Hypersign's mainnet is
getting closer and closer. This is the final version of the testnet that we have
launched. And we today, right now, the identity is the main topic in web3.
Recently, I was reading an article on CoinDesk, which said that CFTC has asked US
policymakers to focus on identity in the DeFi space. So very exciting time for this
panel and all the crazy projects that are being built in the ID space right now.
Today with us, we have three founders who are building in this space, and also
founders who are using identity in, what do you say, different use cases like
gaming, esports, decentralizing, esports. And obviously, so let me just quickly brief
you guys on who all is there on the panel. We have Simon, who's founder of DSID or
Digital Social ID. We have Evan, who's founder of disco. Then we have Vikram,
obviously, that everyone knows in this panel is from Hypersign and Dibio, who's
founder of TURF and also Siddharth, who's founder of Comdex. Comdex, you know, from
the very beginning started as a decentralized exchange. And today, they are
building basically, they provide DeFi infrastructure for projects to launch
different kind of, what do you say, different use cases of DeFi can be
launched on Cosmos chain with help of Comdex. Dibio working on permissionless
hosting of esports, and then we have remaining three working in the identity
space. So I'll not take much of your time. I would ask each of the founders to
come on, what do you say, unmute themselves and just what do you say,
introduce yourself and tell us a little bit about what's happening in your
companies and how's it going? Maybe with Siddharth, we can start with you.
Hey, hi, everyone. Thanks for having me on the panel. Happy to be here. Happy to be
a part of this discussion. I think, you know, very, very interesting state of the
industry where we are at and the use cases for decentralized identities is
surely on the up and exciting times. So just a quick introduction on Comdex. I
think you covered it quite well. Comdex is a DeFi infrastructure layer.
Interestingly enough, we actually started our journey in Comdex 2019,
building out a platform for tokenizing real world assets and facilitating their
exchange and financing. Of course, eventually we realized the size of
the task ahead and started focusing on the infrastructure layer and that's how
we became the infrastructure layer first before we, you know, went fully into
building any RWA focused app. But right now, you know, the Comdex chain has a
suite of DeFi modules that anyone can utilize to launch DeFi protocols
within Cosmos. And this year, we're looking forward to launching, you know, a
few RWA focused products ourselves and having a few RWA teams work with us as
well. And yes, and you know, decentralized identity is going to have a huge role
to play in linking on-chain economies with real world assets that we will
eventually get on board on-chain as well. So yeah, excited for the discussion today
and then looking forward to it.
Awesome. Should I take over maybe? Or actually Evan? Usually it's ladies first.
Maybe let's go to Evan first.
Oh, it's Evan. Such a riot as always.
I'm happy to jump in. Thank you so much for having me today.
Really excited as ever to have the opportunity to chat with these fellow builders.
My name is Evan and I lead the team over at disco.xyz where we believe that you
are the multifaceted center of the party just as you are.
And you should reflect your identity and your data to the world however you decide.
And so as Siddharth was saying, our team similarly started off very deep in the
stack more in a protocol or close to the protocol farm.
And as the infrastructure layer, we had to build out stability and throughput such
that we could accommodate more data than most blockchains are able to process in
any given period of time. However, we also needed to determine exactly how
our builders would interact with these new forms of data.
So I think all of us are probably sharing in the experience of reaching up the stack
to support other teams who are in dire need of more data than just token holdings.
And so at disco, we care very deeply about ensuring that personalization of dApps,
that experiences built around you are able to be informed by more than simply
what tokens are mapped to a given public key, such that we can coordinate
more than simple treasury allocation, which is all we can do without identity data.
Nice. Simon, you want to go next?
Sure. Yeah. So thank you for having me. I'm excited to be here as well.
So I'm Simon. I'm co-founder of DSID or digital social ID.
And that's pretty much what we do. We're trying to help people to build their
digital social self in the Internet. And we're trying to basically make people's
reputation measurable in a meaningful, fair and credible, neutral way.
And we're trying to use crypto incentives and crypto basically coordination games
that we can build with this new tool set that we have to build this reputation
that is fair and that actually brings cool and fun use cases for users
where they can leverage their reputation. And at the same time,
we can help the app and we can help projects to make better decisions for their users
while onboarding them or while putting them through their user flows.
So it is a win-win situation. And you can actually attach another win at the end
because DSID obviously is facilitating all this fun stuff.
And we're growing as our ecosystem grows. So yeah, excited to be here
and excited to chat about those topics around reputation and identity.
We'll talk more about it. Dibyou, you want to quickly introduce yourself before we start?
Yeah, sure. Hi, everyone. This is Dibyou. I'm the founder of Dove.
We are an on-demand esports facilitation network to permissionlessly host, manage
and enable participation in esports and micro competitions worldwide.
So basically, we are solving for the gaming industry, making games more
engageable and having more user attention.
That's where we have been seeing like, hey, this gaming industry is very much unstructured.
And at the same time, we see that there is no collision of all the gamers in one place
where they can see what is the proficiency of the other game.
So that's where there is a huge role of ID that we also have derived,
like we are curating our gamers portfolio. That is a global gamers portfolio
where people can curate their profile, share their in-game skills, share their achievements
and at the same time, play a lot of competitions in our platform
and be a part of the gamers economy. So that's a bit of what we are doing at Dove
Nice, nice, nice. What do you say?
With governments pushing for identity in, what do you say, web3 space,
it is inevitable that it is going to happen.
And we as, what do you say, DeFi users or blockchain users have to realize that,
what do you say, regulation and surveillance are two different concepts, right?
Regulation necessarily doesn't mean surveillance.
But for wider adoption of DeFi, some sort of identity has to come into play in this space, right?
We, like me, Vikram, we keep talking about it many a times in our team meetings
and Vikram had some interesting questions for this panel since everyone
is working somehow around identity space and especially in the web3, what do you say, industry.
So, Vikram, why don't you shoot your questions to all the, what do you say,
interesting panelists that we have today?
Hey, Pankaj, thank you very much.
And first of all, thank you everyone for taking time out
and coming out for this panel.
I really appreciate, like, all of us are in different time zones,
but we were able to somehow, you know, find a time together to come and talk to us.
I don't want to make this panel into a structured one.
Basically, my goal was to have just, you know, open conversation,
but I really want to have it in a way that, you know, even though, like,
there are protocols and applications being built in different layers around the ID and credentials,
but it still has, you know, very less information among the developers.
Probably it could be because of the standards that we are using,
which is not yet, you know, widely adopted or could be something else.
So, as founder in the same space, do you guys also have this challenge in,
you know, educating your customers or your users that why is, you know,
DIDs and credentials required or you think that is not a challenge anymore?
So, this is one question I would love to, you know, start our conversation with.
Anyone can, it should be like, please feel free to pick up the question.
Yeah, Simon, please go ahead.
Let's make it short. I want to give the other sort, so the opportunity to speak,
but what I can say from my conversations with other fellow builders in the ID space,
but also all the discovery calls we do with potential customers that could integrate advanced
identification flows basically for onboarding based on decentralized identity,
is that A, they all, like the customers, obviously, usually want to actually either
save some money on a certain point or make more of it, right?
So, if you can help them make more money or save money with the ID that you're building
or the ID tech that you're building, then that's a quick win, right?
I talked to one project, they do KYC, on-chain KYC,
and they're so desperate because the customers, they say the apps need on-chain KYC,
regulation is coming, if they don't act now, they will have a problem and nobody wants it.
But then they started to introduce a revenue share model.
So, if you implement our on-chain KYC solution, that WhatsApp, their sales pitch,
I'm going to share revenues with you that we make,
which has nothing to do with the initial KYC offer, right?
And then customers were interested.
So, what we learned from it, exactly what I said earlier,
we need to kind of find the right incentives for them to implement this tech
and then it makes sense for them.
Evan, maybe you would want to add something on it and then the video after you.
So, in my experience, I would say probably two years ago,
the identity conversation in Web3 was much more niche.
There were certainly a global and thriving community of us,
but largely focused on nerding out on standards and protocol layer capabilities
and building out the basic primitives that we know and enjoy today.
So, some of the amazing teammates who I work with invented things like
smart contract wallets, social recovery, key rotation with a persistent public identifier
and the ability to manage the delegation of multiple keys using a smart contract.
Now, back in the day when that was first introduced, 2017 or so,
gas was so prohibitively expensive and developer tooling was so rare
that it really wasn't feasible.
And so, we moved toward EOA wallets.
However, we have now as an ecosystem marched back toward the smart contract
with the need for more sophisticated types of keys and more capabilities.
And so, what this conversation, what this journey has meant for me
is that different kinds of education are required at every point in the discussion,
but the user needs, the human needs remain the same.
It's just how we talk about them that has to change.
And so, it's not as though in the last five years human beings have suddenly discovered
that filling out forms is a pain and that they don't enjoy it
or that they have a limited set of things that they're able to do with their keys.
Rather, we need to make it so easy to use solutions that are better than what they're doing today
that the incentive to switch, as Simon was talking about earlier,
the incentives, the sort of switching class incentives make sense
because the user in their new experience will be able to move faster, more cheaply.
They'll be able to enjoy more personalization.
They will be able to save time and indeed, GASP might even enjoy their experience, delight in it.
That experience might even bring them joy.
So, the users who we serve, they were all trained by Tim Cook,
and Web3 applications consistently disappoint their experiences.
So, if we are to build a better way forward that's compelling,
we can't just pay people to come to a party that is lame.
We have to build a party that is so compelling and valuable
that they deliberately wish to walk in the door
because they see what is going to benefit them once they enter.
And we need to make that so obvious and so straightforward,
and I think some teams are doing a great job,
but appealing to the human element where people make decisions with emotion
and justify with logic, that is the skill set, the center of excellence
that I think the identity space can help us all achieve.
I think you put a very valid point that rather than going from the tech and protocol side,
like all those discussions back in the days, it has changed a lot because of,
I guess a lot of people have already understood that,
that it can add value in certain level,
but now it's the time when it can be mass adopted.
And when you are looking at mass adoption,
then we have to talk in the language that the customer would want to listen to
and would feel lesser work to move towards this type of technology.
Divya, you want to add something from the gaming ecosystem specifically from that side?
Yeah, I totally agree with what having just said.
And we have been seeing that too.
My perspective is more from the product side,
where since our audience is basically gamers and gaming business folks,
we have been seeing that,
even if we are talking about DIDs and everything,
they are not in a mode to actually guess that,
even if the gamers are specifically very much tech savvy and adopt things very easily.
So that's where we thought of how we can educate them.
So what we felt like, let's start off with the interface that they like,
that they understand, even if whatever we do in the backend does not matter to them,
But obviously, let's start with the thing that they want,
obviously from the business end as well,
the verification business that we are into.
But they also don't want like, hey, we are using DIDs and all this stuff.
I don't want to delete it right now.
So we started with the simple interface,
and then what we did is the transition.
Now we go to the gamers and say like, hey, now you can take the custody.
This is your specific verified credential,
and this is linked to your third party.
So one of the things that I have seen in this whole journey is like,
not directly showcasing the tech that we have been using,
but actually starting with what they need and what they are up to,
what they understand, and then transitioning them to like,
hey, now you see this is the tech behind this.
Now you can leverage this.
Now you can play around with whatever you want.
So this type of user journey we have seen like,
as impacted and has not caused any issues till now for our production.
So it's, I mean, whatever you said,
Evan actually summarizes really well,
like create a party that they would enjoy,
not to come and have a party together,
but not like get paid to come to that particular party.
So, I mean, it relates so much, honestly,
and I love that analogy, Evan.
Moving on to Siddharth, bro,
you are working mostly around the regulatory sort of side.
And in your product use case,
that I have been following up with you guys for almost like 1.5 years.
But what changed in your team or in your roadmap,
like recently that you guys have started seeing that
there is a requirement of ID verification,
specifically because you are, you know,
So traditionally DeFi projects used to say that
we don't need ID verification,
or we are fine with some sort of on-chain reputation,
but then your protocol moving towards or building products like this.
So what happened in the team internally with the team
and that some demand that you saw in market
or some different type of product lines you had to build
for which you started looking at identity and user verification.
Can you please add on towards and around this?
I think this will be like a slightly longish answer,
but I'll try to keep it as short as possible.
like the name COMDEX itself, what it really stands for is
Commodities Decentralized Exchange
because that was kind of the starting point of our entire journey.
So even before we became the DeFi guys,
we were always the RWA guys.
Like that was the whole reason I entered this whole industry
is because I always thought that this industry has to be
to apply its technology to real world assets
So that was kind of the starting point of our entire journey.
Of course, back in 2017, 2018, and even 2019,
when we were on this journey,
we realized that no matter how much you do
on the building side of things,
the adoption layer is always going to be difficult
because there wasn't much regulatory clarity
around adoption of on-chain assets.
Businesses weren't comfortable holding on-chain assets
and there was no kind of just clarity around
how you kind of declare these assets
So of course, we still believed firmly in our vision
for having real world assets and their financing happen on-chain,
but just realized that 2019, 2020 wasn't the time.
And even if it was the time,
there was no readily available infrastructure
that we could utilize to do this,
especially inside of Cosmos ecosystem.
So what we then started doing
is building the infrastructure layer
that could support all of these use cases.
And what we found is what typically prevails
in traditional finance, the true transactional structures,
they're very common with what you see happen in DeFi as well.
So a lot of the infrastructure we anyways intended to build
for our RWA vision would anyways apply
and have utility in the DeFi space as well.
So come 2021, when the complex chain went live
and we started focusing on all these infrastructure pieces
and the modules on our chain,
we realized that each of these modules
had their own applications in DeFi as well,
and that's why we kind of started applying these modules
to DeFi use cases first before the market was ready
to take on real world assets as a use case.
We're still in touch with the same folks
that we've been in touch with
since the last three or four years.
What we've realized is that regulations are starting to evolve
and become more friendly towards this whole industry,
especially in certain countries like UAE, like Singapore.
Regulations are actually providing you with the kind of clarity
you need to be able to hold on-chain assets
on your balance sheet as a company
and then also transact in these assets within companies.
So that has opened up a huge door for us
to actually start applying a lot of the infrastructure
we have built onto the RWA side of things.
And that's why what seems like a pivot
back to our original journey is really not a pivot,
it's just a continuation of our original journey.
And I think I just want to just point out that
the point that Evan so eloquently put across
a few minutes ago, it kind of all adds together
with especially what Simon said as well,
is that when you kind of apply something like DID
and you're trying to get the end user to actually adopt it,
it has to start with creating value, of course,
and it has to also do it in a way
where it doesn't seem like a cumbersome task to do that.
So from the lens of the industry that we are targeting,
what we realize is that when it comes to something
like having access to capital or having access to financing,
large enterprises are able to do it fairly easily
because they have very well-established credit-worthiness
and identity structures within the traditional finance realm.
But the ones that keep getting left behind
are the small to medium-sized enterprises,
the MSMEs as they're called.
And what we're trying to do is help these MSMEs
create an on-chain record and identity for themselves
so that eventually when they go out in the markets
to access finance and access capital,
this on-chain record serves to build a credit-worthiness
or a credit record for them
so that they have easier access to capital eventually.
So that's why DID plays a very crucial role
in the product that we're building now
and the things we'll be applying it going forward as well.
So I did get summarizing basically more clarity
on the, let's say the market actually help you guys
take the next step towards, you know,
so bringing like the regulated DeFi,
which is basically the next part of Comdex
And that basically the having clarity from overall market
that how this can probably evolve.
So it gave more, you know,
it helped the team to take the decision better.
Now, you know, I heard what Evan said,
Simon, Deepio and you all,
like two things, summarizing again,
like one is that what value we can add to the customers
And the second one, how easy it is to,
for a dev team to move their existing protocols
or applications into this new type of ID system.
Now, I want to connect my next question around this.
Now, let's say that we have decided,
okay, we want to go ahead and we want to go ahead,
you know, and implement DID.
So the business has already taken a decision
to implement some sort of ID verification on chain
and also have taken decision probably
that they might go the ID way
or some sort of ID verification way
which has to work on chain, right?
Now, my next question is like
when you guys are talking to your customer
or when you are actually building for them.
So do you actually only have a focus
on the ID and verifiable credential using that
you have to solve or you take it as a whole,
as a problem statement and then fit in,
you know, the right ingredient to basically cook the meal
or, you know, the cook the right solution for them.
So if you guys, anyone want to, you know, jump on
onto this and talk a little bit about that.
So, I mean, specifically what I'm trying to ask
is that our customers actually asking,
having problem with using DID and credential standard
or they are like, they are asking you to,
you know, you are free to choose
what you are using internally as a standard.
We just want the solution.
Because I keep on seeing this war,
SVT versus verifiable credential on Twitter.
Maybe I am very naive and I'm not understanding it internally
that this is just a funny meme,
but could possibly, you know,
affect the decision of, you know, protocols and projects.
Yeah. So Simon, you have raised hand.
Maybe Evan can add and others are also, please jump in.
So Vikram, I mean, it's a good question
and I think I'm, to some extent,
I'm a good person to answer this
and to another extent, I'm not.
Let's start with why I'm a good person to answer it.
We used to build using SVTs, right?
Like we started our journey very early on
using Sorbonne tokens as basically on-chain identifier
for your reputation data, right?
That was the initial pitch.
But I mean, you quickly realized that Sorbonne tokens
and that's not a secret anymore, especially not amongst us.
They are fairly limited to what you can do with them.
They're always on-chain, they're always public.
Is an SPT really the best vehicle for identity data?
I think we started to all agree that they're not really
are the best vehicle for that.
But that's one thing to the story.
The second thing to the story is standardization
and adoption of technology standards.
And if you want to build a scalable product
that is going to be implemented in many different kind
of applications from customers,
you need to be kind of compliant with what they understand.
And I think Sorbonne tokens is a big bet, you know,
to bet on them being accepted.
Especially, here's the point,
especially if you're targeting Web2 or traditional businesses,
then you can forget that at all, in my opinion.
VCs and Dits, you can build a narrative around that.
And I think we're on a path to finding
better standardization there.
A lot of work has been done to find standardization.
So the path here is more clear, right?
That's why I think if you're targeting Web2 customers
or customers who use traditional internet technology
as their infrastructure, the VC ended way is a good way to go.
Now, last thing I want to say,
DSID is not only focused or it's actually,
from a priority point of view, more focused on DApps.
So we want to have DApps to build better identification systems
and more advanced authentication flows
than a simple wallet lock-in.
You know, like, this is my public key, let me in,
and now let me use the app, great.
But I think in future we have a more customized authentication flow
For them, we can be more creative.
A, because they're new, they are more adaptive.
So here we can come around the corner with SPTs,
attestations, verify the credentials, and see what fits.
You know, I'd experiment a little bit more.
If it's off chain, if it's additional businesses,
I tend to agree that VCs and DIDs is probably the way to go.
I'll stop here and I'll give the mic to Evan.
it is easier to talk to enterprises and governments about DIDs and VCs
than it is to talk to them about crypto at all.
So there are already more than 2 billion verifiable credentials
in enterprise circulation today,
governing everything from access control
to the heavy machinery repair yard at National Railway Service
to enabling citizens in the United States
to carry their green cards around on their mobile devices
and be able to represent the status of their citizenship.
the crypto space is actually behind the ball.
It was not a good look that a lot of the enthusiasm
and primitive development around soulbound tokens
actually included incorrect information,
misinformed information about credentials
because folks didn't bother to read the standard.
And so sometimes I think our ecosystems enthusiasm
to sell block space as the primary economic driver of our existence
can get a little distracted
because sometimes we opt for choices that sell block space
but are suboptimal when it comes to reusing that data later.
So as Simon was talking about,
identity solutions that trap your data to a single chain
and make it very difficult or expensive
to move from one place to another
don't work well because human beings
are not bound to a single protocol.
And so it is through the pragmatism of these solutions,
understanding what business outcome needs to be made available
and then backing into the best tools for the job
as opposed to starting off with the need to sell block space
as a requirement for the solution.
I think this is where we can run into an impasse
between more traditional enterprise objectives
and the need for decentralization
to be a primary driver of the ecosystem
even when it might be a suboptimal way to store and manage data
that shouldn't be decentralized
because it is centralized to the party it was written about
and should be centralized logically to their control.
Actually, whatever you said and Simon said,
I used to think that people in Web3,
they are, I mean, I used to personally not feel good
when everyone just pushed you to bring all the facts on chain,
even if it is in CK form or encrypted form
and that's what like these SBT
or any of these block space thing comes,
I think like what you said is exactly right.
They just want to sell block space
like the more chain it is used,
it will get more transactions on chain.
The goal is not to actually solve the problem
but rather just push the one standard to it.
But now the second question is,
Evan, it is easier for a bigger protocol that has already,
I'm asking this mostly for my own project
and I just want to have open conversation here
that many of the DeFi projects,
they say that it is easier to consume an NFT standard
it can be queried very easily
based on their existing technologies that they have integrated.
But in case of verifiable credential,
it is totally different way of reading the data
because as you understand,
verifiable credentials are off chain data credentials
which are verified on chain in a different way
than we can actually consume NFTs.
So do you get some push backs
purely from a technical perspective that they say,
hey, we still need that some sort of on chain version
of this verifiable credential that can be queried very easily
by the existing smart contract toolkits
and other protocols that are available for querying.
So is it even a relevant question?
First of all that because personally I am also learning.
if you tell me that this is not a relevant question,
But I would love to have your two cents.
Simon and Evan both, please.
I think this is a great question.
And it's also important for us to empathize
with the perspective of builders.
Enterprises have asked us before,
hey, can we just call an API
and you just return an array of addresses?
Like we don't want to have to query
or we don't want to have to parse data
or interpret something that is different
than how we're used to taking in data today.
So of course we interact with a lot of applications
that tell us, hey, we would really prefer
if that data was free and public
and we didn't have to change anything
about how we do anything to be able to access it.
So if you could go ahead and make all that user data public
for everyone on earth and in space
with an internet connection for all time
so that we can optimize for our dApps access,
that seems like an expensive overshare to me.
That in order for one dApp or one protocol
to be able to read a single piece of data,
that it must be exposed to every human being
alive today in perpetuity.
That cannot be the minimum disclosure
described in the seven laws of identity,
the framework set forth by Microsoft in 2005
to minimize the risk and harm to human beings
in building identity systems.
Indeed, I would say that is the opposite.
So if you wanted to maximize the risk and harm
that you would bring to your users,
you would try to publicize their data
as widely as possible by putting it on chain.
And so although that technical setup
might be more convenient for developers,
it maximizes risk and harm for the humans they serve.
Why would we want to do that?
Absolutely, I totally agree with all your points.
But when I talk to customers,
it's like these are the pushbacks that I get.
But I think it's all about how do you educate them
and try to convince them the value is much more
in long term than this particular dApp,
how easy it is to read data for this one dApp.
We cannot build a protocol
or what standard based on one company's requirement,
especially when it exposes users' personal information
to everyone as soon as it is on chain,
it is available to everyone.
One other thing I want to jump in
and note here really quick
is that these conversations happen all the time.
And so what that means is that we as builders
in the identity space are obligated
to lower the switching costs
because harm to end users does not necessarily make it
into the top business considerations
of any project or protocol.
And so we must deliver these requirements
in a form aligned with business outcomes
where we're making it easier for dApps
to save money on storage, on gas fees,
by creating data that can be on chain aware,
can be validated on chain, can be presented to the chain,
but we don't have to pay rent for it
to live on the chain in perpetuity.
So early on we had proposals like EIP 1812
where we could consume an entire credential on chain.
That's unduly public and expensive.
But now with some of the more exciting developments
from teams like Polygon ID,
we can have smart contracts that issue credentials.
We can publish proofs on chain of their validation.
We can publish NFTs or even on-chain attestations
that serve as a proof of existence for off-chain data.
So there are many different mixed methods we can use here
that encompass the friendly, easily accessible standards
of NFTs or other on-chain forms,
but do not put the contents of the data
that's being queried in clear text on-chain
as though we were publishing people's private information
on billboards in Times Square.
And this is Evan, where I wanted to jump in earlier,
but now I think you went down exactly to the point.
We don't need to kind of force our customers
and force apps to use the tech
that we think is the best for the world.
We need to find smart ways to find common ground with them
that we meet our standards of the kind of principles
that our companies live on
and still deliver what they need for their apps.
And those smart ways, you mentioned them, right?
We have the tech being built.
Polygon ID is a very good example.
You just put the VC off-chain, you put the DK proof on-chain,
and voila, you have minimum disclosure.
You have attestations who can be on-chain,
and they can be very useful for apps.
They're smart, contract-based.
They haven't been there like two, three years ago,
So we're coming up with new and smart ways to kind of align
our values with the needs of the customers.
And I think this is the way to go forward.
The new design, I have been following for a long time
the Iden 3 project almost when I was,
almost when HyperSign was a hackathon project
Since then, a lot of design principles have changed.
And I guess the overall idea behind it
is that keep the ethos of our SSI framework,
but then we deliver a seamless and simple solution
that smart contracts on-chain can actually consume it.
You want to add something from the gaming side,
because gaming is like one of the places
where you need the best UX.
So if you have some experience working with the Polygon ID stack,
I think you are using that stack.
So maybe you can add from your dev side also.
Yeah, so it's not more towards inclination of Polygon ID,
but I totally agree with what Simon just said, right?
Because we often come to this question like around SVTs
and why verified credentials?
Because a lot of our competitors are using SVTs.
So I just give all our customers a simple choice.
SVTs are used for if you need a non-transferable
comprehensive representation of an individual
or any affiliations, go for the SVTs.
While verified credentials have different use cases,
it's the digital equivalence of control
and privacy of traditional credentials, right?
So this is a pure distinction that I can literally see
that people can choose between what is your parity
and go ahead with the thing that you want to basically.
So this is one of the things that I obviously put forward
when I'm asked why not SVTs, some other guys using SVTs
and you guys are into verified credentials.
So yeah, this is one of the clear distinctions
that I use to make sure that hey,
why you should be using verified credentials.
But I will drill down more now since you brought this question.
So my next question is that now when you have, okay,
so customer has decided that we are okay to build
some sort of ID verification,
then we have come up with some sort of solution
which is either mix of different things
or it can be purely verifiable and, you know,
Now the point is that each of you have been either using DIDs
or have built your own solution.
So you guys can, can you please maybe talk about
your own implementations or your own consumption
of DID and verifiable credential.
I would love to get some thoughts from Evan
because I have done some research on her project
and maybe she can help me, you know, bridge all the gaps.
And then Simon, the view, if it's okay in this.
Yeah, I'm happy to, happy to chat a little bit more
about DIDs and VCs in the wild in my own life.
So actually one of the recent partnerships
that we kicked off with our colleagues over at Kiki.world,
a community driven beauty brand is that,
so they invented a method to embed NFC chips
inside of acrylic fingernails,
which has never been done before.
They had to create a custom injection mold
and produce these products.
And so then disco built a tech stack on top
that allows you to apply one of these fingernails
to your hand for other people to tap their phone
And then that interaction creates a wallet
to wallet relationship, where both the person
who tap their phone and the person extending their hand
receive a verifiable credential,
proving that the two of them met at that very moment.
So both of them essentially are able to build
their decentralized friends list controlled by their wallet,
so they can bring those relationships with them
from one application to another across chains,
across protocols, capturing in real life events
at their fingertips with their mobile devices
and bringing those relationships on chain immediately
in a gasless and privacy preserving way.
And so how we're able to achieve this
is using verifiable credentials and selective disclosure.
So the ability to selectively share those credentials
or your social graph with an app
to bring your friends with you on chain
from an in-person interaction.
So that's one very tangible example
where I on an everyday basis use Dids and VCs
to maintain my contact list controlled by my wallet.
Additionally, beyond that,
there's actually a verifiable credential
hiding in the comments of this very Twitter space
If you have an EVM compatible wallet,
want to click the link that I just dropped,
then you can actually take custody of a credential yourself.
And then anyone in this space can build a telegram chat
only for holders of those credentials,
a Discord channel, an e-commerce store,
or even a website with content visible
only to holders of these credentials.
And so the composable pieces
that are accessible for folks to play with,
whether they have wallets or not,
whether they authenticate with email or not,
we actually have experiences for those folks.
So we updated the version of the chipped software,
essentially what our friends over at Gossip Protocol
and Kiki World have created with the fingernails.
And that experience actually also supports people
who start with an email address,
who don't yet have their own wallet.
And so we're able to put users who start with email
and users who start with their own wallets
on equal footing in a shared experience.
And this is what we call Web 2.5.
Amazing. Yeah, I've been reading about that actually.
And now I have the clear picture of how this solution
Simon, you want to add something from your side?
Yeah, maybe just briefly.
Like we're going down a path
that is like very kind of like we're combining stuff.
So we're using the stations for our aggregated trust
and risk scores that we compute.
But those risk scores are,
if you break it down and the sum of granular credentials
that could contain person identifiable data.
we do need to have some private layer.
So this would be the base layer of the ID stack that we use.
And they live as credentials.
It's where fiber credentials with the users
and the user can decide to also disclose them
in a minimum disclosure fashion using on-chain ZK proofs.
Or he can just rely on his aggregated score
and keep the private data private and not shared at all.
So we do use the fiber credentials also in that way.
But we're focusing right now on using them with the apps
that are actually creating the data.
So I think the challenge that we have there
is since the space is new and evolving and ever-changing,
it's just not so easy to kind of decide
and stick to a tech architecture for our product.
And so we're frequently pivoting around,
but VCs are definitely staying an integral part of the tech stack,
and they will, I'm pretty sure.
Deepu, you want to share something about your architecture
or the recent, you know, for the e-sports agency,
you guys rolled out a product.
And how did the ID and credential play the role there?
Or even about the Auth product that you guys have built,
if you want to talk more?
So most of our products are B2B-faced,
and we have been focusing on, let's say,
the consumer acquisition through the businesses
So one of the critical factors for us
was to convince all the available platforms
to integrate Earth authentication.
So just like people are having Google authentication
for onboarding all the gamers,
we are providing turf auths.
So any gamer can come in and log in via Earth
What we are giving extra is a vendor dashboard
to all these businesses to analyze
what all different types of games that their customers really play
and track what all the things they are playing
So our stack is basically more around authentication right now
that we are going ahead with.
And providing all these providers or the businesses
a way to verify the game ID credentials.
Whenever any e-sports organizations really want to verify,
like, hey, this guy owns this game ID or not,
they literally can't do it in this ecosystem.
They just roll out a Google form
and whatever someone claims, they have to accept it.
With our infrastructure, with verified credentials,
any third party can actually verify
if this guy is only the owner.
We specifically call it game ID ownership verification.
And this is actually literally playing a crucial role
in our whole infrastructure.
So yeah, this is kind of a brief that we are up to.
So in that case, why would a business
basically integrate a different auth over existing auth?
I mean, I did not get that part.
For a business, what's the value to integrate stuff auth?
Do you give more information on the gamers
This is actually the catch of why exactly
someone will be using turf auth
over any of the social logins or social auth.
So let's say whenever someone uses a social auth,
they didn't actually get any exposure
around the game history of that particular game.
But if they start onboarding users
or their gamers with turf auth,
what happens is they actually get a whole analytics
of what all their gamers are playing
and with what proficiency.
And it can help them to take their business decisions
as in like, hey, most of my gamers are playing Valorant.
Why don't I integrate my next game as Valorant?
So this is getting very much crucial for them
in terms of taking business decisions
as well as in terms of recruitment and all these stuff.
So this is something that e-sports organizations
are looking for right now.
Like we have so many wider...
What I can see from the panel is that there are almost
like three different types of use cases,
very big use cases as well.
And all can be built or built around a verifiable credential,
which is super exciting for me
because I am also building in this space
and getting to know more and more about use cases,
which other folks are trying to solve
with many different types of variety of solutions,
specifically interesting solutions
that gives me so much happiness.
I would also like to add one more use case
that we are exploring currently.
In India, we have something called Adhar,
and anyone can do Adhar verification.
But now Adhar also has offline Adhar verification.
But this has not been implemented before.
Like offline can be done,
but offline cannot be tracked the way online Adhar verification can happen.
Track in the sense, don't get me wrong,
like not about the user's privacy,
but it is mostly about user giving,
user actually telling that,
and I am going to give you permission
to take some information out of that.
Second is that there is no selective disclosure
of the ID documents currently,
not even in the actual ID verification of Indian identity
or in the offline verification.
And third one is there is no way to monetize
the offline ID verification flow.
So our team has actually built some simple use case around it.
We are working with some of the government agencies
based on some of the regulations
that have recently come up in India
and optimistic that more privacy-preserving
ID verification would happen in India.
So that's like another use case that we are exploring as well.
So I just wanted to add on to all the different use cases
the other speakers here have shared.
Now, coming back to if you guys have a little bit more time,
I would love to know a little bit about your tech stacks,
If it doesn't make sense,
if you don't want to talk about it,
if it is something private, then it's fine in this forum.
Why I'm asking this is because
I can learn from your experiences with these tech stacks
and push it back to my product team to improve our product.
anyone who is happy to share what type of DID standards
that you are using or any specific type of DID standard
or a credential standard in that level of information
you want to share them. Evan, yes, please, go ahead.
I'm always happy to share the technical decisions that we've made,
why we made them, and determine if that's helpful for others
or if we can be of service.
So also, just on the selective disclosure front,
if your team ever wants to talk about methodology for that,
we're happy to share how we approach that with our SDK,
how we went about parsing that data
and how we're able to achieve it.
So if anyone's interested in selective disclosure experiments,
we're always happy to support.
so from a DID method perspective,
actually some of our teammates wrote the DID Ether method
back in the day and have contributed to the development
So we are huge fans of exploring the latest and greatest
but also revisiting ways that we can upgrade old methods.
We're very much looking forward to the DID Ether V2 contracts
that will allow for more on-chain interactions
and are exploring some evolving new DID methods
that would allow for a DID document to live
in a public and persistent way,
but minimizing the cost of updating those service
and messaging endpoints by expressing the data on solutions
such as RWeave instead of directly on-chain
or leveraging data availability layers such as Celestia
Furthermore, when it comes to the handling
of our sort of everyday data at DISCO,
we support the DIDWEB method for those
who might not be utilizing private keys when they enter,
but we also support DIDPKH as a more flexible method.
Now, without a DID document, of course,
DIDPKH puts a lot of pressure on credentials
to carry the verifiable data and associated identifiers
such as social handles that might otherwise be tough
We are also very much looking forward
to more evolution on DID methods from other chain ecosystems
than the Ethereum one where we started.
So also very excited about developments in the DIDION
Looking to our colleagues over in the TBD
and block universe as sort of leaders
and folks we look to over there.
But happy to discuss DID methods standards
and their development anytime
and why it is that we made those particular choices
of helpful offline with any of y'all.
Amazing. Thank you so much.
I would love to connect with you offline later
around selective disclosure.
Overall, we are also doing around DIDPKH
and then we have our own version of it
a little bit different than DIDPKH for on-chain attestations.
We are looking at it from a different angle honestly
because we look at whole cosmos as one chain,
but they are all different chains.
So how this data can be consumed across.
So we tried to build a DID standard that could facilitate that.
It's still in early phase of design,
but would love to share some notes with you guys
Simon, you want to add something from the Concordium ecosystem
if you have some notes from there?
Yeah, I mean, we're still, we're not live yet, right?
We're still tinkering in the back.
So I think at this stage,
my contribution here wouldn't be the best one.
On top of that, I think there are other members of my team
that can elaborate better on the DID standard.
So I think I couldn't add any and a lot of value here in that.
No, no, no problem at all.
Divya, you want to add something?
Most of the things are explained, right?
I would like to add one more thing that is fairly innovative
in our technical stack is
we have been actually initiating our own app chain
and we have been able to make the issuance
more decentralized by actually attaching it
to our nodes of Polyquin CDK Valadium.
So this is one of the things that we,
That is very interesting.
that made sure that the data that has been stored
earlier in the Redis or in the DB specifically,
And at the same time, that's our chain.
We make sure that the data and the storage is
made in a way that the whole decent,
it's called decentralized identifier
and not just an issuance node
having all the custody of the storage
of the data that is available
of the particular verify credentials.
So this is a very different design.
Yeah, this is something that we have been very much up to
and next week we have been actually doing
And I feel that's the go-to place to actually learn about
how exactly we are trying to do that.
I would love to know how the Valadium process works.
I read another paper on it,
like Chainlink guys had come up with a similar design
Evan was also talking about it,
like a smart contract can become a issuer
and then there is no one party who is the owner
So we are not relying on one centralized issuer
in terms of, you know, Web3 use cases.
Like, you know, definitely I will call you
and get to know more about Valadium design
and how CDK is trying to solve that.
Maybe, you know, we can take some help from you there.
So with this, we come to closer of this call today.
I thank everyone for coming here and speaking
and sharing about their project and their experiences
working with, you know, working in the SSI field.
I am really honored to have all of you guys here,
especially, and even our community,
HyperSign community, always love when other people
come and share their project to them.
Although we are very small community,
but, you know, we are one strong group of people
that really believe in, you know, user data privacy.
Whether it's SSI or what technology it is,
doesn't matter, but the folks who are in our community,
and that's why they are sticking with us for so long.
So I really appreciate Evan, Simon, Deepio,
Sorry, I forgot his name, but from Comdex,
all of you guys to come and share your project with us.
And I would love to, you know,
connect with you guys after this call
over the next few weeks to understand more in depth
and see if we can work together at, you know, some level.
Even if it is research or implementation,
So with that, thank you very much, Pankaj.
I will now hand over to you.
Thank you so much, guys, for coming to the spaces.
Vikram, if you don't mind, I have one question, okay?
Yeah, you can ask, not to me, but...
To you, this is a question to you.
Yeah, yeah, sure, please go ahead.
Okay, so see, Hypersign stack.
I wanted to, since we were talking about Polygon ID, right,
I wanted to understand what are the differences between
Polygon ID and Hypersign from the stack perspective.
On top of my mind, I know that we use chain link functions
for making the credentials verifiable across,
what do you say, different chains.
And we are using IBC for making the decentralized identifiers
interoperable on different chains.
But apart from this, what are some of the things that are
different in Hypersign from a Polygon ID perspective?
Since we are an infrastructure project, it would be nice to,
you know, hear some of the people who are in the spaces
and want to understand Hypersign stack better.
It would be nice if you can...
Like, these are the only differences I know.
Like, from tech perspective, what are other differences that you see?
Yeah, so mainly it started with having this thought process
of having one off-chain credential, which can be attested
or which can be verified on different chains.
Like, we started with this idea that what if the user has
verified their identity with one issuer,
but the user has a right to bring this identity to any chain,
connected chain in that particular ecosystem.
So with that, we started with like, okay, how would the data
What are the existing data methods which are available?
Then there were some other methods similar to that.
But specifically for the use case of, you know,
private data verification, we saw that like,
the baby japjap keys are the main key signatures
which are being used mostly because we have been following
identity for a long time and my team decided that
we'll go forward with SERCOM.
There is any other DID method so far registered,
which has complete end-to-end credentialing
and verification just with baby japjap.
Polygon does it, but Polygon does it in a different format.
I will tell you what's the difference there.
Polygon's DID method is more compatible towards their own standard.
They have a slightly different standard than the standard SSI toolings.
Now with DID HID, you can actually have the standard SSI tooling,
which is like creating credential, issuing, you know,
creating dates, rotating keys.
All these you can do with baby japjap basically key signature.
So technically that is the main difference,
but on the infrastructure side,
what we are trying to currently work with is that
we are like, you know, we are taking use case wise.
So the first use case that we are working on
in Cosmos ecosystem, if you are a user with a Kepler wallet
and you do like some sort of verification
So how can you have this verification attestation of your credential
available across different chain using IVC?
So we are writing the standard there,
working with couple of more projects to integrate this SDK.
So major differentiator is there, but overall,
I would always say that Polygon ID is much matured product than ours.
But when it goes to specific use case like this one,
for example, if you are a project building in Cosmos ecosystem,
you would probably use our SDK, which will help you build faster
than trying to move other DID methods and, you know,
or other DID SDKs for, you know, Cosmos app chains.
So specifically we designed it for Cosmos app chain,
but as more and more app chains adopt IVC layers,
our solution can be used with those chains.
So we can connect, the chains which are connected using IVC
can actually get the data of credentials
that whether it is attested or what is the status of a credential
and what type of keys the user have used all this information.
So that's the major, you know, research differentiator you can say.
Polygon ID is slightly different.
If you want to use, I didn't know about the Valium design.
This is new for me because the viewer told me today,
but I, what I, my team had done research like three or four months back.
Till then, you had to put Polygon ID on every chain to have the DID,
you know, and the credentialing integrated.
But in case of HyperSign, you can have your user attested on HyperSign chain,
but these users are available across all the app chains in Cosmos ecosystem.
I hope I was able to summarize that.
I guess I have a clearer picture now.
There is one person who was requested to talk and we,
do we have time for questions?
Evan Simon, do you have some more time?
There are some more people asking questions.
It's always the perfect time for the disco.
Thank you, thank you, thank you.
So, Abir, I've invited you to speak.
You can ask your question.
Yeah, so I wanted to thank everyone.
We organized this identity stuff because I worked with Affinity Singapore.
We developed a DID interface for Changi Airport.
So it was quite amazing to see the folks from identity space.
Good to hear that you liked it, Abir, and hopefully you learned something.
And thank you so much for coming in today, guys.
I guess we are well across the time that we had for this.
Thank you so much for giving us your time and kudos.