Architecture

System Overview

Smart Engines V3 is built on a modular, chain-agnostic architecture that enables consistent operation across multiple blockchains while maintaining the unique capabilities of each chain. The platform has three permanent tiers — validators, hosts and gateways. Today Hedera and XRPL are live; Stellar, Polkadot, Solana and Bitcoin come next; Ethereum and Polygon are postponed.

Core Components

flowchart TB
    Client["Client Applications<br/>(SDK, REST API)"]
    GW["Smart Gateway<br/>(routing, rate limiting)"]
    Host["Smart Host<br/>(backend-as-a-service)"]
    subgraph SV["Smart Validator"]
        direction LR
        Auth["Auth and Session Manager"]
        Rules["Rules evaluation (sign gate)"]
        TSS["Threshold Signing"]
        EventBus["Event Bus (private mesh)"]
    end
    Client --> GW --> Host --> SV
    HA["Hedera Adapter (live)"]
    XA["XRPL Adapter (live)"]
    PA["Further adapters (coming next)"]
    SV --> HA
    SV --> XA
    SV -.-> PA
    HN["Hedera Network"]
    XN["XRPL Network"]
    HA --> HN
    XA --> XN

Multi-Chain Core Library

A shared core library gives every chain the same abstractions.

Chain Orchestration

Every chain adapter implements one common contract, so the rest of the platform calls every chain the same way:

Group	Operations
Connection	Connect, disconnect, health and network status
Accounts	Create an account, read account info and balance
Transfers	Transfer, read a transaction and its receipt, transaction history
Tokens (optional)	Create, mint, transfer and burn a token, read token info
Consensus messaging (optional)	Submit a message to a topic
Contracts (optional)	Deploy and call a contract

An adapter implements the optional groups only where its chain supports them.

Capability Detection

Each chain declares which token-control capabilities it supports, and a token request that asks for a capability the chain lacks is refused:

Capability	XRPL Live	Stellar Coming next	Polkadot Coming next	Solana Coming next	Bitcoin Coming next
Mintable	Yes	Yes	Yes	Yes	No
Burnable	Yes	Yes	Yes	Yes	No
Transferable	Yes	Yes	Yes	Yes	Yes
Restrictable (freeze)	Yes	Yes	Yes	Yes	No
Pausable	Yes	Yes	No	No	No
Compliant (KYC / authorization)	Yes	Yes	No	No	No
Wipeable (clawback)	Yes	Yes	No	No	No

Hedera’s role in the platform is consensus messaging (HCS): rule publication, governance and audit topics.

Chain Adapters

Each supported blockchain has a dedicated adapter that implements the standard contract while handling chain-specific logic.

Adapter Structure

Each adapter is its own package, and handles its chain’s account model, transaction format, fees and native multisig. Every on-chain account the platform controls is protected by the chain’s own multisig — a threshold key on Hedera, a SignerList on XRPL — whose signers are the validators’ DKG slot keys.

flowchart TB
    C["Common adapter contract"]
    C --> H["Hedera adapter (live)<br/>HCS topics, threshold keys"]
    C --> X["XRPL adapter (live)<br/>accounts, trust lines, NFTs, SignerList multisig"]
    C --> N["Stellar, Polkadot, Solana, Bitcoin adapters<br/>(coming next)"]
    C --> E["Ethereum, Polygon adapters<br/>(postponed)"]

TSS/MPC Architecture

Threshold signature operations are handled by dedicated services. Every on-chain signing slot is created by a distributed ed25519 key generation (Feldman verifiable secret sharing) across the validators. Only shares exist: the whole key is never assembled, not at rest and not while signing. The signing threshold for an entity is always a strict majority of the validators or more, up to all of them.

Distributed Key Generation (DKG)

flowchart TB
    subgraph P1["Phase 1: Commitment"]
        V1c["V1 commit"]
        V2c["V2 commit"]
    end
    subgraph P2["Phase 2: Share Distribution"]
        V1s["V1 shares"]
        V2s["V2 shares"]
    end
    BUS["Private mesh (commitments broadcast)"]
    SEAL["Private mesh (each share sealed to its recipient's ML-KEM-1024 key)"]
    V1c --> BUS
    V2c --> BUS
    V1s --> SEAL
    V2s --> SEAL

    subgraph P3["Phase 3: Verification"]
        Verify["Verify shares against commitments"]
    end
    subgraph P4["Phase 4: Key Aggregation"]
        Agg["Compute public key and store own share"]
    end
    BUS --> Verify
    SEAL --> Verify
    Verify --> Agg

Each validator keeps only its own share. The group public key becomes one signer on the entity’s on-chain multisig. When the validator set changes, the shares are reshared and the public keys stay the same, so the on-chain multisig does not change.

Signing Sessions

Signing runs in two rounds (FROST). Each validator in the signing set commits to a fresh nonce, then produces a signature share with its own key share after its own rule check passes. The shares are aggregated into one ordinary signature. A validator whose rule check fails withholds its share, so a request that fails the rules never reaches the threshold.

Security Infrastructure

Authentication Flow

sequenceDiagram
    participant Client
    participant Cluster
    Client->>Cluster: 1. Request Challenge
    Cluster-->>Client: 2. Challenge + Nonce
    Client->>Cluster: 3. Sign Challenge with the wallet key
    Cluster->>Cluster: 4. Verify the signature and that the key belongs to the account
    Cluster-->>Client: 5. Session Token

Token Gating

Access control based on NFT/token ownership. A token gate is a list of requirements, and a setting for whether all of them or any one must hold. Each requirement names:

Field	Meaning
Chain	The chain the token lives on
Token ID	The token to check
Minimum balance	For a fungible token, the balance the holder must have
Serial numbers	For an NFT, the specific serials that qualify
Type	Fungible or NFT

Infrastructure Components

Event Bus

Validators communicate over a private message mesh:

flowchart TB
    V1["Validator 1"]
    V2["Validator 2"]
    V3["Validator N"]
    MESH["Private message mesh"]
    V1 --> MESH
    V2 --> MESH
    V3 --> MESH

Message Types:

• DKG ceremony messages: start, commitments, sealed shares and commitment digests
• Threshold-signing requests and signature shares
• Validator heartbeats, for health monitoring

Caching and background jobs

Each node caches rule evaluations and rate-limits requests. DAO jobs and token-holder snapshots run as background jobs.

Deployment Architecture

Kubernetes Cluster

Every tier ships as a protected container image and runs on Kubernetes. Each cluster runs one validator; the network’s validators are spread across independent clusters. The three-cluster testnet is the network’s genesis bootstrap, not a fixed size: the three tiers are the permanent architecture.

High Availability

Independent clusters

Each validator runs in its own cluster, with its own database.

Automatic failover

Kubernetes restarts a failed pod.

Load balancing

Gateways route requests across hosts.

Data replication

Entity bindings are replicated across clusters; rules are anchored on HCS.

Performance Metrics

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

---

Continue to TokenomicsThe economic model.