> What registration puts into chain state, what a registration request contains, and — unhedged — everything that is not self-service today: admission is a conversation. index — 12 documents 1. [overviewsdk/00](/en/sdk) 2. [getting startedsdk/01](/en/sdk/getting-started) 3. [python sdksdk/02](/en/sdk/python) 4. [service modesdk/03](/en/sdk/service-mode) 5. [typescript clientsdk/04](/en/sdk/typescript-client) 6. [mcp serversdk/mcp](/en/sdk/mcp-server) 7. [conformancesdk/05](/en/sdk/conformance) 8. [reason codessdk/06](/en/sdk/reason-codes) 9. [substrate readssdk/07](/en/sdk/substrate-reads) 10. [credentials & holderssdk/08](/en/sdk/credentials-and-holders) 11. [payment identitysdk/09](/en/sdk/payment-identity-profile) 12. [becoming a verifiersdk/10](/en/sdk/becoming-a-verifier) * [what registration is for](#purpose) * [the request](#request) * [two paths](#two-paths) * [not self-service today](#not-self-service) * [the issuer path](#issuer-path) * [related parties](#disclosure) * [what it does not do](#limits) 13. [protocol statesdk/11](/en/sdk/protocol-state) 14. [record · assurance vocabularyrecord/01](/en/sdk/kyc-trust-model) 15. [record · packagingrecord/02](/en/sdk/packaging) 16. [record · multi-languagerecord/03](/en/sdk/multi-language-clients) 17. [record · service contractrecord/04](/en/sdk/verifier-service-contract) SDK docs · sdk/10 # Becoming a verifier What registration puts into chain state, what a registration request contains, and — unhedged — everything that is not self-service today: admission is a conversation. ## What registration is for Installing the SDK does not make you a verifier. Registration does — and registration today is not a form you complete on your own. This page says what it involves, then exactly what is still a conversation with a human. 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](/en/sdk/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 a typing hand: 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. ## What is not self-service today This is the honest part of the page. Every item below is true of the running deployment as of this writing. * **You need an account on a chain with no faucet.** 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 module authority and executed when they pass. 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. The honest summary: **today, admission is a conversation.** The pieces that would make it self-service are named and scheduled, not shipped. If you are planning to onboard programmatically this quarter, plan again — and [talk to us](/en/contact) first. ## 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, stewarded by the MintID Foundation and operated under it by 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. ## What this does not do Registration makes you _addressable_ and _checkable_. It does not vouch for you: nobody has audited your verification stack, policy or data handling, and a registry record is not a certification. Next: [getting started](/en/sdk/getting-started) — the obligations that follow admission; [substrate reads](/en/sdk/substrate-reads) — reading your own record with proofs; and [protocol state](/en/sdk/protocol-state) — what is stable, draft and absent. [previous← payment identity](/en/sdk/payment-identity-profile)[nextprotocol state →](/en/sdk/protocol-state) --- Source: https://mintid.net/en/sdk/becoming-a-verifier · Becoming a verifier — MintID verifier SDK docs