_Follow along the course with this video._ --- ### DSCEngine.sol Setup Alright! It's time to build out the engine to this car. `DSCEngine` will be the heart of the protocol which manages all aspects of `minting`, `burning`, `collateralizing` and `liquidating` within our protocol. We're going to build this a little differently than usual, as we'll likely be writing tests as we go. As a codebase becomes more and more complex, it's often important to perform sanity checks along the way to assure you're still on track. Begin with creating a new file, `src/DSCEngine.sol`. I'll bring over my contract and function layout reference and we can se up our boilerplate. ```js // SPDX-License-Identifier: MIT // This is considered an Exogenous, Decentralized, Anchored (pegged), Crypto Collateralized low volitility coin // Layout of Contract: // version // imports // interfaces, libraries, contracts // errors // Type declarations // State variables // Events // Modifiers // Functions // Layout of Functions: // constructor // receive function (if exists) // fallback function (if exists) // external // public // internal // private // view & pure functions pragma solidity ^0.8.18; contract DSCEngine {} ``` Time for NATSPEC, remember, we want to be as verbose and clear in presenting what our code is meant to do. ```js /* * @title DSCEngine * @author Patrick Collins * * The system is designed to be as minimal as possible, and have the tokens maintain a 1 token == $1 peg at all times. * This is a stablecoin with the properties: * - Exogenously Collateralized * - Dollar Pegged * - Algorithmically Stable * * It is similar to DAI if DAI had no governance, no fees, and was backed by only WETH and WBTC. * * Our DSC system should always be "overcollateralized". At no point, should the value of * all collateral < the $ backed value of all the DSC. * * @notice This contract is the core of the Decentralized Stablecoin system. It handles all the logic * for minting and redeeming DSC, as well as depositing and withdrawing collateral. * @notice This contract is based on the MakerDAO DSS system */ contract DSCEngine {} ``` > ❗ **IMPORTANT** > Verbosity. I know this may seem like a lot, but a common adage is: `Your code will be written once, and read thousands of times.` Clarity and cleanliness in code is important to provide context and understanding to those reading the codebase later. ### Functions At this point in writing a contract, some will actually start by creating an interface. This can serve as a clear, itemized list of methods and functionality which you expect to be included within your contract. We'll just add our function "shells" into our contract directly for now. Let's consider what functions will be required for DSC. We will need: - Deposit collateral and mint the `DSC` token - This is how users acquire the stablecoin, they deposit collateral greater than the value of the `DSC` minted - Redeem their collateral for `DSC` - Users will need to be able to return DSC to the protocol in exchange for their underlying collateral - Burn `DSC` - If the value of a user's collateral quickly falls, users will need a way to quickly rectify the collateralization of their `DSC`. - The ability to `liquidate` an account - Because our protocol must always be over-collateralized (more collateral must be deposited then `DSC` is minted), if a user's collateral value falls below what's required to support their minted `DSC`, they can be `liquidated`. Liquidation allows other users to close an under-collateralized position - View an account's `healthFactor` - `healthFactor` will be defined as a certain ratio of collateralization a user has for the DSC they've minted. As the value of a user's collateral falls, as will their `healthFactor`, if no changes to `DSC` held are made. If a user's `healthFactor` falls below a defined threshold, the user will be at risk of liquidation. - eg. If the threshold to `liquidate` is 150% collateralization, an account with $75 in ETH can support $50 in `DSC`. If the value of ETH falls to $74, the `healthFactor` is broken and the account can be `liquidated` To summarize how we expect the protocol to function a bit: Users will deposit collateral greater in value than the `DSC` they mint. If their collateral value falls such that their position becomes `under-collateralized`, another user can liquidate the position, by paying back/burning the `DSC` in exchange for the positions collateral. This will net the liquidator the difference in the `DSC` value and the collateral value in profit as incentive for securing the protocol. In addition to what's outlined above, we'll need some basic functions like `mint/deposit` etc to give users more granular control over their position and account `healthFactor`. ```js contract DSCEngine { /////////////////// // Functions // /////////////////// /////////////////////////// // External Functions // /////////////////////////// function depositCollaterAndMintDsc() external {} function depositCollateral() external {} function redeemCollateralForDsc() external {} function redeemCollateral() external {} function mintDsc() external {} function burnDsc() external {} function liquidate() external {} function getHealthFactor() external view {} } ``` ### Wrap Up Wow, what a great start. Hopefully the `stability mechanism` of this protocol has been made clear and the incentives we're providing users to `liquidate` unhealthy positions make sense. If not, don't worry. We'll explain these concepts as we build out the functionality, in more detail. In the next lesson we're going to start with the `depositCollateral` function. Let's get going!