# Smart contract sanctuary for Starknet **URL:** \ **Category:** đź“ś Development Proposals\ **Tags:** tooling\ **Created:** [June 29, 2023, 7:04am UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690 "2023-06-29T07:04:53Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\ **Post date:** [June 29, 2023, 7:04am UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690/1 "2023-06-29T07:04:53Z")
_(Initially suggested by @frangio)_ # What This is a proposal to build a [smart contract sanctuary](https://github.com/tintinweb/smart-contract-sanctuary): an index of verified smart contracts written in Cairo. # Why An archive of Cairo smart contract code would be a major aid for the design, development, and decision making of a variety of ecosystem actors such as: app developers, SNIP designers, infrastructure developers, RPC-endpoint developers, node/sequencer developers, wallet developers, security researchers, and the list goes on and on. Just to give two recent examples I stumbled upon this very week myself: 1. Discussing the [Standard Account Interface](https://community.starknet.io/t/snip-starknet-standard-account/95665) with account implementers such as Argent and Braavos, we started considering changing the return value of `is_valid_signature` from `bool` to `felt252`. Although I’m not going to reproduce the discussion in here, the point is that we had no information on whether such a change would break existing, deployed smart contracts or if it was safe to make such change. A smart contract sanctuary wouldn’t have been final, but it would have greatly informed our discussion. 2. Similarly, while working on the [`ERC165` → `SRC5` migration](https://github.com/OpenZeppelin/cairo-contracts/pull/637) we started wondering [whether it was required for us to release a backwards compatible implementation of `ERC721`](https://github.com/OpenZeppelin/cairo-contracts/discussions/640) that worked with both introspection mechanisms or if it would have been a worthless effort and it was safe to drop ERC165 altogether gaining development speed, simplicity in the codebase, and reduced execution costs. A smart contract sanctuary would have suggested whether there was any or several `ERC721Receiver` contracts deployed on the network. These are just two examples, but the real world use cases are infinite. Just to give one more: 1. Several times at [OpenZeppelin](https://openzeppelin.com/), after finding or being notified about a critical vulnerability in a contract or module, we’ve found ourselves in the difficult yet critical task of identifying vulnerable contracts to estimate the potential impact and lay out a mitigation plan for each affected contract. Then we faced another challenge which is to notify developers, but that’s out of this proposal’s scope. # How The best case scenario would be for RPC endpoint providers, node runners, and block explorers to cooperate to collect as much verified source code (maybe also Sierra code?) as possible into a single, well structured, repository. We should draw inspiration (if not directly contribute to) [@tintinweb](https://github.com/tintinweb)’s [repository](https://github.com/tintinweb/smart-contract-sanctuary), or create a new dedicated one. The sooner we build this, the better for the sake of completeness and convenience. # Conclusion Having a smart contract code database provides tremendous value to developers, researchers, companies, individuals, and ultimately the entire ecosystem. Let’s buidl one. ---
**Author:** ![mkaput](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/mkaput/32/73385_2.png) [@mkaput](https://community.starknet.io/u/mkaput)\ **Post date:** [June 29, 2023, 9:12am UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690/2 "2023-06-29T09:12:17Z")
As part of Scarb we are planning to eventually create an official Cairo/Starknet package registry. It looks like such a sanctuary could naturally be part of this registry. Do I understand correctly? ---
**Author:** ![remi.stark](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/remi.stark/32/2680_2.png) [@remi.stark](https://community.starknet.io/u/remi.stark)\ **Post date:** [June 29, 2023, 10:03am UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690/3 "2023-06-29T10:03:53Z")
I understand your idea. It could indeed be useful to analyze what has already been deployed on the network, especially in a development phase where there are many things happening regarding contract development. However, I wonder what you have in mind for managing updates and the “replace\_class” syscall. ---
**Author:** ![MempoolSurfer](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/mempoolsurfer/32/2955_2.png) [@MempoolSurfer](https://community.starknet.io/u/MempoolSurfer)\ **Post date:** [June 29, 2023, 12:08pm UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690/4 "2023-06-29T12:08:48Z")
I think the Voyager team would be super keen to dump the contracts they’ve collected so far ---
**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\ **Post date:** [June 29, 2023, 3:00pm UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690/5 "2023-06-29T15:00:17Z")
> [@remi.stark](#): > > However, I wonder what you have in mind for managing updates and the “replace\_class” syscall Not sure much needs to be done. Contract code is associated with class hashes and that’s all we need to map. Then block explorers already offer a mapping between class hashes and deployed contracts (see: [1](https://starkscan.co/class/0x025ec026985a3bf9d0cc1fe17326b245dfdc3ff89b8fde106542a3ea56c5a918#contracts), [2](https://voyager.online/class/0x025ec026985a3bf9d0cc1fe17326b245dfdc3ff89b8fde106542a3ea56c5a918#contracts)). ---
**Author:** ![frangio](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/frangio/32/73390_2.png) [@frangio](https://community.starknet.io/u/frangio)\ **Post date:** [June 30, 2023, 1:04am UTC](https://community.starknet.io/t/smart-contract-sanctuary-for-starknet/95690/6 "2023-06-30T01:04:03Z")
> [@remi.stark](#): > > However, I wonder what you have in mind for managing updates and the “replace\_class” syscall. An approach could be to structure the sanctuary files around class hashes, and to have a file in the sanctuary that maps contract addresses to class hash. One downside to this structure is that it will be harder to query how many contracts are using a particular Cairo pattern. Not impossible, just more work.