[Slokh]

Pool admission (authorize-router, authorize-zone-router) now runs the same runtime provenance check as Portal gateway and account admission before it sends setTakerAllowed/setRecipientAllowed. A recovered router (and, for the Zone router, its lifecycle-deployed factory) must match the reviewed local build byte for byte, or the step stops before signing anything. Routers that are already admitted cause no new check and no new transaction.

• admitPoolRouter takes a required requireProvenance callback and runs it after the no-op check and before sending.
• authorize-router checks SingleZoneEarnRouter. authorize-zone-router reuses requireModeProvenance.
• Tests: each step rejects a noncanonical router without sending anything.
• Docs: the pool-owner authority note in docs/earn/modules/zone-router.md describes the check.

Checks run: pnpm check:types, pnpm check, pnpm --filter @tempoxyz/contracts test --run (777 passed, 1 skipped). No Solidity changed.

[tempoxyz-bot]

👁️ Cyclops Security Review

✅ Reviewed 1d6571b (latest) · Coverage: full · ⚠️ 1 not rechecked finding · report
⏸️ The review of 1d6571b did not recheck 1 earlier finding, so whether it still applies is unknown

#	Severity	Finding	Introduced	Status
1	⚪ Informational	Zone router page omits the provenance gate on automatic pool admission	529c4ec	✅ Fixed in 103f7ff
2	🟢 Low	Pool-owner handoff skips router provenance check and verification instruction	529c4ec	⏸️ Not rechecked since 529c4ec

[tempoxyz-bot]

Low (exposure and trigger unconfirmed): Pool-owner handoff skips router provenance check and verification instruction

The provenance check this PR adds to admitPoolRouter runs only when the deployer key owns the pool. With no key or no pool authority the step returns before the check, and the emitted pool-owner handoff asks for setTakerAllowed and setRecipientAllowed on the recovered router without any verification instruction. First reported at 529c4ec; recheck at this head: still present.

Valid? React with 👍 / 👎.

[claude]

I reviewed this PR and found no bugs. It changes when the lifecycle's own keys grant pool permissions, so a human look is still worthwhile.

What was reviewed:

• admitPoolRouter awaits requireProvenance after the redirect check and the no-op return, and before it builds the calls. A rejection therefore stops both the direct-owner path and the controller.execute path before anything is sent.
• authorize-router uses the same contract and constructor args as register-zone-gateway. authorize-zone-router reuses requireModeProvenance, so it checks the factory and the router. Named-factory profiles still return a handoff before any check runs.
• In both new tests the mock rejects. The tests check that the same error comes back and that sendTransactionSync is never called. I did not run the type check or the test suite.

Extended reasoning...

The change is in deployments/modules/earn/zone-router/steps.ts and deployments/modules/zone-router/steps.ts, plus two tests and two doc pages. It adds a required provenance callback to the shared pool-admission helper used by authorize-router and authorize-zone-router. The security-sensitive part is the deployer-key path that grants a router taker and recipient permission on a PropAMM pool, a grant the lifecycle cannot take back. The diff is small and follows the existing Portal-admission pattern. I deferred instead of approving because this is an authority and permission path, and an earlier inline bot comment on the Earn doc page may or may not be addressed by the follow-up commit.

[claude]

Code review found no issues

No high-confidence issues detected in this change.