Right. We have essentially 2 separate and overlapping categories of consensus testing: Tests to prove that we don't diverge from core, and then separately tests to prove that we implement bitcoin consensus rules as we understand them. So we run core's functional tests, core's json fixtures, differential fuzz against core. We now have our own json fixtures in addition to core's (also validated against a new embedded core oracle while we created them) with additional coverage for our interpreter, plus a full suite of our own end-to-end and unit tests to guard our own consensus. At this point, rbitcoin has the most complete set of automated tests asserting bitcoin's consensus rules of any implementation. Yesterday, we did find one category of bug which was hiding in the system where certain consensus rules were not correctly enforced during IBD when blocks confirm in batches (h/t @nitesh_btc ). I (and others) continue to audit against every source of consensus claims as they become available to ensure that rbitcoin is in consensus. For example, @Rob1Ham posted his Lean proof of core's consensus rules yesterday, and I immediately got to clank on mapping them to rbitcoin code and tests. I have a PR open with that mapping. I still have to human-check all the gaps that were not mapped to ensure that they are intentional (e.g. rbitcoin does not have full testnet support). Not sure it'll ever merge, but it still provided another validation that each consensus rule maps 1:1 between the two implementations and through a formal proof system in this case).