Due to out-of-gas during deployment, I plan to split one large contract into two: contract A to keep state and is not meant to store any ETH, any state change functions are modified to be allowed to call from contract B only

Contract B is meant to receive/withdraw ETH and be public facing. Its withdraw function will validate the corresponding state in contract A before proceeding with msg.sender.transfer(_validatedAmount).

The question is: Could there be any pitfall of this design to split state and ETH into two contracts this way?

2 Answers 2


Some points that immediately come into mind:

1) Make contract A functions internal or verify the calls are coming from address of contract B.

2) If you go with second approach, delegate the verification i.e. a call to update address function will change B address in A. This way you don't have to keep redeploying A.

3) make payable fallback for A incase someone is generous to send eth in A

4) I don't know the exact use case but I am sure you will share some object information. be careful and make sure proper checks are present.

5) In the end write good test cases

Your end goal should be that contract A private information is inaccessible to rest of the world. Even one leak can be heavy. Hope it helps!


Good points from blockwala. It seems like you would like contract A to be a library, which is a special contract in Solidity that lets you delegate calls from one contract to another. https://solidity.readthedocs.io/en/latest/contracts.html#libraries

Delegate calls don't save the address of contract B calling to A, and it uses the code of A to operate on the state of B, so if you want to prevent other contracts from using your library, or want A to keep common state across multiple contracts B, you might want to keep your current model of Contract A and Contract B.

You now deploy Library A separately from (and before) Contract B, splitting gas costs as you desired, and you have an extra linking step of substituting the address of A into B, before deploying it.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.