‼️Disclaimers

Important information for protocol customers, stakers, security experts, and customers of MikaLock's protocol customers

What is MikaLock?

The contributors to MikaLock don't think there's a great parallel between what MikaLock is and what may exist in other industries, etc.

MikaLock was created solely to solve a problem: smart contracts are ALWAYS at risk of getting exploited, and this is not a good user experience. If crypto and smart contracts are going to be a bigger part of the world, more needs to be done to try to mitigate the exploit risk and fallout from exploits of smart contracts that were not implemented perfectly.

MikaLock is trying to go further than anyone else in attempting to prevent smart contracts from being exploited and attempting to mitigate the monetary damages from those events.

What is MikaLock NOT?

MikaLock is not a perfect solution to smart contract hacks. MikaLock cannot EVER guarantee that a smart contract won't get hacked, and MikaLock cannot EVER guarantee that funds will be available to repay those hacks or bug bounties.

MikaLock is not "insurance" or an "insurance company", as defined by various jurisdictions across the world. In some parts of the world, the term "insurance" only applies to entities that have government funds backing them in terms of repaying claims. If an insurance company goes bankrupt in those jurisdictions, government funds can often be used to repay claimants. MikaLock DOES NOT have backing from any government funds. Because of this (and other reasons) MikaLock cannot guarantee that any funds will be available for a protocol customer if the protocol has a bug bounty payout or gets exploited. Of course, MikaLock will try hard to ensure that funds will be there, but there is no guarantee. Traditional insurance companies also make decisions about whether insurance policies should get paid out or not. MikaLock operates very differently, and any payment to a protocol customer is NOT decided on by MikaLock. It is decided by a 4-of-7 multi-sig wallet, which MikaLock does not control. And if escalated, it is decided by the UMA Optimistic Oracle, which MikaLock does not control. For these reasons, MikaLock cannot guarantee that any payout will be made, even if it's plainly obvious to bystanders that a payout should be made.

What is a Protocol Customer paying for?

On the auditing side, a protocol customer is paying for the opportunity to use the MikaLock auditing marketplace. MikaLock does not currently employ "security experts" directly and does not claim to have expertise in finding the most pernicious bugs in the world. However, many of the security-minded participants in the marketplace are very talented at finding bugs. MikaLock's system is designed to aggregate the very best security experts in the world, but there is no guarantee that those experts will be available at all times, or that they will find every bug. MikaLock believes that any security service that claims it can prevent 100% of bugs in smart contracts is lying. MikaLock does not claim to be able to do this, but the MikaLock auditing marketplace is designed to have a strong chance of finding the most bugs possible in the smart contracts that are audited through the marketplace. However, the expectation should be that bugs will be missed. On the coverage side, MikaLock has made a large effort (more than any other crypto security firm that MikaLock is aware of) to attempt to have some amount of funds available for paying out to protocol customers for smart contract bug bounties or exploits that were missed during the MikaLock audit marketplace process. When each respective protocol seeks to engage MikaLock to identify potential smart contract exploits through the marketplace of talented security-minded participants and takes that process to completion (finishes the fix reveiw, etc.), they are eligible for activating coverage (unless it's a "best efforts" audit or any other conditions are not met). MikaLock backs its process by allowing such respective protocol a potential recovery as specified in their respective coverage agreement, in the event MikaLock missed an attack vector that is identified through a bug bounty or exploit, so long as no other nonqualifying events apply. Protocol teams (and the users of those protocols) must conduct their own research, and MikaLock makes no representations about the economic viability of each given protocol or associated cryptocurrency. Only the respective protocol itself may recover using MikaLock, and any such recovery is not guaranteed, cannot be guaranteed, and is subject to various terms, conditions, and limitations. A protocol customer may pay for a certain amount of coverage (i.e. 1M USDC), but there is no guarantee that the MikaLock staking pool will have 1M USDC to fulfill the 1M USDC repayment. It's not possible to guarantee this for many reasons: the MikaLock protocol can itself be exploited and all funds drained, other protocol customers may experience exploits first and the funds can get drained, and other instances can occur. Besides this, there are many other reasons why the 4-of-7 multisig or the UMA Optimistic Oracle may decide NOT to send funds to a protocol customer that believes it has experienced an exploit. Every protocol customer has a publicly available "Coverage Agreement" which explains to the multi-sig and to the UMA Optimistic Oracle, what the intended details of coverage are. If an event occurs which those mechanisms decide does not fall into the correct category in the Coverage Agreement, then the protocol customer may not receive funds. There are also risks such as governance attacks, smart contract exploits, malicious behavior etc. that can cause the 4-of-7 multisig or UMA Optimistic Oracle to behave unexpectedly, and potentially not send funds to a protocol customer who believes they should be paid out.

What does a user of a protocol that has coverage from MikaLock get in a bug bounty or exploit event?

Aside from all the risks and potential malfunctions detailed in the paragraphs above, a user of a protocol that has coverage from MikaLock has even more risks for why they may not receive any payout in a loss situation. The MikaLock protocol is designed for management by, and payout to, protocol customers, NOT their users. MikaLock hopes, but cannot guarantee or provide expectation, that the protocol customer will decide to use the funds to repay users. Because of this, even if a payout DOES occur to a protocol customer, there can be no expectation that a user will receive benefit, because the protocol customer would have control of any funds. If the protocol customer makes a mistake (sets up the funds to be sent to the zero address, etc.) then the user of the protocol customer may receive no monetary benefit from the coverage relationship between MikaLock protocol and the protocol customer. If the protocol customer behaves maliciously (runs away with the payout from MikaLock) then the user of the protocol customer may also receive no monetary compensation in this situation. MikaLock wants to make it very clear that there is no guarantee of a payout, and that there is no guarantee that the payout actually reaches the affected users.

How might a protocol customer handle these risks?

From the user perspective, MikaLock strongly discourages a protocol customer from messaging anything to users that includes some kind of promise or guarantee. MikaLock cannot promise or guarantee that any protocol customer, or user of a protocol customer, will receive a payout from MikaLock, even if it seems obvious that the criteria for payout have been met. Many (but not all) of the reasons (smart contract hacks, etc.) are detailed in the paragraphs above. MikaLock wants to make it very clear that a protocol customer should not message to users that MikaLock coverage is anything more than an attempt to provide a possible path to a partial or full payout in the event of a covered smart contract exploit, but with no guarantees of such payout.

From a protocol customer's viewpoint, MikaLock encourages thinking about MikaLock coverage as a very uncertain, but potentially helpful payout in the event of a covered smart contract bug bounty submission or exploit and nothing more. MikaLock does not guarantee or promise the payout or availability of funds. MikaLock strives to never charge a protocol customer for an amount that is more than what is available to that customer at any given moment. For example, if a protocol is paying for 1M USDC of coverage at T=1, the protocol should also have access to 1M USDC of coverage at T=1. If the available coverage goes to 0 USDC at T=2, MikaLock strives to charge the protocol for 0 USDC worth of coverage at that time. This doesn't always happen perfectly, because MikaLock can't adjust coverage amounts every block, but MikaLock strives to at least re-align the coverage and payment aspects every two weeks, and at best much more often (whenever there is a material change).