I endorse CHIP-2025-03 Faster Blocks for the November 2026/May 2027 BCH upgrade cycle, targeting a 1 minute blocktime. I believe the benefits are clear, the tradeoffs are acceptable, and the risks are known and bounded. Faster blocks would be an essential step to improving the user experience of Bitcoin Cash in many dimensions. While 0-conf is excellent, and we should still utilize 0-conf whenever possible, Bitcoin's fundamental design and security assumptions still ultimately rely on block confirmations. If we walk through each of BCH's primary use cases: - P2P Cash: payer and payee are more resilient to dsproof-hostile transactions. Multiparty transactions settle more quickly with less contention. - DeFi: Anyone-Can-Spend UTXOs that power BCH dApps can become contested due to simple latency between users and relay nodes. Faster confirmations means less downtime for dApps that encounter this regularly occuring issue. - Currency exchange: both CEXes and DEXes benefit from faster confirmations. We also have heard from Maxbit, one of the largest exchanges in Thailand, signalling an industry expectation for faster confirmations. This suggests to me that CEXes may potentially consider adjusting their confirmation limits after this change - a clear win for attracting BCH liquidity and facilitating real-world use. - Mining: Miners are afforded more certainty in their future earnings, while also smoothing out overall variance between blocks. Smoother variance also allows better calibration for the DAA and ABLA. Almost every stakeholder can find a reason that faster blocks could benefit them. From my point of view, all technical objections have been adequately addressed, and the problem space has been thoroughly explored. I initially had reservations about SPV header growth due to potential complications with a NFC payment card usecase. I later realized that there are other ways to design such a product where that's not an issue, dissolving the last remaining concern I had. The only barrier, as others have said, we cannot move forward if the implementation is not sound. I have confidence in our node developers' capabilities, and if the will to upgrade is overwhelming, the community will find resources to make sure everything is developed and tested on time. The `ticks` abstraction is just the right amount of engineering on paper. However, I expect the realities of implementing such a fundamental change to legacy node software will be fraught with skeletons and dragons. Luckily, our top wizards seem to already be on top of it, with a whole upgraded spellbook to boot. My endorsement is contingent on sound implementation and a safe launch on a separate chipnet BEFORE November 15. On behalf of myself and my enterprises, I offer my approval. 2026-09-20; Kallisti#159412⚖️; bitcoincash:qzvj8dvrj52fmnwcxz2dd2e2tgnmgze47u099rchsf - Kallisti.cash (@kzKallisti, kallisti.io) - Selene Wallet, with joint approval from The Bitcoin Cash Podcast (@SeleneWallet, selene.cash) - Selene Technology LLC - XULU.TECH LLC (xulu.tech) - BCH Ninja (bch.ninja) --- Signature: IPD5rtayVFdhmRutpzpmC+T2OTxT83ekUwDf9p1Nsm/5MgFqCvTbZktJH8lBloFEkfCOucDHgm7hqOazSQa5T/A= Public Address: bitcoincash:qzvj8dvrj52fmnwcxz2dd2e2tgnmgze47u099rchsf