Why It Matters
If blockchains are supposed to be trustless, why does using them almost always mean trusting someone? You trust the exchange with your keys, the bridge with your funds, the API provider with your signing. Smart Engines exists because that gap — between the promise and the practice — is where the money disappears.
The four problems with today’s infra
Section titled “The four problems with today’s infra”1. Custodial keys: one server, all the risk
Section titled “1. Custodial keys: one server, all the risk”Most blockchain backends hold your private key on a server so they can sign for you. Convenient. Also the single largest cause of catastrophic loss in the industry — every major exchange hack, every “the company had the keys” insolvency.
2. Single-signature accounts: one key, one point of failure
Section titled “2. Single-signature accounts: one key, one point of failure”Even when you hold the key, a single-signature account means one secret stands between safety and total loss. Lose it, leak it, or get phished — game over. No quorum, no veto, no recovery.
3. Opaque rules: policy you can’t see or audit
Section titled “3. Opaque rules: policy you can’t see or audit”What’s actually allowed to happen to your tokens? In most systems, the answer lives in a company’s private codebase or database. It can change tomorrow. You can’t audit it, and you find out the rule existed only when it blocks (or fails to block) you.
4. Per-chain rebuilds: five chains, five projects
Section titled “4. Per-chain rebuilds: five chains, five projects”Every chain has its own SDK, key format, transaction model, fee mechanics, and finality rules. Supporting multiple chains means maintaining multiple integrations — and multiplying the surface area for the three problems above.
flowchart TD
App["Your app"] --> P1["Custodial key<br/>on a server"]
App --> P2["Single-sig<br/>account"]
App --> P3["Hidden, mutable<br/>rules"]
App --> P4["Separate integration<br/>per chain"]
P1 --> Loss["Hack / insolvency /<br/>betrayal"]
P2 --> Loss
P3 --> Loss
P4 --> Cost["Cost, drift,<br/>bigger attack surface"]
The Smart Engines answer
Section titled “The Smart Engines answer”| Today’s failure | Smart Engines’ answer | Honest trade-off |
|---|---|---|
| Custodial keys | Keys generated by DKG and held only as shares. To sign, a threshold of validators each sign with their own share; the whole key is never assembled. | Setup involves a real cryptographic ceremony, not “paste a private key.” More moving parts under the hood. |
| Single-sig | Native on-chain multisig, threshold-signed. After genesis, no single key controls any entity. | Signing requires a quorum to be reachable — that’s the point, and it means liveness depends on the cluster. |
| Opaque rules | Rules published on Hedera HCS: public, mandatory, checked before every signature. | Rules are visible to everyone — by design. Privacy of policy is traded for auditability. |
| Per-chain rebuilds | One API over every supported chain. | You depend on the platform’s adapter for a given chain’s newest features. |
The control spectrum: you choose how much you hold
Section titled “The control spectrum: you choose how much you hold”Smart Engines doesn’t force one custody model. Every entity you create picks a security mode:
partial— co-control. The transaction needs both your key and the validator network’s threshold signature. You can always veto.full— the validator network’s threshold signature governs the entity (native multisig), with no single party in control.
Removed (A third “none” mode — full custodial control by the cluster — was removed from the platform. The convenient-but-trust-me option is simply not on the menu anymore.)
Why honesty matters here
Section titled “Why honesty matters here”This isn’t magic. Threshold systems trade some operational simplicity for the guarantee that no single machine can betray you. Public rules trade policy privacy for auditability. We think those are the right trades for infrastructure that holds value — but you should make them with eyes open.