Oracle riddle: signature validity versus panel consensus

Research date: 2026-10-09 (UTC). Scope: the documented IMD oracle interface, considered for a SIMD Discovery Arena consumer; no live request or deployed SIMD consumer was inspected.

1. The question in one sentence

Under Identity.md's documented version-2 oracle semantics, does a valid oracle signature necessarily establish that the signed answer met the requested panel quorum, and what additional evidence would a SIMD consumer need to establish that conclusion?

2. What evidence would make the answer trustworthy

Observed documentation facts: The official documentation defines an EIP-712 version-2 attestation with signed panelSize, quorum, and agreed fields. It describes agreed as the number of members giving the signed answer and explicitly permits it below quorum for chain evidence when a deployer's rerun resolves a split. It recommends agreed >= quorum for accepting panel agreement. Identity.md, “The attestation”

Proposed evidence standard, not evidence already collected: For a particular request, obtain the exact quoted question and quorum policy, original attestation bytes, signing domain and types, signature, and authenticated signer configuration. Preserve their hashes and acquisition times. Recompute the digest and signature verification independently, compare the signed counts with the quote, and check the consumer's actual acceptance conditions.

For stronger assurance than an asserted count, obtain attributable panel submissions and the aggregation record. Reconstruct which submissions support the precise encoded answer and how abstentions, duplicates, tolerances, and conflicts were handled. Independence would need separate evidence about operators and shared sources; a list of seats alone is insufficient.

For a chain-derived result, preserve the recipe, chain identifier, block numbers and hashes, relevant logs or call results, and any rerun record. Independently reproduce the calculation against those blocks. Inspect deployed bytecode and configuration at a specified block, rather than treating documentation or example code as proof of a consumer's behavior. These are proposed review steps, not claims about observed chain state.

3. What an attestation would and would not prove

Conditional cryptographic fact: Correct EIP-712 verification authenticates a structured message to the accepted signing key and binds it to its domain. EIP-712 itself does not provide replay protection. EIP-712 specification, Abstract and Specification

Inference: With a trusted signer configuration and correct verification, an attestation authenticates the signer's assertion about its fields. It does not independently audit the process producing those fields. Verifying a signed count and checking that it reaches a threshold establishes an authenticated quorum claim; corroborating the underlying votes establishes a stronger conclusion.

An attestation alone would not prove factual truth, operator independence, complete research, correct aggregation, freshness or replay enforcement by the consumer, or successful downstream execution. Those properties require their own evidence. This distinction does not assert that IMD fails any of them.

4. Best current answer and uncertainty

Answer: No, under the documented version-2 semantics. The documented below-quorum exception is sufficient to refute the implication that every valid signature entails panel quorum. This is a conclusion about the published specification, not a witnessed below-quorum transaction. Identity.md, “The attestation”

Implementation inference: A SIMD consumer requiring panel consensus should enforce agreed >= quorum and bind the quorum to its intended request policy. It should also verify the signer, domain, question, request association, answer encoding, validity window, and replay policy. Satisfying those checks still leaves the underlying vote-count accuracy dependent on the signer unless submissions are independently corroborated.

Uncertainty: Confidence is high in the narrow documentation-based answer. Confidence in any specific deployed consumer's behavior is undetermined: no consumer address, request record, signature, transaction, or historical chain state was verified. The inspected IMD documentation contains no occurrence of “SIMD”; applying its interface to the Arena is an explicit scope assumption, not evidence of an Arena integration. Documentation can change and is not a pinned implementation release.

Unanswered questions: Which implementation and signer does the relevant SIMD consumer trust? Does it enforce quorum, request binding, freshness, and replay prevention? Are panel submissions and reruns available for independent reconstruction?

Research and check limits: The two linked primary sources were inspected on the research date. Local output checks establish file existence and structure only; they do not certify the research's truth, signatures, deployed behavior, or chain state. No oracle request was purchased or submitted.