FuelLabs · adlerjohn · Feb 21, 2021 · Feb 21, 2021 · Feb 21, 2021 · Feb 21, 2021
diff --git a/specs/protocol/cryptographic_primitives.md b/specs/protocol/cryptographic_primitives.md
@@ -6,4 +6,29 @@ All hashing is done with SHA-2-256 (also known as SHA-256), defined in [FIPS 180
 
 ## Merkle Trees
 
-Two Merkle tree structures are used: a plain Binary Merkle Tree (to commit to transactions) and a Sparse Merkle Tree (to commit to contract storage, i.e. state). A specification for the Binary Merkle Tree is [here](https://github.com/lazyledger/lazyledger-specs/blob/master/specs/data_structures.md#binary-merkle-tree) and a specification for the Sparse Merkle Tree is [here](https://github.com/lazyledger/lazyledger-specs/blob/master/specs/data_structures.md#sparse-merkle-tree).
+Two Merkle tree structures are used: a Binary Merkle Sum Tree (to commit to transactions and collected fees) and a Sparse Merkle Tree (to commit to contract storage, i.e. state).
+
+### Binary Merkle Sum Tree
+
+The Binary Merkle Sum Tree is an extension of the tree defined in [RFC-6962](https://tools.ietf.org/html/rfc6962).
+
+The root pair `(fee, digest)` of an empty tree is:
+```
+(0x0000000000000000, hash()) = (0x0000000000000000, 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855)
+```
+
+The root pair of a tree with one leaf:
+```
+(leaf.fee, hash(0x00 ++ serialize(leaf)))
+```
+
+The root pair of a tree with two or more leaves is defined recursively:
+```
+(left.fee + right.fee, hash(0x01 ++ left.fee ++ left.digest ++ right.fee ++ right.digest))
+```
+
+In other words, the root pair is 40 bytes (8 for fee sum, 32 for hash digest).
+
+### Sparse Merkle Tree
+
+A specification for the Sparse Merkle Tree is [here](https://github.com/lazyledger/lazyledger-specs/blob/master/specs/data_structures.md#sparse-merkle-tree).
diff --git a/specs/protocol/identifiers.md b/specs/protocol/identifiers.md
@@ -2,6 +2,9 @@
 
 - [Transaction ID](#transaction-id)
 - [UTXO ID](#utxo-id)
+    - [Coin ID](#coin-id)
+    - [Deposit ID](#deposit-id)
+    - [Fee ID](#fee-id)
 
 This document defines how to compute the unique identifiers used for transactions and state elements.
 
@@ -11,6 +14,14 @@ The _transaction ID_ (also called _transaction hash_) of a transaction is comput
 
 ## UTXO ID
 
-The UTXO ID of a transaction's output is computed as the [hash](./cryptographic_primitives.md#hashing) of the concatenation of the [transaction ID](#transaction-id) and the output index as a `uint8`.
+### Coin ID
+
+The UTXO ID of a transaction's output (i.e. a _coin_) is computed as the [hash](./cryptographic_primitives.md#hashing) of the concatenation of the [transaction ID](#transaction-id) and the output index as a `uint8`.
+
+### Deposit ID
 
 The UTXO ID of a deposit is computed as the [hash](./cryptographic_primitives.md#hashing) of TODO.
+
+### Fee ID
+
+The UTXO ID of collected fees in a block is the block height as a 32-byte big-endian unsigned integer (i.e. the first byte of the 32-byte array is the most significant byte, and so on).
diff --git a/specs/protocol/tx_format.md b/specs/protocol/tx_format.md
@@ -51,6 +51,7 @@ Transaction is invalid if:
 * `inputsCount > MAX_INPUTS`
 * `outputsCount > MAX_OUTPUTS`
 * `witnessesCount > MAX_WITNESSES`
+* More than one output is of type `OutputType.Change`
 
 When serializing a transaction, fields are serialized as follows (with inner structs serialized recursively):
 1. `uint8`, `uint16`, `uint32`, `uint64`: big-endian right-aligned to 8 bytes.

diff --git a/specs/protocol/tx_validity.md b/specs/protocol/tx_validity.md
@@ -9,6 +9,7 @@
 - [Predicate Verification](#predicate-verification)
 - [Script Execution](#script-execution)
 - [VM Postcondition Validity Rules](#vm-postcondition-validity-rules)
+    - [Correct Change](#correct-change)
     - [No Inflation](#no-inflation)
     - [State Changes](#state-changes)
 
@@ -112,20 +113,26 @@ If `tx.scriptLength > 0`, the script must be executed. The free balance availabl
 freeBalance = available_balance(tx) - unavailable_balance(tx)
 ```
 
-Once the free balance is computed, the [script is executed](../vm/main.md#script-execution) and the transaction in memory on VM termination is used as the final transaction which is included in the block, i.e.:
+Once the free balance is computed, the [script is executed](../vm/main.md#script-execution). After execution, the following is extracted:
 
-```
-tx = MEM[40, MEM[32, 8]]
-```
+1. The transaction in memory on VM termination is used as the final transaction which is included in the block, i.e. `tx = MEM[40, MEM[32, 8]]`.
+1. The unspent free balance `unspentBalance` from the `$bal` register.
+1. The unspent gas `unspentGas` from the `$ggas` register.
+
+The fees incurred for a transaction are `(tx.gasLimit - unspentGas) * tx.gasPrice`.
 
-If the transaction as included in a block does not match the final transaction, the block is invalid.
+If the transaction as included in a block does not match this final transaction, the block is invalid.
 
 ## VM Postcondition Validity Rules
 
 This section defines _VM postcondition validity rules_ for transactions: the requirements for a transaction to be valid after it has been executed.
 
 Given transaction `tx`, state `state`, and contract set `contracts`, the following checks must pass.
 
+### Correct Change
+
+If a change output is present, it must have an `amount` of `unspentBalance + unspentGas * tx.gasPrice`.
+
 ### No Inflation
 
 ```py