Proxygate: The clearinghouse of machine commerce

Revision note (v1.1): reframes Proxygate as the neutral clearinghouse of machine commerce (metering, netting, settlement) built on tradeable API capacity, treats agent-payment standards as supported rails rather than competitors, and updates the MCP, catalog, and competitive sections to the current product. February 2026 (v1.0) is the prior public revision.

Abstract

AI agents are the fastest-growing class of software consumers, yet they cannot open accounts, present credit cards, or manage API credentials. The buyer in this market is the AI agent and its operator: traders, quants, and analysts ride along through the same account. Proxygate gives them the infrastructure to operate autonomously: deposit USDC, discover and purchase curated API access, pay per use, and get work done, all without human intervention.

Proxygate is the neutral clearinghouse of machine commerce. It does for software-to-software trade what a clearinghouse does for any market: it meters every transaction (a platform-signed receipt for each call), nets thousands of micro-transactions into a single settlement, and settles to both the buyer and the seller. That clearing function sits on top of the only supply that is genuinely unique: tradeable API capacity, where sellers resell quota, capacity is pooled, and credentials are handled server-side so they are never shared.

Every entry in that ledger hangs off one identity: the account that binds an agent, its operator, and what it is allowed to do. Balances, signed receipts, and reputation accumulate per identity, which is what makes the clearinghouse durable. Payment rails and agent-payment standards (x402, AP2, and their successors) are supported rails into this ledger, not competitors. The rails are the doors; the ledger is ours. No existing platform combines tradeable capacity with a clearing ledger that meters, nets, and settles across every rail. Proxygate does.

1. The Problem

1.1 Agents Cannot Pay for Things

The AI agent market reached $7.63 billion in 2025 and is projected to grow to $183 billion by 2033 ^[8]. Gartner predicts 40% of enterprise applications will feature task-specific AI agents by 2026 ^[9]. By 2028, AI agents are expected to intermediate more than $15 trillion in B2B purchasing decisions ^[10].

Yet agents face a fundamental access problem. To use an API, an entity must create an account, provide payment credentials, agree to terms of service, and manage API keys. These are human processes. An AI agent cannot sign up for an OpenAI account, cannot present a credit card, and cannot navigate a registration flow. Today, every agent that calls an API does so through credentials provisioned by a human.

Agent capabilities scale with compute. Agent access scales with human administrative effort. This bottleneck limits what agents can do.

1.2 API Capacity Goes to Waste

The global public cloud market reached $723 billion in 2025 ^[1]. Within that market, waste is structural. The Flexera 2024 State of the Cloud Report found that enterprises waste 27% of their cloud spend ^[2]. The Harness "FinOps in Focus" report projected $44.5 billion in cloud infrastructure waste for 2025 ^[3].

API services follow the same pattern. Providers sell capacity in fixed tiers: a team purchases an API plan rated for 10,000 requests per minute but routinely uses 3,000. The unused 7,000 requests per minute expire silently. Enterprise LLM API spending alone doubled from $3.5 billion to $8.4 billion between late 2024 and mid-2025 ^[4].

OpenAI's API generates over $1 billion in monthly revenue ^[5]. Anthropic reached $14 billion in annualized revenue ^[6]. Google's Gemini APIs processed approximately 85 billion calls by August 2025 ^[7]. All sell capacity on fixed tiers that inherently create waste.

On one side: billions in API capacity purchased but underutilized. On the other: millions of agents that need access but lack the means to acquire it. Supply exists, but there is no neutral party in the middle to connect it to autonomous buyers: nobody to meter what each side consumed, net the thousands of tiny transactions into one settlement, and guarantee that buyer and seller each get what they are owed. That is the role of a clearinghouse, and no existing platform fills it for machine commerce.

1.3 Coordinating Agent Work Is Still Unsolved

Agents can call APIs, but coordinating work between them, where one agent attaches a reward to a task and another completes it for payment, remains an open problem. The existing answers are built for humans: freelance platforms require accounts, identity verification, and fiat payments. Proxygate is not shipping a job board, and this is not a product claim. It is an observation that the same escrow primitives Proxygate already runs for settlement (Section 4.4) could serve this coordination layer later, once the core clearinghouse is proven.

1.4 Why Now

Three infrastructure developments converged in 2025.

Autonomous payments on Solana. Sub-second finality and near-zero transaction costs enable per-request payment settlement without human intermediation. USDC on Solana provides the settlement currency.

Stablecoin maturity. Total stablecoin transaction volume reached $33 trillion in 2025, a 72% increase year-over-year ^[13]. Solana surpassed Ethereum in USDC transfer volume in December 2025 ^[14], with stablecoin market cap on Solana tripling to over $14 billion ^[14].

Transaction economics. Solana's average transaction fee is $0.00025 ^[15], compared to $0.44-$1.51 on Ethereum ^[16]. Micropayments, including per-API-call settlements, are economically viable at any scale.

2. Proxygate: The Clearinghouse and Its Pillars

Proxygate is the neutral clearinghouse of machine commerce: it meters every transaction, nets thousands of micro-transactions into one settlement, and settles to both sides, on top of supply that is genuinely tradeable. That clearing function is delivered through three pillars: autonomous payments (the metering and settlement engine), the marketplace (the tradeable supply: curated API capacity with server-side credential handling), and discovery and routing (how agents find and reach that supply). Each pillar works independently but compounds together, and the ledger underneath them is the part competitors cannot copy.

2.1 Pillar 1: Autonomous Payments

Agents deposit USDC to a vault on Solana. The gateway verifies the transaction on-chain and credits the agent's account instantly. From that point, every API call draws from the vault balance, with no further blockchain interaction needed.

Per-request metering happens entirely in-memory using atomic operations. Each credit check completes in sub-millisecond time. Deposits and withdrawals are on-chain (trustless). Everything in between is off-chain (fast).

DEPOSIT (on-chain, infrequent)
  Agent sends USDC --> Gateway verifies --> Vault balance credited

PER-REQUEST (in-memory, sub-millisecond)
  Reserve credits --> Execute API call --> Confirm or Refund

SETTLEMENT (on-chain, batched)
  Aggregate seller earnings --> Batch USDC transfer --> Confirm on-chain

The hybrid model gives agents on-chain security guarantees for their funds with sub-millisecond per-request performance.

2.2 Pillar 2: Marketplace

The marketplace is a curated shelf, not an open long tail. The strategy is depth over breadth in the verticals where agents need a complete task covered end to end: real-world data, market data, prediction markets, and (on the roadmap, legally gated) execution. The shelf is stocked with top providers, regulated exchanges, and alternative-data suppliers, so an agent can complete a whole task (market data plus alternative data plus prediction-market data plus execution) rather than eighty percent of it.

Technically, Proxygate supports seven listing types: proxy (API passthrough), tunnel (expose a local service), skill (AI tool / MCP endpoint), product (digital file), dataset (bulk data access), service (webhook relay), and connector (platform integration). Sellers specify pricing, capacity limits, and authentication. For API-backed listings, Proxygate handles upstream authentication on the seller's behalf: the buyer never sees the seller's credentials, and the seller never shares them (Section 3 details the isolation guarantees).

Trial tier (roadmap). Every paid listing gets a seller-defined free sample portion: a number of calls, a volume of data, or a window of possibly delayed data. Each trial is metered at price zero and limited to one per verified identity, so a buyer can evaluate data before committing without a procurement cycle, and trials cannot be farmed with throwaway wallets. Trial-to-paid conversion becomes the quality metric of the shelf.

When an agent makes a request, the gateway:

1. Validates the request against the seller's allowed paths
2. Reserves credits atomically (check balance + deduct in one operation)
3. Checks capacity against the seller's sliding window limit
4. Retrieves the key from the vault (cached, 30s TTL)
5. Injects the key into the upstream request
6. Proxies the request (including SSE streaming for LLMs)
7. Confirms the charge on success, or refunds on failure

Sellers never share their keys. Agents never see the keys. The gateway is the only component that touches credentials.

Sellers can list any REST API (OpenAI, Anthropic, Twilio, Google Maps) or connect their own agents, datasets, and tools, subject to the curated shelf described above. When multiple sellers list the same service, the gateway routes each request to the best seller based on price, uptime, latency, and available capacity.

2.3 Pillar 3: Discovery & Routing

Proxygate is not just a proxy: it is a discovery and routing layer. Two mechanisms:

Catalog. GET /v1/apis returns a machine-readable catalog of every listing (APIs, skills, datasets, services, products, and connectors) with pricing, capacity, and seller health scores. The same catalog is exposed to agents over MCP (Section 9). Agents programmatically discover the best option for their task without human guidance.

Multi-seller routing. When several sellers list the same service, the gateway picks per request on price, uptime, latency, and available capacity, so the buyer holds one balance and the platform routes to the best supply (Section 6).

3. Key Isolation

The fundamental guarantee of Proxygate is that sellers never share their API keys with anyone.

Keys are encrypted at rest in the vault. They are decrypted exclusively in the gateway's process memory at the moment of injection, and discarded immediately after. Keys never appear in logs, error messages, database records, or API responses.

Exfiltration prevention. API providers often return identifying information in error responses: organization IDs, key prefixes, account ARNs. Proxygate uses a response header allowlist (not a blocklist): only explicitly approved headers are forwarded. All upstream error bodies are replaced with standardized Proxygate errors.

Seller control. Sellers can pause, unpause, rotate keys, and delete listings at any time. After upload, keys are masked to the last four characters. The full key is never visible again.

4. Credit System

4.1 Reserve-Execute-Confirm

Every API call follows a three-phase credit lifecycle, executed entirely via atomic Redis scripts (Lua). No operation can be partially applied: each script runs as a single instruction with no race conditions under concurrent load.

Reserve. A single Lua script atomically: checks for duplicate request IDs, verifies the cached balance is sufficient, deducts the estimated cost, and creates a reservation key with a 30-second TTL. If the balance cache has expired, the gateway fetches the on-chain vault balance, subtracts all unsettled ledger entries (preventing double-spend after cache refresh), caches it, and retries.

Execute. The gateway proxies the request to the upstream API. Reserved credits are held, deducted from the buyer's available balance but not yet allocated to the seller.

Confirm. On success, a second Lua script deletes the reservation key. The deducted amount stays subtracted from the cache. A ledger entry is written atomically (checking cooldown status in the same script) recording the seller payout, platform fee, and request metadata. The ledger entry is what triggers eventual on-chain settlement.

Refund. On failure (upstream error, timeout, or non-success response), a Lua script reads the reservation amount, deletes the reservation key, and adds the amount back to the cached balance. All in one atomic operation.

4.2 Anti-Frontrunning: Why Buyers Cannot Cheat

The system is designed so that a buyer cannot consume API calls and then withdraw their funds before settlement. Four mechanisms work together:

1. Withdrawal cooldown. When a buyer requests a withdrawal, a cooldown key is set in Redis. The same Lua script that writes ledger entries checks for this cooldown key atomically: if the buyer is in cooldown, new proxy requests are rejected. The buyer cannot make API calls and withdraw simultaneously.

2. Unsettled deduction on cache refresh. When the balance cache expires (30-second TTL) and is re-fetched from the on-chain vault, the gateway subtracts all unsettled ledger entries from the on-chain balance before caching. This means the cached balance always reflects reality: on-chain funds minus what has already been consumed but not yet settled. A buyer cannot exploit cache expiry to "reset" their available balance.

3. Withdrawal co-signing. On-chain withdrawals require both the buyer's signature and the platform's co-signature. The gateway only co-signs after verifying the requested amount against the buyer's available balance (on-chain minus unsettled). A buyer cannot drain their vault unilaterally.

4. Skim detection. If, despite all protections, a settlement transaction fails because the on-chain vault has insufficient funds (Anchor error 6001), the buyer is permanently flagged. The skim:{wallet} key is set in Redis, the vault_accounts record is marked is_flagged = true, and all unsettled ledger entries are forfeited as penalty. The buyer can no longer use the platform. Sellers are not affected: the forfeited entries represent the platform's loss, not the sellers'.

4.3 Capacity Fence

Sellers declare total capacity, reserved-for-self, and available-for-resale. The capacity fence enforces these boundaries using a sliding window counter (Redis ZSET with atomic Lua script). Marketplace traffic can never consume the seller's reserved capacity.

4.4 Task Escrow

This describes a protocol capability of the escrow layer; it is not an active marketplace product today.

Task payments use the same vault balance. When a poster creates a task, the reward plus platform fee is atomically deducted from their vault balance. On approval (or auto-release after the review deadline), the reward minus the solver fee is credited to the solver's vault. On cancellation, the full amount is refunded.

The escrow flow:

1. Create: Deduct reward + buyer fee from poster's vault
2. Claim: Solver recorded
3. Submit: Work submitted, review deadline starts
4. Approve: Reward minus seller fee credited to solver's vault
5. Auto-release: If poster does not review within deadline, solver is paid automatically
6. Cancel (only when open): Full refund to poster

5. Payment System

5.1 On-Chain Deposits and Withdrawals

Agents deposit USDC to a program-controlled vault on Solana. The gateway verifies the transaction on-chain and credits the buyer's ledger. Withdrawals reverse the process: the gateway debits the ledger and initiates a USDC transfer back to the agent's wallet, co-signed by the platform for security.

5.2 Hybrid Credit Model

A naive approach would execute a blockchain transaction for every API call. This is impractical: Solana confirmation takes 400-600ms, and at scale the cumulative gas costs become significant.

Proxygate uses a hybrid model: on-chain for deposits and withdrawals (trustless), in-memory for per-request metering (sub-millisecond), on-chain for settlement batches (batched every 10 minutes).

5.3 Transaction Security

Replay protection. Every deposit transaction signature is stored in a deduplication set with a 24-hour TTL. Duplicate signatures are rejected.

Settlement idempotency. Each settlement batch has a unique identifier. Partial failures can be retried without double-paying.

Withdrawal co-signing. Withdrawals require both the buyer's signature and the platform's co-signature, preventing front-running attacks where a buyer drains their vault during settlement.

6. Marketplace Mechanics

6.1 Multi-Seller Routing

When multiple sellers list the same API, the gateway scores each per request:

Lower price, higher uptime, lower latency, and more available capacity all produce higher scores. Routing decisions are per-request, not per-session.

6.2 Health Scoring and Failover

The gateway tracks seller health: latency percentiles, error rate, uptime. Underperforming sellers receive less traffic automatically.

On errors: HTTP 429 triggers rerouting to the next seller. HTTP 5xx triggers retry with backoff, then failover. All sellers exhausted returns a clear error with Retry-After.

6.3 Settlement

Seller earnings settle in batched USDC transfers every 10 minutes:

1. Accumulate confirmed credits minus platform fee
2. Assemble batch above minimum threshold
3. Execute USDC transfers on Solana
4. Clear pending balances after on-chain confirmation

6.4 Fee Model

Dual-sided, applied per metered call:

• Buyer pays: price + 5%
• Seller receives: price - 5%
• Platform takes: 10% total

Transparent and predictable. No hidden fees.

7. Revenue Model

Proxygate generates revenue through a single, transparent mechanism:

Platform fee: 10% total (5% buyer-side + 5% seller-side) on every metered call. Revenue grows one-to-one with routed, paid volume.

No hidden fees, no tiered pricing complexity. The same fee structure applies to every proxy request on the platform. Where Proxygate routes volume to a connected venue, the venue pays affiliate revenue on that volume as a second stream.

8. Security

8.1 Credential Security

Key isolation (Section 3) is the primary control. Encrypted at rest, decrypted only in process memory, never logged, response headers stripped.

8.2 Payment Security

Deposit replay protection, settlement idempotency, withdrawal co-signing (Section 5.3).

8.3 Input Validation

All requests validated against strict schemas. Seller listings specify allowed request paths, and the gateway enforces this before routing. Per-wallet rate limiting with sliding windows. Anomalous patterns trigger throttling.

8.4 Escrow Fraud Deterrents

These deterrents belong to the escrow layer (Section 4.4), a protocol capability rather than an active marketplace product today. Auto-release protects a recipient from a payer ghosting. Wallet blacklist for fraudulent payers via security events. Either party can escalate to platform dispute resolution.

8.5 Risk: Provider Terms of Service

API providers may object to capacity resale. Proxygate addresses this through provider diversification, traffic shaping to match historical patterns, and neutral positioning as infrastructure. As the platform scales, provider partnerships become viable, since increased utilization aligns with provider interests.

9. Agent-Native Design

Proxygate is built for machines, not humans.

9.1 One Identity: The Account of the Clearinghouse

Every entry in the clearing ledger hangs off one thing: a Proxygate account. The account is an identity plus a prepaid balance, and the identity binds three facts together: which agent is acting, which operator it belongs to, and what that agent is allowed to do (scopes, spend budgets, and a kill switch).

Providers attach to this identity rather than to anonymous traffic. A data listing is consumed under it; an operator's own account at an upstream provider or exchange can be linked to it, so that data calls and, on the roadmap and legally gated, order execution run through the same account. That is the one-stop-shop: one identity, one balance, one audit trail, for an operator and every agent in their fleet, with per-agent budgets and limits managed from one treasury.

The same identity also works in the other direction: signing in at an upstream provider with Proxygate credentials. A provider that adds Proxygate as a login option can onboard an agent's operator in one step. Instead of a signup form, the provider receives a verified identity assertion, provisions a new account against it (or links an existing one), and meters that account's usage back to Proxygate. The new upstream account is then billed through the operator's existing Proxygate balance rather than through a separate billing relationship, and every call it makes lands in the same ledger and audit trail. For the provider, this converts inbound agent traffic, which they cannot onboard or invoice today, into billable, verified customers without building agent identity or agent billing themselves. Linking existing accounts (bring your own account) is the nearer-term step; sign-in based provisioning is the direction of the OAuth identity layer described below.

The identity is also what makes the rest of the design enforceable. Verification tiers and future trial allocations are granted per verified identity, which is what keeps free samples from being farmed by disposable wallets. Signed receipts and usage history accumulate per identity, forming books of record an operator can hand to their own accountant or compliance function. And because traffic is attributable to real per-operator accounts instead of one anonymous pool, it stays legitimate in the eyes of upstream providers.

These per-identity assets are the durable ones: the balance on deposit, the receipt history, and a reputation record that can mature into credit terms for proven agents. Rails and protocols change; balances, books, and reputation do not. Proxygate implements and consumes open agent-identity and agent-payment standards rather than competing with them: the account is the clearinghouse's ledger entry, not a bid to own the internet's login. Wallet-based identity is live today; the OAuth-based identity layer (consent, connected applications, and scoped tokens, the basis for signing in to partner services with a Proxygate account) is built and is completing security review before launch.

9.2 MCP Server

Proxygate exposes the marketplace as an MCP server on /mcp (Streamable HTTP), so any MCP-capable agent environment (such as Claude Code, Claude.ai connectors, and compatible clients) can browse, inspect, and buy API access with one integration. The server publishes usage instructions through the MCP instructions field, so a connected agent receives the buy flow automatically.

The server exposes seven tools:

• browse_apis searches the catalog, running the same parallel semantic (vector) plus keyword search as the public catalog. Each result carries the listing id, the service slug, category, buyer price per request, trust and rating hints, and the callable endpoints.
• describe_endpoint drills into one endpoint before spending: parameters, request-body schema, and response schemas, for both OpenAPI and GraphQL listings.
• get_pricing returns per-service pricing (per-request and per-token).
• check_balance returns the wallet's total, available, and pending-settlement balance.
• get_usage returns recent billed requests, cursor-paginated.
• rate_seller records a thumbs verdict on the wallet's most recent successful request to a listing.
• call_api executes a billed call end to end: balance reserve, upstream authentication handled by Proxygate, forward, charge, and a platform-signed receipt.

Public tools (browse, describe, pricing) work without a key; anything that reads a wallet or spends money requires one. The minimal buy flow is two steps: browse_apis(q) to find a listing, then call_api(listing_id, path, method) to call it. Every billed call returns a platform-signed receipt (request id, buyer, seller, amount, timestamp, signature), which is the per-call metering record that feeds settlement.

9.3 CLI Integration

Any CLI-capable agent can use Proxygate through a single tool. proxygate proxy <listing> <path> discovers services, makes authenticated API calls, and manages credits. Works with coding assistants, terminal agents, CI/CD pipelines, and orchestration frameworks.

9.4 SDK Compatibility

Drop-in compatibility with the OpenAI SDK: change only base_url. Response schemas, SSE streaming, and error formats remain identical.

9.5 Programmatic Discovery

GET /v1/apis returns a machine-readable catalog. GET /v1/categories returns service categories. Agents compare price, latency, and availability without human guidance, over either the REST catalog or the MCP browse_apis tool.

9.6 Agents as Distribution

AI agents are both users and distribution. The referral mechanism is on-chain: wallet A refers wallet B, the relationship is recorded as verifiable proof. Referring agents earn incentives proportional to referral volume.

The flywheel: an agent discovers Proxygate, uses it, earns referral incentives, and promotes it to other agents, optimizing ROI continuously, without human intervention.

10. Competitive Landscape

A clearinghouse is defined by the supply it clears and the ledger it keeps, not by the rails money moves on. Two distinctions frame how Proxygate sits in the market.

Payment rails and agent-payment standards are supported, not competitors. x402, AP2, and their successors are open ways for an agent to pay; Proxygate treats each as a door into the same ledger and intends to support the winners as they emerge. The rails are the doors; the ledger is ours. A rail that meters, nets, and settles thousands of micro-transactions and guarantees both sides would stop being a neutral standard and start being a clearinghouse, which is the position Proxygate already occupies. Every rail that wins makes Proxygate more useful, not less.

No existing platform combines tradeable API capacity with a clearing ledger. The genuinely unoccupied ground, verified against the 2026 field, is the marketplace mechanics: two-sided quota resale with server-side credential handling, rate-limit pooling across many credentials to manufacture throughput, and escrow plus seller settlement from one balance. Adjacent products each miss at least one of these.

SF Compute is the closest business model analog: $40M raised at $300M valuation by applying idle capacity resale to GPUs ^[26]. Proxygate applies idle-capacity resale to API access, then adds the clearing ledger (metering, netting, settlement to both sides) and the curated finance and real-world data shelf around it.

11. Roadmap

12. Conclusion

Proxygate is the neutral clearinghouse of machine commerce: it meters every call with a signed receipt, nets thousands of micro-transactions into one settlement, and settles to both the agent and the seller, on top of supply that is genuinely tradeable.

Agents deposit USDC once and reach a curated shelf of API capacity, with sub-millisecond per-request metering and automatic settlement. Sellers monetize unused capacity without sharing credentials. Traders and quants ride along through the same account. Payment rails and agent-payment standards are doors into this ledger, not competitors: every rail that wins makes the clearinghouse more useful.

The timing is structural. Agents are proliferating ^[8][9]. Stablecoins processed $33 trillion in 2025 ^[13]. Solana has sub-second finality at $0.00025 per transaction ^[15]. Enterprises waste 27% of their cloud spend ^[2].

The rails are the doors. The ledger is ours. Proxygate is the clearing layer where machine commerce settles.

References

[1] Gartner, "Worldwide Public Cloud End-User Spending Forecast," November 2024.

[2] Flexera, "2024 State of the Cloud Report," survey of 753 IT professionals, Q4 2023.

[3] Harness / Coleman Parkes Research, "FinOps in Focus," February 2025, survey of 700 engineering leaders.

[4] Menlo Ventures, "2025 Mid-Year LLM Market Update," July 2025, survey of 150 technical leaders.

[5] Sam Altman, statement on OpenAI API revenue, January 2026. Reported by WebProNews.

[6] SiliconANGLE, "Anthropic Closes $30B Round, Annualized Revenue Tops $14B," February 2026.

[7] Google, Q3 2025 earnings call. Gemini API call data reported by Fintool.

[8] Grand View Research, "AI Agents Market Report," 2025.

[9] Gartner, "40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026," August 2025.

[10] Gartner / Digital Commerce 360, "AI Agents to Intermediate >$15 Trillion in B2B Spending by 2028."

[11] Postman, "2024 State of the API Report," survey of 5,600 developers, October 2024.

[12] Stanford HAI, "AI Index Report 2025," inference cost analysis.

[13] Bloomberg / Artemis Analytics, "Stablecoin Transactions Rose to Record $33 Trillion in 2025," January 2026.

[14] Chainstack, "Solana Stablecoins 2026: Solana Surpasses Ethereum in USDC Transfer Volume."

[15] Solana documentation / Backpack, "Solana Transaction Fees."

[16] CoinCodex, "Ethereum Gas Fee Analysis," May-August 2025.

[22] Sacra, "OpenRouter: $100M+ GMV," May 2025. GlobeNewsWire, "$40M Funding at $500M Valuation," June 2025.

[23] GetLatka, "RapidAPI Revenue: $44.9M," October 2024. TechCrunch, "Nokia Acquires Rapid," November 2024.

[24] GitHub, "BerriAI/litellm Repository Statistics," 2025.

[25] GetLatka, "Kong Revenue: $232M," 2025. PRNewswire, "$175M Series E at $2B Valuation."

[26] DCD / eWeek, "SF Compute Raises $40M for AI Compute Marketplace at $300M Valuation," December 2025.