Protocol Security

Incident Identification

The Protocol monitors risk on (i) the smart contract level and (ii) the infrastructure and UI level. On the smart contract level, Term Finance utilizes OpenZeppelin Defender Contract Sentinels to monitor any calls to access controlled functions. On the infrastructure and UI level, measures are established to prevent against DDOS attacks, implement DNS security, and detect unwanted front-end modification and intrusion. For more details follow the page links below.

Smart Contract MonitoringFront-End Security

Incident Reporting

Alerts are sent to all members of the team in real-time, though a rotating schedule is in place to designate a single member of the core team as being responsible for monitoring and escalating alerts to an incident report board each day of the week. Incidents added to the board move through the following steps:

• Discovered

• Triage Needed

• Planned

• Diagnosing

• Fixing

Isolate and Contain

Once identified, emphasis is placed on isolating and containing an incident from spreading or causing further damage to the Protocol. Responses for common situations described in the table below.

Type	Response
SC - Unauthorized deployments	To isolate and contain an unauthorized or malicious deployment, the Protocol can (i) pause further deployments through the Term Initializer and (ii) delist the contracts.
SC - Exploits	Depending on the nature of a hypothetical smart contract exploit, containment will be narrowly tailored to the minimum restrictions necessary to isolate the exploit without unnecessarily prohibiting users from exiting the Protocol. To this end, in some cases it may be sufficient to pause a subset of public functions, in other it may be necessary to pause all public functions.
Web 2.0 infra / front-end	While containment will vary on a case-by-case basis, the procedure will be to isolate affected systems or networks to prevent further damage to the extent there are interconnections before diagnosing and eliminating root cause.

Resolve and/or Restore

Once contained, emphasis turns toward resolving and restoring systems. Resolutions for common situations are detailed in the table below.

Type	Response
SC - Unauthorized deployments	To the extent the cause of unauthorized deployments is due to a compromised access control wallet, roles can be re-assigned using the DEVOPS_ROLE multisig.
SC - Exploits	In certain circumstances, it may be necessary to authorize upgrades to resolve the exploit. In others, it may be sufficient to simply redeploy the entire protocol. Given the finite nature of Term Finance contracts, the impact of redeployments is limited.
SC - Compromised access controls	To the extent any of the access control wallets (other than the DEVOPS_ROLE wallet ) are compromised, it is possible to re-assign roles using the DEVOPS_ROLE multisig. To the extent unauthorized transactions are proposed to the DEVOPS_ROLE multisig, the Zodiac Role Modifier can invalidate any pending transactions during the 24-hour timelock imposed on all DEVOPS_ROLE transactions.
Web 2.0 infra / front-end	The front-end is deployed using Github Pipelines and stored in Amazon S3 buckets with version histories. Once contained and isolated, UI can be quickly restored to a previous version.

Documentation

Lastly, once an incident is contained and resolved, the Protocol will seek to document all actions taken during the incident response process, including timestamps and individuals involved.