How ImmutableProof Fails

1. Verification failures

Proof is malformed

• The proof does not conform to the required format.
• Result: verification fails deterministically.
• Meaning: the proof cannot be evaluated.

Proof signature is invalid

• The signature does not match the proof content.
• Result: verification fails deterministically.
• Meaning: the proof may have been altered or is not authentic.

Unsupported protocol version

• The proof references a protocol version not supported by the verifier in use.
• Result: verification fails deterministically.
• Meaning: that verifier cannot evaluate that version.

2. Payment failures (proof creation only)

Payment affects only the ability to create a new finalized proof.

Payment failures do not affect existing proofs or verification outcomes.

Payment provider unavailable

• Result: proof creation is temporarily unavailable.
• Existing proofs remain verifiable.

Payment rejected or invalid

• Result: proof creation fails.
• No proof is created.

Consumed or reused payment

• Result: proof creation fails deterministically.
• Purpose: prevent duplicate or ambiguous proof creation.

3. Service unavailability

ImmutableProof service unavailable

• Verification is specified to be possible without reliance on ImmutableProof services.
• Existing proofs are not modified.

Partial outages

• Verification endpoints may be temporarily unreachable.
• Existing proofs remain unchanged.

4. If ImmutableProof disappears

• Existing proofs remain verifiable according to the published protocol specification.
• Verification does not require ImmutableProof services.
• The protocol specification for INP v1.0 is frozen.
• The protocol does not define revocation.

5. What the protocol does not provide

• ImmutableProof does not interpret content.
• Verification results do not depend on payment status.
• Existing proofs are not modified retroactively.
• The protocol does not provide a mechanism to revoke or invalidate existing proofs.