GIP Post Guidelines

The following guidelines will compliment the details outlined in our gitbook document here:

  1. 48 hour last call before snapshot. The last call should be announced in the discord governance channel for publicity; enlisting the aid of a mod if need be.

  2. A notable exception would be technical rollouts, or product contract upgrades.

  3. During the “Last Call”, each GIP should clearly state what the voting option will be. The last call post should also indicate any edits which have been made from the original due to the discussions in the forum. If the proposal is significantly amended during last call, the author should respect the flow of the discussion and delay the snapshot accordingly.

  4. The snapshot for any motion will be raised by the core team, this may change in the future (incl long standing / voted in community members).

  5. If a proposal outright fails, the author should indicate whether they intend to repost the GIP after editing its contents with community input. If the edited points required of the failed GIP does not exceed a majority of the original proposals, then the GIP may keep its original GIP number, add “GIP-xx amendment 1” to its title, and may proceed directly to last call. Though if the edits required were so substantial that a majority of the original proposals have been changed, the GIP number would be scrapped and it should restart from scratch on the forum.

  6. If a proposal passes, the authors should indicate if they would like to make non-substantive edits as soon as possible, and outline every edit from the proposal that has passed the snapshot.

  7. The DAO will veto votes if they satisfy any of the following criteria:

  • The proposer or payload is unknown.
  • Proposal which distributes DAO Treasury or incentives to voters on the basis of their vote (bribery proposals)
  • Proposals which add admin control to untrusted accounts
  • Any veto authorised by a DOUBLOON snapshot that reaches quorum and has at least 24 hours duration (mostly applicable to OA)
  • A proposal which contains a security vulnerability, either disclosed by core team or community member, and verified by any third party such as audit firms, security researcher, or community members.

Proposals that blatantly disregards these guidelines should be rapidly informed as such by community members. If the authors do not respond to valid inquiries of procedure, and outright circumvents governance practices, the proposal could be subject to sanctions such as non execution by OA approval, or veto by the DAO.