-
Notifications
You must be signed in to change notification settings - Fork 34
Open
Description
- currently treasury spoke doesnt really behave like a regular spoke; it is connected to 1 hub only and the functions like supply and withdraw accept a reserveId that MUST match the assetId on the hub, as it calls the hub directly with that reserveId input in place of assetId input
- treasury spoke can be misconfigured on the hub, if the same treasury spoke is used across multiple hubs, therefore need to deploy a new treasury spoke per hub
could lead to fees being bricked if the same treasury spoke is used across hubs.
- recently we made sure on addAsset and updateAssetConfig when there is a new feeReceiver, it must be a new spoke (for that hub) which then gets added to the hub
- in treasury spoke, you must define the hub it is connected with in the constructor and it is immutable
See the following scenario:
- deploy treasurySpoke feeReceiver1 connected to hub1
- on hub1, add assetA with feeReceiver1; feeReceiver1 gets added as a new spoke
- on hub2, add assetA with feeReceiver1 as well; this is allowed bc feeReceiver1 is a new spoke to hub2
ref of discussion: https://avaraxyz.slack.com/archives/C04HCBMEEBZ/p1758595490572469