# XCM: Acala Requirements - `XCM::Transact` weight query, which is the runtime weight info data. - Creating independent crates and let runtimes import other runtime's weight info could help, but in a quite chaotic way: If the depended runtime redo benchmark, others need to do runtime upgrade to follow changes. - It could be better to using XCM messages to communicate weight info, other than relying on runtime upgrades. - Support multi-token(trader) to pay execution fees. - Existing traders like [`FixedRateOfConcreteFungible`](https://github.com/paritytech/polkadot/blob/master/xcm/xcm-builder/src/weight.rs#L95) and [`UsingComponents`](https://github.com/paritytech/polkadot/blob/b3efbf38d41f397145f612499c8f41fcf5999ec6/xcm/xcm-builder/src/weight.rs#L133) only support one type of asset for payment for each of them. - Provide `WeightTrader` impl for tuples so if one trader failed, we can try another one. - HRMP channels handling - Currently, we can use root on parachains side to send `XCM::Transact`, to make open channel requests or acceptances. But it's a bit unpractical as the requests could expire, and different parachain councils need to coordinate to make sure the motion for request and acceptance got executed within the expiration period. - Make the acceptance could be configured to be automatic. Parachains could set conditions in advance. When an open channel request notification is received, if the condition is met, a reply message is sent to the relay chain automatically to accept the request.