Becoming a verifier

What registration is for

Installing the SDK does not make you a verifier. Registration does. On the public testnet you can complete it on your own, with one transaction paid from a faucet grant; on the single-node production chain the MintID Foundation admits you under a published policy, with checks, a turnaround and an appeal, and the chain’s operator executes its decision. This page says what registration involves, how to self-register on the testnet step by step, how admission on the single-node production chain works, then exactly what is still not self-service.

Your verifier record puts three things into chain state that anyone can read with proofs: who you are, the exact origins you present from, and the public key that signs your challenges.

That is what lets a holder decide whether to answer you. A challenge arrives claiming an origin, a verifier id and a request key; the holder — and your own SDK, on every decision — resolves those against proven registry state. The holder answers only a challenge whose signature verifies under the registered key the request names, with your record and that key both active (the challenge signature): a challenge your service did not sign gets no proof. Origins are exact: one scheme and host, no path, no wildcards, one verifier per origin. A lookalike domain cannot borrow your reputation, and an unregistered origin of yours is just as dead.

Three obligations then stay live, each with its own rejection in the reason codes: keep the record active (verifier_not_active), revalidate each origin before its window lapses (revalidation_expired), and keep the key that signs your challenges registered (request_key_not_active).

What a registration request contains

One file of public material only — you generate the request-signing key where you keep it, and the private half never enters the file.

A self-registration request differs in three places: its id_hex is not chosen but derived from the origin by the chain (one origin, one verifier, forever); its domain-control digest must be the digest of the evidence document you actually publish at that origin, never a placeholder; and it carries no revalidation window, because the chain stamps the governed one.

The identity check on you

A verifier is an identified actor: the request names the issuer that identified the natural person responsible for the verifier, and carries that issuer’s signed commitment to the check. The procedure:

1. The responsible person completes a KYC session at an issuer that is active in the registry. It is the issuer’s ordinary identity verification, the one a seller or an agent’s principal goes through. A business is identified through that person, together with the company they declare to act for; the company itself is not verified.
2. The issuer returns a signed commitment. For the approved session and your exact origin, the issuer answers the commitment, its own issuer id, the origin, the assurance grade, the approval time and the end of the session’s reuse window, signed with Ed25519 by the issuer’s registered status key over the other six values. Anyone holding that public key checks it offline.
3. The registration request carries it: kyc_issuer_id_hex is the issuer’s id and kyc_attestation_commitment_hex the commitment, for the exact origin the commitment names.

The grade floor is A2: an identity document plus biometric liveness and face match. The issuer refuses a commitment for a session below it. The floor is the issuer’s published policy.

Validity and renewal. The commitment lasts what the KYC session lasts: its reuse window, counted from the approval, 12 months at A2 (6 at A3, 3 at A4). Past it the issuer refuses a commitment from that session, and a new one comes from a re-verification session. A pending, rejected, expired or withdrawn session is refused. Asking again with the same session and origin returns the same commitment.

What it reveals. The commitment is a digest over the person’s verification at the issuer, the origin and the approval time. It names nobody, and only the issuer can relate it to a session: the issuer keeps that relation in its own records, never on chain and never in a public read, and deletes it with the session’s data at the end of its published retention period. The chain stores the digest; it checks neither the signature nor the grade, because block execution never calls an issuer. The MintID Foundation checks both before it admits you, on either tier.

Checked before it is written. Neither the admission tool nor the onboarding portal takes the commitment on trust. You bring the issuer’s answer as it came, and both check it before they write anything: the issuer’s signature under its key in the registry, your exact origin, and a grade at or above the floor (A2). A request that fails a check is refused, and the refusal says why.

Two paths to that file

A form. An onboarding portal builds the request from a web form, with stricter validation than hand-editing the file: exact origin, key sizes, grade ordering, account checksum. It then shows what the registry actually says about your id — absent, pending, active — read with proofs through the same chain client a verifier uses. It never holds a private key, never signs and never votes: you paste public keys, and the operator downloads the file, reviews it and runs the admission.

A command-line tool. The same file and fields, produced by the admission tool that ships with the chain sources. It also writes your domain-control evidence document from the request’s own fields and commits its digest. It does not talk to the chain either; it writes files.

No verifier is admitted on production with a placeholder for the identity check. The onboarding portal never writes one, and the MintID Foundation checks the issuer’s commitment before it admits a verifier, on either tier.

On the single-node production chain both end in the same place: you hand the file over with the rest of your request, and what happens next follows the admission policy.

Domain-control evidence

Your origin binding commits a digest of a document you publish at that origin. The chain stores the digest and never fetches anything; anybody else can fetch the document and check it. The format is versioned, Verifier domain-control evidence v1, and stated here in full.

The document. One JSON object, served at exactly https://<your origin>/.well-known/mintid-verifier:

No other member is allowed. Everything in it is public: no private key, no secret, nothing about the identity check on you.

The digest. SHA-256 over the RFC 8785 canonical form of the document, in lowercase hex: the canonicalization rule the protocol uses for every JSON object it hashes. You may serve any JSON spelling of it; the admission tool writes the canonical form, so the file it writes is the file to serve and its plain SHA-256 is the digest.

The DNS alternative. If you cannot serve a file at the origin, publish the same digest as a TXT record at _mintid-verifier.<your host> with the value v=1; digest=<the digest>. The document still defines what the digest stands for; the record only lets a checker find the digest. The file is the primary form.

The check. The verifier SDK checks either form against the digest the chain holds for your binding and answers with one closed reason: ok, malformed, version_unsupported, unknown_field, origin_mismatch (a copy of your document served from a lookalike origin) or digest_mismatch (a document the chain has not committed). It follows no redirect: the document lives at the exact origin or nowhere.

check_domain_control(origin, digest, document_bytes) is the same check over bytes you fetched yourself, and check_domain_control_dns the TXT form over a resolver you supply. The checker is in the verifier SDK from the release after 0.5.1; until then, install the SDK from the source tree.

Self-registration: the permissionless tier

A second tier lets a verifier submit its own registration, programmatically, with no proposal: the permissionless tier is self-submitted with a MintID Foundation admission grant. You sign one transaction with your own operator key. When it executes, the chain checks the request, burns the admission fee from your operator account and writes your record as active — immediately. The record says which way it came in: the registry marks it permissionless, next to the admitted records that went through the authority. Both tiers carry the same identity check on you; they differ in who submits the registration and in the fee.

The admission grant. The MintID Foundation admits you under its published policy once it has checked the identity commitment on you, your business-register entry and your domain-control evidence, and it signs an admission grant over your origin, your request key, your operator account, the issuer’s commitment and the tier. Your registration carries the grant, and the chain refuses a self-registration or a self-renewal without a valid one. The grant is a signed statement: the Foundation never holds your keys or your accounts. Status: the grant arrives with a chain change that is not yet deployed. Until it lands, the commands on this page are valid as written, without a grant, and on the single-node production chain the Foundation’s decision is executed by the operator’s funding of your account (below). The public testnet will carry its own admission key, which grants automatically for sandbox identities, so the path stays the same there and still identifies nobody.

What it costs. One governed admission fee in the network’s native denomination, burned — not paid to anyone. It is the tier’s only cost: no bond, no stake. Anyone can read the current amount from the chain before submitting; the fee you sign must be in exactly that denomination and at least that amount, and whatever you sign is burned. On the single-node production chain described here the denomination carries no value. The amount on a public network is an open economics decision. The fee is a rate limit; the identity check is the admission.

What you still need. A funded operator account (the fee plus gas); an identity check on you by an issuer that is active in the registry, and its commitment, carried in the request exactly as on the admitted path; an exact origin that no other verifier holds; and the digest of the domain-control evidence document you publish at that origin.

What nobody checks for you. The chain stores the digest of your domain-control evidence and cannot fetch it — block execution never touches the network. The MintID Foundation checks that evidence before it admits you, on either tier; the chain itself does not. Relying parties are expected to check it themselves, with the published format and the SDK’s checker.

What the Foundation can still do. Everything it can do to any verifier, through the registry’s authority: put you under enhanced monitoring, suspend you, reinstate you, revoke you. Self-registration removes the proposal, not the authority over the record. A revoked origin is not freed for someone else.

Why an identity check and not only a fee. A holder answers you only after resolving your origin, key and state from proven registry state, and a registration grants no reach over anyone’s data. But a verifier is the party a holder proves something to, so every verifier, on either tier, has a responsible person behind it whom an accepted issuer has identified. The fee only limits the rate of registrations.

Where it runs. Self-registration and the self-service renewal below are on chain. On the public testnet anyone can use them, paying from a faucet grant: the testnet path below is the whole path. The single-node production chain runs the same tier, but it has no faucet: once the MintID Foundation has admitted you under the admission policy, the chain’s operator funds your account with exactly the fee and the gas. Production is never a place to test; admitted verifiers run there under the published policy.

Where to test

Status: live. The public testnet and its KYC sandbox states whether it is live, its limits and its terms.

Test on the public testnet, with its KYC sandbox; the single-node production chain is never a place to test. A public adversarial testnet with independent participants will run before any mainnet.

The public testnet is the only MintID deployment a third party may use to test. It runs the same software and the same chain parameters as the single-node production chain, on its own chain, with its own keys and hostnames. Its issuer verifies nobody: when you open a KYC session you choose its outcome, so every path of issuance and every error a verifier can meet is reachable on purpose: an approval at the grade you choose, a refusal, an expiry, a manual review, an unavailable provider, a reuse window that has closed. Its sandbox verifier answers challenges and validates presentations, and the testnet runs holder self-revocation and the privacy relay as production does.

Nothing issued on the testnet carries weight: a credential, a grade, an agent or a decision obtained there says nothing about any person and must never be accepted anywhere else. It has one validator, run by the operator of the single-node production chain; it runs on its own test token, free to anyone from an open faucet, which has no value and converts into nothing; and it is reset when the software changes shape, with everything issued before gone.

A verifier of your own can self-register on the testnet in the permissionless tier, paying its registration and renewal from a faucet grant; the admitted tier, which production offers on request, has no path there. The public journey uses the sandbox verifier. To hold every key yourself, the local stack of the main repository runs every service on your own machine.

The single-node production chain answers three public read endpoints — the chain’s status, the issuer’s build information and the verifier’s status and build information — so anyone can check that blocks are produced, which proof engine the verifier is pinned to and whether the issuer’s root is fresh. They are evidence, not a place to test. Accepting real presentations there requires a registered verifier, admitted under the published admission policy: production is never a place to test; admitted verifiers run there under the published policy.

Self-registration on the public testnet, step by step

Everything below runs from a clone of the main project, with Go (the version the chain sources name) and Python 3.12 or later. Nothing in it needs an operator, a password or a proposal. Check the testnet’s status on its page first. The testnet’s endpoints come from the network profile the packages carry; that page says how to select it.

1. Build the chain’s command-line client and point it at the testnet. Read the chain identifier and the testnet issuer’s id from the verifier’s status read: they change at every reset, so read them, do not copy them. A query over the public RPC can hang; give each one a timeout of your own and retry.
2. An operator account, funded from the faucet. A test keyring that keeps the key unencrypted on disk is good enough for valueless testnet tokens, never for anything else. The faucet answers with the grant’s transaction hash; one grant covers a hundred registrations or renewals. Its limits and terms are on the testnet page.
3. Read the fees. The self-registration fee and the self-renewal fee are governed chain parameters; the fee you sign must be in exactly that denomination and at least that amount, and all of it is burned. The testnet charges no gas price: the fee is the whole cost.
4. The four values the record commits.
   • Your request-signing key (Ed25519). The private half signs your challenges and stays with you (an HSM or a KMS outside the testnet); the chain records the 32-byte public half. The snippet beside this section generates one.
   • Your origin: one exact https:// origin, scheme and host only, that no other verifier holds. It is yours for good: a registered origin is never freed.
   • The digest of your domain-control evidence: the evidence document you serve at <origin>/.well-known/mintid-verifier. The admission tool writes it from your origin, "derived" (the permissionless tier), your request key and your operator account, and prints its digest; the chain stores that digest and cannot fetch the document.
   • The identity check on you: the request names an active issuer and its commitment to the check (the procedure). The testnet’s sandbox issuer gives the same commitment as any issuer, open to anyone in its sandbox journey: open a sandbox KYC session that ends approved, complete it, and ask for the commitment for your origin (the issuer’s routes are in its integration guide, given on request: see the testnet page). Nobody is identified: a sandbox approval carries no weight, and neither does its commitment. Its issuer id is the one you read in step 1.
   Serve the evidence file as it is at <origin>/.well-known/mintid-verifier (or publish the TXT record), then check that the SHA-256 of what the origin serves is the digest you are about to commit. Anything else, fix it before you register: the digest is what every relying party will check your origin against. This quick check holds because you serve the canonical bytes the tool wrote; the SDK’s checker (above) is the full check, which accepts any JSON spelling and names what is wrong.
5. Register. One transaction, signed by your operator key; the record is active as soon as it executes. It carries, in order: the display name, the origin, the evidence digest, the request key, the issuer, the identity-check digest and the fee (the amount of step 3, in utestmint).
6. Read your record back. The chain derived your verifier id from the origin and your key id from the key; your service takes both in hex. Expect an active record on the permissionless tier, and the evidence digest you committed: it is the digest a relying party checks your origin against.
7. Run your verifier service with that identity, as in service mode: your origin and the two ids above; chain state read from the testnet’s RPC, and headers anchored on a node you trust, which must be your own node, never an RPC provider you do not control, the testnet operator’s included (on the testnet your node joins through the published sentry); the testnet issuer as the source of its credential definitions, so it can verify that issuer’s presentations; and a signer, an object with one method, sign(canonical_body: bytes) -> bytes, that signs with your request key. Your challenges are then signed and bound to your origin, and your decision log is yours.
8. Renew before the window closes. The origin binding expires at the end of its revalidation window (the governed window, 180 days on the testnet). Renew it with a fresh evidence document and the renewal fee; the window restarts from the renewal. Issue the new document, serve it in place of the old one and commit its digest in the same step (between the two, a check reads digest_mismatch).

A testnet reset erases the record with everything else: register again on the new chain.

Admission on the single-node production chain

On the single-node production chain the MintID Foundation admits third-party verifiers under a published policy (of 28 October 2026, as amended on 2 November 2026), and the chain’s operator executes its decisions. Every decision is recorded as decided by the MintID Foundation and executed by the operator. Production is never a place to test; admitted verifiers run there under this policy. Rehearse the whole path on the public testnet first, and come to production with the service you intend to run.

Two paths, one set of checks. The default is the permissionless tier: after the checks pass and the Foundation admits you, the chain’s operator funds your operator account with exactly the admission fee and the gas of the one transaction, and you register yourself. The admitted tier is available on request only, for a verifier that needs its record to show that the authority checked its evidence: the same checks, then two governance proposals instead of your transaction. Admission costs you nothing either way: the fee you burn is funded by the operator, and the denomination carries no value on this chain.

When the admission grant arrives. A chain change, not yet deployed, makes the Foundation’s admission grant the control on chain: your registration will carry the grant, and the chain will refuse it without one. Until it lands the steps below are valid as written, and the operator’s funding (or the two proposals) is how the Foundation’s decision is executed. The change will be announced on this page and in the admissions log.

Who is eligible

All four, checked by the MintID Foundation before anything is funded or proposed:

1. A registered business: an entry in a public business register (a company or a registered sole trader). The Foundation looks the entry up; that is a lookup, not a verification of the company. The company itself is not verified: your responsible person declares that they act for it.
2. Its responsible natural person, identified at grade A2 or above, through the identity check on you: an approved KYC session at an issuer active in the registry, and that issuer’s commitment for your exact origin, inside its validity.
3. Domain-control evidence that checks: your origin serves the evidence document whose digest your request commits (or the DNS record), and the SDK’s checker answers ok.
4. A signed acceptance of the verifier obligations, signed by the responsible person:
   • revalidate every origin before its window lapses, with fresh evidence;
   • keep the private half of your request key in your custody (or in the KMS of an operator that runs your service for you, under the conditions for operated deployments in the overview), and rotate it with your operator account on any suspected compromise;
   • hold your operator account on your own side, and report its compromise at once: no message replaces it;
   • keep the decision log your service writes, with its signed daily heads, for the retention period your acceptance states; it is yours and is never published;
   • log nothing the protocol forbids a verifier to keep: no presentation, no proof bytes, no claim value, no pseudonym outside the recognition store, in any application, access or infrastructure log;
   • if someone else operates your service, name that operator in your deployment’s published record;
   • accept the suspension, revocation and appeal rules below.

The steps

The steps run from a clone of the main project, as on the testnet, with the production network profile in place of the testnet’s; the fee is read from the chain’s parameters as on the testnet.

1. Your operator account and your request key, on your side. The operator account must live in a keyring that encrypts it, never an unencrypted test keyring; it signs your registration, your renewals and your key rotations for the life of the record. The request key is generated where it will live, as in step 4 of the testnet path.
2. The identity check on your responsible person. Ask the operator for it through ZadQ, the operator’s commercial channel: requests reach the operator, which receives them and executes; the MintID Foundation decides. On this chain the commitment is asked for by the operator: the issuer’s operator opens the KYC session, your responsible person completes it, and the operator asks the issuer for the commitment for your origin and hands you its answer. Keep that answer as it came; its issuer id and its commitment go into your request.
3. Your evidence document and your request file. One command of the admission tool writes both, the evidence document from the request’s own fields; serve the evidence document at <origin>/.well-known/mintid-verifier and check it as on the testnet. The same command checks the issuer’s answer as it came (the issuer’s signature under its key in the registry, your exact origin, a grade at or above the floor, A2) and refuses with its reason rather than write a request that would be refused; it never writes a placeholder. For the admitted tier, the request carries no tier and no fee, no transaction is written, and you may give a verifier id of your choosing.
4. Send the request through ZadQ (every request reaches the operator through its commercial channel; the operator receives and executes, the MintID Foundation decides): the request file, the commitment as it came, the signed acceptance, your business register entry (the register, the name and the number), the responsible person’s name and a contact address, and whether you ask for the admitted tier. Everything but the request file and the commitment stays with the operator, off chain and out of the admissions log.
5. The checks and the answer, within five working days (Monday to Friday) of receipt. The Foundation checks the register entry, the commitment (approved, grade A2 or above, inside its window, for your exact origin), the evidence served at your origin against the digest in your request, that nobody holds your origin, and the signed acceptance. A request that meets the policy is admitted; one that does not is refused with a reason code. The answer is one of three: the admission, executed by the operator as the funding transaction (permissionless) or the passed proposals (admitted); a written refusal with its reason code; or the list of what is missing, in which case the five days restart when it arrives.
6. The funding. On the permissionless tier the operator sends your operator account exactly the fee read from the chain plus the gas of one transaction at the chain’s minimum gas price, which is zero today: the grant equals the fee. The answer gives you the funding transaction’s hash, and you can read the balance from the chain.
7. Register. One transaction, signed by your operator key, with exactly the fee you were granted. Its arguments are the testnet’s, taken from your request file. A transaction the chain refuses leaves no state and burns nothing: fix it and send it again with the same grant. Read your record back as in step 6 of the testnet path. On the admitted tier there is no transaction of yours: the operator runs the two proposals and, if your operator account does not exist on chain yet, sends it one base unit so that it can later sign your own key rotations.
8. The log entry. The admission is recorded in the public verifier admissions log as decided by the MintID Foundation and executed by the operator: your operator account, your origin, your display name, the operator of your service if it is not you, the release production runs, and the transaction hashes. Nothing about your responsible person or your company beyond the display name.
9. Renewals. Send the renewal request at least five working days before your origin’s revalidation window ends, with the fresh evidence document you will serve. The Foundation checks that your record is not suspended and that your identity check is current, the operator funds exactly the renewal fee plus gas, and you serve the new document and commit it in one step, as in step 8 of the testnet path. On the admitted tier the renewal is a proposal of the operator’s. An origin that lapses unrenewed is suspended on the next working day.
10. The identity check over time. Your record keeps the commitment of its first admission: no message on the chain updates it yet (an authority message for it arrives with the admission-grant chain change). Before the responsible person’s session leaves its reuse window (12 months at A2, 6 at A3, 3 at A4), that person completes the issuer’s renewal session and the operator logs the new commitment (date, commitment, issuer id) in the admissions log; the operator renews no origin of a verifier whose last logged commitment has expired. A new responsible person completes a fresh KYC session of their own, never the predecessor’s renewal session, signs the acceptance again, and the hand-over is logged the same way. The record, the origin and the verifier id do not change.

Suspension, revocation and appeal

Who decides. The MintID Foundation decides every admission and every change of state under the published policy, and the chain’s operator executes it: until the compliance council (the Foundation’s organ) is seated, as a governance proposal of the registry’s authority, whose single voter is the validator key of the chain’s operator, a related party of MintID (below), or as the operator’s funding on the permissionless tier. The policy leaves nothing to discretion: a request that meets it is admitted, one that does not is refused with a reason code. A decision that concerns a related party is taken under the same policy and marked “related party” in the log. There is no independent review until an independent reviewer or the council is seated, and this page says so.

When. The Foundation acts on these causes and on no other:

Reinstatement follows when the cause is fixed. A suspended record cannot renew its own origin, so a lapsed and suspended record is renewed and reinstated together by one proposal of the operator’s.

Revocation is final, and a revoked origin is never freed, for you or for anyone. The Foundation revokes only at your request, on a court order that requires it, or after a suspension whose cause you have not fixed, and never before an appeal against that suspension has been answered. A compromised operator account cannot be fixed: you continue under a new origin and a new record.

Appeal. A refusal, a suspension or a revocation can be appealed in writing, through the same channel, at any time. The answer comes in writing within five working days, upheld or reversed, with its reasons and what would change it, and it is recorded in the log; a reversal is carried out within the same five days. Until an independent reviewer or the council is seated, the appeal is answered by the Foundation under the same policy.

Every decision is notified to the contact in your request and recorded in the admissions log.

What is not self-service today

This is the honest part of the page. Every item below is true of the deployments as of this writing.

• On the single-node production chain, your account is funded by its operator, under the published policy. Production has no faucet: your operator account receives exactly the fee and the gas, after the checks above, from the chain’s operator. That funding executes the MintID Foundation’s admission; it is not a service you call. When the admission grant reaches the chain, the grant becomes the control. On the public testnet the faucet does it.
• The admitted tier is two governance proposals, on request only. Their messages are signed by the registry’s module authority and executed when they pass; on the deployment described here there is exactly one voter. The public testnet has no admitted path at all.
• Decisions are the MintID Foundation’s, executed by the operator. Admission, suspension, revocation and appeal follow the published policy above, with a five-working-day turnaround; the Foundation takes them and answers the appeals until an independent reviewer or the council is seated.
• The form is not open either. The portal sits behind a single shared credential handed out of band. You cannot reach it without asking.
• On the single-node production chain, the identity check on you goes through the issuer’s operator. There, the KYC session is opened, and the commitment asked for, by the issuer’s operator or an operator application it serves, on request. The grade floor (A2) is the issuer’s published policy, not a chain rule: the chain does not check it; the Foundation does, before it admits you. Only an issuer active in the registry can perform the check, and on the deployment described here that is the operator’s own issuer: no third party has yet been admitted as an issuer. On the public testnet the sandbox issuer gives the commitment to anyone, and nobody is identified.
• The chain keeps your first identity check only. No message updates a verifier’s commitment after registration yet (the authority message for it arrives with the admission-grant chain change), so renewals of the check and a new responsible person are recorded in the public admissions log, not in your record.
• On the permissionless tier, nobody on chain checks your evidence. On the single-node production chain the Foundation checks it before it admits you and at each renewal; relying parties check it whenever they choose.
• There is no published fee on a public network for either tier.
• Admitted origins renew through the operator of the deployment; self-registered origins renew themselves, with the renewal fee the operator funds on production and the faucet on the testnet.

The honest summary: on the single-node production chain, admission is a published procedure: the MintID Foundation decides, the chain’s operator executes: checks, a funded fee or two proposals, five working days, a public log and a written appeal. On the public testnet, self-registration is self-service end to end; the identity check on you runs against the sandbox issuer and identifies nobody, and your domain-control evidence is checked by the relying parties that choose to check it, not by the chain.

The issuer path, briefly

An issuer registers through the same mechanism, with two differences. First, it declares the assurance grades it may issue, and that set becomes registry state — an issuer cannot grade above its admission. Second, activation is bond-gated: the operator account locks a bond at or above the governed minimum with its own key, and every transition into the active state re-checks that the bond is live. An issuer also registers two keys that may never be the same: the one that signs its status roots, and a separately scoped emergency key that can publish a root on its own. Everything in the section above applies to issuers too — and no third party has yet been admitted as an issuer here.

Related-party disclosure

The chain described here is the single-node production chain operated by Conectia OÜ (Estonia, registry code 16847069), trading as Conectia PRO. Conectia, and the issuer and verifier admitted on that chain, are related parties of MintID, and the single voter on every admission proposal is that operator’s validator key. The MintID Foundation’s decisions that concern Conectia or ZadQ follow the same published policy and are marked “related party” in the admissions log. Any adoption figure derived from this deployment is a related-party pilot, not independent adoption.

What registration attests

Registration makes you addressable and checkable, and that is all it attests: no one has reviewed your verification stack, policy or data handling, and a registry record certifies none of them. The Foundation’s admission says that the published checks passed; the Foundation certifies nothing.

Next: getting started — the obligations that follow admission; the verifier admissions log — every decision under the policy above; reason codes — how a lapsed origin or key reads at decision time; substrate reads — reading your own record with proofs; and protocol state — what is stable, draft and absent.