Burn - LTO Network

Search…
Burn
Burn LTO. Annnnd it's gone...
The Burn transaction isn't available on mainnet yet. It requires the Juicy feature vote to be activated.
JSON
1
{
2
  "type": 21,
3
  "version": 3,
4
  "id": "8M6dgn85eh3bsHrVhWng8FNaHBcHEJD4MPZ5ZzCciyon",
5
  "sender": "3Jq8mnhRquuXCiFUwTLZFVSzmQt3Fu6F7HQ",
6
  "senderKeyType": "ed25519",
7
  "senderPublicKey": "AJVNfYjTvDD2GWKPejHbKPLxdvwXjAnhJzo6KCv17nne",
8
  "fee": 100000000,
9
  "timestamp": 1647870282634,
10
  "amount": 100000000000,
11
  "proofs": [
12
    "49Y3FhLkE8gy7ryWZbxMgs2oWzkjE6qSj7cH1p9rmpnsMd1mMgTg9NynERLdtgWDiq57sDwr4gNUJoP9qYzidRPR"
13
  ]
14
}
Copied!
id and height should be omitted when broadcasting. These fields are set by the node.
Binary strings are base58 encoded.
timestamp is in microseconds since epoch.
fee includes 8 digits, so LTO * 10^8
Binary schema
The binary data structure of the unsigned transaction.
V3 (current)
#
Field Name
Type
Length
1
Transaction type
Byte (constant, value=21)
1
2
Version
Byte (constant, value=3)
1
3
Chain id
Byte
1
4
Timestamp
Long
8
5
Sender's key type
KeyType (Byte)
1
6
Sender's public key
PublicKey (Array[Byte])
32 | 33
7
Fee
Long
8
8
Amount
Long
8
...
​
​
​
​
Chain id can be obtained by taking the 2nd byte from the sender address.
Each key type has a numeric id in addition to the reference from the JSON.
Integers (short, int, long) have a big endian byte order.
Consensus protocol
Last modified 1mo ago
Copy link
Contents
JSON
Binary schema