# Vault

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

##