LiquidPledging Donor Permissions
Previously, we were limited to static permissions for a given method, that would be applied to all calls. Now that we're using AragonOS this us to have complex and dynamic permissions for a given method.
One concern that has been brought up is money laundering... I think it would make sense to have a "DONOR_ROLE" permission that can be used by projects/delegates (and givers?) to restrict who they receive donations from.
By default, delegate/campaigns/milestones would accept donations from anyone. For delegate/campaigns/milestones who want to follow KYC procedures, they would be able to "whitelist" specific givers. Since lp now works w/ any ERC20 token, the delegate/campaign/milestone can "whitelist" select tokens, instead of accepting any token.
I wanted to get feedback on the above. If you think a "Donor Role" makes sense please give feedback on the following as well:
- should Givers accept donations? If so, should they accept donations from anyone or just themselves? 1 use case for accepting from themselves is to "deposit" funds into the Giveth system, for later transferring. We do this in tests, but I'm not sure it is a valid "real-world" use case.
- A "PledgeAdmin" is an entity who controls (transfers, withdraws, etc) a "Pledge". This can be a single user/contract (addy), but can also be many users/contracts (addy) due to the new permission system. Knowing this... when whitelisting possible donors, is it more useful to authorize a "PledgeAdmin" or the address that is sending the donation tx? Or should we allow the ability to authorize either one?
Griff Green · Mon 19 Feb 2018 7:35AM
The DONOR_ROLE does make sense... I don't know if its a feature that needs to be added in right away, if it can be added later that would be best, lets keep this first version as simple as possible. If not then yeah, add it now, having a closed funding round has lots of applications, and being able to whitelist only the tokens you want will need to happen.
The Smart Contract should be as flexible as possible... we can limit features we dont like in the UI, but leaving this functionality might come in handy some how for some random DAC down the line.
Hmmmmm!!! That's interesting. The Pledge Admin makes the most sense at first glance... but I fell like there is a potential Gotchya issue around one address being multiple Admins and then being blocked because maybe they are acting as one admin instead of another... that might be desired behavior... but maybe not.... If it can be done cleanly, both of them would make sense, I really think keeping as many options on the table as possible is the right design choice... as long as it is elegant. If not then just the address is my intuitive feeling.. but this one is a crap shoot, you prob have the best perspective to make this decision. I just hope the contract doesn't get too crazy.