> "The issue: Transaction’s order can affect its validity and thus a honest node may appear dishonest to an observer who sees a different state at the moment of tx validation."

Pepo, Sorry, I thought you understood Hololochain better. Ordering is not systematically omitted, it is already systematically addressed by the fact that all data is committed to ordered hash chains (called source chains) as the source of data which is then published to the shared DHT state. That means ALL DHT data has immutable, non-repudiable, local ordering (distinct from global ordering which requires the heavy load of global consensus). But both blockchain and Holochain use hashchains to establish clear ordering (hence the "chain" part of the names).

All source chain headers (even for private entries) are published to the DHT, and once a header with its progressively chained hashes has been published, it creates an immutable past, a user cannot go back and change anything about data, including the order.

While it's true that the DHT is eventually consistent, so that different people may see a different state for some moments while reaching consistency for any particular data element, they can never see a different ordering of data. They may be missing some newly added data, but there is no confusion about the order of all data that they can see.

Let's look at your token transaction example. Remember, we recommend implementing currencies on Holochain not as a global inventory of tokens but as P2P transaction accounting. So let's look at a HoloFuel transaction -- for example, me sending you 100 units for hosting you've performed.

You commit an invoice to your chain for 100 HF then send it to me (or if I'm offline, link it from my agent ID so I'll see it when I come back online). I commit a promise to pay it to my chain, and send it to you (or similarly link it if you're offline). Then at a moment when we are both online, HoloFuel can automatically initiate a transaction to actually complete the transfer. We construct the transaction with me as spender, and you as receiver, and we BOTH sign it to our chains (using neutral parties on the DHT randomly selected by the hash to collect each of our signed headers for the transaction).

This countersigned transaction is only valid if it has BOTH of our headers attached to it, and it is an identical transaction in each our chains. While we were in the countersigning session we had to momentarily lock our chains because the entry references our current chain position and is only valid at that position. This is what allows me to validate your state and you to validate mine for us to agree to the transaction.

Any transaction that exists on the DHT, has the countersigning data and BOTH headers showing clearly what order in happened in the parties chains. And it is only the state of the affected parties that is relevant as to the validity of the transaction, so we don't need some kind of global ordering.