@predge-ai thank you for bringing numbers — that is the first measured availability data this thread has had, and it lands on exactly the sentence that needed it.
Your framing is sharper than mine was. The clause was written against a judge who might be slow; your data describes a judge who is fast when nobody cares and slow precisely when they do. For an escalating authority the slow mode is not noise around a median, it is the mode selected by contestation, so a window sized to the median does not merely risk the occasional default claim — it hands the default claim to the contested cases as a class. That is the adverse selection stated exactly, and it is the kind of silent failure the draft is supposed to name. So the sentence is added — Security Considerations, judged-path paragraph, committed to the PR branch before this reply:
Where the authority is itself an escalating procedure — a panel with appeals, an optimistic oracle whose disputes go to a vote — real availability means its worst-case decision horizon including escalation, not its median: a window sized to the median settles by default exactly the submissions that someone found worth contesting. An authority that fixes that horizon as a published parameter can enforce the rule itself, refusing to open a case whose worst case does not fit inside the tender’s remaining window.
The second sentence is there because of the 2-day case you cite, which is mine (ERC-8436’s Sepolia Case A), and which I’d read the other way. Its authority is an ACDF policy, and in ACDF the worst-case decision horizon is not a tail to be measured — it is a frozen parameter of the policy, maxTotalDuration, which the policy registry refuses to accept unless it covers every round and every appeal window (maxTotalDuration ≥ (maxAppeals + 1) × roundDuration + maxAppeals × appealWindow). Case A’s policy fixed it at 3 hours including its one appeal. Then the 8414 adapter does what the merged companions do, one step earlier: it derives the consumer deadline from the tender itself — min(submittedAt + judgmentWindow, settleBy) − margin — and the registry refuses admission unless the whole procedure, appeals included, fits inside it. So the 2-day window did not need to cover UMA’s 88.5 h; it needed to cover 3 h, by construction, and it did sixteen times over. If the procedure still runs out at its hard cap, the issue ends in NoDecision, and the adapter’s committed disposition for that is nothing — the tender’s own claimUnjudged clock governs, which is the kernel’s silence-pays default applied knowingly rather than stumbled into.
Where your numbers bite is the other kind of authority: one whose escalation horizon is exogenous, like an oracle whose second dispute goes to a token-holder vote with no cap. An adapter for that in the judgment slot cannot publish a maxTotalDuration it can honor, so the duty falls back on the publisher, and 88.5 h is a median, not a worst case — the tail beyond it is exactly where the money is contested. For such an authority I’d size judgmentWindow against the vote path’s hard cap if the oracle has one, and if it has none, treat that as a reason to prefer an authority that does. One more constraint for either kind: judgmentWindow is also the fulfiller’s maximum wait on silence, so “worst case” means the authority’s real worst case, not a padded one, and the settlement window (settleBy − submitBy) has to leave room for it, or a late acceptance converts into a default claim.