Smart Validator — the core tier

What you’ll get here

why the validator is the heaviest, most-guarded tier in Smart Engines, and the three jobs it alone is allowed to do — sign on chain, sign with no single key, and enforce the rules.

If the platform has a brain, this is it. The Smart Validator is the only tier that holds key shares, the only tier that signs on chain, and the tier that decides whether a request is allowed before anything touches a chain. Everything above it (the host, the gateway) is a convenience layer that defers to the validator for anything cryptographic.

🧠 For Normies

The validator is the part that actually has hands on the blockchain. The other tiers are friendly receptionists; the validator is the surgeon. That’s why it’s heavily guarded and the only one trusted with the dangerous tools.

---

What only the validator does

%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart TD
    Req([Incoming request]) --> Rules["Rules engine<br/>is this allowed?"]
    Rules -->|denied| Reject([rejected])
    Rules -->|allowed| Sign["Threshold signing<br/>collect signature shares"]
    Sign --> Submit["Chain adapter<br/>submit the signed txn"]
    Submit --> Chains[("Hedera · XRPL")]
    Sign -.->|coordinated over| Consensus["Validator mesh<br/>each peer checks the rules too"]

Three responsibilities live here and nowhere else:

Consensus

The validators agree on what happens before it happens.

Threshold signing

Every signature is assembled from shares held by different validators; no single member can produce one alone.

Rules enforcement

Every operation is checked against the rule its account was created with, and that rule is published on Hedera.

🧠 For Normies

Three superpowers, all in one tier: agree (consensus), sign-without-a-single-key (threshold signing), and say-yes-or-no (rules). Keeping them together — and away from the friendlier tiers — is what makes the platform hard to cheat.

---

Responsibility 1 — TSS/DKG signing

No validator stores the whole key of an account the network controls. Each key is created by DKG (distributed key generation): the validators run the ceremony together, and each one ends up with only its own share. Shares are stored encrypted, and a signature needs a threshold of them.

To sign, the validators run FROST, a two-round threshold signing protocol (RFC 9591). In the first round each share holder commits to a fresh one-time nonce; in the second, each returns a signature share, and the coordinating validator aggregates the shares into one ordinary signature. Raw shares never travel over the network.

🧠 For Normies

Imagine a bank vault that needs several managers to turn their keys at once. No single manager can open it; no single manager’s key is even a complete key. DKG is how the managers’ keys get cut so that nobody is ever handed the whole thing. Threshold signing is the act of enough of them turning their keys together.

The platform combines DKG with native chain multisig. Each account the network controls is a multisig on its own chain (a KeyList on Hedera, a SignerList on XRPL): it lists several keys, each created by its own DKG ceremony, and the chain itself requires a threshold of their signatures. So the control is visible on chain, not hidden behind a single key. Each account runs its own ceremonies, so keys are fresh per account and fixed for that account’s life.

🧠 For Normies

“Per-account DKG” means every account the platform manages gets its own freshly-split keys — not one master key reused everywhere. And because the multisig shows up on the actual blockchain, anyone can check that no single party controls it.

---

Responsibility 2 — Consensus

A signing ceremony is a multi-party agreement: the validators have to agree which operation they’re signing, then each contributes its signature share. The validators coordinate over signed messages on their private mesh. Every account’s signing threshold is at least a strict majority of its validators, so no minority of validators can sign anything.

The testnet starts from a genesis of three clusters run by HSuite. Opening the validator set to independent node runners comes after mainnet; see Run a node.

🧠 For Normies

A strict-majority threshold means a minority of validators — even ones that are broken or lying — can never sign on their own. They would need the cooperation of honest validators, who check every operation first.

---

Responsibility 3 — Rules enforcement

Every account the network controls is bound, when it is created, to a rule: what the account may do and who may ask for it. The rules are not buried in code: they’re published on Hedera (Hedera Consensus Service topics), so the policy is publicly auditable rather than “trust us”.

Each validator checks an operation against the account’s rule before it contributes its signature share. A request the rule refuses gets no shares, so it can’t reach the threshold, however it was routed.

🧠 For Normies

The rules that decide what’s allowed are posted publicly on a blockchain, not hidden in the company’s servers. Each validator reads them and refuses to help sign anything that breaks them. You don’t have to trust the operator’s word — you can read the rules yourself.

---

Why only the validator signs on chain

Only the validator holds key shares and signs on chain. This boundary is load-bearing:

• It keeps chain keys out of the host and gateway entirely.
• It keeps the security-sensitive signing code in one guarded place.
• It lets the lighter tiers scale out without carrying any key material.

---

How a request reaches the validator

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant H as Smart Host
    participant V as Smart Validator
    participant P as Peer validators
    participant C as Chain adapter
    participant Chain as Blockchain
    H->>V: sign operation (HTTP)
    V->>V: rules engine — allowed?
    V->>P: round 1: commit request
    P-->>V: nonce commitments
    V->>P: round 2: sign request
    P->>P: each peer checks the rule
    P-->>V: signature shares
    V->>V: aggregate into one signature
    V->>C: submit signed transaction
    C->>Chain: broadcast
    Chain-->>V: receipt
    V-->>H: signed result

The host is the convenient wrapper; the validator is the cryptographic authority for anything that happens on chain.

---

Recap

• The validator is the only tier that holds key shares and the only tier that signs on chain.
• It does three things no other tier does: consensus, threshold signing, and rules enforcement.
• Keys are created by DKG per account and stored only as shares. Signing runs FROST, and the result is checked on chain as native multisig.
• Every account’s rule is published on Hedera, and each validator checks it before it adds its signature share.
• Every signing threshold is at least a strict majority of the validators.

---

Next steps

Genesis & lifecycleSee where the keys come from.

Smart HostThe friendly layer built on top.

Smart GatewayHow traffic gets here.

Network & tiersArchitecture context.

GlossaryArchitecture context.