# Reserve

The three types of reserves that help with stabilizing the system.

There are three types of reserves in the Decentralized Euro system. The first one consists of other Euro stablecoins that reside in a bridge, the second one consists of funds provided by the borrowers when they mint new Decentralized Euros, and the third one is provided by the holders of reserve pool shares. The collateral used to mint Decentralized Euro is not considered reserve as it conceptually stays outside the "balance sheet" of the Decentralized Euro system.

If the Decentralized Euro system was a company, its balance sheet would roughly look as shown above. On the asset side, the system has all the stablecoins that reside in bridges (x), it has given loans to minters that they need to repay (m), and it has a number of Decentralized Euro in its reserves (r). On the liabilities side, there are all the Decentralized Euros in circulation (z), the reserve (b) it owes to the minters, and the equity (e) owned by the pool share holders.

To provide you with an intuitive understanding of the balance sheet, let us look at what happens in three example scenarios:

If a user sends 100 Decentralized Euro to a stablecoin bridge to swap them into another EUR stablecoin (e.g., EURC), the balance sheet items x and z are both reduced by 100 units of that currency. The other balance positions are unaffected.
If a user mints 500 Decentralized Euro against a collateral with a reserve ratio of 20%, the following will happen on the active side: m will increase by 500 (because that is how much they need to repay) and r will increase by 100 (the borrowers reserve held back by the system). On the passive side, z will increase by 500 (the amount minted) and b will increase by 100 (the reserve the system must return when the position is repaid). The user's wallet receives 400 dEURO — the principal minus the reserve. There is no upfront fee at mint time in either V2 or V3 (this is a deliberate change from Frankencoin V1). Equity e only grows over time as interest accrues on the position and is paid via collectProfits whenever the position is closed or modified. The collateral provided by the user is outside the balance sheet and does not appear here. Even though it is locked, it still belongs to the user.
A position that was used to mint 5,000 Decentralized Euro is successfully challenged, with the highest bid being 4,500 Decentralized Euro. To be able to repay everything, the system will take 600 Decentralized Euro out of the reserve, decreasing r by 600. Out of the 5,100 Decentralized Euro we get as a result, 5,000 Decentralized Euro are used to repay the loan, reducing both m and z by 5,000 each. The remaining 100 Decentralized Euro are sent to the challenger as a reward. Assuming that the borrower's reserve attributable to that position was 1,000 Decentralized Euro, there are 400 Decentralized Euro remaining that can be reassigned from b to equity e on the passive side. These 400 Decentralized Euro are the liquidation profits the system made in this example.

When a position is liquidated, there are three layers of protection that kick in to protect the system from a loss: First, the borrower's reserve directly attributable to the liquidated position is used to cover the loss. If that does not suffice, the loss is taken out of equity, making the pool shares less valuable. Third, if not even that is enough, then the general borrower's reserve is tapped into. This last escalation step is a means of last resort. It implies that other users will have to pay back more than anticipated when closing their position. This gives not only the pool share holders an incentive to guard the system against losses, but also everyone who has an open position as they will suffer when a severe loss happens due to having accepted unsound collateral.

Lastly, it is worth mentioning that the system is designed such that given efficient markets, the equity will in equilibrium be about one fifth of the Decentralized Euros not created through a bridge, i.e. 5e = z - x.