Zero Single-Signature — the headline guarantee

What you’ll get here

what “zero single-signature on chain” means, why it is the central security promise Smart Engines makes, the one bootstrap exception, and how each live blockchain enforces it with its own native multisig.

If you remember one thing about Smart Engines’ security model, make it this:

Every on-chain authority the network creates is a native multisig, with the master key disabled, signed by a threshold of validators. Its keys come from a distributed key ceremony or are each validator’s own key. There is no master key to steal.

This is a hard architectural invariant. The only exception is the single-sig wallet that pays for genesis, described below.

🧠 For Normies

A “single-signature” account is one where one private key can do anything — move all the money, change all the rules. It’s the default for almost every crypto wallet, and it’s a single point of catastrophic failure. “Zero single-sig” means every account Smart Engines creates needs a quorum of independent validators to act. No one key can move anything.

---

What “after genesis” means

There is exactly one single-sig account in the design: the wallet that pays for genesis.

%%{init: {'stateDiagram':{'showSequenceNumbers':false}}}%%
stateDiagram-v2
    [*] --> GenesisFunding: before genesis
    GenesisFunding: Genesis funding wallet<br/>(single-sig,<br/>one-time bootstrap)
    GenesisFunding --> Bootstrap: funds Treasury once
    Bootstrap: Treasury + cluster operators<br/>created as DKG multisig
    Bootstrap --> SteadyState: rest of genesis
    SteadyState: Operational costs paid by<br/>the multisig Treasury
    GenesisFunding --> Deleted: final step — AccountDelete / CryptoDelete<br/>(built, not yet enabled)
    Deleted: zero balance,<br/>zero on-chain authority
    SteadyState --> [*]
    Deleted --> [*]

During cold-start, a genesis funding wallet (a normal single-sig account) funds the protocol Treasury once. The Treasury is a multisig from the moment it exists, and it pays for everything after that. The funding wallet is never added to any entity’s signer list, so it holds no authority over any entity.

The final genesis step deletes the funding wallet on chain with AccountDelete (XRPL) or CryptoDelete (Hedera). That step is built, not yet enabled: it is opt-in and has not run on the testnet. Until it runs, the funding wallet remains a single-sig account with whatever balance it has left.

Everything else — the protocol treasury, each cluster’s operator wallet, every token issuer, every HCS topic — is a threshold multisig from creation.

---

The six on-chain entity classes

After genesis the on-chain footprint is:

#	Entity class	Authority pattern
1	Genesis funding wallet	Single-sig. Deletion at the end of genesis is built, not yet enabled. Holds no authority over any entity.
2	Protocol Treasury (per chain), the protocol runner pool, and on testnet the faucet	DKG multisig, master key disabled, threshold quorum
3	Cluster Operator Wallet	DKG multisig, master key disabled, threshold quorum
4	Issuers on XRPL: the HSUITE token, the membership NFT and the subscription NFT	DKG SignerList, master key disabled, threshold quorum
5	HCS topics	KeyList submit key, threshold quorum
6	DKG shares	Shamir t-of-N, encrypted at rest on each validator

Classes 2–6 have no single-key control point.

This includes the network itself — not just your entities.

The validators’ own Cluster Operator and Treasury accounts (classes 2–3) are DKG multisig with the master key disabled, exactly like a user entity. Apart from the genesis funding wallet, no account the network runs on has a single key — not even the accounts that run the clusters. The cluster’s identity is created by a DKG ceremony with the cluster itself as the subject (see Three-Cluster Genesis), so there is no admin keyholder to compromise, bribe, or subpoena.

---

Why this is the guarantee

Most exchange hacks, bridge exploits, and “rug pulls” reduce to the same root cause: one key controlled too much, and someone got it. Zero single-sig structurally removes that failure mode.

The compromise model:

Scenario	Outcome
1 validator compromised	Zero on-chain authority leaked. One Shamir share, or one validator’s own key in a signer list, is below the threshold. A single share below the threshold is information-theoretically useless.
t validators of an entity’s committee compromised (t is at least a strict majority of the committee)	Full compromise of that entity. No threshold scheme can protect an account against a quorum of its own signers.
Genesis funding wallet seed stolen	The wallet’s remaining balance is at risk. No entity is affected, because the wallet is in no signer list. Once the deletion step runs, the wallet no longer exists.

🧠 For Normies

To steal anything, an attacker doesn’t need to crack one key — they’d need to compromise a quorum of the validators that sign for that account, all at once. Breaking into one machine gets them nothing they can use on chain.

The same structure is what makes open membership possible in the design: authority is the on-chain multisig, and membership is a non-transferable membership NFT. In that design, a new validator joins through a decision signed by a quorum of the existing validators, followed by a reshare that keeps every entity’s on-chain keys unchanged. Validator membership is not open to the public yet.

---

How each chain enforces it natively

The critical design choice: enforcement is the blockchain’s own native multisig primitive, not a Smart Engines abstraction the chain must trust. The ledger verifies the threshold with its own consensus rules.

Hedera and XRPL are live today:

Chain	Native primitive	How single-sig is ruled out
XRPL	SignerList	SignerListSet installs the signer list. Entities created at genesis list one address per DKG slot, and each slot signs with FROST. Entities created through the API list each validator’s own XRPL key, and each validator signs separately. In both cases DisableMaster (asfDisableMaster) turns off the master key, so only the quorum can sign. A token entity’s requested issuer flags are set before the SignerListSet, because XRPL refuses them once the account owns a SignerList.
Hedera	threshold KeyList	Account, topic and token keys are set to a KeyList whose threshold is the quorum; Hedera itself checks the threshold.

Stellar, Polkadot, Solana and Bitcoin come next, and follow the same rule with their own primitives: weighted signers with thresholds (Stellar), pallet_multisig (Polkadot), an m-of-n multisig (Solana) and an m-of-n script (Bitcoin).

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant Cluster as Validators
    participant XRPL as XRPL ledger
    Note over Cluster,XRPL: Entity creation
    Cluster->>Cluster: N × ed25519 DKG → N slot pubkeys
    opt Token entity that requested compliant / wipeable
        Cluster->>XRPL: AccountSet issuer flags (RequireAuth / AllowTrustLineClawback)
    end
    Cluster->>XRPL: SignerListSet (slot addresses or validator keys, quorum t)
    Cluster->>XRPL: AccountSet asfDisableMaster
    Note over XRPL: Master key OFF. Only the multisig quorum can ever sign again.
    Note over Cluster,XRPL: Later — any spend
    Cluster->>Cluster: t signatures, each from a slot (FROST) or a validator key
    Cluster->>XRPL: submit multi-signed tx
    XRPL->>XRPL: verify Signers[] against SignerList threshold
    XRPL-->>Cluster: tesSUCCESS

🧠 For Normies

We don’t ask you to trust our idea of a multisig. We use the blockchain’s own built-in multisig feature and then turn off the master key. From that point on, the blockchain itself — not Smart Engines — refuses any transaction that doesn’t carry a full quorum of signatures.

---

Next steps

• DKG & TSS — how the slot keys are born and how the quorum signs.
• Trustless Core — the end-to-end authorization story.
• Rules Engine — the public policy layer gating what the quorum will sign.
• Entities & Sovereignty · Three-Cluster Genesis — the entity model and cold-start.
• Glossary — BFT, multisig, SignerList, KeyList defined.