Rugpull disclosure system

[bloated-devish]

Hi BitClout Devs
I wrote a CIP on rugpull disclosure a month ago here.

If there is a core team member who is interested in this, I can covert the content above to the CIP format maebeam wants us to follow. Let me know what the devs think.

Thanks
-Bloated

---

cip:
title: Rugpull Disclosure System
author: Bloated Devish (@bloated-devish)
discussions-url: N/A
created: 2021-07-09

One-Line Description

A method to responsibly disclose Rugpulling (coin owners selling their own coin, often but not always, in an effort to pump and dump) their own coin

Explanation and Motivation

There has been a significant number of people who have been rug pulled recently as of May 2021. Several users have complained that they didn't anticipate the creator selling their own coin. This is especially relevant to new users, who are still learning how creator coin prices work on an Automated Market Maker.

Goals and Non Goals

This CIP will not prevent anyone from selling their coin in perpetuity. This is because there are always valid reasons for creators (or anyone) to sell their coin. This CIP will not prevent any supporter from selling the coin they purchased. From the vision, the core feature of creator coins is to allow fans to be able to support/oppose creator's action with their buy/sell of the coin. The protection this CIP offers can be circumvented by situations mentioned below in the Weakness section. However, in these circumstances, we will anticipate the coin buyers to do the due diligence to cover these scenarios (or anticipate nodes offering tools to identify these scenarios for coin buyers). These scenarios are not differentiable from a legitimate situation where lack of confidence or an action by the creator can cause the coin price to tumble. In such or similar scenarios, this CIP will err on the side of ensuring the original use case envisioned in the vision doc be prioritized.

Specification

Every account profile will have an extra field called RugPullProtectionStatus and RugPullEndTime.

type UpdateProfileMetadata struct {
	...
	RugPullProtectionStatus bool
	// Timestamp at which protection is disabled. Any time >= the field value will have protection disabled.
        RugPullEndTime          timestamp
}

This field will be updated by creators voluntarily and would be available for nodes to display if a creator has opted into it. The default state is false and a creator needs to turn on for the feature to be true. For the top 15000 profiles, this feature will be by default turned on. Turning off this feature will use disclosure mechanism to notify clients that the feature is being turned off.

When RugPullProtectionStatus is not set, then the feature is off. When the feature is turned on RugPullProtectionStatus is set to True with RugPullEndTime unset. When creator intends to turn off the protection, the field RugPullEndTime is set with the actual end time.

The delay between the protection status request to be turned to false and actually enforced is proposed to a minimum of 15 days by the chain (but can be increased by the node operator). Once turned off, none of the disclosure requirements are applicable.

Profile Rugpull Disclosure

Creators can turn on rugpull protection anytime. When this is turned on, the owner's coin sale would be subject to disclosure. A creator can turn on rugpull protection back anytime.

Here are the possible scenarios when a creator can turn it on or off.

• Current status: Status missing and RugPullEndTime missing.
  • On: Possible to turn on. Will set RugPullProtectionStatus to True.
  • Off: No-op.
• Status on
  • On: No-op.
  • Off: Possible to turn off. Will trigger a disclosure and update profile with RugPullEndTime set with a future timestamp.
• Status on with RugPullEndTime set up with future timestamp.
  • On: Updates profile with RugPullendTime cleared.
  • Off: No-op
• Status on with RugPullEndTime set up with past timestamp. (similar to 1).
  • On: Updates profile with RugPullProtectionStatus to True and RugPullEndTime cleared.
  • Off: No-op

There will be no scenario where RugPullProtectionStatus is missing and RugPullEndTime is set.
The effect of toggling to On will be immediate. Nodes will make clear to creator that they can't sell any of their coins the next 15 days (or more based on the RugPullEndTime) when initiating turning off.

Coin Sales

Coin sales can be of the following scenarios:

• Coin sale by the creator of their own coins that they either bought or received.
• Coin sale by supporter, where the supporter received the coin, either from the creator or someone else.
• Coin sale by supporter of the coin, where the supporter purchased the coin.

When rugpull protection is enabled, the disclosure affects 1 and 2. The disclosure does not affect 3 under any circumstance. When the creator tries to sell their own coin, they are expected to first issue an IntentToSell operation for their creator coin.

Disclosure in UI notification

The purpose of these IntentToSell actions is to provide coin holders awareness of rugpull. The notification receivers can understand why this is being done and choose to not take any action, or can end up selling the coins. It is expected that nodes will create a new notification for IntentToSell actions. A simple notification would read "User x is planning to sell upto 29$ of their coins. Learn More"

The remainder of this section assumes that rugpull protection is enabled.

type CreatorCoinOperationType uint8

const (
	CreatorCoinOperationTypeBuy          CreatorCoinOperationType = 0
	CreatorCoinOperationTypeSell         CreatorCoinOperationType = 1
	CreatorCoinOperationTypeAddBitClout  CreatorCoinOperationType = 2
+	CreatorCoinOperationTypeIntentToSell CreatorCoinOperationType = 3
)

+type CreatorCoinLiquidationType uint8

+const (
+	CreatorCoinLiquidationTypeRegular 	CreatorCoinLiquidationType = 0
+	CreatorCoinLiquidationTypeTransfer	CreatorCoinLiquidationType = 1
+	CreatorCoinLiquidationTypeCreatorSale   CreatorCoinLiquidationType = 3
+)

type CreatorCoinMetadataa struct {
	...
	BitCloutToSellNanos       uint64
	CreatorCoinToSellNanos    uint64
	BitCloutToAddNanos        uint64
+	ReasonPostForIntentToSell *BlockHash
+	LiquidationType           CreatorCoinLiquidationType
        ...
+	// Maximum number of coins that are allowed between this time interval. There is no required minimum distribution.
+	MaxCreatorCoinsToSell  uint64
+	SellStartDate          timestamp
+	SellDuration           duration
+	// Applicable when a supporter sells transferred coins.
+	TransferredCoinHolderPK     []byte
}

For scenario 1, the blockchain will first set up an intent to sell, with an appropriate reason, maximum amount to sell and when the sell starts and duration of sell. The coin sale will never be earlier than 7 days from the date of issue of intent to sell. The sell duration is a positive duration (and should not be more than 15 days). If the creator tries to sell more than the MaxCreatorCoinsToSell within the sale eligible duration, the chain will not allow the creator to sell. The chain will sum the sale of coins from the beginning of SellStartDate to check this. The field CreatorCoinLiquidationType will aid the chain in indexing these transactions. The blockchain will NOT allow sale of coins before the SellStartDate and beyond SellStartDate + SellDuration (without another disclosure). Nodes can use the ReasonPostForIntentToSell field to provide the hash to their post, which can be used by nodes to link to the post, with preview on the reason to sell. This field is optional. A creator is not obligated to sell any of their coins in the provided period. They may choose to sell no coins, if their circumstance changes. However, creators cannot withdraw their intent to sell. This is to prevent creators spamming the chain with unwanted intent to sell.

MaxCreatorCoinsToSell, SellStartDate, SellDuration are required fields. When a supporter sells a transferred coin TransferredCoinHolderPK field needs to be set. If this field is not set, then the transaction can only be made by the coin creator.

For scenario 2, there are two requirements that BOTH need to be satisfied:

• Any sale of these coins below 0.1% of the total coin supply will not need any disclosure.
  (AND)
• Should aggregate sale of coins in the last 24 hour window (not calendar window) with the transferred coin sale exceed 10% of the overall supply, the supporter's coin sale will be immediately subject to disclosure.

If requirement 2 is satisfied, if the creator already has a disclosure in place, the supporter will be subject to the same disclosure. If there is no such disclosure, the supporter will be able to create a disclosure to the maximum of the amount that they possess. This disclosure shall also have MaxCreatorCoinsToSell, ReasonPostForIntentToSell, SellStartDate, SellDuration and additionally TransferredCoinHolderPK indicating the public key of the supporter who intends to sell.

When pre-validating this disclosure, nodes need to ensure that:

• The supporter PK is different from the creator PK.
• The supporter has enough coins as mentioned in the disclosure.
• MaxCreatorCoinsToSell is > 0 and at least 50% of the coins they possess.

Supporter intending to sell may be selling only a small fraction of the entire coin supply but still be subjected to the disclosure. Ways to avoid being subject to disclosure would be to reduce the amount being sold and trying again later. Nodes can provide the ability for supporters to schedule sales when the threshold drops below 10%.

If the supporter wants to dump their coins, because they aren't aligned with the creator anymore and they don't want to associate with the creator, the only option then is to transfer the coins back to the creator and lose their share or to send it to a burn address to lose those coins permanently. If the coins that the supporter possesses is transferred from another supporter, they would still be subject to the same rule. This effectively means, coins transferred from the creator in general are less mobile entities than coins purchased, as they are aligned with LONG strategy for the coin. Users who want to support the creator and retain the ability to sell it anytime should prefer to buy the coins rather than obtain transferred coins.

Scenario 3 has no restrictions and the supporter is free to buy and sell the coin the way they desire.

It is possible to have an inflight profile disclosure protection status toggle to false at the same time with an intent to sell disclosure. In real world, there is a good chance of profile update triggering intent to sell for transfer coins.

Sale of transferred coins

To allow easy indexing, coins sold that were obtained as transfer will have an additional bit that indicates this was a transfer sale.

This allows validators to be able to lookup all transactions in the last 24 hours to compute the sale of transfer sales.

Strengths

This CIP effectively creates a second class of coin mobility for transfer coins and creators owning their own coin. It also incentivizes the transfer coin holders to hold the creator coins long term.
It does not force anyone to sell or not sell. The core of the CIP is disclosure and the market may choose to ignore the disclosure because the creator has a valid reason to sell.

Weakness

Situation below is a valid circumstance where rug pulling might still happen, but will not be prevented by the CIP.

• Creator opens account A, FR at 100%. Creators buy their own coin in small quantities.
• Creator creates another unrelated account B (or reuses an existing account). Seeds the account with CLOUT and buys up lots of coins for account A created in 1 above. This is a legitimate way to both transfer CLOUT to A (if the FR is high) and to hold coins of A.
• The collusion between B and A is not public. Other users continue to buy coins of A.
• B sells all of A's coin and cashes out. Coin value drops as the dump was already done.
• A pretends to be shocked.

The telltale sign of this scheme is unknown accounts like B owning large amounts of coins. Scammers can potentially create multiple popular accounts and rug pull all of them at the same time. However, the barrier to do them is high due to the solution above. If collusion between A and B is not publicly known, then this scenario above is no different from the creator coin market reacting to abhorrent behavior by the creator.

Backwards Compatibility

There are no issues with backwards compatability.

Test Cases

Test cases will be created in the core repository and frontend.

Security Considerations

No additional security requirements.

Data Increase

This CIP, if implemented as is, is expected to add x number of additional profile update operations and y additional Intent to Sell operations on the chain.

Alternatives considered

1. Lock up coins: Simply lock up coins for a fixed period of time after the account is claimed. Apply this only for top accounts. This will not help the problem (outside the 15k accounts) and after the "fixed period" expires, as there are nuance here. The creator could send their coins to their other accounts and sell them.
2. Allow orderly sale: Pick the percentile by when they bought and "unravel" the sale, while preventing the creator from actually taking value out of the coin. The price dynamics at that point is severly impaired and is useful when winding up the account orderly.

Acknowledgements

The author would like to acknowledge Nigel (http://bitclout.com/u/nigeleccles) and V (http://bitclout.com/u/v) for their thoughtful discussion in Discord, which lead to this CIP.

[HPaulson]

@bloated-devish It'd be great to convert this over to the CIP template format! I wouldn't wait on core devs.

[bloated-devish]

FTR - I added 2 sections at the end.

1. Data Increase
   I don't have data on this, but I can project the data for this once I have access to some mongodb dump.

2. Acknowledgments
   Wanted to add because those two folks had the original idea - I'm just organizing those thoughts to make a workable CIP.

[HPaulson]

Also, CIP nums are assigned by core team, and should be left as "Not Assigned" until such is approved

[HPaulson]

Okay so, a couple of quick thoughts, which I'll happily expand upon in the morning if need be:

1. I think the idea of deceiving self-sales is a bad one. As you mentioned, there's often very valid reasons why One would sell their own coin. Now, because this feature is optional, this isn't necessarily the case -- however turning such off would likely attach some stigma, and be looked at as negative towards the creator

2. More importantly: Say for example a project does a pre sale, and has such features enabled. If I purchase via that presale, and inherit the creator coin as such, id be listed as a receiver. Now, the project has the ability, at its own discretion, to force me to disclose my sale If id like to make one. Another scenario is someone transferring CCs to their wallet account, which now is unable to sell such without disclosure -- this would obviously effect sale price for larger holdings, creating an unfair market.

It's very late, and I think I have an understanding of your proposal, but please let me know if the above is ignorant or if I missed anything!

[bloated-devish]

Regarding 1 - yes, there can be some stigma - but that's what a good notes should get around. A strong reasoning post on why a sale is being made is critical to give context to coin holders.
Regarding 2 - This is something I spent a good time myself thinking. We'll need to make a balance between "harrassing" holders and preventing rugpullers creating lots of fake accounts to organize a rugpull. I think a much better answer here would be make this tune-able as needed, but set default thresholds today based on robust data analysis (this isn't done yet in this CIP).

Also a general note: every tune-able parameter here has be provided a default value for completeness (like sale below 0.1% doesn't need a disclosure). That 0.1 was completely made up. As we get closer to an agreement on mechanics, we can change these tunable parameters and I don't have super strong preference between 0.1 and 2% yet, since I haven't queried the data myself to see the pattern. A good amount of data analysis and data based justification on the these parameters is still pending and will help me frame a strong opinion :)

I also mentioned in the CIP - all 15k profiles will have this default on. This is a very broad hammer and has lots of product ramifications. I'd like to hear other's opinion on this as well.

On a more abstract note: I see CIPs as closer to law than regulation or executive order (if you get this in context of US laws). DH vision doc is constitution in that context. I'd in general like this CIP - once we agree on the abstract - provide community tunable params that they can vary - if that is at all possible. We can think through this later.

Good night
Bloated

[HPaulson]

Yeah I see your points here -- the whole idea just seems very complex in nature, and even more complex to execute effectively without error. Quite honestly, I think once we start adding consensus-level regulation to trading, even if optional, we could be entering dangerous territory. Just my two cents

[bloated-devish]

@HPaulson I am not going to try selling this as a simple change. This is a complex CIP.

I'm also willing to hear MUCH simpler options, if they exists. If there is one thing I've learnt in my decades of experience as a software engineer, it is to seek simplicity.

I added some alternative ideas, but I'm willing to hear out if there are better ones.

[AikonMishima]

The dynamics of the proposal are solid and well thought through. Though complex in nature, it will require an extra explanation to new comers and novice Creators as to how it works.

The weakness you described will always be a factor, with all coin locking mechanisms. There’s no simple way around it.

In terms of aiding the proof of concept:

• Creator can turn the feature on, with a message on what the feature does exactly, in simple terms (and ofc how it benefits them and their supporters)
• The word rug pull will not be clear to novice users (think of people outside of the crypto/stocks world). So for the code it would not be an issue, but in the UI it should come across as “a way to build trust with your supporters”.

The scenarios for a coin sale are well described. Great work!

[bloated-devish]

For your observation:

1. Do you mean also adding a link to the post to describe in their own words? Or should this be aided by docs.bitclout.com link where this feature is explained in detail - including from the perspective of coin holders (so they can understand what this disclosure mechanism implies).
2. Ack on this. I like - Coin Trust Protection , but agreed we can rename this. I agree rugpull doesn't sound formal. It's similar to if we were to name the Wallet as HODL ;) . Technically right - but ain't looking good.

Thanks so much for your appreciation!

[AikonMishima]

1. Yes, or at least just a pop-up message which briefly explains what this feature would do.
   And Yes, it should be detailed in the docs.bitclout.com as all features should be explained in depth.
2. Indeed! ^.^

[0xNordian]

Wouldn't it be simpler to create a universal rule that when a creator wants to sell their coin, and they trigger the selling action:

1. The request is on hold for X amount of time (hours, days, etc. The community should agree on the time span).
2. A message from the system will be sent to each creator coin holder, warning them that a sell of X amount of CC $CLOUT will occur by X date. [MANDATORY]
3. The seller can include a message to be sent to coin holders to justify the action (this data could be input when the seller triggers the selling action) [OPTIONAL]
4. Both messages will give coin holders the proper time to analyze the selling reasons and decide if they want to keep the position or not.
5. Once the time span is reached, the seller coin gets sold.

@bloated-devish, thanks for the input. This complex and sensitive matter doesn't have an easy solution but must be addressed as a community.

[AikonMishima]

As this new implementation will bring forth a new variable (the customizable message tied to the sale of coins), the latter can be repurposed for the more standard purchase & selling of creator coins.

In an example:

1. You bought my coin yesterday. Today you want to sell.
2. When you sell, an optional message with the repurposed ReasonPostForIntentToSell Is prompted.
3. This var now gets tied to your PK as output.

Reverse:

1. I see it’s your birthday
2. I go to the « buy » page
3. An optional message with a modified ReasonPostForIntentToBuy is prompted
4. I buy your coins with the message « happy birthday »

My logic is that the ReasonPostForIntentToXXX can be directed by the action, in turn increasing its functionality for future nodes / dapps.

[bloated-devish]

Sorry if it wasn't clear - your idea is great @AikonMishima . Your idea should belong to its own CIP (extendable to this CIP so it can be reused by this CIP). Your idea is very focussed on solving a single problem, so has much better chance of passing the muster. I would encourage you to start a CIP. I'll be happy to review and add supporting arguments to your CIP.

[AikonMishima]

Agreed. I’ll create a new CIP, referring to this CIP for repurposing the « message » code.

[bloated-devish]

Thank you for doing it. Added some comments in the CIP. Apologies for the delay getting to it. I missed out that it was there. Lots of CIPs being discussed now :D

[tijno]

Agreed. I’ll create a new CIP, referring to this CIP for repurposing the « message » code.

@AikonMishima when you create the new cip - is it worth considering the "info/description/reason" field may apply to other transactions like bitclout/creator coin transfers.

[omicreativedev]

A user can just DIAMOND ALL their coins to another account. No notification at all.

[0xNordian]

Another good reason to change the Diamonds Value Source 😉

[bloated-devish]

This CIP will cover the scenario where you can send creator coins to another account (either by transfer or as diamonds) and sell it. This is why we cover received coins as well in this CIP. To be honest, adding it has made this CIP much more complicated than it should be, but I'd be dishonest if I wrote a CIP without solving that scenario.

We however don't cover bought coins - this is by design (and detailed a bit better in the weakness section).

[AikonMishima]

The complexity of this equation is the number of ways a Creator can exploit the weaknesses.

This is a first step towards the right direction.

All that needs to be looked at is covering all basis, without it being a disability for those who do have pure intentions.

[AikonMishima]

Just an idea that popped in my head:

Is there a possibility to incorporate a cool down for giving more than half of your creator coin through diamonds?

e.g. if I give @teambrixmusic 50% of my coin holdings through diamonds. A cool down period of 24 hours is now activated.

[bloated-devish]

This is roughly what the CIP does, except it does it when they sell, not when they receive as part of transfer. This is so that we don't want to make the initial transfer exceedingly laborious for the creator and impair the original intent of coin transfer.

[dgsus]

This is indeed a comprehensive setup, I applaud the time and effort taken on writing this idea!

Having said this, I would argue that we shouldn't over complicate the cc mechanisms and we should put our efforts on community education and wait for a coin locking mechanism.

Lastly, this could be something 3rd parties could do on their own designs/ideas for a frontend.
I believe could all be calculated on the background and shown as info on a 3rd party site/service.

[bloated-devish]

@dgsus I agree this is complicated CIP. Also coin locking mechanism will not solve for small creators, who will need to sell on an ongoing basis to fund their work and generate a sustainable source of income for their creative work.

On doing it on their own frontend: I am not sure how that would work. Anyone who is thinking to rugpull will always find another node where none of these exists and they can sell their coin and leave the platform. Any rugpull protection mechanism has to have some enforcement in the core layer, or otherwise, they'll just be window dressing. Remember when you sell, we already get a message saying this will notify all your coin holders :)? That didn't stop rugpulling - may be it reduced rugpulling the first time.

Having said that, I think there are bunch of product questions on this CIP - in the lines of what you are saying.

1. Do we need this now or 6 months from now?
2. Should we enforce this for top 15k accounts or should we just leave this completely voluntary and make coin holders ask their creators to enable the disclosure.
3. In the priority of things that needs to be done - where does this stand? I fully acknowledge even reviewing PRs is a task on core members - should they be spending time on reviewing some feature X (that will bring in more users) or this (that will make quality of life better for coin holders)? I don't think I have the visibility on priority list to make that call. I'll defer this call to @diamondhands0 or others in the core team (although obviously, I'd lobby for this one).
4. Tons of tunable params in this CIP. What is the right values for them? I'd leave a default on this CIP, with guidance (like a colab/jupyter notebook or something) on how to arrive at optimal value, but let the community be able to tune it as real world circumstance change. This is literally a devops discretion.

[dgsus]

Thx for the feedback!

I understand yours points and good-willing motivations but, while I see benefits for the overly trusting investor, i still believe that this is an education and risk assessment own prerogative for every user - who they invest in.

If 1 extra safety/trustless option can be given by having a native coin locking mechanism, I would say that's enough.

imo we should not limit what each one can do in a free market.

ps: This is my main reason for not agreeing for having this implemented. not for being technically complex, that's fine :)

As for a frontend, couldn't this be done with a algorithm and show the info you described on user profiles? not a actionable option but a informative data for who needs it (the rug pulling derived info).

[bloated-devish]

, i still believe that this is an education and risk assessment own prerogative for every user - who they invest in.

This needs to be there, irrespective of whether we choose to adopt coin locking or the disclosure system. Neither this CIP nor education should obviate each other.

imo we should not limit what each one can do in a free market.
Correct, this is exactly why this doesn't thrust this on anyone. Its really up to the creator to adopt this disclosure system. That is why it is voluntary disclosure.

couldn't this be done with a algorithm and show the info you described on user profiles

Nope usually when rugpulling happens, it is pretty fast, the creator sells their coins and they are gone. Note that even this CIP doesn't protect for specific cases, and in those situations, the idea is for the node to provide guidance on various actors. For example, nodes could provide a reputation score (like member.cash has) and apply that to all the top coin buyers - so if there is lots of top coin buyers that are all shell accounts, its suspicious.

native coin locking mechanism

Is this coin holder saying "I'm not selling my coins until 12/12/2021" (or some arbitrary date) and blockchain blocking any sale? These can be easily defeated by transferring coins to someone else and get them to sell them. Also these transfers won't look odd - since they may be genuine creators / influencers who are encouraging their followers. This is also why in the case of coin transfer, we only restrict when the coin is sold, not transferred.

You can also restrict transfers, then they can't use diamonds of larger magnitude and severely impairs product experience for the creator. IMO, all of these thoughts made me to draw this fine line and build this CIP.

[omicreativedev]

I think it's honorable to favor accounts in a way where rug pulling is speed-bumped. I'm just wondering how to do so. Forgive if I sound antagonistic, I'm not. Just very curious.

Many people put in money with an understanding of a previous "come and go as you please" mechanic. Would this cause their current money (invested under a previous mechanic) now be "stuck" for a period of time that they didn't previously consent to?

If so, that might cause a lot of dissent and bad vibes. I think if it was part of the features that come with transitioning to PoS and they were given lots of warning about it, it might have far more rejoicing— because ultimately it protects everyone and is a good idea.

[bloated-devish]

Its fundamentally voluntary. The only clause in my CIP thats "thrust" is for top 15k accounts - where I've said its default on. However, even for them, I'm willing to rethink it. It is a product argument and there are no 0 or 1 positions, just shades of 0 and 1.

When you go to the UI and enable protection, its a voluntary action. Realistically though, your coin supporters are going to ask "when are you going to turn on rugpull protection?" if you don't.

Regarding rollout plan
These can be rolled out with PoS or any other project. It can also be rolled out separately as well. Can also have a 30 day / 60 day notification time before enforcing it for top 15k accounts.

[HPaulson]

Regulating financial actions on the protocol is dangerous in this respect. Protocol-level mechanisms should not act as a method of becoming the SEC. This feels like very, VERY, dangerous territory which I'm not quite sure we should even look to enter. Just my 2 cents

[bloated-devish]

To be clear, this is voluntary. There is nothing here that would prevent people from opt-out anytime (there is a cool off period).

People have no option to opt-out of SEC. This disclosure does.