In TCP, debt positions and Uniswap liquidity incentives are rewarded with a stream of TCP tokens. At launch, 50% of the incentive stream goes to those that create debt positions, and 50% of the incentive goes to Uniswap liquidity providers.
Users that create a debt position will receive a portion of TCP rewards proportional to that position's contribution to overall debt. For example, on a given day 100,000 TCP token rewards are issued. A user holds a position with 10,000 Hue of debt, and the system has a total of 1,000,000 Hue in debt. The position accounts for 1% of the total debt, and 50,000 TCP are issue to debt position holders (50% of the total as described above). The position holder will earn 500 TCP tokens for that day, which can be claimed immediately by the position owner.
Users that create a Uniswap Liquidity Position for one of the incentivized pools will receive a portion of TCP rewards proportional to that position's contribution to the total virtual liquidity provided to the pool. Virtual liquidity is described in more detail below. Because virtual liquidity is incentivized and not real liquidity, users are incentivized to provide liquidity on a narrow price range. Because out of range positions can be liquidated with a penalty to the position owner, users are incentivized to provide liquidity on a broad enough range that it will always remain useful to TCP. Liquidity position rewards can be claimed immediately by the position owner.
Remember that real liquidity is the actual value of the tokens added to a Uniswap pool, and that virtual liquidity is the amount of liquidity provided between two prices to the Uniswap pool. When adding liquidity to a Uniswap pool, users provide liquidity along a specified price range. Virtual liquidity is always greater than or equal to the value of the real liquidity provided. When the price of the two assets is within the range, the virtual liquidity becomes active. This means that the pool can use the real liquidity provided on that range as if it was as deep as the virtual liquidity. When the price of two assets is outside the range of a position, the pool can not use the real liquidity, and swaps are calculated as if no liquidity was added by that position on that range.
TCP has no use for liquidity that is not in range. As described above, when the actual price of two assets in a pool is outside the range of liquidity provided by a user, swaps are calculated as if that position did not provide any liquidity at all. This means that the position made no contribution to the depth of the liquidity in that range. Therefore TCP does not allow adding liquidity on price ranges that do not contain the current TWAP-ed price.
If a liquidity position provided to TCP becomes out of range, that positions can be liquidated by a keeper. A keeper can point out to the protocol that a position is out of range. TCP confirms this by pulling a TWAP-ed price. If the position is indeed out of range, TCP removes the liquidity from Uniswap at the current price (this will most likely incur impermanent loss that is made permanent by removing the position), and gives a percentage of the real liquidity received back from the pool to the liquidator, and the rest back to the former position owner. Due to this penalty, it is in a liquidity provider's best interest to provide liquidity along a range of prices that will not be out of range in the future.
20m TCP will be issued to users during genesis. The Foundation will evenly split rewards between debt positions rewards and liquidity position rewards as described above.
The Foundation will do so be calculating the rewards values off-chain using a publicly available script that anyone can scrutinize. The primary difference between the on-chain rewards logic described above and the logic used during genesis, is that genesis rewards are given evenly to the owner of each position regardless of how much liquidity or value they have added. This incentivizes early interest in TCP among anyone who supports it, as opposed to only users that hold a significant amount of value.
While the details provided below are complicated, a UI that handles all of this logic will be provided by the Foundation. Users will only need to connect their wallet, set a schedule, and click to claim rewards.
The Foundation does not hold any funds, including the Genesis TCP. Instead the Foundation is able to allows users to mint up to a number of TCP enforced on-chain by issuing cryptographic signatures. These signatures are signed by the private key of the "authenticator account". The signature encodes the batch of rewards (an ID starting at 0), the number of tokens, and the receiver address. The receiver can then call a function on the Genesis rewards distribution contract then decodes that signature to ensure that it was signed by the private key of the authenticator account. Using ECDSA cryptography, the mainnet contract only needs to know the public key (address) of the authenticator account, while the private key stays safely off-chain. The number of TCP tokens that can be minted via this mechanism is capped on-chain.