Cardano

From Organic Design wiki
Revision as of 12:07, 27 December 2019 by Nad (talk | contribs) (→‎Register the pool in the official registry)

Cardano is home to the ADA cryptocurrency, which can be used to send and receive digital funds. The currency is named after Ada Lovelace, who was the first ever person to recognise that a machine had applications beyond pure calculation, and she published the first algorithm intended to be carried out by such a machine. A millionth of a single ADA token is called a Lovelace, the smallest denomination in the Cardano network. Fast, direct transfers are guaranteed to be secure through the use of cryptography and require no trusted third party just like Bitcoin, unlike Bitcoin, Caradno does not require a computationally expensive mining operation in order to secure the network, and has been mathematically proven to be as secure as Bitcoin without it.

Cardano is more than just a cryptocurrency, however, it is a technological platform that will be capable of running financial applications currently used every day by individuals, organisations and governments all around the world. The platform is being constructed in layers, which gives the system the flexibility to be more easily maintained and allow for upgrades by way of soft forks. After the settlement layer that will run ADA is complete, a separate computing layer will be built to handle smart contracts, the digital legal agreements that will underpin future commerce and business. Cardano will also run decentralised applications, or dapps, services not controlled by any single party but instead operate on a blockchain.

Cardano development eras

The Cardano functionality is being developed in five so-called eras, each gathered and presented on its own dedicated page: Byron (laying the foundation), Shelley (staking and decentralisation), Goguen (smart contracts), Basho (network optimisation and scaling), and Voltaire (decentralised governance). Each page has an overview of the goals of the era, as well as descriptions of the core functional components, links to associated academic research, status updates, and even real-time code commits. Each era is centred around a set of functionalities that will be delivered across multiple code releases. While the eras of Cardano will be delivered sequentially, the work for each era happens in parallel, with research, prototyping, and development often in progress all at once across the different development streams.

The Ouroboros protocol family

Cardano uses a proof-of-stake (PoS) mechanism based on the Ouroboros protocol family. The usual "longest chain rule" that secures proof-of-work blockchains like Bitcoin is not directly applicable in PoS systems. Nodes that (re)join the network for the first time or after being offline for a while therefore need to trust the information that they receive from other nodes. This is known as the bootstrapping problem, which increases the network’s vulnerability to long range attacks. In a long range attack, a node is offered an alternative version of the blockchain and the node has limited or no recent information available to distinguish whether this is the correct version. Proof-of-stake systems have been around since 2011, but as of late 2019 Cardano is the first one to overcome all of these design challenges in order to reach the same level of security as Bitcoin.

There have been a number of versions of the Ouroboros protocol released so that the various aspects could be tested and developed in phases - not to be confused with Cardano's eras. The first version which is now being called "Classic" was the basic PoS system that depended on all nodes being constantly connected and in-sync. the next version was "Praos" which allowed for nodes to come and go as they please, which is of course an essential aspect of a real-world peer-to-peer network. The next version was called "Genesis" which was major, because that's what brought all Cardano's promises of a new superior system into reality.

Since Genesis, Ouroboros was the first PoS protocol that is mathematically proven to guarantee persistence and liveness in both a synchronous and semi-synchronous setting — under the assumption that a honest majority participating, just like Bitcoin. Hence, it is more secure than other PoS protocols that require at least 2/3 honest participants (e.g. Ethereum Casper, Algorand) and equally secure as Bitcoin, but with a much lower energy expenditure and better performance.

The version that was first released with the Shelley testnet was called Chronos which allows nodes to operate together without depending on a global time external to the network, making the system more independent and resilient. The final planned version of the protocol is Hydra which introduces sharding into the system.

Staking in Cardano

Cardano uses the Ouroborus (Currently the Chronos version) proof-of-stake algorithm to secure the network. In addition to the main block chain, this system divides time into epochs and slots. In the mainnet, there are 21,600 slots each lasting 20 seconds which makes an epoch 5 days. In the incentivised testnet, slots are only 2 seconds long and there are 43,200 of them making up an epoch of 24 hours. During each epoch, random numbers are written to the blockchain; those numbers provide a mechanism to randomly select future slot leaders. In essence, this mechanism signifies the symbology behind the Ouroboros name: a snake eating its own tail.

The Cardano staking system fundamentally works to incentivize two primary activities. The first is making sure that stakeholders are online. The second is participation in the protocol, i.e., block creation. Because there are many people who are either unable to run their own servers with 24/7 uptime or who don't want to create a stake pool, they will be able to delegate their stake to a pool of their choice. Delegation addresses are different from standard ADA addresses.

Unlike Ethereum, or other staking protocols, users funds are not at risk of being "slashed" or destroyed in case they attempt to participate in the protocol in an inappropriate fashion; the design of the system makes that unnecessary. In fact, user's funds are not at risk at all in any way because they never leave a user's wallet and can even be spent at any time without needing to be "locked up" into the staking system.

Staking pools

To stake your ADA coin, you can either set up your own staking pool or delegate your stake to an existing public pool which can be done from within a supporting wallet such as Daedalus or Yoroi. The person who maintains and controls the pool, and sets its parameters is called the pool operator. A pool's chance of winning is proportional to the total amount of ADA the pool holds for staking (every single staked Lovelace, the Cardano version of a Satoshi, is like a single lottery ticket) which is called the controlled stake. This means that everyone's rewards will average out over time to be in proportional to what portion of the total staked coins they have at stake. But the problem is that the smaller the portion of your coins are, the longer it would take to average out - someone with only a millionth of the total stake would be waiting centuries to realise the average and may go decades without even receiving any rewards at all!

This is why it makes sense to delegate your stake to a pool if you have less than say 0.01% of the total stake. The pool has a lot of individual people's stakes delegated to it, and so as a whole it receives regular rewards in proportion to it's total. Then at the end of each epoch, the rewards the pool received are automatically distributed to the delegators by the Cardano protocol.

Rewards

Rewards are distributed among all stake holders every epoch (which is 24hr in the testnet and 5 days in the mainnet). Rewards automatically contribute back to your stake, but your stake is not locked up, so any amount of stake can be spent at any time. Approximately 3.8 million ADA will be awarded per epoch in the testnet.

Tax

Pools can charge a percentage (called margin or tax-ratio) and/or a fixed amount (tax-fixed or pool cost) per epoch. There is also an optional parameter called tax-limit that allows a pool operator to specify an upper limit to the amount they can take each epoch. These costs can be changed by the pool operator any time and will take effect at the start of the next epoch, staking wallets will notify users of changes in their pools costs. Each pool has a chance of being elected as the slot winner for every slot and gaining the right to create the block corresponding to that slot. The pool's performance is measured by the percentage of blocks assigned to them that they've successfully created, which in the case of well behaving pools basically equates to up-time.

Delegation

You delegate your stake to a pool with a special type of transaction which supporting wallets will do for you. This transaction will not take effect until the end of the next epoch, and then you will start earning rewards until the epoch after that, and you'll receive your first rewards at the end of that epoch. I created my first delegation transaction to LEAF pool in epoch 3, and then my first reward transaction arrived at the start of epoch 7. During epoch 7 I changed my delegation to BCSH, in epoch 10 I changed to LCP01 and in epoch 11 I changed to our own PUDIM pool. I received rewards continuously throughout all those changes, so it seems there's no downtime resulting from changing delegation.

Desirability

This is the most important metric for choosing a pool and reflects the real rewards you're likely to receive. The wallet orders pools by desirability. Desirability is composed of reliability (mainly up time), pool costs, profit margin, saturation and pledge. See this video for details about how desirability works.

There is a network variable called k which maintains equilibrium between efficiency and decentralization, by limiting the desirable number of pools appearing to ADA holders for delegation selection. K will start at around 100 and will ideally aim to be around 1000. As far as Cardano's framework is concerned, the majority of delegated ADA must go to those owners of pools that make it into the top k pools which are called competitive pools, and will be the only ones displayed in the staking-capable wallets. Those that don't make it into the top k will not be visible and are called dead pools. The stake pools that make the k do not have to go out and ask for ADA they will be saturated naturally, by design.

Quote.pngEven if every user were to run a node that was online all the time, it would be hard to keep all those nodes well enough in sync to avoid forks and still keep a short slot length. Our delegation design is aimed at keeping the number of nodes that produce a significant amount of blocks reasonably small (about 100 or 1000 nodes), so that effective communication between them is feasible.

Saturation

To help prevent any single stake pool from growing too large, there is a mechanism to ensure pools saturate at a certain percentage of the total stake in the network. If any stake pool exceeds this percentage, then the rewards for that stake pool will no longer increase but will be shared among delegators, making the pool less desirable. This is 1/k (if k is 100, then pool rewards are capped at 1%) and is discussed in this incentives paper.

Pledge

The pledge variable makes the separation of operator and owner(s) possible, maximising the number of pool owners within k. It's an elegant solution that enables Cardano to reach its k target of 1,000 public pools while encouraging those with limited Ada to pool their holdings and pledge to a pool operator, thus maximizing the diversification of pool owners while maintaining network efficiency. The Incentivised Testnet has the concept of pledging, whereby stake pool operators delegate their personal stake to their pool and register a pledge address when they register the stake pool with the Cardano Foundation. Pledging is not currently enforced by the network protocol (although it may be in the future) and functions to increase the attractiveness of a pool, meaning that other delegators are more likely to delegate to that pool. The person(s) who pledges to the pool is called the pool owner. Pledging follows the same process as delegation.

The effect that the pledged amount has on a pool's desirability is determined by a network parameter called a0. An a0 value of zero would mean that the pledged amount has no effect on rewards at all, and a high value like 0.5 gives pools with large pledges are big advantage. This is explained on detail in the article Preventing Sybil Attacks.

Private pools

In section 4.1 (Stake Pool Registration) of the Staking Design Specification, it says that publicly announcing a stake pool for other people to delegate to requires two steps: posting a stake pool registration certificate to the blockchain, and providing pool metadata, additional information about the pool. The certificate contains all the information that is relevant for the execution of the protocol (public key hashes, cost, margin, and pledge) as well as the content hash of the metadata, while the metadata will be displayed to end users by their wallet. For specifics about the metadata, see Section 4.2. If no metadata is provided, the stake pool is considered a private pool, and will not be displayed in wallets.

Also in Section 3.4.5 it says that usually, the stake pool operator and owner will be the same person, but a stake pool can also have multiple owners. This is to allow people to coordinate and form a stake pool even if none of them had enough stake on their own to make a pledge that would make the stake pool competitive.

And finally in Section 4.6 (Individual Staking) is says stakeholders should not be forced to delegate their stake to a pool. Instead, they should have the option of running their own node, using their own stake. Technically, such stakeholders will create a private pool, which is just a stake pool with margin m = 1 (i.e. operators take 100% of the profit), and without providing metadata. Such pools will pay all rewards to the pool operator (which is not a special rule, but just the effect of having a margin of 1), and they will not be shown in the stake pool directory in Daedalus (although even if they were, they would always be listed at the very bottom, since they would not promise any rewards to their members).

We had looked at other options that would not require individual stakeholders to register a pool, but they either complicated the design, or made it possible for free riders to contribute stake and get a share of the rewards by using suitably chosen addresses. The mechanism of private pools adds no additional complexity to the delegation system (the only added work is to suppress their listing in Daedalus). Optionally, the front-end could even set up (and retire) a private pool at the press of a button, but this is not a must-have feature for the initial release.

Running a staking pool on the incentivised testnet

To run a staking pool you'll need a reasonable server that is on a reliable high-bandwidth connection. First you need to install the node software, then create the cryptographically signed staking pool parameters associated with a funded pledge address, and then finally register your pool so it shows up in the staking wallets. This section is mainly based on the instructions at Stake Pool Operators How-To with a few differences.

Install and configure Jormungandr

We start by installing the latest release (not a pre release) of Jormungandr from the official repo (it's a good idea to subscribe to the repo's feed so you can know as soon as new stable releases are available). One important difference from their procedure is that we need to use the itn_rewards_v1 configuration rather than the beta configuration. A couple of differences from their procedure too: first I had to change both 0.0.0.0's in the config to my external IP not just the public one, second a storage location needs to be added to make the chain data persistent. The first few sections of your config file should look something like this: 

{
  "log": [
    {
      "format": "plain",
      "level": "info",
      "output": "stdout"
    }
  ],
  "storage": "./storage/",
  "p2p": {
    "listen_address": "/ip4/1.2.3.4/tcp/3100",
    "public_address": "/ip4/1.2.3.4/tcp/3100",
    "topics_of_interest": {
      "blocks": "high",
      "messages": "high"
    },
    . . .

Another issue is that I was not able to find any genesis hash in the configuration as it says there should be, I had to obtain it myself from the last page of slots for epoch 0 which yields this (later I found this parameter and others here).

I create a script called start.sh to run it with the correct parameters in the background and redirected its output to a log file: 

#!/bin/sh
nohup ./jormungandr --config itn_rewards_v1-config.yaml \
      --genesis-block-hash 8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676 >> debug.log &

If you see no errors in the log and the daemon keeps running, you can check the sync progress by running the node stats command and checking that the lastBlockDate matches the current epoch and slot shown in the Shelley explorer. 

./jcli rest v0 node stats get --host "http://127.0.0.1:3100/api"
blockRecvCnt: 41
lastBlockContentSize: 0
lastBlockDate: 7.35623
lastBlockFees: 0
lastBlockHash: "f78c64c030383899ebb1b25dac7ae9d360d222d0b80320323375dc51762651d2"
lastBlockHeight: 26342
lastBlockSum: 0
lastBlockTime: "2019-12-21T15:15:20+00:00"
lastBlockTx: 0
state: "Running"
txRecvCnt: 45
uptime: 886
version: "jormungandr 0.8.3-8f276c0"

To shut the node down gracefully use: 

./jcli rest v0 shutdown get --host "http://127.0.0.1:3100/api"

Monitoring the node with a sentinel script

This may be just a problem on the testnet, but nodes seem to get stuck a lot and require a restart. This used to happen a lot with Masternodes as well, and the general solution was to run a "sentinel" script that checks on the node and perform the necessary processes when something's not right. In the case of Jormungandr a simple restart of the node seems to resolve the issue, so I made this sentinel.pl script that is to be run from the crontab every minute. It checks if no new block hash has been created for more than a certain time, and if not it restarts the node. If it's still stuck on the same block even after restarting, then the node has probably gotten itself onto a fork, so the sentinel backs up the chain data and logs and restarts the node from a clean slate.

The script takes two parameters, the first is the number of seconds to wait between polling the node (must be a multiple of 60), and the second is the number of seconds of seeing no new block hash after which we should assume that the node is stuck and restart it. Both parameters are optional and default to 5 and 120 respectively. The scipt should be located in the same directory as jcli and also expects a script called start.sh in the same directory that starts the node in the background with all the necessary parameters.

The script writes the situation to a file in the same directory called sentinel.log which will look like the following snippet. The first part in square brackets is the Unix timestamp of the entry followed by a duration after the slash. 

[1577145836/040] Epoch:10 Slot:8709 Block:34597 Hash:7c1db1bbb77d88636349371d5e7ef60e3cb8a2257e2d9aa8d109eecce3236689
[1577145891/055] Epoch:10 Slot:8735 Block:34598 Hash:fb84bb2a0e48233837d1d5773219b3be9661f333f3aaea41867372f0ed224197
[1577145916/025] Epoch:10 Slot:8746 Block:34599 Hash:c3da1a7f72815280f70e1956b33fda993ad788317515dbd2a5c74e96293b5c2b
[1577146041/125] Stuck on 10.8746, restarting node...
[1577146046/000] Status unknown, check if the node is running!
[1577146051/030] Bootstrapping
[1577146086/000] Epoch:10 Slot:8821 Block:34600 Hash:c93189408bcf7e9fe954e72502f720b661002fb365c3283b16b0a8260bd2cf4f
[1577146126/040] Epoch:10 Slot:8854 Block:34601 Hash:c3af8796c932f635067757b4cbaa1c58c6e7623d1660902172f0cf59b439d12e
[1577146136/010] Epoch:10 Slot:8858 Block:34602 Hash:b21af406419002e5b57b7e3bee7dec5378d10f76670d7780a642fbe1d2e60082
[1577146167/031] Epoch:10 Slot:8872 Block:34603 Hash:573c2b9142eff7435d2aa1cd657b808546c592c62e3710d0143670032ad0fecc

Note: The sentinel misses blocks that are generated quicker than the polling period, so the log shouldn't be used as a definitive chain report, for this application it's only the slow updates that we're concerned about, so missing blocks are not a problem.

Creating and funding a reward address

Now we need to create three files for our reward account, a public/private key-pair and it's corresponding ADA address which I did by following the instructions in how to register your stake pool on the chain. 

./jcli key generate --type ed25519 | tee owner.prv | ./jcli key to-public > owner.pub
./jcli address account --testing --prefix addr `cat owner.pub` > owner.addr

You can then send funds (minimum 510 ADA) to the account from Daedalus or Yoroi, and then check the balance: 

./jcli rest v0 account get YOUR_ADDR -h http://127.0.0.1:3100/api
counter: 0
delegation:
  pools: []
last_rewards:
  epoch: 0
  reward: 0
value: 550000000

Create the stake pool and publish to the blockchain

Finally we need to create the stake pool itself which can be done by calling the handy createStakePool.sh and send-certificate.sh scripts. You only need to run the former script which calls the latter, make sure both are executable first. The script takes four parameters, the listening port, the fixed tax (in lovelace), the percentage as a fraction and the private key of your reward address that you put in the owner.prv file above. For example: 

./createStakePool.sh 3100 1000000 5/100 OWNER_PRIV_KEY | tee results.txt

This will create a pool that takes 1 ADA (1M Lovelaces) fixed rate, and 5%. Note that the instructions say you need another tax_limit parameter, but this must have been removed at some point. This script returns two important values that you need to keep, the Pool ID and Pool Owner, but by appending the tee command, all the output is also captured in results.txt. It also creates the important node_secret.yaml file that is used when starting jormungandr from now on. Check the output for errors and successful signing and sending of the new pool registration transaction, you should see something like this in your output: 

## 10. Encode and send the transaction
56ded95ea6868470337272ef899264abb5c27dcdd2f9aae839924dca19b5dd3f
 ## 11. Remove the temporary files
 ## Waiting for new block to be created (timeout = 200 blocks = 400s)
New block was created - 8fe7ac108640778ca53ce4d38ed8b7b6092454770d4aaf04a38ec548cc66b330

Note: If anything goes wrong in this process, you're best creating a new pledge address before trying again, because if you end up with more than one pool operating on the same pledge address, only the last one will work.

IMPORTANT: As soon as you've created an address and node secret, create a directory for it using the stake id, or its first few characters, as the name and copy all the specific files into it so you have them in case you need them later. For example you need them if you want to retire the pool, or sign any messages as that pool owner, even if it's just a dummy run and you're sure you'll never need to refer to them again, do it anyway! The files are node_secret.yaml, stake_pool.id, owner.prv, owner.pub, owner.addr and results.txt.


Now you're ready to shut your node down and restart it with you secret key parameter to start it as a pool! 

./jcli rest v0 shutdown get --host "http://127.0.0.1:3100/api"
nohup ./jormungandr --config itn_rewards_v1-config.yaml --secret node_secret.yaml \
      --genesis-block-hash 8e4d2a343f3dcf9330ad9035b3e8d168e6728904262f2c434a4f8f934ec7b676 >> debug.log &

Note: Remember to add the --secret node_secret.yaml parameter to the command in your start.sh script.

Register the pool in the official registry

To allow people to delegate their stake to your pool in a supporting wallet, you need to add your pool to the public registry. This is done by creating a JSON file containing your pool's details, and a file signing the JSON content with the owner's private key, and committing these files to the registry's Github repo.

The name of the pool is your owner public key (which is in the owner.pub file) appended with a .json file extension. The content of the file is as follows. The "owner" field is the same key as used in the filename, and the "pledge_address" field is the owner address which is in your owner.addr" file. 

{
  "owner": "OWNER_PUBKEY",
  "name": "Pudim o gatinho com fome",
  "description": "All your stake are belong with PUDIM!",
  "ticker": "PUDIM",
  "homepage": "https://pudim.od.gy",
  "pledge_address": "OWNER_ADDR"
}

Note: This file must be valid JSON (e.g. you must use double quotes) otherwise the pull request will fail.


Then to sign this JSON file with the owner's private key, you use jcli as follows: 

./jcli key sign --secret-key owner.prv --output OWNER_PUBKEY.sig OWNER_PUBKEY.json


You then need to fork the Cardano foundation's incentivized-testnet-stakepool-registry Github repo, clone your new fork of it, add your two files into the registry directory, add, commit and push them and then create a pull request on the Github site in your forked repo page. Note that it's always best to create a new branch for a pull request, because all commits even after you've made the request are automatically included in the pull request at the upstream repo. Note that the following example is assuming that you've cloned the repo in your pool directory, if you haven't adjust the path to your keys as necessary. 

git clone git clone git@github.com:YOUR_GITHUB_USERNAME/incentivized-testnet-stakepool-registry.git
git checkout -b PUDIM
cd incentivized-testnet-stakepool-registry/registry
cp ../../OWNER_PUBKEY.* ./
git add *
git commit -m "PUDIM"
git push --set-upstream origin PUDIM

The pull request will verify your that your JSON is valid and your signature verifies, and if so the team should approve it for inclusion in the registry shortly after, and your stake pool will be listed in the delegation interface of Daedalus!

The image below shows two pull requests to the official registry repo, our PUDIM registration has passed, meaning that the JSON syntax is all correct and the signature has been successfully verified, but the MORON pool registration has not been successful. Even after a successful pull request, manual validation is required by the Cardano team, ours was accepted the next day.

Pudim-pool.jpg
Pudim-pool-accepted.jpg

Note: If you want to remove your pool from the register or change it's details, see these details which involve creating two pull requests, one for a signed "voiding" of the old metadata file, and another to add the new metadata and signature files.

Congratulations PUDIM! She produced her first block in the early morning of December 27th 2019 🎉 🎉 🎉 All blocks produced by PUDIM can be seen in here.

Staking resources

Cardano address types

Todo... There are four types of addresses in Cardano:

Base addresses:

Pointer addresses:

Reward addresses:

Enterprise addresses:

Wallets supporting ADA

Daedalus issues

On the Incentivised Testnet version of Daedalus, some problems sometimes occur such as not being able to connect for a very long time, the stake pools disappearing and staked balance mysteriously moving back to the old balance wallet with no transactions having occurred. The latter two issues can be resolved by stopping the wallet, nuking all data, restarting it and restoring your rewards wallet. On Linux the chain and wallet data is stored in ~/.local/share/Daedalus, in mainnet or itn_rewards_v1.

Token distribution

In a PoS protocol, staking coins is necessary to participate in the consensus mechanism. Since the existence of coins is required to execute the protocol, a certain initial coin distribution was required. At the time (2015), the concept of Initial Coin Offerings (ICO’s) was becoming popular, but there were concerns that holding an ICO by minting virtual assets and selling them to the general public might fall under security regulations. IOHK, Emurgo and the Cardano Foundation therefore chose to sell 25,927,070,538 ADA ‘vouchers’ in a private sale in Japan and a few other Asian countries that were redeemable for ADA after the main-net was launched in September 2017.

Particularly Bitcoin purists, that believe only Bitcoin had a fair launch, tend to react adversely to the idea of a new form of money being created and sold. At Bitcoins’ launch, Satoshi Nakamoto first shared the code to run a Bitcoin node publicly, allowing anyone to participate in network consensus from the start. While Nakamoto clearly had an advantage since just a few people knew of Bitcoin’s existence, the fact that anyone could have participated and that it was all but a given that Bitcoin would be a success arguably made it fair. However, the recent launch of the Grin privacy coin illustrates that a similar ‘fair launch’ is perhaps no longer possible, as ~$100 million in venture capital money was rumoured to be invested in mining Grin. In essence, the choice for Cardano’s private sale was a trade-off between geographical distribution and regulatory certainty, where the latter was chosen as a priority.

In total, 25,927,070,538 ADA were sold for $63 million (= $0.0024 per ADA) to over 10.000 people during voucher sale that was held between September 2015 and January 2017. According to the distribution audit that was held on behalf of the Cardano Foundation, 94.45% of the ADA was sold to Japanese citizens, 2.56% to Koreans, 2.39% to Chinese and the remaining 0.61% to citizens of 5 other Asian countries.

The other 5,185,414,108 ADA (20% of the amount of ADA sold during the voucher sale and 16.7% of ADA’s 31,112,484,646 ADA total supply), were distributed over IOHK, Emurgo and the Cardano Foundation. IOHK has publicly shared its ADA address and that one third of the 2,463,071,701 ADA they received (of which ~97.5% is still there) is available immediately, one third is made available on June 1st, 2018 and the final third on June 1st, 2019. While the Cardano Foundation and Emurgo haven’t publicly shared their ADA address, it is believed that Emurgo originally held 2,074,165,643 ADA in this address and the Cardano Foundation originally held 648,176,763 ADA in this address, as the sum of these amounts adds up exactly to the original total. Finally, the remaining 13,887,515,354 ADA of the 45 billion ADA that will ever exist (maximum supply) will be minted as block rewards.

As of December 2019, there are four ADA billionaires, thirteen addresses hold over 100M ADA, 157 addresses hold over 10M, and there are about 3000 ADA millionaires. There are about 290K addresses in all with just over a third holding under 1K ADA, just over a third holding 1-10K and about 20% holding 10-100K, 7.5% with 100K-1M and 1% are the millionaires.

Official sites

See also

Retrieved from "https://organicdesign.nz/wiki/index.php?title=Cardano&oldid=127182"