SAFE Pod SF - SafeCoin - The SAFE Ecosystem

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!


I’m definitely in favor of flexible options.

I was thinking about search engines. They are GET heavy with almost no PUT. But we really really really need a good search engine. We should have different payment/charging options in the Launcher.

1 Like

Decentralized content spider, and filter system with plugins would definitely address the centralized aggregator issue; that could be an application; and the safecoins generated could go to a decentralize organization for distributing the funds to contributors to the software over time; and also it could reward the users of the app itself. Furthering content creation and stuff for the decentralized content spider to web onto :wink:


I understand your concern, but I think there’s a few way we can eliminate the risks.

Wallet safeguards
This is mandatory. Whichever incentive model they decide to go with we absolutely need this. This must be integrated in the Safe Launcher if we want users to feel confident in exploring the network, there’s no way around it. It must be customizable but default to a very conservative setup. All PUT request and money transfer must go through this, no exception.

The safeguard must be able to:

  • Stops all transactions from an app if the rate of PUT request increases rapidly. It works just like a seat belt, it gives you maneuverability if you move normally but if things get hectic it stops. (This should be very responsive on conservative settings).
  • Determine a set amount of Safecoin you allow an app to consume. Wanna try an app? Give it a small pool of Safecoins and watch how long it last.
  • Blacklist addresses. This is important, it will allow us to create a database of addresses known to be malicious and stop any application of sending any safecoins their way.

These settings must be customizable for all apps so trustworthy app that you’ve been using for a long time can be set to a more permissive setup.

Earning Safecoins and spending them will rapidly become part of you daily routine on the network so it’s important to get an idea of how much you spend and how much you earn. The client should come with a basic set of charts to help you figure out what’s happening. It will be a good tool to compare apps together and figure out which is more efficient and which isn’t worth using.

I expect these chart to be made mostly by third party devs but the launcher should provide a few basic ones.

I believe these two feature must be in place whether or not they decide to put the dev incentive on the PUT request. If not, being on the Safe network will feel like walking into a minefield, not quite safe indeed.

Aligning user and dev interest
So with the above two features I think the interest of the user and the dev will naturally align itself. Since any PUT request cost money, app efficiency will become a very important topic. Users will seek app from developer who have a reputation of creating efficient app. For a serious developer, it’s gonna be very important to build a solid reputation and this will end up being very rewarding.

And even if a reputation system isn’t integrated on the network side, it won’t be long before trusted sources start appearing with articles and blog post on what’s good and what’s not.

I think the network can be made pretty safe with these features whether or not they go with an incentive model set on PUT request.

I’m curious to hear what other dev feel about all this. It’s gonna be quite a new ecosystem for them to work in.

I’ll post later on more reason why the incentive model on PUT is awesome and how to integrate it with other charging options, stay tuned :slight_smile:


I really would like to hear more detail about the update mechanism. It was discusssed relatively shortly at the beginning of the talk and I found it a bit dubious I have to say. The argument that “AI” determines whether the update is “good” doesn’t really sound like something that is feasible as of now. I can see that working in regard to speed or data integrity for example, but what about backdoors or any malicious update. If there is no way for humans to decide whether an update is good or bad, well, I really don’t see happening to be honest.

One other thing I would like to mention, and please, please don’t take this the wrong way, but I think it is essential to hear constructive criticism in order to become better. I’ve seen a couple of videos from you and I think you need to work on your presentation skills. Bear with me here:

  • Make eyecontact as much as posible with all of your audience, try not to look down or to the side too much. This indicates that you’re not to confident and makes it easier for the audience to loose interest.
  • Listen to your audience and let them finish! You’re presenting and even if some of them get a bit rude, you need stay calm, let them finish and try to answer their question/concern as best and friendly as you can, otherwise you’re alienating the whole audience.
  • Work on your body language. I think it becomes obvious if you watch yourself in these videos. Don’t gesticulate too much, try to stand still, don’t “jump” around too much, this is very irritating and it distracts from your presentation.
  • Last but not least, the presenter needs to be more familiar with the topics, there was too much “I don’t know” in the presentation. I get that it is still before launch but most of the stuff was still very vague, even for this stage of development.

Again, please take this as constructive criticism that might help you in getting better at this, especially with regard to bigger audiences/events.

But thanks for doing this, I really appreciate it!