Account Provisioning

What you’ll get here

how the platform stands up accounts and entities on chain for you, with no private key stored anywhere. Multisig is the default, not an upgrade.

The moment your app needs to act on a chain — hold a balance, own a token, own a topic — it needs an account. Traditionally that means generating a private key and storing it somewhere. On Smart Engines, there is no private key to store. Accounts are provisioned as DKG-derived, threshold-signed entities whose control is split across the validator cluster.

🧠 For Normies

Normally a crypto account is “one key = total control,” and whoever holds that key owns everything. That single key is also a single point of failure. Smart Engines instead splits control across many validators, so no one node can sign alone, and there is no stored master key to steal.

---

What “entity” means here

Provisioning revolves around the concept of an entity. An entity is anything the cluster governs and can sign for. The platform recognizes several entity types, including:

Entity type	What it represents
wallet	A user/app wallet/account on a chain.
account	A funded chain account.
token	A token whose mint/admin authority is cluster-controlled.
topic	A messaging/consensus topic (e.g. Hedera HCS).
smart-app	A deployed customer application.

Every one of these is created the same way: through a per-entity DKG ceremony.

🧠 For Normies

An “entity” is just any account-like thing the network can control on your behalf — a wallet, a token, an app. They’re all created with the same trick: the network collectively generates the keys so no single party holds them.

---

DKG: keys nobody holds alone

DKG stands for Distributed Key Generation. Instead of one machine generating a private key, a group of validators jointly run a protocol whose output is a public key plus a share of the private key held by each participant. The key exists only as shares, and the whole key is never assembled, not at rest and not while signing. To sign, each participating validator makes a signature share with its own key share, and the shares are aggregated into one signature (two-round FROST).

To sign, a threshold of those validators must cooperate. An entity’s threshold can be anything from a strict majority of its n validators up to n. The default is ⌊2n/3⌋ + 1, which keeps signing while up to ⌊(n−1)/3⌋ validators are down. With three validators that default is all three, so it tolerates none.

🧠 For Normies

Imagine a safe that needs, say, 3 of 4 keys turned at once to open. No single keyholder can open it alone, and you can lose one key entirely and still get in. DKG builds exactly that, cryptographically, for blockchain accounts.

---

Multisig by default — and visible on-chain

Multisig by default

The cluster doesn’t just keep keys split internally; it expresses that split as native multisig on the chain itself. When an entity is provisioned, the platform builds the chain’s native multisig descriptor — an XRPL SignerList or a Hedera KeyList — from the per-slot public keys the DKG produced.

This means anyone can inspect the chain and see that the account is governed by a quorum, not by one key.

🧠 For Normies

“Visible multisig” means the shared control isn’t a private promise — it’s written on the public blockchain. Anyone can check that your app’s account really is guarded by many signers, not one.

---

The provisioning flow

sequenceDiagram
    participant App as Your App (SDK)
    participant Host as Smart Host (BaaS)
    participant Val as Validator cluster
    participant DKG as DKG participants (validators)
    participant Chain as Target chain

    App->>Host: Request entity (chain in body)
    Host->>Val: Delegate creation (cluster-internal)
    Val->>DKG: Run per-entity DKG ceremony
    DKG-->>Val: Group public key + per-slot pubkeys
    Val->>Chain: Configure native multisig\n(SignerList / KeyList) from pubkeys
    Chain-->>Val: Account / entity established
    Val-->>Host: entityId (canonical ID)
    Host-->>App: entityId + details
    Note over Val,Chain: Cluster now auto-watches this entity on-chain

A key detail: the entityId returned by the validator is the DKG entity identifier, and for smart-apps it doubles as the appId. So your app’s identity, its on-chain account, and its DKG keys all agree from the first byte.

🧠 For Normies

One ID to rule them all: the same identifier names your app, its blockchain account, and its cryptographic keys. No mismatched IDs to reconcile later.

---

You never see a private key

Because the key material is DKG-split and the host holds nothing, provisioning returns identifiers and public information — an entityId, an address, the chain — never a seed or private key. To make the account do something, you ask the cluster to sign (see Token Lifecycle); the threshold of validators cooperates and the native multisig satisfies the chain.

🧠 For Normies

You get an account you can use, but you’re never handed a key to lose. Using the account means asking the network to co-sign — which it does only when a quorum agrees.

---

Membership changes rotate automatically

When the validator set changes (a node joins, leaves or is banned), the DKG shares are reshared rather than the on-chain account being rebuilt. The same primitive that creates entities also rotates them, so cluster membership can evolve without rewriting on-chain state.

---

Next steps

Web3 AuthenticationProve a wallet's identity before provisioning on its behalf.

Token LifecyclePut a provisioned token entity to work.

DKG & TSSCryptography deep-dive.