Nits

bee-message/src/output/mod.rs

@@ -254,7 +254,7 @@ impl Output {
         }
     }
 
-    /// Verify if a valid storage deposit was made. Each [`Output`] has to have an amount that covers its associated
+    /// Verifies if a valid storage deposit was made. Each [`Output`] has to have an amount that covers its associated
     /// byte cost, given by [`ByteCostConfig`].
     /// If there is a [`StorageDepositReturnUnlockCondition`](unlock_condition::StorageDepositReturnUnlockCondition),
     /// its amount is also checked.

bee-message/tip.md

@@ -6,26 +6,15 @@ ce4feebb00f0dd7968b58334465651b95bd21722
   - **output side of the transaction:** the foundry outputs controlling outstanding native token balances must be present in the transaction. The validation of the foundry output(s) determines if the minting operations are valid.
   - **input side of the transaction:** the transaction destroys tokens. The presence and validation of the foundry outputs of the native tokens determines whether the tokens are burned (removed from the ledger) or melted in the foundry.
 
-##### Storage Deposit Return Unlock Condition
-An output that has <i>Storage Deposit Return Unlock Condition</i> specified can only be consumed in a transaction that
-deposits `Return Amount` IOTA coins into `Return Address`. When several of such outputs are consumed, their return
-amounts per `Return Addresses` are summed up and the output side must deposit this total sum per `Return Address`.
-
-###### Additional syntactic transaction validation rule:
-- `Return Amount` must be ≥ than `Minimum Storage Deposit` and must not be `0`.
-- It must hold true, that `0` ≤ `Amount` - `Return Amount` ≤ `Required Storage Deposit of the Output`.
-
 ##### Expiration Unlock Conditions Additional semantic transaction validation rules:
 - If `Milestone Index` != `0`, an output that has <i>Expiration Unlock Condition</i> set must only be consumed and
   unlocked by the target `Address` (defined in <i>Address Unlock Condition</i>) in a transaction that has a confirming
   milestone index < than the `Milestone Index` defined in the unlock condition.
-  `0` value of the `Milestone Index` field is a special flag that signals to the validation that this check
-  must be ignored.
+  `0` value of the `Milestone Index` field is a special flag that signals to the validation that this check must be ignored.
 - If `Milestone Index` != `0`, an output that has <i>Expiration Unlock Condition</i> set must only be consumed and
   unlocked by `Return Address` in a transaction that has a confirming milestone index ≥ than the `Milestone Index`
   defined in the unlock condition.
-  `0` value of the `Milestone Index` field is a special flag that signals to the validation that this check
-  must be ignored.
+  `0` value of the `Milestone Index` field is a special flag that signals to the validation that this check must be ignored.
 - If `Unix Time` != `0`, an output that has <i>Expiration Unlock Condition</i> set must only be consumed and
   unlocked by the target `Address` (defined in <i>Address Unlock Condition</i>) in a transaction that has a confirming
   milestone timestamp earlier than the `Unix Time` defined in the unlock condition.
@@ -38,36 +27,15 @@ amounts per `Return Addresses` are summed up and the output side must deposit th
   `Return Address` must ignore:
   - [Semantic validation of <i>Storage Deposit Return Unlock Condition</i>](#storage-deposit-return-unlock-condition) if present.
 
-##### Immutable Alias Address Unlock Condition Additional semantic transaction validation rules:
- - The output must be unlocked with an <i>[Alias Unlock Block](#alias-unlock-block-semantic-validation)</i>.
- - The next state of the UTXO state machine must have the same <i>Immutable Alias Address Unlock Condition</i> defined.
-
-## Basic Output
-
-- `Amount` field must fulfill the dust protection requirements and must not be `0`.
-
-## Alias Output
-
-- `Amount` field must fulfill the dust protection requirements and must not be `0`.
-
-### Additional Transaction Semantic Validation Rules
+## Alias Output Additional Transaction Semantic Validation Rules
 - For every non-zero explicit `Alias ID` on the output side there must be a corresponding alias on the input side. The
   corresponding alias has the explicit or implicit `Alias ID` equal to that of the alias on the output side.
 
-## Foundry Output
-
-- `Amount` field must fulfill the dust protection requirements and must not be `0`.
-
-### Additional Transaction Semantic Validation Rules
-- The foundry output must be unlocked like any other output type where the <i>Address Unlock Condition</i> defines an
-  <i>Alias Address</i>, by transitioning the alias in the very same transaction. See section
-  [alias unlocking](#unlocking-chain-script-locked-outputs) for more details.
-- When the current state of the foundry with `Foundry ID` is empty, it must hold true for `Serial Number` in the next
-  state, that:
+## Foundry Output Additional Transaction Semantic Validation Rules
+- When the current state of the foundry with `Foundry ID` is empty, it must hold true for `Serial Number` in the next state, that:
     - `Foundry Counter(InputAlias) < Serial Number <= Foundry Counter(OutputAlias)`
     - An alias can create several new foundries in one transaction. It was written for the alias output that freshly
-      created foundry outputs must be sorted in the list of outputs based on their `Serial Number`. No duplicates are
-      allowed.
+      created foundry outputs must be sorted in the list of outputs based on their `Serial Number`. No duplicates are allowed.
     - The two previous rules make sure that each foundry output produced by an alias has a unique `Serial Number`,
       hence each `Foundry ID` is unique.
 - Native tokens present in a transaction are all native tokens present in inputs and outputs of the transaction. Native
@@ -88,17 +56,14 @@ amounts per `Return Addresses` are summed up and the output side must deposit th
   4. When `Next State` is empty, condition `1` and `2` are ignored. It must hold true, that
      `Current State(Minted Tokens) + Token Diff = Current State(Melted Tokens)`
 - `Token Scheme Validation` takes `Token Diff` and `Foundry Diff` and validates if the scheme constraints are respected.
-  This can include validating `Token Tag` part of the `Token IDs` and the `Token Scheme` fields inside the foundry
-  output.
+  This can include validating `Token Tag` part of the `Token IDs` and the `Token Scheme` fields inside the foundry output.
     - `Simple Token Scheme` validates that the `Token Tag` part of the `Token ID` (last 12 bytes) matches the
       `Token Tag` field of the foundry output.
     - Additional token schemes will be defined that make use of the `Foundry Diff` as well, for example validating that
       a certain amount of tokens can only be minted/melted after a certain date.
 
 ## NFT Output
 
-- `Amount` field must fulfill the dust protection requirements and must not be `0`.
-
 ### Additional Transaction Semantic Validation Rules
 - For every non-zero explicit `NFT ID` on the output side there must be a corresponding NFT on the input side. The
   corresponding NFT has the explicit or implicit `NFT ID` equal to that of the NFT on the output side.