Decentralization Model

“Decentralized” is an overused word. This page makes it concrete for Smart Engines by answering three precise questions: what can no single party do? where does authority live? how much can fail? Every answer traces back to one invariant.

The invariant: No single machine and no single operator can sign on your behalf. The validators must mathematically agree.

What no single party can do

%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart TD
    Attacker["A single compromised party<br/>(operator, validator, host, or gateway)"]
    Attacker --> Q1{"Forge a signature?"}
    Attacker --> Q2{"Steal a usable key?"}
    Attacker --> Q3{"Act for an entity alone?"}
    Attacker --> Q4{"Rewrite the rules secretly?"}
    Q1 --> A1["NO — needs a threshold quorum (TSS)"]
    Q2 --> A2["NO — DKG keys are stored only as shares"]
    Q3 --> A3["NO — needs t validators, at least a strict majority"]
    Q4 --> A4["NO — rules are public on HCS, tamper-evident"]

A single party cannot…	Because…
Forge a transaction signature	Signing requires a threshold quorum of validators (TSS)
Take a complete DKG key from storage	Keys are born split via DKG and only shares are ever stored; signing combines partial signatures, not shares
Steal useful key material from one box	A single validator holds only a share, or one key among the members of a native multisig — below the threshold either way
Act for an entity unilaterally	Signing needs `t` of the entity’s validators, where `t` is at least a strict majority
Rewrite policy in the dark	Rules are published publicly on Hedera HCS, mandatory, enforced per transaction
Silently bill or drain a wallet	The payer is resolved explicitly; the validator never silently pays
Take custody of your entity in `partial` mode	Your key is a required signer in the on-chain authorization set

Where authority lives

Authority is split across three layers, each with its own guarantee:

%%{init: {'flowchart':{'htmlLabels':true,'curve':'basis'}}}%%
flowchart LR
    subgraph Crypto["Cryptographic authority"]
        K["DKG-born key shares<br/>+ TSS threshold signing"]
    end
    subgraph Consensus["Consensus authority"]
        C["t of n validators<br/>at least a strict majority"]
    end
    subgraph Policy["Policy authority"]
        R["Rules on HCS<br/>public · mandatory"]
    end
    K --> Sign["A signature is produced"]
    C --> Sign
    R --> Allow["…only if the action is allowed"]
    Allow --> Sign

Authority	Held by	Verifiable how
Who can sign	The validator quorum (no single validator)	TSS math + per-entity DKG
Whether the network agrees	A threshold `t` of the entity’s `n` validators	The chain’s own native multisig check
What is allowed	Public rules on Hedera HCS	Anyone can read the HCS topic
Who you are	Your wallet key (and, in `partial`, your required signature)	On-chain signature verification

The threshold is never below a strict majority of the committee, so it always exceeds the coalition a Byzantine-fault-tolerant system tolerates, ⌊(n−1)/3⌋. For entities created through the API it is the classic BFT bound ⌊2n/3⌋+1, lowered to n−1 where needed so the committee can still act with one member missing; the entities created at genesis use ⌈2n/3⌉.

No layer can override another. The crypto can’t sign for a forbidden action (rules block it); the rules can’t forge a signature (crypto blocks it); a single validator can’t act alone (the threshold blocks it).

How much can fail

The network is built to limp under partial failure, not die.

Failure	Effect	Why it’s survivable
1 validator offline	Existing entities keep signing. Creating a new entity waits until every committee member is back.	Signing needs `t` of `n`, and `t` is below `n`; key creation needs every member
1 validator malicious	It cannot sign alone. It can stall the creation of new entities by refusing or sending a bad share.	A bad share aborts the ceremony; nothing half-made is kept
1 validator compromised	Attacker gets one share or one member key	Both are below the threshold
1 blockchain’s RPC down	That chain’s requests fail fast; other chains continue	Each chain has its own adapter, with its own circuit breaker
A host dies	The gateway routes traffic to the remaining healthy hosts	Gateway health checks + load balancing

stateDiagram-v2
    [*] --> Healthy
    Healthy --> Degraded: 1 validator / chain / host fails
    Degraded --> Healthy: failure recovers
    Degraded --> Degraded: existing entities keep signing (t still met)
    Healthy --> Compromised: t validators collude
    note right of Compromised
        Requires a colluding quorum —
        the threshold the whole design
        is built to make impractical.
    end note

The only way to break safety is to compromise a quorum of an entity’s validators at once. In the design, growing the validator set (onboarding new node-runners through the same staking + DKG flow used at genesis) raises that bar over time. Validator onboarding is designed but not yet open.

How decentralized is my app? Degree is tier-driven, with a floor of 3

A smart-app’s decentralization degree — how many independent clusters its state replicates across — is a per-tier property of your subscription tier. The deploy path reads the degree for your tier.

Two rules make this safe and honest:

3 is the floor, not a knob to turn down

Cheaper tiers are never degraded to degree-1 or degree-2. A client cannot request below 3. Every tier today resolves to degree 3.

Degree scales up, never down

Planned: as new clusters join the network, higher tiers can be assigned a higher degree (replicate across more independent clusters → a higher collusion bar). Today only the three genesis clusters exist, so all tiers sit at the floor.

The honest caveats

Decentralization is a spectrum, and clarity beats hype:

The testnet starts with three clusters

The three clusters are how the testnet bootstrapped, not a permanent ceiling. All of them are operated by HSuite today. The network is designed to grow by admitting new validators, but “more decentralized over time” is a trajectory, not a day-one claim.

“full” mode delegates signing to the validator quorum

It is still multi-party (never a single key), but if you want your own key in the loop on every action, choose partial — see Entities & Sovereignty.

Liveness depends on a quorum being reachable

If fewer than t of an entity’s validators are reachable, that entity cannot sign. The network waits rather than act without a quorum. That’s a safety choice, by design.

Next steps

DKG & TSSThe cryptography that makes “one share is useless” true.

Three-Cluster GenesisHow the testnet bootstrapped from three clusters.

Rules EngineThe public policy layer.

Entities & SovereigntyPicking partial vs full control.

GlossaryTerm definitions.