Sync upstream v2.11.0

.agents/AGENTS.md

@@ -57,13 +57,36 @@ Some directories have a `CONTEXT.md` documenting non-obvious patterns specific t
 - `src/sprite/` — SVG sprite build pipeline and which outputs are tracked vs. generated.
 - `src/toolkit/` — the `@blockscout/ui-toolkit` workspace package structure.
 - `tools/dev-server/` — how the dev server and demo deploy get their env vars from a running instance config.
-- `tools/profiling/` — React render profiling: production profiling build (`profile:preset`) and DevTools trace aggregation (`profile:analyze`).
+- `tools/profiling/` — React render profiling: production profiling build and DevTools trace aggregation.
 
 If you encounter a `CONTEXT.md` not listed here, read it too (and consider adding it to this list).
 
+## Architecture decision records
+
+Decisions with repo-wide consequences are recorded in `.agents/adr/`, named
+`<0000>-<slug>.md`. Read the relevant one before changing what it decided — an ADR carries the
+evidence and the trade-off, so it answers "why is it like this?" without a git archaeology session.
+
+- `0002-layer-shaped-ticket-leaves.md` — why a product task's tickets cut vertically while the leaves inside them run along layers.
+- `0003-turbopack-for-production-builds.md` — why production builds moved back to Turbopack.
+
+Add a new record (next free number, and a line here) whenever a decision is expensive to rediscover:
+it constrains future work, was reached by measurement or an investigation worth not repeating, or
+looks wrong without its context. Supersede rather than rewrite — flip the old record's `Status` to
+`superseded by <n>` and leave its reasoning intact.
+
 ## Product task workflow
 
-Product tasks (GitHub issues) are worked through a spec-driven workflow, run by the `grill-the-task`,
-`to-spec` and `implement-task` skills. Specs live in `.agents/tasks/`; read `.agents/tasks/README.md` for
-the lifecycle before touching one. `.agents/delegation.md` draws the agent/human boundary, and
-`.agents/TEAM.md` says who answers open questions.
+Product tasks (GitHub issues) are worked through a spec-driven workflow — interview, spec, agent
+implementation, code review. Specs accumulate in `.agents/tasks/` as a permanent record. See
+`./tasks/README.md` for the lifecycle, the skills that run it, and the spec conventions.
+
+## Editing this instruction set
+
+Before changing anything under `.agents/`, read `./README.md` — it owns the layout, the dual-frontmatter
+rules contract, the per-file symlink Cursor needs, and how references here are checked.
+
+## Reaching people & channels on Slack
+
+To reach anyone or any channel on Slack, resolve the Slack IDs from `./TEAM.md`. Draft and get approval
+before sending anything — unless the skill you are running names an explicit exception.

.agents/GLOSSARY.md

@@ -36,9 +36,10 @@ vars are documented in `docs/ENVS.md`. Architectural concepts like
 | **Connect Wallet** | feature | Lets users write to contracts, sign transactions, and connect a wallet to the explorer. Previously named `blockchain-interaction`; the current config key is `connectWallet`. Distinct from **Web3 Wallet**. |
 | **Dispute Games** | entity | Part of the Optimism **Fault Proof System**. On-chain games used to challenge and resolve disputed L2 output roots. |
 | **Easter Eggs** | feature | Hidden mini-games wired to claim links for badge rewards. |
+| **Eden** | chain | A rollup built on `ev-reth` / evstack. Introduces the **Sponsored Transaction** type. |
 | **Epoch** | entity | A consensus time period specific to **Celo**. Has its own index and detail pages. Always refers to a Celo epoch in this codebase — not a generic blockchain concept. |
 | **Fault Proof System** | feature | Optimism's mechanism for proving the correctness of L2 state transitions on L1 via **Dispute Games**. |
-| **Flashblocks** | feature | MegaETH's sub-second block streaming mechanism. |
+| **Flashblocks** | feature | Code name for the sub-second pre-confirmation block streaming feature. Surfaced to users as **Subblocks** on OP Stack chains (OP Labs renamed it from "Flashblocks") and as **mini-blocks** on MegaETH. The `flashblocks` code name and `FLASHBLOCKS` env vars are retained. |
 | **Hot Contracts** | feature | Ranked list of the most recently and frequently interacted-with smart contracts on the network. |
 | **Interchain Indexer** | service | Microservice that indexes cross-chain messages and token transfers across heterogeneous chains. General-purpose interop indexer, not ZetaChain-specific. Provides "Cross chain txs" feature. Distinct from **CCTX**. |
 | **Interop Messages** | entity | **Deprecated** Cross-rollup messages passed between OP Stack chains using the native interoperability protocol. Distinct from **Interchain Indexer** messages. |
@@ -52,6 +53,7 @@ vars are documented in `docs/ENVS.md`. Architectural concepts like
 | **Rewards** | feature | The Blockscout Merits program — a token rewards and incentives system operated by Blockscout. Entirely distinct from **Block Reward** (on-chain block-producer payouts). |
 | **Rollup** | concept | A chain that settles transactions on a parent (L1) chain. Introduces specific entities: deposits, withdrawals, transaction batches, output roots. Contrast with **Chain Variant**. |
 | **SolidityScan** | service | Third-party smart contract security vulnerability scanner integrated into contract detail pages. |
+| **Sponsored Transaction** | entity | **Eden**-specific transaction type (EIP-2718 type `0x76`): an executor submits an ordered batch of calls, while a separate sponsor signs for and pays the fee. No equivalent on standard EVM chains. |
 | **SUAVE** | chain | MEV-focused chain developed by Flashbots, built around a trusted execution environment (TEE) architecture. Introduces the **Kettle** entity. |
 | **TAC (Ton Application Chain)** | chain | A chain that bridges the TON blockchain and EVM ecosystems. Introduces the **Operation** entity. |
 | **Tx Actions** | feature | Structured per-transaction action breakdown rendered on the tx details page — a first-party Blockscout interpretation of what a tx did. Distinct from **Tx Interpretation** (natural-language summary) and from raw calldata. |

.agents/README.md

@@ -8,9 +8,11 @@ here; each tool reads it through its own directory via symlinks.
 | `AGENTS.md` | Always-loaded project context | `.claude/CLAUDE.md` → here; Cursor reads `AGENTS.md` natively |
 | `rules/*.md` | Coding rules, scoped to file patterns | `.claude/rules/` and `.cursor/rules/` — see below |
 | `skills/*/SKILL.md` | Workflows loaded on invocation | `.claude/skills/` → here |
-| `delegation.md`, `GLOSSARY.md`, `TEAM.md` | Read on demand, by pointer from `AGENTS.md` or a skill | — |
+| `delegation.md`, `GLOSSARY.md`, `TEAM.md`, `slack-thread.md` | Read on demand, by pointer from `AGENTS.md` or a skill | — |
 | `tasks/` | Product-task specs — see `tasks/README.md` | — |
 
+Cross-references between all of these are machine-checked: `pnpm lint:doc-links`.
+
 ## The rules contract
 
 Claude Code and Cursor discover rules differently and neither reads the other's format, so a rule file

.agents/TEAM.md

@@ -1,60 +1,169 @@
-# Team roster for product tasks
+# Team & Slack directory
 
-The teams involved in product tasks, with the members an agent may need to reach. Teams have several
-people — during a grilling session (`grill-the-task`) the developer picks **one contact per relevant team
-for the task**; the picks are recorded in the spec header and open questions are routed to those contacts.
-The member marked **default** is the fallback when the developer has no task-specific pick.
+The people, teams, and channels the team reaches on Slack, and the IDs needed to address them. This file is
+the **single source of truth** for turning a name into a Slack ID: refer to people, teams, and channels **by
+name** in specs, skills, and requests, and resolve the ID here whenever you actually need to send a message
+or build a mention or link. It is a registry only — *who* gets asked *what* is routing policy that lives in
+the skills that read it.
 
-Slack **member IDs** are stored deliberately so routing is deterministic (no runtime name lookup). They are
-workspace-scoped identifiers, not credentials — knowing one grants no access. To find yours in Slack:
+A **✓** in a team's *Default* column flags that team's fallback member — the one to contact when a request
+doesn't name a specific person.
+
+Slack IDs are stored so addressing is deterministic (no runtime name lookup). They are workspace-scoped
+identifiers, **not credentials** — knowing one grants no access. To find your own member ID in Slack:
 your profile → **⋯ More** → **Copy member ID**. Do not add emails to this file.
 
+## How to address
+
+- **Person** — the *Slack member ID* (`U…`) from the People table. Mention as `<@U…>`; to DM, pass the ID as
+  the channel to the send tool.
+- **Team / group** — the *Slack group ID* (`S…`) from the Groups table. Mention as `<!subteam^S…>`.
+- **Channel** — the *Channel ID* (`C…`). Pass it as the channel target when sending; refer to it in prose by
+  its `#name`.
+- **Permalink** — `https://blockscout.slack.com/archives/<channel-id>/p<message-ts>` (the message timestamp
+  with the dot removed).
+
 ## Product managers
 
 Own: product intent, scope, priorities, user stories, acceptance.
 
-| Name | GitHub | Slack member ID | Focus | |
-| --- | --- | --- | --- | --- |
-| Ulyana | @ulyanas | U024DUPJG3A | | default |
-| Nikita S. | @NikitaSavik | U05BR9QEYKB | |  |
+### People
+
+| Name | GitHub | Slack member ID | Default |
+| --- | --- | --- | --- |
+| Ulyana | @ulyanas | U024DUPJG3A | ✓ |
+| Nikita S. | @NikitaSavik | U05BR9QEYKB | |
 
 ## Designers
 
 Own: mockups, missing screens/states, visual decisions.
 
-| Name | GitHub | Slack member ID | Focus | |
-| --- | --- | --- | --- | --- |
-| Tatyana | @tgladilina | U039P3QLP0A | | default |
+### People
+
+| Name | GitHub | Slack member ID | Default |
+| --- | --- | --- | --- |
+| Tatyana | @tgladilina | U039P3QLP0A | ✓ |
+
+## Core API
+
+Own: core API endpoints and response models, field propagation across services, backend release schedule.
+
+### People
+
+| Name | GitHub | Slack member ID | Default |
+| --- | --- | --- | --- |
+| Victor | @vbaranov | U8L403FEG | ✓ |
+| Nikita P. | @nikitosing | U0218K3MTC5 | |
+
+### Groups
 
-## Backend engineers
+| Team | Slack group ID |
+| --- | --- |
+| Core API | S064H6TD6MA |
 
-Own: API endpoints, response models, field propagation across services, backend release schedule.
+## Microservices API
 
-| Name | GitHub | Slack member ID | Focus | |
+Own: microservice API endpoints and their response models (metadata, stats, admin, interchain, etc.).
+
+### People
+
+| Name | GitHub | Slack member ID | Focus | Default |
 | --- | --- | --- | --- | --- |
-| Victor | @vbaranov | U8L403FEG | Core API | default |
-| Nikita P. | @nikitosing | U0218K3MTC5 | Core API |  |
-| Leonid | @lok52 | U01KDJWBCV7 | Microservices API | default |
-| Evgenii | @EvgenKor | U026N2LB01E | Microservices API: Intercahin Indexer, TAC | |
+| Leonid | @lok52 | U01KDJWBCV7 | | ✓ |
+| Evgenii | @EvgenKor | U026N2LB01E | Interchain Indexer, TAC | |
+
+### Groups
+
+| Team | Slack group ID |
+| --- | --- |
+| Microservices API | S064073HASK |
+
+### Channels
+
+| Purpose | Channel | Channel ID |
+| --- | --- | --- |
+| Default for microservices questions | blockscout-rs | C03G1QASRJ8 |
+| Metadata microservice | blockscout-metadata-service | C067RACJ99B |
+| Admin RS microservice | blockscout-admin | C04TC4W81QV |
+| Stats microservice | blockscout-stats-rs | C089CJF6P0X |
 
 ## Frontend
 
 Own: architecture, the delegation boundary.
 
-| Name | GitHub | Slack member ID | Focus | |
-| --- | --- | --- | --- | --- |
-| tom | @tom2drum | U03MN1588AU | | default |
-| Max | @maxaleks | UKP0RR9K9 | | default |
+### People
+
+| Name | GitHub | Slack member ID | Default |
+| --- | --- | --- | --- |
+| tom | @tom2drum | U03MN1588AU | ✓ |
+| Max | @maxaleks | UKP0RR9K9 | |
+
+### Channels
+
+| Purpose | Channel | Channel ID |
+| --- | --- | --- |
+| Default for frontend questions | blockscout-frontend | C03MMUTQDNU |
+| Ask a frontend engineer to prepare an instance's config | front-config-requests | C08D60ZL1QB |
+
+### Groups
+
+| Team | Slack group ID |
+| --- | --- |
+| Frontend team | S0601760KT9 |
+
+## QA
+
+Own: test plans, acceptance-criteria verification, regression coverage, release sign-off.
+
+### People
+
+| Name | GitHub | Slack member ID | Default |
+| --- | --- | --- | --- |
+| Yan | @yvaskov | U05Q4R111PB | ✓ |
+| Alyona | @alyonakostina | U08NCHV535X | |
+
+### Channels
+
+| Purpose | Channel | Channel ID |
+| --- | --- | --- |
+| General questions | blockscout-qa | C059WER5EB1 |
+
+### Groups
+
+| Team | Slack group ID |
+| --- | --- |
+| QA team | S06015J7WVD |
+
+## DevOps
+
+Own: deployment and running-instance changes (env vars, image versions, restarts), CI/CD, and infrastructure.
+
+### People
+
+| Name | GitHub | Slack member ID | Default |
+| --- | --- | --- | --- |
+| Nick | @nzenchik | U04RVGGEW4Q | ✓ |
+| Alik | @alik-agaev | U06287SP35W | |
+
+### Channels
+
+| Purpose | Channel | Channel ID |
+| --- | --- | --- |
+| General questions | blockscout-devops | C03K1932X1N |
+| Requests to change a running instance (env vars, image versions, restarts, etc.) | blockscout-devops-requests | C050U1F2E9M |
+
+### Groups
+
+| Team | Slack group ID |
+| --- | --- |
+| DevOps team | S061MTPLJHK |
 
-## Slack channels
+## Product channels
 
-Product questions are asked **in a channel, not a DM**, so other teams (QA in particular) see the answers.
-The default is the frontend channel below; a large feature may have its own dedicated channel — recorded in
-the task's spec header — and then **all** of that task's questions go there. Channel posts always mention
-the addressee by member ID.
+Dedicated channels for specific large tasks — a single place to gather a feature's requirements and related
+discussion.
 
 | Purpose | Channel | Channel ID |
 | --- | --- | --- |
-| Default for product questions | blockscout-frontend | C03MMUTQDNU |
 | Multichain explorer | blockscout-multichain-explorer | C08R0UNBE3A |
 | Cross-chain transactions | dev-interchain | C0A7SALNLPL |

.agents/adr/0001-webpack-for-production-builds.md

@@ -0,0 +1,108 @@
+# 0001 — webpack for production builds, Turbopack for dev
+
+| | |
+| --- | --- |
+| Status | superseded by 0003 |
+| Date | 2026-08-04 |
+| Deciders | @tom2drum |
+| Supersedes | — |
+
+## Decision
+
+**Production builds use webpack (`next build --webpack`). Dev keeps Turbopack (the Next 16 default).**
+
+Applies to every entry point that emits a production bundle:
+
+| Entry point | Bundler |
+| --- | --- |
+| `pnpm build` — what the `Dockerfile` runs for the shipped image | webpack |
+| `pnpm build:next` | webpack |
+| `pnpm prod:preset <alias>` — local production build, incl. perf measurements | webpack |
+| `pnpm build:analyze`, `pnpm prod:preset <alias> --profile` | webpack (already were) |
+| `pnpm dev`, `pnpm dev:preset`, `pnpm dev:local` | Turbopack |
+
+Dev stays on Turbopack because it is roughly 3× faster to compile and the crash class below only
+manifests in a minified production build. Production-build regressions are caught in QA rather than
+by making every local dev start slower.
+
+## Why
+
+### Turbopack miscompiles the Dynamic-labs SDK
+
+Turbopack's scope hoisting emits code that reads the SDK's `UserFieldEditorContext` through the
+wrong binding. `useContext` therefore receives a non-context value, returns `undefined`, and the SDK
+throws from its own `useUpdateUserWithModal`:
+
+```
+useUserUpdateRequest can only be used inside the context of DynamicContextProvider
+```
+
+The throwing component is the SDK's internal `SyncAuthFlow`, which the SDK itself renders *inside*
+`UserFieldEditorContextProvider` — so in a correct build the context cannot be missing. It is a
+bundler defect, not a provider-tree bug in our code.
+
+Impact: **a hard crash on the initial load of every page**, for any instance configured with
+`NEXT_PUBLIC_ACCOUNT_AUTH_PROVIDER=dynamic`. It is invisible in dev (unminified, no hoisting) and
+was found only by running the `v2.10.0` image locally. The v2.10.0 release would have broken every
+dynamic-auth instance on rollout; deployed instances were still on v2.9.4 and unaffected.
+
+Bisected to [#3574](https://github.com/blockscout/frontend/pull/3574) (wallet-stack deferral,
+subtask 4 of [#3566](https://github.com/blockscout/frontend/issues/3566)) — parent commit good, that
+commit bad. The trigger could **not** be reduced to a single import: reverting the lazy `import()`
+wrappers, the `_app.tsx` provider restructure, and the `@wagmi/core` dependency each left it broken.
+That fits the mechanism — scope hoisting groups modules across the whole graph, so the trigger is an
+emergent property of how #3574 reshaped it, and any future graph change could re-trigger it
+somewhere else. Next 16.3.0 does not fix it.
+
+### webpack is also the faster bundle
+
+Two options fixed the crash: `--webpack`, or `experimental.turbopackScopeHoisting: false`. The flag
+turned out to be the expensive one. Production builds of `main`, medians of 3
+automated traces:
+
+| Metric | Turbopack | Turbopack, hoisting off | **webpack** |
+| --- | --- | --- | --- |
+| M1 FCP | 432 ms | 790 ms | **501 ms** |
+| M2 first API request | 60 ms | 142 ms | **57 ms** |
+| M5 blocking time | 133 ms | 408 ms | **155 ms** |
+| M6 JS before FCP | 1038 KB | 1064 KB | **697 KB** |
+| Emitted chunk bytes | 49.2 MB | 53.4 MB | **21.4 MB** |
+| Build time | 48 s | 41 s | 2.4 min |
+
+Disabling scope hoisting nearly doubles FCP and triples blocking time while barely moving M6 (+2.5%)
+— the cost lands in execution, not transfer, so M6 alone would not have caught it. webpack instead
+*improves* pre-FCP JS by 341 KB (−33%) over the Turbopack build, more than any single lever in #3566
+delivered on its own.
+
+The measurement harness lives in
+`.agents/tasks/3566-main-page-loading-perf/tools/` (see its README). Absolute values come from
+headless Chromium on a local server and are not comparable to the numbers in that task's spec table;
+the within-comparison deltas are what the decision rests on.
+
+## Consequences
+
+- **CI and image builds get slower** — webpack's compile step measured 84 s to 2.4 min across
+  machines and cache states, against 41–48 s for Turbopack, so budget roughly 2–3×. Accepted:
+  correctness plus a materially smaller bundle outweigh build latency.
+- **Dev and production now use different bundlers.** A bug in either pipeline can only be caught on
+  that pipeline; production-only breakage will not appear in dev. QA runs against a real image.
+- `next.config.js` must keep **both** the `webpack()` and `turbopack` sections in sync — it already
+  does, and this decision makes that non-optional.
+- webpack surfaces one unresolvable import Turbopack silently tolerates:
+  `@react-native-async-storage/async-storage` inside `@metamask/sdk`, reached via
+  `@wagmi/connectors` → `@reown/appkit-adapter-wagmi` → `wagmi-config.ts`. It is an optional peer
+  dependency of a React Native code path a browser bundle never takes, so `next.config.js` maps it
+  to `false` in `resolve.fallback` (an empty module) and the build is warning-free. If a future
+  dependency bump introduces a similar optional import, extend that map rather than silencing
+  warnings wholesale.
+- `next build --webpack` is a compatibility path in Next 16 and may eventually be removed. If that
+  happens before Turbopack is fixed, the fallback is `experimental.turbopackScopeHoisting: false`
+  and its performance cost.
+
+## Follow-ups
+
+- Report the miscompilation upstream to `vercel/next.js` with a minimal reproduction; the bisect
+  boundary and the flag that toggles it are the material.
+- Re-test Turbopack on each Next upgrade. If a release fixes it, revisit — Turbopack's build speed
+  is worth reclaiming, but only with the M1/M5/M6 numbers above re-measured, not on the release
+  notes alone.