Format Markdown

tips/TIP-0038/tip-0038.md

@@ -41,8 +41,8 @@ replaces: TIP-18
 # Summary
 
 This document defines the common building blocks used across multiple output types and transaction validation rules for
-the IOTA protocol. Many of these were originally introduced in [TIP-18](../TIP-0018/tip-0018.md), and the functionality defined
-in this document is an extension of the primitives defined in TIP-18.
+the IOTA protocol. Many of these were originally introduced in [TIP-18](../TIP-0018/tip-0018.md), and the functionality
+defined in this document is an extension of the primitives defined in TIP-18.
 
 ## Summary of changes compared to TIP-18
 
@@ -119,7 +119,8 @@ maximum possible supply of layer 2 tokens. Solidity, the most popular smart cont
 of an ERC-20 token as `MaxUint256`, therefore it should be possible to represent such a huge amount of assets on
 layer 1.
 
-Outputs that can carry Native Tokens have a [_Native Token Feature_](#native-token-feature). Its transaction validation rules are defined in that section.
+Outputs that can carry Native Tokens have a [_Native Token Feature_](#native-token-feature). Its transaction validation
+rules are defined in that section.
 
 ## Chain Constraint in UTXO
 
@@ -198,7 +199,9 @@ A user can identify by looking at the address whether it is a signature-backed a
 #### Unlocking
 
 The address is unlocked in a transaction if and only if:
-- The _Unlock_ of the first output in the transaction that contains the address is a valid _Signature Unlock_ with respect to the address.
+
+- The _Unlock_ of the first output in the transaction that contains the address is a valid _Signature Unlock_ with
+  respect to the address.
 
 ### Account Address
 
@@ -233,7 +236,9 @@ The address is unlocked in a transaction if and only if:
 #### Unlocking
 
 The address is unlocked in a transaction if and only if:
-- The _Account Output_ from whose _Account ID_ the address is derived from, is **state transitioned** in the transaction. A governance transition does not unlock the address.
+
+- The _Account Output_ from whose _Account ID_ the address is derived from, is **state transitioned** in the
+  transaction. A governance transition does not unlock the address.
 
 ### NFT Address
 
@@ -268,6 +273,7 @@ The address is unlocked in a transaction if and only if:
 #### Unlocking
 
 The address is unlocked in a transaction if and only if:
+
 - The _NFT Output_ from whose _NFT ID_ the address is derived from, is consumed as an input in the transaction.
 
 ## Signatures
@@ -679,7 +685,9 @@ transaction validation.
   </tr>
 </table>
 
-_Restricted Addresses_ cannot be put into _Sender Features_ because they are resolved to the underlying address during unlocking Therefore, when using an Sender Feature with a Restricted Address, the underlying Address must be put into the feature.
+_Restricted Addresses_ cannot be put into _Sender Features_ because they are resolved to the underlying address during
+unlocking Therefore, when using an Sender Feature with a Restricted Address, the underlying Address must be put into the
+feature.
 
 ### Issuer Feature
 
@@ -695,8 +703,8 @@ unchanged.
   address is unlocked in the transaction. Every Address Type specifies under which conditions it is considered unlocked.
 
 The main use case is proving the authenticity of NFTs. Whenever an NFT is minted as an NFT output, the creator (issuer)
-can fill the _Issuer Feature_ with their address that they have to unlock in the transaction. Issuers then can
-publicly disclose their addresses to prove the authenticity of the NFT once it is in circulation.
+can fill the _Issuer Feature_ with their address that they have to unlock in the transaction. Issuers then can publicly
+disclose their addresses to prove the authenticity of the NFT once it is in circulation.
 
 <details>
   <summary>Issuer Feature</summary>
@@ -750,7 +758,9 @@ Whenever a chain account mints an NFT on layer 1 on behalf of some user, the `Is
 address, since the user does not sign the layer 1 transaction. As a consequence, artists would have to mint NFTs
 themselves on layer 1 and then deposit it to chains if they want to place their own address in the `Issuer` field.
 
-_Restricted Addresses_ cannot be put into _Issuer Features_ because they are resolved to the underlying address during unlocking. Therefore, when using an Issuer Feature with a Restricted Address, the underlying Address must be put into the feature.
+_Restricted Addresses_ cannot be put into _Issuer Features_ because they are resolved to the underlying address during
+unlocking. Therefore, when using an Issuer Feature with a Restricted Address, the underlying Address must be put into
+the feature.
 
 ### Metadata Feature
 
@@ -889,17 +899,25 @@ plugin.
 
 ## Native Token Migration
 
-The capability to hold Native Tokens is removed from Alias and NFT Outputs. In Basic and Foundry Outputs the capabaility is moved from a field to the _Native Token Feature_. Moreover, each output can only hold one Native Token instead of up to 64. This section specifies the migration.
+The capability to hold Native Tokens is removed from Alias and NFT Outputs. In Basic and Foundry Outputs the capabaility
+is moved from a field to the _Native Token Feature_. Moreover, each output can only hold one Native Token instead of up
+to 64. This section specifies the migration.
 
 Let `Owner Address` be:
+
 - the _Alias Address_ if the Output is an _Alias Output_.
 - the _NFT Address_ if the Output is an _NFT Output_.
 - the _Address_ in the _Address Unlock Condition_ in the output if the Output is a _Basic Output_.
-- the _Alias Address_ in the _Immutable Alias Address Unlock Condition_ in the output if the Output is a _Foundry Output_.
+- the _Alias Address_ in the _Immutable Alias Address Unlock Condition_ in the output if the Output is a _Foundry
+  Output_.
+
+For each Native Token `Token` in an output with `Native Tokens Count >= 1`, a Basic Output `Output` is created as
+follows:
 
-For each Native Token `Token` in an output with `Native Tokens Count >= 1`, a Basic Output `Output` is created as follows:
 - The `Amount` is set to `0`.
-  - TODO: (Discuss) It would be possible to set this at least to `1` or even higher so as to not violate the `Amount != 0` assumption of outputs, by moving some tokens from the output that originally contained it to the newly created output.
+  - TODO: (Discuss) It would be possible to set this at least to `1` or even higher so as to not violate the
+    `Amount != 0` assumption of outputs, by moving some tokens from the output that originally contained it to the newly
+    created output.
 - The `Output` has one Feature of type _Native Token Feature_ which holds the `Token`.
 - The `Output` has one Unlock Condition of type _Address Unlock Condition_ with the `Address` set to `Owner Address`.