Update the x/erc20 module’s IBC middleware, callback logic to cover IBC v2 packet

[vladjdk]

Update the x/erc20 module’s IBC middleware, callback logic to cover IBC v2 packet

• Context: The ibc_callback/middleware logic in the x/erc20 module converts an IBC-denominated token to an ERC20 token for EVM user convenience upon receipt.
• The current ibc_callbacks logic only handles packets from IBC v1. Thus, logic for handling IBC v2 Packets must be added.
• Additionally, add middleware and routers in the reference example chain’s app.go to match IBC v2. This will serve as a reference for chains needing setup and facilitate E2E test case additions based on the example chain.

Considerations and Conclusion

Evaluation of Callback vs Middleware for x/erc20 Module

Summary

• The x/erc20 module currently adopts a middleware-based implementation.
• After evaluating the characteristics of both approaches, middleware remains the preferred design under current constraints.
• Upgrade the middleware to support IBC v2 while maintaining the current logic and architecture

Callback vs Middleware: Comparison

• Design Comparison:
  • Compared the characteristics of:
    • [Callback Middleware]
    • [Standard Middleware]
• Callback Model Considerations:
  • Requires specifying contractAddr during the channel open phase
    • Example: WASM callback in Gaia
• Current Implementation:
  • x/erc20 module uses a middleware-based architecture
• Current Middleware Constraints:
  • Designed exclusively for ICS20 transfer channels
  • Lacks flexibility for multiple or dynamic channel configurations
  • Existing middleware structure remains appropriate for the current scope

---

Middleware Interface Review after IBC v2 Changes

Summary

• In IBC v2, the handshake process is removed, leading to structural changes in middleware interfaces.
• After evaluating to determine whether the x/erc20 IBC middleware needs any changes,
• The x/erc20 module does not rely on handshake-related interfaces.
• Confirmed safe to continue using the current middleware without modification in this respect.

Interfaces Currently Used in x/erc20

• OnSendPacket
• OnRecvPacket
• OnTimeoutPacket
• OnAcknowledgementPacket

These correspond to the standard packet flow hooks and are not affected by the handshake-related changes introduced in IBC v2 Middleware Interfaces

[vladjdk]

I'm in favour of keeping the middleware consistent to what there is now and diving deeper into a redesign if needed after we launch a v1.

If we plan on redesigning, we should wait until we resolve #65 and decide on what we'll be doing with token state as a whole.

In general, I'm in favour of keeping this as the way tokens get brought into the EVM from other chains, but we should discuss that in the other issue.

[dongsam]

Progress note

Through the v10 bump PR #51, the middleware v2 implementation has been added, and it has been confirmed to work without issues for basic cases on the feat/ibc-v10 branch.

However, test cases for ERC20 pairs related to v2 packets still remain to be added and verified due to the current / restriction logic. These test cases will be added and validated after PR for #61, which removes the erc20/ prefix, is merged.

c.c @zsystm