Open tspoff opened 5 years ago
Balances are snapshotted and merkelized at the start of a claimPeriod
Users, (or optionally claimAgents) submit merkle-proofs to a claimDividends
or allocateDividends
method that calls a verifyProof
helper and transfers after successful verification and hasNotBeenClaimed
checks.
A round goes into a closingPeriod
after a variable roundTime
of blocks and/or a permissioned Avatar calls beginClosingPeriod
.
The round ends after all claims have been made and incrementRound
has been called successfully.
Avatars can optionally configure the contract to allow claimAgents
to submit proofs and allocate dividends for others - and optionally reward those claimAgents
for the service + gas through a claimAgentsRewardPool
I like the idea, It's creative and I feel like it may allow us to stick to our dividend model and keep ERC20 bondedTokens while reducing the on-chain costs (perhaps at the expense of operational complexity).
To see if I'm understanding correctly:
To start a claimPeriod
, someone generates a Merkle Tree from the current state of balances and gets the root on-chain. Who has the right to do this and how is its validity verified? A false merkle root here could be used to drain all dividends I believe.
A claimPeriod
lasts for a specified amount of time. Within this time, users
or claimAgents
can submit proofs to transfer funds to the rightful owner.
What's different during the closingPeriod
compared to the claimPeriod
?
A concern I have is inactivity among the dividend holders. What happens when people don't withdraw and incrementRound
is called?
An article I looked at to understand the solution better is here.
I'm kind of envisioning the rounds being a monthly thing "monthly dividend check".
The permissioned and incentivized claimAgents
is interesting, I'll have to think about it some more.
Some notes from offline discussions:
The Cardstack implementation seems to offer a solid basis for this approach.
By having the merkle tree track cumulative withdrawal allowance rather than allowance just for a claimPeriod
, we can allow holders to claim all past earnings in one tx. As part of this, there will be a mapping for address=>totalWithdrawn in a smart contract to track how much each address has withdrawn.
The merkle tree generation for each claimPeriod
could be outsourced to a trusted computation network
The uploading of a merkle root could be something signed off by the DAO
Good summary of our discussions @tspoff. Will be creating a PR with v1 of the implementation shortly.
Issue
Tracking who is entitled to what dividends at what time requires storage and computational overhead.
Solutions
MiniMe Style ERC-20
➕Can handle ERC-20 payment tokens if sent though a function, like repay()
➖O(logn) loops on transfer and withdraw ➖Large storage overhead
Conclusion: Not preferred due to gas costs, but would work.
ERC-721
➕Can handle ERC-20 payment tokens if sent though a function, like pay() ➕No loops, withdraws simple to calculate
➖Can't split or combine stake without extra logic ➖Can't withdraw multiple stakes at once without a batch function (which we could totally do)
ERC-1843: Claims Token Standard
Conclusion: Won't work, requires a fixed totalSupply()
ERC-1726: Dividend-Paying Token Standard
Only allows ether payments atm. Still evaluating.
Alternative: cOrg style
Rather than distribute dividends directly, we could factor in their value by adding them to the reserve and increasing the values along the sell curve proportionally. This doesn't have the issues associated with the above.
Note: What cOrg actually does in the contract is mint tokens and send them to the beneficiary. This pays the beneficiary, and increases the total supply and therefore the price for other holders.