A corollary of this is that acceptance of the new block by the network effectively includes acceptance of the reward. The reward payment to the miner is part of the state of a particular fork. If during fork recovery certain blocks are rejected, then the mining rewards payments for those blocks are also invalidated. 4.2 Receive, Validate, and Propagate Transactions and Blocks

4.2.1 Transactions When the node receives a new transaction (sent from another Arweave node, or from an edge client or app), the node validates the transaction fee and that the previous transaction reference matches that which is found in the Wallet List. If the transaction is successfully validated, the node then propagates the transaction to its peers as quickly as possible. Incentive mechanisms associated with the AIIA meta-game and fork avoidance promote this behaviour (see section 6). It is in a nodes interest to propagate the transaction directly upon receipt instead of just mining it into a block. This is because the individual transaction needs to be accepted as valid by a majority of other nodes in the network before a block containing that transaction can be accepted. The steps for validating a transaction before entry into the transaction pools are as follows:

1. Transactions that are not well-formed (see appendix section 10.2.4 for the full anatomy of a transaction) are ignored by the recipient node; 2. Transactions that have already been processed are dropped; 3. The wallet associated with the transaction must contain a sucient token balance in order to process said transaction and any additional pending transactions from the same wallet; 4. T Xowner and T Xtarget should not refer to the same wallet; 5. The transaction cost must be above a dynamic minimum (see section 3.2.3 for further details of transaction cost and pricing); 6. The T Xanchor must be present in the current wallet list as T Xowners last processed transaction ID, the independent hash of one of the last 50 blocks, or be empty for the rst transaction; 34

4.2.2 Blocks During operation, a node will receive blocks from other peers in the data distribution network, either other miners or special-purpose peers (for example, Weaver browser nodes). The receiving node needs to validate and accept the block as quickly as possible in order to keep up with network consensus and continue mining eectively. Prompt block propagation is part of fork avoidance a node must make sure the blocks it accepts are also accepted by its peers. Critically, in order to make preliminary block verication inexpensive prior to gossiping the block to other peers (risking increasing block consensus time and subsequently forks see section 2.3 for more details of blockshadows), the proof of work found in blockshadows is veriable independently from other block checks. This avoids the necessity for constructing blockshadows into full block structures and verifying the BDS which could otherwise become a denial of service attack vector.