User Flow & Gateway

This page walks the runtime path of a session on the hosted platform — from connecting a wallet to running GPU workloads — and how the gate, scheduler, and billing loop interact. For the static component map, see Architecture.

1. Web3 authentication & deposit-credit

Users prove wallet ownership with an EIP-191 challenge signature. Once authenticated, the gate returns a discount quote based on the wallet's on-chain AXGT balance; paying the discounted ETH amount to the revenue wallet credits minutes after confirmation.

Connect wallet

The UI requests a challenge: GET /api/auth/challenge?wallet_address=0x….

Sign the challenge

The wallet signs with personal_sign; the gate verifies the signature matches the address and issues an auth token.

Get a discount quote

GET /api/discount/quote reads AXGT balance via JSON-RPC balanceOf, resolves the tier, and returns the minimum ETH and expected minutes.

Deposit & verify

The user sends discount-adjusted ETH and posts the tx hash to /api/auth/verify-deposit. The gate polls for ≥ 6 confirmations, then credits minutes to the ledger.

text

User → UI:   Connect wallet
UI → Gate:   GET /api/auth/challenge?wallet_address=0x…
Gate → UI:   signed challenge message
User → UI:   personal_sign(challenge)
UI → Gate:   POST /api/auth/verify-wallet (signature)   → auth token

UI → Gate:   GET /api/discount/quote?wallet_address=0x…
Gate → Eth:  balanceOf(wallet)                            → AXGT balance
Gate → UI:   discount quote (min ETH, expected minutes)
User → Eth:  send discount-adjusted ETH → revenue wallet  → tx_hash
UI → Gate:   POST /api/auth/verify-deposit (tx_hash)
  loop every 10s: Gate → Eth: receipt + confirmations (need ≥ 6)
Gate → DB:   record verified tx, credit minutes
Gate → UI:   verified: true, remaining_minutes

2. GPU session scheduler

When claiming a session, the client selects a resource profile (Small / Medium / Large / Max). The scheduler assigns physical GPUs exclusively; under contention, users are queued fairly based on runnability.

text

User → UI:   Claim session (profile)
UI → SM:     POST /api/session/claim (requested_profile)
SM → DB:     query remaining_minutes
  if credits insufficient → error
  else if free GPUs ≥ profile GPUs:
       SM assigns exclusive GPU IDs
       SM → SL: launch session
       SL → Docker: run --gpus '"device=ID1,ID2"'
       SM → UI: launch details + WebSocket token
  else:
       SM → queue (FIFO, schedulability-aware)
       SM → UI: queueing (position, reason)

3. Billing heartbeat

During an active session the client sends heartbeats; the manager deducts elapsed minutes weighted by the profile's GPU count. When credit reaches zero the session is stopped.

text

loop every 30s:
  UI → SM:  POST /api/session/heartbeat (session_id)
  SM → DB:  deduct elapsed_minutes × GPU_weight
  if remaining_minutes ≤ 0:
       SM → SL: stop session → Docker stop & remove
       SM → DB: mark terminated (credits exhausted)
       SM → UI: session ended
  else:
       SM → UI: ok, remaining_minutes

No free trial

Access is strictly conditional on remaining_minutes > 0 from at least one verified deposit. There is no time-limited trial.

Endpoints at a glance

Endpoint	Method	Purpose
`/api/auth/challenge`	GET	Issue an EIP-191 challenge for a wallet
`/api/auth/verify-wallet`	POST	Verify the signature, issue an auth token
`/api/discount/quote`	GET	Tier + discount quote from on-chain AXGT balance
`/api/auth/verify-deposit`	POST	Verify a deposit tx and credit minutes
`/api/session/claim`	POST	Claim a GPU profile (or queue)
`/api/session/heartbeat`	POST	Keep the session alive and bill credits
`/api/config`	GET	Public chain/UI configuration

Continue to Tokenomics & AXGT for the pricing and discount model.