Clarifying safecoin distribution percentages

There are only 4.3 billion safecoin in existence. It doesn’t delete but rather, put back into the pool. Therefore it is finite amount of supply.

If it were unlimited, then it would be ∞ safecoins.

1 Like

As Dr Irvine says in the post above, they will be deleted, creating space for a new coin. This is essentially the same as recycling.

2 Likes

There are only 4.3 billion ‘potential’ safecoin. They don’t all necessarily exist at any one point.

Where does the value come from for the coins as they are created? The value of the coin comes from the total value of all the coins that currently exist. In other words, they gain their value from the value already held by the community in their wallets - existing coins.

This means that we are agreeing (by using safenet) to accept that the value we hold in our wallets will be diluted up to a maximum of 4.3 billion coins (worth of value).

I feel it’s important to state this as there are many who think that the network owns coins when it does not. The community by pre-agreement is allowing the dilution of the value of what they hold in their wallets (by creating up to a max of 4.3BB coins) for the benefit of running, maintaining and managing the network.

I think the simplest way to say it is that there are 4.3 billion valid safecoin addresses. That address space limits the number of potential safecoins. The safecoin itself is simply a structured-data object with a valid address. There will almost certainly never be that many safecoins in existence at any one time.

Safecoins are created (freshly PUT to the network) in the farming process and destroyed (erased) when used to purchase resources from the network. The address space that that erased coin had occupied is then available to have a fresh coin (structured data object) minted with that valid safecoin address in response to a successful farming request.

So safecoins are both recycled and deleted. The limit is in the valid address space. Once a structured data object has been created by the network at a valid address, no other safecoin can be created there. Once it is deleted, that address can be used again.

“Recycled” is a very good term for it, I think, but perhaps saying that safecoins are “phoenixed” would be better. :sunglasses:

Hope this helps.

See also, New Wiki entry: Safecoin Issuance and Distribution

2 Likes

Where can I find description of a proof type for rewarding app developers?

Ok thank you. That makes a lot more sense. I read the other topic you referenced which confused me even more. This topic with @neo’s explanation made a little bit more sense to me.

Next question.

Can you please help clarify this point if it is valid?

If you have 1 billion coin issued and you have 1 million coin (1/1000 of issued) then if farming results in another 1 billion then the coin in your wallet is now only (1/2000 of issued)

The claim is that by having more coin issued that somehow the coin in your wallet is now worth less to you. Just like you dilute orange juice.

But I am sure people can see how this simplistic view of farming rewards increasing the issued coin is too simplistic to be of much value. Look at bitcoin, it is being “diluted” every time new blocks are mined and the total BTC supply increases.

So even ignoring recycling, if the coin is worth something, then as the network is growing and the coin issued rises, the question remains will each coin actually be less in value? With the 1 billion issued the network can only have grown to a certain size, so the network is not worth as much to as many people.

And at 2 billion coin issued then its pretty evident that the network will have grown much more and be worth more to more people. This is pretty much self evident since the extra coin would not have been farmed for lack of farmers if the network is not worth something.

And since PtD is only given at the rate of 1/10 of farming rewards then the maximum effect is to increase the issued coin by another 10%. But it is pretty obvious that not every GET is for APPs that have PTD address embedded so that is even less. if PtD is applied to 40% of GETS then PtD accounts for 4% of what farmers get worth of increase in coin.

1 Like

Everything you said above this quote made sense to me thank you…and the orange juice example was great. As I said earlier, I can not even explain the point of my confusion here. Can you re-explain this section to a non-techie like me who does not fully understand GET’s and PUT’s and APP and what you mean by PtD is given at the rate of 1/10 farming rewards. I seem to understand best when you use examples such as in your first paragraph. I hate asking dumb questions and would prefer to PM you back and forth but I’m sure I’m not alone. Thanks again.

1 Like

Farmers get a set rate of rewards FR. FR = farming rate based of storage used across SAFE.

To work out how many chunks the farmer must retrieve for the network to pay a coin there is another value called FD which is the number of reads per coin issued. FD is simply the inverse of FR

Let me give an example if FR is 0.0001 (1 ten thousandth) then FD is 10000. (ten thousand)

So while we say FR defines the number of GETs (chunks read from the farmer’s vault) needed before a coin is issued, it is really the inverse of FR that defines the number.

And the payment rates for PtD (pay-the-developer that is APP Developer) are also defined in terms of FR.

So when a chunk is read from a farmer’s vault that is called a “GET”. Someone coined the term and it stuck (David probably)

When a chunk is written to the network it is called a “PUT”

Still with me :slight_smile:

Now the network is able to determine the reason for a read (GET) from a vault. The reason can be

  • a simple read of the chunk, no specific reason.
  • a read of a chunk initiated by an APP

So a farmer, on average, receives a coin for every FD (1/farmingrate) GETs, and every single retrieval from their vault goes towards getting rewarded.

BUT for an APP that has been setup with its PTD payment address they will only have the GETs that they initiated going towards their reward.

And some GETs from vaults will be for APPs but many will not be.

Thus to know how much all the APP developers will receive in rewards you have to know two things

  • The rate of payment for GETs initialed by an APP, which is 10% of FR
  • And the proportion of all the GETs in the network that are caused by APPs

still with me :slight_smile:

Then finally if we take an example where over a day or week there is 1 billion GETs in all of the SAFE network. And use the value of FR that I gave as an example

  • Farmers retrieved 1 billion chunks
  • The coin issued to farmers will be 1 billion * 0.0001 = 100 thousand coins
  • Now say APPs initiated 20% of the 1 billion retrievals (GETs) from farmers vaults then the APP algorithm (GETs * 10% * FR) results in
  • 200 million GETs * 0.1 * 0.0001 = 2 thousand coins issued to pay APP-Developers

EDITED: Thus the APPs number wise got 2% the number of coin as compared to the number the farmers got. Neither amount is affected by the other and neither is dependent on what the other got.

EDIT:

If we now include the attempt - coin issuance equation we then have to know how many coins are unissued in the network, so lets assume 30% issued and 70% unissued

So for every 10 attempts there will be 7 coins issued

  • Farmers retrieved 1 billion chunks
  • The coin attempts for farmers will be 1 billion * 0.0001 = 100 thousand attempts
  • The coins issued will be 70% of attempts = 70% of 100 thousand attempts = 70 thousand coins
  • Now say APPs initiated 20% of the 1 billion retrievals (GETs) from farmers vaults then the APP algorithm (GETs * 10% * FR) results in
  • 200 million GETs * 0.1 * 0.0001 = 2 thousand coins attempts for APP-Developers
  • This means the APP-Developers will get 70% of 2000 attempts = 1400 coins
4 Likes

I think you nailed it this time with your last paragraph. Thank you.

So to be sure that I fully understand, using your FR example…

If farmers retrieve 1 billion chunks and Apps initiated 20% of the 1 billion chunks that were retrieved then farmers would be issued 100 thousand coins while App developers would get 20% of that 100 thousand coins which is 2 thousand coins.

full stop. They get the coin without any regard of what APP-developers got
EDIT: you changed it to be more correct and I may not need to say any of this reply :slight_smile:

And APP-developers get 2 thousand coins which happens to be 2 % of what farmers got.

We need to keep in mind that the amounts are only related by mathematics and neither depends on what the other got.

For instance if it was 30% of all GETs that were initiated by APPs then teh farmers receive exactly the same amount of coin and the APP devs would get 3 thousand coins.

1 Like

So now add PtP to this example and if 10% of GETS are initiated by posters and 30% GETS are initiated by Apps then farmers still get 100K while Apps gets 3k and posters gets 1k of the total 100K issued?

FYI - @janitor made the good point that PtPoster was a more accurate definition than PtProducer.

1 Like

One thing here – Is not quite correct to say that “the farmer receives a coin”? Isn’t it more correct to say that the farmer receives the chance to execute a farming attempt, and only gets a coin if the attempt is successful?

2 Likes

I’ve heard this argument before. Yes, the farmer gets a chance to receive a coin, but the chance is (overall) fairly constant so you could as well say that the farmer receives 1/N-th of a coin (on average) for every GET - I think this way of saying de-obfuscates the nature of how payments effectively happen.

2 Likes

Yeah. There probably is a better way to say it. Depends on the depth you’re looking to. That’s a hard problem, making it understandable, while retaining non-contradictory explanations. Not to mention that what goes on all the way down at the code level is truly inscrutable to most, not the least of which myself.:confounded:

Thanks. I’ll see if the phrasing can be improved.

2 Likes

Absolutely Correct all are attempts for a coin. Edited the example to tack on the end a repeat of the example with attempts-issuance included.

I thought it might have been too confusing to the example.

But I was trying to explain what various terms were and how they relate to each other. So my example assume almost no coin issued where then virtually every attempt results in a coin.

2 Likes

That statement reveals a basic misunderstanding of the coin attempt.

It is the rate of the attempts occurring that averages out to be fairly constant

BUT the rate of receiving issued coin is not constant even it farming rate is constant. While the attempts to issued coin ratio changes slowly it does.

When 20% of the coin is issued then 8 coins will be given for every 10 attempts. (on average)

But when 30% of the coin is issued then 7 coins will be given for every 10 attempts (on average)

TL;DR
The rate of attempts is what FR is.
The ratio of coin issuance to attempts made is defined by coins_unissued/total_coins
Which is why @fergish rightly pointed out the error in my example

3 Likes

How is that different?

In month when 20% of coins are issued if I get 10 attempts I will get 7 coins so I can say on average (in that period) 0.7/req.
It doesn’t matter that I will get 0.8/req in another period. It matters that in this period I can say I get 0.7 on average.
I didn’t claim the amount does not change.

Because it is a 2 variable varying target.

The FR and the issuance ratio.

While you have the point that they are going to change slowly that is not always correct since FR can change quickly.

Then becomes much less correct since its a 2 variable moving target.

I get that but my way of expressing the figure changes as fast as your way - if you say every Nth attempt I can say you get 1/N per req (for that period).

If you receive no gets/requests it would be possible to get nothing at all regardless of the farming rate, but that should be rare.