Capitalize transaction rule headers

tips/TIP-0038/tip-0038.md

@@ -403,14 +403,14 @@ This unlock condition is employed to achieve conditional sending. An output that
 Condition</i> specified can only be consumed in a transaction that deposits `Return Amount` IOTA coins into
 `Return Address`.
 
-#### Additional syntactic transaction validation rule:
+#### Additional Transaction Syntactic Validation Rules
 
 - `Minimum Storage Deposit` is the storage deposit in the base currency required for a
   [<i>Basic Output</i>](../TIP-0041/tip-0041.md) that only has an <i>Address Unlock Condition</i>, no additional unlock
   conditions, no Mana and no features.
 - It must hold true, that `Minimum Storage Deposit` ≤ `Return Amount` ≤ `Amount`.
 
-#### Additional semantic transaction validation rule:
+#### Additional Transaction Semantic Validation Rules
 
 - An output that has <i>Storage Deposit Return Unlock Condition</i> specified must only be consumed and unlocked in a
   transaction that deposits `Return Amount` IOTA coins to `Return Address` via one or more outputs that:
@@ -496,11 +496,11 @@ An output that contains a <i>Timelock Unlock Condition</i> can not be unlocked b
 The lock is expired when the index of the slot to which the transaction belongs is equal to or past the slot index
 defined in the <i>Timelock Unlock Condition</i>.
 
-#### Additional syntactic transaction validation rules:
+#### Additional Transaction Syntactic Validation Rules
 
 - `Slot Index` field of a <i>Timelock Unlock Condition</i> must be > `0`.
 
-#### Additional semantic transaction validation rules:
+#### Additional Transaction Semantic Validation Rules
 
 - A _Commitment Input_ must be present.
 - Let `Future Bounded Slot Index` be given by `Commitment Index + Min Committable Age` where `Commitment Index` is the
@@ -550,11 +550,11 @@ timelock and an expiration unlock condition.
 For the rationale behind the index choices for the slot index conditions in this Unlock Condition, refer to
 [Expiration Unlock Condition Index Bounds](#expiration-unlock-condition-index-bounds).
 
-#### Additional syntactic transaction validation rules:
+#### Additional Transaction Syntactic Validation Rules
 
 - `Slot Index` field of an <i>Expiration Unlock Condition</i> must be > `0`.
 
-#### Additional semantic transaction validation rules:
+#### Additional Transaction Semantic Validation Rules
 
 - A _Commitment Input_ must be present.
 - Let `Future Bounded Slot Index` be given by `Commitment Index + Min Committable Age`, where `Commitment Index` is the
@@ -655,7 +655,7 @@ specify the validated sender of an output.
 Outputs that support the <i>Sender Feature</i> may specify a `Sender` address which is validated by the protocol during
 transaction validation.
 
-#### Additional semantic transaction validation rule:
+#### Additional Transaction Semantic Validation Rules
 
 - The <i>Sender Feature</i>, and hence the output and transaction that contain it, is valid, if and only if the `Sender`
   address is unlocked in the transaction. Every Address Type specifies under which conditions it is considered unlocked.
@@ -724,7 +724,7 @@ minted) it is checked during transaction validation that an output corresponding
 every future transition of the state machine, it is instead checked that the issuer feature is still present and
 unchanged.
 
-#### Additional semantic transaction validation rule:
+#### Additional Transaction Semantic Validation Rules
 
 - The _Issuer Feature_, and hence the output and transaction that contain it, is valid, if and only if the `Issuer`
   address is unlocked in the transaction. Every Address Type specifies under which conditions it is considered unlocked.
@@ -860,7 +860,7 @@ Feature</i>: smart contract request parameters are encoded in the metadata field
   </tr>
 </table>
 
-#### Additional syntactic transaction validation rules:
+#### Additional Transaction Syntactic Validation Rules
 
 - Each `Key` in the `Entries` must consist only of bytes that are valid ASCII characters, that is, each byte may not
   exceed `127`.
@@ -880,7 +880,7 @@ An example use case is voting on the Tangle via the
 [participation](https://github.com/iota-community/treasury/blob/main/specifications/hornet-participation-plugin.md)
 plugin.
 
-#### Additional syntactic transaction validation rules:
+#### Additional Transaction Syntactic Validation Rules
 
 - An output with <i>Tag Feature</i> is valid, if and only if 0 < `length(Tag)` ≤ `Max Tag Length`.
 
@@ -947,11 +947,11 @@ plugin.
   </tr>
 </table>
 
-#### Additional syntactic output validation rules:
+#### Additional Transaction Syntactic Validation Rules
 
 - `Amount` must not be `0`.
 
-#### Additional semantic transaction validation rules:
+#### Additional Transaction Semantic Validation Rules
 
 Whenever any Native Token Feature is present on the input or output side of a transaction, the following rule applies to
 the transaction: