Consensus among parties tolerating up to Byzantine faults requires in synchronous networks and in asynchronous networks. The higher resilience achievable in synchrony relies on a known message delay bound , whereas asynchronous protocols make no timing assumptions but must tolerate fewer faults. Prior work addressed this gap only partially. Some protocols achieve responsiveness under synchrony, meaning that their running time adapts to the \emph{actual} network delay, but offer no guarantees under asynchrony, while others guarantee correctness under both network conditions but sacrifice responsiveness. Only recently, Elsheimy, Kamp, Loss, and Nielsen (IACR~2026) showed for binary validated Byzantine agreement (VBA) that if , , and denote the synchronous, asynchronous, and responsiveness thresholds, respectively, then the conditions and are necessary and sufficient to simultaneously achieve asynchronous security, synchronous security, and responsiveness. While binary BA (or VBA) can be extended to multi-valued Byzantine agreement (MVBA) via standard reductions, such transformations generally incur blow-up in the communication. Whether these tight resilience conditions can be achieved for MVBA \emph{with optimal communication complexity} remained open.
In this work, we resolve this question. For the aforementioned optimal thresholds, we construct an MVBA protocol that is asynchronously secure when , synchronously secure when , and responsive when , where is the actual number of corruptions. Our construction builds on Dumbo-MVBA~(Lu et al., PODC 2020) and preserves asymptotically optimal efficiency. When , our first construction achieves communication for -bit inputs and computational security parameter , matching the best known bounds in asynchrony of Lu et al. (PODC 2020) and the best known synchronous bounds of Shrestha et al. (FC 2025). When is small, we provide an alternative construction with communication in synchrony and in asynchrony, where is a statistical security parameter. Whenever , both protocols terminate in expected time, where is the actual network delay; otherwise, the expected running time is .