Keep your ENS name safe using automatic renewals
💎StakeYourName💎 takes existing tokens or assets the user is holding onto and leverages them to pay for low-cost subscriptions. This project initially deposits into 💸Aave📈 and can be used to keep an ENS name renewed. In the future this could be expanded to use other means of income, such as ETH2.0 staking rewards, as well as providing payment for other services . When the user deposits an asset into StakeYourName the contract will create a user ‘Vault’, this is a copy of a master vault contract that is cloned for each user, this way they can access their Vault directly to check on their assets and what the current configuration of paid for services is. This method also allows for vaults to be upgraded in the future to support other functions. Currently the process to check for and pay for renewals is manually activated, however the plan is to integrate into the ⏰Ethereum Alarm Service⏰, this will allow firstly the StakeYourName contract to schedule itself to run renewals at designated blocks in the future, but also the alarm service would be an ideal candidate for users to be able to fund in order to run their own contracts automatically.
How it's made
Most of the effort has been put into the backend solidity code, probably to the detriment of the project as a whole. It was unexpected just how complex this project would become. There were 2 major themes to the problems in this project, one being the number of different integrations required to get everything working, the other is the amount of data required and how best to store and access it. The data problem was mostly solved with the creation of the user Vault system which stores the data relating to that user in their own contract, this will allow for easy upgrades of the main contract while only having to copy of the list of users (the list of vaults can be derived from this). This is a two-fold benefit as it means no need to calculate user balances or the interest they earn because their balance is simply the balance of tokens on the vault contract. Testing the various integrations was very difficult, the ENS service has a test setup on Ropsten but it’s for testing name resolving not the renewal process which means all the names on there are free to register. 1inch doesn’t have a test setup which makes sense as it requires all the exchanges to operate, however another complication is that 1inch lists documentation for lots of options on exchanging tokens but actually only implements 2 functions, getExpectedReturn() and swap(). Most notably there’s no way to ask for an exact return amount, ultimately a system was designed using a Chainlink oracle to get an estimate of the tokens that will be required to be exchanged, without this an accurate exchange rate could not be established because if you put in a value that’s too low on 1inch you hit rounding issues and a value that’s too high you hit liquidity problems. After the estimated return was delivered from 1inch some calculations were performed to get to an exact return value. This means for an individual user StakeYourName can exchange the exact number of tokens required down to 1wei accuracy. For a multi-user exchange the division of the funds means the accuracy is at worst n-1 wei, where n in the number of users in the exchange. Aave and Chainlink both have functioning test deployments on Kovan so ultimately the decision was made to use Kovan for this project, this required writing contracts to simulate the ENS functions and the 1inch functions. The 1inch exchange rate was simulated by using an historic value from the Chainlink oracle price, this was done to test the contract handling getting different exchange rates directly from Chainlink and via the simulated 1inch. A nice hack that was implemented was the way of fetching the Chainlink oracles, because any Aave supported asset can be used and new ones may be added at any time it wasn’t ideal to have to keep updating a list of oracles. Chainlink have a defined naming system for their price oracles XXX-YYY.data.eth where XXX is the origin token and YYY is the destination token, by using the erc20.symbol() call the symbol for any token can be retrieved, this is however always in uppercase and Chainlink (and ENS) always use lowercase, to do the change the string was converted 1 byte at a time to a uint and 32 added, this converted the ASCII characters to their lowercase versions. The string can then be assembled with the hyphen in-between and because we already have ENS integration the address of the oracle located.Technologies used