Khromosome Validator Operator Application

Public beta (chain 777001). Read OPERATOR-GUIDE.md first, especially §6 (activation), §7 (rewards: none of meaningful value on the testnet today), and §8 (slashing). Send applications to validators@khromosome.network. Never include a mnemonic, keystore, keystore password, or private key in an application.

Selection favours diversity: a hosting provider other than Contabo, a region or jurisdiction outside the US, a different client pair, and operators who are independent of the founder. The first cohort is small, at least 2 operators, with the goal of the founder holding less than 50% of validators before mainnet.

A. Who you are

  1. Operator name as it should appear publicly (a person, a company, or a pseudonym; if a pseudonym, see A3).
  2. Legal entity name and country of incorporation, if any.
  3. Primary contact: name, email, and a messaging handle (Telegram, Signal, or Matrix). Shared privately, never published.
  4. Country of residence of the people who operate the keys.
  5. Do you control, or are you controlled by, any other applicant, or Khromosome / Dunn Global Solutions / Joshua Dunn? (Yes/No, with details.) Operators under common control count as one operator in our decentralization metrics.
  6. Are you, or is any owner of your entity, a sanctioned person, or located in a comprehensively sanctioned jurisdiction? (Yes/No)
  7. Will you consent to an optional OperatorRegistry entry (jurisdiction tag + KYC hash; the KYC documents themselves stay off-chain)? (Yes / No / Later)

B. Experience

  1. Networks you validate or have validated on (mainnet and testnets), with approximate validator counts and how long.
  2. Any slashing, inactivity leak, or major downtime incident you were involved in. What happened, and what did you change afterwards?
  3. Clients you have run in production (EL and CL).
  4. How do you handle key custody and slashing protection today (remote signer, HSM, doppelganger protection, EIP-3076 migrations)?

C. Infrastructure

  1. Hosting: provider (or bare metal / colocation / home), city or region, and country.
  2. Hardware: CPU, RAM, disk type and size, uplink, and monthly transfer limit.
  3. Can you expose TCP+UDP 9000 and TCP+UDP 30303 publicly while keeping RPC, Engine API, and metrics on localhost? (Yes/No)
  4. Proposed client pair: Reth + Lighthouse (the proven pair), or Geth + Prysm / another pair (an unvalidated template; this is planned as a deliberate test).
  5. How many validators do you propose to run? (The first cohort is capped at a number that keeps every operator below 1/3.)
  6. Monitoring and alerting stack, and who is on call.

D. Commitments (OPERATOR-GUIDE §10)

  1. Can you commit to ≥ 99% uptime, 24 hours' notice of planned downtime, client upgrades within 72 hours of a coordinated release, and acknowledging incident pages within 4 hours? (Yes / No, with exceptions.)
  2. Stake and withdrawal arrangement on the testnet (pick one):
    • [ ] Founder-funded 32 KHROME per validator, with withdrawal credentials pointing to a founder-designated address.
    • [ ] Founder-funded under a written delegation, with withdrawal credentials pointing to my own address.
    • [ ] Other (describe).
  3. EVM address for --suggested-fee-recipient, and (optionally) the address you will enrol in ValidatorRewards. Both are public data.
  4. Will you run a node on Khromosome mainnet if and when it launches (after an external audit, Safe + timelock admin, and independent validators)? What would you need, in commercial or legal terms, to commit? We make no promise of a mainnet allocation in this application.

E. Acknowledgements (tick all)

Reviewer notes (internal)

Score each applicant on: independence (A5), diversity (A4, C12, C15), experience (B8–B11), and commitment (D18–D21). Record the decision and the assigned validator index range in node/validators/operators.json only after the validator reaches active_ongoing.