feat: auto claim L2->L1 and L2->L2 support

[arnaubennassar]

🚧 DRAFT — interim base branch, do not merge yet 🚧

This PR is a draft. It targets feat/bridge-service-finder (the head branch of #1692,
feat: add bridgeservicefinder package) as an interim base, not develop, because this
branch was itself created on top of feat/bridge-service-finder and also depends on #1691
(feat: add op-pp-2chains env and L2→L2 bridge test) — both still open.

Merge order / what must happen before this is ready for real review:

1. feat: add op-pp-2chains env and L2→L2 bridge test #1691 merges into develop.
2. feat: add bridgeservicefinder package #1692 merges into develop.
3. Once both have landed, this PR's base is retargeted from feat/bridge-service-finder → develop,
   the draft flag is removed, and it goes up for review for real.

This branch already contains #1691's code via a direct branch merge (commit c3e4e0f2, merging
origin/feat/e2e-op-pp-2chains — #1691's head — directly into this feature branch, per an explicit
decision to unblock this plan's own L2→L2 e2e work without waiting for #1691 to land first). That
merge brought #1691's diff onto this branch as-is; it was not re-authored or re-reviewed here.
Reviewers: please do not review or merge this PR until #1691 and #1692 are both confirmed merged
to develop and it has been retargeted there — merging it as-is (against
feat/bridge-service-finder, before either lands) would land unreviewed code from both of those
PRs on develop attributed to this one, and cause conflicts/duplication when they merge on their
own.

🔄 Changes Summary

• Extends the existing Auto Claim service (L1→L2 only, from feat: autoclaim plan #1662) with automatic claiming for the other two
  bridge directions:
  • L2→L1: bridge exits initiated on a rollup, destined for L1 (destination network 0).
  • L2→L2: bridge exits initiated on one rollup, destined for another rollup.
  • L1→L2 behavior is unchanged in shape — same detector, same claim path — but its proof-readiness gate now
    goes through the destination bridge service instead of a local GER syncer (see below); regression-tested end
    to end (see Testing).
• The node running Auto Claim does not sync any source L2 directly. A new bridgedetector.L2ToLx detector
  watches l1infotreesync for each source rollup's local exit root (LER) advancing (from both
  VerifyBatchesTrustedAggregator, zkEVM/state-transition rollups, and the newly-indexed
  VerifyPessimisticStateTransition, pessimistic/aggchain rollups — the latter previously wasn't indexed by
  l1infotreesync at all), then fetches the new bridges from that source rollup's own bridge service via a new
  bridgeservicefinder-resolved REST call.
• A new bridge service endpoint, GET /bridge/v1/claim-candidates, serves exactly that: bridges in a deposit-count
  range, filtered by destination network. Backed by a new deposit-range+destination query in bridgesync
  (GetBridgesInDepositRange). It does not return a per-bridge Merkle proof — see "GER gate + claim-time proof"
  below.
• GER-injection gate via the destination bridge service, replacing per-claimer l2gersync. Auto Claim no
  longer runs a per-claimer l2gersync instance (no isolated per-claimer SQLite database, no per-claimer L2 reorg
  detector, no per-claimer L2 RPC client dedicated to GER tracking). Instead, during proof preparation, readiness
  for an L2-destination claimer is gated by calling that destination network's own aggkit bridge service GET /bridge/v1/injected-l1-info-leaf (resolved through bridgeservicefinder.Finder). This applies uniformly to
  both directions, including L1→L2. A claimer whose destination is L1 (NetworkID = 0) has no such gate — it
  is ready as soon as l1infotreesync has the relevant leaf, since the GER already exists in the L1 GER manager by
  construction.
• Leaf→LER proof fetched only at claim time. The L2ToLx detector no longer fetches or stores the leaf→LER
  Merkle proof at discovery time — claim-candidates never returned it in this version (see above). The new
  rollup-origin proof preparer (autoclaim/proof.RollupPreparer) builds the LER→rollup-exit-root proof locally
  from l1infotreesync and always fetches a fresh leaf→LER proof from the source's bridge service (GET /bridge/v1/claim-proof) when preparing a claim — there is no "staleness" special case, because the proof is
  never cached in the first place. SourceAwarePreparer dispatches every claimer between this and the existing
  L1-origin preparer based on each request's source_network, not the claimer's destination.
• Claim submission (claimtx, claimer.IsClaimed, global index derivation) is now keyed by source_network
  instead of always assuming L1 origin. The claim ABI is byte-identical across L1 and L2 v2 bridge contracts, so
  claimAsset/claimMessage packing is reused unchanged.
• A destination network 0 (L1) claimer is now a legal, fully-supported configuration — like every other claimer,
  it has no l2gersync, and additionally it is the only claimer type with no GER-injection gate at all (the GER
  already exists in the L1 GER manager by construction once l1infotreesync has the leaf).
• Request identity changed from origin_network:destination_network:deposit_count (origin = bridged token's
  origin, which isn't unique across multiple source networks) to source_network:destination_network:deposit_count
  (the network the bridge exit was initiated on — this is also what the claim global index encodes).

⚠️ Breaking Changes

• 🛠️ Config: [AutoClaim.L2ToLxBridgeDetector] is no longer a permanently-disabled placeholder — it is a
  real, independently-enableable detector. A new [AutoClaim.BridgeServiceFinder] section (embeds
  bridgeservicefinder.Config) is required when L2ToLxBridgeDetector.Enabled = true or when any enabled
  claimer has an L2 destination (NetworkID != 0), in either direction — this includes a pure L1→L2 setup with
  the L2ToLx detector disabled: Validate() now enforces RollupManagerAddr whenever any enabled claimer targets
  an L2 destination, not just when the detector is on. [[AutoClaim.Claimers]] now accepts NetworkID = 0 as a
  valid L1-destination claimer (requires the L2ToLx detector to be reachable).
• 🛠️ Config: Per-claimer [[AutoClaim.Claimers]].BlockFinality and .InitialBlockNum are removed — they
  configured the now-deleted per-claimer l2gersync. Autoclaim no longer consumes [L2GERSync]/
  [ReorgDetectorL2] at all (those sections remain, unchanged, for the node-global l2gersync that backs the
  bridge service and Aggoracle).
• ⚙️ Operational: L1→L2 auto claiming now requires [AutoClaim.BridgeServiceFinder] to be configured
  (with RollupManagerAddr) and the destination network's own bridge service to be reachable, whenever the
  destination is an L2. Previously an L1→L2 claimer only needed the shared [L2GERSync]/[ReorgDetectorL2]
  settings and its own RPC client; there was no dependency on a remote bridge service for GER readiness.
• 🔌 API: GET /bridge/v1/claim-candidates no longer returns a per-bridge Merkle proof — the response is
  {"claim_candidates": [{"bridge": {...}}], "count": N} (previously each candidate also carried
  proof_local_exit_root and local_exit_root). to_ler/from_ler still define the deposit-count range as
  request parameters; they are unaffected.
• 🔌 API: GET /bridge/v1/injected-l1-info-leaf now returns 404 Not Found (previously 500 Internal Server Error) when no injected global exit root covers the requested L1 info tree index yet. The Go client
  (bridgeservice/client.Client.GetInjectedL1InfoLeaf) surfaces this as client.ErrNotFound instead of a generic
  wrapped error. Existing e2e retry loops already treated any error from this call as "not ready, retry" and are
  unaffected.
• 🔌 API: Auto Claim request IDs (GET /autoclaim/v1/bridges/{id}) changed format from
  origin_network:destination_network:deposit_count to source_network:destination_network:deposit_count. For
  every pre-existing L1→L2 request these are numerically identical (source_network is always 0 for L1→L2,
  same as origin_network was for L1-origin tokens) — but any old client that assumed "origin network" semantics
  for a wrapped token bridged L1→L2 would have seen a different (bug-fixed) key than before; see Migration.
• 🗄️ Storage: autoclaim_request no longer has a leaf_proof_json column (never shipped — see Migration).
  Any external tooling reading the SQLite database directly must drop references to it; ler and
  verify_block_num are unaffected.
• No breaking changes to claimAsset/claimMessage calldata or the admin approve/reject endpoints.

📋 Config Updates

[AutoClaim.L2ToLxBridgeDetector]
Enabled = true
StartL1Block = 0            # 0 = full history; else initial from_ler derived via GER at this block
PollInterval = "3s"
RetryAfterErrorPeriod = "1s"
MaxRetryAttemptsAfterError = -1

[AutoClaim.BridgeServiceFinder]
RollupManagerAddr = "0x..."       # required when L2ToLxBridgeDetector.Enabled = true, OR when any
                                   # enabled claimer (either direction) has an L2 destination
PollInterval = "30s"
# BlockFinality, BlockChunkSize, HealthCheckPath, HealthCheckTimeout, RequireAllHealthyOnStart all default.

[AutoClaim.BridgeServiceFinder.URLs]
# Static override map, source network ID -> bridge service base URL.
# Required to reach network 0 (L1), which is never enumerated on-chain:
# 0 = "http://static-override-l1:5577"

# Every claimer uses this same [[AutoClaim.Claimers]] shape, including an L1-destination one
# (NetworkID = 0, BridgeAddr = the L1 bridge contract, URLRPC = an L1 RPC endpoint). There are no
# BlockFinality/InitialBlockNum keys anymore (removed with the per-claimer l2gersync); an
# L2-destination claimer's readiness gate is served by [AutoClaim.BridgeServiceFinder] + the
# destination's own bridge service instead.
[[AutoClaim.Claimers]]
Enabled = true
NetworkID = 0
...

Full reference: docs/autoclaim.md (Configuration section, "Top-level keys" and "Claimer keys" tables).
[AutoClaim.L2ToLxBridgeDetector].DisabledBridgeDetector placeholder is gone — both directions are independently
enabled/disabled the same way (Enabled = true/false).

✅ Testing

Unit tests (make test-unit, full repo green, exit 0, zero failures anywhere), coverage for every package this
plan touched or added:

Package	Coverage
autoclaim/api	90.0%
autoclaim/apitypes	96.9%
autoclaim/bridgedetector	66.4%
autoclaim/claimer	84.4%
autoclaim/claimtx	89.5%
autoclaim/config	98.4%
autoclaim/policy	97.0%
autoclaim/proof	81.6%
autoclaim/runtime	60.6%
autoclaim/sender	81.4%
autoclaim/simulator	95.0%
autoclaim/storage	74.0%
autoclaim/storage/migrations	100.0%
autoclaim/types	100.0%
bridgeservice	92.9%
bridgeservice/client	92.5%
bridgesync	77.5%
bridgesync/migrations	88.1%
bridgesync/types	92.3%
l1infotreesync	72.0%
config	87.5%

make build, make lint (in-scope packages clean — see Notes), make generate-mocks, and
make generate-swagger-docs all run clean with no resulting uncommitted diff.

• 🤖 Automatic (e2e, dockerized):
  • Single-chain op-pp environment, one full green run (go test -v -run 'TestAutoClaimL1ToL2AllowAll|TestAutoClaimL1ToL2APIApprove|TestAutoClaimL1ToL2BasicFilter|TestAutoClaimL2ToL1AllowAll' -timeout 30m -count=1 ./test/e2e, exit 0, 300.06s total):
    • TestAutoClaimL1ToL2AllowAll — PASS (53.28s) — L1→L2 regression, now exercising the destination-bridge-service
      GER gate instead of the old per-claimer l2gersync.
    • TestAutoClaimL1ToL2APIApprove — PASS (55.64s) — L1→L2 regression, manual approval flow.
    • TestAutoClaimL1ToL2BasicFilter — PASS (54.22s) — L1→L2 regression, gas-simulation policy.
    • TestAutoClaimL2ToL1AllowAll — PASS (80.04s) — new L2→L1 direction: L2ToLx detector,
      RollupPreparer, an NetworkID = 0 (L1-destination) claimer, end to end against a pessimistic-proof
      rollup (VerifyPessimisticStateTransition LER indexing exercised for real).
  • Two-chain op-pp-2chains environment (AGGKIT_E2E_ENV=op-pp-2chains), TestAutoClaimL2ToL2AllowAll run
    twice consecutively with -count=1 (per this repo's Go test-result caching):
    • Run 1 — PASS (139.76s), suite ok in 286.13s.
    • Run 2 — PASS (140.78s), suite ok in 285.27s.
    • Exercises the L2ToLx detector + bridgeservicefinder resolving both source and destination networks, the
      destination-bridge-service GER-injection gate, and the claim-time leaf-proof fetch path end to end.
  • All docker-compose environments were torn down cleanly after every run; final git status/docker ps clean.

🐞 Issues

• Closes L2 -> Ly Autoclaim #1665

🔗 Related PRs

• Base branch dependency: targets feat/bridge-service-finder, the head branch of feat: add bridgeservicefinder package #1692
  (feat: add bridgeservicefinder package) — to be retargeted to develop once feat: add bridgeservicefinder package #1692 merges.
• Depends on and merges in feat: add op-pp-2chains env and L2→L2 bridge test #1691 (feat: add op-pp-2chains env and L2→L2 bridge test) via commit c3e4e0f2
  — see the draft/gate note at the top of this description.
• Builds on feat: autoclaim plan #1662 (feat: autoclaim plan, the original L1→L2 Auto Claim implementation).

📝 Notes

• Migration: autoclaim/storage/migrations/autoclaim0002.sql adds source_network to autoclaim_request
  (existing rows default to 0, correct since they're all L1-origin), replaces the UNIQUE(origin_network, destination_network, deposit_count) constraint with UNIQUE(source_network, destination_network, deposit_count) (the real claim identity — it's what the global index encodes), re-keys every pre-existing
  autoclaim0001 row's request_key to the new source:destination:deposit_count format (a no-op value change
  for existing rows, since source_network = origin_network = 0 for all of them), adds ler/verify_block_num
  columns, and adds a new autoclaim_ler_cursor table. This re-key is safe: autoclaim0001
  (introduced by feat: autoclaim plan #1662, merged this week) has not shipped in any tagged release or release branch — confirmed
  against git tag/release/* branches before implementing. The same unshipped migration briefly added, then
  had removed in place, a leaf_proof_json column: once the leaf→LER proof became always-fetch-at-claim-time
  (never stored), the column was dropped from the migration file directly rather than via a follow-up migration,
  since it had never shipped either.
• Docs: docs/autoclaim.md, docs/bridge_service.md, and docs/common_config.md are fully rewritten/updated
  for all three directions and both proof-pipeline changes (architecture diagrams, sequence diagrams, config
  reference, API fields, storage tables, and the e2e test catalog) and were spot-checked against the final code
  state as part of this PR's validation sweep — including the destination-bridge-service GER gate and the
  claim-time-only leaf proof added after the initial L2→Lx docs pass.
• API: GET /autoclaim/v1/bridges gained a source_network (uint32) response field and list-filter query
  param, and a ler (hex string, empty for L1-origin requests) response field. ler records the source LER
  observed at detection time (used to pick the covering L1 info tree leaf); the leaf→LER proof itself is never
  part of the stored request or the API response, since it is now always fetched fresh at claim time. Request IDs
  are source_network:destination_network:deposit_count (see Breaking Changes).
• Lint: make lint still exits non-zero for the repo as a whole, but every finding is pre-existing baseline
  debt outside this plan's footprint — verified per-line via git blame that each finding predates this plan's
  work (either from before this branch existed, or from PR feat: add op-pp-2chains env and L2→L2 bridge test #1691's own commit history brought in by the
  c3e4e0f2 merge). Zero lint findings in autoclaim/**, bridgesync/**, bridgeservice/**,
  l1infotreesync/**, or the touched parts of config/**/cmd/run.go.
• test-unit: two previously-flaky, pre-existing, out-of-scope tests (agglayer's
  TestRateLimitWrapper_* timing assertions and claimsync's docker-connectivity tests, both unrelated to
  autoclaim, flagged as such earlier in this plan's own execution log) were green on the final validation run —
  full repo make test-unit passed with zero failures.
• Commit history: this branch's own work (autoclaim L2→Lx: S01-S17) landed as a single checkpoint commit
  (025bbb2d) followed by the PR feat: add op-pp-2chains env and L2→L2 bridge test #1691 merge (c3e4e0f2, untouched — including its own commit history — per an
  explicit decision not to rewrite anything brought in from that merge or upstream of it) and a small number of
  focused commits on top (a pre-existing env config fix, the L2→L2 test itself, a mechanical lint fix, the
  destination-bridge-service GER gate + claim-time-proof follow-up work, and a docs drift fix). 025bbb2d's "wip:"
  label was deliberately left as-is rather than split/reworded, since either change would require recreating the
  c3e4e0f2 merge commit, which was out of scope to touch.

[arnaubennassar]

@claude

[claude]

Claude finished @arnaubennassar's task in 2m 13s —— View job

---

Review Complete ✅

I've completed a thorough review of PR #1705. Here's my assessment:

---

🚀 What's New

This PR extends Auto Claim to support L2→L1 and L2→L2 bridge claiming in addition to the existing L1→L2 direction. Key additions include:

• New L2ToLx bridge detector that watches l1infotreesync for rollup LER updates and fetches bridge exits from source rollups' bridge services
• New RollupPreparer for building rollup-origin claim proofs with automatic staleness refresh
• New bridge service endpoint GET /bridge/v1/claim-candidates that serves bridges with Merkle proofs against a requested LER
• Support for L1-destination claimers (NetworkID = 0)
• bridgeservicefinder integration for resolving source rollup bridge service URLs
• source_network-based request keying (replacing origin_network which was ambiguous for wrapped tokens)

🐛 Bug Fixes

None - this is a pure feature addition.

📋 Config Updates

[AutoClaim.L2ToLxBridgeDetector]
Enabled = true
StartL1Block = 0            # 0 = full history
PollInterval = "3s"
RetryAfterErrorPeriod = "1s"
MaxRetryAttemptsAfterError = -1

[AutoClaim.BridgeServiceFinder]
RollupManagerAddr = "0x..."  # Required when L2ToLxBridgeDetector enabled
PollInterval = "30s"         # Default value

# L1-destination claimer (new capability):
[[AutoClaim.Claimers]]
Enabled = true
NetworkID = 0  # 0 now valid for L1 destination
BridgeAddr = "0x..."  # L1 bridge contract
URLRPC = "http://l1-rpc:8545"
# No BlockFinality/InitialBlockNum (L1 has no l2gersync)

⚠️ Breaking Changes

• Request ID format: Changed from origin_network:destination_network:deposit_count to source_network:destination_network:deposit_count. For L1→L2 requests these are numerically identical (source=0, origin=0 for L1 tokens), but semantically corrected.
• Config: [AutoClaim.L2ToLxBridgeDetector] is now a real detector (was disabled placeholder). New [AutoClaim.BridgeServiceFinder] section required when enabled.
• API: GET /autoclaim/v1/bridges response adds source_network and ler fields; request IDs changed format (see above).

---

📊 Review Summary

Code Quality: Excellent ✅

• Well-structured with clear separation of concerns
• Comprehensive error handling throughout
• Extensive use of interfaces for testability
• Clean, idiomatic Go code following repo conventions

Test Coverage: Outstanding ✅

• 83.4% coverage on new code (SonarCloud)
• 4 new e2e tests covering all three bridge directions
• Unit tests for every new package/function
• All tests passing (make test-unit, e2e runs documented in PR)

Security: Strong ✅

• Proper SQL injection protection via parameterized queries
• Input validation with DoS protection (max 5 network IDs limit)
• Merkle proof verification before persistence
• No obvious vulnerabilities found

Documentation: Comprehensive ✅

• Detailed PR description with architecture, testing, migration notes
• Updated docs/autoclaim.md, docs/bridge_service.md
• Inline code comments for complex logic
• Swagger API docs updated

---

🔴 Required Issues

1. Migration Safety Assumption

File: autoclaim/storage/migrations/autoclaim0002.sql:114

The migration comment states:

-- autoclaim0001 ships in no release/tag (verified in the plan, §4bis #6)

Issue: This is a time-bomb 💣. If someone accidentally backports or cherry-picks autoclaim0001 to a release branch before this PR merges, the migration will corrupt data by blindly assuming all rows have source_network=0.

Recommendation: Add a runtime check in the migration:

-- Verify assumption: all existing rows should be L1-origin
SELECT CASE WHEN EXISTS (
  SELECT 1 FROM autoclaim_request WHERE origin_network != 0
) THEN RAISE(ABORT, 'autoclaim0002 migration cannot run: found non-L1-origin requests')
END;

This makes the assumption explicit and enforced, preventing silent data corruption.

---

🟡 Suggested Improvements

2. SQL Query Inefficiency in Pagination

File: bridgesync/processor.go:606-618

The GetBridgesInDepositRange function calls GetTotalNumberOfRecordsWithParams on every page, which executes a full COUNT(*) query. For large tables this becomes O(n) per page request.

Current:

bridgesCount, err := p.GetTotalNumberOfRecordsWithParams(ctx, bridgeTableName, whereClause, whereArgs)
// ... executed on every page

Suggestion: Return total count only on first page, or use window functions:

SELECT *, COUNT(*) OVER() as total_count FROM bridge WHERE ...

Impact: Medium - affects performance at scale when paginating through large result sets.

3. Magic Number for Leaf Selection Bound

File: autoclaim/proof/rollup_preparer.go:24

const maxLeafSelectionAdvances = 256

Issue: Hard-coded constant with no justification. What happens if a rollup genuinely needs 257 advances due to empty leaves or chain conditions?

Suggestion: Make this configurable via ClaimerConfig with a sensible default, or document why 256 is sufficient based on L1 info tree insertion frequency.

4. Potential Race in Cursor Advancement

File: autoclaim/bridgedetector/l2_to_lx.go (around cursor advancement logic)

The detector advances the LER cursor after successfully fetching all candidates for a source. If the process crashes between fetching candidates and advancing the cursor, those candidates will be re-fetched on restart.

Current behavior: Idempotent enqueue prevents duplicates, so this is safe but inefficient.

Suggestion: Consider batching cursor advances with candidate enqueues in a transaction, or document this as intentional "at-least-once" semantics.

5. Missing Rate Limiting on Bridge Service Calls

File: autoclaim/bridgedetector/l2_to_lx_fetcher.go:70-103

The fetcher makes unbounded HTTP calls to source bridge services with no client-side rate limiting or retry backoff.

Risk: If a source bridge service is slow/flaky, this could:

• Spam failed requests
• Exhaust connection pools
• Cause the detector to fall behind

Suggestion: Add rate limiting and exponential backoff in ServiceFetcher, or use the existing RetryAfterErrorPeriod config more defensively.

6. Error Handling: Swallowed Context in Defer

File: bridgesync/processor.go:633-637

defer func() {
    if cerr := rows.Close(); cerr != nil {
        p.log.Errorf("error closing rows: %v", cerr)
    }
}()

Issue: If the function returns early due to an error, the deferred rows.Close() error is only logged but not surfaced. In production this can leak connections.

Suggestion: Standard pattern:

defer func() {
    if cerr := rows.Close(); cerr != nil && err == nil {
        err = fmt.Errorf("close rows: %w", cerr)
    }
}()

---

🟢 Optional Nits

7. Inconsistent Naming: L2ToLx vs L2ToL1 and L2ToL2

The detector is named L2ToLx (generic), but configs/docs sometimes refer to "L2→L1" and "L2→L2" separately. Consider documenting why "Lx" (any layer) vs splitting into two detectors.

8. Test Timeout Hardcoded

File: test/e2e/autoclaim_test.go (e2e tests use -timeout 30m)

Consider extracting this to an env var for CI flexibility.

9. Comment Typo

File: l1infotreesync/processor_verifybatches.go:23

// If ExitRoot is zero if the leaf doesnt exists doesnt change the root of tree.

Should be: "If ExitRoot is zero, the leaf doesn't exist and doesn't change the root of the tree."

---

🎯 Overall Assessment

This is high-quality, production-ready code with one critical migration safety issue that should be addressed before merge.

Strengths:

• Excellent test coverage (83.4% + comprehensive e2e)
• Clean architecture with proper interfaces and DI
• Thorough error handling and input validation
• Well-documented with updated guides

Merge recommendation: ✅ Approve after addressing Required issue #1

The migration assumption (#1) is the only blocking concern - everything else is optimization or polish. Once that's fixed with a safety check, this PR is ready to land.

---

✅ Action Items for Author

1. 🔴 [Required] Add migration safety check in autoclaim0002.sql (issue Unify L1 syncers #1)
2. 🟡 Consider pagination optimization for GetBridgesInDepositRange (issue Split L1 / L2 responsibilities for lastgersync #2)
3. 🟡 Document or make configurable maxLeafSelectionAdvances (issue Add UTs for lastgersync #3)

---

[arnaubennassar]

Thanks for the thorough review. I went through each finding against the actual code. Disposition below; commit 421ba23 addresses the one actionable item.

🔴 #1 Migration safety — not applied (false positive, suggested fix is incorrect)

The re-key '0:' || destination_network || ':' || deposit_count matches DeriveRequestKey(source, dest, deposit) (autoclaim/types/types.go:324), and source = 0 is correct by construction: autoclaim0001 had only the L1→L2 detector, whose source is always L1 (network 0). There is no source_network column in the autoclaim0001 schema to verify against — so the assumption cannot be checked at migration time.

The suggested guard WHERE origin_network != 0 is actively wrong: origin_network is the token origin network, which is non-zero for wrapped tokens in perfectly valid L1→L2 claims. That check would falsely ABORT legitimate migrations. The backport concern is a process risk, not a code defect; the existing comment already documents the invariant.

🟡 #2 COUNT(*) per page — by design

GetBridgesInDepositRange needs the total for offset validation (calculateOffset) and to return the total count to the API caller. This matches the existing paginated-query pattern used throughout processor.go.

🟡 #3 maxLeafSelectionAdvances = 256 — already justified

The constant is documented at rollup_preparer.go:20-23 (common case advances zero times; the bound only guards a pathological run). Making it configurable is scope creep with no demonstrated need.

🟡 #4 Cursor advancement — already intentional

As the finding itself notes, idempotent enqueue makes this safe (at-least-once). This is the intended semantics.

🟡 #5 Rate limiting — out of scope

The fetcher already honors RetryAfterErrorPeriod / MaxRetryAttemptsAfterError. Adding a rate limiter is a separate enhancement, not a defect in this PR.

🟡 #6 rows.Close() error surfacing — convention-consistent

Logging (not surfacing) the deferred rows.Close() error is the uniform repo convention — same pattern at processor.go:483,537,634,725,1525,1558,1625. The cerr != nil && err == nil pattern appears nowhere in the codebase. rows.Close() still runs via defer, so there is no connection leak. Changing this one site would introduce an inconsistency.

🟢 #7 L2ToLx naming — intentional

One detector handles both L2→L1 and L2→L2 (destination is the only difference); Lx reflects that single code path. Docs describe the user-facing directions separately for clarity.

🟢 #8 e2e timeout — out of scope

🟢 #9 Comment typo — ✅ fixed in 421ba23

l1infotreesync/processor_verifybatches.go:23 grammar corrected.

Net: 8 of 9 findings are non-defects (by-design, already-documented, convention-consistent, or based on an incorrect premise); the typo is fixed.

[sonarqubecloud]

Quality Gate passed

Issues
14 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.7% Coverage on New Code
0.6% Duplication on New Code

See analysis details on SonarQube Cloud