> For the complete documentation index, see [llms.txt](https://icarusnetwork.gitbook.io/icarus-network-1/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://icarusnetwork.gitbook.io/icarus-network-1/transactions.md).

# Transactions

A Transaction (formally, T) is a cryptographically unmodifiable instruction to change the world state (σ ), constructed by an external actor. A Transaction could instruct validators to move balance from the sender’s account to a recipient’s account, update the state of a smart contract, write changes to the IAN, or more. In the Icarus network, all valid transactions are accepted into the ledger regardless of the success of the execution of that Transaction. A Transaction is considered
 valid if it is formatted correctly, and a Transaction is considered successful if its execution resulted in an update to the world state (σ ).

Pulling apart the acceptance and execution of Transactions has two main benefits: (1) increased throughput for transactions that alter the asymmetric information stored in the IAN thanks to the distribution of work amongst Farmers, and (2) Transactions that are accepted but not successful can still be used to manage the bandwidth consumed by the sending account. Transactions have varying properties based on their type:

**Type:** A single byte that determines the function of the transaction. Required for all transactions

**From:** The 160-bit address of the transaction’s sender. Cannot be the same as the to Address. Required in all transaction types

**To** : The 160-bit address of the transaction’s recipient. Required for TokenTransfer and Execute transaction types

**Value:** A scalar value equal to the total amount of Divvitos to be transferred from the balance of the from address to the to address. Required for TokenTransfer, Deploy, and Execute transaction types; formally Tv<br>

**Time:** A RFC3339 standard time signature for the transaction. The transaction’s time\
determines its order in the ledger. Required for all transaction types; formally Tts

**Code:** The IVM bytecode that is executed each time a subsequent Execute transaction is\
called with a To value that equals the Hash of this Transaction. Required only for Deploy transactions; formally Tc

**Abi:** The Application Binary Interface for the smart contract being deployed. When applied to the IVM bytecode, the ABI defines the methods available to interact with the smart contract and their required parameters. Required only for Deploy transactions; formally Ta

**Method:** An unlimited size byte array that maps to a method defined in the ABI (T quired for Execution and Election transactions; formally Tm

**Params**: An unlimited size byte array that maps to the parameters of Method (Tm) as defined in the ABI (Ta). Required for Execution and Election transactions; formally Tp

**Hash:** The 256-bit keccak-256 hash of the concatenation of the Type, From, To, Value, Code, Abi, Method , Params, and Time fields in that order. The hash is used as the unique identifier for all transactions. In Deploy transaction types, the hash is also used as the address of the deployed smart contract. Required for all transactions; formally Th

**Signature:** The signature is a 65 byte array in \[R S V] format of the transaction hash (Th) where V is 0 or 1. R, S, and V are the values used in the secp256k1 ECDSA signature algorithm used to recover the from address and prove that the transaction was created by the owner of the associated private key. Required for all transaction types; formally Ts