[Forum Post](https://forum.moonbeam.network/t/mb121-mr83-update-xcm-fees/2199)

# TL;DR

This proposal updates the values used for the weight trader pallet to ensure a fair amount is charged for XCM execution using foreign assets in Moonriver.

# Summary

Moonriver first used the approach of units per second, that directly translated units of tokens to seconds of execution for a given XCM message.&#x20;

As we moved to a more Ethereum-compatible approach, in which now XC-20s are actual ERC-20 tokens with EVM bytecode, the XCM fee approach was changed to use a weight trader methodology. In this approach, weight is consumed by a foreign asset based in a new constant that reflects the relative price of a token with the native Moonriver token.

# Details

The calldata for this proposal was obtained from this [weight trader calculation script](https://github.com/Moonsong-Labs/xcm-tools/blob/main/scripts/update-weight-traders.ts). It uses the asset data from a JSON file and the CoinGecko API to obtain the price for each asset. Then, it calculates the relative price (considering decimals).

For assets that do not have a CoinGecko price feed, we've decided to make the XCM execution fee extremely high, making it not really feasible to pay XCM execution with these assets. We've decided on this approach as generally speaking tokens that are not in CoinGecko are from projects not active, etc.

The calldata:

`0x1e00547301010300a10f043205011f00000000007fbdbba4dc260a000000007301010300a10f043205200000008f3ceb3e6f06020000000000007301010200411f0602008100000000000000000000000000000000000000000000000000000000000000007282e110a35223000000000000007301010200411f0602008000000000000000000000000000000000000000000000000000000000000000000000000000997d138210eb0300007301010200451f0602000100000000000000000000000000000000000000000000000000000000000000008198e522585614000000000000007301010100511f0000ea200b17b118110000000000000073010101005d1f000000000000808e5b35053ef90800007301010100711f00902f9be6bde0fc000000000000000073010102007d1f06045445455200000000000000000000000000000000000000000000000000000000000003123a834f4018000000000000007301010100012000000040abfc84069e3205000000000073010101009120c06a3a3f970899020000000000000000730101020095200603484b4f00000000000000000000000000000000000000000000000000000000007b24bc83db020000000000000000000073010101009d20905e794a77646e0000000000000000007301010200b1200602000b00000000000000000000000000000000000000000000000000000000000000000000000082fe98c36c7b2a0000007301010200b1200602000c00000000000000000000000000000000000000000000000000000000000000004fa9a26953da1d000000000000007301010200e5200405c7f02f000000000000000000000000007301010200e920040a000054626d796be84f000000000000007301010200f92006040000000000000000000000000000000000000000000000000000000000000000c7f02f0000000000000000000000000073010101000921000053641af9f8dc09000000000000007301010200352105007b24bc83db0200000000000000000000730101000000001243f430f2da08000000000000`

This was tested in Chopsticks.

Send a batch of dispatch calls.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatched without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

## Complexity
- O(C) where C is the number of calls to be batched.

This will return `Ok` in all circumstances. To determine the success of the batch, an
event is deposited. If a call failed and the batch was interrupted, then the
`BatchInterrupted` event is deposited, along with the number of successful calls made
and the error of the failed call. If all were successful, then the `BatchCompleted`
event is deposited.

#83 Update XCM Fee Amounts

No Active Proposals