Moving from complete non-custodial to semi-custodial setup

[tirtha]

• SDK Version: tkey 12.0.0
• Platform: Web

Currently our auth module operates in a non-custodial manner where the keys are reconstructed while providing a 2/3 share.
It has been our observation that, whether due to the issues of the SDK, lack of user accountability, the pure non-custodial setup, while is ideal - becomes quite risky.

Especially situations where users completely lose access to their accounts.

Would it be possible to build a semi-custodial setup, where through user verification, an account recovery process can be built while providing the user with most control over their funds?
We would like to hear some suggestions from the web3auth team on what modules can we use to implement a system where we have the best of both - secure authentication + reliable recovery(fallback). @yashovardhan

[guru]

Clarification on dApp share requiring custom verifiers

Hi, first of thanks for asking this question, So before biting the bullet to answer why dappShare is returned for custom verifiers and how dapps can use this share, I will make some effort to describe what verifier is and what is the difference between custom and default verifiers. Verifier:- A verifier is a piece of information about the OAuth provider being used by the application which is queried by web3auth auth network nodes from a smart contract deployed on the Ethereum blockchain to v…

you can rely on dapp share if needed or use the concept of dapp share and still remain non custodial, since you will have access to 1/3 share of user

@yashovardhan, correct me if i’m wrong