Do Our Credentials Also Land as Attestations? The Code Says Yes and the Running Process Says No

What dual-emit is supposed to do

Write the same credential twice. Once in our own format, and once as an attestation in a public attestation registry, with the same payload underneath.

The point is reach without integration. A consumer that already reads that registry would see our credentials without adopting anything of ours, which is a genuinely good idea and the reason it was built.

What is built, and it is the whole path

A schema. A defined field layout for the attestation, with a test asserting that a consumer holding only the schema string can decode what we write. That test is the interoperability claim made checkable, which is more than most integration work does.

An encoder, a client and a service. Attestation is idempotent on the stored attestation identifier, so a retry cannot double-write. Revocation has its own path. Every attempt records an anchor event.

Queue and worker wiring, so emission rides the same job machinery as the on-chain anchor.

And it is deployed. The compiled module sits on the production box.

What is running: nothing

The service is gated on one value, the identifier of our schema in that public registry. With it unset, the service logs a warning and returns null for every credential. Nothing is written.

That value is not present in the live process. Read today from the running worker's own environment: the registry address and the schema-registry address are both there, and the schema identifier is not.

CONTROL that makes this an absence rather than a broken lookup: its two siblings are present in the same read. The reader works.

So the answer to the page's question, today, is no. Not for some credentials. For all of them.

The blocker is one step and it is not code

The schema has to be registered once in the public registry, which produces the identifier, which then has to be configured and deployed. The script that does the registration is in the repository.

That is a smaller gap than an unbuilt feature and a bigger one than a typo, and describing it precisely is the difference between "we plan to" and "we are one operation away".

And a live page says the opposite, in the present tense

Our own integrations page states that every credential we issue is also emitted as an attestation with an identical payload, under a schema published to that public registry.

Both halves are unproven today. The emission does not happen, and the missing identifier is direct evidence that the publication step has not reached production either.

This page exists partly to say so, and the contradiction has been filed against the product rather than smoothed over here.

It fails open, quietly, one credential at a time

When the value is unset, issuance still succeeds. The credential is created, anchored and listed. Only the second emission is skipped, with a line in a server log.

Nothing surfaces to the operator. The credential record has a field for the attestation identifier and it simply stays empty, which looks identical to "not yet processed".

A silent skip is the right behaviour for a secondary emission and the wrong behaviour for a capability somebody has been told is automatic. Those two sentences are both true, which is exactly why the copy matters more than the code here.

What we are not going to tell you

No figures for that ecosystem. Our own internal material quotes an attestation count and a chain count for it. We did not verify either and they are not on this page.

And no claim that any consumer sees anything of ours, because nothing has been written for one to see.