Inflation

[Jed McCaleb]

This might be less of a technical question but should we push to get rid of inflation?

- It is complicated

- I'm not sure it really serves its original purpose

- It's performance will drag as we have many more accounts

The downside is we will have to start burning fees. 

[Tomer Weller]

what was the original purpose?

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CALGT9GMK%3Dj%2B-mSK2%2Be_68K5rGJg2n38WZpFrdXgp1vb8H7165w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Dan Robinson]

Good question—I'm strongly in favor of getting rid of inflation. (Really it's a strong opinion weakly held, since the topic is pretty new to me.) In addition to the reasons you cited:

1) It will probably be a significant challenge to make inflation work seamlessly with features like confidentiality and contracts, and if we don't then it acts as a disincentive to use those features.

2) As I understand it, inflation pools like Lumenauts basically turn inflation into an economic no-op (modulo some wasteful transactions).

3) Without workarounds like Lumenauts, inflation seems like it will tend to make the rich get richer (even if people were actually using it to support public goods like validators, as I believe was the original intention?).

Fee-burning doesn't really seem like a problem to me? With ~1,000,000,000,000,000,000 stroops out there, I don't think we're liable to run out any time soon; we can just lower fees if stroops ever get too scarce. And if we did reach a point where individual stroops were too valuable and people had a problem making small payments, I suspect it would be technically simpler to do inflation as something like a one-time stock split every ten years.

If we wanted to do new issuance of lumens, I think it would make more sense to issue it directly to core validators (those contributing to consensus)... but that's a can of worms that may not be worth opening.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAEYuE%3Dv%2B1xy-4f7GDYQv5rfYDmFH_AgTM%2BWvbvhzZHOne1kcPQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Dan Robinson
Protocol Architect

---

[Tom Quisel]

It'll certainly be simpler, although users of Stellar get pretty excited about it. Removing it will probably slow word-of-mouth growth of Stellar.

Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CACUz3Rfdhdw7PPVhzVEJ%2BNFR9NG2C9Kc%3DU2afzX_8DwuS5xgzA%40mail.gmail.com.

[Nicolas Barry]

I think it would help to articulate what kind of properties we want to get out of it (or not).

Scalability can be addressed differently: for example, make it that inflation occurs automatically (potentially a lot more often),but with a smaller scope. This makes it less spiky.

As for utility: I always thought of "inflation" as a way to force people to get along (which resulted in the formation of inflation pools) ; but this can be achieved differently, SDF could airdrop directly to those pools instead under a "thanks for being Stellar program". This would still create lots of transactions on the backend (pools redistribute), but would get rid of inflation at the network layer. It also puts an end date on "inflation" (by way of coins in circulation); when we're done, the network becomes deflationary.

I thought that inflation in itself is useful (doesn't burn coins, compensates for "blackhole" accounts, rewards people), so it could be that it's more the reward mechanism that needs to be revisited.

There might be ways to reward "good behavior" on the network (sadly, this might require a lot more complexity?); or could be as simple as giving out 2% to all accounts in average (where odds can be something simple like balance over a certain threshold, but maxed out after some large amount to avoid giving too much weight to the large holders like SDF accounts).

I am not sure this is incompatible with confidential transactions: we don't know how those look like yet, they might be short lived (order of a few days/months), and the fee model might be different there anyways.

Nicolas

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAAeSNL_0ZK_9b0mPrct162-0q7bCOr7PzM%3DNbUcWeKXPLBDQSQ%40mail.gmail.com.

[Dan Robinson]

Money illusion in action...

On Fri, Oct 5, 2018 at 4:30 PM Tom Quisel <t...@interstellar.com> wrote:

[dm-list-s...@scs.stanford.edu]

'Jed McCaleb' via Stellar Developers <stell...@googlegroups.com>

writes:

There are ways of addressing complexity and performance (like turn it
into more of a lottery--just a straw man I'm not advocating), so the
real question is really whether it is serving some useful purpose,
original or not.

There are several things I like about inflation, in no particular order:

- It's an additional signal that Lumens are not an investment.

- I really don't like the idea of rewarding validators, because
validators are not miners. I'm not hugely in favor of burning fees,
either, and think at some point either transaction volume will be
such that total fees are non-negligible.

- It can compensate people for leaving deep orders in the orderbook,
because offers to sell XLM for various assets may tie up significant
funds now that we have IEIF (immediately executable in full) orders.

So in an ideal world, if we get rid of inflation, I would like to
replace it with some mechanism that rewards people for creating
liquidity. Something like distributing transaction fees to people who
add liquidity (if we can devise such a mechanism that can't be gamed and
doesn't incentivize bogus orders).

David

[Jeremy Rubin]

How about if we put a bounty on closing spreads between assets and lumens. If you have buy at A and sell at A+B XLM, and you open up a tighter spread (A+C, A+B-D) which can't be cancelled for T time, you get something proportional to (B-D-C)T.

Then rather than vote for accounts, you vote for assets you want to be liquid. 

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/87r2h3q405.fsf%40ta.scs.stanford.edu.

[Jed McCaleb]

>  what was the original purpose? 

  Well that is the thing, the purpose was always a little fuzzy.  The main things are:

- to address some criticisms of cryptocurrencies being deflationary. I don't think these are that valid particularly in stellar's case where you can have inflationary currencies represented inside it.

- to give people incentive to collaborate and decide how network rewards are allocated.

- any early inequities or problems with the initial distribution would get less important as time went on.

> Then rather than vote for accounts, you vote for assets you want to be liquid. 

Jeremy: That is a cool idea. Not sure how you would do it efficiently though. I was going to start a discussion in a separate thread about how to incentivize placing orders. but maybe something like this is a better answer.

Jed.

[dm-list-s...@scs.stanford.edu]

Jeremy Rubin <jer...@stellar.org> writes:

> How about if we put a bounty on closing spreads between assets and lumens.
> If you have buy at A and sell at A+B XLM, and you open up a tighter spread
> (A+C, A+B-D) which can't be cancelled for T time, you get something
> proportional to (B-D-C)T.
>
> Then rather than vote for accounts, you vote for assets you want to be
> liquid.

I definitely like this general direction, but we'd need to put some
thought into whether it's possible to prevent gaming the system. In
particular, I'm not sure whether the order living for a long time is
useful so much as placing orders that get filled (and hence are useful).
But we also of course want to avoid incentivizing manufactured volume.

Also, an order that can't be canceled is too scary. But maybe rewarding
someone for not canceling it is okay (as in you'd always have the option
to cancel and forfeit any reward).

Voting for assets is particularly nice, as this could avoid people just
creating bogus assets to collect the reward. We could keep a similar
rule that only assets receiving at least 0.05% of the vote would get
rewarded. Also, inflation votes for assets could give another
independent measure of asset quality. If an asset doesn't have 0.05% of
the vote, you should be extra sure the issuer is what you believe. Of
course, I suppose people might create bogus assets for the precise
purpose of running inflation pools...

David

[Dilip Das]

Are there metrics we can point to to see that inflation is failing at its original purpose? (what I'm understanding to be general ecosystem development incentive)

I like this idea as well, nice Jeremy. High level - 'use inflation to incentivize liquidity.' 

I agree with David that gameability could be tricky to eliminate and that could be a bit of an art-form. The payout will have to incorporate size displayed, spread width on that size and likely how tight that spread is relative to other participants'. Discontinuity is undesirable. Winner take all can be problematic. Christian and I have been thinking about metrics in this vein and I'd be to happy contribute if we want to go more in depth here.

[Mister.Ticot]

Edit: I wrongly thought you said something about negating Stellar inflationary nature. My point was that if a change in monetary policy is needed I'd advise for a clear goal and a careful analysis. As showed complex mechanism are in play.

[Mister.Ticot]

In general inflation is said to incent consuming while deflation incents staking. Inflation happens when the stock of money grows faster than the value it represents, while deflation is the opposite process.

In modern economy, inflation takes the role of an hidden tax as money "printing" sucks out value from pre-existing stock. In Bitcoin deflation is ensured by limiting the total supply which tends to favor price growth.

The inflationary nature of Stellar is essentially due to the 80 billions of tokens to be distributed, which means an inflation *potential* of 500%, or a loss of value of 80% by token.

When inflation goes back to the user it negates its economic effect, because the value extracted from each lumen by the inflation is given back to the holders. In which case it is not true to say it benefits to the richest or to liquidity providers.

The annual 1% inflation is a sort of "passive fee" for using the network. It is part of a fee redistribution mechanism that also includes "dynamic fees" paid to validate transactions. I'm going consider the mechanism as a whole (*fee redistribution*) to demonstrate its usefulness. In this view the main aspect of inflation is to ensure fee redistribution stays meaningful even with low transaction fees.

As a general idea this mechanism benefit any tier staking tokens on the behalf of users, and incent those tiers to use lumens rather than any other token as they would be able to keep the inflation+fees.

This gives lumens use cases and a central place in the network, hence value.

For example, you can create a seemingly "free" escrow service that pay itself from fees redistribution.

For the same reason, fee redistribution mechanism will provides incentive to run lighting network gateways. It will fuel sidechains development as well, as sidechain gateways will have to stake as much lumen as sent to the sidechain.

It provides incent to keep the coins on your wallet rather than on centralized exchanges, which's a positive thing; And provides incent for exchanges to support the coin.

As you can see, in all the cases I mentioned inflation is economically fair, as value is derived proportionally to the amount involved in using the service.

Overall I think the 1% inflation takes an important part in giving value to lumens.

Jed, actually it is not clear to me what you want to achieve by negating Stellar inflationary nature ? Raise token value? Lower liquidity? Fuel adoption?

[Ishai Strauss]

I say get rid of it or distribute it to validators by some scheme as to encourage network reliability.

The way I see it, inflation is a good property to have for a currency as it disincentivizes the hoarding of currency (because you lose to inflation by just hoarding) and instead incentivizes investment (i.e. liquidity). However, the inflation of Stellar as it currently stands is not real inflation. With the rise of inflation pools, users simply get their inflation back and nothing is gained. It is just an unnecessary complexity.

If the inflation is given to node operators for "good behavior" (i.e. maintaining a quorum that is beneficial for the network), then you gain back the positives of inflation (i.e. you lose XLM when hoarding for long periods of time).

[Mister.Ticot]

Penalizing hodlers is the last thing you want to do because in absence of compelling use cases they are the ones who give stable value to the currency. Remember that money makes sense only because it is a store of value, among other functionalities.

Because of all the assets that are going to grow on the network, it is unlikely we reach the point were liquidity is missing. Thus, pushing investors out in order to release liquidity would only damage the network.

I agree with you that productive nodes of the network should properly be compensated. However, I'm not sure validators can really be said productive, as in case of chain split everybody would probably follow the Stellar Foundation truth. I question their utility besides redundancy, which is already sufficient anyway.

However, side-chains gatekeepers and lightning network gateways are both going to be a critical component in the upcoming scalability race and should receive proper incentive to they can develop at a good rythm.

A very great thing in the current design is that the more the main chain is overloaded, the more fee will raise so the more those hubs will get incentive through fee redistribution to play their role in lightening main chain load.

[wouter a]

Inflation is mistreated as a goal by many I think. It should be treated as a result. For example increased oil prices by OPEC flexing is muscle led to increased debt demand by business that needed to pay higher prices. The increase in debt, led to an increase in money supply (money is created through debt). This is not the same as the narrative that printed money creates inflation, which makes sure we start spending. Inflation in a credit centered system is needed though to be able to pay future obligations. As XLM is not created through debt, inflation is not really an issue. Interesting read on this subject:  https://www.forbes.com/sites/johntharvey/2011/05/14/money-growth-does-not-cause-inflation/ 

I would advocate for abolishing inflation and starting to incentize liquidity providing. Next to the advantages provided in this thread, I also think that incentivizing liquidity with something similar to interest would increase the incentive to trade XLM pairs. By only incentivizing XLM pairs, liquidity providers would have an extra incentive to start to trade XLM (instead of for example stable coins). 

Op donderdag 11 oktober 2018 23:20:40 UTC+2 schreef Mister.Ticot:

[Reidmcc]

I have an idea how this might be possible with minimal gaming potential:

1. Every B ledgers snapshot all the open orders
• C = order size
• D = order % distance from mid-price
• E = whatever multiplier we want to assign to influence of order distance
2. Credit for an order F = C / (D*E)
3. Total account credit for the snapshot G = sum(F1, F2, ...F...)
4. Weekly (or whatever interval) account credit H = sum(G1, G2, ...G...)
5. Account payout I = [total inflation pool] * (H / sum(H[account1], H[account2], ...H))

In order to avoid random tokens spoofing, use inclusion criteria something like:

1. For a lumen pair to be included, the pair must have spread < X%
2. For a pair that does not include lumens to be included, both assets must also have a lumen pair with spread < X%

This minimized gaming because having an order open is factual; that liquidity is there, no matter the intent. Wash trading or similar wouldn't get you more credit. Using a ledger-based interval avoids easy flash orders put up just for the snapshot because ledger time is variable (for even more anti-gaming, using B +- X ledgers to foil counting of ledgers).

This approach also allows all market makers to receive some level of credit, avoiding a perception of the rich getting everything. I think we should not require someone to make both sides of the market to get credit; liquidity is liquidity even if asymmetrical, and I think anyone posting a order on the book is helping.

-Reid

[Lennart Friedrich]

Hello everyone,

I am pretty new to Stellar and to that discussion, but haven't found any good advise on Stellar Community Sites or Reddit. 

I was calculating a theoretically value of Stellar under different circumstances and thinking about the current inflation model. 

Here is a short Sum Up of my concerns, it would be great if someone of you could clarify my thoughts:

There are 90.000 billion USD World Money supply in the world.

Stellar right now with 20billion lumens is at 1,7billion.

Compared to other cryptos, they are right now 104,7/19,17=5,46 -> 5,46x1,7= 9,28 billion worth. (if all would be in the market with the same price, which of course not reality)

The problem to me is, that the market don't know this. They only see the 19,17 billion available lumens and with them via supply and demand the current price is 0,009USD per lumen. 
When you than furthermore increase the total volume via 1% of 100billion, instead of only the available coins(which would be better in my opinion), the set price and the real price per coin are going exponentially apart. 
Because new traded inflation lumens are only created with approx 20x1.001years and new created ones which are not traded are approx 104x1.001years. .

The market will never be able to catch up to that amount, so the SDF has to give them away under their terms, which means a growing dependency on the SDF, which I don't like.

1)Better would be a decreasing dependency by giving away all new coins to only the distributed coins. 

2)Or to slow that process down, only create and give away new lumens to available coins, which to me would be better. 

3)Or just giving away the transaction costs, so there is no fee-burning. 

-> all inflation rates should get paid with the non yet distributed lumens, till all lumens are distributed. That means till 104.7billion are distributed, then starting coin creation again. 

[Paul Glavin]

I saw this topic come up in the subreddit today, but figured the conversation might be a bit more productive here.

Inflation might feel pointless right now, but I think it's going to be a critical function of a mature crypto platform. For all currencies, money supply has a huge impact on how markets trading that currency behave.  If Lumens are going to be the intermediary of a significant portion of the world's financial transactions, its going to need to have methods for preventing runaway price inflation or deflation, which would seriously damage the usefulness of the token. The Federal Reserve does this for USD, but maybe there's a more decentralized technique could be used for Stellar.

Of course, a default 1% inflation rate doesn't do anything to achieve price stability, so getting rid of it doesn't hurt (I support it in the short run), but I think the goal should be to eventually have a CAP to add strategic inflation to the protocol with the goal of price stability.

[Jonathan Lister]

Could inflation be used as a vehicle to distribute a portion of the remaining Lumens?

This would provide users with a greater incentive to hold for the long term and provide better price stability. 

Inflation could be increased initially and gradually reduce over time similar to Bitcoin rewards decreasing every ~4 years. 

Jon Lister

Co-Founder

647 – 449 – 7744

BlockEquity Inc.
590 King St W, Suite 400
Toronto ON

--

You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/3d9b7f4e-45f2-4505-8ce5-05e30bf0287d%40googlegroups.com.

[Orbit Lens]

Disable Inflation Mechanism CAP

Preamble

CAP: TBD

Title: Disable Inflation Mechanism
Author: OrbitLens <orbit...@gmail.com>
Status: Draft
Created: 2019-07-11
Updated: 2019-07-11
Discussion: https://groups.google.com/forum/#!topic/stellar-dev/LIFvbMi9jPo
Protocol version: TBD

Simple Summary

This CAP removes the inflation mechanism.

Motivation

Inflation mechanism was originally planned as a simple way for users to support important ecosystem projects and keep the overall XLM supply slightly inflationary.

• Currently, it doesn't serve its original purpose, as users mostly prefer to claim the inflation payouts through the inflation pools instead of sponsoring ecosystem projects. As a result, inflation micropayouts from XLM pools generate a significant validators load and clog the network.
• Payouts get more and more resource consuming for validators over time due to the total lumens circulation supply increase.
• Once the validators vote for the significant base fee increase, such payouts became much less profitable for most lumen holders, and XLM pools will be forced to raise the minimum required account balance to more than 1000XLM to cover transaction fee loses.
• Inflation payouts may lead to additional complications in some edge-cases when programming smart contracts.
• Inflation deprecation opens new possibilities for the more effective targeted reward distributions that require complex logic, like stimulating DEX liquidity providers.

Abstract

Turning off inflation requires several changes in Stellar Core, namely Inflation and SetOptions operations behavior, as well as fees processing routine. At the same time, it can be implemented without XDR changes and breaking protocol changes.

Specification

CAP requires the following Core behavior changes:

• Inflation operation always returns INFLATION_NOT_TIME result code.
• SetOptions operation returns SET_OPTIONS_INVALID_INFLATION result code when a users tries to change inflationDest.
• Fee processing routine discards paid transaction fees instead of adding them to the fee pool.
• LedgerHeader properties feePool and inflationSeq for a newly created ledger are set to zero.

Design Rationale

The proposed approach does not require breaking protocol changes and allows turning on the inflation mechanism in the future if needed. Due to the simplicity of proposed changes, the implementation potentially should require minimum efforts.

Security Concerns

None.

Backwards Incompatibilities

This CAP contains no breaking changes and is fully backward compatible.

Questions
- Is it possible (and does it makes sense) to remove inflationDest field from Account entry, as well as feePool and inflationSeq from LedgerHeader?

[bnogal]

Why not to implement a system like freicon , but inflation instead deflation. Coins amount in a wallet is equal to last amount * annual 0,01% ( that is x 1,0001 or 100 times less amount that now) Every time a wallet is affected by an operation amounts get updated. That way there is no need for pools, inflation will cover operation cost if you store enough coins. Coin fees from operations get destroyed, so "inflation" is there to cover these destroyed coins.

El jueves, 11 de julio de 2019, 20:24:21 (UTC+2), Orbit Lens escribió:

Disable Inflation Mechanism CAP

Preamble

CAP: TBD

Title: Disable Inflation Mechanism
Author: OrbitLens <orbi...@gmail.com>
Status: Draft
Created: 2019-07-11
Updated: 2019-07-11
Discussion: https://groups.google.com/forum/#!topic/stellar-dev/LIFvbMi9jPo
Protocol version: TBD

[Gleb Pitsevich]

Disagree with the concept of removing inflation and proposed CAP.

First of all, the narrative that “inflation doesn't serve its original purpose” is questionable today. LOBSTR and Stellarterm are two examples of how inflation helps with funding the ecosystem projects today. (inflation stats: 115,000+ accounts with ~90M XLM aggregated votes).

RippleFox and Binance are other examples of the businesses that already benefit from Stellar inflation. Several other projects such as Stellarport, Stronghold and Centaurus were putting efforts into collecting payouts from inflation. And as more XLM are distributed, it will become easier to overcome inflation votes threshold, and start receiving payouts.

Second, we are working to simplify access to inflation payouts for other entities (ecosystem projects) by giving access to LOBSTR inflation pool and removing min vote threshold. Several projects have expressed their interest and will be starting beta test shortly - so the number of companies getting that benefit from inflation will increase in the future.

Also, non-inflationary currency is de facto deflationary due to lost keys, bugs etc. 

Actually, it’s possible that the percentage of the coins lost forever each year exceeds the 1% inflation rate of Stellar.

It could be argued, that mass adoption of a crypto currency requires multiple transactions and people constantly using their coins, while deflationary currency provides an incentive to hold the currency and punishes spending.

However, we are also seeing some concerns with the current situation around inflation as well.

Since SDF gets over 95% of inflation payouts (their inflation address currently has 94B+ XLM votes), which means that it receives roughly 1,000,000,000 (1 billion) XLM from inflation on a yearly basis. This is probably comparable to the amounts that SDF distributed to end users and partners during the last year. 

As far as I know, SDF has not clarified yet how they intend to use these 5+ billion lumens received from inflation. Some people have expressed the idea that SDF should not claim inflation over non-distributed lumens, or, since the protocol does not know which lumens are distributed, just burn the inflation payouts from non-distributed lumens. This can be done by sending XLM to a locked account and does not require a protocol change.

We believe that this solution would resolve the concerns of the majority of community members that currently vote against inflation.

On Thursday, July 11, 2019 at 9:24:21 PM UTC+3, Orbit Lens wrote:

Disable Inflation Mechanism CAP

Preamble

CAP: TBD

Title: Disable Inflation Mechanism
Author: OrbitLens <orbi...@gmail.com>
Status: Draft
Created: 2019-07-11
Updated: 2019-07-11
Discussion: https://groups.google.com/forum/#!topic/stellar-dev/LIFvbMi9jPo
Protocol version: TBD

[Christian Rudder]

I agree with Gleb that SDF should burn the inflation it receives and has received.

--

You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/fb77a041-4a20-467a-8a5b-014662188df6%40googlegroups.com.

[Eric Malamisura]

I'm torn on this decision as I think technically speaking I agree. However, from a community standpoint this could and I think has a very high potential to destroy the reputation of Stellar.  Tread lightly.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CAJsXWD%3DpD47O5wMDednWvsODuX%2BRusWkE62iz28U4juNz2Su1A%40mail.gmail.com.

[Gleb Pitsevich]

Would also like to comment on another point mentioned as the argument for removing inflation, which says "inflation payouts are clogging the network and wasting validators resources".

There are only two paying inflation pools on Stellar network right now: Lumenaut and XLM Pool.

Accounts belonging to those pools (G...NAUT and G...COPA) are the only ones that could generate significant amount of network operations, which can be attributed to inflation.

At the time of writing this: 

- Lumenaut pool has 139086 accounts voting for it;

- XLM Pool has 176753 accounts voting for it;

So when these pools are distributing their payouts to end users (beneficiaries), they potentially could make about 315,000 operations per week or 45000 ops per day.

To give a perspective for those numbers: under full load Stellar network can process about 17M operation per day.

This may seem substantial, however, due to the network fees the pools have a minimum payout policies.

So, not all of these accounts *actually* receive a payment from the network.

I don't have any data on XLM Pool, but the biggest pool, Lumenaut will not pay a user if the payout is less than 0.01XLM.

This (roughly) means that Lumenaut only pays inflation dividends to the users, whose balance is above 50XLM.

Let's count how many users of inflation pools have more than 50 XLM and actually receive weekly payouts: 

- Lumenaut pool has 15304 accounts with 50+ XLM voting for it;

- XLM Pool has 6539 accounts with 50+ XLM voting for it;

This potentially reduces amount of network operations caused by inflation to 20K per week.

Next, once CAP-0015 is implemented, it's likely that the validators will vote for a base fee increase.

With the 10X fee increase, the minimum balance to receive inflation payouts would probably increase to 500XLM.

Let's see how many users of inflation pools have more than 500 XLM:

- Lumenaut pool has 11427 accounts with 500+ XLM voting for it;

- XLM Pool has 4284 accounts with 50+ XLM voting for it;

That's only 15000 operations per week (2000 ops per day)...

So, Iooking at the data, I would say that inflation pools have negligible effect on the network load right now, and once the base fee is increased the load caused by inflation will decrease further.

Here's the SQL for anyone looking to verify the numbers:

> select inflationdest, count(*) as total_count, sum(balance)/10000000 as total_votes from accounts where inflationdest<>'' and balance>5000000000 group by inflationdest having sum(balance)/10000000>50000000 order by total_votes desc;

------------

Finally, another common concern about inflation which especially worries the community, is that inflation dilutes their holdings and puts the downwards pressure on the XLM price, as new XLM get sold on the market.

I just wanna mention that the SDF's inflation wallet (which receives ~95% of all inflation) currently holds about 1.5B XLM and it was not touched for over a year.

So, while it could be tempting to put the blame for the downward price movement on inflation, it's not actually supported by data.

To unsubscribe from this group and stop receiving emails from it, send an email to stell...@googlegroups.com.

To post to this group, send email to stell...@googlegroups.com.
Visit this group at https://groups.google.com/group/stellar-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/fb77a041-4a20-467a-8a5b-014662188df6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to stell...@googlegroups.com.