fix lints

Signed-off-by: Guillaume Grosbois <guillaume.grosbois@uniswap.org>

ERCS/erc-7754.md

@@ -29,7 +29,7 @@ via e.g. an XSS vulnerability or due to a malicious extension.
 Once an RPC request is intercepted, it can be modified in a number of pernicious ways, including:
 
 - Editing the calldata in order to siphon funds or otherwise change the transaction outcome
-- Modifying the parameters of an EIP-712 request
+- Modifying the parameters of an [EIP-712](../../EIPs/blob/master/EIPS/eip-712.md) request
 - Obtaining a replayable signature from the wallet
 
 Even if the user realizes that requests from the dapp may be tampered with, they have little to no recourse to mitigate the problem.
@@ -53,7 +53,7 @@ We propose to use the dapp's domain certificate of a root of trust to establish
 
 1. The user's browser verifies the domain certificate and displays appropriate warnings if overtaken
 2. The DNS record of the dapp hosts a TXT field pointing to a URL where a JSON manifest is hosted
-   - This file SHOULD be at a well known address such as <https://domain.com/.well-known/twit.json>
+   - This file SHOULD be at a well known address such as `https://domain.com/.well-known/twit.json`
 3. The config file contains an array of objects of the form `{ id, alg, publicKey }`
 4. For signed requests, the dapp first securely signs the payload with a private key, for example by submitting a request to its backend
 5. The original payload, signature, and public key id are sent to the wallet via the `wallet_signedRequest` RPC method
@@ -79,7 +79,7 @@ Example DNS record for `my-crypto-dapp.org`:
 TXT: TWIT=/.well-known/twit.json
 ```
 
-Example TWIT manifest at <https://my-crypto-dapp.org/twit.json>:
+Example TWIT manifest at `https://my-crypto-dapp.org/twit.json`:
 
 ```json
 {
@@ -90,7 +90,7 @@ Example TWIT manifest at <https://my-crypto-dapp.org/twit.json>:
 }
 ```
 
-Dapps SHOULD only rely on algorithms available via [SubtleCrypto](https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto), since they are present in every browser.
+Dapps SHOULD only rely on algorithms available via [SubtleCrypto](https://www.w3.org/TR/WebCryptoAPI/), since they are present in every browser.
 
 #### Manifest schema
 
@@ -131,7 +131,7 @@ type SignedRequestParameters<Params> = [
 ];
 ```
 
-Here's a non-normative example of calling `wallet_signedRequest` using the EIP-1193 provider interface:
+Here's a non-normative example of calling `wallet_signedRequest` using the [EIP-1193](../../EIPs/blob/master/EIPS/eip-1193.md) provider interface:
 
 ```typescript
 const keyId = '1';
@@ -154,7 +154,7 @@ const result = await ethereum.request({
 
 #### Signature verification
 
-1. Upon receiving an EIP-1193 call, the wallet MUST check of the existence of the TWIT manifest for the `sender.tab.url` domain
+1. Upon receiving an [EIP-1193](../../EIPs/blob/master/EIPS/eip-1193.md) call, the wallet MUST check of the existence of the TWIT manifest for the `sender.tab.url` domain
    a. The wallet MUST verify that the manifest is hosted on the `sender.tab.url` domain
    b. The wallet SHOULD find the DNS TXT record to find the manifest location
    b. The wallet MAY first try the `/.well-known/twit.json` location
@@ -226,6 +226,12 @@ that interactions between the dapp they are using and the wallet are secure, and
 When dealing with insecure request, either because the dapp (or an attacker) uses `request` on a domain where TWIT is configured, or because the signature does not match, wallets should warn the user but
 not block: an eloquently worded warning will increase the transparency enough that end user may opt to cancel the interaction or proceed with the unsafe call.
 
+## Rationale
+
+The proposed implementation does not modify any of the existing functionalities offered by [EIP-712](../../EIPs/blob/master/EIPS/eip-712.md) and [EIP-1193](../../EIPs/blob/master/EIPS/eip-1193.md). Its additive
+nature makes it inherently backward compatible. Its core design is modeled after existing solutions to existing problems (such as DKIM). As a result the proposed specification will be non disruptive, easy to
+implements for both wallets and dapps, with a predictable threat model.
+
 ## Security Considerations
 
 ### Replay prevention
@@ -236,7 +242,7 @@ While signing the `requestArg` payload guarantees data integrity, it does not pr
 2. a signed payload can be replayed across multiple chains
 
 _Effective_ time replay attacks as described in `1.` are generally prevented by the transaction nonce.
-Cross chain replay can be prevented by leveraging the EIP-712 `signTypedData` method.
+Cross chain replay can be prevented by leveraging the [EIP-712](../../EIPs/blob/master/EIPS/eip-712.md) `signTypedData` method.
 
 Replay attack would still be possible on any method that is not protected by either: this affects effectively all the "readonly" methods
 which are of very limited value for an attacker.
@@ -247,7 +253,7 @@ the manifest will provide the necessary room to enforce a replay protection enve
 ## References
 
 - Related EIPs / ERCs:
-  - [EIP-1193: Ethereum Provider JavaScript API](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1193.md)
+  - [EIP-1193: Ethereum Provider JavaScript API](../../EIPs/blob/master/EIPS/eip-1193.md)
 
 ## Copyright