Pleased they ignored that request too, although I can see where RDX are coming from. In a distributed ledger it's all about state. The consensus layer of the architecture is rock solid according to this report.
In my experience it is not. Rather, aggressive fsyncing/O_DIRECT usage are common. The rationale for this is usually partition risk: better to durably log a write before propagating it than to potentially fail in propagating it and then be left in a position of having to either reactively fsync or hope that automatic flush-to-disk will persist your unexpectedly-sole possession of that update.
That's quite a stretch. The report states explicitly a) the usual proviso that they can only prove the presence of bugs, not their absence, but more pertinently b) that their methodology is more usually applied to lower-latency databases, with the implication that they are less confident of their conclusions in this new regime:
> Radix’s low throughput and high latency may have masked safety violations. In particular, our tests required several hours to reproduce e.g. aborted read (#13).
Note also that they didn't even attempt to test what happens in the presence of malicious nodes!
One of your recent-ish blog article for instance, that contrast (commercial vs technical) with the Jepsen report: https://www.radstakes.com/post/airdrops-incoming-radstakes-p...
And your statement of the 2% fee you seem to take on every staking: https://www.radstakes.com/post/radstakes-year-end-report
This report will not help your business, but you should pressure RDX Works into doing a new one on the next version rather than convince us we didn't read properly some quite shocking things in the first one :s