Loading repository data…
Loading repository data…
dante-gpu / repository
Core microservices powering the DanteGPU distributed GPU network. Manages providers, orchestrates AI job scheduling, handles auth, data, and monitoring. Built with Go & Python.
A transparent discovery signal based on current public GitHub metadata.
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
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 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-daemonbilling-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.
flowchart TD
subgraph Clients
FE[console<br/>Vite + React + Tailwind v4]
DAEMON_C[provider-daemon<br/>node agent]
end
GW[api-gateway :8080<br/>chi router, JWT, proxy]
subgraph Services[Go microservices]
AUTH[auth-service :8090<br/>bcrypt + JWT]
REG[provider-registry-service :8081]
GPU[gpu-service<br/>catalog]
RENT[rental-service<br/>reservations]
BILL[billing-payment-service :8082<br/>dGPU pricing + Solana]
SCHED[scheduler-orchestrator-service :8084<br/>NATS consumer]
STOR[storage-service :8083<br/>MinIO]
MON[gpu-monitoring-service :8092]
CACHE[redis-cache-service]
end
subgraph Provider node
DAEMON[provider-daemon<br/>GPU detect, Docker exec]
end
subgraph Infra
PG[(PostgreSQL)]
NATS{{NATS JetStream}}
CONSUL{{Consul}}
MINIO[(MinIO)]
SOL[(Solana devnet<br/>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.
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:
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_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.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.
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.
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.
Kept here so the README never overclaims. Full detail and the plan to close each is in ROADMAP.md.
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.GetUserBalance returns a
hardcoded 100.0 and GetUserWallet returns "not yet implemented"; both are
placeholders pending a real billing client. Live but fake.gpu-monitoring-service collects real
metrics but does not publish usage to billing-payment-service.nvidia-smi), AMD (rocm-smi),
and Apple Silicon (system_profiler), but several VRAM values are hardcoded
mappings rather than queried.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.