Oracles,RCVR and your rugged tokens
Whilst developing and creating the smart contracts for RCVR, it became quite apparent early on, that its like trying to shoot a fish in a barrel. The concept seems clear cut, but the barrel is getting deeper all the time, there is more fish (rugged tokens) getting added all the time and your gun barely makes a dent in the fish.
So I had to work smarter, instead focusing my efforts on a single fish, I needed to design a system whereby all of the fish could be shot at the same time.
I know I may be rambling abit, but this is where the idea of a Rug Migrator comes in.
What exactly is your proposed Rug Migrator?
The rug migrator is a smart contract which will do the following:
- Parse the users wallet for all supported Rugged tokens.
- Determine whether the user was a holder at the time of the Token Info Contract going live (More about this later) or is blocked at Token level, e.g Dev wallet
- Determine if the user has migrated previously
- Retrieve the assigned swap rate for the token and ensure that the users deadtoken balance is enough to convert.
- Determine the amount of RCVR eligible and add it to the amount to be claimed.
- Transfer the “DeadTokens” to the TokenInfo Contract directly or send them to a burn address.
- Repeat until all supported rugs are processed.
- Create a vesting period for the user and pay out 10% of the total at migration
The above will allow RCVR to process as many tokens as we can configure, so as a new rug enters the system, we can add it and it can be available immediately for users to migrate from. Currently we have a manual whitelisting process, this is cumbersome and time consuming, whereas the above is automated and dynamic.
The above will also allow the user to migrate legacy rugged tokens to RCVR without a manual whitelisting process.
That sounds good, so how does the Oracle and the Token Info contract fit into it all?
After looking at the amount of data that would be needed to accommodate this, I decided to fragment it. Having an array in the migrator contract for ALL the holders of every single rug token etc would lead to a very big array and a big contract. So I opted to to break each scamtoken down into a seperate Info contract and then add the holders for each token in this contract.
Now with that we need an interface to harvest the data when we need it. This is where the Oracle comes in. Think of it like an SQL server, it has a RUG database and runs queries. The individual Token Info contracts are the SQL tables.
The migrator contract asks a question and the Oracle goes off and gets the data and feeds it back, all across the blockchain.
Here is a schematic of the planned infrastructure:
The main reason for the Oracle is to query the holders of the rugged tokens at Snapshot.
So the Info Tables will hold a list of holders, can you elaborate on why you need this.
As we are operating a charitable token, we need to ensure that we implement measures to ensure that the migrations are fair.
At the time we deploy each Token info contract, we will gather a list of holders at that moment in time. This allows us to automatically whitelist valid holders to ensure that new users dont buy XXXXX token amount and attempt a migration. That way they could just buy and migrate. An address is needed to be on the whitelist in order to migrate. This holders list will get imported into each Token Contract via a python Mass Importer script.Each address can only migrate ONCE.
When a user migrates a query is done to ensure the following:
- The user is a holder of the token at snapshot, if not it goes to the next token
- The user has not already migrated
- The user is not blocked at TokenLevel e,g Dev address etc
- The users deadtoken balance is over or equal to a required limit. As much as we want to cater for everybody. Depending on the supply,0.0001 of the token is not worth migration to.
So how do payouts work? Surely ill qualify for a nice payout if I have a lot of rugged tokens.
During the “migration loop” your redemption amounts for each token are accumulated. The community decided that the max payout amount for ALL the rugged tokens will be 800RCVR in total. So once the migration process is done. you will get paid out 10% and then you can claim 10% each day for 9 days. So 80RCVR initially and 80RCVR each day for 9 days.
What happens to my “DeadTokens”?
Depending on the type of rug, e.g liquidity/softrug and a non-transfer type rug. We will collect the deadtokens out of your wallet and either burn them or send them to the relevent token Info contract. The latter will allow any user to view the amount of the deadtoken collected for transparency. We do not want to sell these tokens, we just want to ensure that a doublespend cannot take place.
This seems like a great idea, so what are the deadlines or ETA’s on this?
The Oracle contract is done and the into contract is done too. The Rug Migrator is being coded and integrated and then testing is due to be started on the end to end process. (As of 2-May-2021). Please join our TG channel for updates from the DEV.
