Fix syntax errors for formatter

ERCS/eip-7281.md

@@ -3,7 +3,7 @@ eip: 7281
 title: Sovereign Bridged Token
 description: An interface for creating fungible representations of tokens bridged across domains.
 author: Shaito (@0xShaito), Excalibor (@excaliborr), Arjun Bhuptani (@arjunbhuptani)
-discussions-to: <URL> (TODO)
+discussions-to: https://ethereum-magicians.org/t/erc-7281-sovereign-bridged-tokens/14979
 status: Draft
 type: Standards Track
 category: ERC
@@ -48,7 +48,7 @@ The system proposed below has two main components:
 
 ### Token Interface
 
-All xERC-20 tokens MUST implement the standard ERC-20 interface.  Note that while many of the below functions are inspired by ERC777, implementers are NOT REQUIRED to adhere to the full ERC777 specification.
+All xERC-20 tokens MUST implement the standard ERC-20 interface.  Note that while many of the below functions are inspired by ERC-777, implementers are NOT REQUIRED to adhere to the full ERC-777 specification.
 
 All EIP-XX tokens MUST implement the following interface.
 
@@ -76,7 +76,7 @@ interface IXERC-20 {
    * @notice Reverts when a user with too low of a limit tries to call mint/burn
    */
 
-  error IXERC-20_NotHighEnoughLimits();
+  error IXERC20_NotHighEnoughLimits();
 
   struct Bridge {
     BridgeParameters minterParams;
@@ -163,6 +163,7 @@ interface IXERC-20 {
 ```
 
 Implementations MUST additionally satisfy the following requirements:
+
 - `mint` MUST check that the caller's current available `limit` is greater than or equal to `_amount`
 - `mint` MUST increase the supply of the underlying ERC-20 by `_amount` and reduce the current available `limit`
 - `burn` MUST check that the caller's current available `limit` is greater than or equal to `_amount`
@@ -173,7 +174,7 @@ Implementations MUST additionally satisfy the following requirements:
 The lockbox tries to emulate the WETH contract interface as much as possible. Lockboxes MUST implement the following interface:
 
 ```ts
-interface IXERC-20Lockbox {
+interface IXERC20Lockbox {
   /**
    * @notice Emitted when tokens are deposited into the lockbox
    */
@@ -190,13 +191,13 @@ interface IXERC-20Lockbox {
    * @notice Reverts when a user tries to deposit native tokens on a non-native lockbox
    */
 
-  error IXERC-20Lockbox_NotNative();
+  error IXERC20Lockbox_NotNative();
 
   /**
    * @notice Reverts when a user tries to deposit non-native tokens on a native lockbox
    */
 
-  error IXERC-20Lockbox_Native();
+  error IXERC20Lockbox_Native();
 
   /**
    * @notice Reverts when a user tries to withdraw and the call fails
@@ -223,6 +224,7 @@ interface IXERC-20Lockbox {
 ```
 
 Lockboxes SHOULD additionally implement the following alternative `deposit` function for native (non-ERC-20) assets.
+
 ```ts
 /**
    * @notice Deposit native assets (e.g. ETH) into the lockbox
@@ -293,10 +295,12 @@ Regardless of the above, the failure modes associated with rate limits generally
 EIP-7281 introduces new dynamics for aggregators that massively improve user safety and experience across chains.
 
 There are two unsolved mechanism design problems that currently exist around bridge aggregation:
+
 1. Bridge aggregators primarily compare bridges based on price, which itself is a function of the gas costs needed to use a given bridge and the slippage due to liquidity on that bridge. Competing solely on price heavily favors (a) bridges that take a more custodial/centralized approach to cut costs, and (b) bridges that are willing and able to spend lots of capital on liquidity incentives. This creates a system of incentives that penalizes security-minded approaches & open competition.
 2. Bridge aggregators tap into liquidity from DEX aggregators at the source and destination chains. To do this effectively, they need to query DEX aggregators to get a quote for a destination chain swap, *before they initiate the transaction on the source chain*. However, because liquidity-based bridges introduce slippage on crosschain transfers, there is no way for bridge aggregators to know *up front* how many tokens would be received on the destination. Aggregators currently get around this problem by defaulting to some maximum slippage (or minimum amount received) passed into the underlying bridge protocol - this means that users *always* lose 1%-3% of their value when bridging regardless of how much liquidity is available on a bridge.
 
 With EIP-7281, the above problems are solved elegantly:
+
 1. Because xERC-20s are able to be transferred 1:1 across chains (i.e. they have uniform pricing), aggregators are largely incentivized to route xERC-20 transfers based on *available limits* for a given asset (as transferring over a bridge with insufficient limits would result in a negative experience for their users). In other words, aggregators now route based on a **token-issuer-defined** metric of the perceived security of a given bridge. This radically improves the incentives around secure bridge development, pushing bridges to optimize for security in order to receive the highest possible rate limits for a given token. Perhaps most importantly, this definition of security is sovereign to the token issuer, eliminating the need for aggregators, chains, or other ecosystem actors be "central planners" on determining a given bridge's security model.
 2. With slippage-free xERC-20 transfers, aggregators can know precisely how many tokens will get bridged across chains, eliminating headaches and custom code around sourcing destination-chain liquidity from DEXes. This massively improves pricing for users and composability for developers who want to build across chains.