@Brighton36 has clearly not done any research on Factom. If he had read the Whitepaper, the Consensus paper, had he followed the feedback from people like Vitalik, Peter Todd, Luke JR, and many, many others, he could talk to Factom more realistically. In fact, both papers were analyzed, in real time, with comments inline with the document as we went through our public review.
Factom uses a consensus algorithm to build and record entries organized in chains within Factom. A chain represents more than a simple notarization of data, but actually creates a set of data that can be used not only to show what has been entered into the record, but also what has not been entered. Individual entries can be signed, to demonstrate the authority of the submitter.
What @brighton36 keeps talking about is simple Proof of Existence. Factom is providing a Proof of Process. This is actually very powerful for building immutable audit trails, of which Bitcoin's Blockchain is one incredible example.
Factom also anchors its structures into the Bitcoin Blockchain in such a way that it must follow the majority of the servers. It can be branched (i.e. some set of servers can take the history and start building in another direction) but it cannot be forked (where a majority of servers simultaneously begin building two histories). If the protocol dies, one could run the Factom software to continue supporting your applications (since it is open source). You would have to document a branch (assuming a majority of the Factom servers don't choose to support you) but you could continue on.
The proofs of data in Factom remain as long as you have the Factom data and the Bitcoin blockchain. I like to say that you trust Factom for 10 minutes, and Bitcoin forever.
We will deploy a set of 32 federated servers to record this data. These servers have shifting authority over different parts of the network at different times. This ensures that even if some server fails to record your entries because they don't like you, eventually some server will. Unless they are all corrupted.
Behind the 32 federated servers, we have 32 audit servers. These servers are online ready to replace a federated server should they 1) fail, or 2) get faulted out for breaking the protocol, or 3) lose support from the users of the Factom protocol. The 32 federated servers and the 32 audit servers are paid Factoids to run the protocol. They also set the conversion rate of Factoids to Entry Credits. Factoids are tradable, Entry Credits (which you can think of as empowered public/private keys) are not.
So a Factom Protocol user can simply buy Entry Credits and empower a public/private key pair. Then use that pair to sign messages to create chains and create entries. That's it. They don't need a wallet (you can't transfer Entry Credits anyway) and the security of their application is higher because there isn't anything to steal really by getting this private key other than to write data into Factom.
Furthermore, if your application is concerned about exposure to Cryptocurrency (like you are a US business with needs for many records, say to create audit trails for subcontractors) you are not exposed to MSB or MTB rules, or capital gains on the token. It is just a token for the protocol anyway, with no resale value. The price of Entry Credits can be kept at a steady 1/10 a penny, no matter what the value of Factoids are. So as a user, you don't care when you buy them. As long as you have enough for your purposes.
Further, the use of Entry Credits provides proof of use of the protocol, and is the basis for electing the Federated Servers. This is very much like Poof of Stake, only it is more like Proof of Use. The value for voting of Entry Credits degrades over time, so it is only the users of the protocol that have say about how the Federated Servers are. This influence can be delegated, so that users can use parties to protect their interests without having to pay attention to Factom politics. Audit servers can point out (using Factom itself) misbehavior of Federated Servers.
Looking at the Federated Servers and Audit Servers, they are paid a fixed number of Factoids forever. And the use of Factoids removes them from the supply. So the only way to increase their income is to promote and protect the protocol, because the more the protocol is used, the more Factoids are required, and the lower the Factoid supply will be. If the Factoids are under valued, the Factoid supply will fall, in some cases very rapidly. If Factoids are over valued, the Factoid supply will grow (since it will take fewer Factoids to convert to Entry Credits for the demand of the protocol).
I spent months trying to figure out how to align the incentives without a token. And I was finally convinced that the token was necessary, and a year and a half later I still know of no way to build Factom without a token.
I hope this helps.
