# Smart Contract Security

The Mezzanine team has created smart contracts with the philosophy that writing bug-free code is impossible. Instead, Mezzanine's smart contracts were designed to be patchable given a route for exploitation is discovered. &#x20;

The vast majority of the smart contracts that make up a Mezzanine company are deployed with *upgradeable* proxies.  These proxies must follow strict logic for their implementations to be changed and cannot upgrade to an implementation that was not chosen by the Mezzanine team.  This upgradeability enables Mezzanine to patch any vulnerable smart contracts, impeding the exploitation of companies. &#x20;

All of Mezzanine's smart contracts will be sufficiently audited before being put into production and a proactive security monitoring system will be put into place. &#x20;

### Protocol State

All of Mezzanine's smart contracts are also aware of the *protocol state*, which can be three different settings: *Active, Paused,* and *Frozen.*

All of Mezzanine's functionality will be enabled if the protocol is *active*.  Conversely, if the protocol is *frozen*, the vast majority of Mezzanine's functionality will be disabled, thereby preventing companies from being exploited.

*Paused* is an in-between between *Active* and *Frozen* states, disabling some functionality while keeping some enabled.  As a rule of thumb, functionality that lets users *enter the protocol* will be disabled when the protocol is paused while functionality that lets users *exit the protocol* will be enabled.  For example, *hiring* an employee will be disabled if the protocol is frozen while *terminating* an employee would be enabled. This state is desired if there is specifically a bug found with code that enables users to enter the protocol but not with code that lets users exit the protocol. &#x20;

Contracts can be upgraded to patched versions that fix any route for exploitation in the paused or frozen protocol states. &#x20;

### Freezing Implementations and Deployments

The Mezzanine team can freeze specific implementations, which would subsequently be patched.  For example, if a bug is found in Mezzanine's payroll manager, the specific implementation can be frozen such that all of Mezzanine's other functionality is maintained.  The team would then unfreeze this implementation once each company's implementations have been patched. &#x20;

The Mezzanine team can also freeze specific company deployments.  For example, the team can freeze the payroll of company *Foo* while keeping the payroll of company *Bar* enabled.  This functionality may be desired if it is found that the signers of a specific company are compromised or the company is found to be malicious.

### Canceling Proposals and Pending Actions

Certain actions for Mezzanine companies require a time delay, such as a governance proposal or a pending action in payroll.  These actions can be canceled by certain parties, such as the proposer of the governance proposal.  In addition, the Mezzanine team can cancel any proposals it views as potentially malicious.  Once canceled, contact will be made with the team.  The proposal or pending action can then be re-proposed if found non-malicious. &#x20;

### Defenders

A set of accounts known as *Defenders* will be responsible for maintaining protocol security in addition to the Mezzanine team.  Defenders can:

* Freeze the protocol for up to 14 days
* Freeze deployments, which in turn would freeze the functionality of a specified Mezzanine company
* Cancel proposals and pending actions of any Mezzanine company

Defenders will be well-known parties with extensive security knowledge, such as smart contract auditing firms. &#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.mezzanine.xyz/smart-contracts/smart-contract-security.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
