Product & technical documentation

Build on the pair.

How GPAIR connects a verified Solana coin to provider-backed GPU compute—and exactly which capabilities are live today.

01

Introduction

GPAIR is a Pump.fun launchpad and GPU-pairing network. It records the path from a coin's launch or verified mint to a requested provider resource, then publishes a source-backed Compute Profile.

Core rule

A pair is an association with compute capacity. It is not ownership of physical GPU hardware and is not a promise of token price, yield, revenue or profit.

02

Why GPAIR

A coin can have a transparent compute identity: which GPU was requested, which provider supplied it, whether it is online, what jobs ran, how usage was measured and what compute funding was spent.

01Verified coin
02GPU pair
03Provider resource
04Measured compute

03

Launch + Pair

Prepared, not enabled

The flagship flow captures coin metadata, a GPU model and count, and an optional initial buy. The wallet must sign the inspected Pump.fun transaction. GPAIR then waits for Solana confirmation before it may request a GPU.

  1. 01Create coin metadata
  2. 02Choose GPU capacity
  3. 03Review two cost buckets
  4. 04Sign in wallet
  5. 05Confirm on Solana
  6. 06Provision after confirmation

04

Pair Existing

Live verification

Pasting a mint proves only that the coin exists. The connected wallet must also match the Pump.fun creator, metadata update authority or mint authority. A server-side check decides eligibility.

Ownership is never inferred

A mint address, token balance or browser state alone cannot authorize pairing.

05

Coin → GPU → Compute lifecycle

01Draft
02Wallet signature
03Submitted
04Coin confirmed
05GPU provisioning
06GPU online

Failure states are explicit: launch failed, recovery needed, GPU setup failed, offline, funding depleted and terminated. If a coin confirms but GPU setup fails, the same mint is preserved and only compute may be retried.

launch_id → mint → tx_signature
pair_id → idempotency_key → provider_instance_id
source timestamps → public Compute Profile

06

GPUs

The supported catalog below is stored by GPAIR. Model name and VRAM are catalog data; they do not imply current provider inventory.

ModelVendorVRAM

07

Providers

Provider keys stay on the server. Availability and pricing appear only from live provider reads. Provisioning also requires a separate explicit purchase gate.

08

Compute Profiles

A public profile combines token provenance, authority basis, GPU request, provider lifecycle, workloads, funding, ledger entries, metering samples and audit history. Missing measurements show as unavailable—not zero.

Freshness matters

Provider metrics are shown with their source and timestamps so readers can distinguish requested capacity from measured execution.

09

Workloads

Runtime not enabled

AI inference

Serve prompts to an LLM or vision model

Not available

Image generation

Run diffusion models on demand

Not available

Video generation

Render short AI video clips

Not available

Model hosting

Keep a model online behind an endpoint

Not available

Training

Train models from scratch

Not available

Fine-tuning

Adapt an open model to your data

Not available

Community jobs

Holders or users submit compute jobs

Not available

Planned lifecycle: queued → starting/provisioning → running → completed, failed or cancelled. The product does not expose a submit button until provider-backed execution exists.

10

Funding & Costs

Bucket A

Pump.fun + Solana

Initial buy, network fee and launch service costs shown before wallet signing.

Bucket B

GPU compute

Separate SOL or USDC funding with its own ledger and provider-measured spend.

The buckets are never mixed. Compute deposits remain disabled.

11

Wallet / Solana Security

  • Wallet sign-in uses a one-time message and authorizes no transfer.
  • GPAIR never receives private keys.
  • The launch transaction is checked for payer, signers, mint, allowed programs, buy cap and unexpected SOL transfers.
  • Owner-only actions are enforced by the server and recorded in audit history.

User custody

The user signs. GPAIR never automatically trades or spends wallet funds.

12

Failure & Recovery

Launches and pair requests have stable idempotency keys. Reconciliation checks Solana and provider state after timeouts or reloads. The original mint, signature and provider resource identity are retained.

01Detect interruption
02Read chain/provider
03Restore same record
04Retry only failed stage

13

System Status

This panel derives values from current configuration, Solana health and recent metering—not marketing copy.

14

FAQ

Do holders own the GPU?

No. A pair is a compute association, not hardware ownership.

Can anyone pair a mint?

No. A qualifying on-chain authority must match the connected wallet.

Are missing metrics treated as zero?

No. GPAIR labels them unavailable until a source measures them.

Can a retry create another coin or GPU?

The architecture uses persisted identities and idempotency keys to reuse the same launch and resource.

Can workloads run now?

No. The model and lifecycle exist, but provider-backed runtime execution is not enabled.

15

Current Limitations

  • Pump.fun launching is prepared with unsigned transaction assertions but remains locked until a funded test is explicitly approved.
  • RunPod inventory requires its server credential; paid provisioning also requires a separate approval gate.
  • Compute deposits and workload execution are not enabled.
  • No provider-backed GPU should be described as online until provider confirmation exists.

Current safety boundary

This product-design pass does not broadcast Solana transactions or purchase GPUs.