MSC-denominated fees for using advanced features of other currencies

[ripper234]

Everyone and @dacoinminster feel free to edit the title & body.

This issue is a brainstorming pad for how we can charge MSC fees across to board, even for users who don't have MSC. The suggestion is that whenever an MSC fee is required for an operation in a non-MSC token e.g. MaidSafeCoin, then that operation will automatically purchase MSC on the Decentralized Exchange and then immediately burn that (or send that ... but most of our fees involve burning and not sending).

To clarify - the fee isn't for just using a currency, but will go into place anywhere that 'advanced features' are invoked ... e.g. the betting fee that goes to the publisher of the data stream, or fees for promoting smart properties.

[dexX7]

I'd welcome mechanisms which don't affect user experience. Say for example I'd go ahead and distribute the faucet promo coupons I once created. It would probably be a real pain for new users, if it were required to buy MSC first to redeem those coupons (due to an implicit requirement of a MSC based transaction fee).

Another note: fractional amounts introduce the need of clarification of percision as well as the handling of edge-cases. See the lengthy discussion about indivisible tokens and the meta-DEx for example.

Nevertheless I think MSC based fees are a good way to monetize MSC.

[dacoinminster]

So, this is a very important idea Ron Dom had, which I think is downright revolutionary:

Users don't have to hold or use MSC in order to burn MSC.

We can take a fee out of the currency they are using, sell it on the dEX for MSC, and burn the MSC.

So for example, somebody places a bet using USDCoin. A fraction of a percent of that USDCoin is automatically sold on the dEX for MSC, which is burned.

This requires no extra steps for the user, and no extra data in the block chain. The user's TX is recorded, and the fee and burning happen automatically in our databases.

One corner case has been raised so far (by Michael): what if there are no MSC available on the order book?

Answer: the coins taken in fee follow the logic of any new order, and become an active sell offer requesting 0.00000001 MSC, where the MSC goes to 1MasterCoinEater.....

Folks, I honestly believe this is revolutionary, and provides a clear path to using any currency in our ecosystem without fear that MSC will lose value as a result. This is an extremely elegant solution, and I give maximum kudos to Ron for thinking of this.

[dacoinminster]

I anticipate this fee will be used for every TX which is not using MSC (except for simple send). So, dEX between MaidSafeCoin and USDCoin would burn MSC automatically, as would bets between people using EuroCoin, and distributed e-commerce between people using YenCoin, and voting by holders of BlahShares, and any other feature we dream up.

I'd love to get consensus across the team that this is the way we should go, as I think this would make a very positive blog post announcing this. I've already got it half-written in my head, and I'm dying to get it out. :)

[dacoinminster]

I'm going to suggest 0.3% across the board for this fee, with the exception of voting, which should probably be way lower. Our liquidity bonus is also suggested to be 0.3% in another pull request Marv is working on.

[ripper234]

FYI we want to set any magic number like 0.3%, by protocol-level voting. So MSC holders will be able to vote and automatically adjust this 0.3% figure without any code change.

Of course let's start with something manual in the meantime.

@petertodd I think you'll like this one.

[dexX7]

You imply that a "vote" is a specific transaction rather than a simple send of smart properties. I object - smart properties are not only coins, but general purpose "things" such as special unlock keys for member-only areas, coupons, ownership representations or.. vote rights. I'd rather like to see a suggestion like "there is a special transaction which issues vote right tokens to every MSC holder". I'm open for discussion, but so far I haven't seen a valid argument against using SP for this. :P

Ron, awesome idea! A few questions:

• How are small/indivisible amounts handled? E.g. I sell 10 IndivisibleCoins whereby 0.3 % of those IndivCoins are below 1.
• What is a fair price for this automated order and how is the price determined? This is especially an issue for illiquid assets.
• Haven't really thought about this, but could there be the case that an user is unable to sell all tokens, because every time he tries to get rid of them, he receives a few % as bonus?

[ripper234]

I'll dive into the arguments when we get closer to implementing voting (I believe I made my case elsewhere on github).

1. Fees should be rounded up.
2. Dunno.
3. What bonus? And is that even a problem?

[dacoinminster]

1. We'll have to round. I expect there may be a few corner-case situations where the fee is avoided altogether, but those should be rare. If selling IndivCoins for USDCoins, for instance, the USDCoins side will still have to pay the fee
2. Best available price on the dEX (the maximum number of MSC burned)
3. I think this is about the liquidity bonus, which is a different thing than this, but that is a good point to raise in a separate issue.

[dacoinminster]

Ron says round up on 1. Opinions?

[dexX7]

Depends on the traded pair and the use-case, I think. Say for example I'm going ahead and create tokens which can be redeemed for a one week advertisement space on a website and then encourage users to create buy orders for this token to determine the highest price (similar to an auction), then it would be horrible, if the user buys one week ad space, but receives nothing due to the rounding.

Assuming the other currency is MSC, then the fee might be applied here, but I'm not sure, if this can be done so arbitrarily ("in one case the fee is applied on this side of an order, in another case on the other side"). Let's define: who pays a fee?

Edit: this is not an issue, if MSC is involved, but let's discuss the case where no MSC is involved.

Another question: when is the fee applied? I assume during order execution and not for listing an order?

[dacoinminster]

I believe the fee should never be required when MSC is being used on one side of the dEX. So, selling something for MSC would be free, or buying something with MSC would be free, but buying those coupons with USDCoins would burn some MSC.

[dacoinminster]

I think rounding up could have some ugly consequences in some corner cases, where the entirety of a property is eaten up by the fee, for instance. I think normal rounding makes more sense, even though people could potentially trade things with no fee in some cases, I don't think that will be very attractive to most people (doesn't allow much precision in pricing). Besides the fee should be small enough that people don't worry about it under most circumstances..

[dexX7]

Which side of a trade pays fees? Are the MSC based on fees completely removed from the system?

I think in general the fee should be applied in a way to be in favor of the user, in case of doubt rather round down than up. Exploitation is probably never an issue due to the overall cost to submit an order.

[ripper234]

Should round up, rounding down is exploitable by spam (rounding to zero). Round up really is not that bad.

[dexX7]

Another case to discuss: say I created SomeTokenV1 which is depreciated at some point and I go ahead and create SomeTokenV2. Furthermore I'd like offer users to swap V1 for V2 on a 1:1 basis. How could this be done? My first idea was to create a sell offer where one V2 token is sold for one V1 token, but a potential fee makes this somewhat more complicated.

Edit: well rounding up is an issue, if the traded amounts are small and an user could end up with receiving nothing or significantly lower amounts than expected.

Edit 2: since a fee is applied, I assume a fee is also applied on the automated order that was issued based on the fee? ;)

[dacoinminster]

@dexX7 That would probably be handled by using the upcoming "pay dividend" command. You'd pay the new V2 coin to everybody holding V1, proportionally, all at once.

I think both sides would pay the fee on the dEX. For instance, both sides would pay 0.15%

Regarding rounding up, imagine selling 1 indivisible coin representing a house for a million USDCoins. 0.15% of an indivisible house rounds to a zero. It rounds up to the entire house. Not the desired behavior, obviously!

[dacoinminster]

If we do round up, we should round up to a maximum. For instance, round up, but only to a maximum of 0.5%

[ripper234]

I think both sides would pay the fee on the dEX. For instance, both sides would pay 0.15%

We discussed elsewhere that offering liquidity should be compensated at the expense of people eating liquidity. So it may make sense to do the fees 0% and 0.3% instead of 0.15% and 0.15%.

[patrickdugan]

As an active trader and market maker, I agree with these pricings, but we should consider tiered volume discounts as well. Would that be possible given the decentralized nature of the protocol?

[ripper234]

Yes, I see no problem for price tiers. @patrickdugan, I think this deserves its own github issue.

[Bitoy]

Alice offer 10000 foocoins for 1000 goocoins Ben offers 1000 goocoins for 10000 foocoins. offer is a executed. Assuming .03% fees Alice gets 9997 goocoins Ben gets 999.7 foocoins 3 goocoins is offered at meta Dex for .00000001 MSC 0.3 foocoins is offered for .00000001 MSC

If someone buys goocoins or foocoins for MSC the MSC is burned.

Even if the fee is changed to 1% the MSC burned remains the same at .00000001?

[Bitoy]

An option is to have a fixed MSC fee per transaction based on total MSC available. As the total supply MSC goes down due to burning, the fee should also go down also. Ex. Total MSC available is 563,000. Fee is 0.1 MSC When total MSC supply goes down by 10,000 to 513,000. Fee is halved to .05.

Prices of MSC will probably go up.