No real fan-out growth in wallet alignment/Solana account creation — earlier reading was a release-mixture artifact (see #45574)

**Parent Epic:** [#43410 - Sentry Quota Breach Incident — Extension Telemetry](https://github.com/MetaMask/metamask-extension/issues/43410)
**Related:** [#45574 - Multichain account creation fan-out returned to 6x its post-fix level](https://github.com/MetaMask/metamask-extension/issues/45574) · [#43633 - Investigate and cap multichain account creation/syncing span fan-out](https://github.com/MetaMask/metamask-extension/issues/43633) (closed 2026-07-15)
**Source:** `@metamask/multichain-account-service` — `MultichainAccountWallet` alignment loop and non-EVM account creation
**Size:** M | **Priority:** P1

---

## Correction (2026-08-17) — the 1.4–1.6x reading does not survive a release-pure comparison

[#45574](https://github.com/MetaMask/metamask-extension/issues/45574) found the actual mechanism behind this cluster's fan-out swings: [PR #42867 (Sentry SDK v10 upgrade)](https://github.com/MetaMask/metamask-extension/pull/42867) (Sentry SDK v10, shipped in `13.42.0`) replaced this extension's manual `traceparent` construction with the SDK's native propagation, and the pre-fix `13.41.0` release had structurally elevated fan-out across every family in this service — not just `Provider Create Accounts (v2 - batched)`.

The 1.4–1.6x figures below were computed by comparing a May window (predates `13.41.0` entirely) against an August window that blends `13.41.0` and `13.42.0`/`13.43.0` traffic together. Split by release, the picture is different:

| Family | May (release-pure, `13.28.0`–`13.31.0`) | Now (release-pure, `13.42.0`/`13.43.0`) |
|---|---|---|
| `Wallet Alignment` | 1.59 – 2.01 | 1.37 – 1.41 |
| `Create Solana Account Batch` | 1.55 – 1.92 | 1.36 – 1.46 |
| `Wallet Create Multichain Account Groups` | 1.74 – 2.07 | 1.23 – 1.29 |

On current releases, fan-out for all three families is **at or slightly below** the May baseline, not above it. There is no real growth here — the earlier reading was the same release-mixture artifact that made the aggregate for `Provider Create Accounts v2` look like a live regression instead of an attrition curve.

**Recommend closing this ticket** as resolved by the same fix as [#45574 (the Provider Create Accounts v2 fan-out ticket)](https://github.com/MetaMask/metamask-extension/issues/45574), with no separate action needed. The "why this is filed separately" and "is this even a defect" reasoning below is kept as the record of how the original (now-superseded) reading was reached, not as live guidance.

---

## Problem *(original framing, superseded above)*

Three transaction families from the same service as [#45574](https://github.com/MetaMask/metamask-extension/issues/45574) show a modest but consistent rise in fan-out — transactions emitted per trace — since May. This is smaller than a share-based reading suggests, and the correction is recorded below because it changes how the ticket should be prioritised.

Measured 2026-08-17, project `metamask` (273505), production, matched 4-day windows.

| Family | 19–23 May | 4–8 Aug | Multiple |
|---|---|---|---|
| `Wallet Alignment` | 1.81 | 2.76 | 1.5× |
| `Create Solana Account Batch` | 1.73 | 2.72 | 1.6× |
| `Wallet Create Multichain Account Groups` | 1.89 | 2.57 | 1.4× |

**Transactions per trace is the metric here, deliberately.** The retention decision is taken per trace and is constant within one, so this ratio is unaffected by sampling, by the spike, or by changes in total volume — it is comparable across windows in a way absolute counts and shares are not.

### Why this is not the doubling it first appeared to be

An earlier reading of these families put them at roughly 2x on share of non-spike transaction volume. That reading does not survive: the spike-excluded denominator itself fell from 244.8M to 123.8M across the same windows, so a family with flat volume would double its share mechanically. The real change is the 1.4–1.6x above.

### Is this even a defect?

Possibly not, and that should be established before any work is scheduled. These are inherently multi-account operations — one transaction per account in a batch is the expected shape, so a batch that grew from ~1.8 to ~2.7 accounts produces exactly this signal with no defect at all.

The reason to look anyway is proximity: the same service's `Provider Create Accounts (v2 - batched)` moved 1.83 → **9.51** over the same period ([#45574 (the Provider Create Accounts v2 fan-out ticket)](https://github.com/MetaMask/metamask-extension/issues/45574)), which is not explainable by batch size. If a common cause is found there, these three are where to check whether it reached them too.

## Why this is filed separately from [#45574 (Provider Create Accounts v2 fan-out)](https://github.com/MetaMask/metamask-extension/issues/45574)

[#45574 (the Provider Create Accounts v2 fan-out ticket)](https://github.com/MetaMask/metamask-extension/issues/45574) covers `Provider Create Accounts (v2 - batched)` specifically. These three are distinct transaction names with their own growth, and fixing the first will not necessarily move them. They are filed apart so each can be closed on its own evidence.

They are almost certainly related in cause: same service, same alignment and account-creation paths, same period.

## Cluster context

The wider multichain-account family — the eight names covering provider creation, wallet alignment, account syncing, and per-chain account batches — moved from **23.40% to 36.79%** of non-spike transaction volume across the same windows.

That growth is not uniform, and the exceptions matter:

- **`Create Bitcoin Account` improved**, 9.83% → 0.24%, replaced by `Create Bitcoin Accounts Batch` at 5.18%. Batching worked for that path and roughly halved it.
- **`Provider Create Accounts (v2 - batched)` regressed**, 2.75% → 15.74%, despite already being the batched variant.

So the batching approach is demonstrably effective where it is applied and holding. The question for these three families is whether it was applied at all, or applied and then bypassed.

**This cluster was already the largest single source before the incident** — 23.40% of non-spike volume in the earliest window available. [#43633 (the original fan-out cap)](https://github.com/MetaMask/metamask-extension/issues/43633) recorded the same finding: a long-standing always-on baseline rather than a release regression. That remains true; it is now half again as large.

---

## Acceptance Criteria

- [x] For each of the three families, release-pure fan-out checked against the May baseline — at or below baseline on `13.42.0`/`13.43.0`, no action indicated
- [x] Transactions per trace measured before and after for each, release-pure rather than blended
- [ ] Confirm with whoever owns this area that closing is fine, given the finding above
- [ ] If closed, cross-reference from [#43413 (the incident postmortem)](https://github.com/MetaMask/metamask-extension/issues/43413) alongside [#45574 (the Provider Create Accounts v2 fan-out ticket)](https://github.com/MetaMask/metamask-extension/issues/45574) — same root cause, same fix, worth recording once rather than twice

---

## Notes on measurement

Absolute extrapolated counts are not comparable across windows this far apart; the share and per-trace-ratio columns are the claims. Any re-measurement should exclude spike families from the denominator or it will understate every other family in the period.

---

## Labels

`team-accounts-framework`, `area-sentry`, `area-multichain`

Start with the corrected release-pure comparison and linked issue #45574; verify with the area owner that closure is appropriate. No files or tests are named. Done means recording the confirmation, closing this issue, and cross-referencing it from postmortem #43413 if approved.

Written by the indexing model from the issue text.