Alexander Theißen

I don't know if `cargo` merged those two or if one takes precedence in the presence of both. If the former is true we can close this.

In addition what you already stated: Most features are also broken in `parity-wasm`. I recently fixed multi-value support but especially `simd128` needs some fixing. `pallet-contracts` depends on `parity-wasm` for instrumentation....

Is this still true with rv64 support?

Yes it should be roughly the same. Even slightly less after the rework because we still add the `noop_host_fn` onto the new weight as you pointed out. Could be attributed...

`seal_call` still has **3** extra reads and **1** extra write from before.

> @athei I assumed that `chain_extension` calls the API over the `Ext` trait, so read-only protection in the `Ext` implementation is good enough, please comment Another option is to extend...

This is a general difference we have to Ethereum that is independent of `STATICCCAL`. We don't allow balance transfers to plain account via `seal_call`. We need to add this behaviour...

This is definitely good for replacing all those getter RuntimeAPIs which are mostly boilerplate. However, it looks to me as a more comfortable way to define a subset of RuntimeAPIs....

Good point. Maybe we should incorporate more robustness and versioning. If it works well we can backport it to `Call`.

> XCQ will not replace this. As XCM is not replacing pallet calls. I had a brief discussion with @gavofyork about this in Malmö. I noted that `Call` seems redundant...