Pay.sh and the Provenance Gap

Pay.sh shipped this week. It is a discovery and access toolkit for AI agents from the Solana Foundation and Google Cloud, with a payable catalog of API endpoints reachable via x402. The launch is real, the underlying primitive is the right one, and the catalog is broader than any single platform has shipped before in agent commerce.

The Bankless coverage of the launch named the gap precisely. Quoting:

“the broader catalog doesn't make it obvious which endpoints (beyond Google's) are first-party, which are authorized third-party integrations, and which are unauthorized.”

The same author had previously documented x402's “authorization problem,” observing that “many live endpoints acted as unauthorized third-party wrappers in clear violation of the underlying APIs' terms of service.”

That gap is exactly what Treebeard exists to fill. We pulled the public Pay.sh registry, classified all 72 providers under the Treebeard provenance taxonomy, and published the labeled catalog. The labels live at /research/pay-sh-provenance. This post is the argument behind them.

The four-tier taxonomy

Provenance for an agent commerce endpoint is not a binary. It is at least four-state. Collapsing the states into one yes-or-no flag is the same kind of structural simplification that produced the “rated or not rated” failure mode in the bond ratings industry pre-2008. Treebeard's taxonomy distinguishes the four:

Tier A. First-party native. The provider operates the service. AgentMail runs x402.api.agentmail.to. Quicknode runs x402.quicknode.com. Provenance is direct. There is no intermediary whose authorization status needs verification. The trust question is about the provider, not the gateway.

Tier B. Authorized gateway. The Solana Foundation operates a documented gateway to a partner's API. The 47 solana-foundation/google/* and solana-foundation/alibaba/* endpoints fall here. The authorization is visible because the gateway is the official integration vehicle for those partnerships, named on Pay.sh's launch materials. Provenance is verified by the structural fact that the Solana Foundation is the operator and the underlying providers are the named partners.

Tier C. Aggregator product. A third party bundles multiple underlying APIs into a branded product. StableCrypto from Merit Systems aggregates CoinGecko, DefiLlama, Alchemy, and Etherscan into a single paid surface. The Merit Systems brand is first-party for the bundle. The underlying APIs are not necessarily aware of, or authorizers of, the bundle. The provenance question is in the aggregation layer, not the brand.

Tier D. Pass-through wrapper. A third party wraps a single named upstream provider and republishes the API at a different URL with a payment layer. Wolfram Alpha, Perplexity, CoinGecko, RentCast, and seven others appear in the catalog as paysponge/* wrappers. The wrapper's authorization with the upstream is not visible from the catalog. This is the failure mode the Bankless author specifically named.

What the labels actually say

Tier A: 6 providers. Tier B: 47 providers (the Solana Foundation authorized gateways). Tier C: 8 providers (Merit Systems aggregated products). Tier D: 11 providers (paysponge pass-through wrappers).

Two-thirds of the catalog is the Solana Foundation gateway pattern. That is the credible-by-design subset and arguably the strongest argument for Pay.sh as a launch. The remaining third splits between native operators (Tier A, clean), branded aggregators (Tier C, provenance question lives in the aggregation), and pass-through wrappers (Tier D, provenance question lives in the wrapping).

None of this asserts that any specific Tier C or Tier D provider is unauthorized. Some are. Some are not. The catalog does not say. The classification names where the authorization question lives, so a counterparty deciding whether to integrate against a given endpoint knows what they need to verify.

Why this is the right shape for the trust layer

The structural argument the Treebeard methodology v4.0 develops is that trust scoring for autonomous agents requires three things at minimum: a category framework that distinguishes between the structurally different ways trust can fail, source-conflict discounting that down-weights signals from interested parties, and time-decay weighting that ages out stale evidence. Provenance classification of the kind Pay.sh is missing is an input to all three.

The category framework: provenance is a Community-and-Ecosystem signal at the catalog layer (does the upstream provider attest to the wrapper?) and a Security-Posture signal at the operational layer (is the wrapper a credible custodian of the API token, credentials, and traffic?). The seven categories already cover this surface; what was missing was the operationalization for Pay.sh specifically.

The source-conflict discount: a wrapper that exists primarily to capture margin from a providers' API has a structural conflict with the upstream provider. Without a partnership, the wrapper's incentives diverge from the upstream's. The discount for self-attested authorization is high in this case, by structural design.

The time-decay: a wrapper's authorization status is not durable. A partnership can end. An upstream can revoke API access. A static label of “authorized as of launch” decays into stale evidence within months. The methodology explicitly weights this.

Each of these is in the v4.0 whitepaper. What this post and the labeled catalog do is apply that framework to one specific real catalog at one specific real time, in a way that fills the gap a credible journalist named publicly.

Multi-chain proof

One adjacent point that matters for Treebeard's positioning: Pay.sh is a Solana Foundation initiative. The catalog endpoints are accessed via x402, which is chain- agnostic in design. The Treebeard rating layer is multi-chain by construction. Applying the same provenance taxonomy to Pay.sh as we do to ERC-8004 agents on Ethereum and Base is a single technical motion. The taxonomy is the same. The signal sources are different. The composite produces comparable letter grades across chains because the methodology does not depend on chain-specific primitives. One taxonomy, multiple chains, one comparable rating.

What we are not claiming

We are not claiming any specific Tier D wrapper is unauthorized. The classification is structural. The question of whether @paysponge has a partnership with Wolfram Alpha, Perplexity, CoinGecko, or any other named upstream is a verification question that is answerable but not currently answered. Wrapper operators with documented partnerships should be reclassified upon evidence.

We are not claiming the Solana Foundation gateway pattern is the only credible model. Tier A native operators are equally credible by structural design. The taxonomy treats Tier A and Tier B as comparably authoritative; the difference is who operates the gateway, not how trustworthy the resulting endpoint is.

We are not claiming Treebeard's classification is the final word. The taxonomy is published. The classification logic is reproducible from a few lines of code against the public Pay.sh registry. Disagreements with specific labels go through the dispute process at /methodology/improve.

The argument in one sentence

The provenance gap that the Pay.sh launch coverage named is exactly the gap Treebeard's methodology was designed to close, and the labeled catalog at /research/pay-sh-provenance is what closing it looks like in practice.

For the methodology behind the taxonomy, see the v4.0 whitepaper. For agent-rating context, see the /learn explainer. For the structural argument behind why opaque catalogs are a 2008-style failure mode, see The 2008 question.