### What does the PR do

<!-- Fill in the relevant information below to help us evaluate your proposed changes. -->

### Affected areas

<!-- List the affected areas (e.g wallet, browser, etc..) -->

### Architecture compliance

- [ ] I am familiar with the application architecture and agreed good practices.
My PR is consistent with this document: [Architecture guidelines](../architecture-guide.md)

### Screenshot of functionality (including design for comparison)

- [ ] I've checked the design and this PR matches it

<!-- screenshot (or gif/video) that demonstrates the functionality, specially important if it's a bug fix. -->

<!-- Uncomment this section for status-go upgrade/dogfooding pull requests

### Impact on end user

What is the impact of these changes on the end user (before/after behaviour)

### How to test

- How should one proceed with testing this PR.
- What kind of user flows should be checked?

### Risk 

Described potential risks and worst case scenarios.

Tick **one**:
- [ ] Low risk: 2 devs MUST perform testing as specified above and attach their results as comments to this PR **before** merging.
- [ ] High risk: QA team MUST perform additional testing in the specified affected areas **before** merging.

-->