Vault

The Vault contract provides a secure and flexible platform for depositing and withdrawing coins, as well as approving and depositing ETH to strategies.

Functions

init

This function is called during contract deployment and is used to initialize the contract. The AddressRegistry instance is passed as a parameter.

deposit

The deposit function in the Vault contract is used to allow deposit of funds into the vault.

withdrawal

This function is used to withdraw a specified amount of a coin from the contract.

getAmountAcrossStrategies

This function is used to get the total amount of a coin held by the contract and its associated strategies. The function returns the total amount as an unsigned integer.

Price Oracle

Overview

The ALP minting process is a sophisticated two-stage mechanism, designed with security and process efficiency in mind. Regular users can interact with the Router contract by calling either the submitMintRequest or submitBurnRequest functions, making it user-friendly and straightforward.

Once a request is submitted, it is stored in a FIFO queue, ensuring a systematic and orderly processing order. During this period, tokens are securely held in the Router contract, and users are still in control through cancelMintRequest or cancelBurnRequest functions.

The second stage of the process involves a privileged account called the darkOracle. This account has the ability to call the processMintRequest or processBurnRequest functions, providing the system with necessary token pricing information. This two-stage process, with distinct roles for users and the darkOracle, helps maintain a smooth, secure and efficient ALP minting process.

Specifications

The darkOracle, a critical component of our system, is a bot designed to source prices from a CoinGecko PRO-tier subscription along with some of the most liquid decentralized exchanges (DEXes). To ensure the highest level of security, the key for the darkOracle is securely hosted in a Google Cloud Hardware Security Module (HSM). The design is such that neither our team members nor Google personnel can reveal the key, underlining our commitment to security and confidentiality.

A potential avenue for altering the behavior of the darkOracle bot is via changes to the code. In our commitment to transparency, we plan to open source this code in the near future, further enhancing the trust and collaboration within our community.

Moreover, we are also looking forward to introducing decentralized Oracles to ALP. This advancement will further democratize the process and improve the system's resilience, reinforcing our commitment to innovation and community-centric development.

Risk Mitigation

Dark Oracle malfunctioning

In the event of a malfunction in the darkOracle, which could potentially lead to incorrect price submissions to the smart contracts and result in over or under minting of ALP, we have a robust risk mitigation strategy in place.

The first layer of this strategy allows minters and burners to set parameters to guard against drastic price changes. Minters can define a minimum amount of ALP they wish to receive, while burners can specify a maximum they want to burn. This precaution, referred to as slippage tolerance, provides users a measure of control and protection against volatile price fluctuations.

Additionally, the system architecture includes a safeguard in the form of transaction value limits on the vault per block. This feature ensures that even in the event of an anomaly, the impact on the overall system is contained.

Lastly, our team is committed to vigilant monitoring of the minting and redemption processes. Any attempts at malicious minting or redemption would be uneconomical due to the careful design of the system's incentives. Thus, users can confidently engage with the platform knowing that these safety measures are diligently implemented.

Dark Oracle stopped working

In the event of unforeseen circumstances such as a system fault, Denial of Service (DOS) attacks, or even if the team discontinues operating the darkOracle, we have proactive measures in place to secure any tokens or ALP currently held in the Router contract. These tokens can be safely released by invoking the cancel functions, ensuring the preservation of user assets.

Additionally, control over the vault contract is vested in a nested multisig, which means that the power to oversee the contract is not centralized but rather, distributed amongst multiple signatories. The direct link between the Snapshot votes and the multisig is facilitated by the integration of a reality.eth oracle, which enables the community's decisions to directly influence the control of the multisig.

In an extreme scenario where the darkOracle needs to be restarted, the community, empowered by their voting rights and supported by the reality.eth oracle, can take control of the Vault and reset the Router. This resilient framework ensures that the system can recover and continue operation even in challenging circumstances. Hence, user assets and the overall functionality of the system are safeguarded under a broad range of scenarios.