Taking away the money part you'll probably want to replace "distributed chained ledger" with "distributed database" or "state-machine replication". There's actually a nice academic literature on this topic of having distributed databases that have strong notions of "commit". This is never the case with stuff that gets called "blockchain". I've yet to encounter something that isn't a variation on "rate-limit the ingest so we have time to replicate operations world-wide" or "create internal monkey-money incentives for agents not to diverge from corretness", both of which are trivial hacks that don't advance anything from a scientific point of view. Not my field tho, so here's the few refs i know.

https://en.wikipedia.org/wiki/Paxos_(computer_science) An old algorithm used for sharding big-data databases.

https://en.wikipedia.org/wiki/Raft_(algorithm) A simplified version of paxos.

http://www.scs.stanford.edu/~dm/home/papers/losa:stellar-ins... The new paper about SCP which allows replication with subjective notions of trust (no central participant-stake list like paxos/raft).

ps: actually i remove "chained" from the idea. If you want to keep the whole authenticated linked-list thing and do it right you'll end up somewhere near https://irmin.org/ (a generalization of git), which is very useful, but doesn't tackle the "strong decentralized commit". You'll probably want to either centrally manage the "lastest-hash(s)" (like git is usually done), or pair it with a state-machine replication protocol. In that last case it may seem useless to use the chained thing if you already have a real replication protocol, but it is much like using public-key crypto for encrypting small ephemeral symmetric keys and encrypting actual data with symmetric crypto: it's an optimization.