Adding new chains is definitely a higher priority, but this is already being worked on and should be coming out reasonably soon. A few things are worth pointing out that apply in general:
- Prioritisation of the implementation of proposals only happens after the RIP process has been passed through successfully. An RFC is not the place for prioritisation discussion unless there are dependencies involved (e.g. implementing one RFC would be harder/easier based on whether another RFC has been implemented).
- The discussion and development of one feature does not mean that development of other features must halt. It is important to do these things in parallel, because the team is able to work on multiple things simultaneously, so having a pipeline where we can be discussing and designing features while implementing other features is important.
With respect to this RFC specifically, it is actually quite important to understand how fees work when thinking about supporting new chains. From the RFC itself:
In the future, we want to be able to compute fees on RenVM instead of on the minting chain (e.g. Ethereum). The use of an explicit Darknode Payment contract, bound to pay fees to an exact address (the operator), does not make for a smooth transition away from Ethereum.
This is an important point. What happens when we support BTC to Acala? Neither network has anything to do with Ethereum, so how will fees aggregate into an Ethereum contract? In the case of this RFC, this problem is not solved, but the addition of OFT definitely makes this problem easier to solve in the future (for example, you could keep fees in RenVM but still listen to OFT burn events, or you could allow OFTs to move between chains and be burnt where relevant, etc.). That is out-of-scope for now, but this RFC certainly opens up new possibilities thanks to the flexibility of tokens.