Skip to content

Interface: PlainTransaction

JSON-compatible and human-readable format of transactions. E.g. addresses are presented in their human-readable format and address types and the network are represented as strings. Data and proof are serialized as an object describing their contents (not yet implemented, only the { raw: string } fallback is available).

Hierarchy

Table of contents

Properties

Properties

data

data: PlainTransactionRecipientData

The data field of a transaction serves different purposes based on the transaction's recipient type. For transactions to "basic" address types, this field can contain up to 64 bytes of unstructured data. For transactions that create contracts or interact with the staking contract, the format of this field must follow a fixed structure and defines the new contracts' properties or how the staking contract is changed.

Defined in

web.d.ts:501


fee

fee: number

The transaction's fee in luna (NIM's smallest unit).

Defined in

web.d.ts:471


feePerByte

feePerByte: number

The transaction's fee-per-byte in luna (NIM's smallest unit).

Defined in

web.d.ts:475


flags

flags: number

Any flags that this transaction carries. 0b1 = 1 means it's a contract-creation transaction, 0b10 = 2 means it's a signalling transaction with 0 value.

Defined in

web.d.ts:488


format

format: PlainTransactionFormat

The transaction's format. Nimiq transactions can have one of two formats: "basic" and "extended". Basic transactions are simple value transfers between two regular address types and cannot contain any extra data. Basic transactions can be serialized to less bytes, so take up less place on the blockchain. Extended transactions on the other hand are all other transactions: contract creations and interactions, staking transactions, transactions with exta data, etc.

Defined in

web.d.ts:448


network

network: string

The network name on which this transaction is valid.

Defined in

web.d.ts:483


proof

proof: PlainTransactionProof

The proof field contains the signature of the eligible signer. The proof field's structure depends on the transaction's sender type. For transactions from contracts it can also contain additional structured data before the signature.

Defined in

web.d.ts:507


recipient

recipient: string

The transaction's recipient address in human-readable IBAN format.

Defined in

web.d.ts:461


recipientType

recipientType: PlainAccountType

The type of the transaction's sender. "basic" are regular private-key controlled addresses, "vesting" and "htlc" are those contract types respectively, and "staking" is the staking contract.

Defined in

web.d.ts:466


sender

sender: string

The transaction's sender address in human-readable IBAN format.

Defined in

web.d.ts:452


senderData

senderData: PlainTransactionSenderData

The sender_data field serves a purpose based on the transaction's sender type. It is currently only used for extra information in transactions from the staking contract.

Defined in

web.d.ts:493


senderType

senderType: PlainAccountType

The type of the transaction's sender. "basic" are regular private-key controlled addresses, "vesting" and "htlc" are those contract types respectively, and "staking" is the staking contract.

Defined in

web.d.ts:457


size

size: number

The transaction's serialized size in bytes. It is used to determine the fee-per-byte that this transaction pays.

Defined in

web.d.ts:512


transactionHash

transactionHash: string

The transaction's unique hash, used as its identifier. Sometimes also called txId.

Defined in

web.d.ts:440


valid

valid: boolean

Encodes if the transaction is valid, meaning the signature is valid and the data and proof fields follow the correct format for the transaction's recipient and sender type, respectively.

Defined in

web.d.ts:517


validityStartHeight

validityStartHeight: number

The block height at which this transaction becomes valid. It is then valid for 7200 blocks (~2 hours).

Defined in

web.d.ts:479


value

value: number

Defined in

web.d.ts:467