# Transactions
Tx type #Tx type name
1Genesis Transaction
4Transfer Transaction
8Lease Transaction
9Cancel Lease Transaction
11Mass Transfer Transaction
12Data Transaction
13Set Script Transaction
15Anchor Transaction
16Association Transaction
17Revoke Association Transaction
18Sponsor Transaction
19Cancel Sponsor Transaction
20Register Transaction
21Burn Transaction
22Mapped Anchor Transaction
23Statement Transaction
24Certificate Transaction
## Signing a transaction The process is as follows: create a binary message for signing, then create a signature using the private key. To validate a signature, the same binary message must be constructed. For this, the order of the fields matter, if you switch the order, the message will be different. The public key can be used for validation. {% hint style="info" %} The binary message differs for each transaction type. Please check the documentation. {% endhint %} ### Example Transaction data: | Field | Value | | ----------------------------------------------- | -------------------------------------------- | | Sender address (not used, just for information) | 3N9Q2sdkkhAnbR4XCveuRaSMLiVtvebZ3wp | | Private key (used for signing, not in tx data) | 7VLYNhmuvAo5Us4mNGxWpzhMSdSSdEbEPFUDKSnA6eBv | | Public key | EENPV1mRhUD9gSKbcWt84cqnfSGQP5LkCu5gMBfAanYH | | Recipient address | 3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8 | | Amount | 1 | | Fee | 1 | | Timestamp | 1479287120875 | | Attachment (as byte array) | \[1, 2, 3, 4] | Bytes: | # | Field name | Type | Position | Length | Value | Base58 bytes value | | - | ----------------------- | ----- | -------- | ------ | ------------- | -------------------------------------------- | | 1 | Transaction type (0x04) | Byte | 0 | 1 | 4 | 5 | | 2 | Sender's public key | Bytes | 1 | 32 | ... | EENPV1mRhUD9gSKbcWt84cqnfSGQP5LkCu5gMBfAanYH | | 3 | Timestamp | Long | 33 | 8 | 1479287120875 | 11frnYASv | | 4 | Amount | Long | 41 | 8 | 1 | 11111112 | | 5 | Fee | Long | 49 | 8 | 1 | 11111112 | | 6 | Recipient's address | Bytes | 57 | 26 | ... | 3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8 | | 7 | Attachment's length (N) | Short | 83 | 2 | 4 | 15 | | 8 | Attachment's bytes | Bytes | 85 | N | \[1,2,3,4] | 2VfUX | ***Total data bytes for sign:*** `Ht7FtLJBrnukwWtywum4o1PbQSNyDWMgb4nXR5ZkV78krj9qVt17jz74XYSrKSTQe6wXuPdt3aCvmnF5hfjhnd1gyij36hN1zSDaiDg3TFi7c7RbXTHDDUbRgGajXci8PJB3iJM1tZvh8AL5wD4o4DCo1VJoKk2PUWX3cUydB7brxWGUxC6mPxKMdXefXwHeB4khwugbvcsPgk8F6YB` ***Signature of transaction data bytes*** **(one of an infinite number of valid signatures):** `2mQvQFLQYJBe9ezj7YnAQFq7k9MxZstkrbcSKpLzv7vTxUfnbvWMUyyhJAc1u3vhkLqzQphKDecHcutUrhrHt22D` ***Total transaction bytes with signature:*** `6zY3LYmrh981Qbzj7SRLQ2FP9EmXFpUTX9cA7bD5b7VSGmtoWxfpCrP4y5NPGou7XDYHx5oASPsUzB92aj3623SUpvc1xaaPjfLn6dCPVEa6SPjTbwvmDwMT8UVoAfdMwb7t4okLcURcZCFugf2Wc9tBGbVu7mgznLGLxooYiJmRQSeAACN8jYZVnUuXv4V7jrDJVXTFNCz1mYevnpA5RXAoehPRXKiBPJLnvVmV2Wae2TCNvweHGgknioZU6ZaixSCxM1YzY24Prv9qThszohojaWq4cRuRHwMAA5VUBvUs` ### Key type By default, transactions are signed using the ED25519 algorithm. However, LTO supports multiple algorithms and curves like secp256k1, NIST P-256, and RSA. When broadcasting a transaction, it's required to include the [key type](https://docs.ltonetwork.com/accounts#key-types) in addition to the sender's public key. {% hint style="warning" %} RSA public keys are too large to store for each request. For RSA, the sender public key field must contain the SHA256 hash of the public key. This means that the transaction can't be validated by itself. RSA is only available through a [smart account](https://docs.ltonetwork.com/protocol/public/transactions/set-script) or by publishing an X.509 certificate to the public chain. {% endhint %} ### Proofs Proofs are a flexible way to authorize a transaction. Each proof is a Base58 encoded byte string and can be a signature, a secret, or anything else – the semantics of the proof is dictated by the smart contract that interprets it. There can be up to 8 proofs at most 64 bytes each. By default, only one proof is used, which must be the transaction signature by the sender. It should be the very first element in the proofs array, while all the other elements are ignored. The JSON looks like `"proofs": [ "21jgWvYq6XZuke2bLE8bQEbdXJEk..." ]` ## Transaction id The transaction id is not stored in the transaction bytes. It's calculated from the binary message for signing as `blake2b256(binary_message)`. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ltonetwork.com/protocol/public/transactions.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.