The problem ReTransICP solves

The pain

Smart contracts on EVM chains are dormant without an external trigger. Not anymore! Now, they can be triggered by an Internet Computer Canister AND can schedule their next activation by emitting an event to that canister.

The solution

This allows for all kinds of automation, and the example implements a simple show case:
Paying ERC20 tokens each week (day, month, 18 minutes) to a certain address.

more, please

There are lots of possible solutions that can be developed on this foundations. Smart contracts can rebalance, decide how often to do so, stay in yield positions just until a payment needs to be sent, and so on.

Why this solution

The chain fusion approach of ICP makes this approach composable. After setting up the container, one (or later many) contracts can use it to generate custom wake-up calls in a trustless, very comfortable way. There can be a central scheduler smart contract on eth mainnet, where other contracts order their triggers, and that provides them reliably.

Challenges we ran into

When touching ICP for the first (or second) time, it is a new world. While examples and documentation exist, often they target different use cases.
Special mention for very intrusive installation and configuration.

Some notes I tooke along the way:

• download shit | shell is an antipattern

• rustup and <span style="color: #d4d4d4;"><span style="color: #ce9178;">rustup target add wasm32-unknown-unknown missing</span></span>

• libraries in repo is weird

• caddy requiring sudo is creepy

• curl config was missing global, therefore failing without sudo
  {
  http_port 8080
  }

• redeeming a coupon is really a bad experience. doesn't work without dfx start, and there is no documentation about this wallet you that you have to note the address of

• maybe create a PR from my repo to upstream to compare the changes and ask me if you have questions