# Proxy Contracts Inheritance Hierarchy **URL:** \ **Category:** Upgrades\ **Created:** [October 18, 2020, 1:23pm UTC](https://forum.openzeppelin.com/t/proxy-contracts-inheritance-hierarchy/4174 "2020-10-18T13:23:23Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![cjd9s](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@cjd9s](https://forum.openzeppelin.com/u/cjd9s)\ **Post date:** [October 18, 2020, 1:23pm UTC](https://forum.openzeppelin.com/t/proxy-contracts-inheritance-hierarchy/4174/1 "2020-10-18T13:23:23Z")
Hi everyone, I trust everyone is well. I’ve been studying the proxy contracts to get a better understanding of how they work. I’ve come across a few things that I don’t understand along the way. I’ve listed some questions below. - The BaseAdminUpgradeabilityProxy contract inherits the BaseUpgradeabilityProxy contract, but only imports the UpgradeabilityProxy.sol file. Why does this work? Does this work because the UpgradeabilityProxy contract imports and inherits the BaseUpgradeabilityProxy? Why wouldn’t you just import the BaseUpgradeabilityProxy contract into the BaseAdminUpgradeabilityProxy contract? ![BaseAdminUpgradeabilityProxy Inheritance Issue](https://us1.discourse-cdn.com/flex022/uploads/zeppelin/original/2X/a/a78690be4fa526afebe77d65288cc21159632923.png) - Similarly, the AdminUpgradeabilityProxy contract inherits the UpgradeabilityProxy contract and BaseAdminUpgradeabilityProxy contract, but only imports the BaseAdminUpgradeabilityProxy.sol file. Does it have access to UpgradeabilityProxy.sol through the BaseAdminUpgradeabilityProxy contract? ![AdminUpgradeabilityProxy Inheritance Issue](https://us1.discourse-cdn.com/flex022/uploads/zeppelin/original/2X/6/6c5f30672abaed3315314ebfc283bcb4ee92492e.png) - There is a \_willFallback() function in the BaseAdminUpgradeabilityProxy contract. In that function, it invokes super.\_willFallback(). I thought that super only accessed functions from the immediate parent contract level, but the \_willFallback() function is found in the Proxy contract which is two levels above. If you use super, does it just keep going up levels until it finds the referenced function? Is there a limit to how my inheritance levels it will go up? ![Proxy](https://us1.discourse-cdn.com/flex022/uploads/zeppelin/original/2X/9/98f42b41e753bae6346da665bf87cc1eb9139bf0.jpeg) The rectangles mean inherited contracts and the ovals mean imported, but not inherited. I would appreciate any advice or comments. Cheers. Sincerely, Craig ---
**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\ **Post date:** [October 19, 2020, 9:23am UTC](https://forum.openzeppelin.com/t/proxy-contracts-inheritance-hierarchy/4174/2 "2020-10-19T09:23:50Z")
Hi @cjd9s, You may want to look at the proxy contracts that were migrated to OpenZeppelin Contracts 3.x which could be simpler to follow the hierarchy: > Currently the OpenZeppelin Upgrades Plugins use contracts in Upgrades Core (though this will change to use the proxy contracts in OpenZeppelin Contracts). So recommend studying these versions as this is what you would use when deploying an upgradeable project today with the Upgrades Plugins. > > > //github.com/OpenZeppelin/openzeppelin-upgrades/tree/%40openzeppelin/upgrades-core%401.2.0/packages/core/contracts/proxy The proxy contracts used in the OpenZeppelin CLI, as you found, have a more complex hierarchy. Please see: [Building for interoperability: why we’re focusing on Upgrades Plugins](https://forum.openzeppelin.com/t/building-for-interoperability-why-we-re-focusing-on-upgrades-plugins/4088) as we are focusing our upgradeability efforts on the Upgrades Plugins exclusively. [https://github.com/OpenZeppelin/openzeppelin-sdk/tree/v2.8.2/packages/lib/contracts/upgradeability](https://github.com/OpenZeppelin/openzeppelin-sdk/tree/v2.8.2/packages/lib/contracts/upgradeability) * * * > [@cjd9s](#): > > The BaseAdminUpgradeabilityProxy contract inherits the BaseUpgradeabilityProxy contract, but only imports the UpgradeabilityProxy.sol file. Why does this work? Does this work because the UpgradeabilityProxy contract imports and inherits the BaseUpgradeabilityProxy? Why wouldn’t you just import the BaseUpgradeabilityProxy contract into the BaseAdminUpgradeabilityProxy contract? I assume this works because an import of a parent allows inheriting from a grand parent. It would be simpler if the imports matched the inheritance. > [@cjd9s](#): > > Similarly, the AdminUpgradeabilityProxy contract inherits the UpgradeabilityProxy contract and BaseAdminUpgradeabilityProxy contract, but only imports the BaseAdminUpgradeabilityProxy.sol file. I assume the same applies. > [@cjd9s](#): > > If you use super, does it just keep going up levels until it finds the referenced function? Is there a limit to how my inheritance levels it will go up? I assume that `super` calls up the inheritance tree: [https://solidity.readthedocs.io/en/latest/contracts.html#inheritance](https://solidity.readthedocs.io/en/latest/contracts.html#inheritance) I suggest trying it out with some simple contracts to see it for yourself. ---
**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\ **Post date:** [October 26, 2020, 12:59am UTC](https://forum.openzeppelin.com/t/proxy-contracts-inheritance-hierarchy/4174/3 "2020-10-26T00:59:59Z")
Hi @cjd9s, Let me know if you need more information. ---
**Author:** ![cjd9s](https://avatars.discourse-cdn.com/v4/letter/c/b9e5f3/32.png) [@cjd9s](https://forum.openzeppelin.com/u/cjd9s)\ **Post date:** [October 26, 2020, 2:57pm UTC](https://forum.openzeppelin.com/t/proxy-contracts-inheritance-hierarchy/4174/4 "2020-10-26T14:57:41Z")
Hi Andrew @abcoathup, If you ever stop hearing from me, it’s because I’m dead. I will never not need more information. I prefer to download and inherit the proxy contracts directly. I have gone through and mostly understand what is going on. It has been interesting to learn Yul. I do have a few questions, however. 1. My previous post had a question about super. I noted that the \_willFallback() function in BaseAdminUpgradeabilityProxy contract invokes super.\_willFallback(). However, there is no \_willFallback() in the immediate parent contract. It’s actually two levels up in the Proxy contract. As you suggested, I created some simple contracts in Remix. And, lo, even though there was no function in the parent contract, there was one in the grandparent contract and it worked. However, you copied a link to Solidity docs about inheritance. I noted the following: “It is possible to call functions further up in the inheritance hierarchy internally by … using super.functionName() if you want to call the function one level higher up in the flattened inheritance hierarchy (see below).” So, if I’m reading this right, it says that super can be used to call a function one level higher up in the inheritance hierarchy. However, it seems to work at least two levels up. Am I reading this wrong, do I not understand the specific order in the directed acyclic graph (DAG) of base classes, or is Solidity Docs wrong? 1. In the ProxyFactory contract there is a deployMinimal() function. // store next available memory address in clone let clone := mload(0x40) // Set the bytes of memory from the next available memory address (clone) to clone+32 // equal to // 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000000000000000000000 // which is the constructor of the clone contract mstore(clone, 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000000000000000000000) // Set the bytes of memory from clone+20 to clone+52 equal to targetBytes // which is the address of the implementation (logic) contract mstore(add(clone, 0x14), targetBytes) // Set the bytes of memory from clone+40 to clone+72 is set to equal // 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000 mstore(add(clone, 0x28), 0x5af43d82803e903d91602b57fd5bf30000000000000000000000000000000000) So, am I correct that the first store operation is the clone constructor? What is the signifiance of the final (third) store operation? 1. If I want to use the Proxy Factory contract, do I need to inherit the InitializableAdminUpgradeabilityProxy into my own contract and then change the import in the Proxy Contract from InitializableAdminUpgradeabilityProxy to my contract? And then replace the InitializableAdminUpgradeabilityProxy reference to my contract in the constructor function? As always, any insight you could provide would be great. Cheers. Sincerely, Craig ---
**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\ **Post date:** [October 27, 2020, 2:09am UTC](https://forum.openzeppelin.com/t/proxy-contracts-inheritance-hierarchy/4174/5 "2020-10-27T02:09:01Z")
Hi @cjd9s, > [@cjd9s](#): > > I prefer to download and inherit the proxy contracts directly. If you are deploying from Truffle or Buidler I recommend using the proxy contracts via OpenZeppelin Upgrades Plugins as the plugins will check upgrade safety when deploying and upgrading. > [@cjd9s](#): > > However, you copied a link to Solidity docs about inheritance. I noted the following: > “It is possible to call functions further up in the inheritance hierarchy internally by … using super.functionName() if you want to call the function one level higher up in the flattened inheritance hierarchy (see below).” I assume the documentation needs updating. I suggest creating an issue and if the Solidity team agree, a PR to update the docs: [https://github.com/ethereum/solidity/blob/develop/docs/contracts/inheritance.rst](https://github.com/ethereum/solidity/blob/develop/docs/contracts/inheritance.rst) > [@cjd9s](#): > > So, am I correct that the first store operation is the clone constructor? What is the signifiance of the final (third) store operation? For information on minimal proxies, I recommend reading: > **[Deep dive into the Minimal Proxy contract - OpenZeppelin blog](https://blog.openzeppelin.com/deep-dive-into-the-minimal-proxy-contract)** > > In this deep dive into low-level EVM code, you will learn how to code a Minimal Proxy (EIP 1167) from scratch, no Solidity involved. Finally, we see how to easily deploy the proxy using OpenZeppelin's SDK. > [@cjd9s](#): > > If I want to use the Proxy Factory contract, do I need to inherit the InitializableAdminUpgradeabilityProxy into my own contract and then change the import in the Proxy Contract from InitializableAdminUpgradeabilityProxy to my contract? And then replace the InitializableAdminUpgradeabilityProxy reference to my contract in the constructor function? Yes, that sounds right. You could modify the ProxyFactory to meet your use case. There is an open issue and a PR in OpenZeppelin Contracts to create a factory to deploy upgradeable contracts > > > We should provide functionality to make it simple to create proxy instances at r…untime. Creating a single proxy instance is simple using the proxy contracts provided, but it's worth providing something on top of that that implements a common pattern when the implementation contract needs to be reused. This pattern should be simple and not opinionated. > > The proposed design is a library with a \`ProxyFactory\` "object" that would be used as in the following snippet. > > \`\`\`solidity > contract MyFactory { > using Proxies for Proxies.ProxyFactory; > > // This struct contains the address of the implementation that is > // used for the proxies it creates. > struct Proxies.ProxyFactory factory; > > constructor() public { > // Initializes the factory struct by deploying the implementation > // and storing its address. > factory = Proxies.newFactory(FooUpgradeable.creationCode); > } > > // initializerData is the encoded call to the initializer function. > function deployInstance(address admin, bytes initializerData) public { > factory.deploy(admin, initializerData); > } > } > \`\`\` > > In this case the factory creates instances of \`TransparentUpgradeableProxy\`, but the same pattern could be offered for other kinds of proxies. We should think about this as it will affect naming. > > > 2339 > \