template.md

protocol	name of the protocol appended by the version if multiple versions exist (use an '-' and no whitespace)
website	https://...
x	https://x.com/projecthandle
github	https://github.com/projectgithub
defillama_slug	the slug used by https://defillama.com
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.

Overview

Chain

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

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/learn-more#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)

For some guidance:

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

This steps help you write 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)

Autonomy

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

Exit Window

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

Accessibility

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

Technical Analysis

Contracts

Contract Name	Address
contract 1	0x123
contract 2	0x456

Permission owners

Name	Account	Type
name	address	Multisig x/y

Permissions

Contract	Function	Impact	Owner
contract name	functionname	description	owner of the permission

Dependencies

insert text

Exit Window

insert text

Security Council

See http://defiscan.info/learn-more#security-council-requirements for guidance.

change ✅ or ❌ accordingly

✅ /❌	Requirement
❌	At least 7 signers
❌	At least 51% threshold
❌	At least 50% non-team signers
❌	Signers are publicly announced (with name or pseudonym)