Technical documentation

How supa converts bonding-curve fee flow into metered inference for a model-bound asset: transaction layout, vault derivation, settlement maths and trust assumptions.

Architecture overview

supa is a launch and settlement layer on top of two existing systems: the pump.fun bonding-curve program on Solana, and OpenRouter's unified inference API. It adds three components of its own.

  • Launch orchestrator. Builds a single versioned (v0) transaction that mints the asset and locks its fee-sharing configuration in the same slot.
  • Compute vault. A dedicated Solana account per mint that receives 100% of the asset's creator fees.
  • Inference gateway. A rate-limited proxy with two engines: a free-tier preview engine, and the bound model, token-metered against the asset's compute balance.
trade ─▶ pump.fun curve ─▶ creator fee ─▶ fee-sharing config (10,000 bps)
                                                   │
                                                   ▼
prompt ─▶ inference gateway ─▶ OpenRouter ─▶ model   compute vault (per mint)
              │                                        │
              └────── debit(cost_usd) ◀── ledger ◀─────┘

Atomic launch transaction

A launch is one v0 transaction, compressed with an address lookup table to stay under Solana's 1,232-byte packet limit. Instruction order:

  1. createV2: mints the asset and initializes its bonding curve on pump.fun.
  2. buy (optional): the creator's initial buy, executed at curve open in the same transaction, 0 to 50 SOL.
  3. createFeeSharingConfig: opens the asset's fee-sharing account.
  4. updateFeeShares: sets a single shareholder, the compute vault, at 10,000 bps.

Because all four execute atomically, there is no slot in which the asset exists with fees routed anywhere else.

Signing sequence

The server assembles the unsigned transaction and dry-runs it against mainnet state (simulateTransaction, signature verification off) so a launch that would revert never reaches a wallet prompt. The creator's wallet signs first. The gateway then fingerprints every instruction (SHA-256 over program id, account list and data) against what it built, tolerating only wallet-injected compute-budget, Lighthouse assertion, memo and self-funded transfer instructions. Only after that check does the mint keypair co-sign, and the transaction is broadcast and confirmed.

Compute vault derivation

Vaults are hierarchically deterministic. No per-asset key is ever stored: each vault keypair is derived on demand from one master seed and the mint address.

vault_keypair = Ed25519.fromSeed( HMAC-SHA256( master_seed, "sipad-vault:v1:" ‖ mint ) )

The same inputs always yield the same account, so the vault address is known before the launch transaction is built and is written into the asset's metadata.

Fee-to-compute routing

Routing is enforced by pump.fun's fee-sharing program, not by supa's servers. The share table is written once, at launch, with the vault as sole shareholder. Creator fees accrue on the curve and, after migration, on the AMM.

Fees accrue in the asset's fee-sharing account on pump.fun, claimable only to the vault. They count toward the asset's compute as soon as they accrue, read directly from chain; no sweep is needed for the terminal to draw on them. Settlement into the vault happens through distributeCreatorFees, a permissionless instruction that can only pay the shareholders written at launch, and is run periodically.

Compute accounting

Fees are held in SOL; inference is priced in USD. An asset's compute balance is therefore mark-to-market:

fees_earned  = vault_balance + pending_distribution + withdrawn     (SOL)
compute      = fees_earned − inference_spend_usd ÷ SOL_USD          (SOL)
tokens_left ≈ compute × SOL_USD ÷ blended_price × 1,000,000

blended_price = (3 × input_price + output_price) ÷ 4                (USD per 1M tokens)

The blended price assumes a 3:1 read-to-write token ratio. Token estimates and dollar compute move with the SOL price; SOL-denominated fees do not.

Inference terminal

Each asset page exposes a public terminal. Prompting requires no wallet and no holding. The same terminal is available on the launch page before the asset exists, with the draft name, ticker and description as its context.

Inference engines

The gateway routes each prompt to one of two engines, and every reply is labelled with the engine that produced it.

  • Preview engine. A free-tier model selected from OpenRouter's catalogue, with automatic failover. It is never billed to an asset and never presents itself as the bound model. During the bootstrap phase it serves every terminal, while each asset's fees accrue untouched as compute.
  • Paired engine. The asset's bound model, token-metered at the provider's price and settled against the asset's compute. Activated by the operator; once active it answers whenever the asset's compute covers the worst-case cost of the exchange, with the preview engine as fallback.
Prompt lengthup to 2,000 characters
Completion lengthup to 700 tokens
Rate limit4 prompts per minute per visitor
Context memorysliding window of the last 6 messages
System promptasset name, ticker and the creator's description

On the paired engine, the gateway computes a worst-case cost before dispatch and falls back to the preview engine if the asset's compute cannot cover it. After the completion returns, the exchange is settled at the provider-reported cost for the tokens actually consumed, and appended to the asset's ledger. A failed completion is never charged.

On-chain metadata schema

Asset metadata is content-addressed on IPFS and referenced from the mint. Alongside the standard token fields it carries an si extension:

{
  "name": "...", "symbol": "...", "image": "ipfs://...",
  "si": {
    "v": 1,
    "model": "<provider>/<model-id>",
    "computeVault": "<vault address>"
  }
}

Verification

Every asset page links the four artefacts needed to audit it independently:

  • Mint and launch transaction on Solscan: confirms the instruction order above.
  • Fee-sharing config: a single shareholder at 10,000 bps, equal to the vault address.
  • Compute vault: balance and every inbound distribution.
  • Metadata CID: the model binding and vault address as pinned at launch.

Trust model

What is enforced on chain: the asset, its bonding curve, and the routing of 100% of creator fees to the vault.

What is custodial: vault keys are derived from a seed held by supa. Inference is purchased off chain from OpenRouter in USD, and vault SOL is used to reimburse that spend. The compute ledger (spend, tokens, completions) is kept off chain and published on each asset page.

supa takes no platform fee and the creator takes no fee share. Nothing here is an investment product, and a compute balance is not redeemable for SOL.

API responses

429Rate limit exceeded for this visitor.
502No engine returned a completion. Nothing was charged.
503The gateway, the model or the SOL price feed is unavailable.

Launch a coinModel registry

Docs · supa