On creating SAFE alt-coins

This is an explanation on how I plan to create an alt-coin on SAFE for Project Decorum. It should be interesting to any potential Decorum investor and to people who wish to issue their own alt-coins but are unsure how.

Creating alt-coins on SAFE has been discussed before, but one of the requirements for the Decorum coin is that the supply is virtually infinite, because this coin is a utility coin. They serve as “Likes” in the sense that the owner can attach them to a particular piece of content as an endorsement by setting the owner field to the address (hash) of the endorsed content in question. This means that ownership of the coin is given up forever. This is why the supply cannot be hard-capped, the coin would effectively go extinct after some time.

The challenge was to find a way let people buy and create new coins from the network without this resulting in rampant inflation. At the same time the issuer should be able to do this cheaper for the pre-sale coins, or else there would be no profit incentive for a pre-sale for either the issuer or pre-sale participants.

Before telling you how I believe the above requirements can be achieved, I’ll first give a basic explanation on what coins in SAFE actually are.

Coins in SAFE (including SafeCoin) are data entities of the StructuredData type, who I prefer to simply call SD objects. Anyone can create a new SD object on the network (with some exceptions) for the cost of 1 MB in SafeCoin. SD objects have a number of interesting fields that are relevant for this explanation:

tag_type (64 bits)
identifier (512 bits)
owner_keys (list of owners)
data (up to 100 kilobytes)

The first two fields can be set when you buy the SD object from the network. The tag_type has some restrictions, you can’t for example just create a new SD object of the SafeCoin type, which is reserved. But the vast majority of tag_type values are freely available. Once the SD object is created, these tag_type and identifier fields cannot be changed anymore (they are immutable). The tag_type and identifier combination must be unique, because the address of the SD object in the SAFE network becomes SHA-512(tag_type + identifier). If they are not unique, the request to create the SD object fails.

The owner_keys list contains one or more public keys of the owners of the coin. The network only accepts modification of the SD object mutable data fields (such as owner_keys and/or data) if the request is signed by 50% or more owners whose public keys are in the owner_keys list. This is also how a coin can be transacted on the SAFE network, it’s a matter of changing the owner_keys list to the key(s) of the new owner(s).

So to create an alt-coin for your app/protocol, you can pick a tag_type value that isn’t reserved by the network or used by another app/protocol yet and buy a number of coins from a range of identifiers for 1 MB in SafeCoin each. If you want to hard-cap the total supply, pick a max identifier value for valid coins and put that in your (immutable) specification document and any implementation(s).

The problem is that unless you pre-buy 100% of your alt-coins, anyone can create new coins for the meager cost of 1 MB in SafeCoin each. There’s no way to claim a specific tag_type for yourself. I believe I found a solution to this predicament, which I’ll explain in the next section.

The solution is I believe the introduction of “mining”, but in a very different form from typical blockchain mining. Rather than mining a block of transactions as in Bitcoin, here we directly mine the coins themselves.

The proces of mining is to find a nonce value for a given input so that when the input+nonce are hashed, the output is lower than a difficulty target value. In Bitcoin mining the difficulty target is a value that ensures the Bitcoin network finds a new block about every 10 minutes on average.

In this idea the mining difficulty is derived from the identifier value of the coin to be mined, and the input is simply the identifier itself. In our (immutable) protocol specification and our implementation(s) we put the rule that a coin is only valid when the data field of the coin contains a nonce that when hashed with the coin’s identifier results in a value lower than the difficulty target. In other words, the coin itself contains it’s own proof-of-work!

The consequence of this scheme is that the coins with the higher identifier values have lower difficulty targets. This means that the “highest” coins are extremely easy to mine, but this difficulty increases for “lower” coins. So the initial issuer of the coin (in Decorum’s case that’s me) can at a very low cost pre-mine the pre-sale coins before (s)he announces the alt-coin’s tag_type to the world.

After that other people can also buy new coins from the network and try to mine them, but that will be considerably more difficult than it was for the issuer. As more coins (with high identifiers) are mined, the difficulty keeps increasing. It only makes sense to try to mine coins when the cost of doing so is lower than the cost to buy already existing coins on the free market. This puts a serious constraint on the rate of inflation of the coin.

Note that the protocol designer has control over how quickly the difficulty will increase. For example, a difficulty target defined as coin's identifier / 4 increases difficulty a lot quicker per mined coin than coin's identifier / 2. There are no restrictions here, pick a formula that results in the difficulty (and thus indirectly inflation) curve that fits your project.



Coins in SAFE have numbers. Coins with high numbers are easy to mine, coins with lower numbers are harder to mine. Coins with highest numbers are pre-mined for the pre-sale, after that inflation is constrained because mining gets harder as only coins with lower numbers are left to mine.

Dunno why I bothered with OP! :smiley:


It is interesting what you mentioned; I’ll read again a few times,

So someone will be hashing the tag_type value + a nonce and that person then forms a structured data containing the new coin with the validating info, that this is a valid coin according to the algorithm and be able to assign it to others

This is an awesome idea, some more to think about;

1 Like

Interesting, thanks for sharing.

Can you elaborate on how the max identifier rule is set, and who enforces it?

In Bitcoin mining the difficulty target is a value that ensures the
Bitcoin network finds a new block about every 10 minutes on average.

In this idea the mining difficulty is derived from the identifier value of the coin to be mined

How does this play with the fact that some hardware computes hashes at different rates than others, which the bitcoin blockchain does account for? Perhaps in a year a computer will be efficient enough to mine the rest of the coins within a second?

1 Like

The software implementations the users use do, like any rule. The implementation(s) should simply ignore any coin that exceeds the max identifier. The protocol specification (whitepaper) can be made immutable so implementations can be validated. I guess you are concerned about having only major one implementation that is sneakily changed by the owner to commit fraud? Immutable implementations and variety of open source wallets are the only safeguards. In the end there is nothing else that can be done there as far as I know.

It’s not a concern for project Decorum though, as the coin won’t have a hard-cap. :slightly_smiling:

Difficulty increases because the identifiers of the coins available for mining lowers as more coins are mined. If one wants to severely limit inflation, the difficulty algorithm should be chosen to create a steep rise in difficulty. I’ll see if I can create some examples with graphs tomorrow.

Hashing the identifier + nonce, yes!


As an aside, what’s the beef with inflation?
Numbers get bigger, so what?
In a digital economy value is infinite once the power is switched on, ergo “let it rip”
Command and control has us where we are, your posit is more of the same, profit for the “issuer” should not be the primary goal in this instance, imho.

With the data he has given, you can create any sort of coin you want. Usage is voluntary, depending whether or not you want to play the game presented.


@Seneca, this is very cool.

I really appreciate the explanation. I’ve been messing with ideas about how to do this sort of thing, but really don’t have the knowledge to know where to start. I’m really looking forward to how your project roles out.


I just figured that a hard-cap can simply be integrated in the difficulty target formula, by choosing one where only a particular number of coin identifiers result in a difficulty target above zero. The others won’t have a valid solution and can by definition not be mined.


Thank you that you did, it gives a better idea how to do it.

[quote=“Seneca, post:5, topic:7192”]
open source wallets
[/quote] Will SAFE altcoins have the same problems that bitcoin altcoins have due to their wallets? For instance with Coinprism you can send a coloredcoin to every bitcoinaddress, but by doing so, your coin can be lost forever, if the wallet is not able to read your coloredcoin tag. Counterparty solves this problem by informing the sender that the address, that they want to send a coin to is not a Counterparty wallet.

1 Like

No, SAFE natively recognizes SD objects from different types, so no worries there!

1 Like

This would make a really good rfc so many folks can punch holes in it if possible. On first look it appears though to be extremely well thought out. I think we should formalise this and make it a part of documentation on the wiki/web site etc. as many folks will be very interested in this process. Be neat to also run tests on this during the testing phase. If such coins were able to somehow get tagged/pegged for a side-chain type solution then who knows what possibilities would come of it.

I can sniff a potential mechanism for divisibility etc. as well, this could grow into something quite substantial indeed. Best of all it’s the community now starting to take hold and be the innovators on their own network (SAFE) and this has been a goal for sure. Great work @Seneca as we move through the mvp you will get a lot more maidsafe eyes on this as well to help out.

TL;DR Here lies a potential game changer for the SAFE network and projects that run on it.


Could you not also just reject any coin over limit identifier as not a valid coin.

Forgive me for asking what should be obvious, the outline process is that

  • The user buys from the SAFE network one or more SDs giving them the tag_id of the “alt-coin” being mined and an identifier that has not been used for the tag_type.
  • If the user is smart then they set their identifier to one less than the current minimum
  • How does anyone know what the current minimum ident is???
  • the user thus owns the un-mined “alt-coin”
  • the user then proceeds to “mine” the coin to find the nonce that makes it valid
  • the user can then use the coin

Would this be the basic process?

Also the question I had about how one knows the smallest ident that currently exists, since AFAIK SAFE does not have any way to know. It only knows when you try to buy a SD with a tag_type/ident that exists the purchase fails

1 Like

If he can choose where to aim, this is how the miner learns he’s failed, although an intelligent miner would do a search (I patent using a bisection algorithm for this purpose :wink:) to locate the current maximum unused identifier.

However, I’m not sure he can choose, so that might be rubbish. Bring on the RFC @Seneca! :slightly_smiling:

1 Like

Yes without some other method a modified binary search would seem to be the only real option

What I was very much more interested to know is if my list of steps is right. If not then my understanding of what @Seneca wrote is wrong.

Yes it’s correct, but you’d be looking for the maximum unused identifier rather than the minimum. Higher identifier → higher difficulty target. Higher difficulty target is easier to mine.

I think serious miners will generally buy a large set of coins in advance to mine them. It would also be possible for non-miners to buy high ID coins to sell them to miners later on. Might not pay off though.

@seneca how to identify the highest ID coin?

Or that presale part sets the maximum ID value, and then
Then it becomes a race to get the valid nonce with the lowest Identifier
and only less than presold-highest ID value == almost like how genesis block works…

Then you would fill the content of the STructured Data with the parameters, and future people and applications and validate that this coin was in fact properly mined. Since the STructuredDAta at that spot is consumed and can’t be duplicated by others since it is an owned “domain” already.

Then person can send forward to someone else interested in that coin, and validate it is a legitimate coin.

Lower Identifiers are harder to get because that’s the obvious place to start and also highest id coins on the way down, I think so.

Very much enjoying where things are going; @seneca, Using bitcoin keys can generate a script that could be used in the content of StructureData and passed around and validated by others; I am seeing that this will be happening, this mining spec, this is awesome!!

Now a way to have unique

1 Like

Brilliant stuff, Seneca!

If there was a way to adjust difficulty based on minting rate too, it would be the icing on the cake!

1 Like

And… buying more safecoins.

You’re doing the lords work. haha.

1 Like

Essentially, people could participate in the forum in an example… people can participate in the forum using coins they generate from their own motivation. No one would have to sell coins to the people; coin acquisition can take place locally, personally.

And the algorithm distribution would give a meaninful quantity based on participation; more coins potential could indicate more demand;

and could they also be visibly consumed, and continuously be regenerated

1 Like