Dapp interaction

This is an idea for CREATE2 which can be applied in some situations. We use the fact that we can precalculate the CREATE2 address - which means we can transfer tokens here and we can even supply a salt! It is applied to ERC20 tokens where we try to semi-interact with contracts in a single TX.

The idea is that an user transfers tokens to the address which is precalculated by seeding the address of the user together with the calldata. Knowing these values proves that the user wants to “deposit” the value which is currently the balance of the precalculated address together with the calldata. Hence the seeded data in CREATE2 is the address of the user and the calldata.

Now let’s say we have an useless dummy contract to show the usage. An user A wants to transfer tokens to B but not directly. This useless SplitContract is deployed and we can now calculate the CREATE2 address where A should deposit: the salt is simply the address of A and B and the init_code simply transfers all tokens at the CREATE2 address to SplitContract . When we created the contract at the address where A deposited to in the SplitContract we hence knew the seed so at this point we also know address B . We can calculate how many tokens were transferred and now transfer all tokens to B. Note that the CREATE2 contract can be selfdestructed immediately after we transferred tokens (hence yielding extra used gas of about 11k (~32k contract deployment, 22k refund, ~1k execution cost).

This is of course rather stupid but it can be expanded. Think of a DDEX: here you can match someones trade by transferring tokens to a certain address. The only thing the user now needs to do is to broadcast that these tokens are deposited and either the maker of this order can now take them or the user includes a fee for someone else to ““mine”” this token on-chain which gives them incentive to pay for this gas. (This fee is hence in the calldata / salt). If the order is not matched the user can go on-chain to withdraw their tokens by simply providing the supplied calldata and showing that the user wants to cancel the order (to prevent the contract to try to match the order again). (Or the order is fulfilled already).

Notice that in the DDEX cases the contract is also only created and selfdestructed so no code is deposited, yielding a low amount of extra gas. The only downside in the implementation-side is that you can’t selfdestruct, create2 it again, and selfdestruct it again in the same tx which means you have to deposit code if you want to call back into this contract for some reason. When thinking about this I can also see why it would be really nice to have some kind of memory between call frames, something EIP 1283 tries to accomplish.