fix $MOVE

Author: apenzk

MIP/mip-74/README.md

@@ -187,15 +187,15 @@ A. **Single-sided rate limiting (on source chain)**
 - Rate limiting should be implemented on the L1 and maps each day to a budget, for each direction. Once the budget is reached on one of the directions, no more tokens can be transferred on that direction.
 - The bridge is financially secured by an Insurance Fund, see [MIP-50](https://github.com/movementlabsxyz/MIP/pull/50), which determines  the maximum amount of tokens to be transferred per day, called the budget. The insurance fund is maintained by Movement Labs.
 - The budget is one quarter of the Insurance Fund balance. This is meant to account for the insurance fund to be able to insure all current funds already transferred and all tokens inflight, per direction.
-- The Insurance Fund maintains the rate limit budget by adjusting its own `$MOVE` balance. It should be either the Movement Labs multisig or a new multisig 1/3 if we choose to adopt an approach that requires more direct ability by the personnel.
+- The Insurance Fund maintains the rate limit budget by adjusting its own \$MOVE balance. It should be either the Movement Labs multisig or a new multisig 1/3 if we choose to adopt an approach that requires more direct ability by the personnel.
 - Once the rate limit budget is reached, if no issues have been observed, operators should simply wait for the next day.
 - If an issue has been observed, an operator should simply transfer to the bridge contract the sum of the exploit size, being the result of additional supply on L1, outside of the bridge address, and the additional supply on L2. This action covers both cases where tokens were extracted from the bridge contract on L1 or over-minted on L2. Movement Foundation should evaluate the amount of tokens that should be held by the Insurance Fund after the incident and transfer to it the amount to reach that amount.
 - This approach is open to exploits where the Relayer key is compromised. It would enable the exploiter to freely mint on L2.
 
 B. **Two-sided partial rate limiting (target chain only)**
 
 - Rate limiting should be implemented on both L1 and L2 for inbound transactions only. It maps a daily budget of inbound transactions and once it's reached, the Relayer cannot complete more transactions. The bridge is financially secured by two Insurance Funds, one on each side, maintained by Movement Labs, and the maximum amount of tokens to be transferred per day, per direction is half of each of its Insurance Funds balances. This is meant to account for all tokens already transferred and inflight, per direction.
-- The Insurance Funds determine the rate limit budgets. Thus the rate limit can be adjusted by changing the `$MOVE` balance. They should be either Movement Labs multisigs or new multisigs 1/3 if we choose to adopt an approach that requires more direct ability by the personnel.
+- The Insurance Funds determine the rate limit budgets. Thus the rate limit can be adjusted by changing the \$MOVE balance. They should be either Movement Labs multisigs or new multisigs 1/3 if we choose to adopt an approach that requires more direct ability by the personnel.
 - Once the rate limit budget is reached, if no issues have been observed, operators should simply wait for the next day.
 - If an issue has been observed, operators should transfer to the bridge address the exploit amount on the L1 and burn the exploit amount on the L2. Movement Foundation should evaluate the amount of tokens that should be held by the Insurance Funds and operators should receive those tokens and bridge tokens if an exploit occurred on L2.
 - This approach is more susceptible to issues on the frontend because the frontend has to acknowledge rate limit budget and inflight tokens and inform users if the rate limit is about to be reached, not only if it has been reached.