```{eval-rst}
.. meta::
:title: Raw Transaction Format
:description: Dash transactions are broadcast in a serialized raw format, which is hashed to create the TXID and merkle root, complying with the consensus rules.
```
# Raw Transaction Format
Dash transactions are broadcast between [peers](../resources/glossary.md#peer) in a serialized byte format, called [raw format](../resources/glossary.md#raw-format). It is this form of a transaction which is SHA256(SHA256()) hashed to create the [TXID](../resources/glossary.md#transaction-identifiers) and, ultimately, the [merkle root](../resources/glossary.md#merkle-root) of a [block](../resources/glossary.md#block) containing the transaction---making the transaction format part of the [consensus rules](../resources/glossary.md#consensus-rules).
Dash Core and many other tools print and accept [raw transactions](../resources/glossary.md#raw-transaction) encoded as hex.
Transactions prior to protocol version 70209 defaulted to version 1. Transaction version 2 was the default in protocol versions => 70209 and < 70213. Version 2 transactions have the same format, but the `lock_time` parameter was redefined by [BIP68](https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki) to enable relative lock-times. (Note: transactions in the [block chain](../resources/glossary.md#block-chain) are allowed to list a higher version number to permit [soft forks](../resources/glossary.md#soft-fork), but they are treated as version 2 transactions by current software.)
Dash Core 0.13.0 (protocol version 70213) introduced transaction version 3 as part of the [DIP2 - Special Transactions](https://github.com/dashpay/dips/blob/master/dip-0002.md) implementation. Details of the changes introduced by this feature and currently implemented [special transactions](../resources/glossary.md#special-transactions) can be found in the [Special Transactions section](../reference/transactions-special-transactions.md) below as well as in the [DIP](https://github.com/dashpay/dips/blob/master/dip-0002.md).
A raw transaction has the following top-level format:
| Bytes | Name | Data Type | Description
|----------|--------------|---------------------|-------------
| 2 | version | uint16_t | *Converted from 4 bytes to 2 bytes by DIP2 in v0.13.0*
Transaction version number; currently version 3. Programs creating transactions using newer consensus rules may use higher version numbers.
| 2 | type | uint16_t | *Added by DIP2 in v0.13.0. Uses 2 bytes that were previously part of `version`*
Transaction type number; 0 for classical transactions; Non-zero for DIP2 special transactions.
| *Varies* | tx_in count | compactSize uint | Number of inputs in this transaction.
| *Varies* | tx_in | txIn | Transaction inputs. See description of txIn below.
| *Varies* | tx_out count | compactSize uint | Number of outputs in this transaction.
| *Varies* | tx_out | txOut | Transaction outputs. See description of txOut below.
| 4 | lock_time | uint32_t | A time (Unix epoch time) or block number. See the [locktime parsing rules](../guide/transactions-locktime-and-sequence-number.md).
| *Varies* | extra_payload size | compactSize uint | *Added by DIP2 in v0.13.0*
Variable number of bytes of extra payload for DIP2-based special transactions
| *Varies* | extra_payload | blob | *Added by DIP2 in v0.13.0*
Special transaction payload.
A transaction may have multiple [inputs](../resources/glossary.md#input) and [outputs](../resources/glossary.md#output), so the txIn and txOut structures may recur within a transaction. [CompactSize unsigned integers](../resources/glossary.md#compactsize) are a form of variable-length integers; they are described in the [CompactSize section](../reference/transactions-compactsize-unsigned-integers.md).
## JSON-RPC Responses
When retrieving transaction data via Dash Core RPCs (e.g. the [`getrawtransaction` RPC](../api/remote-procedure-calls-raw-transactions.md#getrawtransaction)), the transaction data is returned in the following format.
Version 1 and 2 Transaction Structure (prior to DIP2 activation in Dash Core v0.13.0):
``` json
{
"txid": "",
"size": "",
"version": 2,
"locktime": 0,
"vin": [ ],
"vout": [ ]
}
```
Version 3 Transaction Structure (Dash Core v0.13.0+ and activated [DIP2](https://github.com/dashpay/dips/blob/master/dip-0002.md)):
``` json
{
"txid": "",
"size": "",
"version": 3,
"type": "",
"locktime": 0,
"vin": [ ],
"vout": [ ],
"extraPayloadSize": "",
"extraPayload": "…"
}
```
For [special transactions](../resources/glossary.md#special-transactions) (those using the extraPayload fields), JSON-RPC responses contain a parsed JSON representation of the Transaction Payload.
The sample transaction below shows the response for a quorum commitment special transaction:
``` json
{
"txid": "592a09d08348d970b4d9ba216246a23dac866717b460d3f369a86293b9839eea",
"size": 342,
"version": 3,
"type": 6,
"locktime": 0,
"vin": [
],
"vout": [
],
"extraPayloadSize": 329,
"extraPayload": "0100841b0000010001211cd3e4230b2bc47530e200447e998a38e960d4ed5f5251e26892130c000000320000000000000032000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
"qcTx": {
"version": 1,
"height": 7044,
"commitment": {
"version": 1,
"llmqType": 1,
"quorumHash": "0000000c139268e251525fedd460e9388a997e4400e23075c42b0b23e4d31c21",
"signersCount": 0,
"validMembersCount": 0,
"quorumPublicKey": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
},
"instantlock": false
}
```
****
## TxIn: A Transaction Input (Non-Coinbase)
Each non- [coinbase](../resources/glossary.md#coinbase) [input](../resources/glossary.md#input) spends an outpoint from a previous transaction. (Coinbase inputs are described separately after the example section below.)
| Bytes | Name | Data Type | Description
|----------|------------------|----------------------|--------------
| 36 | previous_output | [outpoint](../resources/glossary.md#outpoint) | The previous outpoint being spent. See description of outpoint below.
| *Varies* | script bytes | compactSize uint | The number of bytes in the signature script. Maximum is 10,000 bytes.
| *Varies* | signature script | char[] | A script-language script which satisfies the conditions placed in the outpoint's pubkey script. Should only contain data pushes; see the [signature script modification warning](../reference/transactions-opcodes.md#signature-script-modification).
| 4 | sequence | uint32_t | Sequence number. Default for Dash Core and almost all other programs is 0xffffffff.
****
## Outpoint: The Specific Part Of A Specific Output
Because a single transaction can include multiple [outputs](../resources/glossary.md#output), the [outpoint](../resources/glossary.md#outpoint) structure includes both a [TXID](../resources/glossary.md#transaction-identifiers) and an output index number to refer to specific output.
| Bytes | Name | Data Type | Description
|-------|-------|-----------|--------------
| 32 | hash | char[32] | The TXID of the transaction holding the output to spend. The TXID is a hash provided here in internal byte order.
| 4 | index | uint32_t | The output index number of the specific output to spend from the transaction. The first output is 0x00000000.
****
## TxOut: A Transaction Output
Each [output](../resources/glossary.md#output) spends a certain number of [duffs](../resources/glossary.md#duffs), placing them under control of anyone who can satisfy the provided [pubkey script](../resources/glossary.md#pubkey-script).
| Bytes | Name | Data Type | Description
|----------|-----------------|------------------|--------------
| 8 | value | int64_t | Number of duffs to spend. May be zero; the sum of all outputs may not exceed the sum of duffs previously spent to the outpoints provided in the input section. (Exception: coinbase transactions spend the block subsidy and collected transaction fees.)
| 1+ | pk_script bytes | compactSize uint | Number of bytes in the pubkey script. Maximum is 10,000 bytes.
| *Varies* | pk_script | char[] | Defines the conditions which must be satisfied to spend this output.
**Example**
The sample raw transaction itemized below is the one created in the [Simple Raw Transaction section](../examples/transaction-tutorial-simple-raw-transaction.md) of the Developer Examples. It spends a previous pay-to-pubkey output by paying to a new pay-to-pubkey-hash (P2PKH) output.
``` text
01000000 ................................... Version
01 ......................................... Number of inputs
|
| 7b1eabe0209b1fe794124575ef807057
| c77ada2138ae4fa8d6c4de0398a14f3f ......... Outpoint TXID
| 00000000 ................................. Outpoint index number: 0
|
| 49 ....................................... Bytes in sig. script: 73
| | 48 ..................................... Push 72 bytes as data
| | | 30450221008949f0cb400094ad2b5eb3
| | | 99d59d01c14d73d8fe6e96df1a7150de
| | | b388ab8935022079656090d7f6bac4c9
| | | a94e0aad311a4268e082a725f8aeae05
| | | 73fb12ff866a5f01 ..................... Secp256k1 signature
|
| ffffffff ................................. Sequence number: UINT32_MAX
01 ......................................... Number of outputs
| f0ca052a01000000 ......................... Duffs (49.99990000 Dash)
|
| 19 ....................................... Bytes in pubkey script: 25
| | 76 ..................................... OP_DUP
| | a9 ..................................... OP_HASH160
| | 14 ..................................... Push 20 bytes as data
| | | cbc20a7664f2f69e5355aa427045bc15
| | | e7c6c772 ............................. PubKey hash
| | 88 ..................................... OP_EQUALVERIFY
| | ac ..................................... OP_CHECKSIG
00000000 ................................... locktime: 0 (a block height)
```
****
## Coinbase Input: The Input Of The First Transaction In A Block
The first transaction in a [block](../resources/glossary.md#block), called the [coinbase transaction](../resources/glossary.md#coinbase-transaction), must have exactly one input, called a [coinbase](../resources/glossary.md#coinbase). The coinbase [input](../resources/glossary.md#input) currently has the following format.
| Bytes | Name | Data Type | Description
|----------|--------------------|----------------------|--------------
| 32 | hash (null) | char[32] | A 32-byte null, as a coinbase has no previous outpoint.
| 4 | index (UINT32_MAX) | uint32_t | 0xffffffff, as a coinbase has no previous outpoint.
| *Varies* | script bytes | compactSize uint | The number of bytes in the coinbase script, up to a maximum of 100 bytes.
| *Varies* (4) | height | script | The [block height](../resources/glossary.md#block-height) of this block as required by BIP34. Uses script language: starts with a data-pushing opcode that indicates how many bytes to push to the stack followed by the block height as a little-endian unsigned integer. This script must be as short as possible, otherwise it may be rejected.
The data-pushing opcode will be 0x03 and the total size four bytes until block 16,777,216 about 300 years from now.
| *Varies* | coinbase script | *None* | The [coinbase field](../resources/glossary.md#coinbase): Arbitrary data not exceeding 100 bytes minus the (4) height bytes. Miners commonly place an extra nonce in this field to update the block header merkle root during hashing.
| 4 | sequence | uint32_t | Sequence number.
Although the coinbase script is arbitrary data, if it includes the bytes used by any signature-checking operations such as [`OP_CHECKSIG`](../reference/transactions-opcodes.md), those signature checks will be counted as signature operations (sigops) towards the block's sigop limit. To avoid this, you can prefix all data with the appropriate push operation.
An itemized [coinbase transaction](../resources/glossary.md#coinbase-transaction):
``` text
01000000 .............................. Version
01 .................................... Number of inputs
| 00000000000000000000000000000000
| 00000000000000000000000000000000 ... Previous outpoint TXID
| ffffffff ............................ Previous outpoint index
|
| 18 .................................. Bytes in coinbase: 24
| |
| | 03 ................................ Bytes in height
| | | b8240b .......................... Height: 730296
| |
| | 03b8240b049d29aa59080400077efa95
| | 0000052f6d70682f .................. Arbitrary data
| 00000000 ............................ Sequence
02 .................................... Output count
| Transaction Output 1
| | f20cbe0a00000000 .................... Duffs (1.80227314 Dash)
| | 1976a9142cd46be3ceeacca983e0fea3
| | b88f26b08a26c29b88ac ................ P2PKH script
|
| Transaction Output 2
| | eb0cbe0a00000000 .................... Duffs (1.80227307 Dash)
| | 1976a914868180414905937a68fadeb0
| | f33e64d102c9591a88ac ................ P2PKH script
|
| 00000000 ............................ Locktime
```
Note: currently the normal coinbase has 2 outputs (1 for the [miner](../resources/glossary.md#miner) and 1 for the selected [masternode](../resources/glossary.md#masternode)). Superblocks ([superblock example](https://chainz.cryptoid.info/dash/block.dws?731104.htm)) have multiple outputs depending on the number of proposals being funded.