Benefits of a Trust Model

Documenting your security and trust model assumptions:

• Help you understand how things could go wrong even if your contracts are bug-free; this allows you to identify mitigation measures even before you get to the audit.
• Give auditors more insight into your thinking and may be able to tell you whether or not your assumptions are realistic. They may also be able to point out assumptions you're making that you didn't realize you were making.
• Enables auditors to align their evaluation with the project's security goals.

What to Include

Spend some time brainstorming the assumptions and accepted risks upon which your project is built; these are often things that are not completely under your project’s control. You should also briefly describe any mitigation steps you are proactively taking and the justification for any accepted risks.

• Do you have any privileged roles that are allowed to call certain functions? If so, which functions? How do you determine who is “trusted” enough to receive that role? What steps are you taking to mitigate risks presented by these roles? For example, are you using a multisig wallet? If not, why not?
• Are you relying on any external contracts? If so, what assumptions are you making about their security and reliability? Why did you decide to rely on those contracts instead of writing your own?

Examples

Trust Models don’t have to be super formal! Here’s an example of a very brief trust model:

We assume that the owner is not malicious, that the Chainlink oracles won't lie about the token price, that the Chainlink oracles will always report the price at least once every 24 hours, that all tokens that the owner approves are ERC20-compliant tokens with no transfer hooks, and that there will never be a chain reorg of more than 30 blocks".

Here’s another example that goes into a bit more detail about the trusted roles:

Trusted roles:

• Manager (ProxyManager): Handles implementation migration in the Proxy inheriting ProxyBase. This role has the power to change the manager which fetches the implementation address potentially controlling all storage and contract functionalities.
• Owner (TokenOwnable): Responsible for specific administrative responsibilities. Manages admin tasks such as channel creation, role creation, and entitlement modules.
• Diamond Owner (Ownable): Protocol-controlled address that manages the canonical diamond implementation and included facets. Owners can use this diamond implementation but they can not modify the structure and facets of this diamond.

<aside> ℹ️ It can also be useful to add your threat model here so our auditors can reference it.

</aside>