All new users will be airdropped VAULT tokens as of right now during mainnet launch. We will also set dynamic pricing per-vault or per-lock operation. 1 VAULT token is just the starting price. Users will be able to vote on changing the price via a DAO (with quadratic voting so whales cannot influence elections heavily) and a price-feed oracle will be leveraged to adjust the pricing to account for market conditions.
We mean to make this both accessible, worthwhile, and rewarding to all new users. We are still figuring out what the most scalable and approach is.
Unfortunately we didn’t manage to get past the ideation phase and actually built what we envisioned this time around. As a result we never launched (on testnet/mainnet, etc.) and have no users just yet. Hopefully we’ll have quite a few once we realize our vision.
Hello. Thank you for your kind feedback. We agree on the necessity of new protocols such as the one we are proposing, foremost because one of our team members nearly lost their entire savings due to a cyberattack and this solution would have prevented immeasurable heartache…
With regards to making things accessible, including recovery, especially to new users, etc. - the team has gone to great lengths to prioritize an intuitive, clean UI/UX, upon which we iterated to “trim the fat” and all unnecessary and confusing aspects until we were left with the absolute essentials.
As a consequence, we hope that in conjunction with our user guide which we will shortly publish and the very short demonstration video for our pitch with regards to how to use the protocol, anybody would be able to seamlessly start using our protocol.
One of our crown achievements in our eyes, in fact, is just how simple it is - especially considering how complicated the underlying mechanics are (as evidenced from some of our technical responses in this forum). And we hope our future testers and users will come to agree. Please stay tuned for the aforementioned resources coming shortly.
Ok thank you for your answer. I will wait for your update and while waiting for it, I want to know how you will detect and respond to attacks in real time.
Hello. Yes, prior to our mainnet launch we will only have the protocol and its associated token on the testnet. We will be releasing a set of resources including a guide, diagrams, and our pitch deck & accompanying video shortly. The airdrop mechanism and the token will still be available in a similar fashion on the mainnet once we launch.
Yes, we are close to complete in terms of realizing our vision. During the last tron hackathon season we have not built out anything we envisioned and described.
So perhaps there is a slight misunderstanding - a crucial aspect to note here is that our protocol is not inherently designed to detect/respond to attacks in real-time. Rather, security is built-in into the protocol and our smart contracts to prevent unauthorized access to resources and to provide a pathway to trustless and efficient resource recovery in the event a wallet is suspected to be compromised or lost.
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. The bank teller would then require that you perform the necessary MFA procedures in order to access the contents of these boxes again or to authorize that resources be moved. If the bank is “breached in a robbery”, you can think of all safety deposit boxes as completely immovable by the attackers.
Your recognition of Web2 risks and the proactive integration of VaultMFA demonstrates a deep understanding of security challenges in the Web3 ecosystem.
How do you plan to handle scenarios where a user cannot access any of their configured MFA factors? Will there be an emergency recovery process that maintains security without compromising user control over their assets?
It’s important to note that the price of the token itself will not be the “true cost” itself for our operations due to price recalibrations in terms of the cost in VAULT tokens
We will adopt a four-pronged approach to fee volatility:
token burn and other fee redistributions for operations and rewarding holders - token burns also disincentivize operations that are too frequent and can be calibrated to disincentivize price manipulation attempts
DAO calibrated fee readjustments at regular intervals
locking/vaulting fee pegging via price-feed oracles to TRX/BTT/stablecoins
volume-based fee readjustments to protect against turbulent volatility and friction loss
Unfortunately, due to the risk of exposing a central point of failure to attackers we have had to make the compromise that the users will have to perform all their configured MFA sequences when they unlock or unvault; however, as a concession, as we mentioned in a prior response, in a future upgrade a subset of MFA factors can be configured as the minimum threshold in order to protect against problems with availability of certain MFA providers.
We will go to great lengths to inform users of risks associated with high/low thresholds, availability, etc.
That being said, a future upgrade will also allow users to configure a set of configured emergency MFA providers that will allow them to unvault and unlock all their coins after they are placed into a new safe wallet, however, once again, due to the risk of a central point of failure, users will have to go through a set of confirmations and configure the thresholds as they desire to enable this feature.
A careful balance between usability and risk has to be struck. A challenge in most security domains, especially with those concerning multi-factor authentication in general…
Hello. Forgive our ignorance we don’t quite understand this question but we will do our best. If we do not address your questions and concerns please let us know if we can clarify upon anything further.
Regarding utilizing the platform without compromising security:
The platform itself is concentrated on setting up security rather than providing attackers with a new attack surface.
Our dApp is entirely trustless and stateless. Neither developers nor attackers can read anything that is on the user’s browser at any time.
Our dApp implementation allows users to simply scan a QR code to integrate Google and Microsoft Authenticator and does not give avenues to hack these providers or to access OTP codes otherwise.
Similarly, our trustless ZKP-based MFA provider is entirely trustless and does not store any sensitive data in smart contracts or otherwise by design. It is also entirely on-chain.
Lastly, for custom API MFA, that purely relies on providing an API provider’s URL and an associated payload - this cannot serve as an attack verctor for cyberattacks apart from giving attackers knowledge of the API provider’s URL, which is already public and not sensitive information. The payload may be exposed only if the user is not careful and allows someone to read what is being read as they are interacting with the dApp by snooping their screens, etc. or if a computer virus/malware is installed on their machine. API requests from our serverless frontend are TLS encrypted and cannot be read by servers/developers/hackers otherwise.
In conclusion, we have taken great care to make our dApp stateless, serverless, and to have all external interactions be TLS encrypted and unreadable by us/potential attackers. All MFA providers are also secure.
Thank you for your reply to me, so far I am really liking you’re approach, please tell me how are you going to decide about the percentage of the amount of the token that you are going to burn, thank you
This totally addresses potential accessibility concerns while maintaining a strong emphasis on security. How do you plan to handle potential abuse of the emergency access feature, especially if an attacker gains partial control of a user’s account?
For now, we will follow battle-tested percentages that other protocols have used for quite some time such as an equivalent distribution for team funds, staking rewards, burn tax, etc. However as time progresses these will be adjustable via the DAO by our users (with quadratic voting to prevent manipulations by whales).