When sending XYM from a multisig account, it is wrapped in a bonded transaction. This makes it much more difficult to readily identify the impact to sender and recipient balances, which will likely create confusion and disputes between users, and potentially provides a vector for user exploitation.
The absence of a 'Transfer' transaction and absence of a readily visible balance impact is liable to cause disputes between sender and recipient. Users cannot readily see that they received an amount of XYM in their transaction history, as no value exists in the 'Amount' column of the desktop wallet. While partially mitigated by the transaction details containing the balance change as a Mosaic, this is not explicitly intuitive.
In theory, a malicious actor could attempt to exploit this by misleading a recipient on the nature of bonded transactions (which are not presently documented at a layman's level and are rather difficult to fully understand) paired with a fake blockchain explorer showing an XYM amount embedded associated with the aggregate transaction. The 'Deadline' shown on the aggregate transaction could be used to justify the absence of a balance change (i.e. it's future dated and will show up in your wallet in a couple days).
I suspect this also adds complexity from a developer's perspective, as not all XYM transfers are transaction Type=Transfer
Recommendations:
For bonded transactions with associated XYM transfer(s), display the net XYM amount in the Amount column of the desktop wallet for the sender(s) and recipient(s)
Add a class/table to unify balance change history, including: every instance of balance change, the associated block / transaction, and a rolling balance in the UI.
This would serve to consolidate harvested block rewards, aggregate transfers, and transfers in one place, making it much easier to review address history in the UI and as a developer.
cryptoBeliever
commented
3 years ago
When sending XYM from a multisig account, it is wrapped in a bonded transaction. This makes it much more difficult to readily identify the impact to sender and recipient balances, which will likely create confusion and disputes between users, and potentially provides a vector for user exploitation.
Recommendations: