Trustless Core — authorizing a transaction without anyone holding a key

What you’ll get here

the end-to-end story of how Smart Engines authorizes a blockchain transaction when no single machine can sign alone — from key birth, through signing, to the chain’s own native multisig accepting it.

Most “secure” custodians come down to one uncomfortable fact: somewhere, somehow, a full private key exists on a disk or in a memory dump. Steal that key, steal everything. Smart Engines is built so that no single key controls an account. Keys created by distributed key generation (DKG) exist only as shares: they are never assembled, not at rest and not while signing. Where an account instead lists each validator’s own key as a member of a native multisig, each of those keys is one signer, below the threshold.

This page is the map. Three other pages drill into the parts:

Distributed Key Generation & Threshold SignaturesHow keys are born and used in pieces.

Zero Single-SignatureThe headline guarantee and how each chain enforces it.

Post-Quantum SecurityThe lattice-crypto layer riding alongside.

🧠 For Normies

Imagine a bank vault that needs several different managers turning their keys at the same time to open — and crucially, the master key for the vault was never made as a single physical object. It was manufactured in pieces, each manager got one piece, and the pieces are designed so that putting them together is never necessary. That’s the whole idea. We’ll unpack how that’s even possible.

---

The trust chain, end to end

A transaction goes from “a customer wants to do X” to “the blockchain accepted it” through three cryptographic stages. No stage ever assembles a whole DKG key.

%%{init: {'sequence':{'showSequenceNumbers':false}}}%%
sequenceDiagram
    autonumber
    participant Client
    participant Cluster as Validator cluster (N nodes)
    participant Chain as Blockchain (native multisig)

    Note over Cluster: Stage 1 — DKG (once, at entity creation)
    Cluster->>Cluster: Each node contributes randomness
    Cluster->>Cluster: Joint public key emerges — secret never assembled
    Cluster->>Chain: Publish the members as a native multisig (KeyList / SignerList)

    Note over Client,Chain: Stage 2 — Threshold signing (every transaction)
    Client->>Cluster: "Sign this transaction"
    Cluster->>Cluster: t-of-N nodes each produce a partial signature
    Cluster->>Cluster: Partial signatures combined — key shares never combined

    Note over Chain: Stage 3 — Native multisig acceptance
    Cluster->>Chain: Submit signatures
    Chain->>Chain: Verify against the on-chain multisig threshold
    Chain-->>Client: Receipt

Stage	What happens	Where the secret is
1. Key birth (DKG)	Validators jointly generate a key via a DKG ceremony.	Never assembled — each node holds only a share, and only shares are stored.
2. Signing (TSS)	t-of-N validators each emit a partial signature.	Never assembled — each signer turns its own share into a partial signature, and the partial signatures, not the shares, are combined.
3. Acceptance (native multisig)	The chain itself checks the signatures against its built-in multisig rule.	The chain enforces the threshold — math it verifies natively.

---

Stage 1 — Keys are born distributed (never split after the fact)

A naive design generates a key on one machine, then splits it into shares (“split after the fact”). For a moment, the whole key existed. Smart Engines never does this. Keys are born already distributed, via Distributed Key Generation (DKG).

Every validator brings its own randomness. Through the DKG protocol (Feldman-verifiable Shamir sharing run peer-to-peer — see DKG & TSS), the cluster derives a joint public key whose corresponding private key is the sum of secrets that were never added together anywhere. Each validator walks away holding only a Shamir share.

Three design invariants back this up:

• No function derives a private key from a public key.
• No secret is a deterministic function of public data.
• All secret generation uses crypto.getRandomValues().

🧠 For Normies

There’s a subtle but huge difference between “make a key, then cut it into pieces” and “make the pieces directly so the whole key never exists.” The first one has a dangerous moment where the full key is sitting in one place. The second one — what we do — has no such moment, ever. The key is a ghost: real enough to verify signatures against, but it has never had a body.

The ceremony is coordinated peer-to-peer over the cluster’s internal message bus. Every share sent to a peer is sealed to that peer’s post-quantum key.

Per-entity isolation

Every entity — a user account, a token issuer, a smart-agent, the protocol treasury — gets its own DKG ceremony, with the entity itself as the payload. So even if two entities are governed by the exact same set of validators, their DKG keys are completely independent. Recovering one entity’s share from disk tells an attacker nothing about any other entity’s DKG keys.

---

Stage 2 — Signing without ever reassembling the key

DKG gives the cluster a distributed key. Now it has to sign with it — without the obvious-but-fatal move of “collect the shares, rebuild the key, sign, delete.”

Two techniques accomplish this, depending on how the account’s multisig is built:

FROST threshold Schnorr

Each validator computes a partial signature from its own share; a coordinator aggregates the partials into one normal Schnorr signature. This is FROST (RFC 9591), run in two rounds. No raw share is ever sent, and no party — not even the coordinator — ever holds the whole secret. It is used for the DKG-created ed25519 slot keys.

Per-validator keys + native multisig

For some accounts — such as XRPL entities created through the API — the native multisig lists each validator’s own key for that chain. Each validator signs separately with its own key, and the chain counts the signatures against the multisig threshold. Each of those keys is one member of the list; none of them can meet the threshold alone.

Either way, the result is something the blockchain accepts as completely ordinary.

🧠 For Normies

Picture several people each writing one stroke of a single signature, in a way that produces a perfect, indistinguishable autograph — without any of them ever seeing the others’ strokes assemble into the full pen-stroke. The bank teller sees a normal signature and accepts it. They have no idea (and don’t need to know) that several people made it.

The threshold t is always at least a strict majority of the N validators and never more than N, 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.

---

Stage 3 — The chain itself is the final authority

The cluster’s threshold signing is internal machinery. The final on-chain authority is the blockchain’s own native multisig primitive — not a Smart Engines abstraction the chain has to trust.

Chain	Native multisig primitive
XRPL Live	SignerList (master key disabled)
Hedera Live	threshold KeyList
Solana Coming next	m-of-n multisig
Bitcoin Coming next	native script / P2WSH
Polkadot Coming next	pallet_multisig
Stellar Coming next	weighted signers

The chain verifies the threshold using its own consensus rules. There is no “trust us” step — the ledger enforces the math. This is a deliberate design rule: prefer chain-native multisig when the chain provides it.

See Zero Single-Signature for the per-chain enforcement detail and why this is the platform’s headline guarantee.

---

Verifiability — don’t trust, check

Trust-minimization isn’t only about keys. Smart Engines includes building blocks that let a customer verify the platform’s claims rather than take its word:

Merkle trees

Log-sized proofs that “this value was in that dataset.”

State anchoring

Built, not yet enabled: the cluster commits its state-root hash to a public Hedera HCS topic, so any later tampering is detectable against an immutable on-chain checkpoint.

Host verification

Before a gateway routes traffic to a host, the host must sign a fresh challenge with its identity key; the gateway repeats the check every 24 hours.

🧠 For Normies

Even the honesty of the system is meant to be something you can check yourself: proofs that your data is in the dataset, a public checkpoint of the platform’s state (built, not yet switched on), and hosts that have to prove who they are before they get your traffic. You never have to take “trust us” for an answer.

---

Why this matters

No single point of theft

There is no file, no memory dump, no insider with access to a whole DKG key. Stealing one validator’s share — or its own member key — is useless below the threshold.

Survivable

Up to N − t validators can be offline and existing entities still sign; fewer than t colluding validators cannot forge a signature.

Chain-verified

The final authority is the blockchain’s own multisig — auditable by anyone, trusting nobody.

---

Next steps

DKG & TSSThe cryptography of distributed keys and threshold signing, with ceremony diagrams.

Zero Single-SignatureThe invariant, per chain.

Rules EngineThe public, mandatory policy layer that gates what the cluster will even sign.

Entities & SovereigntyWhat an entity is and who signs for it.

Network & TiersWhere these clusters live.

GlossaryPlain-English definitions for every bold term.