Solution: SmartNode Technology

Overview

Smart Engines solves the multi-chain development challenge through a three-layer architecture that provides security, flexibility, and decentralization without compromise.

The Three-Layer Architecture

flowchart TB
    L3["LAYER 3: Off-Chain Execution<br/>Every validator evaluates the rules before it signs"]
    L2["LAYER 2: Immutable Validators<br/>Consensus-stored validation rules (HCS)"]
    L1["LAYER 1: Multisig-of-Multisig<br/>DKG + On-Chain Threshold Signatures"]
    L3 --- L2
    L2 --- L1

Layer 1: Multisig-of-Multisig Protection

The foundation layer provides cryptographic security through:

Off-Chain DKG (Distributed Key Generation)

• Keys generated without any single party knowing the complete private key
• Threshold signatures: a strict majority of validators, or more, must agree
• No single point of failure or compromise

On-Chain Multisig

• Blockchain-level verification of threshold signatures
• Immutable transaction authorization
• Transparent audit trail

Key Features

• Key-share resharing when the validator set changes, so a departing validator’s share stops being useful while the account keys stay the same
• Node expulsion mechanisms for compromised validators
• Post-quantum signatures: ML-DSA-87 (FIPS 204) attestations on internal platform artifacts, verifiable offline with the SDK’s @hsuite/smart-engines-sdk/pqc-verify entry point and the CLI’s hsuite verify. By default a missing or invalid attestation raises a warning; it does not block the operation yet.

Layer 2: Immutable Validators

Validation rules are stored immutably on Hedera Consensus Service (HCS) topics, whichever chain the entity they govern lives on. Hedera’s role in Smart Engines is HCS: consensus, rule publication, governance and audit topics.

Benefits

• Rules cannot be altered without consensus
• Each entity is bound to its published rule by a rule reference (ruleRef)
• Rule amendments go through DAO proposals
• Composable policy conditions: limits, allowlists, approvals

Layer 3: Off-Chain Execution Engine

Complex validation happens off-chain for efficiency:

flowchart TB
    A["Transaction Request"]
    B["Resolve the entity's rule reference"]
    C["Retrieve Rules (from consensus)"]
    D["Execute Logic (off-chain)"]
    E{"Valid?"}
    R["Reject"]
    F["Submit On-Chain (threshold sig)"]
    A --> B --> C --> D --> E
    E -->|"No"| R
    E -->|"Yes"| F

Cost Savings

Rule checks run off-chain, so they pay no on-chain execution fees.

Flexibility

Rules are not bound by a chain’s on-chain execution limits.

Security

Only valid transactions reach the blockchain.

Unified Multi-Chain Interface

Smart Engines provides a single SDK whose calls take the chain as a parameter. Today the live chains are Hedera and XRPL; Stellar, Polkadot, Solana and Bitcoin come next.

import { BaasClient, xrplWalletFundWith } from '@hsuite/smart-engines-sdk';

const baas = await BaasClient.connectToCluster({ network: 'testnet', appId: 'app_abc' });

// Publish the rule that governs the new account, then create it.
const { ruleRef } = await baas.rules.publish(myAccountRule);
const account = await baas.entities.createAccount({
  chain: 'xrpl',
  ruleRef,
  fundWith: xrplWalletFundWith(wallet), // your wallet pays the account's reserve
});

Configurable Security Levels

Applications can choose their security model:

Level	Description	Use Case
Partial	App owner and validators both sign (nested native multisig)	Standard apps
Full	Validators only, through their native multisig	High-security assets

There is no mode in which the app alone signs: every entity has the validators in its signing path.

Key Innovations

1. No Bridge Dependencies

Each chain operates independently:

• No platform operation depends on a bridge or a wrapped token
• No cross-chain message passing vulnerabilities
• The one bridge the platform builds, the Universal Token Bridge, only moves a token itself from one chain to another Built, not yet enabled

2. Chain-Agnostic Development

High-level abstractions handle chain specifics:

// The chain is a parameter. XRPL is live; more chains come next.
await baas.entities.createToken({
  chain: 'xrpl',
  name: 'MyToken',
  symbol: 'MTK',
  currency: 'MTK',
  initialSupply: '1000000',
  ruleRef,
  creationIntent, // your signed create intent, built with signEntityCreateIntent
  fundWith: xrplWalletFundWith(wallet),
});

3. Enterprise-Grade Security

• AES-256-GCM envelope encryption for sensitive data at rest
• TLS at the gateway, with TLS 1.2 as the minimum version
• Post-quantum signatures: ML-DSA-87 (FIPS 204) attestations on internal platform artifacts; customer-verifiable offline via verifyPqcAttestation() (SDK) or hsuite verify (CLI). See Post-Quantum security for the cert format, threat model, and migration policy.
• Security audit: the testnet opens to developers once the security audit is complete

4. Kubernetes-Native Infrastructure

Deployment includes:

• One packaged deployment for validators, hosts and gateways
• Kubernetes restarts failed pods automatically
• Metrics for monitoring each tier

Performance Characteristics

Smart Engines does not publish performance figures yet. An operation’s latency is bounded by the target chain’s own confirmation time plus the validators’ threshold-signing round.

Getting Started

Developers will integrate Smart Engines in three steps. The testnet runs on HSuite-operated validators and opens to developers once the security audit is complete.

1. Install the SDK

   npm install @hsuite/smart-engines-sdk

2. Connect to a cluster

   import { BaasClient } from '@hsuite/smart-engines-sdk';
   
   const baas = await BaasClient.connectToCluster({ network: 'testnet', appId: 'app_abc' });

3. Start building

   const { ruleRef } = await baas.rules.publish(myAccountRule);
   const account = await baas.entities.createAccount({
     chain: 'xrpl',
     ruleRef,
     fundWith: xrplWalletFundWith(wallet),
   });

---

Continue to ArchitectureDetailed technical specifications.