Vault - Uncompromising Asset Security and Account Abstraction

TRON Hackathon Hackathon Season 7
42

Hello.

Well, with regards to partial control of a user’s account, this is insufficient for attackers to steal a user’s assets by design in our protocol. An attacker either has complete and utter control over BOTH the wallet AND all the MFA factors or they don’t. This is insufficient for abuse precisely because of our Account Abstraction recovery feature.

As you may note in our “Asset Recovery w/Account Abstraction” diagram - if compromised, users will simply rebind a new wallet to their account to which all the mirrored assets will be transferred and in which they can be safely unlocked and recovered.

2 Likes
43

Alright all the best

3 Likes
44

Thank you for you’re replying to me and I am liking you’re approach very much already, please tell me as you are gaining more and more users how are you going to do to adjust the sharing or distribution of staking rewards, thank you

2 Likes
45

Hello.

While the equal distributions will be the starting protocol (based on what historically worked for other well established protocols and chains), the DAO will eventually allow our users to vote on these distributions at regular cadences where they will be able to vote on both the distribution percentages and voting frequency periods.

1 Like
46

im getting this error

There was an error with the transaction: eW: Transaction has been reverted by the EVM: {“blockHash”:“0x710b7ba1d9183d69f7e5d6bcb2d8ad5cafc2577c03bf528ea570276032a76089”,“blockNumber”:“43349758”,“cumulativeGasUsed”:“28858”,“effectiveGasPrice”:“9000000000000000”,“from”:“0x4b215566f59d3a5d9eecb087695aa7ec100979b8”,“gasUsed”:“28858”,“logs”:[{“address”:“0x0000000000000000000000000000000000001010”,“topics”:[“0x4dfe1bbbcf077ddc3e01291eea2d5c70c2b422b415d95645b9adcfd678cb1d63”,“0x0000000000000000000000000000000000000000000000000000000000001010”,“0x0000000000000000000000004b215566f59d3a5d9eecb087695aa7ec100979b8”,“0x00000000000000000000000054ffc23455ade612e7d0e068b36d1f80f0885cc0”],“data”:“0x00000000000000000000000000000000000000000000000e145de6ef120100000000000000000000000000000000000000000000000f645d251692995d8296af0000000000000000000000000000000000000000011fdfcac3fadf801ec8b9380000000000000000000000000000000000000000000f644f10b8abaa4b8196af0000000000000000000000000000000000000000011fdfd8d858c66f30c9b938”,“blockNumber”:“43349758”,“transactionHash”:“0x2f2dd8a9f849d113ecfb12db6b261ec7b9f0a4175cca6fb227bb161c754184c0”,“transactionIndex”:“0”,“blockHash”:“0x710b7ba1d9183d69f7e5d6bcb2d8ad5cafc2577c03bf528ea570276032a76089”,“logIndex”:“0”,“removed”:false}],“logsBloom”:“0x00000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000008000000000000000000000000000000000080000000000000000000000800000000000000000000100000000000000000000000000000000000000000000000000000400000080000000010000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000080000004000000000000000000201000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000100000”,“status”:“0”,“to”:“0xb6ea1ac42c3efff1b81b20ea797ca2a9148606fb”,“transactionHash”:“0x2f2dd8a9f849d113ecfb12db6b261ec7b9f0a4175cca6fb227bb161c754184c0”,“transactionIndex”:“0”,“type”:“0”,“events”:{}}

Screenshot 2024-10-03 135648
Screenshot 2024-10-03 1356481374×591 34 KB

2 Likes
47

Hello @Kojopapo,

minor update: the fixes to these issues have been implemented

firstly, thank you for trying out our protocol we hope you are liking things so far apart from the unfortunate roadblocks you have raised

image
image1882×953 150 KB

for your first failed tx: please select at least one MFA provider when vaulting; it does fail by design as our smart contract does not allow the tx to proceed but we haven’t added the frontend to fail fast if no provider is selected just yet.

image
image1443×775 96.9 KB

for your second failed tx: please ensure the quantity of the token you are vaulting is either less than or equal to your balance of said token.

Apologies you ran into these errors. Please feel free to reach out to me here: https://t.me/vaultweb3 on telegram or ask further questions here.

These frontend safeguard rails will be added shortly. (Within one or two days)

2 Likes
48

Allowing users to implement Multi-Factor Authentication (MFA) and time-based locks adds a valuable layer of security. This gives users greater control over their assets and adapts to different risk profiles.

1 Like
49

Thanks for that.

Yes; we also want to empower developers, so our contracts can be easily utilized by others writing web3 protocols by just importing our code and pointing to our smart contract if they need custom security/asset protection.

Web3/Web2 MFA providers are also free to integrate their own security logic quite easily based on the simple interfaces and instructions we left in the forum.

50

By ensuring that an attacker needs complete control over both the wallet and all MFA factors, your protocol offers a strong safeguard against partial compromises.
Can you elaborate on the process of rebinding a new wallet in more detail?

2 Likes
51

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/

image
image968×783 69.1 KB

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).

image

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.

3 Likes
52

How does Vault keep its asset recovery system secure and reliable if a wallet is compromised? Also, how does integrating Web2 APIs improve the overall security of the assets stored in Vault?

1 Like
53

What are the future plans for Vault regarding cross-chain compatibility and expansion beyond Tron and BitTorrent?

1 Like
54

What guidelines or best practices should developers follow when adding their Web3/Web2 MFA solutions to Vault?

1 Like
55

Hello JOHNY thanks for your interest. Sorry I just elaborated upon that first question 7 minutes prior to this question :sweat_smile: could you consult my reply here:

With regards to how Web2 APIs improve the overall security of the asset - they empower users and organizations using our protocol with the ability to use the rich and far more established world of Web2 MFA providers. We have demonstrated this by integrating google and microsoft MFA, but ANY traditionally Web2-only domain such as Pass Keys, FaceID, custom government issued biometrics verification, etc. is now available to our users. Any number and any sequence of MFA providers can be made available via our flexible and extendible protocol in the future.

1 Like
56

Great …
How do Web2 APIs enhance the security of assets within your protocol, and what specific benefits do they provide in terms of multi-factor authentication (MFA) options?

1 Like
57

This one is a bit out of scope for us as we are more concerned with providing the infrastructure for the simple integration capability for Web3 and Web2 MFA providers into our protocol/new Web3 protocols using ours, however, general security guidelines are of course to be observed:

  • making MFA providers as trustless as possible, minimizing trust in servers and third parties, etc.
  • making MFA providers available - such that servers of MFA providers such as Google do not go down (although we are configuring subset requirements so that only a threshold of MFA providers is required to be available to account for contingency scenarios such as this)
  • making MFA providers efficient and scaleable - so that the authentication logic of say a Web2 API that is integrated into a Web2 MFA provider does not crash if thousands of users are utilizing it
  • observing established software security patterns when developing the MFA providers to maintain security of operations
1 Like
58

“How do Web2 APIs enhance the security of assets within your protocol, and what specific benefits do they provide in terms of multi-factor authentication (MFA) options?” - this has been answered in the reply you have linked.

1 Like
59

Some of our plans include:

  • Cross-chain account abstraction and account recovery.
  • Vaulted stable-coin and native asset bridging capability.
  • Integration of DEX capabilities to be able to sell/transfer/swap vaulted assets at quoted prices by the integrated DEXes across chains while maintaining the vaulting and/or transfer locking on the mirrored asset. Essentially, asset translation in a way from chain x to chain y whereby vaulted and locked TRX say can be translated and transferred to vaulted and locked BTT/ETH/etc. on another chain.
1 Like
60

You can think of our protocol as a solution similar to a bank vault with safety deposit boxes where you can configure your safety deposit box to your liking or ask that it be moved to a different and more secure uncompromised bank.

2 Likes
61

Ok, thank you for clarifying that point, please has there been a scenario where your protocol has been successfully utilized to recover assets or prevent unauthorized access to resources?

2 Likes