Skip to content

Transactions

Transactions are the only means IEP accounts have of altering their state or balance. Each transaction performs only one function, the record of which is permanently stored on the network once that transaction has been included in a block.

Transaction Fees

Transaction fees are the primary mechanism through which token are recirculated back into the network. Every transaction requires a minimum fee of 1 token while several services like aliases, assets or voting require higher fees. When a IEP account forges a block, all of the transaction fees included in that block are awarded to the forging account as a reward.

Until the size of all the transactions in a block exceeds the current 32 kilobyte block size limit, the minimum fee will be sufficient for all transactions to be included in blocks. In situations where the number of unconfirmed transactions exceeds the number that can be placed in a block, forging accounts will likely select transactions with the highest fees. This suggests that transaction processing may be prioritized by including a fee that is higher than the minimum.

Transaction Confirmations

All IEP transactions are considered unconfirmed until they are included in a valid network block. Newly created blocks are distributed to the network by the node (and associated account) that creates them, and a transaction that is included in a block is considered as having received one confirmation.

As subsequent blocks are added to the existing blockchain, each additional block adds one more confirmation to the number of confirmations for a transaction. If a transaction is not included in a block before its deadline, it expires and is removed from the transaction pool.

Transaction Deadlines

Every transaction contains a deadline parameter, set to a number of minutes from the time the transaction is submitted to the network. The default deadline is 1440 minutes (24 hours). A transaction that has been broadcast to the network but has not been included in a block is referred to as an unconfirmed transaction. If a transaction has not been included in a block before the transaction deadline expires, the transaction is removed from the network.

Transactions may be left unconfirmed because they are invalid or malformed, or because blocks are being filled will transactions that have offered to pay higher transaction fees. In the future, features such as multi-signature transactions may be able to take advantage of deadlines as a means of enforcing an expiry date.

Transaction Types

Categorizing IEP transactions into types and subtypes allows for modular growth and development of the IEP protocol without creating dependencies on other “base” functions. As features are added to the IEP core, new transaction types and subtypes can be added to support them. During integration additional transaction types like subscriptions, escrow and automated transactions are added, named as advanced transactions.

Transaction Creation and Processing

The details of creating and processing a IEP transaction are as follows:

  • The sender specifies parameters for the transaction. Types of transactions vary, and the desired type is specified at transaction creation, but several parameters must be specified for all transactions:

    • the private key for the sending account
    • a specified fee for the transaction
    • a deadline for the transaction
    • an optional referenced transaction

  • All values for the transaction inputs are checked. For example, mandatory parameters must be specified; fees cannot be less than or equal to zero; a transaction deadline cannot be less than one minute into the future; if a referenced transaction is specified, then the current transaction cannot be processed until the referenced transaction has been processed.

  • If no exceptions are thrown as a result of parameter checking:
    • The public key for the generating account is computed using the supplied secret passphrase
    • Account information for the generating account is retrieved, and transaction parameters are further validated:
      • The sending account’s balance cannot be zero
      • The sending account’s unconfirmed balance must not be lower than the transaction amount plus the transaction fee
  • If the sending account has sufficient funds for the transaction:
    • A new transaction is created, with a type and subtype value set to match the kind of transaction being made. All specified parameters are included. A unique transaction ID is generated with the creation of the object
    • The transaction is signed using the sending account’s private key
    • The encrypted transaction data is placed within a message instructing network peers to process the transaction
    • The transaction is broadcast to all peers on the network
    • The server responds with a result code: the transaction ID, if the transaction creation was successful an error code and error message if any of the parameter checks fail.