Deactivate insufficiently traded assets

[ManfredKarrer]

Related to the earlier proposal I would like to discuss the policy for filtering inactive coins.

I would suggest those criteria:

• If an asset was added in the last 120 day it is not subject for filtering (warmup phase)
• If an asset was never traded it will be marked as inactive
• If an asset was not traded more than minNumTrades and if it did not exceed minTotalTradeAmount it will be marked as inactive

The question is which values we should apply for minNumTrades and minTotalTradeAmount.
I think minNumTrades=10 and minTotalTradeAmount=1 BTC would be reasonable thought that would lead that we remove most of our assets (only 4 remain). So I think we need to be more tolerant here and rather use minNumTrades=3 and minTotalTradeAmount=0.01 BTC. Those values can be changed over time on

When an asset is marked inactive it is not displayed in the payment account combobox as well in the currency selection in the settings (already selected currencies will stick there). An account with an asset which got deactivated is still valid and can be used. As well offers and trades can be continued. So there is no hard filter. It would make all much more complicate otherwise and would also create more discussions from people who have created an offer and cannot use it anymore.

Beside the filter by inactivity there will be a possibility to vote for removing an asset once the DAO is live.

One open question is how we support re-activation of an asset.
One option would be that a BSQ fee has to be paid to give the asset 120 days warmup phase again.
Assets removed by DAO voting cannot be re-activated anymore.

Here are the list of coins which would remain if we use minNumTrades=3 and minTotalTradeAmount=0.01 BTC and apply it to the last 120 days:

Sufficiently traded assets:
Bitcoin Cash (BCH): Trade amount: 7.2513 BTC, number of trades: 21
Bitcoin Clashic (BCHC): Trade amount: 0.01 BTC, number of trades: 1
Byte (GBYTE): Trade amount: 0.03 BTC, number of trades: 1
Dash (DASH): Trade amount: 0.403 BTC, number of trades: 3
Decred (DCR): Trade amount: 0.20 BTC, number of trades: 1
Ether (ETH): Trade amount: 7.38 BTC, number of trades: 17
Ether Classic (ETC): Trade amount: 0.045 BTC, number of trades: 2
Gridcoin (GRC): Trade amount: 0.0141 BTC, number of trades: 2
Litecoin (LTC): Trade amount: 0.4397 BTC, number of trades: 6
Monero (XMR): Trade amount: 706.2912 BTC, number of trades: 932
Namecoin (NMC): Trade amount: 0.11 BTC, number of trades: 3
PIVX (PIVX): Trade amount: 0.10 BTC, number of trades: 1
Siacoin (SC): Trade amount: 0.0609 BTC, number of trades: 2
Siafund (SF): Trade amount: 1.09 BTC, number of trades: 1
Spectrecoin (XSPEC): Trade amount: 0.642 BTC, number of trades: 7
Unobtanium (UNO): Trade amount: 0.049 BTC, number of trades: 3
Zcash (ZEC): Trade amount: 0.20 BTC, number of trades: 1
ZenCash (ZEN): Trade amount: 0.2224 BTC, number of trades: 4

Insufficiently traded assets (would be removed):
Burstcoin (BURST): Trade amount: 0.0081 BTC, number of trades: 2
Obsidian (ODN): Trade amount: 0.0012 BTC, number of trades: 1

Not traded assets:
10grans (GRANS)
AchieveCoin (ACH)
Angelcoin (ALC)
Arto (RTO)
Better Betting (BETR)
BitDaric (DARX)
BitZeny (ZNY)
Bitcoin Gold (BTG)
Bitcore (BTX)
Cagecoin (CAGE)
Cassubian Detk (CDT)
Conceal (CCX)
Counterparty (XCP)
Creativecoin (CREA)
Cryptonite (XCN)
DSTRA (DST)
Dai Stablecoin (DAI)
DarkNet (DNET)
Decent (DCT)
DeepOnion (ONION)
Devcoin (DVC)
Diamond (DMD)
DigiMoney (DGM)
Dinero (DIN)
Dogecoin (DOGE)
DynamicCoin (DMC)
Ellaism (ELLA)
Espers (ESP)
Exceed (EXC)
GeoCoin (GEO)
Infinity Economics (XIN)
Instacash (ICH)
Internet of People (IOP)
Internext (INXT)
Koto (KOTO)
Kumacoin (KUMA)
LBRY Credits (LBC)
Lisk (LSK)
LitecoinExtreme (LCE)
MFCoin (MFC)
Madbyte (MBYT)
Madcoin (MDC)
MaidSafeCoin (MAID)
Mazacoin (MAZA)
Mycelium Token (MT)
NEETCOIN (NEET)
Nav Coin (NAV)
Nilu (NILU)
NuBits (NBT)
Nxt (NXT)
Octocoin (888)
Particl (PART)
Pascal Coin (PASC)
Pepe Cash (PEPECASH)
Phore (PHR)
Pied Piper Coin (PPI)
PostCoin (POST)
Pranacoin (PNC)
Qwark (QWARK)
ROIcoin (ROI)
ReddCoin (RDD)
RefToken (REF)
Ringo (RIN)
SOS Coin (SOS)
STEEM (STEEM)
Safe FileSystem Coin (SFSC)
Semux (SEM)
Sibcoin (SIB)
SpeedCash (SCS)
Stellite (STL)
Strayacoin (NAH)
Tamadcoin (TMC)
Terracoin (TRC)
The Movement (MVT)
Ubiq (UBQ)
Verify (CRED)
WACoins (WAC)
WILD Token (WILD)
WorldMobileCoin (WMCC)
Wownero (WOW)
Xuez (XUEZ)
Yenten (YTN)
Zcoin (XZC)
vDinar (VDN)

[ghost]

Since I wrote the previous proposal, I thought also on the follow-up, and without speaking with Manfred, I arrived roughly at analog conclusions :

1/ maintain free listing ... but only for the first enlisting. (warmup phase)
So it's up to the candidates to profit from this opportunity, or to waste it.
And nobody can reproach Bisq not being altcoins friendly.
Bisq is altcoins friendly, but Bisq is a living meeting place, not a dead altcoins memorial.

2/ if the first free enlisting doesn't lead to enough trading (or at least offers) and ends with unlisting, then the next enlisting is no more free.
And the payment has to be done in BSQ is probably a good solution for multiple reasons: legal, good for the BSQ token itself, good for the project human ressources if earned BSQ, good for involving the serious candidates and having them as contact, etc.

3/ as for the delays, many solutions are possible, 120 days seems ok, but we may also say that the delay is 2 (or 3) releases.
imo, candidates have to fully integrate the marketing/trading strategy immediately with the listing efforts. If this is not done as a bundle, I see the probability of succeeding as very low.

4/ I found also that fixing threshold is not so obvious. Maybe that instead of fixing such threshold we can just consider the ranking, and eliminate the worst performers. Or a combination of threshold + ranking ?

Anyway, if the listing policy is changed, we need to strongly warn the candidates to not waste their 1st trial.

[ManfredKarrer]

@HarryMacfinned

1/ maintain free listing...

Ah sorry that was not clear from my side. I am not decided on that yet and basically did not consider that we should skip a fee. But your arguments have some value.

3/ as for the delays...

Release dates are not so reliable, so I would prefer to not use them.

4/ I found also...

Ranking is hard for them to get a clear metrics as it changes dynamically. I think its more predictable with fixes metrics like nr. of trades and volume.

Another idea might be to have the warmup phase and the BSQ fee connected. E.g. For each BSQ you pay in fee you get a day of warmup phase. So the argument from coin issuers who are doing a valuable coin but have not much funds for paying a high fee is solved as anyone can pay a relative low fee and if there is no trade activity there is no reason why they need an exchange.

Requiring a BSQ fee at listing time also adds friction/mental costs which helps to filter out "spam".

I need to figure out the technical implementation for the fees. Basic idea is to have a special tx with a n opReturn where the hash of the tickerSymbol is in the data. So we can look up when the tx happened and check the hash. Anyone can do the fee payment.
That scheme could be more generally used or proof of burn. One can keep a pre-image of the hash and proof that he was the one who did the burning (e.g. for reputation). With signing a nonce from the input for that tx he can proof that he is was the originator of the tx.
@sqrrm What do you think?

[ManfredKarrer]

I created a new issue (#42) to discuss the fee or a voting model to not mix too much aspects into that issue. So that issue is only about deactivating an asset if it is not traded.

[cbeams]

I propose the title of this proposal should be "Deactivate insufficiently traded assets". Manfred, please change it to that if you agree.

@ManfredKarrer, I'm glad you've separated out #42. With the listing fee question out of the picture here, I'm giving a 👍 to the proposal, with the understanding that the deactivation is a soft filter (logical not physical deletion) and that the specific parameters can be adjusted over time and over releases. I'd say let's go ahead with this asap.

[ManfredKarrer]

@cbeams Thanks for the suggestion, I changed the title.

Yes I implemented it already and will probably move the parameters to the DAO params so they can be changed with voting.

One aspect to consider is that there should be a way to re-activate an asset, so thats where we get to #42 again and even those are separated here they probably should have at least conceptually a holistic solution.

[cadayton]

Just an outsider prospective. Might want to factor in rankings outside of Bisq and the impact upon new and existing customers. For example, I would think a coin in the top 100 trading volume but 0 trades on Bisq would not be candidate for removal.

[ManfredKarrer]

Yes i was thinking on that as well but there are no clear metric. There are quite a few "scamcoins" in the top 100 and market cap can be manipulated quite easily. I think if anyone is interested in trading a coin the barrier to get that added might not be too high.

I think we really need to be aware that the main problem is not the quality of a coin but that it is basically very difficult to get a market started and to gain enough network effects.

[sqrrm]

I support the idea of removing (or hiding) assets that are not traded using a fixed metric. Relative ranking does not sound predictable enough.

A way to re-enable would be to have a command line flag to enable a removed asset. Then anything not traded for a while would be hidden it would still be possible to trade it for those that really want to. It's also a way to re-enable the coin for default visibility if there are enough supporters that can be bothered to use the command line flag.

@ManfredKarrer on the topic of proof of burn, that sounds reasonable. I think it's a topic for a different proposal though, or more likely a technical discussion outside of proposals.

[ManfredKarrer]

Not sure about the command line flag... I think that jsut adds confusion and we don't want to support to work around the filtering...

[sqrrm]

I agree that we want to avoid confusion. My thinking is that only those that really want an asset to be visible for trading would bother with the command line flag and if they actually do enough trades the asset will become visible and shown as per normal. This way de-listing really just means hiding the asset and it will be visible again if a market that the asset appear. With a good doc on when assets are hidden or visible I don't think this would generate a lot of inquiries. Not many people would care about the hidden assets, that's the reason they're hidden. I also think it would generate less animosity to hide rather than inactivate an asset.

An asset removed by DAO vote should be properly removed though to make sure trading is not supported at all in the software.

[ManfredKarrer]

Ok. I am open to it, but I think its not worth the effort. But if anyone wants to implement that why not.

[ManfredKarrer]

I think the delisting inactive assets found sufficient consensus. It is implemented in bisq-network/bisq#1861 and will be soon merged. I will close that proposal.

[TheHungryRaccoon]

My favorite coin has been delisted. How much is the relisting fee?

[m52go]

@TheHungryRaccoon 1 BSQ per day. See details here:
https://docs.bisq.network/exchange/howto/list-asset.html#fees