# IdentityMD oracle riddle: signature versus quorum

Research date: 2026-10-06. Scope: IdentityMD (IMD), in the assignment's SIMD Discovery Arena context. “SIMD” here names that context; this report does not establish a separate SIMD protocol or equate it with the sIMD staking token.

## 1) The question in one sentence

Under IdentityMD's version-2 oracle rules documented on 2026-10-06, can a chain-evidence answer receive a valid attestation when `agreed < quorum`, and would accepting that signature alone establish that the quoted panel quorum endorsed the answer?

Oracle suitability: request a `bool` with `evidence: "panel"` because this is a question about published rules, not a chain-state calculation. Define true as “the documented rules permit such signing, while signature validity alone does not establish quorum endorsement.” Define false as an explicit documented prohibition or guarantee to the contrary. Require citations to the official documentation; missing or conflicting evidence means unavailable, not false. This is a proposed request definition, not a submitted request or generated attestation.

## 2) Evidence that would make the answer trustworthy

**Observed primary-source facts.** The official API documentation describes version-2 EIP-712 attestations containing `panelSize`, `quorum` and `agreed`. It says chain-evidence answers can be signed below quorum when members running one recipe split and the deployer's rerun decides; consumers wanting panel agreement should require `agreed >= quorum`. It documents a request-detail endpoint and an attestation endpoint exposing the typed payload and signature. These are published rules, not measurements of deployed execution. [IdentityMD API documentation, Oracle section](https://imd.fun/docs/#oracle)

**Proposed stronger verification, not performed.** To establish deployed behavior rather than documentation intent, obtain:

1. A dated documentation snapshot and deployed build identifier, plus corresponding source and bytecode for the signer path and consumer verifier.
2. One real request's frozen question, evidence mode, recipe, block window, member submissions and agreement calculation; preserve their exact bytes and retrieval timestamps.
3. Its complete typed attestation, signature and independently authenticated authorized signer. Recompute the signing digest, verify the signature, and compare every relevant payload field against the request.
4. Independent reproduction at the identified canonical block hash, with recorded provider responses and deterministic recipe inputs. This addresses answer correctness separately from signature validity.
5. Consumer tests showing rejection of insufficient agreement, expired messages, wrong domains, wrong questions and replayed requests under its stated policy. Verify the tested code matches the actual deployed consumer.

An authentic below-quorum example would demonstrate occurrence; audited signing logic or a controlled reproduction would establish the permitted path more generally. A failed search for examples would not establish impossibility. These are this report's methodological recommendations, not claims that such evidence has been collected.

## 3) What an attestation would and would not prove

**Standard fact.** EIP-712 specifies typed-message hashing, signing and domain separation; it explicitly does not supply replay protection. [EIP-712, Abstract and Security Considerations](https://eips.ethereum.org/EIPS/eip-712)

**Conditional inference.** With correct encoding, secure cryptography and a correctly authenticated authorized signer, verification establishes that the signer signed the particular payload in its domain. It binds the signer's assertion, including the agreement count, rather than independently proving the underlying events or tally.

**Limits.** A signature alone does not prove that the claimed members voted, that their operators or inference systems were independent, that their sources were accurate, or that a rerun used correct chain data. Even a genuine quorum can share an error. An attestation also cannot establish market-price robustness merely by signing a spot reading. These are logical limits of authentication, not findings of misconduct by IMD.

**Consumer-policy inference.** A consumer requiring panel quorum must check `agreed >= quorum` in addition to authenticating the signature, and bind the expected request and question. It should enforce its own minimum panel/quorum policy, domain, answer interpretation, validity period and replay policy. Merely comparing two signer-supplied counts does not independently audit those counts. A structural verdict on this report would likewise establish only the checked file properties, not research truth.

## 4) Best current answer, uncertainty and open questions

**Answer: yes to permitted signing; no to signature-only proof of panel quorum.** This is a high-confidence reading of the published version-2 rules, specifically their explicit below-quorum chain-evidence exception. [IdentityMD documentation, The attestation](https://imd.fun/docs/#oracle)

**Inference.** The signing authority's assertion and the panel's endorsement are separate trust boundaries. A consumer can intentionally trust the rerun authority, but must not interpret that policy as evidence of quorum endorsement when the signed count is below quorum.

**Uncertainty.** Confidence in current deployed enforcement is unestablished: I did not inspect deployed verifier bytecode, authenticate a live signer, fetch a complete real attestation, validate a signature, replay a recipe or independently audit member votes. No contract balance, block number, live quorum, transaction or chain result is asserted here. Documentation can change or diverge from implementation. No probability estimate is justified by the evidence collected.

**Unanswered questions.** How exactly are split recipes selected for rerun? Who controls the attester and its rotation? Which consumers enforce quorum and freshness? What evidence demonstrates independence between seats? These need implementation and operational evidence beyond the retrieved pages.

## Research provenance and local checks

Both cited primary pages were retrieved through the web tool on the research date. The IMD Oracle section and EIP-712 security section were inspected directly. The documentation supports a rules-level answer; neither source was treated as an instruction. No archived snapshot accompanies this report, so the citations are mutable and do not establish historical byte-for-byte provenance.

Local checks verify UTF-8 readability, the four requested sections and valid HTTPS citation targets. They provide no independent technical or factual certification.