I want to bundle web3auth’s WaaS, along with other features that I provide as a service to my clients (Game developers). However one of my requirements is that the wallet address that is generated should be consistent across all my clients. I.e.
- Player logs in to game 1, using email address user@example.com generates a wallet address 0xabc, mints an NFT.
- Player logs in to game 2, using same email address (user@example.com) generates same wallet address (0xabc), still owns the NFT and is able to see it in game 2.
When I had a call with one of your reps, they told me that this would work provided the client IDs were the same in both the games.
However what escaped me then was, wouldn’t that be a security issue? If I provide everyone the same client ID, I can’t ensure the keys don’t get leaked, I can’t ensure that the keys will only be used for some other projects. I can’t track which project used how much/how much they should be charged.
So my question is, how can I meet my requirement of consistent wallet generation, without the issues that come with sharing the same client ID to multiple clients.
PS: I also want to make sure that the wallet addresses stay consistent regardless of which network they’re on.
Hi @Aniket-Bhat,
I hope you’re doing well. I recommend reading this explanation on how different wallet addresses are created across our protocol: Link to documentation.
The ClientId is an ID you create from the dashboard that you will use across all your projects to identify them. Clients will log in to your projects with their social logins or other chosen methods, and only they will have access to their private keys.
Can I ask you who are you planning to send the clientId to?
Hi @TomTom,
What you’ve mentioned would be the case, if I (my company) was the one creating the games themselves that would consume the Client IDs. We are not. These are not OUR projects. We aim to provide web3 solutions to game developers (our clients), one of which, is to provide WaaS via white labeled web3auth SDKs.
Now in this case, every game developer would require their own client ID, which would be used to create wallets for the end user, i.e., game players. But one of the business requirements is that a player should be able to mint an NFT in one game, and use it in a completely different game. That is what we are aiming to build, cross-game compatible NFTs.
Now we’ve realized, that most gamers and game developers would prefer the blockchain part to be invisible to the end user. So we need on-the-fly wallet generation via web3auth’s SDKs.
But for the business requirement to be met, the wallet account generated in game 1 should be the same as the wallet account generated in game 2. I.e., same user, same email, different games, different developers, but same wallet address generated.
And as discussed with one of your reps, was that the client ID and the email address are what defines the wallet address generation. If the client ID in two games is different, the wallet address generated would also be different. If the wallet address generated is different, then there is no way for the two games to share the same NFT.
So I hope that clears up what we are trying to achieve, and what we believe the obstacles are in meeting our business requirements. Hoping to hear some resolution from you, TIA!
Hi checking in to hear back from you.
Thanks for checking in @Aniket-Bhat.
And thank you for outlining your requirements and concerns. Maintaining consistent wallet addresses across different games and developers is indeed critical for your cross-game NFT functionality.
To achieve this, I suggest utilizing aggregate verifiers. Here’s how it can work:
-
Aggregate Verifier: With an enterprise plan, Web3Auth dashboard gives unlimited seats(allowing you to add devs from different Waas providers with limited privileges) enabling you to create an aggregate verifier that includes multiple sub-verifiers. You would control the aggregate verifier, ensuring a single client ID is used.
-
Sub-Verifiers: Each game developer (your client) would use a unique sub-verifier within the aggregate verifier. This means while the client ID remains the same, the sub-verifiers differ for each provider.
By setting up the aggregate verifier in this manner, you achieve:
- Consistent Wallet Addresses: The same email will generate the same wallet address across different games because the aggregate verifier ensures uniformity while allowing sub-verifiers to distinguish between different developers.
Hi,
Thanks for the response. I see the documentation provided mentions adding sub-verifiers, here. Are there any limitations to the how many sub-verifiers can be added, or the type of social login that can be used? Is there a way to programmatically set this? Also does the address also stay consistent between networks?
Hey @Aniket-Bhat,
There are no limitations to the number of subverifiers that can be added. Regarding programmatic access, I need to check with the team to see if it’s still provided.
I assume you mean blockchain networks when you refer to “consistency between networks.” For chains using the same curve, you’ll be fine. However, for chains using different curves, the addresses will differ. Rest assured, the private key will remain the same for the same user with the same email across different networks.
Hi @maharshi ,
Just to confirm, you are referring to secp256k1? We only plan on using this for a handful of EVM chains, so that should be fine. Did you get any updates on the management APIs?
Also another query was if we can still track the usage for individual games even though the client ID is the same? Assuming each game uses one or two sub verifiers each, can we track how many accounts they have generated to charge them accordingly?
Hi @maharshi, any updates on this?