A stablecoin routing provider scorecard is a fixed set of criteria for judging how a service moves USDC or USDT between blockchains, scored only from evidence the provider publishes. This page sets out six criteria, the evidence each one accepts, and how to apply them to two kinds of provider: rails, which carry messages or mint and burn tokens (Circle's CCTP, USDT0 on LayerZero, Wormhole, Hyperlane), and routing layers, which select a path and deliver funds on top of those rails (Across, Eco Routes). For example, CCTP publishes per-chain attestation times, from about 8 seconds to hours depending on the source chain (Circle finality and block confirmations).
​

Last reviewed: Nov 2026. The scorecard is a method, not a ranking. Examples below show what each criterion looks like when scored from a provider's own pages.
​

The scorecard measures six things a treasury or product team needs before routing funds: the token that arrives, the published settlement time, the fee model, the verification model, chain and asset coverage, and public disclosures. Each criterion has an evidence rule, so two reviewers scoring the same provider reach the same answer.
​

Each criterion scores 0, 1 or 2. Zero means no public evidence, one means partial or qualitative evidence, and two means specific, dated, linkable evidence on the provider's own domain. Third-party summaries never count. A provider that declines to publish something scores zero on it, which is a fact about disclosure, not a judgment of the service.

Weights are left to the reader. A payments team may double criterion 1 and criterion 3; a market maker may double criterion 2. The rule is to fix weights before scoring, not after.
​

The blocks below apply the same template to six providers, rails first and routing layers second. Every statement is drawn from the provider's own documentation as fetched in November 2026. Scores are omitted on purpose: the template shows which evidence exists so each reader can weight it.
​

Best for: native USDC between the chains Circle supports.
​

Pros: per-chain Fast and Standard attestation tables; Standard Transfers carry no USDC protocol fee, and Fast fees come from a public API (Circle CCTP fees). A public status page reported 98.99% 90-day uptime for the CCTP group on November 11, 2026 (Circle status).
​

Cons: USDC only; Fast Transfers sit under a global allowance (Circle finality).
​

Best for: USDT across the 24 networks USDT0 lists as native deployments (USDT0 deployments).
​

Pros: public audit repository and a 3-of-3 DVN requirement (USDT0 security); Legacy Mesh fee of 0.03% stated (USDT0 Legacy Mesh).
​

Cons: no published transfer times on the pages reviewed.
​

Best for: fast fills between major EVM chains through a Swap API.
​

Pros: states about 2-second fills and 24 chains (Across docs); documents its optimistic verification and bond model (Across security model).
​

Cons: the status page is password-protected, so criterion 6 has less public evidence.
​

Best for: applications that want intent-based transfers across EVM, Solana and Tron chain types from one API.
​

Pros: documents its intent, solver and prover flow, including Hyperlane and LayerZero prover adapters and CCTP as a possible transport leg (Eco provers); publishes four Cantina audit reports in its contracts repository (eco-routes audits).
​

Cons: no static chain list or fee schedule; both come from the API at quote time.
​

Best for: teams that want a guardian-signed messaging layer.
​

Pros: documents a 13-of-19 guardian threshold and 29 completed third-party audits (Wormhole security).
​

Cons: a messaging rail, so token outcome depends on the token standard built on it.
​

Best for: teams that want configurable security modules per route.
​

Pros: lists audits from several firms on a public page (Hyperlane audits).
​

Cons: like other messaging rails, times and fees depend on the application configuration.
​

Rails and routing layers answer different questions, so scoring them on one list hides the difference. A rail defines how a message or token crosses chains. A routing layer chooses among rails and liquidity to deliver a specific outcome, often by fronting funds. Many routing layers use rails underneath, so the two are complements.
​

The layering is visible in documentation: Eco's prover inventory includes Hyperlane and LayerZero adapters and treats CCTP as a token-transport leg rather than a prover (Eco provers). For a provider comparison built on these ideas, see cross-chain USDC and USDT routing compared.
​

A documentation-based scorecard rewards providers that publish more, which is not the same as performing better. It cannot see private SLAs, negotiated fees or incident histories that are not posted. It also ages quickly, because chain lists and fees change between reviews.

The grid below fills four of the six criteria with the evidence each provider published when this page was reviewed. It is the raw input a reviewer would score, not a score. A cell reading "not on pages reviewed" earns zero under the rubric until the provider publishes the item on its own domain.
​

Two patterns show up. Rails publish more about verification, because their security model is the product. Routing layers publish less about fixed fees, because they price per quote, which caps them at one point on criterion 3 under this rubric.
​

The method only works if every reviewer follows the same order. Weights come first, evidence collection second, scoring third. Skipping ahead lets a favorite provider shape the weights, which defeats the point of a fixed rubric and makes two reviews of the same provider impossible to compare.

CCTP shows what a two-point fee model looks like. The Fast Transfer fee is retrieved from a public endpoint, GET /v2/burn/USDC/fees, and the sender sets a maxFee cap; if the actual fee exceeds that cap, the transaction reverts instead of overcharging (Circle CCTP fees). A fee that is retrievable before signing and bounded by the sender meets the evidence rule even though the amount itself changes.
​

These are the questions reviewers ask most when they first apply the scorecard.
​

Weights depend on the use case. Publishing totals would impose one team's weights on every reader.
​

Yes, with the same six criteria, though exchanges rarely publish per-chain times.
​

Monthly, or whenever a provider changes its chain list or fee page.
​

No. The scorecard measures how much specific evidence a provider publishes. It does not test contracts, audit operations or judge the safety of any service.
​

Its documentation site, its official code repository and a status page it operates. News coverage, aggregators and third-party dashboards do not count.
​

Every provider statement on this page comes from the provider's own documentation, fetched on November 11, 2026. No provider reviewed or approved its entry.