Becoming a verifier
Registration puts your identity, exact origins and signing key on chain. Today an operator admits you, and every step still done by hand is listed below.
What registration is for
Registration is what makes you a verifier, and today an operator admits you: no form completes it on your own. Below is what registration puts on chain, what the request contains, and each step that still goes through a person.
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. 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.
| Field | Meaning |
|---|---|
kind | verifier |
id_hex | your 32-byte verifier id, fixed for the life of the record |
public_display_name | the name the registry shows |
operator_account | the chain account that operates the record and pays its fees |
policy_version | the registry policy version the request is made under |
kyc_issuer_id_hex | the issuer that performed the identity check on you as a verifier |
kyc_attestation_commitment_hex | a digest standing for that check (see below — a labelled placeholder today) |
request_key_pub_hex | the public key that will sign your challenges |
origin | one exact HTTPS origin, validated on the spot |
domain_control_proof_hash_hex | a digest of your domain-control evidence (see below) |
revalidation_days | the origin binding’s validity window before renewal (default 180) |
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, fields and placeholders, produced by the admission tool that ships with the chain sources. It does not talk to the chain either; it writes a file.
Both paths end in the same place: you hand the file over, and what happens next is not in your hands.
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 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 uses, 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 by governance proposal until self-service registration reaches that chain; it starts as a conversation through the contact page.
Still manual today
Every item below is true, as of this writing, of the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group.
- You need a funded account on the production chain. Your operator account must exist and hold enough to pay its way before anything is submitted, and there is no self-service funding path: someone must fund it for you. Today that someone is the chain’s operator, out of band.
- Admission is a governance proposal. Registering and then activating your record are two proposals, whose messages are signed by the registry’s governance authority and executed when the proposal passes. On the deployment described here there is exactly one voter. A human decision gates you, and it is not automated.
- The form is not open either. The portal sits behind a single shared credential handed out of band. You cannot reach it without asking.
- The identity check on you as a verifier has no published process. The request names the issuer that performed it and commits a digest of it. There is no published procedure, criteria or turnaround, and in requests produced today that digest is a labelled placeholder.
- The domain-control evidence has no published format. No challenge string, no well-known path, no DNS record name, no automated checker. The field takes the digest of a file you supply and nothing inspects what that file is. Renewal exists as an expiry date on the binding; what it revalidates is procedure, not protocol.
- There is no published eligibility policy, fee, service level or appeal. Nothing states who may register, what it costs, how long it takes, or what happens if you are refused.
- The self-registering tier is designed, not built. A second verifier tier — operator-signed self-registration with an exact origin and a domain-control proof, an admission fee, and a governance power to suspend afterwards — is decided and scheduled. It exists on no running chain, and you cannot use it.
Today, admission is a conversation. The pieces that would make it self-service are named and scheduled, and none has shipped yet; if your plan needs programmatic onboarding this quarter, talk to us before you commit to it.
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, in production since 20 September 2026 and operated by the CONECTIA group through Conectia PRO. Conectia PRO, 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. Any adoption figure derived from this deployment is a related-party pilot, not independent adoption. The first issuer and the first verifier were admitted through the same path the protocol offers anyone: a governance proposal, today voted by the chain’s single validator and, once the compliance council is seated, by the council; the same slashable bond; the same 30-second roots; all of it on chain.
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.
Next: getting started — the obligations that follow admission; substrate reads — reading your own record with proofs; and protocol state — what is stable, draft and absent.