EigenSelect

Verification

Verify a transaction

Every EigenSelect selection publishes its evidence to two independent channels before and after physical execution. Neither channel belongs to the web server that showed you this page, and neither requires an account, an API key, or our cooperation to query.

1 · The commitment chain

Before the quantum processor is contacted, every parameter of your selection is fixed in a commitment manifest and its SHA‑256 digest is published. After resolution, a second record documents the outcome. The records bracket the physical event: what was promised, then what was measured.

Pre-commitment pre.<transaction>.eigenselect.eu — published before the QPU job is submitted. Covers the canonical outcome list, the state→outcome mapping, the transpiled circuit, the backend identity, the shot count (1), and the rejection policy — each by hash, all bound into one manifest digest.
Post-resolution post.<transaction>.eigenselect.eu — published on resolution. Covers every physical attempt in order (including rejected measurements), the accepted bitstring, and the resolved outcome.
Multi-draw Structured draws carry one record pair per pick: pre.2.<transaction>.eigenselect.eu for the second pick, and so on. Each pick is committed and resolved independently.

2 · Check the DNS records

Using any terminal:

dig TXT pre.a7f3e9c2.eigenselect.eu +short
dig TXT post.a7f3e9c2.eigenselect.eu +short

Substitute your transaction ID (it is on your report and in your delivery email). A pre-commitment record looks like this:

"v=es1 t=pre h=sha256:9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 n=9 d=1/1 ts=2026-07-15T14:30:00Z"

The digest h is reproduced in full in your report, together with the manifest it commits to, so you can recompute it yourself. The zone is served by two authoritative nameservers we operate — ns1.eigenselect.com (Amsterdam) and ns2.eigenselect.com (Warsaw) — and is DNSSEC-signed, chained to the .eu registry.

Both nameservers are reachable over IPv6 only, as a matter of documented policy (Infrastructure Transparency). If your network has no IPv6 path, query through a dual-stack public resolver — for example dig @8.8.8.8 TXT pre.<transaction>.eigenselect.eu +short — which reaches them on your behalf.

3 · Check the Nostr events

The same one-line records are published as signed, non-replaceable events (kind 1) on public Nostr relays, creating a second, independently operated evidence channel. Events are signed by the EigenSelect publication key:

public key (hex): 6d6f58ca01f899ce9a3ef37802db4af4aa5b9d9f489b0b0aeecefe4b009eeab3
relays:           wss://nos.lol · wss://relay.damus.io · wss://relay.primal.net

Any Nostr client can retrieve the event by the event ID printed in your report. The event content is byte-identical to the DNS TXT record — two channels, one commitment.

4 · What verification demonstrates

EigenSelect can demonstrate:

  1. A specific canonical selection manifest produced a specific digest.
  2. That digest was published through the configured channels before the recorded QPU job was submitted.
  3. The provider returned a recorded measurement associated with that job.
  4. The reported outcome follows deterministically from the committed mapping and the accepted measurement.
  5. Rejected measurements, retries, and terminal failures are included in the report.

EigenSelect cannot independently demonstrate:

  1. That the provider's backend metadata is truthful.
  2. That the provider's reported measurement originated from the stated physical device.
  3. That the physical output distribution was perfectly uniform.
  4. That public Nostr relays will retain an event indefinitely.
  5. That a DNS record's internal timestamp independently establishes when it was first published.
  6. That the selection satisfies any legal, regulatory, contractual, or procedural requirement.
  7. That the nameservers' IPv4 reachability reflects the operator's preference — both are dual-stack as a concession to the .eu registry's delegation requirements, a matter documented at length on the transparency page.

Additionally: DNS records are mutable by us, and we hold the DNSSEC signing keys — DNSSEC protects the records against third-party tampering in transit, not against their operator. The value of the commitment chain is external observability at the time of the event, not permanent immutability. Your report states all of this in its technical appendix, because a verification chain that overstates itself is not a verification chain.