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.

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.

Using any terminal:

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

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 in Amsterdam and ns2.eigenselect.com in Warsaw, and is DNSSEC-signed. The DS record for its key (tag 29820, ECDSA P-256) is published at the .eu registry, so a validating resolver checks the whole chain from the root down to each record.

The h= field in that record is a digest of the commitment manifest: the outcome list, the state mapping, the circuit, the backend, the shot count, and the rejection policy, bound together. The manifest is served in its exact canonical form, so you can hash it and check it against what DNS has been serving since before the processor was contacted.

The manifest commits to the circuit by hash. The circuit that physically ran is served the same way, so that hash is checkable too:

That value appears as circuit.qasm_sha256 inside the manifest you just hashed. The chain closes: the DNS record fixes the manifest, the manifest fixes the circuit, and the circuit is the one the processor executed. No step requires an account, an API key, or our cooperation. Every record for a transaction is collected on its verification page, at /verify/<transaction>.

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:

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.

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 both nameservers are reachable from every resolver. ns2 is IPv6-only since 16 August 2026, so a resolver without IPv6 connectivity reaches ns1 alone. Both nodes serve identical, identically signed records; the matter is documented on the transparency page.

DNS records are also 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.