#746 will first introduce the DepositManager.sol. Bidder accounts are intended to set their code via EIP 7702 to that contract to enable on-chain, oracle invoked, auto deposit.
In this initial PR, a bidder "setting their code" will be enabled by a simple forge script. A future PR should enable bidders to set their code through the bidder node grpc/REST apis.
The geth client tooling for EIP 7702 is sparse https://github.com/ethereum/go-ethereum/blob/v1.15.11/core/types/tx_setcode.go, and only implements SignSetCode accepting the ecdsa.PrivateKey type. So we'll either need to create our own 7702 auth sig code in golang compatible with our usage of ContractBackend, or find some other client library in golang that could work for us, maybe Erigon.
Alternatively the eip 7702 auth could be done in JS etc.
Note the MEV_COMMIT_AUTODEPOSIT_AMOUNT and MEV_COMMIT_AUTODEPOSIT_ENABLED env vars can be reused for this "setting code" logic.
Possibly related to #679
#746 will first introduce the
DepositManager.sol. Bidder accounts are intended to set their code via EIP 7702 to that contract to enable on-chain, oracle invoked, auto deposit.In this initial PR, a bidder "setting their code" will be enabled by a simple forge script. A future PR should enable bidders to set their code through the bidder node grpc/REST apis.
The geth client tooling for EIP 7702 is sparse https://github.com/ethereum/go-ethereum/blob/v1.15.11/core/types/tx_setcode.go, and only implements
SignSetCodeaccepting theecdsa.PrivateKeytype. So we'll either need to create our own 7702 auth sig code in golang compatible with our usage ofContractBackend, or find some other client library in golang that could work for us, maybe Erigon.Alternatively the eip 7702 auth could be done in JS etc.
Note the
MEV_COMMIT_AUTODEPOSIT_AMOUNTandMEV_COMMIT_AUTODEPOSIT_ENABLEDenv vars can be reused for this "setting code" logic.Possibly related to #679