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.
) to locate the current maximum unused identifier.