feat!: use antehandlers for wasm calls to core

[cgorenflo]

AXE-2180

[xyuanatbgraph]

will user-made cosmwasm contracts deployed on axelar eventually have access to evmkeeper and axelarkeeper routes? or is only gatewayAddress allow to send messages at all?

if yes, this might take care of my other PR

[cgorenflo]

will user-made cosmwasm contracts deployed on axelar eventually have access to evmkeeper and axelarkeeper routes? or is only gatewayAddress allow to send messages at all?

if yes, this might take care of my other PR

yes, if a route is only available through the core (evm, axelarnet) cosmos sdk modules, the cosmwasm router contract is going to reroute messages there

[xyuanatbgraph]

will user-made cosmwasm contracts deployed on axelar eventually have access to evmkeeper and axelarkeeper routes? or is only gatewayAddress allow to send messages at all?
if yes, this might take care of my other PR

yes, if a route is only available through the core (evm, axelarnet) cosmos sdk modules, the cosmwasm router contract is going to reroute messages there

i see, thanks. does this require the evm axelarnet modules to migrate to not legacy? i think so, after looking at how x/wasm implementation

i checked and this might just be types.RegisterMsgServiceServer(cfg.MsgServer(), keeper.NewMsgServerImpl(...)) in module.go. if this make sense would it help if i make pr to add modules to grpc msg server in this way?

[cgorenflo]

will user-made cosmwasm contracts deployed on axelar eventually have access to evmkeeper and axelarkeeper routes? or is only gatewayAddress allow to send messages at all?
if yes, this might take care of my other PR

yes, if a route is only available through the core (evm, axelarnet) cosmos sdk modules, the cosmwasm router contract is going to reroute messages there

i see, thanks. does this require the evm axelarnet modules to migrate to not legacy? i think so, after looking at how x/wasm implementation

i checked and this might just be types.RegisterMsgServiceServer(cfg.MsgServer(), keeper.NewMsgServerImpl(...)) in module.go. if this make sense would it help if i make pr to add modules to grpc msg server in this way?

No work required. The necessary changes have already been merged into main. The nexus/keeper/msg_dispatcher.go handles calls from wasm and routes them to the nexus

[xyuanatbgraph]

will user-made cosmwasm contracts deployed on axelar eventually have access to evmkeeper and axelarkeeper routes? or is only gatewayAddress allow to send messages at all?
if yes, this might take care of my other PR

yes, if a route is only available through the core (evm, axelarnet) cosmos sdk modules, the cosmwasm router contract is going to reroute messages there

i see, thanks. does this require the evm axelarnet modules to migrate to not legacy? i think so, after looking at how x/wasm implementation
i checked and this might just be types.RegisterMsgServiceServer(cfg.MsgServer(), keeper.NewMsgServerImpl(...)) in module.go. if this make sense would it help if i make pr to add modules to grpc msg server in this way?

No work required. The necessary changes have already been merged into main. The nexus/keeper/msg_dispatcher.go handles calls from wasm and routes them to the nexus

Thank you. But I have one confusion. I checked this and it looks like it is on only for GeneralMessages. What about sdk.Msg but from cosmwasm contract to x/evm or x/axelarnet module? It seems nexus dispatchMessage doesnt reroute there. This due to all Custom msgs encoded to "exported.WasmMessage"

[cgorenflo]

will user-made cosmwasm contracts deployed on axelar eventually have access to evmkeeper and axelarkeeper routes? or is only gatewayAddress allow to send messages at all?
if yes, this might take care of my other PR

yes, if a route is only available through the core (evm, axelarnet) cosmos sdk modules, the cosmwasm router contract is going to reroute messages there

i see, thanks. does this require the evm axelarnet modules to migrate to not legacy? i think so, after looking at how x/wasm implementation
i checked and this might just be types.RegisterMsgServiceServer(cfg.MsgServer(), keeper.NewMsgServerImpl(...)) in module.go. if this make sense would it help if i make pr to add modules to grpc msg server in this way?

No work required. The necessary changes have already been merged into main. The nexus/keeper/msg_dispatcher.go handles calls from wasm and routes them to the nexus

Thank you. But I have one confusion. I checked this and it looks like it is on only for GeneralMessages. What about sdk.Msg but from cosmwasm contract to x/evm or x/axelarnet module? It seems nexus dispatchMessage doesnt reroute there. This due to all Custom msgs encoded to "exported.WasmMessage"

I'm not sure what you mean by that. sdk.Msg is cosmos's basic message interface. You can only route expected messages to any given module (see handlers and msg servers in each module).
The cosmwasm routing is only going to support general message passing. Token transfers will work through the Interchain Token Standard (https://docs.axelar.dev/dev/send-tokens/interchain-tokens). This will be supported for messages from cosmwasm to any existing chain registered in the x/axelarnet and x/evm modules.

[xyuanatbgraph]

Hi is it possible allow stargate? We meant to use these modules to script axelar interactions. I think security is same because only using Msg types already in app.

[cgorenflo]

Hi is it possible allow stargate? We meant to use these modules to script axelar interactions. I think security is same because only using Msg types already in app.

To guarantee safety we are going to roll out cosmwasm support with stargate and direct IBC calls (without going through axelar routing) blocked. We're going to revisit this once we are absolutely sure it can't be used to cause harm to the protocol

[xyuanatbgraph]

Hi is it possible allow stargate? We meant to use these modules to script axelar interactions. I think security is same because only using Msg types already in app.

To guarantee safety we are going to roll out cosmwasm support with stargate and direct IBC calls (without going through axelar routing) blocked. We're going to revisit this once we are absolutely sure it can't be used to cause harm to the protocol

It makes sense, thanks. Do you have estimate on when you think that happens? e.g. 1+, 3+, 6+ months?

[cgorenflo]

Hi is it possible allow stargate? We meant to use these modules to script axelar interactions. I think security is same because only using Msg types already in app.

To guarantee safety we are going to roll out cosmwasm support with stargate and direct IBC calls (without going through axelar routing) blocked. We're going to revisit this once we are absolutely sure it can't be used to cause harm to the protocol

It makes sense, thanks. Do you have estimate on when you think that happens? e.g. 1+, 3+, 6+ months?

Not before Q2