chore: md lint

neps/nep-0536.md

@@ -21,12 +21,15 @@ Refund receipts create nontrivial overhead: they need to be merklized and sent a
 ## Specification
 
 Pessimistic gas pricing is removed as a part of this change. This means that transactions that do not involve function calls will not generate gas refund receipts as a result. For function calls, this proposal introduces cost of refund to be
-```
+
+```rust
 REFUND_FIXED_COST = action_receipt_creation + action_transfer + action_add_function_call_key
 refund_cost = max(REFUND_FIXED_COST, 0.05 * gas_refund);
 ```
+
 per receipt. The refund fixed cost includes consideration for implicit accounts (created on transfer) and refund for access key allowance, which requires an access key update. The design of refund cost is supposed to penalize developers from attaching too much gas
 and creating unnecessary refunds. Some examples:
+
 * If the contract wants to refund 280Tgas, burning 5% of it would be about 14Tgas, which is a significant cost and developers would be encouraged to optimize it on the frontend.
 * If refund is 100Tgas, then 5% is 5Tgas, which is still significant and discourages developers from doing so.
 * If the refund is <10Tgas (very common case for cross-contract call self-callbacks), the penalty should be just 500Ggas, which is less than the gas refund cost. So only the fixed refund cost will be charged from gas to spawn the gas refund receipt. No UX will be broken for legacy cross-contract call contracts, so long as frontend correctly estimates the required gas in worst case scenario.
@@ -35,6 +38,7 @@ and creating unnecessary refunds. Some examples:
 ## Reference Implementation
 
 The protocol changes are as follows:
+
 * When a transaction is converted to a receipt, there is no longer a `pessmistic_gas_price` multiplier when the signer balance is deducted. Instead, the signer is charged `transaction_gas_cost * gas_price`. If the transaction succeeds, then unless the transaction contains a function call action, it will not generate any refund. On the other hand, when a transaction with multiple action fails, there is gas refund for the rest of unexecuted actions, same as how the protocol works today.
 * For function calls, if X gas is attached during the execution of a receipt and Y gas is used+burnt, then `max(0, X-Y-refund_cost)` is refunded at the original gas price where `refund_cost = max(REFUND_FIXED_COST, 0.05 * X-Y)`. In the case the refund is 0 then no refund receipt is generated.
 * Tokens burnt on refund cost is counted towards tx_balance_burnt and the part over `REFUND_FIXED_COST` is not counted towards gas limit to avoid artificially limiting throughput.