-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A new DAO approach! #73
Comments
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 (
#73 ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/AAEYL2BA7LRXZP2J4CBMZYDTO7Z6PANCNFSM45K4CYFA
).
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 and @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 notwithdrawBuyBackAndBurn
should 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!
The text was updated successfully, but these errors were encountered: