Please describe your proposed solution
Source Code and Blueprints
Administrators will be able to upload the source code and JSON Blueprint files of a contract (https://cips.cardano.org/cips/cip57/) along with its corresponding hash on our website. The platform will verify that compiling that source code generates the specified hash.
Initially, we will accept source code in Haskell, but we intend to incorporate all available contract writing forms. To achieve this, we will implement a compilation process for each of these forms and obtain the resulting hash, which will then be compared to the initially provided hash.
Ideally, the submitted source code should include comments and documentation so that the average user can understand and comprehend what the contracts they are interacting with do.
Searching Scripts
Users will search for a hash and obtain information and details of the contract. The platform will display contract definitions, source code, explanations, comments, and various ratings left by users who have analyzed the code.
Analysis by Creators and Third Parties
Users will be able to perform analysis, leave comments, and provide ratings for each contract. Both the creator and other users can analyze the code and leave their insights, and these analyses can be rated and ranked.
Some possible ratings for the contract could be: secure, clear, controversial, unreadable, insecure, etc.
A reputation system could be implemented to reward users for their participation and valuable contributions.
The goal is to have these analyses written in terms understandable to an average person, explaining what the contract does in general, its datums and redeemers, under what valid conditions it operates, and under what conditions it fails.
Minting Policies and NFTs
In the case of minting policies, we will provide additional information about the tokens being generated, such as whether they are FTs or NFTs, if there are wallet restrictions for generating them, if there are temporal limitations and other relevant aspects.
This information is particularly valuable for studying NFTs. Some NFTs hold high economic value, often costing hundreds or thousands of dollars, and many users cannot determine with certainty whether what they are purchasing is truly an NFT or simply resembles one.
For a token to be considered an NFT, the minting policy must meet certain conditions to prevent duplication. There are various ways to achieve this, including utilizing temporal conditions that can be highly useful. However, the most established condition for defining such policies is to use a UTXO as a parameter of the policy and ensure that this UTXO is being consumed, indicating that the policy will only validate once. This is one of the necessary conditions for creating NFTs. Therefore, we can analyze the scripts and their source code to identify which policies fulfill this condition and provide this information to users.
REST API
We will be implementing an API to query token information based on minting policies. This API will provide details about the token, such as whether it is an NFT or an FT, reuse restrictions of the policy, specific wallet restrictions, temporal limitations and the maximum supply defined in the policy, among other relevant aspects.
Different wallet services will be able to access this information through our API and clearly display to users whether a token is considered an NFT or not. Additionally, network explorers can also utilize our API to provide this information to users.
In addition, we will also introduce the capability to query contract information through APIs. This feature will provide basic information about a contract, as well as reviews and ratings associated with it.
The REST API will provide a user-friendly interface for developers and service providers to access our data programmatically. They can query specific policies or smart contracts, retrieve token attributes, and integrate this information into their applications or platforms.