manumonti
commented
1 week ago The current approach is to have three claim functions that a stake can call:
claimMerkle(...)that will claim the rewards generated using Merkle distribution. I.e., the rewards that come from tBTC application.claimApps(...)that will claim the rewards directly generated by the applications. At this moment, TACo.claim(...)that will claim both types of rewards.
But this can be problematic:
The claim(...) function has as arguments those values related to a Merkle distribution: Merkle root, Merkle proof, and cumulative amount. But it may happen that a stake only runs a TACo application, so this stake won't have tBTC rewards. If no tBTC rewards are calculated, this stake won't be part of the Merkle distribution, so there won't be a Merkle proof to be passed as an argument to the claim function.
Two solutions are possible (if not more):
- Adding this stake to the Merkle distribution with 0 tBTC rewards so a Merkle Proof will be generated.
- Adding an if statement in the
claim()function so if the Merkle Proof is null (or zero address), only the applications (TACo) rewards will be claimed.
cc @cygnusv
Once we introduce rewards in the TACoApp contract, this will produce a fragmentation of the rewards between other apps (tBTC & RB, currently on the MerkleDistribution contract) and TACo. In order to eliminate this friction from a staker perspective, we should allow the MerkleDistribution contract to trigger withdrawing rewards to the beneficiary.
In addition to the changes mentioned in https://github.com/nucypher/nucypher-contracts/issues/244 to the TACoApp, we'd need a new MerkleDistribution contract that performs this call. This issue includes also the migration of approvals from the ClaimableRewards proxy contract owned by Threshold.