DAO MSIG Intervention Policy

Based on a DAO proposal (link) and vote (link)


The prerequisites for whitelisting a token on Bancor are in place to prevent attempted exploits of the Bancor protection mechanism. However, hacks and exploits, and coordinated exits (“rug-pulls”) affecting a token that has passed the vetting process can still become a threat to the system.

This proposal provides a detailed policy whereby the BancorDAO can intervene in the operation of affected pools, immediately after a token has become compromised.

The scope of the interventions available to the DAO authority are:

  1. Adding liquidity is disabled on the affected pool.

  2. Swaps are disabled on the affected pool.

  3. The DAO isn’t allowed to intervene with the withdrawal of funds, save for the adjustments to the protection mechanism.

The actions of the operations multi-sig signers must then be ratified with a DAO vote. The signers must provide a short report that describes the motivation behind any actions taken, and publish it to Discourse 1 in a timely manner. The DAO will then vote to uphold or reverse the decision via the normal process.

This format allows for action to be taken to protect the protocol in time-sensitive situations. The requirement for retroactive community approval preserves the integrity and authority of the BancorDAO

Some Threats Cannot be Anticipated on Long Time Horizons

The prerequisites for whitelisting a token on Bancor provide a helpful filter against predictable security risks. A reasonable scope of common abuse vectors are covered that provide a high level of protection from deliberate exploit attempts, hacks, and other nefarious behavior that could allow an antagonist to siphon value from the network. However, an element of risk will always persist, where events elsewhere in the Defi ecosystem can affect the health of a pool, regardless of the community’s diligence during whitelisting.

There are an infinite number of possible scenarios where a fully-audited, vetted and community-approved token for a respectable and trustworthy project can turn malignant. For example, a large reservoir of the token could be drained from another protocol, AMM or otherwise, which could then be used to perform a very large trade on Bancor. In such a scenario, neither the token’s ERC20 contract nor the team that created it are at fault, and anticipating these types of attack vectors for all tokens on our network is simply untenable.

DAO Bureaucracy is Effective, but Slow

The BancorDAO has demonstrated an exceptional ability to govern. Processes have been created that ensure a high level of engagement and community awareness, albeit at a significant time cost. The time interval between the appearance of a well-considered and polished proposal on Discourse, and executing the relevant actions following a successful DAO vote is simply too long to be a tenable route to intercepting an apparent threat, after it is discovered. Moreover, the fact that such a proposal exists serves to advertise the exploit opportunity, heightening the risk that an antagonist might act on it. In short, the existing channels for the DAO to exercise its powers are rendered impotent in the face of an oncoming and imminent attack, or an exploit in an external contract that can damage the protocol unintentionally.

Retroactive, Time-Sensitive Decisions

Some threats can be anticipated, and presents a short window of time wherein the DAO multi-sig signers can act, thus eliminating or reducing damage to the Bancor Network. With the acceptance of this proposal, the DAO is agreeing to allow the mult-sig signers to act appropriately when a perceived, avoidable risk becomes known. The actions that the mult-sig authority may take prior to a formal DAO vote are strictly limited. To prevent theft, or another problem arising from a known issue affecting certain tokens, the DAO will allow the multi-sig authority to temporarily cease swaps and liquidity provision to affected pools, as required. These actions need not be executed together; depending on the nature of the perceived threat, it may only be necessary to exercise only one of these options rather than all of them. Importantly, user withdrawals must not be inhibited.

Ratification of Actions Taken

After the multi-sig signers have interrupted the functioning of a pool, a written report must be made available that clearly describes the rationale for the actions taken, and provide sufficient evidence for DAO members to consider whether the action was warranted. This is unlikely to be controversial. Thereafter, the report will be incorporated into a formal DAO proposal, and the actions of the mult-sig signers will be ratified via the voting process. This is especially important if the measures taken to protect the protocol are expected to persist indefinitely.

False Alarms and Reactivation

If due to a misunderstanding, or misinterpretation of the perceived threat, or it being nullified in a timely manner, the MSIG signers may reverse the actions taken to restore proper functioning of the pool, prior to a DAO vote. Under these circumstances, a written report must be made available, regardless of the decision reversal. The report should detail precisely why action was taken, and reasoning for its reversal. In these cases, the report should be published to the governance Discourse pages, under the Community Chatroom category (as the report is not a draft proposal, and will not result in a vote).

Last updated