Skip to content

<chain>.md

Latest commit

 

History

History
126 lines (80 loc) · 5.45 KB

<chain>.md

File metadata and controls

126 lines (80 loc) · 5.45 KB
Raw
chain the name of the chain on which the protocol is deployed
stage 0
reasons
remove
if none
risks
x
x
x
x
x
author
author-1
author-2
submission_date 1970-01-01
publish_date 1970-01-01
update_date 1970-01-01

Summary

Add a summary of the protocols. What is it? What does it do? etc.

Ratings

Chain

See http://defiscan.info/framework#chain for more guidance.

Chain score: Low/Medium/High

Upgradeability

In the upgradability section & risk we address bytecode upgrades and parameter changes that are permissioned.

We wrote a section explaining the Upgradeability Risk in our framework here: See http://defiscan.info/framework#upgradability

For some practical guidance follow this steps. It will help you in writing a nice report:

  1. Run the permission scanner
  2. Fill in all the permissioned functions in the table (## Permissions)
    • Remember: Each function with a permission needs to be considered when determining the risk on Upgradability
  3. Get a mechanistic and precise understanding of each permissioned function
  4. Assess impact for each function, look out for
    • loss/blocking of user funds
    • loss of unclaimed yield
    • change expected behavior significantly (blacklisting/kyc/fees/...)
  5. Write the impact column based on your understanding
    • A good tipp when writing the impact column below, think of least 2,3 sentences:
    1. First sentence: what it does technically, e.g "It assigns a new address to the owner variable"
    2. Second: what is the impact within the system, e.g "The owner is permissioned to raise fees"
    3. Third: Imagine faulty or malicious action, e.g "The malicious owner could raise fees to 100%, redirecting all future yield.
  6. Summarise and abstract away technical details in this section here (## Upgradeability)

Upgradeability score: Low/Medium/High

Autonomy

See http://defiscan.info/framework#autonomy for more guidance.

Autonomy score: Low/Medium/High

Exit Window

See http://defiscan.info/framework#exit-window for more guidance.

Exit Window score: Low/Medium/High

Accessibility

See http://defiscan.info/framework#accessibility for more guidance.

Accessibility score: Low/Medium/High

Conclusion

Some text in form of:

The xyz protocol achieves High centralization risk scores for its Upgradeability, Autonomy and Exit Window dimensions. It thus ranks Stage 0.

The protocol could reach Stage 1 by ...

The project additionally could advance to Stage 2 if ...

Reviewer's Notes

(Here, anything worth mentioning about what critical permissions you excluded from the scope or some elements that xyz protocol does in a unique way. If nothing seems relevant, just say that :)

⚠️ During our analysis, we identified ...

Protocol Analysis

Here include the diagram. Please explain what the main contracts are doing within the diagram.

Dependencies

Go into more detail of the oracle, bridge, or other dependency the defi protocol is using

Governance

Relevant Subsection

Here anything relevant to the governance, in this case it could be what you highlighted in "Upgrade Process"

Security Council

New table with all the multisigs

Name Account Type ≥ 7 signers ≥ 51% threshold ≥ 50% non-insider Signers public
Team Multisig 0x123 Multisig ✅ ❌ ❌ ✅

Contracts & Permissions

Contracts

Contract Name Address
contract 1 0x123
contract 2 0x456

All Permission Owners

Name Account Type
name 0x... Multisig x/y
name 0x... Contract
name 0x... EOA

Permissions

Contract Function Impact Owner
contract name functionname First sentence: what it does technically, e.g "It assigns a new address to the owner variable". Second sentence: what is the impact within the system, e.g "The owner is permissioned to raise fees". Third sentence: Imagine faulty or malicious action, e.g "The malicious owner could raise fees to 100%, redirecting all future yield. owner of the permission