The support ticket was annoyingly normal.
User wants reason for denial.
Partner wants explanation before retry.
Ops wants something they can paste back without escalating again.
That was it. Nothing dramatic. No exploit, no failed proof, no broken contract. Just a result nobody could explain in the kind of language people actually ask for when they are stuck.
And the bad part was that Midnight had already done its job.
The Compact contract ran. The outcome settled. The proof validation passed. Validators checked the result against the circuit with the verifier keys, accepted it, and moved on. From the network’s perspective, this was one of the clean ones.
Correct output.
Valid proof.
Done.
Except not done, obviously.
Because “the proof passed” is an answer only if the person asking the question already thinks like the protocol. Most people do not. The user did not want cryptographic correctness. The partner did not want proof-based assurance. They wanted a reason the way institutions always want a reason, what condition failed, what input mattered, what path inside the logic produced this outcome instead of the other one.
Something readable.
Something blame-shaped.
Midnight is where that gets weird fast.
On a replay-visible chain, even messy logic leaves a trail. You can inspect the transaction, walk the execution, point at the branch, reconstruct the state transitions, and say: there, that’s where it happened. Maybe ugly. Still legible.
Midnight does not verify contracts that way. The network does not replay the execution. It does not watch the Compact contract unfold step by step in public. It checks the proof against the circuit, confirms the output is mathematically consistent, and accepts the result because the cryptography holds.
That is enough for correctness.
It is not automatically enough for explanation.
And those are not the same thing, no matter how badly people want them to be.
That gap is not accidental here. It is native to Midnight. Once trust shifts from replayed execution to proof validation, the chain stops being the place where outsiders learn how a decision unfolded. It becomes the place where correctness gets certified. Cleaner, yes. Also thinner.
The result can be right without being interpretable in any ordinary sense.
Which is exactly what was happening in that ticket. The contract had not failed. The proof had not failed. Midnight had not failed. What failed was the expectation that a correct output would still come with a usable explanation attached to it.
Ops kept pushing the same question in slightly different forms.
Can we tell them why?
Can we show which condition triggered it?
Can we at least give them enough to stop the back-and-forth?
And the honest answer was uncomfortable. Not because the system did anything wrong. Because the system was designed around a different kind of trust. Midnight guarantees that the Compact contract followed its circuit. The verifier keys and proof validation settle that part. But they do not magically produce a narrative someone in support, compliance, or partnership ops can forward around without friction.
So the burden moves somewhere else.
Interface text.
Selective disclosure.
Application-level explanation.
Whatever the builder decided would sit on top of the proof after the proof had already settled the chain.
That is where this stops being a neat cryptography story and turns back into product design. If the contract is provably correct but the execution is not directly observable, then trust does not end at validity. Somebody still has to decide what kind of explanation survives after Midnight has already proven the result.
And if nobody designed that layer well enough, the contract can be perfectly correct while the human answer still comes back looking unfinished.
Which is a very boring problem.
Right up until someone asks for a reason and all you really have is: the math said no.