# Check the contrack MetaMask snap

## System overview

The system consist of the server and Metamask Snap.
The Snap checks if the contract was audited/exploited and gives information about few other params. This allows users to review more information and determine if it is safe to interact with the contract.


### Server
The server is responsible for pushing data about the contracts to Arweave (decentralized permanent storage technology).
One of the key idea is to show users if the contract was audited or not and which company did the audit, but most of the audit reports do not have the address of the deployed contracts (most likely links to the repo, sometimes even private), also there is no universal tool which allows to get/scrape audits data from different companies, only few of them provide API.
This requires us to input data by hand or by the limited scrapers, which is not only a boring routine thing, but also leads to the redundant centralization around the input controller entity.

The structure of the data which is stored to Arweave in a JSON format

{
    auditDate: number, // UNIX time
    auditingCompany: string,
    status: enum {exploited, audited, fraudulent},
    link: string,
    chainId: number,
}

The purpose of the majority of fields is clear, the `link` field is the link to the audit report and the contract address is stored in the metadata of the Arweave transaction, which plays a role of the key, to retrieve the data.

### MetaMask snap

The snap itself makes a request to one of the Arweave endpoints, for example `https://arweave.net/graphql` and sorts the relevant data according to the date and time. Here is the GraphQL request structure:

transactions(
    owners:[WALLET_ADDRESS],
    tags: [
        {
            name: "App-Name", 
            values: ["APPLICATION_NAME"]
        }, {
            name: "Contract-Address",
            values: ["ADDRESS_OF_THE_CONTRACT"]
        }
    ]
) {
    edges {
        node {
            id
        }
    }
}]

The information form the Arweave storage is displayed on the Span tab before confirming the transaction.

Moreover, the contract is checked for upgradability, as the ability to update the functionality of the audited contract can potentially pose a security risk. The upgradability detection is not 100% reliable because the script only detects the signatures of the common function names responsible for upgradability.

## Next steps
It would be nice if auditing companies provide any kind of public API with the list of audits, this would pave the way for upgrading the current concept to a more decentralized solution that relies on oracles.

Here are the few next steps:
- write automated oracle based scrapers which automates pushing audit data to Arweave and keeps the system relatively decentralized.
- improve detection of the contracts upgradability.
- integrate code analizing solution and AI based vulnerability anilizer in the future.