An unsigned transaction represents a transaction that has not been signed and its values are flexible as long as they are not ambiguous.
The address this transaction is to.
The nonce of this transaction.
The gas limit for this transaction.
The gas price for this transaction.
The maximum fee per unit of gas for this transaction.
The maximum priority fee per unit of gas for this transaction.
The data for this transaction.
The value (in wei) for this transaction.
The chain ID for this transaction. If the chain ID is 0 or null, then EIP-155 is disabled and legacy signing is used, unless overridden in a signature.
A generic object to represent a transaction.
The transaction hash, which can be used as an identifier for transaction. This is the keccak256 of the serialized RLP encoded representation of transaction.
The address transaction is to.
The address transaction is from.
The nonce for transaction. Each transaction sent to the network from an account includes this, which ensures the order and non-replayability of a transaction. This must be equal to the current number of transactions ever sent to the network by the from address.
The gas limit for transaction. An account must have enough ether to cover the gas (at the specified gasPrice). Any unused gas is refunded at the end of the transaction, and if there is insufficient gas to complete execution, the effects of the transaction are reverted, but the gas is fully consumed and an out-of-gas error occurs.
The price (in wei) per unit of gas for transaction.
For EIP-1559 transactions, this will be null.
The maximum price (in wei) per unit of gas for transaction.
For transactions that are not EIP-1559 transactions, this will be null.
The priority fee price (in wei) per unit of gas for transaction.
For transactions that are not EIP-1559 transactions, this will be null.
The data for transaction. In a contract this is the call data.
The value (in wei) for transaction.
The chain ID for transaction. This is used as part of EIP-155 to prevent replay attacks on different networks.
For example, if a transaction was made on goerli with an account also used on homestead, it would be possible for a transaction signed on goerli to be executed on homestead, which is likely unintended.
There are situations where replay may be desired, however these are very rare and it is almost always recommended to specify the chain ID.
The r portion of the elliptic curve signatures for transaction. This is more accurately, the x coordinate of the point r (from which the y can be computed, along with v).
The s portion of the elliptic curve signatures for transaction.
The v portion of the elliptic curve signatures for transaction. This is used to refine which of the two possible points a given x-coordinate can have, and in EIP-155 is additionally used to encode the chain ID into the serialized transaction.
Normalizes the AccessListish anAccessListish into an AccessList.
This is useful for other utility functions which wish to remain flexible as to the input parameter for access lists, such as when creating a Signer which needs to manipulate a possibly typed transaction envelope.
Parses the transaction properties from a serialized transaction.
Computes the serialized transaction, optionally serialized with the a signature. If signature is not present, the unsigned serialized transaction is returned, which can be used to compute the hash necessary to sign.
This function uses EIP-155 if a chainId is provided, otherwise legacy serialization is used. It is highly recommended to always specify a chainId.
If signature includes a chain ID (explicitly or implicitly by using an EIP-155 v or _vs) it will be used to compute the chain ID.
If there is a mismatch between the chain ID of transaction and signature an error is thrown.