Contract Verification Aggregation (draft SEP, companion to Contract Verification Results)

[jia57b]

This thread is to discuss a second draft SEP: Contract Verification Aggregation. It depends on Contract Verification Results (https://github.com/orgs/stellar/discussions/2037), and the two PRs are open side by side.

Draft: https://github.com/jia57b/stellar-protocol/blob/sep-contract-verification-aggregation/ecosystem/sep-contract-verification-aggregation.md
PR: #2040
Depends on: #2038

The problem. Independent verification is worth more than one verifier's word, but only if a reader can see every answer, including the ones that disagree. Every consumer that merges verifiers itself makes the same decisions differently (timeouts, stale results, "disputed" vs "newest wins"), and none of those decisions are visible to the person reading the result.

The approach: an aggregator relays, never adjudicates.

• Each verifier's entry is passed through unchanged: its own identity block, fields the aggregator does not recognise, and the schema_version it was read at.
• unavailable_verifiers is always present, with a reason (fetch_failed, invalid_response, timeout, refused), so silence is visible.
• agreement describes how the entries relate (single, unanimous_verified, disputed, …) and is never a verdict. One verifier is single, not "unanimous".
• The Trusted Verifiers List (GET /v1/verifiers) is the operator's own published input. Paused and disabled members stay listed, so an omission can be checked from outside. There is no registration API.
• An aggregator that has not read its list yet answers 5xx, never an empty 200.

On trust (re @ethanfrey in #1945). This SEP accepts that an aggregate is only as trustworthy as the aggregator, and does not try to fix that with signatures. Instead it makes every entry checkable at its source: verifier URL plus results_urls with sha256. A reader that does not trust the aggregator re-reads the verifiers directly.

Open questions

1. Should list membership (admission and revocation) ever be specified, or stay the operator's call?
2. Is agreement's vocabulary right? Are any states missing?
3. Is GET /v1/contracts/{network}/{contract_id} worth standardising, or should it stay an explorer concern?