Writing a threat model encourages a proactive approach to security, enabling engineers to design their contracts with potential risks in mind from the very beginning. This ultimately leads to more resilient and secure smart contracts, minimizing the chances of successful attacks and enhancing the overall trustworthiness of the project.

The threat model should:

1. Identify potential known attack vectors or assumed risks. E.g. sybil attack or centralization risks.
2. Communicate the weight the protocol gives to different exploits or edge cases. This helps us accurately categorize issues: what may be an existential threat for one protocol may be a slight inconvenience for another.
3. Call out areas where there are specific security concerns.

Here are some examples for things you may want to think about when creating a threat model:

1. Identify a list of
   1. Value transfers (e.g. deposit, withdrawal etc.)
   2. states that the transfer depends on (e.g. account ownership)
2. Answer the following questions for each value transfer, articulating your reasoning in a few sentences. Referencing code or external sources can help solidify your reasoning.
   • How does value enter and leave the system?
   • What access controls (e.g. account owner only) are there for the entries and exits?
   • What access controls are there for functions that update the relevant states?

As you walk backward from each value transfer and carefully examine the existing protections (or lack of), you might see openings that shouldn’t be there!