tequ {X}🪝

Statement on dUNL Responsibilities and my position following the Batch amendment incident (XLS-56) Over the past weekend, in spaces and in several DM conversations regarding the recent Batch amendment issue (widely referred to as BatchGate), I have seen widespread confusion about the actual role and responsibilities of dUNL validators. I want to provide clarity from my perspective as a long-standing operator, along with the conclusions I have reached. The role of dUNL validators is specific and limited: We coordinate the activation (or rejection) of amendments by casting “Yay” or “Nay” votes once an amendment is proposed. We are supposed to judge pending amendments. That is our primary governance function. The baseline expectations for anyone on the dUNL are straightforward technical competencies: - Deep understanding of how rippled works - Operational experience running and maintaining rippled nodes - Solid knowledge of decentralised network principles - Ability to debug issues quickly - Proactive mindset to identify risks before they materialise Importantly, dUNL participation is uncompensated. The principle “no incentive is the best incentive” has always guided consensus security, and I fully support it. I run my validator as a service to the network because I believe I am well-positioned to help protect its long-term health and uptime, better than the vast majority of voices in the ecosystem. I have repeatedly pushed back against Ripple when I believed it was in the network’s best interest, and I will continue to do so. Ripple’s corporate objectives are not always aligned with the XRPL’s security and decentralisation priorities. My success metric is simple: 100% uptime and preventing issues, not their resolution after the fact. The dUNL is not a free code-review or protocol-auditing body. Expecting validators to spend dozens of unpaid hours reviewing complex amendment code was never part of the design and never will be. Instead, parties proposing amendments should be required to deliver comprehensive documentation, test suites, security analyses, and formal proofs upon request. If you want my vote, prove the change is safe and beneficial. I have applied this standard consistently for years. However, requiring proposers to ask them to review their own code is simply not enough. We need more eyes and hands on the code. Past warnings ignored. Over the last five years, I have publicly flagged serious concerns with several high-impact amendments, including XLS-20 (NFTs), XLS-30 (AMM), and now XLS-56 (Batch). In every case, my concerns proved valid. Despite this track record, the pattern has not changed: proposals continue to advance with insufficient scrutiny, and public discourse rarely engages with the actual technical risks. The recent critical vulnerability in XLS-56, which could have allowed unauthorised transaction execution and potential fund drainage, is the latest and most serious example. The fact that it reached the voting stage on mainnet before being caught, and that public disclosure by an independent researcher and an AI tool was ultimately required to prevent harm, highlights a systemic failure in review processes. By public opinion, this issue rests with the amendment’s authors and the dUNL. Meanwhile, formal verification and AI are being pitched as the complete solution, as the holy grail. This is unacceptable. My actions moving forward, effective immediately: - Withdrawing all current “Yay” votes on every amendment under consideration (excluding pending fixes) - Refusing to upgrade to rippled 3.1.1 (unless staying on the prior version risks removal from the network) I will not vote in favour of any future amendments until Ripple makes a credible, concrete commitment to substantially increase investment in XRPL core protocol engineering, security review, and long-term sustainability. I am pinning this on Ripple as no well-funded alternative exists in the ecosystem as of today. If XRP is truly Ripple’s “North Star,” as repeatedly stated, then the network’s foundational security and decentralisation must receive the attention and resources they deserve. A fintech company positioning itself at the centre of future finance cannot afford to under-invest in the very ledger that powers its vision. A fancy blogpost with made-up numbers is not enough. I remain fully committed to the XRPL’s success and will continue to operate my validator to the highest standards of reliability. However, I will no longer participate in a governance process that repeatedly accepts elevated risk without corresponding accountability. The network’s security and longevity must come first. Always.