[Phase-1] HIP-XX Create a curated list of Proposers

HIP: <Number to be assigned>
title: Create a curated list of Proposers
author: drlorente97.eth (drlorente97@ethmail.cc)
status: Draft
created: 2022-01-26
replaces: HIP 34

Simple Summary

This proposal seeks to create a decentralized solution to the problem of spam in the official Snapshot of the project by creating a curated list of proposers and repeal HIP-34.

Abstract

By means of the present proposal, we propose the creation of a curated list of proposers by means of a smart contract deployed on the Ethereum mainnet. The Kleros dispute resolution service will be used. The power to make proposals will be represented by an ERC721 token (aka NFT). In order to obtain such a token, a deposit block will be required, using a procedure similar to the one used for registration in Proof of Humanity. The deposit will serve as a guarantee that the proposer will use the Snapshot as agreed in HIP-5 and its possible amendments. Upon implementation of this list, HIP 34 will be repealed.

Motivation

The current HIP-34 solves the spam problem in a very centralized way and is not what is expected from the operation of a DAO. A better and more decentralized solution that also promotes community participation in the Snapshot is possible.

Specification

  • A smart contract will be created and deployed that allows for the creation of a curated list of proposers.
  • Only humans who are part of the registry can be part of the list.
  • To be part of the list you need to block a deposit in Ether, with an amount sufficient to cover the costs of using Kleros jurors and a bounty.
  • A non-transferable ERC721 token will be issued upon blocking the deposit, certifying the bearer as a proposer.
  • Only those who have this token will be able to create proposals in the project’s Snapshot.
  • The reasons for which a proposal may be sued are as follows: “Spam” and “Non-compliant with HIP-5” (and its possible amendments). Text that is not related to the project or that is offensive or disruptive in content will be considered Spam.
  • If a proposer makes a proposal that does not comply with the above, he may be challenged anonymously by having a deposit of the same amount locked by the challenger.
  • Dispute resolution procedure will be conducted in the Kleros courts.
  • If the dispute proceeds, the resulting penalty will depend on the initial motive. If the proposal was marked as “Non-compliant with HIP-5”, the proposer’s token will be burned and its deposit will be used to pay for the use of the Kleros courts and the reward given to the claimant. If the proposal was flagged as “Spam”, it will proceed in a similar manner, but in addition the proposer will permanently lose the right to reapply for that role by having their Ethereum address added to a blacklist in the contract.
  • In case the dispute does not proceed, the claimant will forfeit his deposit and it will be used to pay for the use of Kleros courts and the reward delivered to the defendant.
  • The proposal may only be removed after the resolution of the dispute in the Kleros courts, with the exception of those with prejudicial or offensive content. Proposals will be removed by the members of the official board of the project, with prior announcement in the official channels.
  • The bearer will be able to resign his proponent role and get his deposit back, for this he will make an interaction with the contract which will burn his token and trigger a 72 hour timeout.
  • During this time, he will not be able to create proposals but he can be sued in case he has an active proposal at that moment in the Snapshot that does not comply with the above mentioned.
  • After this time, the former proposer will be able to withdraw his deposit through an additional interaction with the contract.
  • HIP-34 will be repealed as soon as this solution is deployed on the Ethereum mainnet.
3 Likes

I think it’s an interesting idea.
The question I have is:

  • What would be the criterion to be on the list?

I can easily see how it could work as a blacklist

  • Allow everyone to be a proposer if they have a cutoff amount of delegations (it could even start at 1).
  • Use the registry to blacklist proposers. Proposers would be blacklisted if they put an invalid proposal to vote.

But for me it’s less obvious on how it would work as a whitelist.

It could actually work for other purposes. Like we recently saw PoH adoption with Orbis, it could be used to handle spammer lists in social media.

2 Likes

The criteria would simply be that anyone can be part of the white list, as long as they provide a guarantee that they will not engage in malpractice.

This is an interesting idea, it could be checked in the contract at the time of whitelisting, that the proposing candidate has received at least one delegated vote.

I consider a white list necessary because to be part of it is necessary to lock a deposit that will serve as an incentive if the proposer sends spam or poorly drafted proposals (not compatible with HIP-5 and its possible amendments). The aforementioned blacklist is for former proposers who have spammed or sent harmful content to the Snapshot, cannot reapply to be whitelisted.

I believe that there would be no incentive to challenge proponents who engage in these malpractices without a deposit. I do not understand how a reward mechanism could be used using a blacklist.

The idea is for the community to be the one to point out the deficient proposals, thus achieving more decentralization with respect to this issue.

Regarding the latter, I did not know about the adoption of PoH by Orbis, I will look for more information about it.

Thanks for your interest

2 Likes