Challenge in sending packets to ICS-20 contract with starkli

[Farhad-Shabani]

Context

To interact with IBC Cairo contracts, users can utilize starkli for declaring, deploying, and invoking contracts. While declaring and deploying IBC contracts with starkli is relatively straightforward, invoking them presents challenges due to the need for Cairo-encoded arguments, which hampers the user experience.

This issue is particularly relevant when wanted to submit a MsgTransfer to the ICS-20 Cairo contract. It involves constructing the message and serializing it into Cairo’s format.

Proposal

To address this, there should be a mechanism that either outputs a ready-to-use encoded value for users to pass directly into starkli, or alternatively, a command within the relayer’s CLI so that it handles the underlying complexity by accepting a few arguments like transfer amount and receiving address.

cc @soareschen, if it make sense to implement this as part of the relayer?

[soareschen]

I am thinking that the simplest way is to build a simple CLI separately that would encode the messages with Cairo and output them as hex strings. The user can then copy and paste the string to starkli, or use bash subshells to compose them with the main starkli command.

This is simpler than providing it via the relayer, as a Starknet user won't need to figure out how to install and configure the relayer, together with the Cosmos config. On the other hand, we can reasonably expect all Starknet users know how to use starkli already.

[rnbguy]

I wonder if it makes sense to look into some dApp frontends, such as

• Scaffold-Stark
• Starknet-Scaffold

[rnbguy]

simplest way is to build a simple CLI separately that would encode the messages with Cairo

as a Starknet user won't need to figure out how to install and configure the relayer

I think, we should just provide the CLI via relayer and make the relayer configuration optional for that subcommand.
It should be similar to hermes tx ft-transfer ... except for the aut-relaying part (as our validation will be auto-clearing the packets).

I suggest this as it is an interm solution until the Polaris frontend supports our implementation. I don't think, we need a separate binary for this.

Also, if you feel, starknet users may be concerned about wallet handling, we can offload the send_message call to starkli by creating another component. This avoids the de/serialization part and keeps the wallet handling and transaction submission at starkli.