benwerd
commented
3 years ago I like the idea - particularly the ongoing, self-sustaining nature of it. And I think there's something reusable here - if we/you/someone wraps the method in a nice web interface and open sources that, a lot of projects could potentially make use of it for a similar purpose. I think there's a lot to be said, at the very least, for telling this story in the open for others to follow.
Ben Werdmuller ( http://goog_1933028737 ) werd.io ( http://werd.io ) | @benwerd ( https://twitter.com/benwerd )
(he/him)
On Sat, May 22, 2021 at 11:31 AM, Julien Genestoux < @.*** > wrote:
Until now, the approach we took was using the proceeds of the lock to payout dividends to co-owners of the DAO. And DAO ownership was created by minting new "shares" on every key purchase thru the hook and by leveraging the data attribute.
Paying dividends is hard, because it can only be at a specific point in time, which means the lock has to be "withdrawn" and the proceeds snapshot-ed so that every DAO member can then claim their fair share. This is very complicated and quite wasteful.
Another alternate approach would to create a (Uni)swap pool for the DAO shares. Then, we set the DAO so that any member, at any point, can call a function called withdrawBuyBackAndBurn. This function, when called will withdraw the balance on the lock, take the proceeds and immediately swap them on the pool to purchase back DAO shares and then burn them.
This way, there is no need to create a complicated dividends scheme, as the DAO itself will purchase back its own shares and burn them, redistributing the value back to the DAO share holders.
I would love everyone's thoughts on this, and especially you @ nfurfaro ( https://github.com/nfurfaro ) and @ benwerd ( https://github.com/benwerd )
From an implementation perspective, I think withdrawBuyBackAndBurn should be in a dedicated contract who is both the beneficary of the lock and the lock manager. All functions on this contract should only be callable by the DAO, and any call that is not withdrawBuyBackAndBurn should just "proxy" to the lock contract. (ie. the DAO can call any function on the lock thru this contract)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub ( https://github.com/unlock-protocol/locked.fyi/issues/73 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAEYL2BA7LRXZP2J4CBMZYDTO7Z6PANCNFSM45K4CYFA ).
Until now, the approach we took was using the proceeds of the lock to payout dividends to co-owners of the DAO. And DAO ownership was created by minting new "shares" on every key purchase thru the hook and by leveraging the
dataattribute.Paying dividends is hard, because it can only be at a specific point in time, which means the lock has to be "withdrawn" and the proceeds snapshot-ed so that every DAO member can then claim their fair share. This is very complicated and quite wasteful.
Another alternate approach would to create a (Uni)swap pool for the DAO shares. Then, we set the DAO so that any member, at any point, can call a function called
withdrawBuyBackAndBurn. This function, when called will withdraw the balance on the lock, take the proceeds and immediately swap them on the pool to purchase back DAO shares and then burn them.This way, there is no need to create a complicated dividends scheme, as the DAO itself will purchase back its own shares and burn them, redistributing the value back to the DAO share holders.
I would love everyone's thoughts on this, and especially you @nfurfaro and @benwerd
From an implementation perspective, I think
withdrawBuyBackAndBurnshould be in a dedicated contract who is both the beneficary of the lock and the lock manager. All functions on this contract should only be callable by the DAO, and any call that is notwithdrawBuyBackAndBurnshould just "proxy" to the lock contract. (ie. the DAO can call any function on the lock thru this contract).One of the benefits is that this should considerably simplify the hook!