Splitting Wallet Creation & Adding Wallet to Chain

[its-colby]

https://github.com/subspace/auto-mobile/blob/115a23df284065e00343877fc7b3c149e473df68/packages/sdk/src/library/wallet.ts#L110

This function should not include a await didRegistryContract.connect(signer).register(autoId);. This functionality should be included in a separate function, namely, because it requires a signing key. Therefore, await isAutoIdVerified(autoId); should also be removed. These should be added to a separate function.

From the mobile app, the UX should be as follows:

1. user generates auto ID (no on-chain events happen)
2. user decides to a. seed fund his auto pub key b. pay his auto pub key from previous address c. add in credentials for previous address or d. for POC, have faucet for seed funding.

Then, once an auto-controlled signing key has relevant funds, this on-chain aspect can occur.

@chrissotraidis

[abhi3700]

From a non-custodial perspective, this approach is logical.

The current version of the code operates under the assumption that we would essentially handle the register process on behalf of the user. Naturally, we would verify the authenticity of users during the Know Your Customer (KYC) submission phase using some AI model. It’s likely that we would generate revenue through some form of subscription fee paid by the user.

Require thoughts from @chrissotraidis on this.

[its-colby]

I don't think we could handle the register process on behalf of the user; if we did, we would need to somehow supply the user with sufficient funds for the fee associated with publishing account on-chain. As a side note, we don't plan to require KYC to create an Auto account. Additionally, we (as of now) haven't planned for any kind of subscription fee or something similar (which would then cover any relevant fees during publishing account on-chain).

[abhi3700]

if we did, we would need to somehow supply the user with sufficient funds for the fee associated with publishing account on-chain.

Actually, there is a signer who is sending transaction register function on the contract. So, no fund is ensured in the new account, but the signer should have sufficient gas cost for the transaction.

Rest, are you confirming that we go ahead with change in the code or we wait for @chrissotraidis to confirm?

[chrissotraidis]

@abhi3700

I agree with Colby on separating the signing key functionality into its own function for better clarity and security. Regarding the subscription model, it's likely better for Subspace to seed the funds initially to encourage adoption. Users might be hesitant to pay for a subscription without experiencing Auto first.

For KYC, it's not necessary now, but we should keep our system adaptable for future integration, especially if we expand into more web2 offerings. Let's proceed with the code changes with these considerations in mind.

[its-colby]

Actually, there is a signer who is sending transaction register function on the contract. So, no fund is ensured in the new account, but the signer should have sufficient gas cost for the transaction.

This is exactly what I was talking about. This part should be 1) taken out 2) moved to another function and 3) swapped to not be a "hardcoded signer", but rather a dynamic signer (the user of the app)

[abhi3700]

Will make the change