I’m trying to figure out if I can derive the set of possible addresses for a canister on the evm side using the t-ecdsa schema. The use case is that I want users to fund transactions my canister sends to an evm, but I don’t want them to share the same evm address because they may ‘swipe’ other users funding base eth token. (ie. I want to call function x so I wait until I see someone else fund the canisters t-ecdsa address and use their funds for my function call before they can).
Now I could us different derivations but then I have to tell my evm contract all possible valid callers. This is too expensive unless they can be derived somehow.
Is there a way I can tell an evm contract the ‘root’ of my canister t-ecdsa key and derive addresses using the derivation on the evm contract side? If so what would that look like?
If I can do this then I can assign unique derivations to users and call in a kind of account abstraction sense where the contract will be a be able to derive if the address is valid for a particular function.
Maybe another way to ask this is when I call to get the public key using a derivation, is there some silent prefix?(I assume the canister id is at least part of this silent prefix but I wonder if there is more). Maybe this is ‘secret’ and derived during the threshold construction, but I thought I’d ask.
So, If I get this right, the canister makes EVM contract interactions on behalf of users. These users should pay for the gas cost of the canister. And users should pay this cost in ETH, not in ICP?
In that case I’d say you would want to give each transaction an id, perhaps a hash of the transaction data. Plus you need a payment contract on the EVM chain.
This contract exposes a payable function that accepts the transaction hash as an argument.
On received payment, it forwards the funds to the canister address and emits an event with the transaction hash.
The canister monitors for these events and makes the transaction once payment is confirmed.
Alternatively, the frontend can notify the canister that a payment has been completed. This is cheaper and faster than the timer running on a timer every X seconds to check for payments.
I made one such contract for the C–ATTS project that has worked well:
Looks like it has potential. My concerns is that if gas price moves up I may not have enough gas and the user will have to do it again.
The other solution I came up with was just signing a packed tuple and having the contract ec recover the sig, but then I need to track nonce in my contract to prevent replay and evrecover is like 3000 gas.
The question remains if there is a derivation fiction that can be run off chain to discover valid t-ecdsa public keys. It may not be the solution here but I’m interested if they are “secret” or not.(obviously not that secret because anyone can call the function for a canister if, but perhaps they are only revealable by the signing set)