Build backend executor service for walletless onboarding of USDC

[p-offtermatt]

This has two parts,

1. EVM->Neutron
2. Neutron->Inflow

A forwarder and proxy contract is instantiated once per user; we only instantiate contracts when there are enough funds sent in to cover our fee/some minimum amount. The address can be precomputed even before we instantiate the contract via https://immunebytes.com/blog/explained-create2-opcode-in-solidity/.

1. EVM->Neutron:
   Solidity contract: https://github.com/informalsystems/hydro/tree/main/contracts/inflow/evm
   This contract charges a fee https://github.com/informalsystems/hydro/blob/f5678d3c685e2f9237d4b75a6e0230335d197953/contracts/inflow/evm/contracts/CCTPUSDCForwarder.sol#L36C1-L38C48

2. Neutron->Inflow:
   CW contract https://github.com/informalsystems/hydro/blob/main/contracts/inflow/proxy/src/contract.rs

Interface:

• ContractAddressesForUser(userID: string) -> (string, string)
• NextProcessID(user) -> uint
• Status(userID, processId) -> string
• Fee(amount) -> uint

Monitors the instantiated contracts and forwards funds (permissionlessly by calling the forward entrypoint).
-> only forward and instantiate if there are sufficient funds in the contract

Status provider interface:

• Pending incoming funds: Waiting for the user to send funds
• Pending more incoming funds: User has sent funds, but not enough to forward them
• Transfer in progress: Enough funds, now waiting for the transaction to land onchain or for the IBC transfer. Attach the most relevant TX hash
• Transfer done/Deposit in progress: Transfer was complete, now waiting to deposit in Inflow
• Deposit done: Deposited funds into Inflow

Note: The deployment for this has to be hardened. If the server is compromised it could send wrong contract addresses to the frontend.

Question: Is there a new forwarder contract for every time they send this action?

We just reuse the same contract for the users. It lets the users keep the contract address e.g. in their addressbook on Coinbase, and lets them verify sends with small amounts.

Question: If a user has multiple deposits, how should we do it?

Attach a process id to the deposit to differentiate them; one time forwarding is one process id. If there are edge cases here, it's ok, it will be rare for the deposits to overlap, the most important thing is that the users money gets put into Inflow and amounts larger than the minimum don't get stuck

Question: Should we have the code in this repo or a separate one?

Just start in the Hydro repo, we can move it in a separate one if necessary later.

Nice to have:

• Get a notification when gas in the operator wallet get low
• Get simple metrics of how much money has flown through the system (also per-user)
• A way for the frontend to easily verify that the contract at the claimed address is fine (recomputing the create2 on the frontend? contract checksum?)