Basic Vault
Opened this issue · 0 comments
devtooligan commented
Exercise name: Basic Vault
Assignment #: 2
Testing framework: Foundry
Deployment framework: Foundry (forge create)
Node provider: Infura
Target network: Rinkeby
Assignment summary
Users can send a pre-specified erc-20 token to a Vault contract. The contract records the user's balance. Only that owner can retrieve their tokens. Think of this as a multi-user safe.
To complete this you will need two contracts, one of them a ERC20 token that will be moved around, and another one the Vault that will store it for the users.
- Vault should import the IERC20 interface, take the Token address in the Vault constructor, and cast it into an IERC20 state variable.
- The user approve the Vault to take Token from them in one transaction.
- The user calls a function that instructs the Vault to take from them an amount of Token, which now belongs to the Vault, in exchange, the Vault records the user's deposit.
- Whenever the user feels like it, it can withdraw its deposit. The Token is returned, and the Vault updates its user records.
- For testing this (and later for playing around with it on Etherscan) create a ERC20 mock contract. Don't worry about understanding every detail of this contract, it is more important at this stage to understand the Vault and the interaction with the vault. Be sure your ERC20 mock has a public, unrestricted
mint()
function that will allow you to mint tokens to any user (of course we would not do this with a real token, but it is useful when testing). You can import or just copy and paste https://github.com/yieldprotocol/yield-utils-v2/blob/main/contracts/mocks/ERC20Mock.sol Pick a fun name and symbol for your token! When I did my first vault I made Toolie tokens symbolTOOL
😄
Additional Details
- Add full NatSpec. This means the contract as well as every event and function should have complete NatSpec. This might seem a bit overkill at first, but do it anyway. Writing a complete NatSpec should become second nature for you and then at that point you can start deciding to omit certain things. For now, contracts should have @title, @notice, @dev, @author. Functions should have @notice, @dev, @param, @return. Events should have @notice (no need param or return).
- Of course, your contracts should be fully tested. (Meaning the vault contract, don't worry about testing the erc20 mock contract)
- Deploy to Rinkeby this time, and verify your contract. You should deploy your token as well, and be sure the token has a mint function that is public and anyone can mint themselves tokens. After you deploy, go on to etherscan Rinkeby and play around with your newly deployed contracts. Mint yourself some tokens and deposit them in a vault, then withdraw some.
- For this (and future) exercises, please install forge-std which is in the foundry-rs repo.
forge install foundry-rs/forge-std
This gives usconsole.sol
for console logging, some additional cheat codes, and error types. Please read up on and experiment with some of these forge-std cheats and other new tools. - Implement CI so when you push to gh, your tests are run automatically.
Peripheral Goals
- Tenderly is a powerful tool that can be used for many things. At Yield we use it for monitoring/alerts as well as for simulating transactions before running them and also for reviewing transactions after the fact. Create yourself a free Tenderly account. After you have deployed your vault and done some transactions via etherscan, go on to Tenderly and inspect one of those transactions. There is also a debugger (similar to Foundry debugger) that allows you to step through opcodes. If you're up for it, try simulating a transaction as well. Here is a video of Alberto demo'ing Tenderly.