Guide/Template for SC Domain Community Assessments

Hi everyone, I’ve done a few of these Smart Contract Domain Assessments now, and I decided to write a little bit of a guide based on the template here:

Most of the information for these assessments is on etherscan and can be found from the token tracker page. That said, I have written a short blurb on the requirements for each section. Let me know if I should add any additional information.

Title: [SYMBOL] ERC20 Token Smart Contract Domain Community Assessment
tags: -symbol, -sc-domain-work

General Information
This can mostly be found through etherscan, on the token contract page. Deployment Date can be found by checking the date where the analytics graph begins. Two exceptions are the developers allotment and github page, which may take more searching online and digging. MCD collateral type adapter requires an understanding of the maker adapters:

here is the GemJoin contract for well behaving erc20s:

here are GemJoin variants for not quite well behaving erc20s:

• Symbol:
• Address
• Deployment Date:
• Total supply:
• Developers allotment:
• Project website:
• Github repository:
• Can use existing MCD collateral type adapter?

Risk Summary
For this we look at the erc20 standard here: The solidity contract code can be found by looking under “profile summary” on the etherscan token tracker page, and clicking the “contract” link. The contract tab then shows all of the solidity code. A low risk contract is one that follows erc20 or another ethereum standard. Medium and high risk contracts have extra administrative functions, don’t follow basic security protocols, or have strange functions that have questionable merit. Use your best judgment or ask someone if something looks strange.

• Does the contract implement the ERC20 token standards?
• Risk analysis: LOW/MEDIUM/HIGH

Technical Information
This is all found under the profile summary section of etherscan or within the contract code itself.

• Compiler version:
• Decimals:
• Overflow checks:
• Mitigation against allowance race-condition:
• Upgradeable contract patterns:
• Access control or restriction lists:
• Non-standard features or behaviors:

Formal Verification Considerations:
This section involves an analysis of the solidity contract

• Does transfer have simple semantics?
• Does transferFrom have simple semantics?
• Can balances be arbitrarily modified by some actor?
• Are there any external calls?

Testnet Information
Requires some digging online, and is likely the most difficult portion of this asessment to discover. It is possible a token will not have testnet information, especially if it is a custodial token for a RWA.

• <Add any relevant testnet information here>

Contract Logic Summary

<Add written summary of smart contract logic here, does the contract use a multi-sig, 1-2 paragraphs>

• How the contract is upgraded
• Administrative addresses (EOAs, controller contracts, and similar)

Contract Risk Summary

<Add written summary of smart contract risk here, 1-2 paragraphs>

Supporting Materials

A common tool used for this section is particularly the mdreport function
<Add supporting materials, documentation, and graphs here>