Tendermint founder here. What we're doing with Tendermint is creating a new protocol. See TMSP from the tutorial from Tendermint. http://tendermint.com/posts

Tendermint founder here. What we're doing with Tendermint is creating a new protocol. See TMSP from the tutorial from Tendermint. http://tendermint.com/posts/tendermint-socket-protocol/ http://tendermint.com/posts/tendermint-socket-protocol/ Yes, we're moving away from "PoS" from the time being, because our clients are more interested in posting collateral external to the blockchain. That said, the original security properties still hold. It's the combination of three things that create security on a non-PoW blockchain, for Tendermint. * Validators have posted collateral (either on chain or off chain) that is not immediately transferrable, so there is something at stake. * The BFT consensus algorithm ensures that at least +1/3 of validators must deviate from the protocol to attack the network. * If there is a fork, then we can find out who had caused the fork. The validator-set is held accountable. That hasn't changed. What has changed is our client base. We don't want to launch a cryptocurrency ourselves because as US/Canadian residents, that's a legal gray area. On the other hand, fin-tech clients and banks are interested in utilizing this technology for creating a distributed multi-write database. Thus the change in direction. That said, we're very much interested in support the original PoS design. Other designs as well. For example, we're building out an experimental governance app that allows for arbitrary proposals. Perhaps we can use that to empower users or designated administrator groups to decide on updates to the validator set. https://github.com/tendermint/governmint https://github.com/tendermint/governmint There are many ways to update the validator-set, PoS just being one of them. We will build out our platform to accommodate a wide variety of strategies for managing the validator set. For all strategies, they will make use of our robust BFT consensus algo. Finally, there are sound technical reasons why a BFT ledger should utilize a hash-chain of blocks (list of txs). It is both a speed optimization (validators only need to sign block hashes, not each tx) as well as a security requirement. To expound on the latter, note that the original PBFT implementation does not provide any guarantees when more than 1/3 are Byzantine (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121.9617&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121...). But the hash-chain ensures fork consistency. So there you have it, a chain of blocks of transactions is fundamentally important for non-PoW ledgers. That's why we use the term "blockchains".