MCPcopy Index your code
hub / github.com/dante-gpu/dantegpu-core

github.com/dante-gpu/dantegpu-core @main

Chat with this repo
repository ↗ · DeepWiki ↗ · + Follow
1,457 symbols 4,111 edges 178 files 1,045 documented · 72%
What it actually does AI analysis from the code graph — generated when you open this
loading…
README

DanteGPU Core

Decentralized GPU rental marketplace on Solana. Providers list idle GPUs, renters pay by the minute in the dGPU SPL token, and a set of Go microservices coordinate discovery, scheduling, metering, and settlement.

DanteGPU Core is the coordination and billing layer, not an inference engine. It owns the marketplace: who is renting, what they pay, how a job reaches a provider, and how the provider gets settled on-chain. The actual compute runs on the provider node (Docker or a script executor managed by the provider daemon).

Status: working MVP backbone, not production. The core path (list, discover, rent, run) is real and runs on real PostgreSQL, NATS, Consul, MinIO, and Solana devnet. One caveat up front: the api-gateway still authenticates against an in-memory mock user map (the React frontend already talks to the real auth-service), and replacing it is the first roadmap item. Several other edges are deliberately stubbed and are tracked honestly below and in ROADMAP.md. If a feature is not listed as working here, assume it is not wired yet.

The marketplace in six verbs

The whole system is a six-step lifecycle. This table is the honest state of each step (see docs/STATUS.md for the per-service breakdown).

Verb What happens Services State
LIST A provider registers and its GPUs are detected provider-registry-service, provider-daemon Working (NVIDIA solid; AMD via rocm-smi, Apple via system_profiler, with some hardcoded VRAM mappings)
DISCOVER A renter browses the catalog gpu-service, console Working (read path)
RENT A renter reserves a GPU and funds are locked rental-service, billing-payment-service Working (USDC billing; on-chain Covenant escrow opened on session start)
RUN A job is dispatched and executed on the provider scheduler-orchestrator-service, provider-daemon Working (NATS dispatch + Docker exec; matching by type, count, VRAM and power; K8s extender is an unused stub)
METER Usage is sampled per second provider-daemon, billing-payment-service Working (real per-vendor GPU metrics threaded into the billing session)
SETTLE The provider is paid in USDC on Solana billing-payment-service Partial (Phase 1 fixed-duration on-chain settlement via Covenant; metered refund is the open work)

The honest one-line summary: you can list a GPU, find it, rent it in USDC, run a job, and have the session settle on-chain via Covenant; the remaining open work is true metered (partial) refund and mainnet hardening.

Want proof rather than claims? ./scripts/rental-proof.sh runs the whole loop end to end with real code on a throwaway Postgres + NATS (no Docker/NVIDIA needed): it detects this host's GPU, prices the rental, persists a metered session to Postgres and reads it back, then dispatches a task over NATS that the daemon actually executes. And ./scripts/gpu-model-proof.sh goes further — dispatching an AI-inference job whose payload runs a real quantized Llama model on the host's GPU (Apple Metal: ~235 tok/s on an M4 Max), with the model's answer returned through the daemon. See docs/PROOF.md.

Architecture

flowchart TD
    subgraph Clients
      FE[console

Vite + React + Tailwind v4]
      DAEMON_C[provider-daemon

node agent]
    end

    GW[api-gateway :8080

chi router, JWT, proxy]

    subgraph Services[Go microservices]
      AUTH[auth-service :8090

bcrypt + JWT]
      REG[provider-registry-service :8081]
      GPU[gpu-service

catalog]
      RENT[rental-service

reservations]
      BILL[billing-payment-service :8082

dGPU pricing + Solana]
      SCHED[scheduler-orchestrator-service :8084

NATS consumer]
      STOR[storage-service :8083

MinIO]
      MON[gpu-monitoring-service :8092]
      CACHE[redis-cache-service]
    end

    subgraph Provider node
      DAEMON[provider-daemon

GPU detect, Docker exec]
    end

    subgraph Infra
      PG[(PostgreSQL)]
      NATS{{NATS JetStream}}
      CONSUL{{Consul}}
      MINIO[(MinIO)]
      SOL[(Solana devnet

dGPU SPL token)]
    end

    FE --> GW
    GUI --> DAEMON
    GW --> AUTH & REG & GPU & RENT & BILL & SCHED & STOR
    SCHED <-->|jobs| NATS
    DAEMON <-->|tasks/results| NATS
    REG -. register .-> CONSUL
    BILL --> SOL
    AUTH & REG & GPU & RENT & BILL & SCHED --> PG
    STOR --> MINIO
    GW -. cache .-> CACHE

Each service is an independent Go module under its own directory. They share types through common/ and discover each other through Consul. Inter-service events (job submission, task dispatch, results) flow over NATS JetStream.

The billing model

This is the part of the system that is most fully built and the reason the project exists. Pricing is computed with shopspring/decimal (no float money) in billing-payment-service/internal/pricing/engine.go:

total_hourly = base_rate(gpu_model)
             + vram_rate_per_gb * allocated_vram_gb
             + power_multiplier * estimated_power_kw
adjusted     = total_hourly * demand_multiplier - base_rate * supply_bonus
cost         = adjusted * duration_hours
platform_fee = cost * platform_fee_percent
provider_earnings = cost - platform_fee

Wallets, balances, deposits, and withdrawals are real Solana RPC calls (gagliardetto/solana-go) against the dGPU SPL token (configurable mint, devnet by default). Funds are locked in PostgreSQL when a rental starts.

Two honest caveats:

  • Dynamic pricing is a stub. getDynamicPricingFactors() returns a fixed demand=1, supply=0. The supply/demand signal is meant to come from provider-registry-service and is not wired yet, so prices do not actually move with the market.
  • Provider payout is recorded, not paid. Ending a rental writes a provider_payouts row but no background worker executes the on-chain transfer yet. Renter-side balance accounting is correct; provider-side disbursement is the open loop.

Data model

The strongest artifact in the repo is the schema: 13 migrations under database/migrations/, roughly 68 tables modeling users and auth, the GPU marketplace (providers, capabilities, instances, reservations), Solana billing (wallets, blockchain transactions, rental sessions, escrow, platform fees, provider payouts), and the job lifecycle (jobs, logs, metrics, files, checkpoints, dependencies). It includes monthly partitioning for high-volume log and metric tables, stored procedures for wallet fund lock/release, and views for billing and analytics.

Quick start

Requirements: Docker with Compose, Go 1.23+, Node 20+ (for the frontend).

git clone https://github.com/dante-gpu/dantegpu-core.git
cd dantegpu-core
cp env.production.example .env   # then edit secrets

# Bring up infra + services
docker compose up -d

# Apply database migrations
./database/run_migrations.sh

Core service ports once the stack is up:

Port Service
8080 api-gateway
8081 provider-registry-service (listens on 8002 internally)
8082 billing-payment-service
8083 storage-service
8084 scheduler-orchestrator-service
8090 auth-service
8092 gpu-monitoring-service
5174 console (web frontend)

Supporting infra runs on its standard ports: PostgreSQL 5432, Redis 6379, NATS 4222 (monitoring 8222), Consul 8500, MinIO 9000/9001, Prometheus 9090, Grafana 3000, Loki 3100.

To build a single service directly (each is its own module):

cd billing-payment-service && go build ./...

gpu-service, rental-service, and provider-registry-service build clean with go build ./... on Go 1.24.

Repository layout

services/                     Backend Go microservices (one module each)
  api-gateway/                Edge router: JWT auth, CORS, Consul/NATS, proxy
  auth-service/               PostgreSQL + bcrypt + JWT identity
  provider-registry-service/  Provider + GPU-capability registry (Consul)
  gpu-service/                Read-only GPU catalog
  rental-service/             Rental reservations and lifecycle
  billing-payment-service/    Pricing engine + Solana wallets/settlement (USDC)
  scheduler-orchestrator-service/  NATS job consumer + (stub) K8s extender
  storage-service/            MinIO-backed object storage
  gpu-monitoring-service/     nvidia-smi metrics + WebSocket stream
  redis-cache-service/        Cache helpers (library, imported by services)
clients/                      Apps and node agents
  console/                    DanteGPU web console (Vite + React + Tailwind v4):
                              marketplace, rent flow, USDC wallet, provider dashboard
  provider-daemon/            Provider node agent: GPU detect, Docker/script exec
contracts/                    On-chain settlement integration (Covenant) + future programs
common/                       Shared Go types and utilities (root module)
cmd/                          Root-module executables (provider, rental, tooling)
database/migrations/          13 SQL migrations (the canonical schema)
infrastructure/               Redis/MinIO/NATS/Consul/Prometheus config
monitoring-logging-service/   Prometheus + Grafana + Loki + Alertmanager stack
k8s/                          Staging and production manifests
docs/                         Architecture, runbook, API reference, status

Note: the Go module namespace is github.com/dante-gpu/dante-backend (historical), while the repository is dantegpu-core.

Known limitations

Kept here so the README never overclaims. Full detail and the plan to close each is in ROADMAP.md.

  • api-gateway has mock users. api-gateway/internal/auth/user.go holds a hardcoded in-memory user/admin map. The gateway does not yet call auth-service for identity. This is the highest-priority correctness fix.
  • Gateway billing endpoints return mock data. GetUserBalance returns a hardcoded 100.0 and GetUserWallet returns "not yet implemented"; both are placeholders pending a real billing client. Live but fake.
  • Metering does not reach billing. gpu-monitoring-service collects real metrics but does not publish usage to billing-payment-service.
  • On-chain escrow and payout are incomplete (see the billing section).
  • Not implemented despite past claims: two-factor auth, OAuth2, on-chain smart contracts, multi-signature wallets, and Stripe/PayPal payments. Billing is Solana-only. GPU detection is real for NVIDIA (nvidia-smi), AMD (rocm-smi), and Apple Silicon (system_profiler), but several VRAM values are hardcoded mappings rather than queried.
  • Test coverage is thin: about 8 test files, mostly SQL-mocked unit tests plus three integration suites that assume a running stack. The real services (billing-payment-service, scheduler-orchestrator-service, provider-registry-service) have no unit tests yet.

A previous generation of triumphant progress reports (MISSION_ACCOMPLISHED and friends) and self-congratulatory "audit passed" documents have been removed; they described an idealized system, not this one. They remain in git history if needed.

Documentation

License

MIT

Extension points exported contracts — how you extend this code

SecretLoader (Interface)
SecretLoader defines the interface for loading secrets from various sources [3 implementers]
services/provider-registry-service/internal/config/secrets.go
EmailService (Interface)
EmailService interface for sending emails [2 implementers]
services/auth-service/internal/handlers/registration.go
Executor (Interface)
Executor defines the interface for running tasks. [2 implementers]
clients/provider-daemon/internal/executor/executor.go
LoadBalancer (Interface)
LoadBalancer defines the interface for selecting a backend server. [1 implementers]
services/api-gateway/internal/loadbalancer/balancer.go
ObjectStorage (Interface)
ObjectStorage defines the interface for interacting with an object storage backend. [1 implementers]
services/storage-service/internal/storage/interface.go
JobStore (Interface)
JobStore defines the interface for storing and retrieving job state information. This allows for different backend imple [1 …
services/scheduler-orchestrator-service/internal/store/jobstore.go
ImportMetaEnv (Interface)
(no doc)
clients/console/src/vite-env.d.ts
ProviderStore (Interface)
ProviderStore defines the interface for provider storage operations. This allows different storage backends to be used i [2 …
services/provider-registry-service/internal/store/providerstore.go

Core symbols most depended-on inside this repo

Error
called by 665
services/billing-payment-service/internal/models/errors.go
String
called by 610
cmd/provider/main.go
String
called by 168
clients/provider-daemon/internal/models/status.go
Close
called by 126
services/scheduler-orchestrator-service/internal/store/jobstore.go
respondError
called by 125
services/auth-service/internal/handlers/registration.go
append
called by 119
clients/console/src/hooks/useLogSocket.ts
Get
called by 102
services/auth-service/internal/session/redis_store.go
Scan
called by 94
services/scheduler-orchestrator-service/internal/models/job_record.go

Shape

Method 652
Function 437
Struct 309
Interface 40
TypeAlias 16
Class 2
FuncType 1

Languages

Go89%
TypeScript11%

Modules by API surface

cmd/provider/main.go84 symbols
cmd/rental/main.go50 symbols
services/auth-service/internal/handlers/registration.go30 symbols
services/ory-kratos-integration/main.go26 symbols
services/billing-payment-service/internal/covenant/onchain.go26 symbols
services/auth-service/internal/session/redis_store.go26 symbols
services/redis-cache-service/main.go25 symbols
services/provider-registry-service/internal/handlers/provider.go25 symbols
services/gpu-monitoring-service/main.go25 symbols
clients/provider-daemon/internal/gpu/detector.go24 symbols
services/auth-service/internal/handlers/two_factor.go22 symbols
services/scheduler-orchestrator-service/internal/k8s/scheduler_extender.go21 symbols

Datastores touched

dante_billingDatabase · 1 repos
dante_registryDatabase · 1 repos
dante_auth_testDatabase · 1 repos
dante_schedulerDatabase · 1 repos
dantegpuDatabase · 1 repos
dante_registry_testDatabase · 1 repos
danteDatabase · 1 repos
dante_authDatabase · 1 repos

For agents

$ claude mcp add dantegpu-core \
  -- python -m otcore.mcp_server <graph>

⬇ download graph artifact