The ideal "Traditional Cryptocurrency" that can be used by nearly everyone, nearly instantly, and nearly freely.
Published: 2/21/21
Update: 6/22/21
Author: GiverofMemory
Maintainer: GiverofMemory
License: Site License
Categories: See Footer
See Also: Digital collectible network, Chromaton, Transep
Page: (upload / browse / edit / print)
Discussion: Monaton-Talk
Download: URL,PDF from URL


Blockchain coins aren't the real money. Blockchain is the network of banks. Tokens are the Federal Reserve. So blockchain's optimum use case is as a settlement layer. And knowing this we can create the best blockchain.

The important factors in a blockchain are:

  1. Cheap fees forever (non-deflationary emission)
  2. Fast settlement (High TPS)
  3. High security (resistance to 51% attack) Which includes Decentralization
  4. Full programmability (Turing complete).

Blockchain coins like ETH or BTC are nothing more than incentives for miners providing to provide these four features.

The real money is tokens like Tian. Blockchain coins (Like BTC or ETH) are like stocks or assets that incentivize miners to provide secure and fast settlement. Tokens will eventually be layer-2's and will only settle with the blockchain daily or at another set interval.


Monaton is an attempt at perfecting "Last Generation" or "Legacy" Cryptocurrency. There will always be a place for Nakamoto Consensus as a robust "error corrected" version of cryptocurrency that "just works" and can be relied upon. If for nothing else than to generate globally accepted, truly random numbers since we don't know who is going to win the next block. Many applications can be built upon just this aspect alone.

We will make some tweaks to Nakamoto's original design in 3 main places.

  1. Consumer hardware mining. We will make sure that 1 PC = 1 Vote. Sha-256 has been easily parallelized making asic's the only profitable way to mine Bitcoin. Solar Designer and others have been tirelessly working to create hashing algorithms that keep mining within reach of consumer hardware.
  2. Scaling Blocksize. See Transep and Meta ledger for more info; we will solve the blocksize dilemma by using a hashchain instead of a blockchain, basically only the block header is transmitted by miners and the transactions are on a side-chain maintained by both nodes and miners. This way the "blocksize" can scale infinitely only limited to the "parcel optimization" which is a sister to "knapsack optimization". Side-chains work; as demonatrated by Dogecoin basically being a side-chain to Litecoin (merged mining).
  3. Forever block reward. Transaction fees are scaling unsustainably in Bitcoin and fees will not be sustainable when all Bitcoin are mined. This is because the transaction fees will become way too high when there is no longer a block reward. Around 2000 transactions fit in a block [1], and with current block reward of 6.25 bitcoin at $50,000, that would mean at this rate each transaction would need to pay an extra (6.25*50,000)/2000 = $156 (on top of the roughly $5 fees bitcoin currently has per transaction). It is not feasible to pay miners just in fees as this would make all transactions that are under $10,000 impractical. Therefore we will instead pay miners in a small inflation rate of the coin to keep fees low and people sending coins. Of course having 'infinitely' large blocks will help, but still fees would grow too high unless there is a small amount of inflation to reward miners. Bitcoin currently has over 2% inflation (in 2021) and it's price keeps rising which proves that a small predictable inflation is not a bad thing!


BlockTock is an idea to allow for scheduled execution smart contracts. The idea is simple, you "sign up" an address to receive dust from every mined block. This transaction can help smart contracts to do something at a scheduled time. There is a transaction in every block that creates new coins and gives them to miners, called a "coinbase" transaction (no relation to the website). Every signed up address would be added to this transaction and get the smallest unit of currency.


This will likely he a hard fork of Dogecoin. The reason for this is there is already a large userbase, and the same type of people who like dogecoin will like this coin. The block reward will start out the same as well with 10,000 coins per block (but will grow slowly over time) so we are in a perpetual tail emission that tends towards 1% inflation instead of the 0% inflation that Doge tends towards.

Forking a current coin's blockchain is helpful in that we don't have to have a period of relatively high emission to create the initial coin distribution. Since Doge is already widely and somewhat fairly distributed, it is a good starting point at which we can start with around 4% inflation and head down to 1% instead of starting at 100% inflation rate.


Emission is decided to be as fair as possible to both late and early adopters. The way we achieve this is by having an increase in coin emission above last years emmission by ~1%. This means that more coins will be mined next year as compared to this year, but only ~1% more so inflation will be minimal. There still is an early adopter advantage, it will likely be much easier to mine this year than next year because mining competition will likely grow by much more than 1% per year. The reason why we don't tune the reward to give exactly 1% of the total coins per year, is that how do we initially distribute the coin? By letting inflation % be high early and gradually lower toward 1%, we get a very fair and decentralized distribution.

As time goes on, the coin will reach a place where the initial amount of coins mined per year is insignificant to the total coin supply. At this point we will have reached the true tail emission, where the coin supply grows by only 1% per year. This is achieved by increasing the block reward by 1.0101010101...% each year compared to the previous year. See attachments for a csv file showing this.


Ideally an algorithm that is both memory and L2 Cache (and ideally L1 and L3) hard, where increases in difficulty increases the Memory and L2 cache utilization rate. So as the network grows, ASIC's will become obsoleted as the hashrate grows since they don't have enough Cache and/or Memory. This is fine for CPU's since firstly when they are in consumer grade hardware they have more cache and memory than any gpu or asic, but also because consumer hardware keeps increasing cache and memory every year.

A good candidate is Yespower and perhaps some progressive cryptonight algorithms. The goal is to achieve as close to "1 CPU = 1 Vote" as possible. Factorizations of large numbers is an ideal candidate and is used in digital collectible network because it is "1 CPU + 1 GPU = 1 Vote" (which is even harder to build specialized mining rigs for) however it would be difficult to implement into a traditional cryptocurrency since in factorization, collaborating groups of miners would get more than linear increases in factorization speed. Finding the factors is not a random chance, so collaborating miners could win proportionally more blocks than solo or small pools.

Coinbase maturity

You must wait 40 weeks (9 months) after mining a block to spend the transactions. Bitcoin is currently 1000 minutes which is about 17 hours. This 9 month requirement makes sure miners are dedicated and not just jumping to the most profitable coin. This also makes it so that only invested miners can sell, thus stabilizing the price. Also solo mining is more viable since you will have to wait 9 months to spend your coins anyway you may as well solo mine even if it takes a month to win a block.

Transaction fees

No minimum transaction fee. You can add a transaction fee for transaction priority to miners if desired. Theoretically since we never run out of block rewards, we don't technically need transaction fees. In practice some fees will be needed to incentivize miners and masternodes to pick up all transactions.


See transep and meta ledger for a more detailed rundown. Ideally consists of only a chain of final block hashes. Transactions are kept on sidechains and these proposed (candidate) transaction blocks must be proposed to at least 50% of the network before the last block reward is proposed to 50% of the network. So if a miner did not hear about a transaction block before the last block was mined, he will not accept a vote for that block as the winner for the next block.


A series of hash-blocks is what makes up the hashchain. Each hash-block is like a blockheader on a typical blockchain with a couple extra fields. However we omit version stamp.

The timestamp cannot be trusted. Say a miner sends out a hash-block with an earlier timestamp than another hash-block, yet you heard about the later timestamped hash-block first. Which one was really first? The one you heard about first, the timestamp doesn't matter. Thus we would omit this, however we see in hash-block components that we may have a use for the timestamp.

Secondly the version number is a centralized thing and if the devs want they can change this and then tell miners which version numbers to accept or reject. I don't think devs should have this power and see no reason for this other than acting as a sort of checkpoint, miners can't be mining an alternate chain in secret and then broadcast it since they wouldn't know what version numbers to use. If we want to do checkpoints then we can just do checkpoints instead of version numbers; and instead of the version number hack we can be transparent about intentions.

Components of each hash-block


As we said before, a timestamp is basically worthless in our hashchain since it cannot be trusted. However I have one possible use for it. Lets say we are all happily mining on the hashchain and out of nowhere someone proposes a chain restructure of 100 blocks that we have never seen before. How do we know that the difficulty the miner used was valid when they mined it? In this case we can use the timestamps of our old blockchain and the difficulty, and match them up with the new chain and see if the difficulties they used match up with their timestamps and our timestamps. This way we can verify that the segregated miner was doing at least as much work as we were before we accept his chain restructure.

Previous hash-block hash

The hash of the entire previous hash-block. This is different than the merkle root that resides within the last hash-block; the previous hash-block hash includes the hash of the last hash-block in entirety, including the winning nonce.

Candidate block hash (merkle root)

In our design, transactions are not included into the the main blockchain (called hashchain). They are kept on a sidechain that both cnodes and miners would maintain. The link between the sidechain and hashchain is the merkle root (hash of the candidate transaction block). The transaction block is hashed and this final hash is included in the hash-block. The transaction block is called a candidate block before it's root is included in the hashchain, and it is called a target block after it is included in the chain. Target blocks are candidate blocks that won by being mined upon by a miner.


The difficulty is how many leading zeroes are needed when the nonce is hashed with the merkle root. When another miner (dnode) recieves a proposed hash-block, they will check what they believe to be the network difficulty against the hash-block's proposed network difficulty. Then they will hash the proposed hash-block's nonce and merkle root and see that the difficulty requirement was met. The difficulty does not need to be explicity said in the hash-block since just hashing the nonce with the merkle root will tell you the difficulty, but it does help hashchain analysis after the fact, so we will keep it.


The nonce can be as long as desired, which solves the current problem of not having enough digits allowed to solve the problem at the given difficulty. A nonce is like a key and it is a number that, when hashed with the merkle root, gives us a number that has a certain number of leading zeroes that fulfills the difficulty.

Coinbase tx

The coinbase transaction is where new coins are minted. The miner specifies how many coins are made, and they are given to the address of their choice if their hash-block is accepted by the other miners.

Feebase tx

The feebase tx is the cnodes bid for having his block be accepted to the network. By signing his cblock, the cnode verifies that they transfer the bid coins to the miner upon their block bieng accepted into the network. Basically the cnode is writing a signed check that the miner is allowed to endorse and deposit to an address of his choice.

Transaction block (sidechain)



The blocksize transmitted by a miner is constant and very small, only a few hundred bytes.

Transaction blocks

However transaction blocks which can be proposed by any node not just miners, can be as large as you like. The catch is you have to get it transmitted to 50% of miners before a solution for the the last block is found. Thus an "optimum size" will be arrived on by market forces to propose a currently correct transaction block (no other transactions in the block were mined in a previous block) in time for it to be useful and maximize transactions present to maximize fees generated. Minimizing the size of the of transactions and maximizing their fee to put in your block (knapsack optimization), but also minimizing time to travel across the blockchain is our "parcel optimization". In practice; minimizing the size of the transaction will also minimize the time to travel, however the size of the parcel (amount of transactions to include) is also a variable in our parcel optimization.

Candidate blocks

Candidate blocks are transaction blocks compiled by cnodes that have been broadcast to the network.

Target blocks

Target blocks are candidate blocks that have been not only broadcast to the network as candidate blocks, but also been mined upon by a winning miner and whose hash is included in the hashchain.

Determiner nodes

Aka miners or dnodes, determiner nodes decide which candidate block to mine on. If they win the mining challenge, then the candidate block they were mining on becomes a target block, a block who has made it into the hashchain and been confirmed.

Compiler nodes

Cnodes for short, they are really just normal nodes that decide to compile transactions they hear (after checking they weren't already included in a block or likely are in the current block bieng mined) into candidate blocks and recieve the fees from the transactions. They then make a bid so the winning miner will select their cblock (candidate block) to mine on. When the challenge is won, only the hash of the node block makes it into the blockchain. Thus the blockchain will be renamed to the hashchain. Cnodes need not only the hashchain to work with, but all previous target blocks (cblocks that are called out in the hashchain, so they were accepted by the network) so they can verify all proposed transactions to include them in their cblock.

Broadcaster nodes

Bnodes for short, broadcaster nodes are just customer nodes that create valid transactions. They would have the hashchain and only transaction blocks that they need in order to know their current funds.

Public key cryptography

Cryptography should be ECDSA-512 or ECDSA-1024 (Bitcoin is ECDSA-256) to resist conventional and quantum computers for as long as possible. Soft forking to new address requirements in the future would keep the addresses safe from attack.


Edit: may start around 60s but this depends on the hashing algorithm and how fast it is. The below is best case scenario but not likely.

Starts at 40 seconds and reduces 1% every year until it reaches a minimum of 14.79 seconds (100 years) at which point it stays constant. The reason for this number is it takes light 130 ms to go around the world so assuming we have technology that approaches that, we want it to be 100x longer than that so the previous miner only has a 1% advantage on the next block since he started mining 130ms before you did. An extra 1.79 seconds for delays in transmission making it 14.79s.

The reason it is 40s and not 60s to start when compared to doge, is our miner blocks are much smaller than doge (256 bytes? vs 500 kilobytes) and thus traverse the network much faster, likely in under a second.

Block reward

10000 coins per block. After 161 years roughly, this number is increased 1% per year to keep a 1% yearly inflation after the blocktime reaches a minimum. So year 162 each block will have a 10,100 coin reward; in year 163 each block will have a 10,201 coin reward, etc.



Blue doge looking pepe. Or a demented fox.


Pew Pew and Brr... and Lit and Ripp.. and stonks and tendies and yolo and zoom zoom and gotta go fast and oh fo sho and to the moon and nyoooom and up up and away and i have a very particular set of skills Bits at the speed of sound


Mona- refers to money or Mona lisa. -ton refers to "smallest unit of" or literally a Ton of something. Adapted from the name chromaton.

Or Sonicoin referring to money at the speed of sound.

Or Tailcoin for tail emission. Or just Tail or Tails.

Developer responsibilities

I am not going to contact an exchange to list the coin. If you want to do this than that is great. To me it is more important to have a community that shares or barters coins before having a mechanism to sell them.

I am not going to run a pool. I suggest solo mining when possible.

I am not going to continue to develop the miner. People that work on miners can do that, we will launch with a basic miner.

I am not going to maintain general development fund. Each developer can have their own fund (receiving address) that they maintain.

I will, as long as I am able, make sure of two things. First that the algorithm continues to be ASIC (and GPU) resistant, and that the addresses remain secure from attack. Soft or hard forks will be done as needed to maintain these two things.


Historical block propogation times (probably around 1s) [2] [3].

Asymetric merged mining [4]

Dogetags for sending coins to a handle instead of recieving address [5]

Meta ledger as a precursor to this idea [6]

Bitcoin Scalability and Blocktime [7]

Learning about Cache [8]

Loki algorithm discussion [9]

Stablecoin stability [10]

Yespower PoW [11] [12] [13].

bcrypt [14]

password security history [15]

password hashing [16]

ROM hard hashing functions [17]

Equihash analysis [18]

Merged mining [19].

GNFS polynomial selection on GPU, sieving on CPU and post processing on clusters for multithreaded linear algebra (post #21) [20]

Other pages that link to Monaton:

Attachments to Monaton:

Password to edit: nature