EVM Forwarder SC implementation

[dusan-maksimovic]

Description

Implementation of EVM SC to bridge USDC tokens from EVM chains to Neutron in order to deploy them in Inflow USDC Vault.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• Targeted the correct branch
• Included the necessary unit tests
• Added/adjusted the necessary interchain tests
• Added necessary migration code for all stores that were adjusted or added
• Added a changelog entry in .changelog
• Compiled the contracts by using make compile and included content of the artifacts directory into the PR
• Regenerated front-end schema by using make schema and included generated files into the PR
• Updated the relevant documentation or specification
• Reviewed "Files changed" and left comments if necessary
• Confirmed all CI checks have passed

[Copilot]

Pull request overview

This PR implements an EVM smart contract to enable bridging of USDC tokens from EVM-compatible chains to Neutron via the CCTP (Cross-Chain Transfer Protocol). The contract acts as a temporary holder and forwarder of USDC tokens, with role-based access control and emergency pause functionality.

Key Changes

• New Solidity smart contract CCTPUSDCForwarder with operator/admin roles for bridging USDC via CCTP
• Hardhat development environment setup with TypeScript configuration and OpenZeppelin dependencies
• Documentation explaining the contract's purpose, constructor parameters, and compilation instructions

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
contracts/inflow/evm/contracts/CCTPUSDCForwarder.sol	Core forwarder contract implementing CCTP bridge integration with pause mechanism and role-based access control
contracts/inflow/evm/package.json	Node.js project configuration with Hardhat and OpenZeppelin dependencies
contracts/inflow/evm/tsconfig.json	TypeScript configuration for Node 22 compatibility
contracts/inflow/evm/hardhat.config.ts	Hardhat configuration specifying Solidity 0.8.28
contracts/inflow/evm/.gitignore	Git ignore patterns for node_modules, build artifacts, and cache directories
contracts/inflow/evm/README.md	Documentation describing the contract's purpose, parameters, and compilation process
.changelog/unreleased/features/359-evm-forwarder-contract.md	Changelog entry for the new forwarder contract feature

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[p-offtermatt]

The basic CCTP wrapper looks good to me. Did you try this on some networks already? How much gas is it to instantiate this? Would be interested to see for ETH and Base

The next step would probably be to harden this:
The one thing that comes to mind for me is, we need a way to "emergency extract" funds in the contract while it is paused (pausing does not much right now, since anything in the contract will be stuck, right? So it's not really realistic to do)

[dusan-maksimovic]

The basic CCTP wrapper looks good to me. Did you try this on some networks already? How much gas is it to instantiate this? Would be interested to see for ETH and Base

The next step would probably be to harden this: The one thing that comes to mind for me is, we need a way to "emergency extract" funds in the contract while it is paused (pausing does not much right now, since anything in the contract will be stuck, right? So it's not really realistic to do)

Tried it on Ethereum. Instantiated 2 contracts and the costs were:
0.00003178318176228 ETH
0.000022857230321211 ETH

After SC is paused, an admin can call approve() to grant access to any address to spend tokens held by the contract. Then the specified address can call transferFrom() directly on ERC-20 contract to move the USDC to new owner. But if you want, we can introduce new function that will immediately move the funds to new owner?

[p-offtermatt]

At time of writing, looks like it's about 10 cents to instantiate this.

The approval sounds good enough, even if it's not so direct. But it feels like charging the fee through the approval is a bit weird, but maybe this is just the way to do it in Solidity? I would expect that when we bridge, a hardcoded portion of the amount (say, 0.1% with a minimum of 0.2 USDC) is taken from the funds and given to a feecollector