Whitepaper

SwiftCash - Decentralized Governance & Economy

Introduction

SwiftCash is the SplitFork of SmartCash as of block 633,000 - appx. 1st of September 2018 09:53:00 GMT. Driven by strong divisions between the community and the core team(SmartHives), about 80% of the total supply which was believed to be mostly controlled or owned by the core team(SmartHives), exchanges, hackers or exploiters, was burned which then turned into a unique experience with an amazing initial decentralization of power, supply ownership, as well as inflation. SwiftCash is an open-source, decentralized, peer-to-peer transactional cryptocurrency which also offers a solution to the problem posed by the exponential increase in energy consumed by Bitcoin, and other Proof-of-Work cryptocurrencies. Proof-of-Work mining is environmentally unsustainable due to the electricity used by high-powered mining hardware and anyone with 51% hash power can control the network and double spend. SwiftCash utilizes the Green Protocol, an energy efficient Proof-of-Stake algorithm inspired by Bitcoin Green, can be mined on any computer, and will never require specialized mining equipment. The Green Protocol offers a simple solution to Bitcoin sustainability issues and provides a faster, more scalable blockchain that is better suited for daily transactional use.

Mining - PoW vs. PoS

One common solution to 51% attacks on Proof-of-Work networks is to centralize mining which is a method adopted also by SmartCash after the chain was hacked over three times. In this method, miners are required to sign the blocks with a private key that is issued by central authorities, such as the developers. This is the main reason why we could not hard fork the main chain, apart from the fact that the core team controlled the majority of the total supply as well as the budgets. With SwiftCash however, mining will be based on the Proof-of-Stake algorithm, and therefore fully decentralized. Anyone with a stake in the blockchain can try mining new blocks, and a 51% attack is going to require the attacker to buy or own 51% of the total stake, which is being used to mine new blocks. Therefore, the more stakeholders participate in mining, the more secure the network becomes, as the cost of an attack increases. With Proof-of-Work mining however, the attackers can invest in a strong mining infrastructure once, and use it to attack as many PoW blockchains as they want, whereas with PoS mining, the attackers will have to invest in each blockchain individually, and each time they attack a blockchain, they also attack their own investment! Another thing that makes PoS mining a better solution is saving on energy and being friendly to the environment. To give an example of how extraordinary the difference is, it might be noteworthy to point out that bitcoin mining for example consumes more electricity a year than the whole country of Ireland! This is while PoS mining does not depend on hash power and therefore, only uses as much electricity as any average computer or phone does. Technical Specifications

Block Time: 1 minute

Difficulty Adjustment Timespan: 40 blocks

Difficulty Adjustment Interval: 1 block

Algorithm: Keccak

Max Supply: 5,000,000,000

Theoretical Block Rewards: floor(0.5 + 4000 * 525600) / (8*525600 + nHeight - 10000 + 1)

Distribution: SwiftNodes: 20%, PoS Miners; 10%, SwiftRewards: 10%, Budget: 60%

Proposal Fee: 100 SWIFT

Budget Fee: 10 SWIFT

Forkdrops

The following rules were used to burn almost half of the circulating supply, and more than 80% of the total supply of SmartCash, as of block 633,000. Some of these rules have overlaps and therefore, the total amount that was burned is less than the sum of the following amounts. Rule number one is a no-brainer, and with this rule, no exceptions were made. Plus the snapshot date was chosen on a date that no one knew about this fork, including those who decided to fork away later in September. The majority of the addresses in rule number two were either known exchanges or linked to hives, which is why the 500K cap seemed like a good option to filter the few others which may also be indirectly linked to whales, exchanges and hives - one exception prior to launch was made to this rule after a community member contacted us during the dispute period. Rule number three, once again had a lot of overlaps with other rules, which is why 2M seemed like a good cap to choose, in order to filter the few others which may also be indirectly linked to exchanges and hives. Rule number four was meant to target exchanges, and also the SmartNode exploiter(s). 200 transactions in one address was highly uncommon and most addresses had a maximum of 80 transactions, including SmartNodes that had been running from the very start. Rule number five seemed like a good cap for abandoned change addresses. Rule number six was mostly applicable to Cryptopia and HitBTC’s known addresses which again had significant overlaps with the other rules. Rule number seven was decided by the majority of the community involved with the fork, as it was believed that Ben’s proposal was mostly voted yes by the core team(SmartHives) rather than the community. It might be noteworthy that rule number seven also had about 11M overlap with the other rules. Some exceptions with this rule were made after a few community members reached out to us during the dispute period. Rule number eight would again be a no-brainer, as those few addresses were controlled by SmartHive coordinators.

1. Any address directly paid from any hive - appx 220M coins

2. Any address with a balance greater than 500K - appx 120M coins

3. Any address with total received greater than 2M - appx 240M coins

4. Any address with more than 200 transactions - appx 23M coins

5. Any address with a balance less than 1 smartcash - appx 2500 coins

6. Known exchanges and pools - appx 22M coins

7. Any address that has voted yes to Ben Swann’s proposal - appx 16M coins

8. All the hives and community budget - appx 1.2B coins

Objections

After finalizing the list, an announcement was made on steemit about how users can still settle any dispute they wish with the community after launch via proposals and the new onchain governance. It is obvious and undeniable that these rules have not affected the majority of the community, and any accusation about the rules or the date of snapshot favoring those in charge of the snapshot and forkdrops falls extremely short, after looking into Ben Swann’s proposal. A proposal that the organizers and supporters of this fork were radically against only had about 9M no votes. More than 2M of those votes are also blacklisted due to some of the rules mentioned above, most of which are directly linked to the core team(SmartHives), yet no exceptions were made for those either, and if assuming the remaining of appx. 7M coins are somehow intentionally whitelisted with such a design, which is highly unlikely to even be true, it would still be nothing compared to approximately 300M initial supply via the forkdrops, which further establishes the initial claim that the new chain is radically decentralized in terms of ownership of the circulating supply.

Onchain Governance

Manual handling of the treasuries by SmartCash founders might be one of the main reasons why things went so wrong. The main excuse for not adopting onchain governance was to allow every coin to have a voice over proposals. This was to combat onchain voting with MasterNodes in blockchains like Dash, where a MasterNode would cost over 200K USD. With SwiftCash however, collaterals for SwiftNodes will require 20K SWIFT, and owning a SwiftNode would be extremely cheap compared to coins like Dash and PIVX. The 20K collateral was chosen by the community who was involved in this fork, and is of course like most things open to change in the future. Our vision of onchain governance is that proposals can even be submitted to hard fork the main chain, and if enough stakeholders vote yes, who should stand in their way? After all, the blockchain belongs to the stakeholders. This was supposed to be the vision of SmartCash as well, which has taken a completely different path. To make sure that does not happen with SwiftCash, we decided that there should be no core team, teams or hives but rather individual contractors selected by the community via onchain voting and governance. There is no hard-coded address that is going to continually get paid no matter what. Each payment will need to be approved by the community through proposals and onchain voting and governance. That includes the developers, admins and anyone else involved in the community. Everyone has to go through the same process to get paid anything from the budget. Stakeholders will have the final say at the end of the day and will hire and fire people as pleased. The only exception to this design is made for the initial development costs where a contractor has accepted to give us a custom codebase for 1M coins in the new chain, as without the core wallet, there is no way to have a chain to begin with, let alone onchain voting and governance. Everyone else, including those who have been contributing to the project before launch will need to submit a proposal to get reimbursed for their time and any costs, should the community vote yes. Having said that, a maximum of 70% of our theoretical block rewards are set aside for budgeting, out of which 10% are set aside for SwiftRewards. If the total budget is used every month, maximum supply will reach in about 70 years. However, given our experience with SmartCash, this is an extremely unlikely scenario. The more likely scenario will be that about 30-40% of the block rewards will not be used which means that it will take us much longer to run out of block rewards, and rely on fees and donations only.

Proposals & Budgets

The cost for submitting a proposal is 100 SWIFT and once a proposal passes, 10 SWIFT will be required to finalize the budget in the blockchain, so that it can get paid in the next super block. Superblocks are a few blocks, in which proposals that have passed get paid, and this happens every 43800 block or appx. every month. Proposals need to be on chain for at least 10 days before they can be finalized and get paid. Each proposal can only ask for a maximum of 20% of the available monthly budget. In case there are more winning proposals than the maximum available budget, proposals with more votes will be finalized and get paid. Each proposal will need a minimum of 10% of the network in yes votes minus no votes, in order to pass. That means if there are 10,000 SwiftNodes, a proposal will need at least 1000 yes votes minus no votes, such as 1500 yes votes vs. 500 no votes in case of a 20% participation rate. Therefore, the lower the participation rate, the more the required passing point. This means that in case of 100% participation, required passing point will be 55%, whereas in case of 10% participation rate, which is the minimum participation rate required for any proposal to pass, required passing point will be 100%. Another rule for participation rate is that each proposal will need to be within 10% of the maximum participation rate in order to pass. That is if the maximum participation rate at any given time is 50%, any proposal with less than 40% participation rate will not pass. Due to the nature of continuously diminishing block rewards and its effect on the markets, only a maximum of 3 payments per proposal can be asked for. Longer-term proposals will need to re-submit their proposal every 3 months. Last but not least, a minimum of 100 votes is required for any proposal to pass, and votes can be updated one hour after each submission, and that includes votes on proposals that have already passed and got paid once or more. Furthermore, a URL must be attached while submitting a proposal, which should include the details of the proposal. The recommended platform for the details of proposals and also any pre-proposal is the STEEM blockchain which is not only independent from SwiftCash, but also decentralized and resistant towards censorship. Recommended hashtags for SwiftCash proposals and pre-proposals are #swiftproposal and #swiftpreproposal respectively.

SwiftRewards

The idea behind SwiftRewards will be a way to not only help stabilize the price, but to also reward long term holders, in case price depreciates. The more price depreciates, the more rewards would holders receive. If however price does not depreciate, there would be no airdrops on holders. Minimum required balance to be eligible for SwiftRewards will be 1000 SWIFT, and any outgoing transaction from an address during any snapshot will disqualify that address, unless it’s a PoS transaction where more amount is returned to the address in the same transaction. Given the initial design, there will be 4 tiers for SwiftRewards:

1. Tier 1: Every 43,800 block - appx. 1 month

2. Tier 2: Every 131,400 block - appx. 3 months

3. Tier 3: Every 262,800 block - appx. 6 months

4. Tier 4: Every 525,600 block - appx. 12 months

Given the initial design, there would be one possible airdrop each month, two possible airdrops every three months, three possible airdrops every six months and four possible airdrops every twelve months. As mentioned above, those who hold longer would be rewarded more if price depreciates and the more price depreciates, the more rewards will be dropped on holders! This method would help stabilize the price by encouraging stakeholders to hold in bear markets and to sell in bull markets. SwiftRewards will initially be done manually by developers and the required funds will need approval from the community via a proposal. But the process will be later coded into the blockchain, and will be done automatically with the help of SwiftNodes. SwiftRewards will be a maximum of 4%, 3%, 2% and 1% of block rewards for tier 1, 2, 3 and 4 respectively - i.e. a maximum total of 10% of the block rewards. For tier 1, each 5% drop in the average price from the start of the snapshot to the end, results in 0.4% of block rewards being dropped on holders. First snapshot for each tier begins one snapshot late to make things fair to the future adopters. That means, first snapshot for tier 1 will start at block 43,800 while the first snapshot for tier 4 will start at block 525,600. To give an example, if the average price is recorded as 0.10 USD at block 43,800 and then becomes 0.075 USD by block 87,600, holders will receive 2% of the block rewards during that period. That is 5 times 0.4% due to 25% drop in the average price. Price drops of more than 50% will not affect the amount of airdrop, since maximum amount of available coins to airdrop will be reached.

Block Rewards & Inflation

As explained above, SwiftCash launches with appx. 300M coins dropped on most SmartCash holders. Block rewards are set to be only 10 SWIFT per block up to block 10,000. This is to make the launch fair and give the community about one week to set up their wallets for mining and/or servers for SwiftNodes. From block 10,000 rewards will start with 500 coins per block theoretically, but only 30% of this amount will be mined every block which will be split between SwiftNodoes and PoS miners with a ratio of 2 to 1. The rest of the theoretical block rewards are set aside for budgeting, and will only be mined on demand via proposals, should enough stakeholders or SwiftNode owners to be specific, vote yes. Block rewards are set to fall gradually to zero and the gradual curve is very slow and becomes even slower as time goes by. It will take 8 years for block rewards to halve; second halving will take 16 years, third halving will take 32 years, and so on and on. This gives us a maximum inflation of appx. 80% in the first year, 40% the second year and so on and on. Maximum inflation however is most likely not going to occur due to unused treasuries which can then turn into future reserves, and so this way, it will take us longer to run out of block rewards and solely depend on fees and donations. If maximum inflation is reached every month, blockchain will run out of block rewards within appx. 70 years and by then, the maximum supply of 5,000,000,000 coins will be reached. However, our experience with SmartCash shows that about 40-50% of the treasuries will remain unused which in our case will turn into future reserves; that means it can take us about 200+ years to run out of block rewards. Furthermore, as an example, bitcoin has mined over 80% of its maximum supply in less than 12 years, and SmartCash has mined about 40% of its maximum supply within 18 months, while if we consistently use the whole budget, which is very unlikely as explained above, will have mined less than 40% of the maximum supply within 12 years! That is great news for future adopters and we do this because we have a long-term goal; what we want is a decentralized cryptocurrency to benefit everyone in the world, not another pump and dump ponzi scheme. Having said that, the following chart depicts the inflation of SwiftCash within the first 12 years, with the assumption that 30% of the block rewards will turn into future reserves due to unused treasuries. As depicted below, yearly inflation in this case would start with about 55%, and would then reach 4% in 12 years.

In order to get an insight into how slow block rewards will reduce, we can have a look at the following chart which depicts the block rewards for SwiftNodes within the first 12 years. As it can be seen, SwiftNodes will initially get about 100 SWIFT per block, and by the end of the 12th year, they will be getting about 40 SWIFT per block. The slow curve is designed by intention to not only stabilize the price as we grow, but to also decentralize the distribution of block rewards by making inflation fairer to future adopters compared to most, if not all cryptocurrencies out there. SwiftNodes will be used for instant locks via swift transactions - also called SwiftTX or InstantPay - which will allow users who use this option to rely on these transactions before they are even mined yet. SwiftNodes will also secure the treasuries, help the community reach consensus via onchain voting, and help mine budgets on demand via onchain governance. Each SwiftNode will be secured with a 20,000 SWIFT collateral, and a unique IPv4 address that will be required to run a full node on port 8544.

Copyright © SwiftCash Developers

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.