# OpenZeppelin usage in audited, well-known projects **URL:** \ **Category:** SDK\ **Created:** [March 30, 2020, 3:26pm UTC](https://forum.openzeppelin.com/t/openzeppelin-usage-in-audited-well-known-projects/2556 "2020-03-30T15:26:57Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![spalladino](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/spalladino/32/22_2.png) [@spalladino](https://forum.openzeppelin.com/u/spalladino)\ **Post date:** [March 31, 2020, 8:46pm UTC](https://forum.openzeppelin.com/t/openzeppelin-usage-in-audited-well-known-projects/2556/8 "2020-03-31T20:46:54Z")
> [@miohtama](#): > > - Do you know any well-known and audited open source projects out there using the Zeppelin Proxy pattern? > - Have there been any recently released tokens with Zeppelin token code and audits? Among the first projects that launched using our proxy patterns, I can recall **CENTRE** ([USDC](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48)), which is an ERC20 that is currently holding almost 700M USD (proxy code [here](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code)). Another coin [using our proxies](https://github.com/paxosglobal/pax-contracts#upgradeability-proxy) is **Paxos** (token [here](https://etherscan.io/token/0x8e870d67f660d95d5be530380d0ec0bd388289e1)), for a value of about 250M USD, and they were [audited by three different firms](https://github.com/paxosglobal/pax-contracts#abi-address-and-verification), Trail of Bits among them! **Decentraland** has also used our upgrade patterns for the marketplace and districts, which were audited [here](https://medium.com/nomic-labs-blog/decentraland-audit-report-a7465c8eb14c). More recently, **PoolTogether** also uses our [upgrade patterns](https://etherscan.io/address/0xb7896fce748396ecfc240f5a0d3cc92ca42d7d84#code), and was [audited](https://www.pooltogether.com/audits) both by us and Quantstamp. I understand that **AZTEC** [also uses our proxies](https://github.com/AztecProtocol/AZTEC/blob/cb78ba3ee32ad82234ac0fbed046333eb7f233cf/packages/protocol/contracts/AccountRegistry/AccountRegistryManager.sol#L62-L66), same as [**Unlock Protocol**](https://github.com/unlock-protocol/unlock/blob/5d3ed7519e3fe3c75ef7220468d7a8ae716db194/smart-contracts/contracts/Unlock.sol#L30), and [**SablierHQ**](https://github.com/sablierhq/sablier/blob/develop/packages/payroll/contracts/Payroll.sol#L6). I'm sure I'm missing other high profile projects, but these are the ones that come to mind now. Also, as Andy pointed out, the proxies themselves have been [audited by Nomic Labs](https://medium.com/nomic-labs-blog/zeppelinos-smart-contracts-audit-iv-a52987973b88). * * * Now, as Dan mentions, upgrades do introduce an additional complexity, but from what we've seen in most cases the benefits definitely surpass the hassles. Also, any "manipulaton of low-level Solidity" (I'm assuming Dan refers to assembly here) is isolated in the proxies themselves, and has been **very** carefully reviewed and audited, as well as widely used in production. We have rolled out patterns such as [unstructured storage](https://docs.openzeppelin.com/upgrades/2.7/proxies#unstructured-storage-proxies) or [transparent proxies](https://blog.openzeppelin.com/the-transparent-proxy-pattern/) to ensure that it's extremely difficult to shoot yourself in the foot, unless you explicitly try to do so. And if you are using [our CLI](https://docs.openzeppelin.com/cli/2.8/), we have embedded all [necessary checks](https://docs.openzeppelin.com/upgrades/2.7/writing-upgradeable) to make sure that an upgrade is safe - though we always strongly encourage to [test them](https://blog.openzeppelin.com/testing-real-world-contract-upgrades/). FWIW, I'm not a fan of the data separation pattern for upgrades. It produces very awkward code, it makes it impossible to reuse existing libraries, it's extremely easy to screw up just by forgetting an `onlyOwner` modifier in any of the functions in the storage contract, and is much more expensive in terms of gas as it requires an additional CALL for every read or write operation. Last, I'm sad to see that the Trail of Bits post is still promoting FUD on our proxies, by touting an alleged vulnerability found on our implementation. The fact is that the post picks on an unreleased implementation of the proxies which was under development in our [labs repository](https://github.com/OpenZeppelin/openzeppelin-labs) (a space dedicated to exchange ideas), and was not present in the released version. And not to mention that, if this had been an actual vulnerability, we would have appreciated a responsible disclosure privately first, instead of finding out via a public post. --- _[View the full topic](https://forum.openzeppelin.com/t/openzeppelin-usage-in-audited-well-known-projects/2556)._