Democratizing Rare Pepe Curation

Summary: The Rare Pepe Foundation is on their way out. This is a formal proposal for how to democratize curation of Rare Pepes in a way that is a continuation of the existing ecosystem. Two Rare Pepes are selected each week to be added to the canon, where one is selected by pepecash-weighted voting, and the other by weighting of pepe card ownership.

Curation schema:

Artists:

  1. Artist designs card
  2. Artist takes card hash, H
  3. Artist burns X Pepecash to a specified burn address with payment ID H
  4. Artists submits H+image to one of the multiple channels available (card submission bot, website)

Votes are divided into two separate categories, where one is weighted by held Pepecash, and the other is weighted by ownership of Pepe cards. In the case where votes are weighted by pepe cards, each card is worth the same number of votes. A cardholder who has a fraction of that card’s ownership gets that fraction of that card’s votes.


Voters sign a sha256 hash of a message of the following format:

{

    Block: xxxx,

    Votes:

    [

        {

            Asset: xxxxx,

            Hash: xxxxx,

            Weight: x.xxx

        },

        {

            Asset: xxxxx,

            Hash: xxxxx,

            Weight: x.xxx

        },...

    ]

}

Where the block number is within  the week’s span (it acts as a monotonically increasing nonce to prevent replay attacks), and the hash represents the hash of one of the submitted images that week.

Voters (curators):

  1. During the week, voters look over the current submissions, choosing and weighting the cards they like.
  2. A message is generated using the above format, and signed by counterwallet or rarepepewallet.
  3. Rarepepewallet signs the message and sends it back, where it is recorded in the current public voting record.
  4. At the end of the week, the card with the highest weight in Pepecash and the highest weight in Cards are both chosen as the ‘winner’ and added to the directory as new canon pepes.
  5. In the case of ties:
  1. If both pepecash and pepecards vote in the same card, then the second-highest weighted card will be selected from either the Pepecash or Pepe card vote pools. If the ending block hash is even, the second-highest Pepecash weighted card is chosen. If it is odd, the second-highest Card weighted card is chosen.
  2. In the unlikely circumstance that two cards get the same number of votes in Pepecash or Pepe cards, if the ending blockhash is even, pick the one with the lower hash. If the ending blockhash is odd, pick the one with the higher hash.

Concerns:

  • The person who runs RarePepeWallet may find some of the accepted Pepes unacceptable (racist, illegal, whatever), and not want to host them. One solution is to implement a blacklist of asset names that are explicitly deemed by the server owner as unacceptable. Then, anyone running a rare pepe wallet server can not host, recognize, or see images associated with things they find distasteful. If someone has a problem with the censorship of that pepe, they can host their own version of rarepepewallet (hopefully Ledger integration will be complete before then).

  • There are concerns of bribery/corruption in a stake-based system, but those concerns exist today as well. It’s theoretically cheaper to pay off a small group of curators than it is to pay off everyone with lots of pepes/pepecash.

Future advancements:

Someone suggested a system where a card is selected randomly, and each vote is a ‘ticket’. This removes part of the ‘guarantee’ of buying priority, making it more of a statistical gamble. The concern here is that it would occasionally allow low quality or ‘bad’ pepes through without a filter.

When voting, consider adding the possibility to vote-cancel. Instead of voting for something, you can vote against something. This allows activist pepe card and pepecash holders to deprioritize racist/illegal pepes without needing to make a choice as to what should supersede them. To mitigate the risk of ‘vote hopping’ at the last minute, the last hour (or some timespan) of T2 can be reserved for cancellations or movements from votes to cancellations only.

Perhaps T2 should be longer than 24 hours, and the cancellation period (T3?) expanded.

Since voting FOR something you want is always more effective than voting AGAINST a competitor, the existence of cancellation shouldn’t be gameable. It's always an inefficient action for someone trying to get a card accepted, so it's only useful when you vehemently disagree with some pepe.

  • Website holder should not have extra privileges
  • Need to query a burn address and get all burns of pepecash above a certain quantity within the interval T1 and extract the payment IDs of all of those transactions
  • Query user’s address and, for every asset, look up in dictionary and allocate votes based on card holdings (except PEPECASH card)
  • Do the same for PEPECASH

If a burn has been made with a particular memo in the past, the address that first burned to it is the only address that can burn in future weeks with that memo.