The fundamental data structures and building blocks present on the Diamante network.
A ledger in the Diamante network represents the state of the Diamante network at a specific point in time. It is shared across all Core nodes in the network and contains information about accounts and balances, orders on the distributed exchange, operations data, and any other persisting data.
In other blockchains, this concept is often referred to as a "block", and the entire blockchain is sometimes called "the ledger".
In every Diamante Consensus Protocol round, the network reaches consensus on which transaction set to apply to the last closed ledger. When the new set is applied, a new "last closed ledger" is defined. Each ledger is cryptographically linked to the unique previous ledger, creating a historical chain that goes back to the genesis ledger.
Data within the ledger is stored as ledger entries. Possible ledger entries in Diamante include:
Every ledger has a ledger header. To learn more about what is contained in the ledger header, refer to our, Encyclopedia-> Ledger Header.
Accounts are a fundamental data structure in the Diamante network, responsible for holding balances, signing transactions, and issuing assets. An account can only exist with a valid keypair and must maintain the required minimum balance of DIAM (Diamante's native cryptocurrency). For information regarding minimum balance requirements, refer to the Diamante Diams Section.
A base reserve is a unit of measurement used to calculate an account’s minimum balance in Diamante. Currently, one base reserve is equivalent to 0.0000002 DIAM.
Account data is organized in subentries, where each subentry incrementally increases the account’s minimum balance by one base reserve (0.0000002 DIAM). An account is limited to a maximum of 1,000 subentries. Possible subentries include:
Trustlines are an explicit opt-in for an account to hold and trade a specific asset in Diamante. To hold a particular asset, an account must establish a trustline with the issuing account using the change_trust operation. Trustlines track the balance of an asset and can also impose limits on the amount of an asset that an account can hold.
For an account to receive any asset except the native DIAM, a trustline must be established. While you can create a claimable balance to send assets to an account without a trustline, the recipient must create a trustline to claim that balance. Refer to the Claimable Balances Encyclopedia Entry for more information.
Trustlines also track liabilities, including buying liabilities and selling liabilities. An account's trustline must always have a balance sufficiently large to satisfy its selling liabilities and a balance sufficiently below its limit to accommodate its buying liabilities.
Assets are a core concept in the Diamnet blockchain, where assets can represent a wide range of values. These assets can be cryptocurrencies, fiat currencies, tokens (such as NFTs), pool shares, bonds, equity, and many more. In Diamante, assets provide a way to model various types of value or ownership within the network.
Assets on Diamante have two primary identifying characteristics: the asset code and the issuer. Since multiple organizations can issue a credit representing the same asset, asset codes often overlap. Assets are uniquely identified by the combination of their asset code and issuer.
These characteristics are critical when performing transactions or interacting with assets on the Diamnet blockchain.
The process of Naming an Asset in Diamante is a critical step when issuing an asset, and the format of the asset code is an essential aspect to understand. Let me break down the different naming conventions and formats:
When creating an asset on Diamante, you must decide on an asset code. This code will uniquely identify the asset in the Diamante blockchain and is an important part of the asset’s structure.
There are three main formats for naming an asset:
Assets in Diamante are composed of the following key components:
In aurora, assets are represented in a JSON object:
{
asset_code: "DiamanteToken",
asset_issuer: "GC2BKLYOOYPDEFJKLKY6FNNRQMGFLVHJKQRGNSSRRGSMPGF32LHCQVGF",
// `asset_type` is used to determine how asset data is stored.
// It can be `native` (Diams), `credit_alphanum4`, or `credit_alphanum12`.
asset_type: "credit_alphanum12",
}
Each asset amount is encoded as a signed 64-bit integer in the XDR structures used by Diamante to encode transactions. The asset amount unit seen by end-users is scaled down by a factor of ten million (10,000,000) to arrive at the native 64-bit integer representation.
For example, the integer amount value 25,123,456 equals 2.5123456 units of the asset. This scaling allows for seven decimal places of precision in human-friendly amount units.
The smallest non-zero amount unit, also known as a jot, is 0.0000001 (one ten-millionth) represented as an integer value of one. The largest amount unit possible is 922,337,203,685.4775807.
Relevance in aurora and Diamante Client Libraries
In aurora and client-side libraries such as js-diamante-sdk, the integer encoded value is abstracted away. Many APIs expect an amount in unit value (the scaled-up amount displayed to end-users). Some programming languages (such as go) have problems maintaining precision on a number amount. It is recommended to use "big number" libraries that can record arbitrary-precision decimal numbers without a loss of precision.
To perform actions with an account on the Diamante network, you compose operations, bundle them into a transaction, and then sign and submit the transaction to the network. We can perform (1 - 100) operations per transaction.
Operations are individual commands that modify the ledger. Operations are used to send payments , enter orders into the decentralized exchange, change settings on accounts, and authorize accounts to hold assets.
All operations fall into one of three threshold categories: low, medium, or high, and each threshold category has a weight between 0 and 255 (which can be determined using set_options). Thresholds determine what signature weight is required for the operation to be accepted. For example, let’s say an account sets the medium threshold weight to 5. If the account wants to successfully establish a trustline with the changeTrust operation, the weight of the signature(s) must be greater than or equal to 5.
To learn more about signature weight, see the Signature and Multisignature Encyclopedia Entry.
View a comprehensive list of Diamante operations and their threshold levels in the List of Operations section.
The Diamante network encodes transactions using a standardized protocol called External Data Representation (XDR). You can read more about this in our XDR Encyclopedia Entry.
Accounts can only perform one transaction at a time. Transactions comprise a bundle of between 1-100 operations and are signed and submitted to the ledger by accounts. Transactions always need to be authorized by the source account’s public key to be valid, which involves signing the transaction object with the public key’s associated private key.
secret key. A transaction plus its signature(s) is called a transaction envelope.
A transaction may need more than one signature- this happens if it has operations that affect more than one account or if it has a high threshold weight. Check out the Signature and Multisignature Encyclopedia Entry for more information.
Transactions are atomic: meaning if one operation in a transaction fails, all operations fail, and the entire transaction is not applied to the ledger.
Operations are executed for the source account of the transaction unless an operation override is defined.
Before being successfully submitted to the Diamante network, transactions go through several validity checks. These checks are grouped into three categories:
Preconditions (Optional)
Valid if within set time bounds of the transaction
Time bounds are an optional UNIX timestamp (in seconds), determined by ledger time, of a lower and upper bound of when a transaction will be valid. If a transaction is submitted too early or too late, it will fail to make it into the transaction set. Setting time bounds on transactions is highly encouraged, and many SDKs enforce them.
If maxTime is 0, upper time bounds are not set. In this case, if a transaction does not make it to the transaction set, it is kept in memory and continuously tries to make it to the next transaction set. Because of this, we advise that all transactions are created with time bounds to invalidate transactions after a certain amount of time, especially if you plan to resubmit your transaction at a later time.
Valid if within set ledger bounds of the transaction
Ledger bounds apply to ledger numbers. With these defined, a transaction will only be valid for ledger numbers that fall within the determined range.
If a minimum sequence number is set, the transaction will only be valid when its source account’s sequence number (call it S) is large enough. Specifically, it’s valid when S satisfies minSeqNum <= S < tx_seqNum.
If this precondition is omitted, the default behaviour applies: the transaction’s sequence number must be exactly one greater than the account’s sequence number.
Transaction is valid after a particular duration (expressed in seconds) elapses since the account’s sequence number’s age.
Valid if submitted in a ledger meeting or exceeding the source account’s sequence number age
Valid if submitted with signatures that fulfill each of the extra signers
When a transaction is submitted to a node, the node checks the validity of each operation in the transaction before attempting to include it in a candidate transaction set. These initial operation validity checks are intended to be fast and simple, with more intensive checks coming after the fees have been consumed.
For an operation to pass this validity check, it has to meet the following conditions:
Finally, the following transaction checks take place:
© 2025 Diamante Financial Technologies. All Rights Reserved.