# Incentivising token lock up for service reward system We want to provide an incentive for token holders to lock up their EWT in order to reduce liquidity and provide an upward pressure for the price. In the long run the return on staking will depend on how many tokens are staked because the rewards is not a variable that can be easily influenced. In this article, I would like to propose a second lock up mechanism that would benefit the users of the services by giving them a discount proportional to the amount of tokens they are willing to remove from the liquidity pool. This scheme is meant for users of the utility layer and is a discount on the price of the subscription. It must not be possible to earn money directly for investors who have no intention of using the service. I understand that this is blockchain and it is easy to create a derivative of a locked token but this is outside of the scope of this document. ## Staking pools We have the following token pools all controlled by the governance ```plantuml [Governance] as gov [Service Provider Staking] as sps [Service Reward] as rew [Service Reward Reserve] as srr sps <- gov gov -> rew gov -down-> srr ``` ### Service Providers Staking In order to become a service provider, a company has to provide a certain amount of EWT as guarantee for the SLA. These tokens are locked as long as the company wants to remain a service provider. Staked tokens can be withdrawn and sold on the open market. The staking mechanism is a way to earn income on the EWT. ### Service Rewards Each user must contribute to the `Reward Pool` before they are allowed to use the service. The users or the organisation which pays for access, can purchase as many usage periods as they whish, in advance. Tokens paid into the `Reward Pool` cannot be withdrawn. As the price for using the service is denominated in fiat, it makes sense to pay in advance if you believe that the token price will diminish in the future. On the other hand, if you think the token price will go up, it makes sense to pay for one usage period at a time as the price in tokens will diminish when it's fiat value increases. Once purchased, a subscription it is not possible to get the money back from the `Service Reward Pool`. The only flexibility is to reassign the subscription to a different user. ### Service Reward Reserve The third token pool serves as a staking mechanism for service users. Service users also would like to get some revenue for their tokens but staking the tokens with the service providers makes the tokens harder to get at when needed. Tokens in the `Service Reward Reserve` will be transferred as required to pay for access for the defined users. Tokens paid into the `Service Reward Reserve` cannot be withdrawn but they can be used to purchase more than one subscription period and they can be reassigned to different users. The EWT in this pool will earn a yield that comes from the reward pool itself as explained in the next chapter. ## Reward distribution For a service delivery period (e.g. one week) the sequence of events is: ```plantuml actor User as usr participant "Reward Pool" as rep participant "Service Provider" as sp participant "EWF Community Fund" as ewf loop for each delivery period usr -> rep: pay for service in EWT group wait for end of delivery period rep -> sp: pay 80% of reward rep -> ewf: pay 20% of reward end end ``` As can be seen in the above diagram, a portion of the reward payout is sent to the EWF community fund. The community has an incentive to keep the EWT price high and hence should devote a portion of the reward to this aim. ### Yield on purchased or pre-purchased subscriptions To achieve the price optimisation effect, the diagram is slightly modified: ```plantuml actor User as usr participant "Reward Reserve" as rer participant "Reward Pool" as rep participant "Service Provider" as sp participant "EWF Community Fund" as ewf usr -> rer: lock up EWT to be used for\nservice subscription loop for each delivery period rer -> rep: pay for service in EWT group wait for end of delivery period rep -> sp: pay 80% of reward rep -> ewf: pay 20% of reward ewf -> rep: transfer 5% of reward ewf -> rer: transfer 5% of reward end end ``` Both the `Reward Pool` and `Reward Reserve Pool` get a kickback from the EWF Community fund. The reason this makes sense is because it incentivises the users to pay in advance, locking the tokens and reducing the number of EWT in circulation. The EWT paid into the token pools are distributed evenly over the token holders proportionally to their holding. To avoid an unfair advantage to whales it is not possible to get more than 100% discount for the next `Service Delivery Period`. Hence there can be an overflow from the token alocation based purely on the token balance. The overflow is distributed evenly between the users. This system reduces inequality over time instead of reinforcing it as a purely pro-rata distribution would. #### Kickback distribution Assuming the reward being paid out is 1'000EWT, the distribution would be: * 800 EWT paid out to the service providers * 100 EWT paid into the EWT Community fund * 50 EWT paid into the Reward Pool * 50 EWT paid into the Reward Reserve The 50 EWT kickback to `Reward Pool` and `Reward Reserve` represent a discount on the next usage period. #### Reward Pool kickback In the reward pool, the users with the longest lease get the most rewards. Assuming 5 users have purchased more than 1 period and the price in EWT for the next subscription period is 4 EWT, the tokens are distributed as follows: * User 1 = 10 periods - receives 10.3 EWT * User 2 = 5 periods - receives 10.3 EWT * User 3 = 2 periods - receives 10.3 EWT * User 4 = 2 periods - receives 10.3 EWT * User 5 = 1 periods - receives 8.8 EWT The more periods a user has purchased in advance, the bigger the discount it receives from the community fund. Up to 100% of the price of the subscription, which is 4 EWT. Hence `User 1` who should receive 25 EWT based on the number of subscription periods purchased, receives the same amount than `User 3` who has purchased only 2 periods and is entitled to 5 EWT. The total spill over of 31.5 EWT is paid out to all users in equal shares of 6.3 EWT. The trouble with purchasing usage periods in advance is that if the price of the EWT increases, the amount paid in fiat is higher than just in time purchasing. It is still interesting to do so in order to benefit from the community fund discount. #### Reward Reserve kickback For those who want to benefit from an appreciating EWT, the `Reward Reserve` provides an opportunity to pre-pay for usage, benefit from the community fund discount and still get the benefit of the price appreciation. For simplicity's sake, we will not consider a price difference in EWT between the two subscription periods. As the total reward is 1'000 EWT there are 250 users paying 4 EWT each. Five of those have purchased multiple subscriptions, leaving 245 in the `Service Reward Reserve` if all users take advantage of the facility. The same distribution principles apply in the `Service Reward Reserve` as int he `Reward Pool`. Assuming following state: * User 1 = 500 EWT - receives 4.02 EWT 100% discount * User 2 = 400 EWT - receives 4.02 EWT 100% discount * User 3 = 50 EWT - receives 0.76 EWT * User 4 to 245 = 10 EWT - receive 0.17 EWT Again the spillover effect comes into play here, givin `User 1` and `User 2` identical rewards instead of 7.42 and 5.93 EWT respectively. The 5.35 EWT difference between the arithmetic alocation and the capped alocation is distributed between all 245 users in the form of 0.02 EWT additional rewards.