What are the signs that a Move specification is too weak to catch real bugs?

What makes a Move specification too weak to trust?

A weak specification leaves room for the prover to satisfy the rules without actually protecting the property you care about. That usually means the spec is too abstract, too permissive, or missing the exact safety condition that would rule out the bad state. The result is a proof that looks successful but does not meaningfully constrain the implementation.

One common sign is that the specification only checks a narrow slice of behavior, so unrelated but dangerous paths remain open. Another is that the proof still passes when you remove an important runtime check, which tells you the proof is not anchored to the security property itself.

Which gaps usually show the specification is underspecified?

Weak Move specs often fail in predictable ways. They may leave permissions unconstrained, so any caller can satisfy the model. They may omit resource conservation, so minting, burning, or balance drift is not prevented. They may describe a function’s intent without asserting who is allowed to invoke it, which lets the prover prove the function under assumptions the real system does not guarantee.

A good test is to ask whether the spec would still reject a clearly unsafe state if the code were changed in the wrong way. If the answer is no, the spec is probably describing the interface, not the invariant. In Move, that distinction matters because the strongest proofs come from invariants that track capability ownership, resource movement, and entry-point authorization.

How do you tell whether the proof is real or only cosmetic?

The best indicator is whether the specification fails when you deliberately weaken the implementation in a way that should be unsafe. If removing a check, relaxing a permission, or skipping a conservation rule does not break the proof, the specification is not pinning down the bug class. Another warning sign is when the prover succeeds only because the model omits a realistic caller, state transition, or resource edge case.

Look for specs that are satisfiable for the wrong reasons. For example, a property may be true because the model never reaches the dangerous state, not because the dangerous state is impossible. That is a coverage problem, not a proof of correctness. The stronger the property, the more it should force the prover to account for the exact preconditions that would make the bug possible.

Risk and Threat Considerations

A weak specification can create false confidence, especially when it permits privilege bypass, resource inflation, or unauthorized entry-point use to remain invisible to the proof. The practical risk is not just a missed bug, but a proof artifact that reassures reviewers while leaving the real failure mode untouched.

Failure mechanism: The spec omits a material invariant, so the prover validates a narrower or easier property than the one the code must actually satisfy. That lets unsafe states remain reachable even though the formal check reports success.

Impact: Reviewers may ship code that appears formally verified but still allows incorrect authorization, broken resource accounting, or other exploitable state transitions.

Practitioner Guidance

What to verify: Test the spec against the failure you most want to prevent. Remove a critical check, relax a permission boundary, or mutate a conservation rule and confirm the proof fails. If it still passes, the property is too weak or too indirect.

Common mistake: Treating a successful proof as evidence that the implementation is safe, when the spec may only prove that some execution path is consistent with the model. The useful question is whether the specification excludes the exact bad state, not whether the prover can find any satisfying state.

Practitioner takeaway: A useful Move specification should make the unsafe state unprovable, not merely make one implementation path look correct.

Related resources from NHI Mgmt Group

• What are the signs that LLM security testing is too narrow to catch real-world abuse?
• What are the signs that API testing coverage is too shallow to catch real abuse?
• What are the signs that mobile passcode protection is too weak for real-world theft scenarios?
• What are the signs that a FinTech security model is too weak for real-world threats?