结算运营会上有人说“几秒就确认”，先问这句话绑定的是哪一个状态。sequencer 和 L2 区块可以给出较早的可见反馈，但这只说明请求进入了某个处理阶段；batcher 把数据发布到 DuskDS，又增加了一层可验证性；状态承诺和最终状态，才接近结算承诺所需要的证据。

因此，体验 SLA 和结算 SLA 应该分开写。体验 SLA 可以描述提交后多久看到 sequencer 或 L2 反馈；结算 SLA 要描述数据何时发布、状态承诺何时可查、最终状态何时成立。前一个时间短，不代表后一个承诺已经完成。

这条分层也方便解释延迟。用户可能很快看到交易，却仍要等待 batcher 发布或底层状态形成；如果只用最早的时间点宣传完成，金融团队会把可见性误当成放行依据。检查表应为每个阶段记录对象、时间和下一步，而不是只保留一个“confirmed”。

对 @Dusk 的结算描述，$DUSK 不是 SLA 证据。#dusk 可以讲速度与最终性，但不能把快速收录写成已完成最终结算。

如果团队要把等待时间写进合同或运营承诺，就应分别给出四个节点的定义和测量方式。没有节点定义的“秒级结算”，只能描述体验印象，不能作为最终状态的 SLA。

两条 SLA 分开，用户体验和结算责任才不会互相透支。

合同中的时间也应说明开始和结束边界：从提交到收录，从收录到数据发布，从发布到状态承诺，最后才是最终状态。

定义要写清。

时间点不同，承诺就不能相同。