Sign modes reduction in the Cosmos SDK

This issue aims to summary the current status and lay out what would be needed for reducing the amount of sign modes the SDK handles by default.

Current status

The SDK currently has 4 sign modes:

• Direct
• Direct Aux
• Textual
• Amino JSON

Also SignModeEIP191 is available but not implemented by default.

Direct and Direct Aux

Proposed in ADR-020.

Direct is meant to make sign docs easier/more standard by using protobuf, so clients can easily generate and sign transactions without needing extra dependencies.

Direct Aux allows just enough malleability to easily create a multisig transaction without knowing the signers from the start (by not including AuthInfo in the sign bytes).

Pros: Easy to use in clients that can make use of protobuf
Cons: No support on hardware wallets; not human friendly

Amino JSON

Now considered legacy but kept for backwards compatibility (mainly for multisigs).

Textual

Proposed in ADR-050.

Provides a better UX making the sign bytes human readable, specially for hardware wallets like Ledger.

Pros: human readable, supported by hardware wallets
Cons: requires on-chain info (denom metadata); doesn't allow multisgs as is.

Similarly to Direct, "Textual Aux" would be possible to develop in order to support multisigs.

Proposal

Remove Direct and Direct Aux, keeping only Amino JSON and Textual.

Issues to solve on Textual before making it the default

Allow offline signing

This can be done in 2 ways:

• Allow passing in a local denom metadata store (like a JSON).
• Modify Textual and renderers to allow an "offline" mode which ignores on-chain data

Add multisig support

Leaving this out of the scope, but it should be solved outside of sign modes.

Good client support

Before making Textual the standard signing mode, we must have at least an implementation in Javascript. This implementation must also accept custom renderers like the Go implementation.

This is a very important point given that Direct is better at this.

Could AminoJSON be removed?

After a migration path is available, yes, Amino JSON can be removed.