Credit Economy

Availability in. AI out. Teale runs a closed-loop credit economy. Devices earn Teale Credits for being online and for serving requests. Credits redeem AI inference and can be gifted to other users — they don't cash out. When a user wants more AI than their credits cover, they top up with USDC; that USDC funds the shared pool that backs everyone's credits.

Paying customers never earn USDC on the way out. If the network accumulates surplus USDC (real demand outstrips availability), providers receive more credits, not dollars. That keeps Teale out of the payout-and-reporting regulatory surface and keeps the user-facing unit honest: credits are for AI.

Earning credits

Two components accrue to the same ledger:

• Availability. Every second your device is online and reachable, credits tick up at a steady base rate. Rate scales with hardware tier (Backbone > Desktop > Tablet > Phone).
• Serving. When your device actually handles a request, credits accrue faster based on tokens served, model complexity, and quantization.

Random health-check probes validate that an "online" device can actually serve. Failed probes pause availability accrual until the device recovers.

Why credits don't cash out

Credits are internal utility scrip — same legal category as AWS credits or arcade tokens. Keeping them non-convertible gives Teale:

• A clean regulatory posture. No money-transmitter or payout-reporting obligations.
• No tax headaches for users or the network. No 1099s. No reportable income from participating.
• A durable promise. The closed loop can survive demand volatility without rewriting the rules.

If you want fiat, you can transfer credits to another user privately — that's between the two of you. Teale is not a party to any such transfer.

When the network earns USDC and has more than the pool needs, we issue additional credits to providers. That rewards participation without touching fiat outbound.

Transfers

Credits are freely transferable to any other user. Transfers are immutable and irreversible by design — no chargebacks, no reversal flow, no dispute process. If you send credits to the wrong person or get scammed, the credits are gone. Treat sends like cash.

Internal pricing math

The network uses a transparent formula to price inference internally. Pool accounting is done in USDC; the user-facing unit is credits. The ratio between credits and pool-USDC is tuned over time by the network.

Pricing formula

The cost of an inference request is:

cost = (tokens / 1000) * modelComplexity * quantizationMultiplier / 10,000

The result is in USDC.

Model complexity

Model complexity scales linearly with parameter count:

modelComplexity = parameterBillions * 0.1

Model size	Complexity factor
1B	0.1
8B	0.8
32B	3.2
70B	7.0

Quantization multiplier

Lower precision is cheaper because it uses less memory and compute:

Quantization	Multiplier
q4 (4-bit)	1.0x
q8 (8-bit)	1.5x
fp16 (16-bit)	2.0x

Example

Generating 1,000 tokens on an 8B parameter model at q4 quantization:

cost = (1000 / 1000) * 0.8 * 1.0 / 10,000
     = 0.00008 USDC
     = $0.000080

Revenue split

• Provider earns 95% of the inference cost.
• 5% network fee funds relay infrastructure and development.

For the example above, the provider earns $0.000076 and the network fee is $0.000004.

Electricity cost floor

Providers should never lose money on inference. The electricity floor ensures the effective price always covers the real cost of running the hardware:

electricityCost = (tokens / tokensPerSecond) * (watts / 3,600,000) * costPerKWh * 1.2

The 1.2 multiplier adds a 20% margin over raw electricity cost.

The effective price charged is:

effectivePrice = max(tokenPrice, electricityCost)

If the token-based price is below the electricity floor, the floor price is used instead.

Worked example

Scenario: Running an 8B q4 model on an M4 Pro (38W inference power draw, 50 tokens/second, $0.12/kWh electricity rate). Generating 1,000 tokens.

Token-based price:

tokenPrice = (1000 / 1000) * 0.8 * 1.0 / 10,000
           = $0.000080

Electricity floor:

secondsOfCompute = 1000 / 50 = 20 seconds
kWhUsed          = (38 * 20) / 3,600,000 = 0.000211 kWh
rawCost          = 0.000211 * 0.12 = $0.0000253
electricityFloor = $0.0000253 * 1.2 = $0.0000304

Effective price: max($0.000080, $0.0000304) = $0.000080

In this case, the token-based price exceeds the electricity floor, so the standard price applies. On slower hardware or with expensive electricity, the floor would kick in.

Provider earnings: $0.000080 * 0.95 = $0.000076

WWTN reverse auction

On the public network (WWTN --- Wider World Teale Network), pricing is market-driven via reverse auction:

1. The requestor posts a job with a maximum bid per 1,000 tokens.
2. Available providers automatically bid their floor price plus a margin (floor * 1.1, scaled by demand).
3. The lowest bid wins. Ties are broken by quality score (measured speed and reliability).
4. If no bid comes in under the maximum, the request is not fulfilled.

This creates a competitive market where providers are incentivized to run efficient hardware and keep electricity costs low.

PTN fixed pricing

Private TealeNet members use fixed-rate pricing instead of auctions. The PTN administrator sets the rate, and all members pay the same price. This provides predictable costs and avoids the overhead of the auction mechanism. See Private TealeNet for details.

Wallet mechanics

• Starter balance: New users receive enough credits for ~5 minutes of Qwen3-8B inference to get started immediately after install.
• Minimum balance for remote inference: A few credits. Below this, only local inference is available.
• Local inference is always free. Running models on your own device costs nothing and doesn't draw from your credit balance.
• Credit ledger: All transactions are stored locally in a JSON ledger. Pool accounting is reconciled on-chain via Solana. See Solana Settlement.

Transaction types

Type	Description
earned	Credits received for serving inference
spent	Credits paid for consuming remote inference
bonus	Welcome bonus or promotional credits
adjustment	Manual corrections
transfer	Peer-to-peer credit transfers
sdkEarning	Credits earned via TealeSDK contribution

Scheduling priority

The RequestScheduler uses Weighted Fair Queuing to allocate capacity:

• PTN requests: 70% weight
• WWTN requests: 30% weight
• Zero idle waste: If one queue is empty, the other gets 100% of capacity

This means PTN members always get reliable performance, while WWTN traffic fills any remaining capacity at market rates.

Related pages

• Solana Settlement --- on-chain USDC settlement
• Private TealeNet --- fixed pricing and priority scheduling
• Inference Providers --- the CreditAwareProvider middleware