Contributing Your Own Provider Key for USDC Credit: What Gets Attributed and How to Audit It

What contributing a provider key means

When you contribute a provider key, you are adding your own upstream credential (for a specific provider and account) to the shared pool. Other callers on the platform can then route traffic through that key. You keep control of the credential and can remove it; the key is not shared back to other users, only used by the routing layer to serve requests.

The economics are deliberately simple:

• Callers pay the official price × 1.3.
• Contributors are credited the official price × 1.1 (or × 1.2 for premium keys) back, in USDC.
• The platform keeps the margin between what callers pay and what contributors earn.

The important idea is that the credit you receive is tied to the calls that were actually served by your key, valued at the provider's official price. It is not a flat fee, a lottery, or a share of overall traffic.

How a contributed key is used in the pool

The lifecycle is roughly:

1. You add the key, identifying the provider, the account, and any capability or tier metadata (for example, whether it should be treated as premium).
2. The key is validated and made eligible for routing.
3. When a caller issues a request that your key can serve, the router may select it based on availability, capacity, and policy.
4. The upstream provider receives the request under your credential, and usage is recorded against the call.
5. That usage event becomes the basis for your USDC credit.

Because routing is demand-driven, a contributed key is not guaranteed to receive a fixed volume. Its earnings depend on how much compatible traffic it serves.

How traffic maps back to your USDC credit

The attribution chain is what you should care about when auditing:

• Call record. Every request produces a record with an identifier, timestamp, model, token counts (input/output or equivalent), and the key that served it.
• Price basis. The record is priced using the provider's official rate for that model and those token counts, on the same date the call ran.
• Contributor credit. Your credit for that record is the official price multiplied by the contributor factor (×1.1 standard, ×1.2 premium).
• Settlement. Credits accumulate and are paid out in USDC on Base, with a ledger entry per period or per batch.

Two consequences follow. First, credits should scale with the real usage of your key, not with a separate estimation model. Second, the numbers in your credit ledger should reconcile against call-level records; if they do not, something in the attribution is wrong and is worth investigating.

What is attributable and what is not

Not every figure you see is part of your credit. Keep these distinctions clear:

• Attributable to you: requests served by your key, valued at official price × contributor factor.
• Not attributable to you: the caller-side surcharge (× 1.3). That is paid by the caller, not passed to you.
• Not attributable to you: requests served by other contributors' keys, even on the same model or account tier.
• Not attributable to you: platform-level fees, retries that were not billed upstream, or calls that failed before any upstream usage occurred.

If a failed call consumed no upstream tokens, there should be nothing to credit. If a call was retried and billed upstream more than once, the credits should follow what the provider actually charged.

A simple audit method

You do not need special tooling to check your credits. A periodic reconciliation is enough.

1. Export the call records for your key for the period. You want the request identifiers, timestamps, models, and token usage.
2. Export your USDC credit ledger for the same period.
3. Recompute the expected credit for a sample of calls. For each sampled call, look up the official price for that model and token mix, multiply by the contributor factor for your key tier, and note the result.
4. Compare expected versus recorded credits. Do this call-by-call for the sample rather than only in aggregate. Aggregate totals can hide offsetting errors.
5. Reconcile the totals. Extend the sample or recompute the full set if the sample shows a mismatch. Check for boundary effects: timezone cutoffs, calls that started in one period and finished in the next, and rounding.
6. File discrepancies with identifiers. If something does not match, include the request IDs, the model, the token counts, the price you applied, and the credit you expected. Specific records are far easier to investigate than a lump-sum discrepancy.

A useful discipline is to audit a small, fixed sample every period. It catches drift early and keeps the reconciliation cheap.

Common sources of mismatch

Most audit differences come from a short list:

• Pricing basis. Comparing against a stale price list rather than the official rate in effect on the call date.
• Tier confusion. Applying the standard contributor factor to a key that is premium, or vice versa.
• Token counting. Comparing provider-reported usage with your own local tokenizer estimates; the provider's figures are the basis.
• Period boundaries. Calls near the cut-off attributed to the neighbouring settlement period.
• Duplicate or retried requests. Upstream billing and platform logs can diverge if retries are handled differently.
• Key rotation. Traffic moving between keys mid-period, so a ledger filtered by key ID misses calls served under an older or newer key.

Checking these first usually resolves a discrepancy without escalation.

Keeping the audit honest over time

A few habits make contributed-key accounting trustworthy:

• Keep a stable identifier for each contributed key and record when it was added, changed, or removed.
• Preserve the contributor factor that applied to each key during each period.
• Keep the call-record export and the credit ledger side by side, so the reconciliation is reproducible.
• Re-audit after any change to routing policy, key tier, or model availability, since these can shift where traffic lands.

The goal is not to distrust the ledger but to make it verifiable. When the call records, the official pricing, and the contributor factor reconcile against your USDC credits, you know the attribution is doing what it claims: paying you for the traffic your key actually served.