#129 Increasing `ump service limit` threshold value
At current stage, the ump trasact
used by XCM cannot call the contribute
function, due to the insufficient maximum weight of the ump service limit.
This proposal hence to increase the weight limit, in order to call more functions such as contribute
, staking
and etc. Allowing more ump transacts means provide more flexibility&possibility so to improve the flexibility of parachains, which benefits the use cases of Kusama ecology.
One of Bifrost service is to help other parachains to participant crowdloan with assets locked while still provide liquidity in the form of our staking derivatives. We use xcm transact to achieve it with contribution call constructed as following.
Xcm::WithdrawAsset {
assets: vec![MultiAsset::ConcreteFungible {
id: MultiLocation::Null,
amount: contribution_amount,
}],
effects: vec![Order::BuyExecution {
fees: MultiAsset::All,
weight: contribution_weight,
debt: contribution_debt,
halt_on_error: true,
xcm: vec![Xcm::Transact {
origin_type: OriginKind::SovereignAccount,
require_weight_at_most: contribution_weight_at_most,
call: contribution_call,
}],
}],
But the current ump-service-weight threshold does not allow it and the call will just fail.
Show More
Cancelled before enactment at request of the proposer by referendum 134.
The dispatched proposal submitted by Bitfrost, lowers the UMP weight to 5_000_000_000
. After more testing from the Acala team, we indeed found out that if this proposal got executed, when there are more than one XCM messages in a block, the second one would be discarded which leads to fund loss (more about this discussion can be found above on this channel).β¨β¨The Acala team opened an issue, and the cancellation of the dispatched proposal was executed through referendum 134.
Discover similar proposals