Proxies Table

Type	Summary	Pros	Cons	Gotchas	Who should implement	Known Vulnerabilities	Upgradeable?	Can be made immutable?
Proxy	Calls made to the proxy contract are forwarded to the implementation contract using `delegatecall`. Address of the implementation contract is immutable in the proxy. This is the basis for just about all proxy types with the exception of Metamorphic. One example of this proxy type is EIP1167 Minimal Proxy Clones. An improvement over Minimal Proxy Clones is Clones with Immutables	Simple	Costs gas to do the delegate call		Shims to avoid deploying many of the same contract and can deploy new shims that point to an existing contract. When there’s a 1-1 relationship between proxy and impl contracts.	delegatecall in implementation or selfdestruct in implementation	No	Yes, by design.
Upgradeable Proxy	Similar to proxy except the address of the impl contract is kept in storage in the proxy. Permissioned upgrade logic is also located in the proxy.	Simple.	Extra care is required for the upgrade logic (access control) as it resides in the implementation contract. Costs gas to do the delegate call, Vulnerable to function collisions	Storage collisions can be avoided by EIP1967, admin != caller	Not widely used anymore. There are better patterns.	Function collision with proxy, storage collision, delegatecall in implementation, or selfdestruct in implementation	Yes	Yes, by admin revoking ownership of the proxy.
Transparent Proxy (TPP)	Similar to Upgradeable proxy for non-admin callers, but when the admin calls the proxy the proxy’s functions are used	Comparatively easy and simpler to implement; widely used	Waste gas on delegatecall and checking storage to see if caller is admin	Storage collisions can be avoided by EIP1967 , admin != caller, using a UUPS compliant implementation with a TransparentUpgradeableProxy might allow non-admins to perform upgrade operations	Still used for its simplicity especially when there is a 1:1 relationship between the proxy and impl contracts.	function collision with proxy, delegatecall in implementation, or selfdestruct in implementation, storage slot collision with proxy, uninitialize proxies, gas guzzler	Yes	Yes, by admin revoking ownership of the proxy.
Universal Upgradeable Proxy Standard (UUPS) - EIP1822	Similar to Transparent proxy except the `upgrade` logic is stored in the implementation contract so there is no need to check if the caller is admin in the proxy (saving gas). UUPS proxies also contain a check to ensure the new impl contract is also upgradeable.	More gas efficient. Reduces function conflicts w proxy since upgrade fns are in impl.	Still have overhead of delegate call	Storage collisions can be avoided by EIP1967 , admin != caller	For a more gas efficient proxy and when there are many different proxy contracts pointing to the same implementation.	delegatecall in implementation, or selfdestruct in implementation, uninitialized proxy	Yes	Yes by admin revoking ownership or by upgrading to an impl contract that does not contain impl logic.
Beacon Proxy (aka Dharma Beacon Proxy)	Instead of storing the impl contract address the proxy stores the address of a beacon. The beacon contract stores the address of the implementation contract.	Can upgrade many different proxies pointing to the beacon.	Gas overhead of calling Beacon contract and getting the impl contract address from storage, as well as the delegate call	Storage collisions can be avoided by EIP1967, admin != caller	When more control is desired with more complex systems of upgradeability. Sets of proxies can point to one beacon while other types can point to a different beacon.	delegatecall in implementation, or selfdestruct in implementation, uninitialized proxy	Yes	Technically yes, but if the goal was immutability then choose a different type.
Upgradeable Beacon Proxy	Same as Dharma Beacon proxy except the Beacon address is settable in the proxy.	Even the Beacon contract can be upgraded.	Complex. Gas guzzler.	Storage collisions can be avoided by EIP1967 , admin != caller	Even more complex patterns can be used when the beacon address is also upgradable.	delegatecall in implementation, or selfdestruct in implementation, uninitialized proxy	Yes	Technically yes, but if the goal was immutability then choose a different type.
Storageless Upgradeable Beacon Proxy	The Beacon contract stores the implementation contract in the code instead of in storage, saving gas. https://forum.openzeppelin.com/t/a-more-gas-efficient-upgradeable-proxy-by-not-using-storage/4111	More gas efficient than TPP, UUPS, Dharma Beacon	Complexity. Little to no adoption.	The upgrade process involves self-destructing the beacon so there is a 1 block down time for the beacon. As such a backup beacon is utilized.	This is more of an experiment and there are no known implementations of this in the wild.	delegatecall in implementation, or selfdestruct in implementation, uninitialized proxy	Yes	Technically yes, but if the goal was immutability then choose a different type.
Diamond Proxy	An upgradeable proxy pattern in which there are multiple logic contracts (instead of just one) called facets. Additionally, this pattern uses a separate contract for storage.	Can create powerful, modular combinations. Helps to battle the 24KB size limit via modularity; incremental upgradeability	Complexity. Slow adoption.	More complex to implement and maintain; uses new terminologies that can be harder for newcomers to understand; as of this writing, not supported by tools like Etherscan	When you need the control and flexibility offered by having multiple logic contracts or separate storage.	delegatecall in implementation, or selfdestruct in implementation, uninitialized proxy	Yes	Yes
Metamorphic Contract	A contract that is deployed with CREATE2 and in the constructor, it retrieves the address for the contract code from the storage of an external registry contract. To upgrade, the contract is selfdestructed.	No delegatecall so this is the most gas efficient.	Complex, little adoption in the wild.	The selfdestruct opcode may be removed in the future.	Optimizooors, those who like living on the edge.	?	Yes	Yes, by removing self destruct from the upgrade.