Regular address turns into a contract after receiving a transfer?

Question

To accept payments in ether myself, I first tried how others have implemented it. So I bought an item in a store that uses Coinbase Commerce to accept crypto payments and paid for my item with ether. Here is my payment transaction: https://etherscan.io/tx/0x229fc693785f97f905f9db953800edca58cced706592684d5f24ca9b69d80dac

At the moment I made this transaction, etherscan was showing the recipient address 0x6a173337f2bb7ad85c011dda499ab9cfc1016461 as a regular (external) address that has just received my payment and had the ether on its balance.

But 8 minutes (37 blocks) later a series of internal transactions appeared: https://etherscan.io/address/0x6a173337f2bb7ad85c011dda499ab9cfc1016461/advanced#internaltx

Which included the contract creation and a transfer of the funds to another address. Here is the parent transaction: https://etherscan.io/tx/0xc05d18302cf9363c858cea9068f1ba88827ef5b0d446553c44c5c9cab282c693

My question is: how could a contract be created on an existing address that was previously used as external? And what exactly has happened there in general? Does anyone understand such a scheme works under the hood? Any clues are highly appreciated, thanks!

Answer 1

Looks like the answer to your question is CREATE2. This is an EVM opcode that was created to allow contracts to be created deterministically, (other people use the term 'counterfactually')

It's a fairly complicated topic. One link is here: https://hackernoon.com/using-ethereums-create2-nw2137q7 but there are many you could check out.

Perhaps most simply put, it means that you can determine in advance the address that a new contract will be deployed to (which is much harder in the case of 'CREATE') - and this means that funds could be sent to the contract in advance of the contract actually being deployed.

Your use of the word "External" is perhaps misleading you here. All you did is send your funds to an address. And those funds can only be used by someone that knows the private key of the address, or a contract deployed to that address. Here - this is the second case - all that happened is that the contract was deployed afterwards.

Answer 2

CREATE2 is very cool, I was one of the engineers that worked on this project at Coinbase Commerce. You can read more about the implementation and our approach at the following blogpost

https://blog.coinbase.com/usdc-payment-processing-in-coinbase-commerce-b1af1c82fb0

Answer 3

As previously stated from the other answers, they use CREATE2.

That happens because when you receive ERC-20 or any other token on a unique address, from a business perspective, it is very operationally costly, as they would need to top up these accounts with funds to be able to pay the GAS fees to sweep the tokens out to a centralised cold wallet.

With the CREATE2 and minimal proxies architecture, they ensure that they cut one of these steps from the sweeping phase, and the gas fees to move those tokens can be paid from a central wallet that is calling the smart contract function.

Although you have a point that it is costly to deploy these smart contracts, comparing to 2 transactions to sweep these tokens, it is much more effective, especially when you take into account that the minimal proxy method optimises this deployment cost significantly, and with CREATE2 you can choose when you want to deploy it depending on network traffic.