LTO Network
  • Getting started
  • What is LTO Network?
  • Tutorials
    • Buying and staking LTO
      • Exchanges
        • Binance
        • AscendEX (Bitmax)
        • Uniswap
        • PancakeSwap
        • Other exchanges
      • Creating your LTO web wallet
      • Using the LTO token bridge
      • Staking LTO tokens
    • Mining
      • Setup your node wallets
      • Node management
      • Public community nodes
    • Anchoring
      • Hashing
    • LetsFlow
  • Wallets
    • LTO Web Wallet
      • Using Ledger
    • Universal Wallet
    • LTO CLI
    • Third-Party Wallets
      • Stakely.io wallet
        • Web wallet
        • Commandline
    • ERC20 Token Swap
  • Running a node
    • Public node
      • Installation Guide
        • Mainnet & Testnet
        • Requirements
        • Configuration
        • (Virtual) Machine
        • Nginx reverse proxy (optional)
        • Troubleshooting FAQ
      • Cloud installation
        • Alibaba Cloud
        • AWS Elastic Beanstalk
        • Google Cloud
        • IBM Cloud
        • Microsoft Azure
        • OKD (OpenShift)
        • Raspberry Pi (Expert)
        • Ubuntu Linux with Container
        • Windows with Container
      • REST API
        • Address
        • Wallet
        • Lease Transactions
        • Peers
        • Blocks
        • Utils
        • FAQ
      • Security Notes
      • FAQ
      • Exchange integration guide
    • Anchor node
      • Installation Guide
        • Linux
        • MacOS
        • Windows
      • REST API
    • Identity node
      • Installation guide
        • Linux
        • MacOs
        • Windows
      • Configuration
        • Trust network
      • REST API
    • Workflow node
      • Installation Guide
        • MacOS
        • Windows
        • Ubuntu Linux
      • REST API
  • Ownables
    • What are Ownables?
    • Making your first ownable
    • Ownables SDK
      • Prerequisites
      • Setup
    • Ownables Architecture
      • Smart Contract
      • Widget
    • Ownables Bridge
  • Templates Overview
  • Libraries
    • JavaScript
      • Accounts
      • Transactions
      • Event chain
      • Messages
      • Identities
      • HTTP Authentication
    • Python
      • Accounts
      • Public layer
    • PHP
      • Accounts
      • Identities
      • Public layer
      • Private layer
      • HTTP Authentication
      • Commandline scripts
    • Java
  • Protocol
    • Cryptography
    • Accounts
      • ED25519
      • secp256k1
      • secp256r1
    • Identities
      • Decentralized identifiers (DID)
      • Trust network
      • Verifiable credentials
    • Public layer
      • Transactions
        • Transfer
        • Lease
        • Cancel Lease
        • Mass Transfer
        • Set Script
        • Data
        • Anchor
        • Association
        • Revoke Association
        • Sponsorship
        • Cancel Sponsorship
        • Register
        • Burn
        • Mapped Anchor
        • Statement
        • Certificate
      • Transaction fees
      • Consensus protocol
      • Activation Protocol
      • Data Structures
    • Private layer
      • Event chain
        • Event
      • Messaging
        • Sending messages
Powered by GitBook
On this page
  • Signing a transaction
  • Example
  • Key type
  • Proofs
  • Transaction id
  1. Protocol
  2. Public layer

Transactions

Tx type #
Tx type name

1

Genesis Transaction

4

8

9

11

12

13

15

16

17

18

19

20

21

22

23

24

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.

The binary message differs for each transaction type. Please check the documentation.

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

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).

PreviousPublic layerNextTransfer

Last updated 12 days ago

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 in addition to the sender's public key.

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 or by publishing an X.509 certificate to the public chain.

key type
smart account
Transfer Transaction
Lease Transaction
Cancel Lease Transaction
Mass Transfer Transaction
Data Transaction
Set Script Transaction
Anchor Transaction
Association Transaction
Revoke Association Transaction
Sponsor Transaction
Cancel Sponsor Transaction
Register Transaction
Burn Transaction
Mapped Anchor Transaction
Statement Transaction
Certificate Transaction