{"id":28560447,"url":"https://github.com/hclivess/nado","last_synced_at":"2025-06-10T09:08:35.163Z","repository":{"id":50698550,"uuid":"519884702","full_name":"hclivess/nado","owner":"hclivess","description":"Standalone blockchain project built from scratch. Rewards for having an IP address. Proof-of-Work fairness. Proof-of-Stake efficiency. This project is not affiliated with any tokens.","archived":false,"fork":false,"pushed_at":"2024-12-06T22:03:45.000Z","size":1232,"stargazers_count":17,"open_issues_count":7,"forks_count":9,"subscribers_count":4,"default_branch":"main","last_synced_at":"2024-12-06T23:18:47.992Z","etag":null,"topics":["bismuth","bitcoin","blockchain","consensus","crypto","cryptocurrency","ethereum","mining","minting","new","nft","p2p","staking"],"latest_commit_sha":null,"homepage":"https://nodeisok.com","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/hclivess.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-07-31T20:52:05.000Z","updated_at":"2024-12-06T22:03:49.000Z","dependencies_parsed_at":"2023-02-11T22:15:48.947Z","dependency_job_id":"2a906cb3-26d6-4997-abe9-b527da05be93","html_url":"https://github.com/hclivess/nado","commit_stats":null,"previous_names":[],"tags_count":24,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hclivess%2Fnado","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hclivess%2Fnado/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hclivess%2Fnado/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hclivess%2Fnado/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/hclivess","download_url":"https://codeload.github.com/hclivess/nado/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/hclivess%2Fnado/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":259043784,"owners_count":22797164,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["bismuth","bitcoin","blockchain","consensus","crypto","cryptocurrency","ethereum","mining","minting","new","nft","p2p","staking"],"created_at":"2025-06-10T09:08:34.279Z","updated_at":"2025-06-10T09:08:35.143Z","avatar_url":"https://github.com/hclivess.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://nodeisok.com\"\u003e\u003cimg src=\"https://nodeisok.com/media/bauhaus.png\" /\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n    \u003ca href=\"https://discord.gg/6aEBWTvcTV\"\u003e\u003cimg src=\"https://nodeisok.com/media/discord.png\" /\u003e\u003c/a\u003e\n    \u0026emsp;\n    \u003ca href=\"https://twitter.com/nodeisok\"\u003e\u003cimg src=\"https://nodeisok.com/media/twitter.png\" /\u003e\u003c/a\u003e\n\n\u003c/p\u003e\n\n## Installation\n### Ubuntu\n#### Before you start\nPlease close your node using [/terminate](http://127.0.0.1/terminate) or **CTRL+C** before shutting down your machine.\nYou can also use `wget --delete-after localhost:9173/terminate --timeout 1 -t 1` from anywhere in your environment to force shutdown.\n\n### Virtual environment installation\n\nMake sure to set your open file limit high enough:\n\n```\nnano /etc/security/limits.conf\nroot soft nofile 65535\nroot hard nofile 65535\n```\n\nAppend:\n\n```fs.file-max = 100000```\n\nThen apply the settings and restart the machine.\n\n```\nsysctl -p\nsudo reboot\n```\n\nYou may now proceed with installation:\n\n```\nsysctl -w fs.file-max=65535\nulimit -n 1000000\nscreen -S nado\nsudo apt-get update\nsudo apt-get install software-properties-common\nsudo add-apt-repository ppa:deadsnakes/ppa\napt-get install python3.10-dev python3.10-venv\npython3.10 -m venv nado_venv\nsource nado_venv/bin/activate\npip install --upgrade pip\ngit clone https://github.com/hclivess/nado\ncd nado\npip install -r requirements.txt\n```\n\nTo go back to your screen, use `screen -r nado` \nTo update your NADO installation, use \n\n```\ngit reset --hard origin/main\ngit pull origin main\n```\n\nfrom the directory where you have it installed.\n\n### Windows\n#### Before you start\nWhen running in window console, please close your node using [/terminate](http://127.0.0.1/terminate) or **CTRL+C**.\nNever use the **X** in the upper right corner to avoid possible database corruption.\n\nThere is a [release page in GitHub](https://github.com/hclivess/nado/releases), which is periodically updated when major changes occur. \nThe easiest way to run NADO for Windows users is to use the `nado.exe` binary from there.\n\nIt is also possible to install [Python on Windows](https://www.python.org/downloads/) and run NADO directly. Command line instructions:\n\n#### Direct installation\nFirst [download](https://github.com/hclivess/nado/archive/refs/heads/main.zip) the master branch from GitHub and extract the archive.\nRun the command line as Administrator and enter the following commands:\n```\npython -m pip install -r requirements.txt\n```\n\n# To run NADO, execute the following command: `python3.10 nado.py`\n\nAfter installation, go to your browser and announce your peer to one of the nodes like this:\nhttp://127.0.0.1:9173/announce_peer?ip=207.180.203.132. For this,\nyou should have [port 9173 open](https://www.google.com/search?q=port+forwarding+guide) so the node is accessible from the internet if you want to receive rewards. After this step, synchronization should start shortly. \n\n## GUI Wallet\nYou can download the [official NADO wallet here](https://github.com/hclivess/nado-microwallet) or on the [release page of NADO](https://github.com/hclivess/nado/releases).\n\n## CLI Wallet\nYou can use the CLI wallet by running `python3.10 linewallet.py`\nThis wallet takes arguments, which enable you to access more wallets from one place and also automate your routines.\nAll arguments can be displayed with `python3.10 linewallet.py --help`, here are some examples:\n```\n--sk, \u003cprivate key\u003e Use private key, ignore default key location\n--amount, \u003cnumber\u003e Amount to send\n--recipient, \u003cNADO address\u003e Recipient address\n--fee, \u003cnumber\u003e Fee to spend\n--target, \u003cnumber\u003e Target block number\n--auto, \u003cany\u003e Uses suggested fee and target block instead of asking, use any value (1)\n--peers \u003c'130.61.131.16','207.180.203.132'\u003e Broadcasts transaction only to the supplied list of peers\n```\n## Remote access\n\nAfter running the node, you can access it at http://127.0.0.1:9173 from where all API calls used by the node itself are accessible. Here are some examples:\n- Raw: http://127.0.0.1:9173/get_account?address=ndo5ccd6e3aaaf4764161a29ef13d4bbda832e2cf4a94016c\n- User-friendly using the `readable=true` argument: http://127.0.0.1:9173/get_account?readable=true\u0026address=ndo5ccd6e3aaaf4764161a29ef13d4bbda832e2cf4a94016c\n\n## Private key storage \n- Linux: `/~/nado/private/keys.dat`\n\nTo view your file, you can use the following command: `cat ~/nado/private/keys.dat`. You may need to exit screen first using `CTRL+a` and then `CTRL+d`.\n\n- Windows: `C:\\Users\\[username]\\nado\\private`\n\n## Is there anything unique?\n\nYes. No mining or minting. All communication happens using a public API. Block production happens in every node at once, based on the deterministic principles of the\nparticipant addresses mixed with the blockchain state. This is possible because block production is separated from the consensual layer. It removes all the selfish\nminer incentives, which cause issues like transaction exclusion in traditional PoW systems.\n\n## What is NADO?\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"https://nodeisok.com/media/overview.png\" /\u003e\n\u003c/p\u003e\n\nNADO is short for Tornado. It is just another blockchain written from scratch with a highly experimental consensus algorithm, \nwhich was created to provide effortless block production for all participants with a public IP address. NADO is not a classic proof-of-work\nblockchain like Bitcoin. Unlike most other crypto, its focus is on accessibility to rewards for everyone. It has a fully\nelastic reward mechanism, rewarding users only when transactions are happening on the chain. Users can burn their share\nof tokens in order to increase their chances of winning more rewards in the future.\n\n## What's the reason for NADO?\n\nNADO is a take on one of the newer trends, where users do not use graphics cards or specialized hardware for mining, nor\ndo they have to own a large portion of tokens in order to be rewarded. It is inspired by IDENA and NYZO, while\nattempting to bring the barrier of entry even lower than those two by not requiring solving of puzzles or highly\nefficient machines for users to remain in a reward distribution cycle.\n\n## Emergency measures\n\nWhen the network consensus drops too low, you can take the following measures to help improve it. This trades\nsecurity for quicker and less ambiguous synchronization.\n\n`wget --delete-after http://127.0.0.1:9173/force_sync_ip?ip=207.180.203.132` forces synchronization\nfrom a particular target IP, in this case 207.180.203.132. This feature turns off automatically once the network\nconsensus rises above 80%. For Windows and UI-based environments, simply access http://127.0.0.1:9173/force_sync_ip?ip=207.180.203.132\n\nYou can enable promiscuity mode, which ignores peer trust when synchronizing. This will default the synchronization\nto a typical 51% scenario, which is less experimental. To set it up, go to your config file and add `\"promiscuous\": true`.\nRestart your node to put it into effect.\n\nIt is also possible to decrease the synchronization cascading level to a given value, like 1. You can do that by\nadding the following to your configuration file and restarting your node: `\"cascade_limit\": 1`. This setting will only\nhave effect when running in non-promiscuous mode. Value represents depth of hash pools to iterate through, choosing\nbased on trust. For example, there can be 50 nodes in state A, but there is no node with sufficient trust there,\nso the node goes into the second most popular hash pool, let's say 30 nodes in state B and sync from those. \n\n### Resyncing\nShould you choose to wipe out your database and resync the chain from scratch, you can use the bundled script: `python3.10 purge.py`\n\n## What does NADO do differently?\n\nIn NADO, every user generates new blocks at the same time. This is possible because users are not rewarded for producing\nblocks but for keeping the network running. After generating a block and receiving a reward, chances of receiving more\nblock rewards are temporarily lowered based on the public IP address. Every IP address can only have one block\ngenerating node. While this excludes users without public addresses, it prevents node spamming to a degree.\n\n## Sounds interesting, can you elaborate?\n\nThere are multiple cycles for every block. It starts with accepting peers and transactions directly. In the second\nstage, transactions and peers are stored in a buffer for the following block so that transactions can stabilize across\nthe network. NADO prefers decentralization to efficiency, which means it exposes consensus more than the individual\nnode, which makes it more resilient regarding SPOF but less efficient.\n\n## But is there a premise?\n\nThe premise of NADO is that users stop being interested in decentralized value distributing projects because it becomes\nprogressively more difficult for them to join them or remain as time goes on.\nThe main reason for users to leave is not the lack of adoption, but the mismatch between adoption, \ndistribution and inflation. Distribution is the single one most important aspect of a cryptocurrency project as proven \nin the success of NANO, where no single entity was capable of obtaining a high amount of tokens through monopolizing \ntoken distribution. \n\n- Constant rewards are counterproductive: Users will keep running their nodes even though they are not receiving rewards\nin a particular moment because there is no block reward for a particular block because network activity is low. Fighting\ninflation is more important than hoping for users to not stop running nodes.\n\n- Elastic distribution was one of the key promises of Vertcoin, one of the most popular cryptocurrencies \nof 2014. NADO puts these promises into practice. \n\n- Litecoin was created as a Bitcoin with fair distribution. None of the projects mentioned above put large \neffort into marketing and were extremely popular nonetheless.\n\n- Barrier of entry is directly correlated to fairness of distribution. This is an idea on which Steve Jobs built his\nentire business. Removal of hassles in Apple operating systems and simplicity of their mobile devices led to widespread \nadoption simply because there were no hurdles to adoption.\n\n- Interestingly enough, some of the most successful \"cryptocurrency projects\" where pyramid schemes that had zero technology\nin them: Bitcoinnect and Onecoin. All users had to do there was to go on a website and click a button to invest\nmoney into something that did not exist. Why did they do it? Because it was easy.\n\n- Combining great and accessible technology with perfect distribution and effective marketing is the key to successful adoption. \n\n## Why not only use the existing projects?\n\n- With PoW, the problem is in the arms race.\n- With PoS, the problem is in the rising price.\n- With PoD, the problem is in the increasing difficulty to re-join mesh with more participants.\n\n## Proof of what?\nEvery node in the NADO ecosystem keeps track of what opinions other nodes have by sharing state checksums for current\nblock producer pools, transaction pools, and block hash pools. Participants add credibility over time to\nthose who share their opinions on what the state of the network is. The security principle is that any\nattacker needs to be connected to the network for a longer time than the legitimate nodes and postpone the attack until\ntheir network participation duration is longer than that of other nodes - to perform a 51% attack. If the legitimate nodes\nstay in the network longer than the attackers, it is impossible to attack.\n\nFor rewards, NADO uses a variant of PoW with a very limited input set unlike in normal PoW crypto, where it is unlimited.\nWhen producing blocks, addresses of all block producers are hashed with the block candidate. This results in a new hash,\nwhich is then compared with the block candidate. The address which has the least matching wins. Penalties from absence\nof burning have to be taken into consideration.\n\n## Ideal way to receive rewards (optimal mining)\nUser chance to be rewarded for a block is random and depends on their address. This is because of how NADO is designed,\nIPs are important only for users to join the network, while addresses are critical. Reason for this is that IP address\nmanagement is out of reach for most users, so IP-centered system would lead to problems. Meanwhile, addresses are entirely\nin user control. You could mine to one address on more nodes than one, but that would effectively decrease your chance\nof receiving rewards. One address per node is recommended.\n\n## Burn-to-Bribe system and governance\nIn the beginning, all users have the same chance at receiving a reward every block. If they succeed, they are issued\nboth tokens and a penalty. This penalty lowers chance of further finding rewards in relation to users who have not been \nrewarded yet, but it can be negated by burning a portion of the coins they generated or obtained otherwise. \n\nThe model is set up in 1:100 ratio, which means that 1 portion of burn negates 100 portions of penalty. Both penalty and burn \nare counted from the smallest unit of NADO, so the lowest penalty resolution is 0.0000000001 and the lowest burn/bribe \nresolution is 0.0000000100.\n\nTo prevent monopolization of reward distribution, the burn bonus is in effect only to the level of default value for the\naccount, which means that any account can at best have a bonus of an entirely fresh address.\n\nThis system was created as an additional measure against inflation \nafter implementation of elastic distribution and burned tokens are used for governance purposes.\n\nTo burn your NADO, send it to the following address: `burn`\n\n\n## What about security?\n\nThere are no guarantees for security of NADO, mainly because of its highly experimental character. Compared to more\nexcluding networks like Bitcoin, security will always be lower as the main focus is on lowering the entry level for new\nusers to make block production and rewards as inclusive as possible.\n\n## How many decimals are there and what are the units called?\n\n1 NADO can be split into 1,000,000,000 units (0.0000000001).\n\n## Got some sci-fi tech mumbo jumbo?\n- Cryptography: Edwards-curve Digital Signature Algorithm (Ed25519)\n- Link hashing: BLAKE2b\n- Block capacity: Capped at 150KB per minute\n- Block reward: Between 0 and 0.5 depending on network usage\n- Transaction throughput: 7 raw transactions per second\n- Proof of Fidelity with aspects of majority and diversity\n- noSQL MessagePack file-based atomized database system\n- Optional MessagePack formatting in API\n- Shared block production and reward protocol\n- Periodic intervals to enforce consensus stabilization\n- Burn-to-Bribe deflationary incentive and governance\n- The logo is a vortexed version of the Impossible Toroidal Polyhedron\n\n# Related Repositories\n\n#### NADO .NET SDK\nhttps://github.com/blocksentinel/nado-dotnet-sdk\n\n#### NADO Media Kit\nhttps://github.com/hclivess/nado-media-kit\n\n#### NADO Web Repository\nhttps://github.com/hclivess/nado-web\n\n#### NADO MicroWallet\nhttps://github.com/hclivess/nado-microwallet\n\n#### Where can I learn more?\n\nhttps://nodeisok.com\n\n# For developers\n### Design philosophy\n\nWhen implementing new functionalities to NADO, existing routines/loops should be used instead of instant invocation of functions.\nEvery function should have its place in the particular routine, which is responsible for it. If such routine does not exist, create it.\n\nStandard development rules apply. Functions should be as small and as independent as possible, responsible for small tasks\nafter which they are named. Assignment of returns is preferred to object fungibility passed as arguments.\n\nSynchronous loops are not allowed for multiple targets, always use the existing compounder. If you require a specific new\ncompounder function, feel free to add it.\n\n### How to contribute\n\nTo contribute, you first have to fork this repository here on GitHub. After that, you make changes to your fork.\nWhen you are done, you can ask for a merge request to have your changes to the code accepted to the repository.\n\n### How NADO is structured\n\n#### Level III\nThe main module is `nado.py`, which runs all loops and governs API endpoints. \n\n#### Level II\nThere is a central memory element named memserver in `memserver.py`. Values are stored in its variables and accessed\nmostly by the main loops: `consensus_loop.py`, `core_loop.py`, `message_loop.py` and `peer_loop.py`. Apart from memserver,\nvariables related to pools are stored in `consensus_loop.py`\n\n#### Level I\nFiles that end in\n`_ops.py` like `block_ops.py`, `data_ops.py`, `account_ops.py`, `transaction_ops.py` and `peer_ops.py` handle low level \noperations and are populated with functions, which should be minimalistic both in length and complexity.\n\n### Parts of NADO\n\n#### Block production\nThere are several phases in which blocks are created. First a block is constructed from data using `construct_block()`. \nThen this structure is submitted for block production in `produce_block()`, which consists of `verify_block()` with \n`rebuild_block()` for restructuring hashes of remotely received blocks and the final `incorporate_block()`.\n\n#### Transaction pool flow\nTransaction, aka mempool, is divided into three levels.\n- `user_tx_buffer`: Where users directly submit transactions from wallets\n- `tx_buffer`: Where user buffer and transaction pools of other nodes are moved into\n- `transaction_pool`: The pool which will be incorporated into the block, transaction buffer\nis merged into it before block production. Transaction pools of other nodes are also merged into it.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhclivess%2Fnado","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fhclivess%2Fnado","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fhclivess%2Fnado/lists"}