Active development. APIs and on-chain layouts may change. Track on GitHub.
S SolanaLM
Home / Architecture
Architecture

Gateway, registry, nodes. No magic.

SolanaLM is a small number of moving parts wired together with a standard Python stack. A FastAPI gateway authenticates and routes; a registry tracks node health; inference and training nodes plug in through a uniform interface; Solana settles every request. 

 Client SDK ─▶ Gateway API ─▶ Node Registry
                  │              │
                  ▼              ▼
            Auth / Rate     Health / Routing
            Audit Logs      Circuit Breakers
                                 │
            ┌────────────────────┼────────────────────┐
            ▼                    ▼                    ▼
       Inference          Training            Proxy
       PyTorch · GGUF     FedAvg · FedProx    OpenAI
       Transformers       SCAFFOLD · DP       Anthropic
            │                    │                    │
            └──────────▶ Solana Settlement ◀──────────┘
                     ~0.4s finality · ~$0.00025

The layers

Gateway API

FastAPI · Uvicorn · Pydantic v2

JWT + Solana-signature auth, per-user rate limits, input sanitization, audit logging, Prometheus metrics. The single entry point for every request.

Node registry

Discovery · health checks

Tracks node role and capacity, runs health checks, and fails over between nodes with circuit breakers so requests never hit a dead node.

Inference nodes

PyTorch · llama.cpp · proxies

A pluggable backend abstraction gives one API across local Torch, llama.cpp (GGUF), and remote OpenAI/Anthropic/Cohere/Ollama proxies.

Training nodes

FedAvg · FedProx · FedAdam · SCAFFOLD

A federated round coordinator handles heterogeneous client configs and non-IID data, with secure aggregation and differential privacy.

Privacy layer

3-hop onion · differential privacy

Optional onion routing for confidential inference so no node sees source and content together; DP on gradient updates for federated rounds.

Settlement

solana-py · pynacl · base58

Per-request SOL micropayments via signed transactions, with disputes resolved against on-chain audit logs.

Request lifecycle

What happens between an OpenAI-style call and a SOL payout to the serving operator.

  1. 1

    Authenticate

    The client sends a request with a Solana wallet as the API key. The gateway verifies a JWT or Solana signature, applies per-user rate limits, and sanitizes input.

  2. 2

    Reserve settlement

    The gateway requires a signed Solana transaction (or a pre-funded session) before forwarding. Payment intent is recorded in the audit log.

  3. 3

    Route to a node

    The node registry selects a healthy node that can serve the requested model, using health checks and circuit breakers to skip degraded nodes.

  4. 4

    Serve inference

    The chosen inference node runs the completion on its backend — local PyTorch/Transformers, llama.cpp, or a proxied provider — behind a uniform wire protocol.

  5. 5

    Settle and pay out

    Settlement finalizes per-request on Solana (~0.4s, ~$0.00025). The serving operator receives SOL; the transaction is written to the on-chain audit trail.

  6. 6

    Observe

    Prometheus metrics, structured request tracing, and the WebSocket admin dashboard record latency, node health, and throughput for every call.

Ready to run it?

The quickstart walks you from clone to first OpenAI-compatible request in a handful of commands.

Open the quickstart Back to features Use cases