SECURITY

This document outlines essential security information and best practices for interacting with our staking pool and related services. We are committed to providing a secure environment for our users through audits, ongoing bug bounties, security precautions, and continuous monitoring of our systems.

Our goal is to empower users with the knowledge and tools needed to protect themselves against potential threats and ensure a safe and trustworthy experience.

Please take the time to read through the following sections carefully. Your awareness and actions play a crucial role in maintaining the security of your investments and the integrity of the platform.

User Security Recommendations

Secure Your Wallet

Make sure you always keep access to the wallet you use to deposit. It is the only wallet that is allowed to withdraw from the pool. Use a Universal Profile that has 2FA and/or third-party recovery enabled. Or connect a fresh Ledger account with your MetaMask to deposit.

Beware of Scams

We will not email or DM you and we will also never ask you to send us funds or share sensitive data with us. If you have any problems you can reach us in the following ways:

• Email
• X
• Telegram
• Discord

If we do an announcement, it will be on our official channels. Always double-check the URL of the website you are visiting is on the stakingverse.io domain and make sure it is the correct one.

Audit

The smart-contracts for our staking pool are built by Universal.Page and fully audited by CD SECURITY.

Check the preview below.

You can also find the full audit here

Risks

There are many risks associated with interacting with decentralized smart contracts. Here are some of the most common problems and what we have done to prevent them to ever happen.

Smart Contract Risks

The contracts and oracles are build from scratch by Vlad Lykhonis and audited by CD SECURITY, you can read the audit down below.

However an audit does not guarantee absolute security. Audits vary in quality, and even comprehensive audits can miss subtle vulnerabilities or fail to predict how complex interactions with other contracts could lead to issues.

Next to the audit we had, there is an ongoing bug-bounty that forever will keep running at immunefi. Eventually we will add more money over time to the bounty to attract more people to find potential bugs.

Oracle Failures/Hacks

Smart contracts often rely on oracles to fetch external data (e.g., asset prices). If an oracle provides incorrect data, it can lead to unintended contract behavior, including loss of funds. Vlad completely re-designed the functionality of the Oracles to reduce the risk as much as possible.

The Stakingverse oracles are running independently of the Staking Pool and the rewards and funds are distributed directly from the beacon chain to the pool's smart-contract, the oracles don't have any access to the funds. So even if there is an error in the oracle or it gets hacked, the funds in the pool remain safe.

Slashing

If a validator misbehaves, it can be slashed. This means that the validator will lose some of its LYX. The vault is operated by Stakingverse and is not likely to be slashed. However, if the Stakingverse validator is slashed, the vault depositors will lose some of their LYX.

To prevent this to be happened we divided all keys we generated in different folders of X amount of keys and numbered them per server. All servers we are running at the moment are pre-filled with x amount of keys, before we welcome the next server into the protocol we will always fill

Wronly Deposited Validator Data/Invalid deposits

Even though this problem is not really common, it happened on the LUKSO network recently and we want to mention what we have done to prevent this from happening. Before our Oracle is able to register a new validator it will check all variables in the deposit_data.json before the Vault is able to deposit a new validator to the LUKSO Validator Deposit contract.

In this way, our Oracles will never be able to register a validator with invalid data. Also, we generated all keystores and deposit_data.json at once. If there was a problem with the deposit data, or keystores it would be a problem for all validator keys, not just one. We tested 1 key first to confirm that everything was working as expected, which was logically the case.

So far we did deposit over 1000 validators without any problems, so as long as we don't have to generate new validator keys it will be impossible for us to run into this problem. We did generate enough keys for the coming years.

Disclaimer

We take every precaution to ensure the safety of our customers, but as you can see there is always a small chance that something can go wrong. We will always do our best for our customers, but it is important that you read our full Terms of Service to understand your rights and responsibilities when using our platform Terms.