For validators

The chain a validator would run carries status roots, never names

Validators run the machines that would keep MintID’s public network honest: they run consensus and check deterministic state transitions without ever touching a passport, a biometric or a KYC file, which is issuers’ work. What runs today is the single-node production chain, in production since 20 September 2026 and operated by the CONECTIA group; the validator role below is the design for a public network, if that route is chosen.

What securing MintID would look like

Validation here would be cryptographic and deterministic. There would be no identity to inspect and no discretionary judgement to make about a person, only protocol rules to enforce.

PoS

Proof of stake, bounded set

In the public design, anyone could run a node, bond tokens and register a validator. The active set would be capped at 60 validators at genesis, growing toward 100 by governance once fee-funded security supports it; no validator’s effective voting power may exceed 5%, and unbonding takes 21 days. All three are priors.

⊨

Fast, deterministic finality

MintID is designed for delegated proof of stake on CometBFT through the Cosmos SDK, with a block every two to three seconds and a finality objective of about five seconds under normal conditions; a finalised state is final, with no probabilistic waiting.

∅

Validators see no personal data

A validator would never inspect passports, biometrics, names, addresses or KYC files. KYC is performed entirely by issuers; validators would replicate a deterministic state machine and check cryptographic evidence, nothing else.

◇

Paid for consensus, never for judging people

In the public design, each epoch’s emission would be shared by capped voting power, weighted by signing performance; delegators would share through the standard path and validators would charge a declared commission. No reward is ever paid for “identity work”. Paid off-chain services you choose to run earn their own fees, firewalled from consensus rewards.

⚖

Slashing on objective evidence only

In the design, double-signing is slashed with permanent exclusion and sustained downtime with a temporary jail. There is no slashing for alleged censorship at launch, because attribution would be subjective. Professional topologies (sentry nodes, separated and hardware-backed keys, monitoring, reproducible builds) are expected.

SLA

Bootstrap service agreements

If the public route is chosen, the initial operators would be recruited under fiat or stablecoin service agreements for their first 12 to 24 months, followed by an operator floor programme, funded by the Foundation once it is active, that pays for verifiable service (uptime, topology, monitoring) and never for stake.

⊓

Hard-capped monetary policy

In the public design, supply is capped at exactly 108,000,000 tokens. The reward pool, a prior of 60% of the cap, would be paid out only as validator emission, on a strictly declining curve that exhausts the pool exactly: the prior is 3% of the cap in year one, declining by a factor of 0.95 each year. The cap counts everything ever minted; no mint beyond it is ever possible.

GATE

Security-first launch gate

If the public route is chosen, genesis would wait for published, price-independent thresholds — priors of at least 20% of supply bonded by external parties, at least 25 independent operators and a Nakamoto coefficient of at least 7 — plus a public adversarial testnet and a funded bug bounty, with the audit programme reported as scheduled milestones whose findings are published. Development and Foundation accounts would count toward none of it.

Values marked as priors are working points the team has argued for, inside ranges already agreed; an independent economic simulation, run before any genesis, confirms each one or argues against it.

The numbers that shape the role

Starting values for a public genesis

The values the public network would start from. The first three are priors that the simulation confirms or argues against before genesis; the status-root heartbeat is a consensus rule today.

60 → 100
Active validators: at genesis, then by governance
5%
Cap on any validator’s voting power
21 days
Unbonding period
30 s
Issuer status-root heartbeat, enforced by consensus

Interested in the validator role?

Staking, delegation and slashing would follow standard proof-of-stake mechanics. Issuer bonds, and a separate BTC remediation reserve designed to sit under council and independent-custodian control, are outside the validator role. If you operate infrastructure and want to follow the validator design, talk to us, or read the protocol.