fix: malicious recovery detection

[schmanu]

What it solves

Resolves https://www.notion.so/safe-global/Recovery-tx-is-being-considered-a-malicious-tx-724664e7de4e4a8da4d88b5606af047c?pvs=4

How this PR fixes it

• Uses correct multiSend deployment when trying to detect if recovery is malicious

How to test it

• Queue a recovery through the interface

Checklist

• [x] I've tested the branch on mobile 📱
• [x] I've documented how it affects the analytics (if at all) 📊
• [x] I've written a unit/e2e test for it (if applicable) 🧑‍💻

[github-actions[bot]]

Branch preview

✅ Deploy successful!

Website: https://fix_recovery_detection--walletweb.review.5afe.dev/home?safe=eth:0xA77DE01e157f9f57C7c4A326eeE9C4874D0598b6

Storybook: https://fix_recovery_detection--walletweb.review.5afe.dev/storybook/

[github-actions[bot]]

ESLint Summary View Full Report

Annotations are provided inline on the Files Changed tab. You can also see all annotations that were generated on the annotations page.

Type	Occurrences	Fixable
Errors	0	0
Warnings	0	0
Ignored	0	N/A

• Result: :white_check_mark: success
  • Annotations: 0 total

---

^{Report generated by eslint-plus-action}

[katspaugh]

I guess it's a regression after #3811. So we cannot just always use the latest multisend contract?

[github-actions[bot]]

📦 Next.js Bundle Analysis for safe-wallet-web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

🎉 Global Bundle Size Decreased

Page	Size (compressed)
global	948.78 KB (-3 B)

Details

The global bundle is the javascript bundle that loads alongside every page. It is in its own category because its impact is much higher - an increase to its size means that every page on your website loads slower, and a decrease means every page loads faster.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

If you want further insight into what is behind the changes, give @next/bundle-analyzer a try!

[github-actions[bot]]

Coverage report

St.:grey_question:	Category	Percentage	Covered / Total
🟡	Statements	79.44% (+0% 🔼)	11515/14496
🔴	Branches	58.45% (+0.01% 🔼)	2784/4763
🟡	Functions	66.74%	1846/2766
🟢	Lines	80.76% (+0% 🔼)	10381/12854

Show files with reduced coverage 🔻

|

St.^{:grey_question:}

| File | Statements | Branches | Functions | Lines | | :-: | :- | :- | :- | :- | :- | | 🟢 |

`...` / recovery-state.ts

|

95.24% (+0.08% 🔼)

|

84.21% (-2.46% 🔻)

| 85.71% |

96.55% (+0.06% 🔼)

|

Test suite run success

1436 tests passing in 199 suites.

Report generated by 🧪jest coverage report action from 23cdfa01c6fbdd6d0213f87990a4566a578a072b

[schmanu]

So we cannot just always use the latest multisend contract?

We use the version that we pass to the safe-core-sdk. But if that version has no MultiSendCallOnly contract it falls back to 1.3.0. Maybe we could use the getMultiSendCallOnlyContract function of the safe-core-sdk instead of using safe-deployments. Then it would always be aligned.

[schmanu]

Closing this as we reverted the change that caused this issue.