> You need a consensus mechanism and immutable ledger in order for it to be secure and truly transparent

Consensus between who? The stablecoin issuer, stripe in this case, is a single party, who are they coordinating with that requires a consensus algorithm?

How does centralized SQL replication do consensus, compared to a DLT?

Blockchain consensuses: Which is the next block, Which protocol version must what quorum upgrade to before a soft fork locks in, Whether a stake should be slashed, Leader/supernode election (handled by the UNL text file in git in rippled, which underpins R3, W3C Web Monetization micropayments, and W3C ILP Interledger protocol (which FedNow implements)),

When there are counterparties and then they might as well just off-site replicate the whole database or blockchain locally, and run indexes and queries at their expense.

And then there is a network of counterparties willing to grant liquidity to cover exchanges that cover multiple assets and chains, who want to limit their exposure by limiting the credit they extend to any one party in the network and account for an entire auditable transaction. (Interledger ILP Peering, Clearing, and Settlement)

Private blockchain or SQL replication scaling woes? And then implement mandatory keys in an append-only application.

This or something like Trillian?

From "PSA: SQLite WAL checksums fail silently and may lose data" https://news.ycombinator.com/item?id=44672902 :

> google/trillian adds Merkle hashes to table rows.

> sqlite-parquet-vtable would workaround broken WAL checksums.

> [...] [cr-sqlite implements CRDT, which is one of a number of newer ways to handle consensus in SQL database replication ]

> (How) Should merkle hashes be added to sqlite for consistency? How would merkle hashes in sqlite differ from WAL checksums?