security(contracts): support verifier sets and quorum-based proof acceptance

[enliven17]

Summary

Reduce dependence on a single verifier implementation by supporting bounded, versioned verifier sets and configurable m-of-n acceptance.

Motivation

Harpocrates needs this capability to become a production-grade, interoperable evidence protocol while preserving privacy, deterministic verification, and safe failure behavior. The implementation must reuse existing metadata, manifest, ZK, backend, frontend, and Soroban boundaries instead of creating parallel truth sources.

Scope

• Define verifier-set versions, members, compatible circuit/artifact versions, threshold, activation, retirement, and emergency disable.
• Collect distinct verifier results and finalize atomically after quorum.
• Represent disagreement, timeout, partial failure, and incompatible output deterministically.
• Govern set changes through existing staged rotation/timelock controls.
• Bound verifier count, calls, proof size, and Soroban resource use.

Acceptance criteria

• Duplicate verifier votes and replayed results cannot satisfy quorum.
• Tests cover split decisions, unavailable verifiers, version mismatch, rotation overlap, and emergency disable.
• No partial result is misrepresented as final verification.
• Benchmarks, migration, rollout, and rollback guidance are included.
• Existing lint, type checks, tests, builds, contract checks, and privacy guarantees remain green.

Engineering expectations

Use versioned canonical encodings, explicit error/status types, bounded resource consumption, idempotent operations, and privacy-safe observability. Schema, contract, circuit, or artifact changes require migration and compatibility analysis. Cryptographic changes require stable vectors and a written threat model.

Out of scope

Live production deployment, real credentials or sensitive media, unrelated visual redesigns, and broad dependency upgrades not required by this objective.

Definition of done

A maintainer can reproduce success and adversarial failure paths locally, understand the trust and privacy boundaries, operate the feature safely, and roll it back without undocumented state repair.

[emmyokolo2525-cyber]

@emmyokolo2525-cyber has applied to work on this issue as part of the Stellar Wave Program's 7th wave.

Hi maintainer, I'd like to work on issue. I'll keep the implementation aligned with the current architecture and submit a focused, reviewable PR.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @emmyokolo2525-cyber to this issue.

[drips-wave]

Congratulations, @emmyokolo2525-cyber! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on July 30, 2026.

🧑‍💻 @emmyokolo2525-cyber: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊