So FACTOM servers aggregate the hashes from all of their clients into one megahash and commit it to the blockchain every 10 mins while giving cryptographic proof to each client that their hash was indeed included into the megahash?
This is a nice way to cut costs for your clients, albeit your solution has a single point of failure - FACTOM servers. Still some gov and corporate entities may be interested in using your service.
What I did not immediately understand after looking at the paper is why you need your own coin and your own chain?
Can't FACTOM be a subscription-based service where you hand out API keys to your clients to push the hashes to your servers?
The easy stuff first.
Why does Factom use its own chain? The really short answer is that Bitcoin has no room. Gotta go somewhere else. But bigger picture, if you want to provide proof of a series of modifications, you have to link entries together in some cryptographically provable ordered set. Or a chain. If you want to require everyone to have to have everything, you use one chain (like Bitcoin does). But if all you want to do is record data, why mix it all together? With Factom, a user can create various chains which to track the data interesting to them, while Factom uses a set of Directory Blocks to track these chains. Directory blocks are designed to be small and light, allowing applications to find the chains they need. Then only that data has to be downloaded.
So having a chain outside of Bitcoin is necessary not to produce single proofs of entries, but so you can create a series of related entries in a provable set, without requiring everyone to have everyone's data to prove the content and order of their own set.
Single point of failure issue: The Factom servers are to be a distributed set of servers; anyone with sufficient support from users of the protocol can run a Factom Server. Thus our "Single Point of Failure" will be the 32 Federated Servers + the 32 Audit Servers (which can replace a lost Federated Server in real time) + Candidate Servers competing to become Audit Servers. Or in other words, once past milestone 3, there will be no single point of failure. In comparison, Bitcoin has far fewer options should the network lose any significant number of the five or six major mining pools. (The Bitcoin situation is more complex, so that five or six might represent (quickly) 10 or 15 entities as hash power moves elsewhere on the loss of a pool, yet it still doesn't have the decision making power distributed over as many diverse entities as Factom does.)
The harder question: Why does Factom use a token? Why not a subscription service? Why not Bitcoin?
Why does Factom use a Token rather than just being a subscription service. First, Factom IS a subscription based service. Entry Credits are nothing other than API keys used to push hashes (or data) to the servers. Nothing more, nothing less. They cannot be transferred, they keep your balance, and you can recharge them as you wish. You can buy entry credits from us (you provide an Entry Credit address to our store, pay for entry credits at some rate (1/10 cent + some mark up) and we charge your address at that address.
Where do entry credits credits come from? They are created by converting (or destroying) Factoids, the token.
Second, Factom uses the token to reward servers in a distributed system for maintaining the Factom chains and data. While Bitcoin or some other token might be used for rewards, this would push the accounting onto Bitcoin (or that other token) and thus require (perhaps significant) bitcoin (or other token) blockchain space to support. If people pay in Bitcoin to get their entry credits, the distribution of those Bitcoin to the servers running the protocol becomes a problem. Decentralization requires the code (not a wallet) to provide the reward for contributing to the protocol. The way code does this is through a token.
I hope that helps. This is very high level, and I'd be happy to answer questions if anything above is unclear.
Paul Snow
