Safecoin Recycle Request

Users pay Safecoin to the Network and receive credit to their PUT balance. These Safecoins are “recycled,” meaning they don’t transfer to anyone. Instead, the Network reverts the coin back to unowned where it can be farmed again.

Can we have a core feature where users can recycle Safecoin back into the Network? They are literally donating Safecoin to the SAFE Network.

Why would anyone donate Safecoin to the SAFE Network?

  • Unbiased Global Charity for the SAFE economy.
  • APP Devs can use this feature similar to a “proof of burn” except the coin also replenishes the Network farming pool.
  • Voting / Reputation systems.

This post presents other use cases.

Safecoin Recycle Request works just like the Basic Walletmark. Both are neutral tools with no objective until the APP makes use of them.



I think it may be a good idea in theory but I also think that an unregulated rate of recycling could effect the pricing of safecoins in a negative way.

Manipulation of price could happen if there was an influx or a decrease in the rate of recycling (supply) of unused safecoins…

1 Like

You could “hack” a method by creating an account and spending the coin, then forget all about that account.

I don’t think the plan allows for people to spend multiple coins at once. Its spend coin, use it then spend another. So that “hack” would be expensive time/effort wise.

Another “hack” is to buy SD objects then delete it, rinse and repeat till you have spent the required coin. An APP could be made that does this for users, and the beauty of that would be that donations could be fractions of a coin since it merely reduces the storage_balance of the account without storing anything.

The problem with this “hack” is that it costs in bandwidth and node’s processing. But buying/deleting SD is minimal in B/W since its only a few K worth of transmission for each SD. No need to send the whole 100K

Another “hack” is to store 1 byte files. Each requires 1 PUT. If you PUT the same byte then dedup kicks in and only the first is stored and the rest discarded, but still cost one PUT.

Downside is the bandwidth of all the stores pretty much the same as create/delete SD object Hack.

1 Like

Not sure I understand your argument.

Donation Influx Manipulation

Are you saying if I donated 1 million Safecoins to the SAFE Network, it will drive down the fiat value? It’s far more effective to dump 1 million Safecoins onto an exchange. At least, I could recover some my costs for acquiring 1 million Safecoins in the first place.

Donated Safecoins still have to be refarmed. The Network pays out based on supply/demand. Since there is no increase in storage consumption (demand), the GETS per farm attempt remains the same but the success rate per farm attempt increases. If anything, this actually reverses the low hanging fruit situation, to the point where success per farm attempt is the same as launch day.

If this how the Network recycles for PUTS, then yeah, the Network should only recycle 1 SC at a time as PUTS are being used. To understand why, see my annoying posts from this thread.

But this is not about recycling for PUTS. It’s about donating your Safecoin without getting anything in return.

I’m trying to understand your “hack” argument which implies the Network is treating Donation recycle the same as PUT recycle. I’m saying they aren’t the same. You’re not paying for a ZERO PUT. I can’t further this discussion with my limited knowledge of recycling.

1 Like

@dyamanaka, I was presenting “hack” to the current proposed system to implement a form of donation recycling and the drawbacks of each “hack”

I was not trying to show how it should be implemented.

Each of my “hacks” had significant drawbacks and were costly to the user/network in other ways.

Your idea is interesting, but I am not sure how many would be interested.

A thought on one method to implement donation for farmers.

A farmer could set one or all his vaults to have no payment address for the coins generated, and the core made to not attempt a coin issuance is the address is absent.

That is one form of donation that requires one line of code in the core and simply means the farmer does not set the safecoin address in the vault

This plan starts to sound like it will just interfere with safecoin proof of resource; if you make an application where you encourage people to burn their safecoin to each their own; but definitely not for network wide requirement. Demand; just doesn’t make sense, what for deposit safecoins for a purpose external to data storage/to be later farmed; why make more farming rewards than data gets farmed,

It just reads as throwing wrench into the engine… to me anyway.

Yes, farmers could donate their resources. But the OP is about donating Safecoin. I would go into more reasons why but I think it’s pointless now.

I would describe it this way…

If Safecoin is the blood of the SAFE Network, then circulating blood helps it run more smoothly. The supply of blood increases as the Network grows, at least until the 4.3B cap is reached. There will come a time when the Network keeps growing but the blood supply does not. At that point, circulation will be very important.

1 Like

Yet if folks stop consuming safecoin to store data, then farming will stop also, hence we will not need to ever reach 4.3 billion coins. The distributing algorithm will need to accommodate the next capacity; or sit still until we put data again.

And at that point you can “donate” by storing arbitrary data; yet again it’s more like a dooms day scenario that I imagine the ebb and flow of safecoin will already take care of blockages. And if there is a blockage so be it. It means more capacity didn’t come in, and more data is not consumed.

I imagine that in such a situation all of the world’s knowledge would be stored there, and all computers to exist would be attached



Yes, but the result is donation of their rewarded coin which was the desired thing

Yes, it only covers one area.

I only mentioned it to show a potential way, and considering that it will be the major generating method of “new” coin, it does cover long term most of the coin out there.

While this is absolutely true, the effect of scarcity on coins being generated is important to consider. At 20% of coin issued (~800 million) for every 10 coin issuance attempts only 8 result in a coin being issued. At 80% (~3.5 billion) it is 2 coins issued for every 10 attempts.

So as the unissued coin reduces so does the supply dry up. It will not be a sudden thing.

The other side of the coin is that as the scarcity reduces coin issuance then the farmer leaving will drive the put cost higher resulting in an increase of coin returned hopefully more returned than the increase in farming rate cause coin to be issued. Of course the scarcity helps in that because at 95% the farmers only get 1/20th of the FR, but PUTs cost result in all coin paid being returned.

And this is where donations can certainly help, an API for that would be the best way. I would think though that if an API (core feature) is supplied for donation then the null safecoin address for vaults feature would have been implemented first since that is a “one liner” of code which is easy to test. Whereas the API, while straight forward needs to be tested, and a permissions setup so that a bad/evil APP cannot burn all your coin, which requires a lot of testing.

1 Like

We’re going off topic but I think this is important.

Actually, if people stop PUTTING, then we will reach cap sooner rather than later. The reason is because the Network bleeds out from GETS until there is very little Safecoin left.

If it stops paying before it reaches cap, as you say, that’s even worst. Farmers may leave because the Network stops paying due to very little PUT income.

I agree. It is a doomsday scenario and something we need not worry about right now. Our time is best spent making the most of this new creation.


Can not underestimate the cache, an abundant cache means that GETs dont bleed the network, they just happen and eventually on time. They stop the production of safecoin for GET requests, until the next piece of content comes around. And if the farmer does not have sufficient RAM for caching then their machine will have to cut into their farming reward.

Agreed might be out of the scope of the thread, sorry for that; yet to finish the thought. Also agreed have to have the plans available for the any many scenarios so the repertoire is stocked with answers of any event.


Yes, cache “slows” the bleeding which is a very good point. But I think we both understand bleeding is still not a good thing.

1 Like

@dyamanaka, I didn’t much like your proposal when I first read it, but am warming to it. If I get you correctly, another way of saying it is that you’re buying a proof from the network that you burned a safecoin without claiming resource, thus performing a bit of reverse inflation and plumping network resources at the same time. This could have interesting usages.

I really don’t think it would affect pricing of safecoin. It’s not like ANYBODY knows how many safecoin are coming and going anyway.

On the other hand, if it introduces any hassle in the code or execution categories by complexifying things, I’m agin it.

Charity of your spare safecoin to an archiving charity would accomplish something, but would also incur a carrying cost for the network into the future, as opposed to turning back the age clock for it.


There is no complex code to introduce. The hacks given by @neo allow doing this kind of donations right now (no safecoin yet, but they will use the account put reserve).

I think RADS has interesting system of using a side chain to store data,
To see safe network use system where one could put safe coins on to the network and have them returned plus PUT interest would be cool, giving another element to the safe network…