Skip to content
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.

Sign up for GitHub

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

Grammatical suggestion #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Grammatical suggestion #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion MCV-Whitepaper.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -431,7 +431,7 @@ RageClaims relating to a SAFT may end up being redeemable for either the exiting

As discussed above under "Grimoire," a member may "RageQuit" (voluntarily resign as a member), in whole or in part, at any time, by calling the RageQuit function with reference to a specific number of the member's shares. A partial RageQuit is a reduction in shares. A complete RageQuit is a resignation of membership. In most cases, a RageQuit or RageKick will work seamlessly. However, there are several game theoretical edge cases that are addressed with MolochDAO v2: 

Because there is an up to two-week delay between a proposal being voted on and being fully implemented (voting period of one week, grace period of one week), a member could vote to approve various proposals which adversely impact the other members and leave the DAO without experience the consequences. This effectively means that members were directing proposals with funds they were not entitled to managing, and thus a potential source of conflict and moral hazard. Members are not allowed to leave the DAO if they have voted "YES" on proposals that have not been fully processed.
Because there is an up to two-week delay between a proposal being voted on and being fully implemented (voting period of one week, grace period of one week), a member could vote to approve various proposals which adversely impact the other members and leave the DAO without experiencing the consequences. This effectively means that members were directing proposals with funds they were not entitled to managing, and thus a potential source of conflict and moral hazard. Members are not allowed to leave the DAO if they have voted "YES" on proposals that have not been fully processed.

Moloch DAO v2 smart contracts are dependant on the external ERC-20 smart contracts controlled by third parties, therefore we must always hold the assumption that the smart contracts that MCV calls, are at all times untrusted and potentially adversarial. An example of this would be with a whitelisted GuildBank token that happens to blacklist an existing DAO member. In this case, if the blacklisted DAO member attempts to RageQuit, the RageQuit function will revert and result in an error as the GuildBank would be unable to call the transfer function to distribute the adversarial set of RageTokens to the blacklisted DAO member. As a result, the DAO member will be unable to leave the DAO. In order to deal with this problem and preserve the power of free exit (while also honoring any potentially important third-party restrictions that may have been imposed on a member for legal reasons), MolochDAO v2 includes a SafeRageQuit function. By calling SafeRageQuit instead of RageQuit, a quitting member may (by setting the parameters) choose to avoid receiving the problematic type of RageToken, but still receive all the RageTokens and RageClaims from which the member is not blacklisted. 

Expand Down