lint setting

.markdownlint.json

@@ -6,5 +6,6 @@
     "MD025": false,
     "MD033": false,
     "MD034": false,
+    "MD046": false,
     "whitespace": false
 }

specs/Standards/Tokens/MultiToken/ApprovalManagement.md

@@ -53,12 +53,12 @@ Let's examine the technical calls through the following scenarios:
 
 Alice approves Bob to transfer her tokens.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Alice approves Bob
 2. Alice queries the token to verify
 
-**Technical calls**
+#### Technical calls
 
 1. Alice calls `mt::mt_approve({ "token_ids": ["1","2"], amounts:["1","100"], "account_id": "bob" })`. She attaches 1 yoctoⓃ, (.000000000000000000000001Ⓝ). Using [NEAR CLI](https://docs.near.org/tools/near-cli) to make this call, the command would be:
 
@@ -78,17 +78,17 @@ Alice approves Bob to transfer her tokens.
 
        true
 
-### 3. Approval with cross-contract call
+### 2. Approval with cross-contract call
 
 Alice approves Market to transfer some of her tokens and passes `msg` so that MT will call `mt_on_approve` on Market's contract. She probably does this via Market's frontend app which would know how to construct `msg` in a useful way.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Alice calls `mt_approve` to approve `market` to transfer her token, and passes a `msg`
 2. Since `msg` is included, `mt` will schedule a cross-contract call to `market`
 3. Market can do whatever it wants with this info, such as listing the token for sale at a given price. The result of this operation is returned as the promise outcome to the original `mt_approve` call.
 
-**Technical calls**
+#### Technical calls
 
 1. Using near-cli:
 
@@ -119,14 +119,14 @@ Alice approves Bazaar and passes `msg` again. Maybe she actually does this via n
 
 Not to worry, though, she checks `mt_is_approved` and sees that she did successfully approve Bazaar, despite the error. She will have to find a new way to list her token for sale in Bazaar, rather than using the same `msg` shortcut that worked for Market.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Alice calls `mt_approve` to approve `bazaar` to transfer her token, and passes a `msg`.
 2. Since `msg` is included, `mt` will schedule a cross-contract call to `bazaar`.
 3. Bazaar doesn't implement `mt_on_approve`, so this call results in an error. The approval still worked, but Alice sees an error in her near-cli output.
 4. Alice checks if `bazaar` is approved, and sees that it is, despite the error.
 
-**Technical calls**
+#### Technical calls
 
 1. Using near-cli:
 
@@ -162,11 +162,11 @@ Not to worry, though, she checks `mt_is_approved` and sees that she did successf
 
 Bob buys Alice's token via Market. Bob probably does this via Market's frontend, which will probably initiate the transfer via a call to `ft_transfer_call` on the nDAI contract to transfer 100 nDAI to `market`. Like the MT standard's "transfer and call" function, [Fungible Token](../FungibleToken/Core.md)'s `ft_transfer_call` takes a `msg` which `market` can use to pass along information it will need to pay Alice and actually transfer the MT. The actual transfer of the MT is the only part we care about here.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Bob signs some transaction which results in the `market` contract calling `mt_transfer` on the `mt` contract, as described above. To be trustworthy and pass security audits, `market` needs to pass along `approval_id` so that it knows it has up-to-date information.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli notation for consistency:
 
@@ -181,11 +181,11 @@ Using near-cli notation for consistency:
 
 Bob transfers same token back to Alice, Alice re-approves Market & Bazaar, listing her token at a higher price than before. Bazaar is somehow unaware of these changes, and still stores `approval_id: 3` internally along with Alice's old price. Bob tries to buy from Bazaar at the old price. Like the previous example, this probably starts with a call to a different contract, which eventually results in a call to `mt_transfer` on `bazaar`. Let's consider a possible scenario from that point.
 
-**High-level explanation**
+#### High-level explanation
 
 Bob signs some transaction which results in the `bazaar` contract calling `mt_transfer` on the `mt` contract, as described above. To be trustworthy and pass security audits, `bazaar` needs to pass along `approval_id` so that it knows it has up-to-date information. It does not have up-to-date information, so the call fails. If the initial `mt_transfer` call is part of a call chain originating from a call to `ft_transfer_call` on a fungible token, Bob's payment will be refunded and no assets will change hands.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli notation for consistency:
 
@@ -200,7 +200,7 @@ Using near-cli notation for consistency:
 
 Alice revokes Market's approval for this token.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli:
 
@@ -215,7 +215,7 @@ Note that `market` will not get a cross-contract call in this case. The implemen
 
 Alice revokes all approval for these tokens
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli:
 

specs/Standards/Tokens/NonFungibleToken/ApprovalManagement.md

@@ -49,13 +49,13 @@ Let's examine the technical calls through the following scenarios:
 
 Alice approves Bob to transfer her token.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Alice approves Bob
 2. Alice queries the token to verify
 3. Alice verifies a different way
 
-**Technical calls**
+#### Technical calls
 
 1. Alice calls `nft::nft_approve({ "token_id": "1", "account_id": "bob" })`. She attaches 1 yoctoⓃ, (.000000000000000000000001Ⓝ). Using [NEAR CLI](https://docs.near.org/tools/near-cli) to make this call, the command would be:
 
@@ -103,13 +103,13 @@ Alice approves Bob to transfer her token.
 
 Alice approves Market to transfer one of her tokens and passes `msg` so that NFT will call `nft_on_approve` on Market's contract. She probably does this via Market's frontend app which would know how to construct `msg` in a useful way.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Alice calls `nft_approve` to approve `market` to transfer her token, and passes a `msg`
 2. Since `msg` is included, `nft` will schedule a cross-contract call to `market`
 3. Market can do whatever it wants with this info, such as listing the token for sale at a given price. The result of this operation is returned as the promise outcome to the original `nft_approve` call.
 
-**Technical calls**
+#### Technical calls
 
 1. Using near-cli:
 
@@ -142,14 +142,14 @@ Alice approves Bazaar and passes `msg` again. Maybe she actually does this via n
 
 Not to worry, though, she checks `nft_is_approved` and sees that she did successfully approve Bazaar, despite the error. She will have to find a new way to list her token for sale in Bazaar, rather than using the same `msg` shortcut that worked for Market.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Alice calls `nft_approve` to approve `bazaar` to transfer her token, and passes a `msg`.
 2. Since `msg` is included, `nft` will schedule a cross-contract call to `bazaar`.
 3. Bazaar doesn't implement `nft_on_approve`, so this call results in an error. The approval still worked, but Alice sees an error in her near-cli output.
 4. Alice checks if `bazaar` is approved, and sees that it is, despite the error.
 
-**Technical calls**
+#### Technical calls
 
 1. Using near-cli:
 
@@ -189,11 +189,11 @@ Not to worry, though, she checks `nft_is_approved` and sees that she did success
 
 Bob buys Alice's token via Market. Bob probably does this via Market's frontend, which will probably initiate the transfer via a call to `ft_transfer_call` on the nDAI contract to transfer 100 nDAI to `market`. Like the NFT standard's "transfer and call" function, [Fungible Token](../FungibleToken/Core.md)'s `ft_transfer_call` takes a `msg` which `market` can use to pass along information it will need to pay Alice and actually transfer the NFT. The actual transfer of the NFT is the only part we care about here.
 
-**High-level explanation**
+#### High-level explanation
 
 1. Bob signs some transaction which results in the `market` contract calling `nft_transfer` on the `nft` contract, as described above. To be trustworthy and pass security audits, `market` needs to pass along `approval_id` so that it knows it has up-to-date information.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli notation for consistency:
 
@@ -209,11 +209,11 @@ Using near-cli notation for consistency:
 
 Bob transfers same token back to Alice, Alice re-approves Market & Bazaar, listing her token at a higher price than before. Bazaar is somehow unaware of these changes, and still stores `approval_id: 3` internally along with Alice's old price. Bob tries to buy from Bazaar at the old price. Like the previous example, this probably starts with a call to a different contract, which eventually results in a call to `nft_transfer` on `bazaar`. Let's consider a possible scenario from that point.
 
-**High-level explanation**
+#### High-level explanation
 
 Bob signs some transaction which results in the `bazaar` contract calling `nft_transfer` on the `nft` contract, as described above. To be trustworthy and pass security audits, `bazaar` needs to pass along `approval_id` so that it knows it has up-to-date information. It does not have up-to-date information, so the call fails. If the initial `nft_transfer` call is part of a call chain originating from a call to `ft_transfer_call` on a fungible token, Bob's payment will be refunded and no assets will change hands.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli notation for consistency:
 
@@ -229,7 +229,7 @@ Using near-cli notation for consistency:
 
 Alice revokes Market's approval for this token.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli:
 
@@ -246,7 +246,7 @@ Note that `market` will not get a cross-contract call in this case. The implemen
 
 Alice revokes all approval for this token.
 
-**Technical calls**
+#### Technical calls
 
 Using near-cli: