5.8 Slashing Slashing occurs when a validator votes two separate sequences. A proof of malicious vote will remove the bonded coins from circulation and add them to the mining pool. A vote that includes a previous vote on a contending sequence is not eligible as proof of malicious voting. Instead of slashing the bonds, this vote removes remove the currently cast vote on the contending sequence. Slashing also occurs if a vote is cast for an invalid hash generated by the PoH generator. The generator is expected to randomly generate an invalid state, which would trigger a fallback to Secondary.

5.9 Secondary Elections Secondary and lower ranked Proof of History generators can be proposed and approved. A proposal is cast on the primary generators sequence. The proposal contains a timeout, if the motion is approved by a super majority of the vote before the timeout, the Secondary is considered elected, and will take over duties as scheduled. Primary can do a soft handover to Secondary by inserting a message into the generated sequence indicating that a handover will occur, or inserting an invalid state and forcing the network to fallback to Secondary. If a Secondary is elected, and the primary fails, the Secondary will be considered as the rst fallback during an election. 17

5.10 Availability CAP systems that deal with partitions have to pick Consistency or Availability. Our approach eventually picks Availability, but because we have an objective measure of time, Consistency is picked with reasonable human timeouts. Proof of Stake veriers lock up some amount of coin in a stake, which allows them to vote for a particular set of transactions. Locking up coin is a transaction that is entered into a PoH stream, just like any other transaction. To vote, a PoS verier has to sign the hash of the state, as it was computed after processing all the transactions to a specic position in the PoH ledger. This vote is also entered as a transaction into the PoH stream. Looking at the PoH ledger, we can then infer how much time passed between each vote, and if a partition occurs, for how long each verier has been unavailable.

To deal with partitions with reasonable human timeframes, we propose a dynamic approach to unstake unavailable veriers. When the number of veriers is high and above 2 3, the unstaking process can be fast. The number of hashes that must be generated into the ledger is low before the unavailable veriers stake is fully unstaked and they are no longer counted for consensus. When the number of veriers is below 2 2, the unstaking timer is slower, requiring a larger number of hashes to be generated before the missing veriers are unstaked. In a large partition, like a partition that is missing 1 2 or more of the veriers, the unstaking process is very very slow. Transactions can still be entered into the stream, and veriers can still vote, but full 2 3rds consensus will not be achieved until a very large amount of hashes have been generated and the unavailable veriers have been unstaked. The dierence in time for a network to regain liveness allows us as customers of the network human timeframes