Genesis & lifecycle

What you’ll get here

how Smart Engines goes from a fresh, empty deployment to a live network that no single party controls — and what happens when a member joins or leaves afterwards.

A validator network doesn’t materialize fully-formed. It has to be bootstrapped: chains have to come online, the network’s own accounts have to be created with DKG, rules have to be published on chain, and new members have to be admitted later — all without ever letting a single validator sign alone. This page is the choreography of that ritual.

🧠 For Normies

Booting one program is easy. Booting a network of cooperating programs that have to share secrets nobody is allowed to hold alone — and getting them to agree before they do anything — is the hard part. “Genesis” is that first, careful boot.

---

The shape of genesis: BFT, zero single-sig

Genesis runs across the genesis validators, which coordinate with Byzantine-fault-tolerant consensus. Every account the network creates at genesis is a native multisig whose keys come from DKG ceremonies across those validators, and every account users create afterwards runs its own DKG too — so after genesis, no single validator can sign anything alone. No single key controls any entity, and that is the whole point: decentralization is enforced cryptographically, not promised in a policy doc. The one bootstrap exception is the wallet that funds genesis once: it controls no entity, and the step that deletes it is built but not yet enabled.

On the testnet, the genesis validators are three clusters run by HSuite. Three clusters is where the network starts, not a limit of the design.

🧠 For Normies

“Zero single-sig” means: once the network is up, there is no lone key anywhere that can move funds or change state by itself. Every action needs a threshold of independent validators to cooperate.

---

The five phases

stateDiagram-v2
    [*] --> ChainReadiness
    ChainReadiness: Phase 1 — Chain readiness
    ChainReadiness: each chain connects and reports ready
    GenesisInit: Phase 2 — Genesis initialization
    GenesisInit: per-chain genesis, in order
    ClusterDKG: Phase 3 — Cluster key DKG
    ClusterDKG: validator keys + DKG for every genesis account
    GovPublish: Phase 4 — Governance publish
    GovPublish: rules and validator registry on Hedera topics
    MembershipOpen: Phase 5 — Membership open
    MembershipOpen: membership API accepts applications

    ChainReadiness --> GenesisInit
    GenesisInit --> ClusterDKG
    ClusterDKG --> GovPublish
    GovPublish --> MembershipOpen
    MembershipOpen --> SteadyState
    SteadyState: Steady state — serving requests
    SteadyState --> Resharing: member joins / leaves
    Resharing: Resharing ceremony
    Resharing: re-split every key for the new membership
    Resharing --> SteadyState
    SteadyState --> [*]

The phases overlap in practice (keys are generated as each account is created), but each has a clear job. Let’s walk them.

Phase 1 — Chain readiness

Each chain the network uses connects and reports when it is ready. Genesis runs per chain, and it is complete only when every chain the network requires has finished. Today those chains are Hedera and XRPL.

🧠 For Normies

Each blockchain comes online on its own schedule. Genesis works through them one by one, and isn’t done until all the required ones are.

Phase 2 — Genesis initialization

Genesis creates the network’s own accounts in a fixed order:

1. The rules topic on Hedera, first, so every account created after it can point at its rule.
2. A protocol treasury on each chain, which pays for the accounts created after it.
3. The node-runner reward pool.
4. A cluster-operator account per validator per chain. These hold the membership NFTs.
5. The network’s Hedera topics, then the XRPL accounts.

Every one of these is a native multisig controlled by DKG keys, not a single key. Genesis runs once: a network that has completed it refuses to start it again.

Phase 3 — Cluster key DKG

Each validator generates its own chain keypair, and every genesis account’s keys are created by DKG across the validators. Each validator ends up with only its own share of each key, and the shares are stored encrypted. The public keys are registered so the rest of the system can look them up.

🧠 For Normies

Before the network can sign for users, it needs its own keys — and those are split too, so no single validator holds any of the network’s keys either.

Phase 4 — Governance publish

The network publishes what it runs by on Hedera Consensus Service topics: the rules every account is bound to, and the validator registry. Each topic’s submit key is itself a threshold key, so no single validator can write to it. Anyone can read these topics and check an account’s rule for themselves.

Phase 5 — Membership open

Once genesis is complete, the membership API is up, for three roles: validator, host and gateway. An applicant calls POST /api/v3/membership/apply with the roles they want, stakes the HSUITE for them, and is admitted by the existing validators. Joining is not open to outside node runners yet: HSuite runs the genesis validators until the network opens after mainnet. See Run a node.

---

Creating entities after genesis — any cluster, no bottleneck

Once the network is live, the accounts users create aren’t pinned to the cluster that happened to receive the request. The rule that governs a creation is published on a Hedera topic, which every cluster can read, so whichever cluster fields the request can look up the rule, run the per-account DKG and native multisig, and create the account on chain. The result then replicates to the other clusters. No single cluster is a creation chokepoint.

🧠 For Normies

The rulebook for “how to create this thing” lives on a public, shared ledger every cluster can read. So it doesn’t matter which cluster you happen to reach — any of them can look up the rule and build your account, and the others find out about it.

---

Steady state and membership changes

The hardest case is a new validator joining a live network: it needs a share of every existing key. The existing validators first approve the join with a quorum of signed approvals, then run a resharing ceremony for every key: each existing holder deals a verifiable piece to the new member set, and each member combines the pieces into its new share. The key itself is never rebuilt, and the public key does not change, so the accounts on chain keep their keys.

Leaving is the reverse: the remaining validators reshare without the departing one. The old shares are not automatically useless after a reshare: enough old holders together could still sign with them. That is why old shares have to be deleted, and why a departing validator’s share alone is never enough to sign.

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant New as Joining validator
    participant Cluster as Existing validators
    participant Chain as XRPL
    New->>Cluster: POST /api/v3/membership/apply (roles, identity)
    New->>Chain: stake HSUITE into the deposit account
    Cluster->>Chain: deposit confirmed, mint the membership NFT
    Cluster->>Cluster: quorum of signed approvals
    Cluster->>Cluster: reshare EVERY existing key (incl. new member)
    Cluster-->>New: verifiable pieces (one per existing holder)
    New->>New: verify + combine into its own share
    Note over Cluster,New: same public keys, new shares for the new member set

🧠 For Normies

Adding a validator is harder than it sounds: they need a piece of every existing key. The validators rerun the “split the key” dance for every key, this time including the newcomer, without ever putting the key back together. Same when someone leaves — the rest re-split every key without them.

---

Snapshots — deterministic votes

The network takes snapshots of token holdings and publishes them on IPFS as plain JSON, so anyone can open them. Each governance proposal fixes the snapshot time that every voter’s weight is taken from, and that time is part of what the proposal signs, so the result can’t be changed by moving tokens afterwards.

🧠 For Normies

The network takes “photographs” of who holds what. Votes point at the photo, so no one can rewrite the result by shuffling tokens after the fact.

---

Recap

• Genesis runs across the genesis validators with BFT coordination; on the testnet that is three HSuite-run clusters.
• Every genesis account is a native multisig with DKG keys, and every account created later runs its own DKG, so no single key controls any entity.
• Five phases: chain readiness → genesis init → cluster DKG → governance publish → membership open.
• Rules and the validator registry are published on Hedera so anyone can check them.
• Joining or leaving triggers a resharing ceremony across every key; the keys are never rebuilt, and old shares must be deleted.
• Snapshots make votes deterministic.

---

Next steps

Smart ValidatorThe tier that runs all this.

Harbor & content-addressed imagesHow the images that run the network stay trustworthy.

Run a nodeHow node runners will join the network.

GlossaryNew term?