@agruzdev.near [Posted on DevHub](https://near.social/#/devgovgigs.near/widget/Post?id=1565) ## Solution: Smart Contract Source Code Verificator with Social Features and Code Viewer ###### Requested amount: 32999 USDT ###### Requested sponsor: @neardevgov.near *Prior art:* https://near.org/devgovgigs.near/widget/gigs-board.pages.Post?id=853 After receiving feedback from Frol, we re-evaluated the security and centralization aspects of our solution. Initially, our approach prioritized user-friendliness and rapid implementation. However, a significant drawback was the centralized verification process, which might have led to scalability issues down the road. From the outset, we had a vision for how we would evolve and decentralize in the future, but our attention was directed towards different facets of the solution. Nevertheless, our solution was inherently designed to seamlessly transition to a new verification process, which I'll elaborate on below. Another concern raised by Frol was the provision of full access keys to us. We were using it since NEAR requires such keys for contract deployment. Our revised solution can be broken down into two main stages: 1. **Contract Compilation and Deployment**: The user would utilize NEAR's containerized CLI for compilation to ensure reproducibility of the wasm. As of now, this is the only method to guarantee reproducibility. Once compiled, the user would deploy the code using the same CLI without exposing his full access key to third party. 2. **Contract Verification**: The user would then access the SourceScan BOS app. Here, the user's sole responsibility would be to input the contract's address and provide the GitHub link and commit (a feature we've already implemented). The code would then be compiled within the same container. If the hash of the wasm code matches, the contract gets verified. The transaction to add a new entry, consisting of the contract address and the GitHub repo SHA, to the mapping would be signed by sourcescan.near itself. Importantly, no user keys would be needed during this second verification phase. This ensures that newly created critical contracts, known for deleting full access keys after deployment, will be verified. SourceScan will no longer require these keys in the second phase, and they won't be exposed to third parties during deployment. All old critical contracts will be added to SourceScan as exceptions since they are already locked, and we cannot reproduce their WASMs. In the end, we can automate the second stage by inserting additional metadata into the contract during compilation and deployment stage and listening to indexers for all deployment transactions. We'll identify the one verified with SourceScan. After that, a job will be initiated on the compilation server. If the wasm hash matches, the contract will be verified. As discussed, funding is parted into three month each. Whole project 6 month. ## Updated Milestones ## 0 - Proof of Concept - (June - July) - **(✓)June**: 1. (✓) First MVP developed 2. (✓) Mainnet integration - **(✓) July** 1. (✓) Acess Keys managment 2. (✓) BOS components for contracts lookup 3. (✓) Integration of multiple NEAR wallets ## 1 - BOS Integration - (August - October) - **August**: 1. (✓) Github integration for source code upload 2. (✓) BOS components for contracts compilation & deployment ## 2 - Verification v2.0 (This proposal) - (November - January) - **November** 1. First stage implemented 2. Nearblocks integration (? - waiting for their BOS components) - December 1. Second stage implemented - January 1. Contract social features (upon workload could be carried to next proposal) 1. votes 2. bio 3. comments 4. followers 2. Trustworthiness level 3. Code viewer ## 3 - Indexers automation (Next half proposal) - (February - April)