Jepsen's latest distributed systems safety report covers Radix DLT 1.0-beta.35.1 through 1.0.2. We found stale, aborted, and intermediate reads, as well as the partial or total loss of committed transactions. Transactions could also hang indefinitely.
For Radix DLT folks concerned about 16 vs. 50 transactions per second--I wouldn't worry about that at all. In benchmark terms those are basically the same number. As mentioned in the report, we're talking about different hardware, a different network, and different workloads. :-)
Since the release I've had the chance to chat with a handful of analysts working specifically on verification of blockchain/cryptocurrency/DLT systems, and can confirm that they also use the usual distsys sense of "safety property"--namely: "something bad does not happen".
I'm not sure how widespread this understanding is in the DLT space (still looking for a citation for RDX Works's definition) but the researchers I've talked to were unanimous: losing committed transactions *is* a safety error, even if every validator agrees to throw away data.
They also stressed the importance of end-to-end verification of safety properties, because APIs are how exchanges and users actually interact with DLTs. This is a challenge in traditional databases as well: composition of (e.g.) serializable transactional DBs is nontrivial!
RDX Works (the makers of Radix DLT) states that all safety issues as well as the problem with indefinite transactions have been resolved as of Radix DLT 1.1.0.