Hello. Yes, for sure.
We will publish a video which will demonstrate how everything is interacted with within a day or two with regards to our dApp. The instructions are also part of our guide attached above.
Alright. So based on the image below, we know that username user.vault has some address, lets call it 0x11 attached to it via our Account Abstraction system. Suppose 0x11 gets hacked because the private key/seed phrase of the 0x11 wallet gets stolen after a keylogger/keyboard clipper is installed on a user’s machine… Not good… This is exactly what happened to me through sophisticated malware similar to this - https://cyble.com/blog/new-laplas-clipper-distributed-by-smokeloader/
Another scenario - lets say you lost access to your seed phrase or private key because you lost access to your computer, it got destroyed in a fire, etc. and you no longer have access to 0x11.
Both are pretty bad situations to be in, with the former being particularly nasty because an attacker can just redirect the coins in your account to their own wallets and spend them. This is the case with traditional ERC20s and ERC721s because transfers are unlocked by default and getting your private key robbed is usually the death sentence to your holdings…
This is precisely why we have developed the mirrored ERC20/ERC721 standard for our protocol. When an asset is vaulted in our protocol, the underlying asset such as your TRX or BTT coins and/or NFTs get sent to our core smart contract but users receive newly minted mirrored ERC20s/ERC721s in exchange so that the mirrored assets can be exchanged for the original assets later. The mirrored ERC20s and ERC721s (mTRX/mBTT/etc.) allow you to configure a required sequence of MFA operations to unlock transfers or let you set a time lock on transferability - including an infinite one. The implication here is if you get hacked and your mirrored assets are locked an attacker has no way of getting to the underlying assets (the TRX/BTT/NFTs) in our core smart contract OR of transferring the mTRX/mBTT/etc. to their wallets. The former requires unvaulting (which can has an associated custom MFA sequence requirement the user sets), and the latter requires unlocking (which also has an MFA sequence required and, additionally, up to a permament time requirement).
So what does one do if they realize their wallet is compromised or lost? They log in to their account user.vault but with a different wallet, say 0x22. This is done by proving ownership of the user.vault account and must be done by selecting the “recover” option . All mirrored assets are then simply redirected (automatically) from 0x11 to 0x22 where they can be safely unlocked and unvaulted.
“Contract wallets”, or wallets that are managed at a smart contract level, are not a new concept, however our contribution of the new mirrored ERC standard along with the fully extendible custom configuration of MFA requirements (including any custom Web2 API/Web3 MFA compliant with our simple interfaces) makes us see ourselves as a new evolution - a completely customizable and extendible asset management protocol that allows for recovery. Our dApp is just one way to interact with our smart contracts. The protocol can be integrated into new Web3 protocols, including cross-chain ones soon, in as little as two lines of code.
We will be extending recovery and mirrored asset control and functionality shortly. Some upcoming extensions will include:
- Control over which assets are redirected to the new rebinded wallet/which quantity and to which wallet (allowing recovery through multiple wallets, etc.)
- Setting a fully configurable sequence of MFA requirements for recovery beyond our zero-knowledge proof based requirement currently present
- Blacklisting and whitelisting wallet addresses and allowed operations on accounts
We hope you find this concept as intriguing as we do. We see a lot of potential in it. If I was using our own protocol it would have prevented immeasurable heartache for me as I could have just recovered my stolen assets relatively simply.