- [Refactor `fromIncluded` and `fromExcluded` Maps to Slices in Route Validation Logic](https://github.com/status-im/status-go/issues/5241) - `created`
- [Refactor and Simplify `hasSufficientCapacityV2` Logic to Ensure Correct Path Amount Validation](https://github.com/status-im/status-go/issues/5244) - `created`
- [Check Validity of `fromLockedAmount` in `SuggestedRoutesV2`](https://github.com/status-im/status-go/issues/5227) - `updated`
- ie in the UI context bridging refers to the user pressing a "bridging" button to perform an explicit bridging action. Not the required routing performed by `status-go` Wallet `Router`.
- ⚠️ Attention. Devs and QAs particularly should be mindful of this.
- Emphasised that the app should mint `ERC1155` rather than `ERC721` tokens
- Confirmation that this is the case was suggested.
- Highlighted that there is an inconsistency with the current desktop app functionality verse the intention of the design.
- Locking behaviour for values on specific chains does not work as the product design intended
- Full requirements not yet provided, expected to follow.
- Additional clarification and validation likely to be needed
- Discussed that `ERC1155` tokens of the same kind should be grouped together.
- Unclear if designs and requirements for this feature exist in the form needed by Desktop UI.
- Dario has mentioned in chat: > "*This is mostly a backend effort with relatively high complexity (define a special kind of token for these "community ERC721 we want to treat as ERC1155" ones, do the grouping backend-side when fetching them, do the un-grouping backend-side when sending, ensure no side effects in activity). I see low chances of swap-team being able to work on + finish that for 2.30, unless it's prioritized over Swap.*"
- So this intent is / has been expressed somewhere.
- Brief update from Brian and me.
- The call expressed a blithesome response to the update that the Wallet Router filter modularisation and test suite was complete and ready for review.
- I'm very nearly finished now. However, I do need reviewers to pay super close attention to the test cases and check that the intent of the functions is matched by the cases.
- The full list of changes is available in the PR commit.
- A very in depth meeting reviewing the send flows of desktop.
- **Key Decisions:**
- Reduce the scope of the Send, Bridge and Swap UI designs for 2.30
- UI and design to work together
- Desktop UI should detail what is feasible for the 2.30 release
- Alisher and Ben are supportive of facilitating a highly iterative framework.
- Alisher and Ben will adapt sending flows as required
- Michal and Sale would discuss the best process for improving the UI while at the same time being able to deliver something. Include Noelia
- Identified distinctions between the concepts of backend `Router` and UI `Router`
- Backend `Router` is a logic model for sending blockchain tokens. This model contains functionality that manages:
- Calculating the best path for any given transaction requirements:
- From address(es)
- To address(es)
- From network(s)
- To network(s)
- From token type(s)
- To token type(s)
- The `Router` is capable of using multiple input tokens and addresses to plan a route to multiple output addresses and tokens.
- The `Router` determines which swaps and bridges may be required to achieve the goal
- Backend `Router` can be called by multiple UI components:
- Bridging
- Sending
- Swapping
- Backend `Router` handles all of these transaction types internally.
- UI `Router` is a complex high level UI component that allows a user to plan with great detail which tokens, addresses and networks they wish for a transaction (or series of transactions to take).
- UI `Router` is part of the UI bridging functionality.
-`filterRoutes` is a very complex function, and it is very difficult to read. I've split it apart and named the levels of filter after what they do rather when they happen.
- [See here for details](./analysis/wallet/Router/code/filterRoutes.go)
- I raised an axe to the crew meetings, swung hard and true. Toppled and prostrate they settled motionless. Tonight we revel in the light of their embers!
- I began work on reading and building context of the Route `status-go` logic.
- This work is tricky to track, but I have begun making notes of the logic. I plan to continue to build out a description or documentation detailing the analysis.