RCVR- How governance will work
From the offset, RCVR was designed to be customised, based on what the community wants. Now that statement sounds fairly standard for most ERC-20 tokens, but what makes RCVR different and why is itappealing to a niche sector of the Crypto market?
Governance will take place via a snapshot page located on the main website homepage. This is linked to the Rinkeby testnet tokens and proposals are linked to that. I opted for this, because I wanted people to be able to have their say without needing actual valuable tokens, Rinekby fulfils this perfectly.
Please post your ETH address in the telegram and the developer will send RCVR tokens you your address, to exercise the site and participate in governance.
RCVR is truly a community token because of the following features
- The token contracts itself are currently ONLY on the Rinkeby testnet. So why is that a big deal? Well most tokens which people ape into, are already deployed on the mainnet and have hit UNISWAP. RCVR is still very early. The large portion of all the contract code is up and running, but for transparency, I want to deploy the contracts on the mainnet AFTER the community are happy with the contracts and their features. As smart contracts are final, adding features afterwards is not ideal. Transparency is what I am aiming for. The community can say exactly what they want to token to do for them,which will allow greater recuperation of rugged funds. You have a say!
- The community can decide how they want the distribution order to work. Nowadays, the following seems to be the norm, a token is deployed on the mainnet, it is listed on Uniswap, people ape into it. It gets shilled, the token developers then start to taper off on communication in the telegram (Not all projects!), then there appears to be another “token” being released alongside the current one for farming, this then gets delayed or relies on a presale, and from then onwards it either actually does get released or it gets rugged (This has happened to be three times). We are planning to ONLY have two distribution methods : Migration from rugged tokens directly to RCVR (ratio,token to be migrated and limit can be decided by the community) and Uniswap. In what order those occur are going to be governed by the community.
The community can decide on a large number of variables within the smart contracts themselves :
- Enable and Disable Staking Rewards
- Enable and Disable staking per pool
- Price feed to be used to track for Safe Pool rewards (Chainlink feed or Uniswap Price)
- Token to track for the Risky Pool (Default RCVR on Uniswap)
- Timer intervals for the rebases (Safe Pool and Risky Pool)
- The % reward for each rebase in each pool (1% default for both)
- Amount of Tokens to be locked away (If community requests it) and date for release of funds
- The “DeadToken” to be migrated to RCVR. Old DeadTokens are burnt
- Conversion of DeadToken to RCVR Default is 1:1
- Cost of manual force Reward calculation (0.01 ETH Safe and 0.02 Risky ETH default)
- Enable/disable Migration cost
- Migration pool amount
- Risky reward multiplier (See White paper)
- Enable/Disable the migration token lock and the quantity
- The limit of stakers allowed in each pool (upto 256 in each one)
Once the contracts are live on the MainNet, all the above will only be action-ed once the community are happy. That entails, having the contracts verified on Etherscan PRIOR to any UNISWAP trading. The normal procedure is to buy a token and then verify the legitimacy of the developer afterwards. We are aiming for the community to have “driven” the token before we go live with real funds. That will then be the Uniswap or Migration first scenario.
There will be no PRESALE of any kind, this is risky for the investors and not one I condone. I want the community to be happy with the contracts and token before any money flows in it.
