[Economic Model Suggestion] Soft thresholding through probabilistic matching


#1

The current model works by implementing two hard thresholds - Pmin and Pmax.
Whenever the price reaches one of these values, the system automatically intervenes.

The current model has two major problems:

  1. As these values are fixed (Pmin and Pmax) and pre-determined, this can be seen as a trader who placed to infinitely large buy/sell walls at Pmin and Pmax respectively. A smart day-trader would act accordingly and place large buy/sell walls at Pmin+epsilin and Pmax-epsilon respectively. While the price is still stable, this leads to the price never hitting Pmax.

  2. The ROI model relies on the system hitting Pmax. Consider the scenario in which the price is fixed at 1.09, this means there is real usage and people appreciate the coin at a higher value than the promised reserves (0.9) yet during this whole period the ROI is 0 as Pmax isn’t hit and thus there is no redistribution of inflationary coins.

The proposed solution:
We define the base value of XRD to be Pmin.
The system acts as follows

  1. When a buy order is placed at a value v which is higher than Pmin, the system will match this buy order with probability P(v). This probability it’s monotonous, i.e., it grows higher with v. The difference between the buy order and Pmin is given to the bag-holders/node runners as incentive/distribution of inflationary value.

  2. When a sell order is placed at under Pmin, the system will match this order with probability Q(v). Similarly as above, Q(v) should grow as the order is nearer to v=0 and should be equal to 100% when someone attempts to sell at 0.

This proposal can be seen as a generalization of the current stable mechanisms.
When you set P and Q to be 100% at $1 you have a pegged token to $1 similar to Tether.
When you set P to be a step function at 1.1 (e.g., the system only matches buy orders above 1.1 - but matches them all) and Q to be a step function at Pmin (e.g., the system matches all sell orders below Pmin) then you have the current model.

Challenges of the model
The major challenge of this proposal is to select ‘good’ functions for P and Q. As P and Q can be seen as the amount of force the market is required to place in order to move the value of the token - on the one hand you want to allow the price to float freely around 1 without applying too much negative force but on the other hand you want the value to float “far” only if a large force is applied for a long period of time (similar to how a spring works, the more you push on it the denser it becomes and the more contradictive force it returns).

Notes:

  1. Pmin can be set as a fixed value (0.9) if you still want to ensure a base price.

  2. This system can be seen as an elastic pricing model. It will put pressure on the price to move towards Pmin however if everyone wants to BUY and no one is SELLING then the price can continue to grow (similarly to Dan’s original vision).

  3. As the thresholds are SOFT and not HARD this system can’t be gamed and there is ROI as long as people use the system (e.g., the value is above Pmin).

  4. This model is different from the previously proposed model (a few years back) as it doesn’t provide stability by creating and burning currency, it does it by matching buy and sell orders similarly to how any player in the market would do, similarly to how a country which wants their currency to be worth Pmin will intervene more strongly as their currency moves further away from the goal value (Pmin).


#2

Tesslerc, I think that’s a brilliant suggestion. I definitely think that the current system would be gamed at the low end. There’s virtually no risk in buying a small amount above Pmin. It seems like the price may naturally gravitate toward Pmin since that’s where the risk is lowest. But maybe that really doesn’t matter that much if the result is a relatively stable currency that’s useful.

Your system also provides some incentive to buy by making it possible (with probability P) to complete a buy order that’s less than Pmax.

I do have a couple of comments:

  • It’s probably obvious, but the algorithm should only come into play when there are no existing matching orders.

  • One way to game your suggested system would be to place an order to sell above any existing order and if the algorithm doesn’t match it, cancel the order and make a new one at the same price. Eventually, the order will be completed with the probability Q. A fee on an attempted order could combat that. But in most systems there isn’t a fee unless the order completes – how does Radix plan to handle that with the DEX?

  • This method could significantly complicate calculating the amount of surplus reserves there are each period. One very nice feature of the current system is how easy it is to know how much surplus there is. With your method, you would have to look at every purchase by the algorithm.


#3

I’ll try to address these concerns.

  1. If there is an existing matching order then you are correct, the system shouldn’t intervene. But normally people place orders in the “gap” between the buy and sell orders.

  2. Recall that the system only intervenes when only the system can gain. Similarly to the current configuration in which it sells at Pmax and buys at Pmin, my proposal only sells above the designated value and buys below it. As the system still holds the reserves it is ensured to always win - yet it shares the winnings with the users. Think of it like this - if the price is pressured towards $1, then the system is ensured to win as it has an infinite reserve of XRD (it can print) and the tokens are backed by XRI.

  3. Indeed the difference is that in the current system you only need to consider the total amount bought and that enables you to easily calculate. My proposal requires you to calculate how much was bought and at what price. However, as you have to go over the entire orderbook in both scenarios, I can’t see this as a complicated matter. But I have no idea how it is really implemented, so maybe @fuserleer / @edgars will say otherwise.


#4

Tesslerc, thanks for the response. I think that your system would work well for selling above $1, but there’s another problem if it’s buying below $1 (but above Pmin). One of the assurances of the current system is that it’s guaranteed to have sufficient reserves to buy all XRD at a price of Pmin. However, with your system, if there is a sustained period where the XRD is trading between Pmin and $1 then any purchases above Pmin will reduce the amount in the reserves below what is required to buy all remaining XRD. If there are enough such purchases, without sales above $1, then Pmin could go down significantly. I think that it’s important to retain the current behavior that maintains the price floor.

Perhaps it would be enough to only provide the feature for sales above $1, and not implement it for purchases below $1. The primary thing to protect against is people gaming the system to prevent the algorithm from buying at Pmax (which would prevent any new redistributions). If someone wants to buy at Pmin + epsilon and thereby provide a higher floor, then is that really a problem?


#5

Good catch @steve ! Thanks!
You are entirely correct, the system should never match sell orders higher than Pmin. I fixed the original post to reflect that the real value is the backed value which is Pmin and not $1.
Now P is higher than 0 in the range of (Pmin, infinity) and Q in [0, Pmin].

Regarding your second point, I placed that option as a remark in the original post. If you want to ensure a hard floor you can keep Pmin as a step function but I’m not sure what would work better. I’ll need to think more on the matter and see if I come up with any meaningful insights.


#6

@tesslerc, I like your change to how it could now sell at values above Pmin (instead of only above $1), but if we do want an eventual floor at 0.9, then it should never sell at values less than 0.9, because otherwise it may not have sufficient funds to purchase all XRD at 0.9. Of course, if we don’t care about having a guaranteed floor then that won’t be necessary. However, I personally really like the idea of the guaranteed floor – it provides a solid reason to trust XRD when using it as a business or as a consumer.

So, if we choose to maintain the floor at Pmin (and aim to reach a Pmin of 0.9) then the algorithm could sell with a probability P at any value above 0.9. It wouldn’t buy except when it reached Pmin.


#7

Yup I agree. A solid floor does provide confidence, and if it is seen as an infinite buy wall then day-traders will push it higher which in turn results in increased ROI for everyone. I believe this can work very nicely :slight_smile: thanks for your help @steve!


#8

It’s an interesting idea, and actually the original design for how Pmax worked, where the price at which the ECA would intervene in the market was a deterministically random function, where the price at which it would definitely enter the market adjusts on a probabilistic function related to the size of the buy order (higher larger buy orders are more likely to be matched at a lower price than small ones).

The problem we found with this model was two fold:

  1. A good source of entropy (randomness) that is deterministic (e.g. all Nodes arrive at the same conclusion) without being game-able (e.g. a trader can front run the algorithm)

  2. We do not really expect that companies and developers will be purchasing Rads from the DEX at the “market price” - they are much more likely to just want to know that they can always buy Rads for $x and it then costs them $y to use the system. The probabilistic nature of a variable Pmax makes getting Rads much more complex for the average business/dev that does not understand a DEX. A set Pmax means that they don’t need to worry about this bit.

I do, however, like the idea of a probabilistic ECA operating between Pmax and Pmin to make sitting between Pmin and Pmax much harder. It is something we will have to chew on a bit more with respect to point 1. Non-gameable deterministic randomness is a non-trivial problem.


#9

Thanks for joining @Piers :smile:
Let’s assume we are at stage 3. Pmin is 0.9 and is the reserves we have. If the system sells at any value above Pmin, then it’s ok. The exact value doesn’t matter since it is still ensured 0.9 XRI to XRD matching and the difference itself is rM (which is bigger as the match price is higher).

I think the difference between this model and what you attempted, if I understand correctly, is that we don’t set a random Pmax but rather Pmax doesn’t exist. For each buy order above Pmin we have a probability to match this order. How do we decide? It depends on what data you have regarding the buy order. Let’s assume each buy order has a hash associated to it (or an ID). We just need to predefine a mapping from ID to the range of [0,1]. If it’s below P, the econ algorithm will match the order otherwise it doesn’t.

Regarding external companies, if the market price is 0.95 they won’t buy at Pmax. And the current model allows it to float in a 20% value difference.


#10

Have these companies told you that they will be quite alright with buying all their Rads at 1.1? Because if not, I do not see a current scenario where it is likely others will either. If these businesses can provide constant buy pressure (or semi constant) buy pressure at 1.1 then stage 2 can support the market price. Is this what they have told you they would do? If they aren’t buying off Dex, how are they buying?


#11

Sure, understood - it’s slightly semantic, but any price that the system comes into the market at is technically Pmax for that moment as it would clear anything at or above that price off the DEX, but I get what you are saying.

The problem still comes back to gam-ability. What is to stop me just continually placing and cancelling orders until I am matched at Pmin + 0.01; or similar strategy.


#12

More that companies don’t really want to be market operators at all. Buying at Pmax is an instant transaction, at a pre-set price. It doesn’t require you to place a market order; or even consider a market order.

As an extra bonus, it means that the Rads you receive are “clean” because they are newly minted. You don’t need to worry about potential AML/KYC issues that may be faced by larger companies when looking at dealing with DEX markets.


#13

(1) placing and canceling orders should cost fees.
(2) buying above Pmin is buying “at a loss”. Anyway, Pbuy-Pmin is the surplus which gets redistributed. The goal is to push the price towards Pmin.
(3) The system should only intervene above (or at) the max buy price. If people are currently trading at Pmax and someone places at buy order at Pmin + 0.01, it shouldn’t be matched anyway - the system is merely another trader…


#14
  1. Failed transactions do not have a fee on Radix (related to the double spend problem). We can look at adding a cancelation fee, but that would have to be no more than the cost of a normal transaction because if it was bigger I would likely use the double spend consensus prevention to cancel the order instead. That fee size means that inserting and removing a significant trade a few hundred or thousand times is not likely to be much of a cost. I know there are a few different methods you could use here, but the underlying issue here is that with anything deterministically random related to money adds an inherently gameable aspect of the system, and while you can go down the anti-game rabbit hole, you will always be doing that at the expense of ease of use, low friction, and adding system complexity.

  2. Depends if I want to use the Rad, or I am just playing the market. If I want to use the Rad, it isn’t at a loss, just the best possible price. It just pushes the surplus to be essentially negligible.

  3. Oh - in that case, it doesn’t really solve the problem? It just means the value of the Rad can periodically push higher than Pmax. I thought the issue that was being looked at here was market makers sitting between Pmin and Pmax and thus reducing the likelihood of the ECA entering the market?

I’m no longer clear which issue is being solved by this proposal.


#15

The goal is for XRD to be stable w.r.t. the XRI basket while not placing a hard ceiling limit. Hard ceiling limit without intervention inbetween means that the value is relatively stable as it can freely move between Pmin and Pmax which in turn may incur a 20% loss. In addition, this means that while XRD is switching hands a lot, there is no incentive to hold over day trade as the value doesn’t hit Pmax.

My proposal means the system provides increasing market pressure on the price and pushes it towards Pmin. The real value w.r.t. XRI is Pmin. Any value above is speculative. The system merely attempts to match buy/sell orders which are above Pmin and redistribute the surplus to bag holders during which the price is pushed towards Pmin.
Eventually, the price can’t hold for long above Pmin and it will be very stable w.r.t. the XRI.


#16

Sorry Piers, I am unclear on your answer. Have companies you surveyed said they would be fine buying at 1.1 to avoid “unclean” Rads (or for other reasons)? Or are you speculating that they will be fine paying a premium? For instance there is legitimate reasons to assume price to be well below $1 during stage 2. Far below $1. How much are you speculating and how much have you addressed this possibility with interested businesses? Right now, to get to Pmin of .9 we need billions of Rads bought at 1.1. Billions. So I am very interested on what businesses have told you specifically.


#17

There is nothing stopping you from placing orders above pmin or below pmax in the current model. That is the inherent issue of creating hard bounderies when the system is so new. You show your cards, you make the system a trader and other traders will control the market, because it will be easier to profit on trading the range than waiting around for the hopes of interest through redistribution. Additionally having redistribution associated with only buying the “ceiling” de-incentivizes people to do so pyschologically.

But this model proposed hides what the pmin and pmax are, because there is a randomness in the buying or selling. Therefore how would people know what to “game.”? If the price goes up to $10 early in stage 2, who cares? Isnt the goal stability by stage 3?

Also if businesses are going to buy direct (like you suggest above) then if the price is $5, why can’t you still sell it to them for $1.1? They are still paying more than those at stage 1, they are creating redistribution and contributing to the pmin.


#18

Sure - in this case you are gaming the randomness, simply by placing and removing orders. You are trying to force the system to behave in the way you want it to by repeatedly triggering the randomisation algorithm. Theoretically, do it enough times, it will fulfil your order at the price you want. That is the gameability. It may be random, but play enough times it still gives you a predictable outcome because the randomness is still bounded by a probability function.


#19

I disagree. In this scenario there is no incentive to trigger the algorithm. These incentives go away as soon as price doesn’t have a ceiling. I don’t know at that point why anyone would want to “trick” algorithm as there would no longer be a manufactured range to trade.


#20

To get clean Rads, not to avoid them.

No - we haven’t yet asked if they are willing to pay above market price for tokens if it meant they did not have to interact with other users. The Economics was not yet sufficiently defined, so asking such a specific question wasn’t possible.

Our market research has instead been asking as many projects as possible about the issues they have with deploying on existing platforms. Predictability of cost of using the platform (e.g. it not suddenly costing you 5x to use the platform next month as it does this month) has been one of the biggest pain points we have seen (outside of scalability).

A strong guarantee of supply, at a predictable cost is verified to be desirable. To also know that none of the tokens you receive are tainted in any way as they are freshly minted by the system - that has not been properly surveyed yet.