docs: add more on transaction validity

plasma_framework/docs/integration-docs/integration-doc.md

@@ -64,11 +64,20 @@ To determine the position of the outputs of a transaction, you will include the
 
 
 
-## Transaction type and output type
+## Transaction type, output type, and spending condition
 
-ALD introduces the concepts of transaction type, and transcation output type. Each transaction type and transcation output type can define different rules about how to spend funds.
+ALD introduces the concepts of transaction type and transaction output type.
+Each transaction output type can define its own rule about how funds may be spent.
 
+Rules are encoded in the [mapping](../contracts/src/exits/registries/SpendingConditionRegistry.sol) from `hash(tx_type, output_type)` to an address.
+If address is 0x0, spend is forbidden.
+Otherwise, address is referencing a contract that implements [ISpendingCondition](../contracts/src/exits/interfaces/ISpendingCondition.sol) interface and its `verify(...) returns (bool)` function.
 
+For a valid transaction, `verify(...)` will return `true` for every of transaction's inputs.
+
+## Printing money
+
+Plasma transactions must not mint tokens. Sum of inputs must not be smaller than sum of outputs. ALD defines `IStateTransitionVerifier.verify(...) returns (bool)` [interface](../contracts/src/exits/interfaces/IStateTransitionVerifier.sol) where such checks must be implemented. An [example](../contracts/src/exits/payment/PaymentTransactionStateTransitionVerifier.sol) is in `PaymentTransactionStateTransitionVerifier`.
 
 ## Generic transaction format
 All Transactions follow the same basic format [GenericTransaction](../contracts/GenericTransaction.md) and can be extended. 
@@ -93,6 +102,13 @@ txData ::= undefined, to be defined by concrete transaction types
 metaData ::= bytes32
 ```
 
+GenericTransaction [performs](../contracts/src/transactions/GenericTransaction.sol#L42) a range of checks when decoding:
+
+* Is binary a proper RLP encoding?  
+* Is decoded list of required length? See `TX_NUM_ITEMS`  
+* Is txType an integer? Is it `> 0`?  
+* Is each of the outputs correctly formed? See `decodeOutput(...)`
+
 The current implementation supports only the `Payment` transaction type.
 
 Support for additional transaction types, such as ERC721, is reserved for future development.
@@ -122,7 +138,13 @@ Child chain and watcher both expect, for a signed transaction to be valid, that:
 A signature is a specific form of a `witness` and is called as such throughout this document.
 
 ## Payment transaction format
-Payment transactions are used to transfer fungible tokens, such as ETH and ERC20 tokens. A Payment transaction's output is as described in [FungibleTokenOutputModel](../contracts/FungibleTokenOutputModel.md)
+Payment transactions are used to transfer fungible tokens, such as ETH and ERC20 tokens. A Payment transaction's output is as described in [FungibleTokenOutputModel](../contracts/FungibleTokenOutputModel.md).
+
+[PaymentTransactionModel](../contracts/PaymentTransactionModel.md) does few more checks when decoding comparing to GenericTransaction above:
+
+* Is amount of inputs too large? See `_MAX_INPUT_NUM`.  
+* Is outputs number in range `(0, _MAX_OUTPUT_NUM]`?  
+* None of input pointers is null.
 
 ### Payment transaction RLP encoding
 A Payment transaction must be RLP encoded as follows: