SAFE Pod SF - SafeCoin - The SAFE Ecosystem


I hope you folks don’t mind that I take a stab at it, I just want to raise my concern and see how they can be addressed.

This is what the forum is for! Welcome to the scrum! (Rugby reference intentional :-))

App Rewards

I don’t think App rewards has been detailed or debated much, and I’ve also asked for clarification on this, but think the team are too busy right now. Come testnet3 we can get more into it I hope, but nothing to stop the community coming up with our own ideas.

I share your concerns about what is imagined for App rewards at this point, but without detail is not clear if they are valid.

If a discussion grows, i think this will deserve a new topic.

Storage Fees

I’ve also been revisiting the other aspects of the economic model spurred by the Safecoin white paper and this video, so I’d like to wake that discussion up again for testnet3. You getting your head around this issue is great because we need as many informed heads as possible.


Thanks @happybeing, I’m looking forward to the debate around this.

1 Like

If the application doesn’t get rewarded for GETs on cached content, the correlation isn’t so linear. (Similar set up for proof of resource distribution)

Aggregating other users content is valuable! The problem comes from dependency on that middle man. I don’t envision just one application per category. The ease of app creation on the network should generate a healthy market (aka moral choice is on the user).

Hopefully it’ll just be easier to set up a couple of farming vaults?

We’ll be ready for this. It will certainly take a shift in perspective to overcome for some folks, but you gotta start somewhere!

The network isn’t restrictive in it’s content payments. The network based tipping solution is voluntary. There will be 3rd party services offering a variety of options for compensating creators.

Hm… a kill switch sounds mighty centralized. Forking sounds like a better option.


Thanks for the reply @ioptio. I don’t know how to properly quote a quote so I hope my formatting isn’t too hard to follow.

This will pigeon-hole developer into making GET heavy apps.

Maybe not, but caches get recycled over time, and increasing your app GET request remains the best strategy to get the most income out of your app.

This will incentive people to develop app that aggregate other’s content and reap the reward of their work

I agree it is but it changes the intention from bringing value to others to extracting value from the network, it incentives a profit oriented mindset instead of an altruist one. Also, most users won’t know anything about it because it’s done behind the scene, they will just flock to the biggest aggregator following the path of least resistance.

EDIT: Also, it sets back content creators in a worst position than they are now. They will have to fight against the resources of a few wealthy aggregator to get any return from their work. This system empowers the middle men instead of the content creator. Achieving the opposite of what it’s trying to do.

Create an app that auto-gets all files you put in and send the safecoin from the get request back to you

Why not do both, are they mutually exclusive?

The network paying off morally wrong activity is harder to defend than if a user makes the decision to support them.

A gang beats up a kid, post a video wrapping it in an app, it goes viral, they receive a hefty sum of cash from the network. Is a shift in perspective to make this ok really in the best interest of everyone and something to look forward to? I don’t think I can make this shift. Let the user do the moral choice of doing it. Honestly, all other points might be weak but this one is a real concern.

We’ll pay.

That’s my point, money will flow, there’s no need to force it.

Kill switch

I was referring to the beta, you probably will have a mechanism to update all vaults with patches.

Thanks for the reply @ioptio, as you can see, I’m quite excited about this project, it’s just this features that I, for some reason really dislike. Anyway keep up the good work.

1 Like

In my first post I said to try it anyway but thinking more about it I changed my mind. The reason is that it’s easier to add something if we need it than to remove it if we don’t like it.

So how about letting the network run for a while without it and see how things fall into place? Who knows right. But I bet there’s gonna so many different ways to pay with safecoin that it will become obvious any automated reward system is not needed.

Again, my 2 cents. Thanks for reading me.


@DavidMtl I agree with you in all the aspects you said in this thread.
It’s a big flaw bring an income to app developers for GET request. IMHO, I think is better to bring this reward for PUT operations, and subtract the 10% for the app developer from there. This way there’s no “Game the System”. Otherwise there will be a lot of botnets doing “auto-getter”.


Can you explain more about how you think this would work? PUT operations are only done once. So how does the system know which App was how popular? How do you decide which App gets money and which don’t? Are you gonna pay to some sort of Popcorn Time app from the PUT money? If not, who’s gonna decide?

@ioptio I don’t understand how caching mitigates app GET requests because the App doesn’t have to stick to any particular content to be rewarded.

Example, an app that crawls the network would hit lots of uncached data and be rewarded for doing nothing useful if rewards are simply tied to GETS.

I guess the mechanism is more complex than what I’ve read so far, but without details is not possible for us to handle people’s concerns.


@happybeing Do you remember arcade machines? They require coins/tokens to play.

What if the App earns “based” on PUT requests?

Online Game Example

  • When personal data is PUT through the APP, (high score, character stats, items, etc…) the player is charged Safecoin by the Network as normal.
  • The personal data is owned by the consumer, and therefore does not burden the App with storage costs.
  • At the same time, 10% of PUT “revenue” is directly accounted for using this method.

I hope this makes sense. I haven’t figured out the logistics because I’m not a dev, but I think this could work.

Credit to @bcndanos for suggesting PUT instead of GET.

Going outside the box…

I don’t think the above model will work for all Apps, because some don’t use a PUT function, but I’m wondering if there is a way to make it possible.

Music App Example

A music App offers a list of songs, watermarked by various artists. The user gets to stamp the song with a “LIKE”, which means they send a PUT through the App. Now we can apply the model above. And if they want to support the Artist directly, they can “TIP” them through their watermark address.

It’s a win for the App Dev, to aggregate independent song artists, and a win for the Artist to earn income directly. I think artists would be encouraged to join this kind of App, gaining more exposure.

Again, I don’t know how the logistics will work but it could be possible?

Why would farmers agree to the above model?

I’m glad you asked. Apps are key to mass adoption. I strongly stand behind this statement.

If it weren’t for killer Apps, farmers would have a lot less data to look after. If PUTS became insanely cheap, the App Devs wouldn’t make much, but it’s still directly accounted for in terms of usage, without the opportunity to spam the Network with artificial GET requests.


I think we have to solve an economic problem: to ensure that the interests of users, farmers and app devs are aligned, and so far I haven’t seen a model that does this (regardless of whether it would be practical, or as you highlight, work for some apps and not others).

Ideally the model would automatically reflect value to users in the charges, so that apps/farmers are rewarded, and users charged in a way that works regardless of app function. So far we’ve wrestled with a single special case, a “store my data forever app”, and have struggled to solve that, but it’s a much harder problem to generalise.

For the “storage app”, we’re attempting to solve this by creating a way for user storage fees (Safecoin PUT charges) to reflect global storage and retrieval costs (farmers’ GET rewards).

For other app services, this may not work because storage may generate far too little revenue to incentivise creation of a complex app, especially any app that provides value without consuming storage (as your example illustrates).

My current thought is that rewarding apps may be better left to the app developer, who can charge using a subscription, time, or other appropriate metric, at a rate (in Safecoin micropayments) that reflect value to users, and cost of development, which will in turn be regulated by competition between apps / demand from users.

I get that might be good to have a very simple default that devs can easily tap into, but it remains to be seen if we can design a scheme that is economically and technically practical. Evenso, I think it would need to be optional so so developers don’t have to use it if they want to go totally free, or use an alternative.

Users that PUT data are more valuable than users that GET (leechers). The system rewards an App that encourages PUT new content into the network.(If not, you’re generating inflation) Though, It will be necessary an app rating, for detect malicious apps that spend all the user funds uploading fake data.
That rating can be the feedback from the users like Google Play.


@bcndanos I first dismissed your proposal without really thinking through it but with @dyamanaka explanation it’s actually quite a brilliant idea.

It reward app developers which is the first goal of the incentive model.

It takes safecoin from the pocket of the user which guarantee they are always making the moral choice of supporting someone.

It can’t be abused because the PUT request cost more than the reward gives. Actually, I would put the user’s address by default so people don’t create a PUT app to get the reward when they put a file without app. The PUT reward would just be redirected to another address when using an app.

It reward aggregators which is fine. As long as people are making the moral choice of supporting them by using their app and not just by consuming their contents it’s ok. Overtime, aggregators which payoff their content creator will get the best reputation, people will reason that since they pay anyway they might as well use an app that pays back the creator and since it’s backed into your PUT request you can actually see the money going to them, there’s no need to trust them for doing it.

Of course this “pigeon-hole” dev into making PUT heavy app but I can live with that. A PUT heavy app is much more interesting than a GET heavy one. And for apps that tries to abuse this they will soon find themselves with an awful reputation and people will just not use them. Add a little protection client side so an app doesn’t clear your wallet and we’re golden (should be there anyway).

It has no impact on farmers since the money is taken from the wallet of the user. Actually, they can now get back their 10%, devs don’t need it anymore.

What a stroke of genius @bcndanos, am I missing something, can the solution to all my concern be that simple?

I guess you could hack your client to override the PUT addresses with your own… It’s a small concern, you aren’t spamming the world with fake GET request at least.

I would add these 2 features if possible:
We need to be able to put more than one address to support all kind of cooperative effort. Like a post? Send 95% to the poster, 4% to the OP and 1% to the dev.

We need to have a record of all our payments so you can make sure everything is alright. Add a public database that creator can subscribe to with a reputation system and you can be sure the address you are sending your PUT request to goes to the correct person.

Brillant stuff, I need to let this sink in.

Btw you might have found the killer app right there, a backed in micropayment ecosystem that everyone can profit from. Incredible.

1 Like

@DavidMtl I just realized an unintended benefit to the PUT model we are discussing… Imagine an internet where trolls have to literally put their money where their mouth is. HA!

@happybeing yeah, all things need to be considered carefully. But I still think it’s a more efficient alternative to the GET scheme.

I’m biased because I will be a farmer. I favor rewarding Apps for sending me data compared to Apps that punish my bandwith with GETS.

1 Like

@dyamanaka With a forum app that shares a part of the income with the original poster the troll would actually be paying the person he’s trolling, man I love this.



1 Like

I think @bcndanos just fixed the internet, what a day.

1 Like

I think as a user it’s hard to trust this model.

Without it, an app that is wasteful of my storage is just that. It’s wasteful, it’s costly, but there’s no sense it is deliberately ripping me off. There’s still an incentive for the app dev to fix this, and reduce my costs. Win win.

With it, every app becomes a potential thief: App dev and users’ interests are in conflict, not aligned.

At first, I’m not sure if this matters or not, because obviously it could happen anyway. Any app, might have malicious code in it. I think the difference is that users will find it very hard to detect an app that is efficient, inefficient, or deliberately inflating costs to profit by stealing. I think this is an important point.

It creates a temptation for app devs that will be hard to resist and easy to get away with, which seems a risky combination.

So while I share your excitement at the idea of something simple that, when used honestly, would be brilliant, I don’t think it would work in practice.

I landed here two weeks ago. After reading the paper “Safecoin: The Decentralised Network Token”, my first concern was about how the network reward to the app dev. Then, I realized that reward on GETs operations can be a huge problem.
I think your idea is brilliant. But, why don’t let the user decide in the SafeLauncher how much he want’s to pay to the developer (0% - x%) for his PUTs operations? Anyway, a hacker always can change the destination account…

@happybeing I don’t have time to reply but I believe I got your concern covered. I’ll post later on tonight.

I prefer a transparent model:

App dev selects one or more of several network supported charging options, such as:

  • pay once (user receives key enabling unlimited use on this account)
  • subscription (user receives time limited key, automatic renewals until disabled, or ask me each time)
  • timed micropayment (user periodically tops up the app with an amount of Safecoin that is depleted by the app at a declared rate (authorised by a user signed key). I can imagine variations on this, such as a capped maximum per day, or for the dev to specify a minimum payment with the user having the option to pay at a higher rate, or make larger one-off donations etc.

I think this is good for developer and user, and can be made easy for both by building a standard charging UI into the launcher (as part of the authentication protocol between app and launcher - note to @Viv for later).

The point of this is it is very clear to the user what they pay, for the app dev what they believe the app is worth, and whether an app behaves or steals, but even this question might be put to rest. As part of this protocol, I think it’s feasible for the user to be protected from an app charging more than the user agreed.

Ps @DavidMtl sounds good!