This is the official discussion thread for RPIP: Enable pDAO Spending of ETH and ERC-20. Discussion in Discord is in the governance channel.
This proposal is basically just about ensuring that pDAO can actually spend the ETH if it decides to change pdao_shareto not 0.
Thanks for doing this.
Just repeating my opinion here, even though it is in the discord thread:
People might not be aware that as of now, the treasury can take ETH/ERC20, but can only spend RPL. In Saturn 2, we will have the possibility to turn on pdao_share which will give the protocol the ability to collect ETH commission. Taking it without being to get it out would be unwise, imo.
There is also the less likely but not impossible scenario where a third party wants to pay the DAO in some other token than RPL (or someone accidentally sends something there) and it would be nice to get it back out. In the past, we have had parties interested in direct pDAO payments (unfortunately, we had to turn those down for legal reasons but that might change in the future).
The team has expressed that this is not a particularly complicated change to make, so better to do it now and test it before turning on pdao_share and finding out there is an issue of some sort and trapping that ETH.
A small yet necessary addition. In addition to being able to spend all types of funds received from external parties, also future-proofing in case the treasury wants to convert and hold part of its RPL earnings in stablecoins at some point.
Will the ERC-20 spend route replace the current RPL spending method, or be added separately?
This is more of an implementation detail, but in maintainability terms, I think a single ERC-20 route that replaces the current RPL-only would be nicest.
Yes, I think a single route makes sense. I was a bit worried about how to handle existing recurring payments at the time of the change. It may be easiest to have a transition period where claims for legacy recurring payments still work, but new payments use the new route. And then the legacy route can be completely removed in a future upgrade. Maybe @kane has a better idea how to handle this. For now I just kept it vague so that there is flexibility to come up with something sensible during implementation.