# Relayer Staking
## Purpose of the System
This module of our project allows a user to mint a renode(nft) by staking Silent tokens and then be able to setup their relayer after bootstrapping their relay service node and be able to stake the renode to finish the relayer setup process. By completing this whole flow, a user’s relay endpoint will be findable on the client frontend.
## Components
We have a mainly two different entities that defines the interaction flow in this module:
1. Operator
2. User (Relayer)
### Operator
**Operator** is defined to an entity that maintains a few system functionalities. For example the operator can add new types of NFTs that a user can mint. NFTs in our system is knows by renodes. An operator can establish new pools , which accepts a new type of NFT as a stake. The operator every month, distributes the revenue that the system has generated to the stakers in all the different pools that exists.
### User (Relayer)
**User** in our system is a actor that helps in running a relaying service for our core protocol users. This user through this Relayer Staking component, does two things at large :
1. Sets up their Relay Service infrastructure and to do this, they mint and stake renodes. Staking their renodes, helps them get whitelisted, from which a user, selects a relayer end-point.
2. Earns a part of the protocol rewards by staking a renode and running a relayer.
For the rest of this spec, we define the main function that the system needs, for it to operate. These are just rough system schematic, feel free to redesign, if felt appropriate.
## On-Chain Infrastructure
We intilaize the system with a few different contracts :
1. renode Bonding-contract
2. renode relayer registry-contract
### Renode Bonding Contract
This contract is the main contract that users can mint renode by spending some pre-determined amount of Silent Tokens.
This contract has the following main functions:
1. **bond**: This contract allows a user to mint a particular renode(NFT) by locking in the required number of token (Silent token)._
2. **addAllowed**: This allows the owner of the contract to define and add new NFT minting options, by allowing the users to stake different amount of silent tokens. This function also accepts a parameter that determines the fees that the contract will charge a user during the unbonding function. This also calls the newslot() in the “renode relayer registry” contract.
**For example** the owner should be able to call a function and say add the option to stake 1234 Silent tokens and mint, “renode of type D” (ERC1155), with an unbonding fee of 12 %.
3. **unbond**: A user can call this function by passing in the type of nft that the user wants to unbond by passing the nft type that the user owns and the amount, and based on the nft type the contract calls an internal function to scan the state of fee for that particular nft type, and then proceed to disband the nft by returning the silent tokens to the owner of the nft only after taking and burning the portion of the fees.
4. **turnoff**: This allows the owner of the contract to turn-off the fee for a particular nft series. When turned off the fee for a NFT series the fee goes down to Zero over a year, every block.
### Relayer Registry Contract
The purpose of this contract is to allow a user to stake the nft(renode that the user has minted and be able to stake the renode in this contract. Each type of NFT will have a different staking pool, where after a user has staked will be able to claim rewards, which comes to them in the form of ETH.
This contract is defined to have the following actions:
1. **stake(type, amount)**: By calling this function a user is able to stake that nft in its particular pool.
A user can call this function and pass a renodes (NFT) that this contract accepts, and be able to start staking their renodes to setup their relayer and be able to earn a part of protocol fees that the system generates.
Through the “renode Bonding” contract we allow a user to stake silent tokens and be able to mint a new renode. The renode that the user mints can be staked into this,”Relayer Registry” contract. People who have staked under this contract, will be findable by the end-user while using our silent application and will be able to use their relaying services. The moment a user stakes a renode (NFT) the user address is whitelisted and the user is eligible to be elected by the user on the frontend.
2. **newslot()**: This is a function that is called by the renode Bonding contract, through an inter-contract call, when the Function `addAllowed` is called, which allows this contract to create a new staking pool for the new NFT-type that gets created.
3. **addReward**: We use this to distribute eth rewards to each new pool for specific period of time.
4. **withdrawRenode**: This function withdraw staked renode from the Renode pool and claim any pending reward for the whole pool.
**Note**: this function withdraw 1 renode at a time and claims all reward for all staked renodes for user in the pool.
5. **claimRewards**: This function claims all pending rewards(pending rewards for the current rewrads cycle and all unclaimed rewards from the past cycles).
Each type of nft in their respective pools, whoever has staked, will stand to receive rewards. If there are three types of staking pool for three different types of renodes(nfts), the owner of the system can inject unique monthly rewards in eth three different times for three different pools and these gets distributed to the the stakers in the pool.
## On-Chain Deployment
To make users to serve as relayer in our system, users need to have **`Renodes`** and stake them into our relayer staking contract.
Once they're staked in our system, they can not only provide relayer service but they can also get rewards for the staked **Renodes**.
The rewards will be distributed by Silent protocol.
Here's the detailed steps for above working flow.
1. Deploy `RenodeBonding` smart contract.
When deploying RenodeBonding contract, needs to specify the `silentToken` address that will be used for bonding Renodes.
2. Adding allowed renodes in `RenodeBonding` contract. (**Only owner**)
In this step, we're allowing some of the available renodes in the platform with `type` and `amount` so that users can bonding available renodes from our platform.
`type`: Particular Renode Type
`amount`: Amount of Silent Token that needs to bond this Renode `type`.
For this step, we're not only adding allowed renode but also create a new pool that accepts this renode (`type`, `amount`) staking in **RelayerRegistry** contract which will be deployed in **step 4**.
3. Set unbonding fee for every renodes. (**Only owner**)
This step will set the **unbonding fee** for the renodes that will be calculated when users unbond their bonded renodes.
i.e:
`type: 1, amount: 100, unbondingFee: 10`
if user unbond the renode(type: 1, amount: 100), then he will receive amount * (100 - unbondingFee) = 90 token.
4. Deploy **RelayerRegistry** smart contract.
In this step, we're deploying **RelayerRegistry** contract which is known as staking contract for renode. It receives `renodeBonding` contract address that deployed in the **step 1**.
6. Set Reward Cycle index.
For adding distributed rewards in the **RelayerRegistry** contract, we need to set reward cycle index first. Reward cycle index is an incremental index for indicating specific reard cycle period.
In this step, pending rewards for members in all pools will be tracked in the contract.
8. Adding Distributed reward for specific renode pool.
Distributing rewards into specific renode pool. The rewards will be sent as `ETH`.