Intermedio

Resumen

DecentralChain es un protocolo blockchain abierto y un conjunto de herramientas de desarrollo para aplicaciones Web \(3.0\) y soluciones descentralizadas. Blockchain es una tecnología de registros distribuidos que garantiza la inmutabilidad y la transparencia de los datos.

Cuentas

DecentralChain utiliza un modelo basado en cuentas. Cada transacción se crea en nombre de una cuenta, todos los activos y datos están asociados a una cuenta. Una cuenta tiene un par de claves vinculadas criptográficamente: una clave privada que la cuenta utiliza para firmar las transacciones, y una clave pública que permite a cualquiera verificar la firma. Más información sobre las cuentas.

Para crear una cuenta, almacenar claves y firmar transacciones, puede utilizar Decentral.Exchange.

_images/01_Accounts.png

Transacciones y bloques

Los datos de Blockchain se presentan como transacciones. Una transacción es un registro de una acción, como una emisión de tokens, una transferencia de criptomoneda, la creación o invocación de un contrato inteligente, etc. Más información sobre las transacciones.

Las transacciones se apilan en bloques. Además de las transacciones, cada bloque también contiene el hash del bloque anterior y la firma digital del nodo que generó el bloque. El bloque anterior contiene el hash de datos de su bloque precedente, y así sucesivamente. Como resultado, la firma de cada bloque depende de los datos de todos los bloques precedentes. Más información sobre los bloques.

En otras palabras, la cadena de bloques es una secuencia de bloques vinculados por hashes criptográficos. Cada transacción permanece intacta indefinidamente. Un intento de cambiar cualquier dato de un bloque invalidaría el bloque y todos los bloques posteriores.

_images/02_Transactions-and-Blocks.png

Nodos

Un nodo es un ordenador que sirve a la red blockchain. Los nodos de DecentralChain almacenan una copia completa de los datos de la cadena de bloques, validan las transacciones y los bloques, verifican las firmas y los hashes, y sincronizan los datos con otros nodos.

La red DecentralChain está formada por nodos alojados en todo el mundo. Esto garantiza que los datos de la cadena de bloques están protegidos contra la falsificación o el borrado, ya sea malicioso o accidental. Todo el mundo puede lanzar un nodo y unirse a la red. Los nodos que posean al menos \(1,0000\) DecentralCoins (por propiedad o arrendamiento), pueden participar en la generación de bloques para recibir recompensas por generación de bloques y comisiones por transacciones. Cuantos más tokens tenga el nodo, mayor será su posibilidad de añadir el siguiente bloque. Más información sobre los nodos.

dApps

Una aplicación descentralizada (dApp) es una aplicación potenciada por la cadena de bloques. Una dApp puede almacenar datos en la blockchain e invocar un script asignado a una cuenta. Por lo tanto, no hay una base de datos centralizada que pueda ser hackeada o comprometida. Cualquier usuario puede ver el código del script y el resultado de su invocación. Más información sobre las dApps.

Cuenta

DecentralChain utiliza un modelo basado en cuentas:

Claves de la Cuenta

A diferencia de las aplicaciones centralizadas, los usuarios no tienen nombres de usuario ni contraseñas en la cadena de bloques. La identificación del usuario y la validación de sus acciones se realizan mediante un par de claves vinculadas criptográficamente:

  • La clave privada se utiliza para firmar transacciones u órdenes.

  • La clave pública permite la verificación de la firma digital.

Cada transacción contiene la clave pública de la cuenta del remitente. El remitente genera una firma digital de la transacción utilizando la clave privada de la cuenta. La firma y la clave pública del remitente se utilizan para verificar la autenticidad de los datos de la transacción y para comprobar que la firma de la transacción coincide con la clave pública.

_images/03_Account-Keys.png

DecentralChain utiliza un sistema criptográfico asimétrico basado en la curva elíptica Curve25519-ED25519 con claves X25519.La pauta para la generación de claves y firmas se da en el artículo detalles prácticos criptográficos. Las claves privadas y públicas son matrices de \(32\) bytes. En las interfaces de usuario, las claves se muestran como cadenas codificadas en base58. Las claves codificadas en base58 pueden tener diferentes longitudes, la longitud máxima es de \(44\) caracteres.

Ejemplo de clave privada en base58:

6yCStrsBs4VgTmYcSgF37pmQhCo6t9LZk5bQqUyUNSAs

Ejemplo de clave pública en base58:

5cqzmxsmFPBHm4tb7D8DMA7s5eutLXTDnnNMQKy2AYxh

Frase Secreta (semilla)

La clave privada puede generarse a partir de alguna frase semilla aleatoria utilizando funciones de hashing. La clave pública se obtiene a partir de la clave privada utilizando una multiplicación de curva elíptica. La dirección de la cuenta se obtiene a partir de la clave pública. Todas estas transformaciones son unidireccionales. La dirección opuesta es casi imposible en términos de los cálculos requeridos.

_images/04_Secret-(Seed)-Phrase.png

La frase secreta (también conocida como frase semilla o frase de respaldo) puede ser cualquier combinación de símbolos, palabras o bytes. Las billeteras ofrecidas por DecentralChain suelen utilizar un conjunto aleatorio de \(15\) palabras en inglés de entre las \(2048\) palabras disponibles. El uso de una frase de este tipo es seguro ya que la probabilidad de generar dos frases semilla idénticas es \(\frac{1}{2048^{15}}\), por lo que la fuerza bruta tardaría millones de años en una CPU promedio. El objetivo de utilizar una frase secreta (en lugar de una clave privada) es simplificar la experiencia del usuario: la frase secreta es mucho más fácil de escribir o recordar.

Ejemplo de frase secreta:

body key praise enter toss road cup result shrimp bus blame typical sphere pottery claim

Información de seguridad:

  • La frase secreta o la clave privada derivada de esta proporcionan un control total sobre la cuenta, incluida la capacidad de disponer de los fondos. No dé su frase secreta ni su clave privada a nadie, y no las publique ni las envíe.

  • La frase secreta no puede cambiarse: otra frase secreta (incluso una que difiera en un solo carácter) generará un par de claves diferente y, por tanto, una cuenta diferente.

  • Si pierde su frase secreta o su clave privada, no podrá volver a acceder a su cuenta. Le recomendamos encarecidamente que haga una copia de seguridad de su frase secreta <02_intermediate:Backup Seed Phrase>`.

  • Si la frase secreta está comprometida (la has enviado accidentalmente a alguien o sospechas que ha sido tomada por estafadores), crea inmediatamente una nueva cuenta y transfiere todos los activos a ella.

Para conocer la forma de generar las claves de la cuenta, consulte el artículo crear una cuenta.

Crear una Cuenta

Crear una cuenta significa generar un par de claves de cuenta y una dirección address basada en una frase frase secreta (semilla).

Se puede utilizar Decentral.Exchange en línea para crear una cuenta.

  • En la pantalla principal haga clic en Crear Cuenta, luego en la casilla Crear Contraseña escriba la contraseña, vuelva a escribirla en la casilla Confirmar Contraseña, acepte los Términos y Condiciones así como la Política de Privacidad y haga clic en Continuar.

  • En la siguiente pantalla selecciona Crear Cuenta y luego elige el avatar que más te guste para tu cuenta y haz clic en Continuar.

  • Luego de esto, selecciona el nombre que quieres que tenga la cuenta en ese dispositivo concreto y haz clic en Continuar.

  • En este punto se le remitirá a la página de su cartera. Debes hacer un respaldo de tu frase semilla.

Respaldar Frase Semilla

  • Abra la pantalla principal de Decentral.Exchange y asegúrese de haber iniciado sesión en su cuenta. Haga clic en el avatar de la cuenta y navegue hasta Configuración > Seguridad.

  • Haga clic en Mostrar en el cuadro de Respaldar Frase Semilla.

  • Anote la frase y guárdela en un lugar seguro.

No almacene la frase de respaldo sin encriptar en ningún dispositivo electrónico. Recomendamos encarecidamente hacer una copia de seguridad de la frase semilla, ya que es la única manera de restaurar el acceso a su cuenta en caso de pérdida o robo del dispositivo.

Acceder a la Cuenta

  • Abra la pantalla principal de Decentral.Exchange y haga clic en Crear Cuenta, luego en la casilla Crear Contraseña escriba la contraseña, vuelva a escribirla en la casilla Confirmar Contraseña, acepte los Términos y Condiciones así como la Política de Privacidad y haga clic en Continuar.

  • En la siguiente pantalla, seleccione Importar Cuentas y, a continuación, elija la opción Semilla o Clave.

  • A continuación, escribe la semilla de la que hiciste una copia de seguridad en el pasado y haz clic en Continuar, luego selecciona el nombre que quieres que tenga la cuenta en ese dispositivo en particular y haz clic en Continuar.

  • En este punto, se le remitirá a la página de su monedero.

Olvidé mi Contraseña

  • Abra la pantalla principal de Decentral.Exchange y haga clic en Olvidé mi Contraseña y luego seleccione la opción Restablecer Todo.

  • En la siguiente pantalla, en la casilla Crear Contraseña escriba la contraseña, vuelva a escribirla en la casilla Confirmar Contraseña, acepte los Términos y Condiciones así como la Política de Privacidad y haga clic en Continuar.

  • Una vez hecho esto, seleccione Importar Cuentas y, a continuación, elija la opción Semilla o Clave.

  • A continuación, escribe la semilla de la que hiciste una copia de seguridad en el pasado y haz clic en Continuar, luego selecciona el nombre que quieres que tenga la cuenta en ese dispositivo en particular y haz clic en Continuar.

  • En este punto, se le remitirá a la página de su monedero.

Dirección

La dirección es un atributo de la cuenta derivado de la clave pública. La dirección también contiene el chain ID que identifica la red blockchain, por lo que la dirección en la Mainnet no puede ser utilizada en la Testnet y viceversa.

La dirección es una matriz de \(26\) bytes (ver formato binario de la dirección). En las UIs la dirección se muestra como una cadena codificada en base58.

3PDfnPknnYrg2k2HMvkNLDb3Y1tDTtEnp9X

Normalmente, la dirección que empieza por 3P se refiere a la Mainnet, y la que empieza por 3M o 3N se refiere a Testnet o Stagenet.

La dirección se utiliza para obtener información sobre la cuenta:

La dirección es indicada:

Obtener Dirección Personal

  • Abra la pantalla principal de Decentral.Exchange y asegúrese de haber iniciado sesión en su cuenta. Haga clic en el avatar de la cuenta y navegue hasta Dirección.

  • Copie la dirección y utilícela, o también puede utilizar el código QR generado.

Alias

El alias es un nombre corto, fácil de recordar, de la dirección. El alias es único en el blockchain. Una dirección puede tener varios alias. El alias puede utilizarse en lugar de la dirección:

El alias no puede ser eliminado.

Requisitos del Alias

La longitud de un alias puede ser de \(4\) a \(30\) bytes (el carácter \(1\) puede ocupar hasta \(4\) bytes). Se permiten los siguientes caracteres:

  • letras latinas minúsculas

  • números

  • punto

  • subrayado

  • guión

  • @

Crear Alias

Puede utilizar Decentral.Exchange en línea para crear un alias.

  • Asegúrese de que está conectado a su cuenta. En la pantalla principal, haga clic en el avatar de la cuenta y navegue hasta Aliases.

  • En la siguiente pantalla, seleccione Crear Nuevo y, a continuación, escriba el nombre del alias y vuelva a hacer clic en Crear Nuevo para completar el proceso.

Ver Aliases

La lista de aliases de la cuenta, así como otros datos de la cadena de bloques, son pública y puede ser leídos por cualquiera. Por ejemplo, puede ver los alias en DecentralChain Explorer. Para ello, busque una cuenta por su dirección y cambie a la pestaña Aliases.

Utilizando Node REST API, puede obtener una lista de alias por dirección utilizando el método GET/alias/by-address/{address} y una dirección por alias utilizando el método GET /alias/by-alias/{alias}.

Formato Binario

Consulte el artículo del formato binario de alias.

Saldo de la Cuenta

El saldo de la cuenta es el monto de un token (activo) que pertenece a la cuenta.

Una cuenta puede almacenar diferentes tokens en diferentes cantidades. Por ejemplo, una cuenta puede tener \(50\) DecentralCoins y USD-N al mismo tiempo. La cantidad del token Y en la cuenta se denomina saldo de la cuenta en token Y. Si no hay ningún token Y en la cuenta, se dice que el saldo de la cuenta en el token Y es igual a cero.

Saldo de la Cuenta en DecentralCoin

Hay cuatro tipos de saldos en DecentralChain:

  • regular

  • disponible

  • efectivo

  • generando

El saldo regular es el monto de DecentralCoins que pertenece directamente a la cuenta. Los otros tipos de saldos se determinan contando los DecentralCoins arrendados .

Introduzcamos la siguiente notación:

R is the regular balance,
Lo is the amount of DecentralCoins which the account leased to other accounts,
Li is the amount of DecentralCoins which are leased to the account by other accounts.

Entonces:

Available balance = R – Lo
Effective balance = R – Lo + Li
Generating balance is the minimum value of the effective balance during the last 1000 blocks.

El saldo generador de la cuenta asociada a un nodo afecta a la capacidad de participar en la generación de bloques. Para generar bloques, se necesita un saldo generador de al menos \(10000\) DecentralCoins. Cuanto mayor sea el saldo generador, mayor será la posibilidad de añadir el siguiente bloque.

Ver el Saldo de la Cuenta

Los saldos de cualquier cuenta, así como otros datos de la cadena de bloques, son públicos y pueden ser leídos por cualquiera.

Por ejemplo, puede ver la lista de tokens y su monto en la cuenta en DecentralChain Explorer. Para ello, busque una cuenta por su dirección o su alias. Los saldos en DecentralCoin se muestran justo debajo de la dirección, los saldos en otros activos se encuentran en la pestaña Activos, y los tokens no fungibles (NFT) se encuentran en la pestaña Tokens no fungibles.

_images/05_View-Account-Balance.png

Recarga de Saldo

Puedes comprar DecentralCoins en Decentral.Exchange.

Almacenamiento de Datos de la Cuenta

El almacenamiento de datos de la cuenta es un almacenamiento clave-valor asociado a una cuenta. La clave de cada entrada es una cadena única. El valor es el dato que se almacena, se almacena utilizando uno estos dos tipos:

  • Cadena de caracteres

  • Booleano

  • Entero

  • Matriz de bytes

El tamaño del almacenamiento de datos de una cuenta es ilimitado. Para conocer las limitaciones de tamaño de las claves y los valores, consulte el artículo transacción de datos.

Ver Datos de la Cuenta

Los datos almacenados de cualquier cuenta, así como otros datos de la cadena de bloques, son públicos y pueden ser leídos por cualquiera. Por ejemplo, pueden verse las entradas de datos en DecentralChain Explorer. Para ello, busque una cuenta por su dirección o alias y cambie a la pestaña Datos.

_images/06_View-Account-Data.png

Añadir, Modificar y Eliminar Entradas

El propietario de la cuenta puede añadir, modificar o eliminar entradas del almacenamiento de datos de la cuenta a través de una transacción de datos.

A dApp script can add, modify or delete entries in the dApp’s data storage as a result of an invoke script transaction via script actions:

dApp y Cuenta Inteligente

Una cuenta con un script asignado se convierte en una dApp o cuenta inteligente. dApp es la cuenta con el script dApp asignado. dApp es una aplicación cuyas funciones pueden ser llamadas desde otras cuentas a través de transacciones de invocar scripts. Las funciones invocables pueden aceptar pagos a la dApp y también realizar acciones aplicadas a la blockchain:

  • Añadir, modificar o eliminar entradas del almacenamiento de datos de la cuenta dApp.

  • Transferir tokens del saldo de la dApp.

  • Emitir, reemitir, quemar tokens en nombre de la dApp, configuración del patrocinio.

Además, un script dApp puede incluir la función verificadora que permite o deniega las transacciones y órdenes que se envían en nombre de la cuenta dApp con base en las condiciones especificadas. La función verificadora sustituye a la verificación por defecto que se utiliza para verificar la firma del remitente y permite establecer reglas más complejas, como la multifirma.

Mediante las dApps, se pueden implementar diversas aplicaciones potenciadas por blockchain: juegos de azar y apuestas, DeFi, identidad digital, cadenas de suministro y muchas otras.

Una cuenta inteligente es una cuenta con el script de cuenta asignado. El script de cuenta es similar a la función de verificación de un script de dApp. Tenga en cuenta:

  • Para asignar un script a una cuenta, tienes que enviar una transacción para asignar scripts en nombre de la cuenta.

  • También se puede modificar o eliminar el script a través de la transacción para asignar scripts, a menos que el propio script lo prohíba.

  • La tarifa mínima para cualquier transacción enviada desde una dApp o cuenta inteligente se incrementa en \(0.004\) DecentralCoins si la complejidad del script de la cuenta del remitente o de la función verificadora del script de la dApp supera el límite de complejidad del remitente.

Token (Activo)

Un token representa un activo digital en la cadena de bloques. Un token puede ser utilizado:

  • Como criptomoneda para pagar bienes y servicios dentro de un proyecto, así como para el financiamiento colectivo;

  • Como objeto o recurso en los juegos, etc.

Un token puede representar un objeto físico o intangible. Las palabras «token» y «activo» se utilizan indistintamente en el ecosistema DecentralChain. DecentralCoin es el token nativo en la blockchain de DecentralChain. Más sobre DecentralCoin.

Todos los demás tokens son fichas personalizadas emitidas en nombre de alguna cuenta. Cualquier cuenta que tenga suficientes DecentralCoins para pagar la cuota puede emitir su propio token. El nuevo token está disponible inmediatamente:

Emisión de Tokens

Puede utilizar Decentral.Exchange en línea para crear un activo.

  • En la pantalla principal, asegúrese de haber iniciado sesión en su cuenta y, a continuación, haga clic en Crear Token.

  • En la siguiente pantalla especifique los parámetros del token:

    • Nombre: El nombre del activo creado no puede ser más corto que \(4\) caracteres.

    • Descripción: Una breve descripción en la que puedes incluir enlaces a sitios web que puedan ser especialmente útiles.

    • Cantidad: Defina la oferta total de su activo. La oferta total puede fijarse en el momento de la emisión o aumentarse posteriormente haciendo que el activo sea reemitible.

    • Reeditable: Define si la oferta total del activo puede ser aumentada posteriormente. Si se establece como reemitible, el emisor puede aumentar el suministro en cualquier momento (Si se selecciona reemitible cuando se crea el activo, se puede cambiar a no reemitible en una etapa posterior).

    • Decimales: Especifique cuántos decimales tendrá su activo. Por ejemplo, si especifica \(8\) decimales, como en el caso de Bitcoin, su activo puede dividirse hasta \(0.00000001\).

    • Activo inteligente: Un activo inteligente es un activo con un script adjunto que pone condiciones a cada transacción realizada para el activo en cuestión.

    • Script (para emitir un activo inteligente).

  • Antes de crear un nuevo activo, lea atentamente las condiciones de creación. Si es necesario, cambie el nombre del activo de acuerdo con las condiciones, luego seleccione la casilla Entiendo… y haga clic en Generar.

  • En la siguiente pantalla vuelva a comprobar los datos introducidos y si todo es correcto haga clic en Enviar para finalizar la creación o en Volver para hacer correcciones..

La cuota de transacción es \(1\) DecentralCoin para un token normal o \(0,001\) DecentralCoins para un token no fungible (NFT). Además, el token puede ser emitido por el dApp script como resultado de transacciones de invocar scripts cuando el resultado de la función invocable contiene la acción emitir. La tarifa mínima para invocar una transacción de script se incrementa en \(1\) DecentralCoin por cada token no NFT emitido.

Id del Token

El ID del token es una matriz de bytes calculada de la siguiente forma:

  • Si el token es emitido por emitir transacción, el ID del token es el mismo que el de la transacción.

  • Si el token es emitido por transacciones de invocar scripts cuando la función invocable del dApp script realizó la acción emitir, el ID del token se calcula como el hash BLAKE2b-256 de la matriz de bytes que contiene el ID de la transacción y los campos de la estructura resultante de dicha emisión.

En la API REST de Node, el identificador del token se codifica en base58. Por ejemplo:

"assetId": "8LQW8f7P5d5PZM7GtZEBgaqRPGSzS3DfPuiXrURJ4AJS"

El token DecentralCoin no tiene identificador. La API REST de Node utiliza null para DecentralCoin.

Operaciones con Tokens

  • Transferencia a otra cuenta

Se puede hacer mediante transferencias o transferencias en masa. Un dApp script puede transferir el token a través de una acción de transferencia de script como resultado de transacciones de invocar scripts.

  • Intercambio (Acuerdo Comercial)

Tres cuentas pueden participar en el intercambio: un usuario crea una orden para comprar un token, el otro crea una orden para vender un token. El comparador combina las órdenes de compra y venta con los parámetros adecuados y crea una transacción de intercambio.

  • Quema

Disminuye la cantidad de tokens en la cuenta y, por tanto, la cantidad total de tokens en la blockchain. Cualquier propietario de un token puede quemarlo, no sólo el emisor. Es imposible quemar DecentralCoin. Se puede hacer a través de una transacción de quemado. Un dApp script puede quemar el token a través de una acción quemar como resultado de transacciones de invocar scripts.

  • Pago a dApp.

Las transacciones de invocar scripts puede contener hasta dos pagos a la dApp. El importe del pago y el token están disponibles para la función invocable.

Operaciones Disponibles Sólo Para el Emisor

Las siguientes operaciones con tokens sólo pueden ser realizadas por la cuenta que emitió el token:

  • Configuración del Patrocinio

The token issuer can enable sponsorship which allows all users to pay fees in this token (instead of DecentralCoins) for invoke script transactions and transfer transactions. More about sponsorship. Enabling or disabling sponsorship can be done via a sponsor fee transaction. A dApp script can set up sponsorship using a SponsorFee as a result of the invoke script transaction.

  • Reemitir

Increases the amount of token on the blockchain. The reissuable field of token determines whether the token can be reissued. Can be done via a reissue transaction. A dApp script can reissue the token via a reissue script action as a result of the invoke script transaction.

  • Replacing the asset script

Can be done via a set asset script transaction. If the token is not a smart asset, that is, the script was not attached when the token was issued, then it is impossible to attach the script later.

  • Modifying the token name and / or description

Can be done via an update asset info transaction.

Token Types

Non-Fungible Token

Non-fungible token or NFT is a special type of a token that is issued with the following parameters:

  • «quantity»: \(1\)

  • «decimals»: \(0\)

  • «reissuable»: false

NFT is a singular entity that has a unique ID. This contrasts with a regular token, two coins of which (for example, two WBTC) cannot be distinguished from each other. NFTs can be used as in-game items, collectibles, certificates, or unique coupons.

Issue of NFT

NFT can be issued in the same ways as a regular token, see token issue. The minimum fee for an NFT issue is \(0.001\) DecentralCoins, \(1000\) times less than for a regular token.

Smart Asset

Smart asset is a token that has an asset script assigned to it. By default, tokens on the DecentralChain blockchain are not smart contracts, and any transactions with them are allowed. The script endows a token with functionality that sets the rules for its circulation. Each transaction involving a smart asset is automatically checked against the conditions specified in the script. If the asset’s script allows the transaction, it will be executed; if the script denies the transaction, it is either not put onto the blockchain at all or saved as failed (for details, see the transaction validation article).

Using smart assets, you can implement various financial instruments on the blockchain (options, interval trading, taxation), game mechanics (allowing transactions only between characters with certain properties). Please note:

  • If a token is issued without a script, then the script cannot be added later.

  • The script cannot be removed, so it is impossible to turn a smart asset into a regular one.

  • The asset script can be changed using the set asset script transaction, unless prohibited by the asset script itself (as well as by the dApp or account script assigned to the issuer account).

  • The minimum fee for transaction is increased by \(0.004\) DecentralCoins for each smart asset involved, except for:

Tokens of Other Blockchains

A token issued on another blockchain cannot be used directly on the DecentralChain blockchain. A new token representing the original one can be issued on the DecentralChain blockchain, and a gateway that pegs the two tokens \(1:1\) can be deployed.

DecentralCoin

DecentralCoin is the native token of the DecentralChain blockchain. Block generators receive transaction fees and block rewards in DecentralCoins, which encourages generators to maintain and develop the blockchain network infrastructure. The more DecentralCoins the generator holds (by ownership or lease), the greater its chance to add the next block is.

DecentralCoin Parameters

DecentralCoins are present on the blockchain since inception, there is no issue transaction for it, therefore the DecentralCoin token does not have an ID. The REST API uses null for DecentralCoins. The number of decimal places (decimals) for DecentralCoins is \(8\). The atomic unit called Decentralite is \(\frac{1}{100,000,000}\) DecentralCoins.

Leasing

The owner of DecentralCoins can lease them via a lease transaction. DecentralCoins received on lease are included in the generating balance. Block generators send back different percentages as rewards to lessors. A lessor can cancel the lease at any time via a lease cancel transaction. More about leasing.

How to Get DecentralCoin

You can buy DecentralCoins tokens at Decentral.Exchange, or at one of the centralized exchanges. In addition, cryptocurrency gateways can be used to transfer external cryptocurrencies such as Bitcoin, Ethereum etc. from the external blockchain to the DecentralChain blockchain and vice versa. The gateway provides the user with the address on the external blockchain. After receiving a confirmation of transfer to this external address, the gateway transfers the corresponding asset (minus the fee) to the user’s DecentralChain address.

Token Custom Parameters

Below is an example of JSON representation returned by the GET /assets/details/{assetId} method of Node REST API:

{
  "assetId": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p",
  "issueHeight": 1806810,
  "issueTimestamp": 1574429393962,
  "issuer": "3PC9BfRwJWWiw9AREE2B3eWzCks3CYtg4yo",
  "issuerPublicKey": "BRnVwSVctnV8pge5vRpsJdWnkjWEJspFb6QvrmZvu3Ht",
  "name": "USD-N",
  "description": "Neutrino USD",
  "decimals": 6,
  "reissuable": false,
  "quantity": 999999999471258900,
  "scripted": false,
  "minSponsoredAssetFee": 7420,
  "originTransactionId": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p"
}
Token Custom Parameters

Field

Description

assetId

Token ID: base58 encoded byte array. The token ID is calculated as a hash of the token parameters upon issue. See also the token ID article.

issueHeight

Blockchain height (the sequence number of the block) at which the token is issued.

issueTimestamp

Token issue timestamp: Unix time in milliseconds.

issuer

Address of issuer account: base58 encoded byte array.

issuerPublicKey

Public key of issuer account: base58 encoded byte array.

name

Token name. From \(4\) to \(16\) bytes (\(1\) character can take up to \(4\) bytes).

description

Token description. From \(0\) to \(1000\) bytes.

decimals

Number of decimal places, from \(0\) to \(8\).

reissuable

Reissue availability flag.

quantity

Total supply of token on the blockchain specified in atomic units. From \(1\) to \(9,223,372,036,854,775,807\). Total supply can change as a result of reissue or burning, see token operations below.

scripted

There being a script: true for smart asset, false for regular token. More about smart assets.

minSponsoredAssetFee

For sponsored asset only: an amount of asset that is equivalent to \(0.001\) DecentralCoins. More about sponsorship.

originTransactionId

ID of the transaction that issued the token: base58 encoded byte array.

scriptDetails

For smart asset only: asset script and its attributes.

Atomic Unit

The amount of token is displayed differently in UIs and in the JSON representation used by the Node REST API. In API requests and responses, amount values are integers indicated in atomic units to avoid precision issues in floating-point calculations. An atomic unit is the minimum fraction (“cent”) of a token, it is equal to \(10^{-decimals}\). The amount of token in JSON is the real quantity multiplied by \(10^{decimals}\).

For USD-N in the example above:

  • decimals = \(6\),

  • atomic unit is \(\frac{1}{1,000,000}\) USD-N.

  • «quantity»: \(999999999471258900\) corresponds to \(999,999,999,471.258900\) USD-N in UIs, «minSponsoredAssetFee»: \(7420\) corresponds to \(0.007420\) USD-N.

Transaction

Transaction Issue

How to Sign and Send Transactions

  • In Decentral.Exchange you can create some types of transactions such as transfer, issue/reissue/burn, sponsor fee transaction, set asset script, create alias.

  • Via Node REST API:

    • The POST /transactions/broadcast method sends a signed transaction to a node;

    • The POST /transactions/sign method generates transaction signature (but this method is only available to the node owner).

Transaction Sender and Signature

Each transaction contains the public key of the sender’s account, on behalf of which the action is performed on the blockchain. Smart accounts and dApps can set their own rules for outgoing transactions verification.

Transactions that are sent from an ordinary account (without script) must contain the sender’s digital signature. The sender generates a signature using the account’s private key. Along with the signature, the transaction contains the sender’s public key, so the node (and anyone) can verify the integrity of the transaction data and the authenticity of the signature, that is, make sure that the signature of the transaction matches the public key.

After Transaction is Sent

Upon receiving a transaction, the node validates its signature, checks the sender’s balance, and so on, see the transaction validation article for details. If the transaction is valid, the node puts the transaction to the UTX pool, which is a list of transactions awaiting to be added, and also broadcasts the transaction to other nodes of the blockchain network.

Due to block size limitation (\(1\) MB) the transaction may not get to the block immediately. First of all, nodes add the most “profitable” transactions with the highest fee per byte. After being added to a block, the transaction changes the blockchain state: account balances, records in the account data storage, and so on. The transaction may never be added to a block if it becomes invalid while waiting in the UTX pool. For example, the transaction has expired (the timestamp is more than \(2\) hours behind current time) or another transaction has changed the blockchain state and now the sender’s balance is insufficient to execute the transaction or the account or asset script denies the transaction.

Transaction Proofs

Verification by Script

If the transaction sender is a dApp or smart account, then the transaction is verified by the script assigned to the account instead of signature verification. The script allows or denies the transaction depending on whether it meets the specified conditions. In particular, the script can run various verifications of the proofs.

A common example is a smart account with a multisignature where three co-owner users store shared funds.

Transaction Fees

Transaction fee is a fee that an account owner pays to send a transaction. A transaction sender can specify any amount of fee but not less than the minimum amount. The larger the fee is, the quicker the transaction will be added to the new block. For invoke script transactions and transfer transaction, a sender can specify a transaction fee nominated in a sponsored asset instead of DecentralCoins, see the section fee in sponsored asset below.

Regular Fees

Minimum Fee

The minimum fees in DecentralCoins for each type of transaction are listed below.

Example 1

  • The minimum fee for a transfer transaction:

  • No smart account or smart assets: \(0.001\) DecentralCoins.

  • Transfer from smart account*: \(0.001 + 0.004 = 0.005\) DecentralCoins.

  • Transfer of smart asset: \(0.001 + 0.004 = 0.005\) DecentralCoins.

  • Transfer of smart asset sent from smart account*: \(0.001 + 0.004 + 0.004 = 0.009\) DecentralCoins.

If the account script complexity is higher than the sender complexity threshold.

Example 2

The minimum fee for an Invoke Script transaction:

  • No smart account, no assets issued: \(0.005\) DecentralCoins.

  • dApp script invocation is sent from a smart account*: \(0.005 + 0.004 = 0.009\) DecentralCoins.

  • dApp script invocation issues an asset that is not non-fungible tokens: \(0.005 + 1 = 1.005\) DecentralCoins.

  • dApp script invocation is sent from smart account*, and \(10\) assets that are not non-fungible tokens are issued: \(0.005 + 0.004 + 10 × 1 = 10.009\) DecentralCoins.

If the account script complexity is higher than the sender complexity threshold.

Minimum Fees

Transaction type

Transaction type ID

Minimum transaction fee in DecentralCoins

Burn transaction

\(6\)

\(0.001\)

Create alias transaction

\(10\)

\(0.001\)

Data transaction

\(12\)

\(0.001\) per kilobyte. The size is rounded up to an integer number of kilobytes.

Exchange transaction

\(7\)

\(0.003\)

Invoke script transaction

\(16\)

\(0.005 + K\). \(K\) is the number of assets issued as a result of dApp script invocation that are not non-fungible tokens.

Issue transaction

\(3\)

\(1\) for reqular token. \(0.001\) for non-fungible token.

Lease cancel transaction

\(9\)

\(0.001\)

Lease transaction

\(8\)

\(0.001\)

Mass transfer transaction

\(11\)

\(0.001 + 0.0005 × N\). \(N\) is the number of transfers inside of the transaction. The value is rounded up to the three decimals.

Reissue transaction

\(5\)

\(0.001\)

Set asset script transaction

\(15\)

\(1\)

Set script transaction

\(13\)

\(0.01\)

Sponsor fee transaction

\(14\)

\(0.001\)

Transfer transaction

\(4\)

\(0.001\)

Update asset info transaction

\(17\)

\(0.001\)

Fee for Failed Transactions

Invoke script transactions and exchange transactions can be saved on the blockchain even if the result of a dApp script or asset script execution failed. In this case, the sender is charged a fee. For an exchange transaction, the matcher is charged the transaction fee but the order senders are not charged the matcher fee. More about transaction validation.

Fee in Sponsored Asset

An issuer of an asset can set up sponsorship — so that any user can specify a transaction fee in this asset for invoke script transactions and transfer transactions. To activate sponsorship, the issuer puts a sponsor fee transaction that specifies an amount of asset that is equivalent to the minimum fee of \(0.001\) DecentralCoins. For example, if minSponsoredAssetFee: \(5\), then the fee in this asset for an invoke script transaction equals \(5 * \frac{0.005}{0.001} = 25\).

Transaction Representations

JSON Representation

The Node REST API of DecentralChain nodes uses the JSON representation of transactions. You can send transactions to a node and read transactions stored on the blockchain via REST API in JSON. Here is an example of JSON representation:

{
  "senderPublicKey": "BVv1ZuE3gKFa6krwWJQwEmrLYUESuUabNCXgYTmCoBt6",
  "sender": "3N8S4UtauvDAzpLiaRyDdHn9muexWHhBP4D",
  "feeAssetId": null,
  "proofs": [
    "22QJfRKX7kUQt4qjdnUqZAnhqukqhnofE27uvP8Q5xnBf8M6PCNtWVGq2ngm6m7Voe7duys59D1yU9jhKrmdXDCe"
  ],
  "fee": 100000,
  "alias": "91f452553298770f",
  "id": "AD7KmXwoVNc2fXsmaxsHsrnT1tfPF3HsWYtfjFijVsvM",
  "type": 10,
  "version": 2,
  "timestamp": 1548443069053,
  "height": 466104
}
JSON Representation

Field

Description

senderPublicKey

Public key of the transaction sender: base58 encoded byte array.

sender

Address of the transaction sender: base58 encoded byte array.

feeAssetId

ID of the fee token. null means that the fee is in DecentralCoins. The sender can specify the fee for invoke script transactions and transfer transactions in a sponsored asset, see the sponsored fee article for details.

proofs

Array of transaction proofs. Up to \(8\) proofs, each proof up to \(64\) bytes base58 encoded.

fee

Transaction fee: an integer value indicated in the minimum fraction (“cent”) of the fee asset. For example, if the fee is \(0.001\) DecentralCoins, \(100000\) is indicated in the JSON representation, so far as \(1\) DecentralCoin = \(10^{8}\) Decentralites.

id

Transaction ID. For the transaction ID calculation method, see the cryptographic practical details article.

type

Transaction type. Type IDs are listed in the transaction type article.

version

Transaction version. Versions for each type of transaction are listed in transaction binary format descriptions.

applicationStatus

Status of transaction execution: 1) succeeded: transaction is successful. 2) script_execution_failed: the dApp script or the asset script failed. See the transaction validation article for details.

timestamp

Transaction timestamp specified by the sender: Unix time in milliseconds. The transaction cannot be added to the blockchain if the timestamp value is more than \(2\) hours behind or \(1.5\) hours ahead of current block timestamp.»

height

The sequence number of the block that contains the transaction.

The sender, id, applicationStatus, and height fields do not need to be filled when sending a transaction, and they are not stored on the blockchain. The node calculates these fields when providing transaction data via the Node REST API. The fields that depend on the type of transaction are listed in the description of each type of transaction.

Formato Binario

Transactions are stored on the blockchain in the binary format (byte representation). Node extensions such as gRPC server can work directly with data in binary format. The transaction signature and ID are also formed on the basis of the binary format. The guideline for generating a signature and ID is given in the cryptographic practical details article. Transaction binary format is described in the transaction binary format article.

You can get the transaction by ID, or the list of transactions by certain account address, or the list of all transactions in the block:

  • In DecentralChain Explorer.

  • Via Node REST API using the following methods:

    • GET /transactions/info/{id} returns transaction data by transaction ID.

    • GET /transactions/address/{address}/limit/{limit} returns the list of transactions where the specified address is involved.

    • GET /blocks/at/{height} returns block data at the specified height including all transactions in the block.

Transaction Types

Tokenization

Tokenization

Transaction type ID

Name

Description

\(3\)

Issue transaction

Issues a token.

\(5\)

Reissue transaction

Reissues a token.

\(6\)

Burn transaction

Decreases the amount of token.

\(15\)

Set asset script transaction

Modifies the asset script.

\(17\)

Update asset info transaction

Changes the token name and description.

Issue Transaction

Issue transaction creates a new token.

Fee

The minimum fee for an issue transaction is \(1\) DecentralCoins, in case of issue of a non-fungible tokens (NFT) \(0.001\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "2M25DqL2W4rGFLCFadgATboS8EPqyWAN3DjH12AH5Kdr",
  "quantity": 50000,
  "fee": 100000000,
  "description": "Script true.",
  "type": 3,
  "version": 2,
  "reissuable": true,
  "script": "base64:AQa3b8tH",
  "sender": "3Mz9N7YPfZPWGd4yYaX6H53Gcgrq6ifYiH7",
  "feeAssetId": null,
  "chainId": 84,
  "proofs": [
    "4yjVxzrLuXUq5y2QCa2LDn1Fp9P63hPBmqDLGQCqn41EB1uZ1pys79NP81h7FxRBnZSbpNGbz1xjwckHcPAQHmFX"
  ],
  "assetId": "7Xpp9PPeZbG4wboJrcbRQdq3SxCJqbeFRUjjKccM1DsD",
  "decimals": 2,
  "name": "Smart",
  "id": "7Xpp9PPeZbG4wboJrcbRQdq3SxCJqbeFRUjjKccM1DsD",
  "timestamp": 1548653407494,
  "height": 469677
}
Issue Transaction JSON Representation

Field

Description

name

Token name. From \(4\) to \(16\) bytes (\(1\) character can take up to \(4\) bytes).

description

Token description. From \(0\) to \(1000\) bytes.

quantity

Token quantity: an integer value specified in the minimum fraction (“cents”), that is, the real quantity multiplied by \(10^{decimals}\). From \(1\) to \(9,223,372,036,854,775,807\). \(1\) for NFT.

decimals

Number of decimal places, from \(0\) to \(8\). \(0\) for NFTs.

reissuable

Reissue availability flag, see the reissue transaction article. False for NFTs.

script

For the smart asset: the compiled Asset script, up to \(8192\) bytes, base64 encoded. For the token without a script: null. The token issued without a script cannot be converted to a smart asset.

chainId

Chain ID

assetId

Token ID base58 encoded. The token ID is the same as the Issue transaction ID.

The assetId field does not need to be filled when sending a transaction, and it is not stored on the blockchain. The node calculates these fields when providing transaction data via the REST API. The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the issue transaction binary format.

Ride Structure

The IssueTransaction structure is used for transaction handling in smart contracts.

Reissue Transaction

Reissue transaction increases the amount of the token on the blockchain and/or prohibits its reissue. Only the token issuer can send a reissue transaction. The additional amount of token increases the balance of the transaction sender. The reissuable field of the token determines whether the token can be reissued.

Fee

The minimum fee for a reissue transaction is \(0.001\) DecentralCoins. If the token is a smart asset, the minimum fee is increased by \(0.004\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "DjYEAb3NsQiB6QdmVAzkwJh7iLgUs3yDLf7oFEeuZjfM",
  "quantity": 200000,
  "fee": 100000000,
  "type": 5,
  "version": 2,
  "reissuable": true,
  "sender": "3PLJciboJqgKsZWLj7k1VariHgre6uu4S2T",
  "feeAssetId": null,
  "chainId": 87,
  "proofs": [
    "5mEveeUwBdBqe8naNoV5eAe5vj6fk8U743eHGkhxhs3v9PMsb3agHqpe4EtzpUFdpASJegXyjrGSbynZg557cnSq"
  ],
  "assetId": "GA4gB3Lf3AQdF1vBCbqGMTeDrkUxY7L83xskRx6Z7kEH",
  "id": "27ETigYaHym2Zbdp4x1gnXnZPF1VJCqQpXmhszC35Qac",
  "timestamp": 1548521785933,
  "height": 1368623
}
Reissue Transaction JSON Representation

Field

Description

assetId

Token ID base58 encoded.

quantity

Amount of token to reissue: an integer value specified in the minimum fraction (“cents”) of token. The total quantity of token as a result of the reissue should not exceed \(9,223,372,036,854,775,807\).

chainId

Chain ID

reissuable

Reissue availability flag.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the reissue transaction binary format.

Ride Structure

The ReissueTransaction structure is used for transaction handling in smart contracts.

Burn Transaction

Burn transaction decreases the amount of token on sender’s account and thereby the total amount of the token on the blockchain. Any account that owns a token (not necessarily the token issuer) can send the burn transaction. Burned tokens cannot be restored back to the account.

Fee

The minimum fee for a burn transaction is \(0.001\) DecentralCoins, in case of burning a smart asset \(0.005\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "9GaQj7gktEiiS1TTTjGbVjU9bva3AbCiawZ11qFZenBX",
  "amount": 9999,
  "fee": 100000,
  "type": 6,
  "version": 2,
  "sender": "3P9QZNrHbyxXj8P9VrJZmVu2euodNtA11UW",
  "feeAssetId": null,
  "chainId": 87,
  "proofs": [
    "61jCivdv3KTuTY6QHgxt4jaGrXcszWg3vb9TmUR26xv7mjWWwjyqs7X5VDUs9c2ksndaPogmdunHDdjWCuG1GGhh"
  ],
  "assetId": "FVxhjrxZYTFCa9Bd4JYhRqXTjwKuhYbSAbD2DWhsGidQ",
  "id": "csr25XQHT1c965Fg7cY2vJ7XHYVsudPYrUbdaFqgaqL",
  "timestamp": 1548660675277,
  "height": 1370971
}
Burn Transaction JSON Representation

Field

Description

amount

Amount of token to burn: an integer value specified in the minimum fraction (“cents”) of token.

assetId

Token ID base58 encoded.

chainId

Chain ID

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the burn transaction binary format.

Ride Structure

The BurnTransaction structure is used for transaction handling in smart contracts.

Set Asset Script Transaction

Set asset script transaction replaces the asset script. Only the token issuer can send an asset script transaction. If a token is issued without a script, then no script can be assigned to it. It is also impossible to remove the script and turn the smart asset into a regular one.

Fee

The minimum fee for a set asset script transaction is \(1\) DecentralCoin.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "AwQYJRHZNd9bvF7C13uwnPiLQfTzvDFJe7DTUXxzrGQS",
  "fee": 100000000,
  "type": 15,
  "version": 1,
  "script": "base64:AQa3b8tH",
  "sender": "3P67JUW8Djit7hMjKhADmn6CWvKPbRuh2sQ",
  "feeAssetId": null,
  "chainId": 87,
  "proofs": [
    "nzYhVKmRmd7BiFDDfrFVnY6Yo98xDGsKrBLWentF7ibe4P9cGWg4RtomHum2NEMBhuyZb5yjThcW7vsCLg7F8NQ"
  ],
  "assetId": "7qJUQFxniMQx45wk12UdZwknEW9cDgvfoHuAvwDNVjYv",
  "id": "FwYSpmVDbWQ2BA5NCBZ9z5GSjY39PSyfNZzBayDiMA88",
  "timestamp": 1547201038106,
  "height": 1346345
}
Set Asset Script Transaction JSON Representation

Field

Description

assetId

Token ID base58 encoded.

chainId

Chain ID

script

Compiled asset script, up to \(8192\) bytes, base64 encoded.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the set asset script transaction binary format.

Ride Structure

The SetAssetScriptTransaction structure is used for transaction handling in smart contracts.

Update Asset Info Transaction

Update asset info transaction modifies the name and description of the token.

Fee

The minimum fee for an update asset info transaction is \(0.001\) DecentralCoins, in case of a smart asset \(0.005\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "6a6r9d3r2ccyE9SvuxmdZbfSHXmKPUoExnigvippJLfu",
  "fee": 100000,
  "description": "xxxXXXxxx",
  "type": 17,
  "version": 1,
  "applicationStatus": "succeeded",
  "sender": "3MQdH4MAmM5RNz5TAT43UXXCvMtCa9YgHq9",
  "feeAssetId": null,
  "chainId": 83,
  "proofs": [
    "4DfvJL4cVisQaMuMB7ar15EtYZTvTZzAUQQMkq4RA3uTMzziVYLrbNHSL2a1eCqBV3YQb7dddXdjywETXHuu65ij"
  ],
  "assetId": "syXBywr2HVY7wxqkaci1jKY73KMpoLh46cp1peJAZNJ",
  "name": "zzzz",
  "id": "4DL8K4bRvYb9Qrys9Auq7hSGuLGq8XsUYZqDDBBfVGMf",
  "timestamp": 1591886337668,
  "height": 411389
}
Update Asset Info Transaction JSON Representation

Field

Description

name

Token name. From \(4\) to \(16\) bytes.

description

Token description. From \(0\) to \(1000\) bytes.

chainId

Chain ID

assetId

Token ID base58 encoded.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the update asset info transaction binary format.

Ride Structure

The UpdateAssetInfoTransaction structure is used for transaction handling in smart contracts.

Usage

Usage

Transaction type ID

Name

Description

\(4\)

Transfer transaction

Transfers a token to another account.

\(7\)

Exchange transaction

Exchanges two different tokens between two accounts. Contains two counter orders: a buy order and a sell order.

\(10\)

Create alias transaction

Creates alias for the sender’s address.

\(11\)

Mass transfer transaction

Transfers a token, up to \(100\) recipients.

\(12\)

Data transaction

Adds, modifies and deletes data entries in the sender’s account data storage.

\(13\)

Set Script transaction

Assigns the dApp script or account script to the sender’s account.

\(16\)

Invoke Script transaction

Invokes a callable function of a dApp.

Transfer Transaction

Transfer transaction transfers a certain amount of token to another account.

Fee

The minimum fee for a transfer transaction is \(0.001\) DecentralCoins, in case of transferring a smart asset \(0.005\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "Cs4DShy4nTx6WyxjKRoDtoYsGhvT663pYLysPCLeVZHE",
  "amount": 15540,
  "signature": "5EaYqFx2xFJmdvwZ1gT3yLecKr88z3jByCj5GE1MjE1ossvehExZKoT7uhGatiYCGM9Co8iUR8Q5ce52XDmno3rn",
  "fee": 100000,
  "type": 4,
  "version": 1,
  "attachment": "3vrgtyozxuY88J9RqMBBAci2UzAq9DBMFTpMWLPzMygGeSWnD7k",
  "sender": "3PN2bVFxJjgudPKqEGZ41TVsD5ZJmxqnPSu",
  "feeAssetId": null,
  "proofs": [
    "5EaYqFx2xFJmdvwZ1gT3yLecKr88z3jByCj5GE1MjE1ossvehExZKoT7uhGatiYCGM9Co8iUR8Q5ce52XDmno3rn"
  ],
  "assetId": "7uncmN7dZfV3fYVvNdYTngrrbamPYMgwpDnYG1bGy6nA",
  "recipient": "3PFmoN5YLoPNsL4cmNGkRxbUKrUVntwyAhf",
  "feeAsset": null,
  "id": "D79kL1Jr5xyL2Rmw2FnafQHugJGvuBhNEbLnhMuwMkDC",
  "timestamp": 1548660895034,
  "height": 1370973
}
Transfer Transaction JSON Representation

Field

Description

assetId

Token ID base58 encoded. null means DecentralCoins.

amount

Amount of token to transfer: an integer value specified in the minimum fraction (“cents”) of token.

attachment

Arbitrary binary data (typically a comment to transfer) base58 encoded, up to \(4\) bytes.

recipient

Recipient address base58 encoded or recipient alias with alias:<chain_id>: prefix, for example alias:T:merry (See chain ID).

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the transfer transaction binary format.

Ride Structure

The TransferTransaction structure is used for transaction handling in smart contracts.

Exchange Transaction

Exchange transaction exchanges two different tokens between two accounts. Commonly the exchange transaction is created by the matcher service that executes orders to buy and sell tokens. The exchange transaction contains two counter orders: a buy order and a sell order. The blockchain guarantees that the terms of the exchange are not worse than those indicated in each order.

An order can be filled partially. An order can participate in several exchange transactions, with different counter orders. One of the two exchanged tokens is the amount asset (base currency): it represents the amount of token in orders and in the Exchange transaction. Another token is a price asset (quote currency): it represents the price.

_images/08_Exchange-Transaction.png

Transaction Fee

The minimum fee for an exchange transaction is \(0.003\) DecentralCoins. In case of exchange of a smart asset for an ordinary asset the minimum fee is \(0.007\) DecentralCoins, in case of exchange of two smart assets the minimum fee is \(0.011\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

Matcher Fee

The matcher receives a fee for order execution from each order sender. The minimum matcher fee is set by the matcher. The order sender specifies the fee not less than the minimum amount.

If the order is fully filled with one exchange transaction, the matcher receives the entire fee specified in the order. If the order is partially filled, the matcher receives a part of the fee. The blockchain guarantees that the total matcher fee received from the order sender in all exchange transactions does not exceed the fee specified in the order.

_images/09_Matcher-Fee.png

JSON Representation

{
  "senderPublicKey": "9cpfKN9suPNvfeUNphzxXMjcnn974eme8ZhWUjaktzU5",
  "amount": 100000000,
  "fee": 300000,
  "type": 7,
  "version": 2,
  "sellMatcherFee": 750,
  "sender": "3PEjHv3JGjcWNpYEEkif2w8NXV4kbhnoGgu",
  "feeAssetId": null,
  "proofs": [
    "LQD8VoFhHEW2b6o2e2ujzDHdZatwMMwigC2tmoSHcFNRGXrowA1yyVxD6nZBNeABLWjs59dnuLhgNP7UMfFKDuR"
  ],
  "price": 1134500,
  "id": "EHLccXcemZPEvUpM9UkASG1GciwMt9R5B3QuYFxywj9g",
  "order2": {
    "version": 3,
    "id": "JCiF3gmprLc8u7xdWR7KUkJ3YfM6yfgxB6CvhJYGJFAa",
    "sender": "3PRBeeFD64wvTMfS3HEoDDFPXfJs3gFdAxk",
    "senderPublicKey": "ytgWVbKG9e6TSsQ5buMryr2QyxNoL3RezXP3f9RJ2As",
    "matcherPublicKey": "9cpfKN9suPNvfeUNphzxXMjcnn974eme8ZhWUjaktzU5",
    "assetPair": {
      "amountAsset": null,
      "priceAsset": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p"
    },
    "orderType": "sell",
    "amount": 40000000000,
    "price": 1134500,
    "timestamp": 1591356602063,
    "expiration": 1593862202062,
    "matcherFee": 300000,
    "matcherFeeAssetId": null,
    "signature": "3D2Ngr7H6MQRs1izMQSix3dMHmDfg4bcRjxamFXFsb4Ku28neNWHdtwE6LtR3eq69Jqr1CvEsAKCWkQEeEEomcoK",
    "proofs": [
      "3D2Ngr7H6MQRs1izMQSix3dMHmDfg4bcRjxamFXFsb4Ku28neNWHdtwE6LtR3eq69Jqr1CvEsAKCWkQEeEEomcoK"
    ]
  },
  "order1": {
    "version": 3,
    "id": "FNvEGPgUqEWnrnpxevZQnaZS3DUTBGE2wa6L75xCw7mo",
    "sender": "3PDxxx7eSeYLgzTAtuAV7gUCtHeeXeU85fP",
    "senderPublicKey": "3WEkbavP3Sw4y5tsgxbZvKkWh87BdB3CPVVxhcRUDBsJ",
    "matcherPublicKey": "9cpfKN9suPNvfeUNphzxXMjcnn974eme8ZhWUjaktzU5",
      "assetPair": {
      "amountAsset": null,
      "priceAsset": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p"
    },
    "orderType": "buy",
    "amount": 100000000,
    "price": 1134500,
    "timestamp": 1591356752271,
    "expiration": 1593862352271,
    "matcherFee": 300000,
    "matcherFeeAssetId": null,
    "signature": "2gvqaYy2BFbK4BJZS8taRJnhgfQ1z2CytF2RqjcyEfzFiu9tkTjN5q4UyFXpPqS3E6eD2WQBUaYCTYDKv98iW1sy",
    "proofs": [
      "2gvqaYy2BFbK4BJZS8taRJnhgfQ1z2CytF2RqjcyEfzFiu9tkTjN5q4UyFXpPqS3E6eD2WQBUaYCTYDKv98iW1sy"
    ]
  },
  "buyMatcherFee": 300000,
  "timestamp": 1591356752456,
  "height": 2093333
}
Exchange Transaction JSON Representation

Field

Description

amount

Amount of the amount asset: an integer value specified in the minimum fraction (“cent”) of asset.

price

Price for the amount asset nominated in the price asset, multiplied by the factor: 1) \(10^{8}\) for the exchange transaction version 3. 2) \(10^{(8 + priceAssetDecimals – amountAssetDecimals)}\). Where amountAssetDecimals, priceAssetDecimals are decimals of the assets, for the exchange transaction version 2 or 1.

buyMatcherFee

Matcher fee for the buy order execution. The fee token ID is indicated in buy order.

sellMatcherFee

Matcher fee for the sell order execution. The fee token ID is indicated in sell order.

order1, order2

Buy and sell orders. See the order article for details.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the exchange transaction binary format.

Ride Structure

The ExchangeTransaction structure is used for transaction handling in smart contracts.

Create Alias Transaction

Create Alias transaction creates an alias for the sender’s address.A created alias cannot be deleted.

Fee

The minimum fee for a Create Alias transaction is \(0.001\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey":"BVv1ZuE3gKFa6krwWJQwEmrLYUESuUabNCXgYTmCoBt6",
  "sender":"3N8S4UtauvDAzpLiaRyDdHn9muexWHhBP4D",
  "feeAssetId":null,
  "proofs": [
    "22QJfRKX7kUQt4qjdnUqZAnhqukqhnofE27uvP8Q5xnBf8M6PCNtWVGq2ngm6m7Voe7duys59D1yU9jhKrmdXDCe"
  ],
  "fee":100000,
  "alias":"91f452553298770f",
  "id":"AD7KmXwoVNc2fXsmaxsHsrnT1tfPF3HsWYtfjFijVsvM",
  "type":10,
  "version":2,
  "timestamp":1548443069053,
  "height":466104
}
Create Alias Transaction JSON Representation

Field

Description

alias

Alias. From \(4\) to \(30\) bytes (\(1\) character can take up to \(4\) bytes).

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the create alias transaction binary format.

Ride Structure

The CreateAliasTransaction structure is used for transaction handling in smart contracts.

Mass Transfer Transaction

Mass transfer transaction transfers a token to several accounts, from \(1\) DecentralCoin to \(100\) DecentralCoins .

Fee

The minimum fee for a Mass Transfer transaction is \(0.001 + 0.0005 × N\) DecentralCoins, in case of transferring a smart asset \(0.001 + 0.0005 × N\) DecentralCoins, where \(N\) DecentralCoins is the number of recipients. The fee value is rounded up to three decimals.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "5DphrhGy6MM4N3yxfB2uR2oFUkp2MNMpSzhZ4uJEm3U1",
  "fee": 5100000,
  "type": 11,
  "transferCount": 100,
  "version": 1,
  "totalAmount": 500000000000,
  "attachment": "xZBWqm9Ddt5BJVFvHUaQwB7Dsj78UQ5HatQjD8VQKj4CHG48WswJxUUeHEDZJkHgt9LycUpHBFc8ENu8TF8vvnDJCgfy1NeKaUNydqy9vkACLZjSqaVmvfaM3NQB",
  "sender": "3P2rvn2Hpz6pJcH8oPNrwLsetvYP852QQ2m",
  "feeAssetId": null,
  "proofs": [
    "FmGBaWABAy5bif7Qia2LWQ5B4KNmBnbXETL1mE6XEy4AAMjftt3FrxAa8x2pZ9ux391oY5c2c6ZSDEM4nzrvJDo"
  ],
  "assetId": "Fx2rhWK36H1nfXsiD4orNpBm2QG1JrMhx3eUcPVcoZm2",
  "transfers": [
    {
      "recipient": "3PHnjQrdK389SbzwPEJHYKzhCqWvaoy3GQB",
      "amount": 5000000000
    },
    {
      "recipient": "3PGNLwUG2GPpw74teTAxXFLxgFt3T2uQJsF",
      "amount": 5000000000
    },
    {
      "recipient": "3P5kQneM9EdpVUbFLgefD385LLYTXY5J32c",
      "amount": 5000000000
    },
    ...
  ],
  "id": "3LRfudet7avpQcW1AdauiBGb8SSRAaoCugDzngDPLVcv",
  "timestamp": 1528973951321,
  "height": 1041197
}
Mass Transfer Transaction JSON Representation

Field

Description

assetId

Token ID base58 encoded. null means DecentralCoins.

attachment

Arbitrary binary data (typically a comment to transfer) base58 encoded, up to \(140\) bytes.

transfers.recipient

Recipient address base58 encoded or recipient alias with alias:<chain_id>: prefix, for example alias:T:merry (See Chain ID).

transfers.amount

Amount of token to transfer: an integer value specified in the minimum fraction (“cents”) of token.

transferCount

Number of recipients.

totalAmount

Total amount of transfers in transaction.

The transferCount and totalAmount fields do not need to be filled when sending a transaction, and they are not stored on the blockchain. The node calculates these fields when providing transaction data via the REST API.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the mass transfer transaction binary format.

Ride Structure

The MassTransferTransaction structure is used for transaction handling in smart contracts.

Data Transaction

Data transaction adds, modifies and deletes data entries in sender’s account data storage. Limitations are as follows:

  • The maximum number of entries is \(100\).

  • For a transaction version 2 the maximum data size (keys + values) is \(165,890\) bytes.

  • For a transaction version 1 the maximum transaction size (except proofs) is \(153,600\) bytes.

Fee

The minimum fee for a Data transaction is \(0.001\) DecentralCoins per kilobyte, the size is rounded up to an integer number of kilobytes.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "38bYRUxFCaoa9h822nMnsoTX1qfczqtHJLgouNcNnd8h",
  "data": [
    {
      "type": "boolean",
      "value": true,
      "key": "bool"
    },
    {
      "type": "binary",
      "value": "base64:SGVsbG8gV2F2ZXM=",
      "key": "bin"
    },
    {
      "type": "integer",
      "value": 1234567,
      "key": "int"
    },
    {
      "type": "string",
      "value": "some text",
      "key": "str"
    }
  ],
  "sender": "3N4iKL6ikwxiL7yNvWQmw7rg3wGna8uL6LU",
  "feeAssetId": null,
  "proofs": [
    "kE1hjN1yW68j8DsYGNB7Gg1ydC4hqRmt3wBaFQUPkftnbiM7QfJCn1gTHgveJ7pCLXvvqffhKBmiF8qS1Uqk6SR"
  ],
  "fee": 100000,
  "id": "3EPJuvQiJYiu9Y5g6mYDQgHVu8GFUfnZurHrVwwF1ViH",
  "type": 12,
  "version": 2,
  "timestamp": 1591351545000,
  "height": 1029815
}
Data Transaction JSON Representation

Field

Description

data.key

Entry key. String, up to \(400\) bytes for version 2, up to \(100\) characters for version 1.

data.type

Entry type: 1) binary. 2) boolean. 3) integer. 4) string. 5) null – delete entry.

data.value

Entry value. Up to \(32,767\) bytes. Binary value is base64 encoded. null – delete entry.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the data transaction binary format.

Ride Structure

The DataTransaction structure is used for transaction handling in smart contracts.

Set Script Transaction

Set script transaction assigns the dApp script dApp script or account script to the sender’s account.

Fee

The minimum fee for a Set Script transaction is \(0.001\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "7nLAwoiRA4fWF4VHd6gRsbwF2UFFmRADXHqRcgy3h27w",
  "sender": "3N9yCRmNsLK2aPStjLBne3EUiPSKvVHYgKk",
  "feeAssetId": null,
  "chainId": 84,
  "proofs": [
    "2ihGFLUbvJHEpuGRqx5MXEXsEzwMuCmB8FgUTZgSPdANA4iab4M3nsNJ7a7hyiuqjrvwNCHoWn69hvUeziJiSAie"
  ],
  "fee": 1400000,
  "id": "28hbeFhYBq6uir1bbjt2dxbpqxCM2B6GKq4c7zf7AbkX",
  "type": 13,
  "version": 1,
  "script": "base64:AAIDAAAAAAAAAAYIARIAEgAAAAACAQAAAApyYW5kb21pemVyAAAAAQAAAANpbnYEAAAACGxhc3RQbGF5BAAAAAckbWF0Y2gwCQAEHAAAAAIFAAAABHRoaXMCAAAACGxhc3RQbGF5AwkAAAEAAAACBQAAAAckbWF0Y2gwAgAAAApCeXRlVmVjdG9yBAAAAAFzBQAAAAckbWF0Y2gwBQAAAAFzAwkAAAEAAAACBQAAAAckbWF0Y2gwAgAAAARVbml0BAAAAAFhBQAAAAckbWF0Y2gwAQAAAAxXYXZlc0xvdHRvVjIJAQAAAAV0aHJvdwAAAAAEAAAABHJhbmQJAADLAAAAAgkAAMsAAAACCQAAywAAAAIJAADLAAAAAgkAAMsAAAACBQAAAAhsYXN0UGxheQgFAAAAA2ludgAAAA10cmFuc2FjdGlvbklkCAUAAAADaW52AAAAD2NhbGxlclB1YmxpY0tleQgFAAAACWxhc3RCbG9jawAAABNnZW5lcmF0aW9uU2lnbmF0dXJlCQABmgAAAAEIBQAAAAlsYXN0QmxvY2sAAAAJdGltZXN0YW1wCQABmgAAAAEIBQAAAAlsYXN0QmxvY2sAAAAGaGVpZ2h0CQAB9wAAAAEFAAAABHJhbmQBAAAACnN0YXJ0TG90dG8AAAABAAAAA2ludgQAAAAJcGxheUxpbWl0CQAAaQAAAAIJAQAAAAx3YXZlc0JhbGFuY2UAAAABBQAAAAR0aGlzAAAAAAAAAABkBAAAAAdwYXltZW50CQEAAAAHZXh0cmFjdAAAAAEIBQAAAANpbnYAAAAHcGF5bWVudAMJAQAAAAEhAAAAAQkBAAAACWlzRGVmaW5lZAAAAAEIBQAAAANpbnYAAAAHcGF5bWVudAkAAAIAAAABAgAAAB9TaG91bGQgYmUgd2l0aCBQYXltZW50IGluIFdhdmVzAwkBAAAACWlzRGVmaW5lZAAAAAEIBQAAAAdwYXltZW50AAAAB2Fzc2V0SWQJAAACAAAAAQIAAAAaUGF5bWVudCBzaG91bGQgYmUgaW4gV2F2ZXMDCQAAZgAAAAIIBQAAAAdwYXltZW50AAAABmFtb3VudAUAAAAJcGxheUxpbWl0CQAAAgAAAAEJAAEsAAAAAgIAAAAcUGF5bWVudCBzaG91bGQgYmUgbGVzcyB0aGFuIAkAAaQAAAABBQAAAAlwbGF5TGltaXQEAAAACHJhbmRoYXNoCQEAAAAKcmFuZG9taXplcgAAAAEFAAAAA2ludgQAAAALd2luVHJhbnNmZXIJAQAAAAtUcmFuc2ZlclNldAAAAAEJAARMAAAAAgkBAAAADlNjcmlwdFRyYW5zZmVyAAAAAwgFAAAAA2ludgAAAAZjYWxsZXIJAABpAAAAAgkAAGgAAAACCAUAAAAHcGF5bWVudAAAAAZhbW91bnQAAAAAAAAAAL4AAAAAAAAAAGQFAAAABHVuaXQFAAAAA25pbAQAAAANd3JpdGVMYXN0UGxheQkBAAAACFdyaXRlU2V0AAAAAQkABEwAAAACCQEAAAAJRGF0YUVudHJ5AAAAAgIAAAAIbGFzdFBsYXkFAAAACHJhbmRoYXNoBQAAAANuaWwDCQAAZgAAAAIAAAAAAAAAAfQJAABqAAAAAgkABLEAAAABBQAAAAhyYW5kaGFzaAAAAAAAAAAD6AkBAAAADFNjcmlwdFJlc3VsdAAAAAIFAAAADXdyaXRlTGFzdFBsYXkFAAAAC3dpblRyYW5zZmVyCQEAAAAMU2NyaXB0UmVzdWx0AAAAAgUAAAANd3JpdGVMYXN0UGxheQkBAAAAC1RyYW5zZmVyU2V0AAAAAQUAAAADbmlsAAAAAgAAAANpbnYBAAAABWxvdHRvAAAAAAkBAAAACnN0YXJ0TG90dG8AAAABBQAAAANpbnYAAAADaW52AQAAAAdkZWZhdWx0AAAAAAkBAAAACnN0YXJ0TG90dG8AAAABBQAAAANpbnYAAAAA4XqnJg==",
  "timestamp": 1592408917668,
  "height": 1047736
}
Set Script Transaction JSON Representation

Field

Description

chainId

Chain ID

script

Compiled script, base64 encoded. Account script up to \(8192\) bytes, dApp script up to \(32,767\) bytes. null – delete script.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the set script transaction binary format.

Ride Structure

The SetScriptTransaction structure is used for transaction handling in smart contracts.

Invoke Script Transaction

Invoke script transaction invokes the callable function of the dApp.

In addition to the dApp address, callable function name, and arguments, the Invoke Script transaction can contain payments to dApp. The maximum number of payments is 10.

Fee

The sender can specify a transaction fee nominated in a sponsored asset instead of DecentralCoins, see the sponsored fee article.

The minimum fee in DecentralCoins for an invoke script transaction is Fee \(= 0.005 + S + 1 × I\).

  • If the transaction sender is a dApp or smart account, and that the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, then \(S = 0.004\), otherwise \(S = 0\).

  • \(I\) is the number of issued assets that are not NFT.

Total Complexity

A dApp callable function can invoke a callable function of another dApp, or another callable function of the same dApp, or even itself. All invoked functions are executed within a single Invoke Script transaction. More about dApp-to-dApp invocation.

The total complexity is limited by \(26,000\) for all callable functions and asset scripts of involved smart assets in a single invoke script transaction. The sender’s account script complexity is not included in that limit.

JSON Representation

{
  "type": 16,
  "id": "DN9Ny8mph4tLjn58e9CqhckPymH9zwPqBSZtcv2bBi3u",
  "sender": "3Mw48B85LvkBUhhDDmUvLhF9koAzfsPekDb",
  "senderPublicKey": "BvJEWY79uQEFetuyiZAF5U4yjPioMj9J6ZrF9uTNfe3E",
  "fee": 500000,
  "feeAssetId": null,
  "timestamp": 1601652119485,
  "proofs": [
    "2536V2349X3cuVEK1rSxQf3HneJwLimjCmCfoG1QyMLLq1CNp6dpPKUG3Lb4pu76XqLe3nWyo3HAEwGoALgBhxkF"
  ],
  "version": 2,
  "chainId": 84,
  "dApp": "3N28o4ZDhPK77QFFKoKBnN3uNeoaNSNXzXm",
  "payment": [],
  "call": {
    "function": "foo",
    "args": [
      {
        "type": "list",
        "value": [
          {
            "type": "string",
            "value": "alpha"
          },
          {
            "type": "string",
            "value": "beta"
          },
          {
            "type": "string",
            "value": "gamma"
          }
        ]
      }
    ]
  },
  "height": 1203100,
  "applicationStatus": "succeeded",
  "stateChanges": {
    "data": [
      {
        "key": "3Mw48B85LvkBUhhDDmUvLhF9koAzfsPekDb",
        "type": "string",
        "value": "alphabetagamma"
      }
    ],
    "transfers": [],
    "issues": [],
    "reissues": [],
    "burns": [],
    "sponsorFees": [],
    "leases": [],
    "leaseCancels": [],
    "invokes": []
  }
}
Invoke Script Transaction JSON Representation

Field

Description

call.function

Callable function name. Up to \(255\) bytes (\(1\) character can take up to \(4\) bytes).

call.args.type

Argument type: 1) binary. 2) boolean. 3) integer. 4) string. 5) list.

call.args.value

Argument value. 1) integer: from \(-9,223,372,036,854,775,808\) to \(9,223,372,036,854,755,807\) inclusive. 2) string or binary: up to \(32,767\) bytes. Binary value should be base64 encoded. 3) list: up to \(1000\) elements.

dApp

dApp address base58 encoded or dApp alias with alias:<chain_id>: prefix, for example alias:T:merry (See Chain ID).

payment.amount

Amount of token in payment: an integer value specified in atomic units.

payment.assetId

ID of token in payment, base58 encoded. null means that the payment is in DecentralCoin.

stateChanges

Script actions performed by the callable function and dApp-to-dApp invocation results.

The stateChanges structure does not need to be filled when sending a transaction, and it is not stored on the blockchain. The node returns this structure when providing transaction data via the REST API.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the invoke script transaction binary format.

Ride Structure

The InvokeScriptTransaction structure is used for transaction handling in smart contracts.

Network

Network

Transaction type ID

Name

Description

\(8\)

Lease transaction

Leases DecentralCoins.

\(9\)

Lease cancel transaction

Cancels the leasing.

\(14\)

Sponsor fee transaction

Configures sponsorship.

Lease Transaction

Lease transaction leases DecentralCoins to another account. After \(1000\) block the leased tokens are accounted for by the recipient’s generating balance. The larger the generating balance of the node is, the higher the chances for that node to be selected to generate the next block. Commonly node owners share the reward for generated blocks with lessors. More about leasing.

Leased tokens remain locked on the sender’s account with the full control of their owner. The sender can cancel the lease at any time by the lease cancel transaction.

Fee

The minimum fee for a lease transaction is \(0.001\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "senderPublicKey": "b8AB1PQWE7kH55cS48uDTV5fezrAyDTCf7iePyXNzNm",
  "amount": 500000000,
  "signature": "3n34MYd3Acx1JpTtvYffdVYCVySuRgZvSbHMA3AxqQwr4xvfZedv9UbqSB9k84PGY5C8RSwGRjDnMGcYwQu2x7B5",
  "fee": 100000,
  "type": 8,
  "version": 1,
  "sender": "3P6iv9tYo3ELne7tc9HR8BzhK3LE2aDDu1A",
  "feeAssetId": null,
  "proofs": [
    "3n34MYd3Acx1JpTtvYffdVYCVySuRgZvSbHMA3AxqQwr4xvfZedv9UbqSB9k84PGY5C8RSwGRjDnMGcYwQu2x7B5"
  ],
  "recipient": "3P2HNUd5VUPLMQkJmctTPEeeHumiPN2GkTb",
  "id": "7k4EPgA3VxoE56TMJLjvF9FMpywyfeS5qRJSEEN9XGuU",
  "timestamp": 1528813353617,
  "status": "canceled",
  "height": 1038624
}
Lease Transaction JSON Representation

Field

Description

amount

Amount of DecentralCoins to lease.

recipient

Recipient address base58 encoded or recipient alias.

status

Lease status: 1) active: lease is active. 2) canceled: lease is cancelled, see lease cancel transaction.

The status field does not need to be filled when sending a transaction, and it is not stored on the blockchain. The node calculates these fields when providing transaction data via the REST API.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the lease transaction binary format.

Ride Structure

The LeaseTransaction structure is used for transaction handling in smart contracts.

Lease Cancel Transaction

Lease cancel transaction cancels the leasing. See the lease transaction article.

Fee

The minimum fee for a lease cancel transaction is \(0.001\) DecentralCoins.

If the transaction sender is a dApp or smart account, and the complexity of the account script or dApp script verifier function exceeds the sender complexity threshold, the minimum fee is increased by \(0.004\) DecentralCoins.

JSON Representation

{
  "type": 9,
  "id": "6rzxZ3rEsCxgmkcn6DDPB9f9Phi28D4JWZsCtwcViD8C",
  "sender": "3Mx7kNAFcGrAeCebnt3yXceiRSwru6N3XZd",
  "senderPublicKey": "81fxJw7HM2VX1ucq1vNKiedM1XBGX7H2TDUtxN6ib68Z",
  "fee": 100000,
  "feeAssetId": null,
  "timestamp": 1622579112096,
  "proofs": [
    "3eFnprsRSeczc371bQ7AUsbh6qjiUFze6y5BZGKbxyHG27K1cU6jVUgRdthYz9uWVw1FgVpLjMciGCb64rJnMp3k"
  ],
  "version": 2,
  "leaseId": "BhHPPHBZpfp8FBy8DE7heTpWGJySYg2uU2r4YM6qaisw",
  "chainId": 84,
  "height": 1551763,
  "applicationStatus": "succeeded",
  "lease": {
    "id": "BhHPPHBZpfp8FBy8DE7heTpWGJySYg2uU2r4YM6qaisw",
    "originTransactionId": "BhHPPHBZpfp8FBy8DE7heTpWGJySYg2uU2r4YM6qaisw",
    "sender": "3Mx7kNAFcGrAeCebnt3yXceiRSwru6N3XZd",
    "recipient": "3Mz9N7YPfZPWGd4yYaX6H53Gcgrq6ifYiH7",
    "amount": 124935000,
    "height": 1551763,
    "status": "canceled"
  }
}
Lease Cancel Transaction JSON Representation

Field

Description

leaseId

Lease transaction ID.

chainId

Chain ID

lease

Parameters of canceled lease.

The lease structure does not need to be filled when sending a transaction, and it is not stored on the blockchain. The node returns this structure when providing transaction data via the REST API.

The fields that are common to all types of transactions are described in the transaction article.

Binary Format

See the lease cancel transaction binary format.

Ride Structure

The LeaseCancelTransaction structure is used for transaction handling in smart contracts.

Genesis

Genesis

Transaction type ID

Name

Description

\(1\)

Genesis transaction

Accrues DecentralCoins to an account upon the initial distribution during the creation of the blockchain.

Genesis Transaction

Genesis transaction accrues DecentralCoins to account upon the initial distribution of DecentralCoins during the creation of the blockchain. The first block of the blockchain, the genesis block, consists of genesis transactions.

Binary Format

See the genesis transaction binary format.

Transaction Validation

A DecentralChain node validates each transaction in the following cases:

  • The node receives the transaction via the broadcast endpoint of Node extensions or gRPC server.

  • The node receives the transaction from another node of the blockchain network using the binary protocol.

  • The block generator adds the transaction to a block.

  • The node receives a block (or microblock) from another node in the network.

Full transaction validation includes the following checks:

  1. Transaction fields check including:

  1. Timestamp check: the transaction timestamp should be not more than \(2\) hours ago or \(1.5\) hours ahead from the current block timestamp.

  2. Transaction version check: all the features required to support this version should be activated.

  3. Transaction type check: all the features required to support this type should be activated.

  4. Check of token amounts: the values must be non-negative.

  5. Check different fields depending on the transaction type.

  1. Sender’s balance check.

  1. The sender should have enough funds to pay the fee. If a sponsored asset is used for the fee, the sponsor’s balance is also checked.

  2. Depending on the type of transaction, the sender should have enough assets for transfer or for payments attached to the invoke script transactions. Order senders in the exchange transaction should have enough funds to exchange.

  1. The sender’s signature verification

  1. For ordinary accounts (without script).

  2. For account script execution if the sender is a smart account.

  3. For verifier function execution if the sender is dApp.

  4. A similar check is performed for orders in an exchange transaction.

  1. For the invoke script transaction:

  1. Calculation of the result of dApp callable function.

  2. dApp balance check: dApp account should have enough funds for dApp script actions.

  3. Check that the transaction fee is not less than the minimum fee based on script actions.

  1. Execution of asset scripts if the transaction uses smart assets, including scripts of assets used in dApp script actions.

When receiving the transaction via the broadcast endpoint, or adding a transaction to a block, or receiving a block over the network, the node performs full validation of the transaction. When receiving an invoke script transaction over the network, the node performs calculations of the callable function (check 4.1) up to the threshold for saving unsuccessful transactions.

Validation Result

When the transaction is received via broadcast or over the network:

  • If one of the checks fails, the transaction is discarded.

  • If all the checks passed, the transaction is added to the UTX pool, which is the list of transactions waiting to be added to the block.

When adding the transaction to the block, the result of validation depends on the transaction type.

For the invoke script transaction:

  • If one of the checks 1–3 failed, the transaction is discarded.

  • If checks 1–3 passed, and the calculation of the result of the dApp callable function (check 4.1) failed with an error or throwing an exception before the complexity of performed calculations exceeded the threshold for saving failed transactions, the transaction is also discarded.

  • If checks 1–3 passed but checks 4–5 failed and besides the result of the callable function is calculated successfully or the complexity exceeded the threshold, the transaction is saved on the blockchain but marked as failed: «applicationStatus»: «script_execution_failed». The sender is charged the transaction fee. The transaction doesn’t entail any other changes to the state of the blockchain.

  • If all checks passed, the transaction is saved on the blockchain as successful: «applicationStatus»: «succeeded» and the sender is charged the fee.

For the exchange transaction:

  • If one of the checks 1–3 failed, the transaction is discarded.

  • If checks 1–3 passed but check 5 failed, the transaction is saved on the blockchain but marked as failed: «applicationStatus»: «script_execution_failed». The sender of the transaction (matcher) is charged the transaction fee. The transaction doesn’t entail any other changes in balances, in particular, the order senders don’t pay the matcher fee.

  • If all checks passed, the transaction is saved on the blockchain as successful: «applicationStatus»: «succeeded». The matcher is charged the transaction fee as well as the order senders are charged the matcher fee.

For the other transactions:

  • If one of the checks fails, the transaction is discarded.

  • If all checks passed, the transaction is saved on the blockchain as successful and the sender is charged the fee.

Block

A block is a link in the chain of the blockchain. Block contains transactions. A block has its height.

The maximum block size is \(1\) MB. The maximum total complexity of scripts in transactions of the block is \(2,500,000\). The complexity of all executed scripts is taken into account: dApp scripts, account scripts, and asset scripts.

Block Generation

A block generation is a creation of a new block on the blockchain. Blocks are generated by generating nodes according to FPoS algorithm and the DecentralChain-M5 protocol. The block generator signs the block headers only. The block headers contain the merkle root hash of the block transactions. This makes it possible to verify the block headers apart from transactions and to provide evidence of the presence of transactions in the block without the presence of all transactions. See details in the transactions root hash article.

Base Target

The base target is the variable in the average block generation time formula that adjusts block generation time to \(60\) seconds.

Generation Signature

Generation signature is the variable in the average block generation time formula. It is used to check whether the current generating node is eligible to generate the next block. The generation signature is calculated using VRF (verifiable random function with short proofs and keys) — a pseudo-random function that uses a message and the private key of an account to provide a non-interactively verifiable proof for the correctness of its output.

This improvement allows resisting stake grinding attacks aimed at influencing block generation randomness to skip miner’s opportunity to create a block. The use of VRF makes signature generation unpredictable because of the need to know the private key for calculation. Only the holder of the private key can compute the hash, but verifying the correctness of the hash using the public key from block header is available to anyone.

The VRF contains calculateVRF function, which calculates proof for some message, and verifyVRF function, which verifies proof from calculateVRF function with a message and the public key of the signer. Considering that a block’s generation signature is equal to calculateVRF output for a previous generation signature with account private key sk (of generator of \(i+1\) th block):

generationSignaturei+1 = VRFproof = calculateVRFsk(VRFi)

The output of calculateVRF function is a VRF proof, which means that the validity of the signature can be checked. The output of function verifyVRF(pk \(_i\), generationSignature \(_i\)) is used to define the time delay between \(i+99\) and \(i+100\) blocks for concrete block generator.

Block Height

The block height is a sequence number of a block in the blockchain.

Block Signature

A block signature is a hash that a generating node acquires when it signs the generated block with the private key of the account from the node’s wallet.

Block Timestamp

A block timestamp is a time of block generation. The time is specified in milliseconds that have passed since the beginning of the unix epoch.

When the node receives a new block from the blockchain network, it verifies that the timestamp value of the block does not outpace the UTC time by more than \(100\) milliseconds. The timestamp value of the block is validated by nodes using the formula from FPoS.

Genesis Block

A genesis block is the first block of the blockchain. A genesis block contains one or more genesis transactions. There is one genesis block in the blockchain.

Transactions Root Hash

The transactionsRoot field in the block header contains the root hash of the Merkle tree of transactions of the block. The root hash is the proof that the block contains all the transactions in the proper order. The transactions root hash in the block header has the following purposes:

  • To prove the integrity of transactions in the block without presenting all transactions.

  • To sign the block header only, separately from its transactions.

transactions Root Сalculation

_images/10_transactionsRoot-Calculation.png
  1. The hash of each transaction in the block is calculated. For example:

  • \(H_A\) = hash(\(T_A\))

  • \(H_B\) = hash(\(T_B\))

  1. Each pair of adjacent hashes is concatenated, and the hash is calculated for each resulting concatenation:

  • \(H_{AB}\) = hash(\(H_A\) + \(H_B\))

  • If the last hash does not have a pair, it is concatenated with the zero byte hash: \(H_{GH}\) = hash(\(H_G\) + hash(0))

  1. Step 2 is repeated until the root hash is obtained:

  • \(H_{ABCDEFGH}\)

  • The root hash is written in the transactionsRoot field.

If the block is empty, then transactionsRoot = hash(0). DecentralChain blockchain uses BLAKE2b-256 hashing function.

Proof of Transaction in Block

Let’s suppose that side \(1\) stores the full blockchain data and side \(2\) stores the block headers only. To prove that the block contains a given transaction, side \(1\) provides the following data:

  • T: Transaction to check.

  • merkleProofs: Array of sibling hashes of the Merkle tree, bottom-to-top.

  • index: Index of the transaction in the block.

<<<<<<< HEAD .. image:: _static/02_intermediate/images/11_Proof-of-Transaction-in-Block.png ======= .. image:: _static/02_intermediate/images/image.jpg >>>>>>> b83a891fea7eef2d472ac2e336795eea50776d03

For example, for the \(T_D\) transaction:

  • merkleProofs = [ \(H_C\), \(H_{AB}\), \(H_{EFGH}\) ]

  • index = \(3\)

Side 2 checks the proof:

  1. It calculates the hash of the transaction being checked (all the transaction data is hashed, including the signature): \(H_D\) = hash(\(T_D\))

2. It concatenates the current hash with the corresponding hash of the merkleProofs array and calculates the hash of concatenation. index determines in which order to concatenate the hashes:

  • If the nth bit of index from the end is \(0\), then the order is: the current hash + the nth hash of the merkleProofsarray (proof hash is on the right).

  • If the nth bit is \(1\) , the order is: the nth hash of the merkleProofsarray + the current hash (proof hash is on the left). For example, index = \(3_{10}\) = \(11_2\) , thus:

    • merkleProofs[0] = \(H_{C}\) is on the left,

    • merkleProofs[1] = \(H_{AB}\) is on the left,

    • merkleProofs[2] = \(H_{EFGH}\) is on the right.

  1. It repeats step 2 until the root hash is obtained: \(H_{ABCDEFGH}\)

  2. It compares the root hash obtained with the already known transactionsRoot from the block header. If the hashes match, then the transaction exists in the block.

Tools

The following Node API methods accept transaction IDs and provide the proof that the transaction is in a block for each transaction:

  • GET /transactions/merkleProof

  • POST /transactions/merkleProof

The methods are described in the transaction article. You can check a transaction on the same blockchain without using a root hash, since the DecentralChain nodes store the entire blockchain data, including all transactions. Use the following built-in Ride function:

transactionHeightById(id: ByteVector): Int|Unit

The function returns the block height if the transaction with the specified ID exists. Otherwise, it returns a unit. See the function description in the blockchain functions article. To check a transaction in a block on the external blockchain you can use the following built-in Ride function:

createMerkleRoot(merkleProofs: List[ByteVector], valueBytes: ByteVector, index: Int): ByteVector

This function is applicable if the external blockchain uses the same algorithm for calculating the root hash of transactions. The createMerkleRoot function calculates the root hash from the transaction hash and sibling hashes of the merkle tree (see Steps 1–3). To check a transaction in a block, compare the calculated root hash with the transactionsRoot value in the block header.

Node

A node is a host connected to the blockchain network. Node functions are:

Generating Node

Generating node is a node that generates blocks. Each generating node is a validating node. Generating account is an account that a node uses for signing generated blocks. A node can generate blocks if the following conditions are met:

  • The node’s generating balance is at least \(10000\) DecentralCoins. This means that the account balance in DecentralCoins, taking into account leasing, was not less than \(10000\) DecentralCoins in each of the last \(1000\) blocks (more details in the account balance article). The greater the generating balance, the higher is your chance of being eligible to generate the next block.

  • Node’s account is not a smart account or dApp.

  • Block generation is not disabled in node settings. By default, block generation is enabled.

  • The node is connected to at least the number of peers specified in the required parameters (\(1\) by default).

Validating Node

A validating node is a node that validates transactions.

Generator’s Income

A node’s income from adding a new block to the blockchain consists of the following amounts:

  1. Block reward: The current reward size is \(6\) DecentralCoins but it can be changed by voting, see the block reward article.

  2. \(40\%\) of the total transaction fees in the current block. The exact value is calculated as follows:

  • \(\sum_{i}^{} 2 * (\frac{f_i}{5})\)

  • Here f \(_i\) is the fee for the \(i\)-th transaction. For each transaction fee, an integer division by \(5\) is performed, then a multiplication by \(2\), and finally they are summed up.

  1. \(60\%\) of the total transaction fees in the previous block.

  • \(\sum_{i}^{} (f_i - 2 * (\frac{f_i}{5}))\)

  • The block generator receives exactly the part of the fee that the previous block generator did not receive.

If the transaction fees are specified in a sponsored asset, then the block generators receive the fee equivalent in DecentralCoins instead of the fee (as a general rule, in a \(\frac{40}{60}\) ratio):

feeInDecentralCoins = feeInSponsoredAsset × 0.001 / minSponsoredAssetFee

minSponsoredAssetFee is the amount of the sponsored asset equivalent to \(0.001\) DecentralCoins. The sponsor sets this value when enabling sponsorship. For details, see the sponsored fees article.

Block Reward

Block reward is a blockchain feature under which generating nodes receive a fixed fee in DecentralCoins for each generated block. Block rewards are paid due to the additional issue of the DecentralCoin token. The community of generating nodes can change the size of reward through voting.

Current Reward Size

You can view the current reward size by making a request to the Node REST API. In response to the request, a JSON file is returned, the value of the currentReward field of which is the current block reward size in Decentralites.

Example of response:

{
  "height": 1742254,
  "totalDecentralCoinsAmount": 10001353000000000,
  "currentReward": 600000000,
  "minIncrement": 50000000,
  "term": 100000,
  "nextCheck": 1839999,
  "votingIntervalStart": 1830000,
  "votingInterval": 10000,
  "votingThreshold": 5001,
  "votes": {
    "increase": 0,
    "decrease": 0
  }
}

In the example above, the value of the JSON’s currentReward field is 600,000,000 Decentralites— i.e. it’s 6 DecentralCoins.

The Change of Block Reward Size Over Time

Every \(100,000\) blocks, i.e. approximately every \(70\) days, a new voting for the current reward size change begins among the generators. The voting duration is \(10,000\) blocks. During this time, generating nodes vote to increase, decrease or leave the current reward size unchanged. The elected reward size remains unchanged for \(100,000\) blocks following the end of voting.

Voting

A generating node specifies the new desired reward size via settings in the node configuration file, the setting value is specified in Decentralites. If the value is greater than the current reward size, then the generator votes for the current reward size increase; if the value is smaller — for the decrease. If the setting value is not specified in the configuration file, then the generator votes for keeping the current reward size. When a node generates a block, it writes into that block the value of the desired reward size specified in the setting from its own node configuration file. If the setting value is not specified in the configuration file, then \(-1\) is written to the block. During the voting time in \(10,000\) blocks, a single node can generate several blocks, therefore one node can vote several times. How often a node generates blocks is determined by the LPoS consensus.

How Votes are Counted

To count the votes, all \(10,000\) blocks generated during the voting period are inspected. If either \(-1\) or the value that is equal to the current reward size is recorded to the block, then the generator votes for keeping the current reward size. If the value recorded to the block is greater than the current reward size, then the generator votes for the current reward size increase; if the value is smaller — for the decrease. The block reward is increased/decreased only if more than half of the \(10,000\) votes — i.e. \(5,001\) votes or more — were given for increase/decrease. The amount of the current reward is increased/decreased by \(0.5\) DecentralCoins.

Example 1

At the blockchain height of \(2,000,000\), the block reward equals \(5\) DecentralCoins. At the height of \(2,090,000\), another voting starts. During the \(10,000\) blocks of voting \(6,000\) votes were given for reward increase, \(1,000\) — for decrease, \(3,000\) — for keeping the current reward size. From the height of \(2\), \(100,000\) to the height of \(2,199,999\), the new reward size will be \(5.5\) DecentralCoins, because the reward change step is \(0.5\) DecentralCoins. The next voting will take place from the height of \(2,190,000\) to \(2,199,999\).

Example 2

At the blockchain height of \(2,100,000\), the block reward equals \(5.5\) DecentralCoins. At the height of \(2,190,000\), another voting starts. During the \(10,000\) blocks of voting \(4,500\) votes were given for reward increase, \(4,000\) — for decrease, \(1,500\) — for keeping the current reward size. From the height of \(2,200,000\) to the height of \(2,299,999\), the «new» reward size will be the same — \(5.5\) DecentralCoins. Although the highest number of votes were given for the reward increase, it was not enough to change the current reward size. In order for the current reward size to be increased, at least \(5,001\) votes must be given for the increase. The next voting will take place from the height of \(2,290,000\) to \(2,299,999\).

Leased Proof of Stake

Leased Proof of Stake (LPoS) is an enhanced type of proof of stake consensus algorithm by which the DecentralChain blockchain network aims to achieve the distributed consensus to secure the network.

Leasing Benefits for the Node Owner

Nodes can use the leased tokens to generate blocks and get the mining reward. For that purpose, the generating balance of a node must be at least \(10000\) DecentralCoins.

Leasing Benefits for the Token Holder

LPoS allows the token holders to lease their tokens to the DecentralChain nodes and earn a percentage of the payout as a reward. By using LPoS, lessors will be able to participate in the process of generating new blocks because the larger the amount that is leased to a DecentralChain node, the higher the chances for that node to be selected to generate the next block. If that node is selected, then the leaser will receive a reward. When the user starts leasing the tokens, those leased tokens are locked and remain in the same address with the full control of their owner (they are not transferred to the node, they just remain unspendable until the lease is canceled by the lessor). The only thing to consider when leasing is to choose the right node operator, as the operator’s node may work with different efficiency and send back different percentages as rewards.

Rewards
  • The node owner may send the lessor a part of the rewards according to his conditions.

  • The more transactions that are made on the network, the more rewards the lessors get.

  • These rewards mostly are in DecentralCoins but also they can be in the form of different tokens with the unique DecentralCoins feature where different tokens can be accepted as a fee.

LPoS Transactions

To start leasing, the token holder needs to create a lease transaction and specify the recipient address (node address) along with the amount of DecentralCoins to lease. There are two types of transactions which are used in the LPoS:

Create a Lease

You can use Decentral.Exchange online to create a lease.

  • Make sure you are logged into your account. On the main screen navigate to Wallet > Leasing.

  • On the next screen click Start Lease and then select the recipient between the list of nodes and indicate the amount you want to lease.

  • Verify all the information and click Start Lease again to confirm.

Order

Order is the instruction from the account to matcher to buy or sell a token on the exchange.

Asset Pair

Each order contains amount asset / price asset pair, also called asset pair.

Example

"assetPair": {
    "amountAsset": "3QvxP6YFBKpWJSMAfYtL8Niv8KmmKsnpb9uQwQpg8QN2",
    "priceAsset": "null"
}

Asset Pair Fields

Asset Pair Fields

Field name

Description

amountAsset

ID of the pair’s first asset, that the order’s sender wants to buy or sell.

priceAsset

ID of the pair’s second asset, in which the price of the order is expressed. null value means that asset is DecentralCoins.

Order’s Amount and Price

In the user interface, the amount and price are usually presented as values with a fractional part (for example, \(0.74585728\) DecentralCoins), i.e. in the denormalized form. The denormalized form is convenient for humans, but not for calculations. To solve the problem of calculation accuracy, the normalization is performed.

In the user interface, the amount and price are usually presented as values with a fractional part (for example, \(0.74585728\) DecentralCoins), i.e. in the denormalized form. The denormalized form is convenient for humans, but not for calculations. To solve the problem of calculation accuracy, the normalization is performed, i.e. amount and price are represented as an integer. So, \(0.74585728\) DecentralCoins is \(0.74585728 × 10^{8}\) or \(74585728\) Decentralites. In this case, the exponent is \(8\), because DecentralCoins has \(8\) decimals after the decimal point. Other assets may have different amount of decimals. For example, TDX has 2 decimals.

Amount

Consider buying \(2.13\) TDX at the price of \(0.35016774\) DecentralCoins for one TDX. Here the asset pair is TDX / DecentralCoins. The amount in the order is the number of units sold or bought in conventional «pennies». This value in the current case is \(213\), since \(2.13\) TDX \(= 2.13 × 10^{2}\) = 213` «pennies» of TDX. So, to bring the amount to the normalized form, it is multiplied by \(10^{amountAssetDecimals}\).

Price

Price is the value of 1 unit of the amount asset, expressed in the price asset. In the TDX / DecentralCoins example above, this is the price in DecentralCoins for 1 TDX. To normalize price, it is multiplied by:

  • In orders of versions 1, 2, 3: \(10^{(8 + priceAssetDecimals - amountAssetDecimals)}\).

  • In orders of version 4: at \(10^{8}\).

The exponent of \(8\) is selected because there cannot be an asset with the exceeding quantity of decimals on the DecentralChain blockchain. The matcher algorithm has a limitation in relation to price: the last N digits of the normalized price must be zeros (N is price_decimals minus amount_decimals). If this is not so, then the matcher rejects the order on placement.

Price Asset Quantity Calculation

The quantity of price asset in normalized form which:

  • Will be given by sender if order is BUY.

  • Will be acquired by sender if order is SELL.

Is calculated by the following formula: amount × price × \(10^{(priceAssetDecimals - amountAssetDecimals - 8)}\).

  • In orders of versions 1, 2, 3: amount × price × \(10^{-8}\)

  • In orders of version 4: amount × price × \(10^{(priceAssetDecimals - amountAssetDecimals - 8)}\).

If the result of the calculation is a value with a fractional part, then the fractional part is discarded. Designations in the above formula:

  • Amount — amount in normalized form.

  • Price — price in normalized form.

  • PriceAssetDecimals — the number of decimal places of the price asset.

  • AmountAssetDecimals — the number of decimal places of the amount asset.

Order Cancellation

The order sender may cancel the order before it is executed. Unexecuted orders are automatically canceled at the date and time specified by the order sender.

Order Expiration Date

Order expiration date is the date and time of automatic cancellation of an unexecuted order. The date is specified in milliseconds which have passed since the beginning of the unix epoch. The expiration time can’t be earlier than matcher time + \(1\) minute and later than matcher time + \(30\) days.

Order Timestamp

Order timestamp is the time when the matcher added the order to the order book. The time is specified in milliseconds that have passed since the beginning of the unix epoch.

Order Binary Format

See the order binary format page.

Oracle

Oracle is a data provider from the outside world on the blockchain.

Sources of the Outside World

Software oracles handle data accessible on the web. For example, the temperature, costs of products and merchandise, flight or train delays, etc. The information originates from online sources, e.g. API. The product prophet extricates the required data and pushes it into the blockchain.

Hardware oracles track real-world objects with devices and sensors. For example, a video camera with an analytics function virtual line crossing tracks vehicles entering a specific zone. If an event is detected, the oracle writes about it on the blockchain. Based on the data of such oracle, some script of decentralized application on the blockchain may be triggered. In this case, for example, a fine and the write-off of tokens from the account of the vehicle owner. But it is not in oracle scope, it is in the scope of the script that is based on the data of such an oracle.

Human oracles imply that the data is entered by a human being.

Oracles Issue

The oracle is a way of connecting the blockchain with the outside world. The major problem that is solved by the usage of oracles is the very point that blockchains can only access data that is stored on the blockchain. Here, in blockchain, the point is that it is important that decentralized applications can only access data that is stored on the blockchain so that every execution of the script leads to the same result at a given point in time. Therefore, decentralized applications are not able to access data from outside the blockchain, e.g., provided by web services or other external sources of data. Nevertheless, many interesting applications need access to the outside world, e.g., decentralized applications for insurances, decentralized betting systems, financial services and so forth.

Here, the solution is quite straightforward: if external data is necessary for the execution of a decentralized application, this data needs to be stored on the blockchain. To achieve this, there are usually small programs implemented that access the necessary data and write it to the blockchain. Those little programs are called oracles.

Consensus of Oracles

One source may be unsafe if it does not have the authority or high rating. However, several oracles can be used to stay away from the monopoly and be safer. For example, get information from ten oracles and only if the data of \(6\) out of \(10\) oracles coincide, to accept them. This is the consensus of the oracles.

Mainnet, Testnet, Stagenet

Connecting Node to Blockchain Network

You can launch your node in any blockchain network. Select the network in the node configuration file.

  • For more information about the configuration file, see the node configuration article.

  • For installing a node, see the install DecentralChain node article.

  • For starting your own blockchain network, see the custom blockchain article.

Chain ID

Chain ID is a symbol that is passed over a network during a handshake and allows nodes not to connect to the nodes of other networks. The chain ID is used while building account addresses, therefore, an address on one blockchain network cannot be used on another network. The chain ID is also indicated in transactions so it is impossible to move transactions between different blockchain networks.

Chain ID

Blockchain Network

Chain ID

Mainnet

W or \(87\) (ASCII code of W).

Testnet

T or \(84\) (ASCII code of T).

Stagenet

S or \(83\) (ASCII code of s).

Tools

API of Pool of Public Nodes

Chain ID is a symbol that is passed over a network during a handshake and allows nodes not to connect to the nodes of other networks. The chain ID is used while building account addresses, therefore, an address on one blockchain network cannot be used on another network. The chain ID is also indicated in transactions so it is impossible to move transactions between different blockchain networks.

API of Pool of Public Nodes

Mainnet

https://mainnet-node.decentralchain.io

Testnet

https://testnet-node.decentralchain.io

Stagenet

TBA

Data Service API

Data Service API

Mainnet

https://data-service.decentralchain.io

Testnet

TBA

Stagenet

TBA

Decentral.Exchange

Decentral.Exchange is a decentralized exchange.

Decentral.Exchange

Mainnet

https://decentral.exchange/

Testnet

TBA

Stagenet

TBA

API of Decentral.Exchange Matcher

The addresses for order sending and market data obtaining are as follows:

API of Decentral.Exchange Matcher

Mainnet

https://mainnet-matcher.decentralchain.io/api-docs/index.html

Testnet

https://matcher.decentralchain.io/api-docs/index.html

Stagenet

TBA

DecentralChain Explorer

DecentralChain Explorer is a service for browsing blockchain data.

DecentralChain Explorer

Mainnet

Go to http://decentralscan.com/ and click the three lines, then switch to Mainnet.

Testnet

Go to http://decentralscan.com/ and click the three lines, then switch to Testnet.

Stagenet

Go to http://decentralscan.com/ and click the three lines, then switch to Stagenet.

Faucet: Obtaining Tokens

Faucet: Obtaining Tokens

Mainnet

Testnet

TBA

Stagenet

TBA

Protocols & Data Formats

Cryptographic Practical Details

Description

This section describes all the details of cryptographic algorithms which are used to:

  • Create private and public keys from seed.

  • Create addresses from public keys.

  • Create blocks and transactions signing.

We use Blake2b256 and Keccak256 algorithms (in the form of hash chain) to create cryptographic hashes. And Curve25519 (ED25519 with X25519 keys) to create and verify signatures. Base58 to create the string form of bytes.

Bytes Encoding Base58

All arrays of bytes in the project are encoded by Base58 algorithm with Bitcoin alphabet to make it ease human readable (text readability).

Example

The string teststring is coded into the bytes \([5, 83, 9, -20, 82, -65, 120, -11]\). The bytes \([1, 2, 3, 4, 5]\) are coded into the string 7bWpTW.

Creating a Private Key From a Seed

A seed string is a representation of entropy, from which you can re-create deterministically all the private keys for one wallet. It should be long enough so that the probability of selection is an unrealistic negligible. In fact, seed should be an array of bytes but for ease of memorization lite wallet uses Brainwallet, to ensure that the seed is made up of words and easy to write down or remember. The application takes the UTF-8 bytes of the string and uses them to create keys and addresses. For example,

seed string manage manual recall harvest series desert melt police rose hollow moral pledge kitten position add

After reading this string as UTF-8 bytes and encoding them to Base58, the string will be coded as:

xrv7ffrv2A9g5pKSxt7gHGrPYJgRnsEMDyc4G7srbia6PhXYLDKVsDxnqsEqhAVbbko7N1tDyaSrWCZBoMyvdwaFNjWNPjKdcoZTKbKr2Vw9vu53Uf4dYpyWCyvfPbRskHfgt9q

A seed string is involved with the creation of private keys. To create a private key using the official web wallet or the node, to \(4\) bytes of int “nonce” field (big-endian representation), which initially has a value of \(0\) and increases every time you create the new address, should be prepended to seed bytes. Then we use this array of bytes to calculate hash keccak256(blake2b256(bytes)). This resulting array of bytes we call account seed, from it you can definitely generate one private and public key pair. Then this bytes hash passed in the method of creating a pair of public and private key of Curve25519 algorithm. DecentralChain uses Curve25519-ED25519 signature with X25519 keys (montgomery form), but most embedded cryptography devices and libraries don’t support X25519 keys. There are libraries with conversion functions from:

  • ED25519 keys to X25519 (Curve25519) crypto_sign_ed25519_pk_to_curve25519(curve25519_pk, ed25519_pk) for public key.

  • Crypto_sign_ed25519_sk_to_curve25519(curve25519_sk, ed25519_skpk) for private key.

NOTE: Not all random \(32\) bytes can be used as private keys (but any bytes of any size can be a seed). The signature scheme for the ED25519 introduces restrictions on the keys, so create the keys only through the methods of the Curve25519 libraries and be sure to make a test of the ability to sign data with a private key and then check it with a public key, however obvious this test might seem. There are valid Curve25519 realizations for different languages:

Also some Curve25519 libraries (as the one used in our project) have the Sha256 hashing integrated, some not (such as most of c/c++/python libraries), so you may need to apply it manually. Note that the private key is clamped, so not any random \(32\) bytes can be a valid private key.

Example

Brainwallet seed string

manage manual recall harvest series desert melt police rose hollow moral pledge kitten position add

As UTF-8 bytes encoded

xrv7ffrv2A9g5pKSxt7gHGrPYJgRnsEMDyc4G7srbia6PhXYLDKVsDxnqsEqhAVbbko7N1tDyaSrWCZBoMyvdwaFNjWNPjKdcoZTKbKr2Vw9vu53Uf4dYpyWCyvfPbRskHfgt9q

Account seed bytes with nonce \(0\) before apply hash function in Base58

1111xrv7ffrv2A9g5pKSxt7gHGrPYJgRnsEMDyc4G7srbia6PhXYLDKVsDxnqsEqhAVbbko7N1tDyaSrWCZBoMyvdwaFNjWNPjKdcoZTKbKr2Vw9vu53Uf4dYpyWCyvfPbRskHfgt9q

blake2b256(account seed bytes)

6sKMMHVLyCQN7Juih2e9tbSmeE5Hu7L8XtBRgowJQvU7

Account seed ( keccak256(blake2b256(account seed bytes)))

H4do9ZcPUASvtFJHvESapnxfmQ8tjBXMU7NtUARk9Jrf

Account seed after Sha256 hashing (optional, if your library does not do it yourself)

49mgaSSVQw6tDoZrHSr9rFySgHHXwgQbCRwFssboVLWX

Created private key

3kMEhU5z3v8bmer1ERFUUhW58Dtuhyo9hE5vrhjqAWYT

Created public key

HBqhfdFASRQ5eBBpu2y6c6KKi1az6bMx8v1JxX4iW1Q8

Creating Address from a Public Key

Our network address obtained from the public key depends on the byte chainID (“T” for Testnet, “W” for Mainnet, “S” for Stagenet), so different networks obtained a different address for a single seed (and hence public keys).

Example

For the public key:

HBqhfdFASRQ5eBBpu2y6c6KKi1az6bMx8v1JxX4iW1Q8

Created public key:

3PPbMwqLtwBGcJrTA5whqJfY95GqnNnFMDX

Signing

Curve25519 is used for all the signatures in the project. The process is as follows: create the special bytes for signing for transaction or block, then create a signature using these bytes and the private key bytes. For the validation of signatures it’s enough with signature bytes, signed object bytes and the public key. Do not forget that there are many valid (not unique!) signatures for a one array of bytes (block or transaction). Also you should not assume that the ID of the block or transaction is unique. The collision can occur one day! They have already taken place for some weak keys.

Example

Transaction Data:

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

Asset id

BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG

Amount

\(1\)

Fee

\(1\)

Fee asset id

BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG

Timestamp

\(1479287120875\)

Attachment (as byte array)

\(1[1, 2, 3, 4]\)

Bytes:

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

Amount’s asset flag (0-DecentralCoins, 1-Asset)

Byte

\(33\)

\(1\)

\(1\)

\(2\)

\(4\)

Amount’s asset ID (*if used)

Bytes

\(34\)

\(0 (32*)\)

BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG

\(5\)

Fee’s asset flag (0-DecentralCoins, 1-Asset)

Byte

\(34 (66*)\)

\(1\)

\(1\)

\(2\)

\(6\)

Fee’s asset ID (**if used)

Bytes

\(35 (67*)\)

\(0 (32**)\)

BG39cCNUFWPQYeyLnu7tjKHaiUGRxYwJjvntt9gdDPxG

\(7\)

Timestamp

Long

\(35 (67\_ ) (99*\_ )\)

\(8\)

\(1479287120875\)

11frnYASv

\(8\)

Amount

Long

\(43 (75\_ ) (107*\_ )\)

\(8\)

\(1\)

\(11111112\)

\(9\)

Fee

Long

\(51 (83\_ ) (115*\_ )\)

«\(8\)»

\(1\)

\(11111112\)

\(10\)

Recipient’s address

Bytes

\(59 (91\_ ) (123*\_ )\)

\(26\)

3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8

\(11\)

Attachment’s length (N)

Short

\(85 (117\_ ) (149*\_ )\)

\(2\)

\(4\)

\(15\)

\(12\)

Attachment’s bytes

Bytes

\(87 (119\_ ) (151*\_ )\)

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

Calculating Transaction ID

Transaction ID is not stored in the transaction bytes and for most transactions (except Payment) it can be easily calculated from the special bytes for signing using blake2b256(bytes_for_signing). For payments, the transaction ID is just the signature of this transaction.

DecentralChain-M5 Solution

Reasoning

The maximum rate of transactions in blockchain systems is limited by the choice of two parameters: block size and block interval.

The block interval defines the average amount of time that passes between the creation of two blocks. If we reduce this time, forks will appear more frequently, which will lead to either non-resolved forks or to decreased throughput since a considerable amount of time would be spent on resolving these forks. Larger blocks lead to huge network usage spikes during block propagation, which in turn will lead to throughput problems and huge forks.

DecentralChain-M5 Solution With Technical Details

DecentralChain addresses this issue by allowing the miner to continuously farm a block during the time of mining. This continuously increasing block is called liquid block, which becomes immutable when the next block referencing it is built and appended. A liquid block consists of a key block and chain of microblocks. The process of creating liquid block goes as follows:

  • When a miner node observes it has the right to create a block, it creates and sends keyBlock, which is regularly just an empty block.

  • After that, it creates and sends microblocks every \(3\) seconds. Microblock is very similar to a regular block: it’s a non-empty pack of transactions, which references its parent: previous microblock or key block.

  • Microblocks are continuously mined and propagated to the network until a new key block, referencing the current liquid block appears.

Microblock Structure
generator: PublicKeyAccount
transactionData: Seq[Transaction]
prevResBlockSig: BlockId
totalResBlockSig: BlockId
signature: ByteStr

totalResBlockSigis the new total signature of a block with all transactions from blockId=prevResBlockSigand owntransactionData. This means that having a_liquid block_consisting of 1_keyblock_and 3_microblock_s: KEYBLOCK() <-MICRO1(tx1,tx2) <-MICRO2(tx3,tx4) <-MICRO3(tx5,tx6) We have 4 versions of last block:

Microblock Structure

ID

Transactions

KEYBLOCK.uniqueId

MICRO1.totalResBlockSig

tx1,tx2

MICRO2.totalResBlockSig

tx1,tx2,tx3,tx4

MICRO3.totalResBlockSig

tx1,tx2,tx3,tx4,tx5,tx6

Next miner can reference any of these ids in its keyBlock.

Economy

For a miner, it might seem a good idea to reference KEYBLOCK from previous example and pack all txs from microblocks to its own (micro)block(s). In order to make “stealing” transactions less profitable than referencing the best-known version of liquid block(= the last known microblock), we change the mechanics of fees: After activating M5, miner will receive \(40\%\) of fees from the block it creates and \(60\%\) of fees from the block he references.

Configuration

The following miner parameters can be tuned(though it’s best not to change them in order to maximize final version of your liquid block in the resulting blockchain):

  • KeyBlock size (maxTransactionsInKeyBlock, default = \(0\)). If changed, it won’t be rebroadcasted and the usual extension requesting mechanics will be used.

  • Microblock mining interval (microBlockInterval, default = \(3\) s).

  • Max amount of transactions per microblock (maxTransactionsInMicroBlock, default = \(200\)).

  • Miner will try to reference the best-known microblock with at leastminMicroBlockAgeage(default = \(3\) s). This is required in order for a miner to reference already-propagated block so its key block doesn’t get orphaned.

  • Microblock synchronization mechanism can be tuned with waitResponseTimeout(default = \(2\) s), processedMicroBlocksCacheTimeout(default = \(10\) s),invCacheTimeout(default = \(10\) s) which are basically time of awaiting a microblock and times to cache a processed microblock ids and a list of nodes which have a microblock(by id).

API changes

  • Upon applying every microblock, the last block gets changed, which means/blocks/lastand/blocks/at/…will reflect that.

  • /peers/blacklistednow expose ban reason, one can clear a node’s blacklist via/peers/clearblacklist

  • /debug/and/consensus/section are expanded, _stateHash _doesn’t take _liquid block _into consideration.

DecentralChain-M5 Protocol

Scalability Limits and Challenges in Current Blockchain Systems

Problem Statement and Motivation

Blockchains protocols have some scalability limits and challenges that tradeoff between throughput and latency. The current blockchain technology is not fast enough and does not scale to include more transactions into the system so we have a performance challenge to be considered. There is a united agreement between miners, consumers, and developers with several perspectives that we need to deploy scalability measures, and there has been an ongoing argument on how to improve Bitcoin’s scalability. Current proposals have focused on how big to make the blocks and how to handle the block size increases in the future.

All proposals suffer from a major scalability bottleneck: No matter what block size is chosen, the blockchain system can at best reach a proper transaction throughput, increasing from ~ \(3\) transactions per second to ~ \(7\) transactions per second. This is so far from the \(30,000\) transactions per second which are necessary to compete with the existing systems such as VISA transactions. The same major limitations apply to litecoin, Ethereum, and all other currencies that share Bitcoin’s blockchain protocol.

DecentralChain-M5 will address the scalability bottleneck by making the network reach the highest throughput depending on the network conditions. It will not only enhance the transaction throughput, it will also reduce transaction latencies. So it will be possible to get an initial transaction confirmation in seconds rather than in minutes.

Weaknesses of Current Proposals to Improve Scalability

Blockchain Systems can process transactions and the maximum rate of these transactions is limited by the choice of two parameters: block size and block interval.

  • The block interval defines the average amount of time that passes between the creation of two blocks. By deciding to reduce the block interval to solve the latency limit, the system will have less security (increase forks probability) due to the reason of new miners for every second which will lead to instability where the blockchain is subject to reorganization and the system is in disagreement (Figure 1). If we reduce the time per block, then we will have a situation where a significant number of blocks are solved in less time than it takes to relay a solved block throughout the network. So there will be no way to know which block is the «real» one and which one is a «fork» because the transactions that appeared to have multiple confirmations suddenly have fewer confirmations (or possibly go back to being unconfirmed).

<<<<<<< HEAD .. image:: _static/02_intermediate/images/12_Weaknesses-of-Current-Proposals-to-Improve-Scalability-1.png ======= .. image:: _static/02_intermediate/images/image.jpg >>>>>>> b83a891fea7eef2d472ac2e336795eea50776d03

Figure 1: Increasing block frequency with static block size will result in less security.

  • The throughput of a system is bounded by the maximum block size (given a fixed block interval), as the maximum number of included transactions is directly dependent on the block size.

  • Larger blocks do however cause slower propagation speeds, which causes more discarded blocks (orphaning risk). An unlimited blocksize could, for example, result in a DoS attack on the system by creating a block that takes a long time to validate. If the choice is to Increase block size in order to improve throughput, there will be Network spikes with longer time to propagate in the network (Figure 2).

<<<<<<< HEAD .. image:: _static/02_intermediate/images/13_Weaknesses-of-Current-Proposals-to-Improve-Scalability-2.png ======= .. image:: _static/02_intermediate/images/image.jpg >>>>>>> b83a891fea7eef2d472ac2e336795eea50776d03

Figure 2: Increasing block size with Static block frequency will lead to more discarded blocks and network spikes.

Brief Summary of Bitcoin-M5

It is a next-generation blockchain protocol which is an alternative bitcoin scaling solution that does not involve increasing the size of blocks or decreasing the block time interval. This reduces the risk of forks amongst other advantages. Bitcoin-M5 describes that the basic tradeoffs in Bitcoin can be reduced with an alternative blockchain protocol, offering a consensus delay and bandwidth limited only by the Network Plane. The protocol splits time into time periods(epoch). In each time period, a particular leader is responsible for serializing transactions (Figure 3). The leaders take the rule of generating blocks:

  • Key blocks for the election of a leader.

  • Micro blocks for ledger records.

<<<<<<< HEAD .. image:: _static/02_intermediate/images/14_Brief-Summary-of-Bitcoin-M5.png ======= .. image:: _static/02_intermediate/images/image.jpg >>>>>>> b83a891fea7eef2d472ac2e336795eea50776d03

Figure 3: Bitcoin-M5 time periods structure with serializing transactions.

DecentralChain-M5 Overlay

DecentralChain-M5 is based on the bitcoin next generation protocol that serializes transactions and offers important improvements in the transaction latency(lower latency) and bandwidth(higher throughput) in comparison to Bitcoin without sacrificing other properties. DecentralChain approaches this scalability matter by providing the miner with the ability to farm a block during the time of mining in a continuous approach. This block continues increments called liquid blocks. This liquid block is unchangeable over time once the next block referencing is created and appended. This approach increases effective bandwidth and speed of block creation, which is described as being “especially significant for businesses” using the DecentralChain-M5 protocol since it allows for conducting micro-transactions - without any delays that are typical with traditional blockchain systems. Furthermore, it allows the blockchain to withstand high loads, such as distribution of tokens following crowdsales and airdrops of bonus tokens. The speed of processing trading transactions on the exchange gets increased as well.

DecentralChain-M5 Operations

The main and core idea of DecentralChain-M5 is to split the Liquid block into two types, Key blocks and Micro blocks. The process of creating liquid block works as follows:

  • The miner node gets the permission to create a block.

  • The miner node creates and sends the key block (which does not contain transactions).

  • The miner node creates and sends the micro blocks (which contain transactions just as in normal blocks with a reference to previous micro blocks or key blocks) with a mining time interval of three seconds.

  • Miners will mine those micro blocks and propagate them directly to the network until the next new key block appears with a reference to the liquid block.

All of the transactions are part of the same block and are contributed all together. In between blocks, the traditional Bitcoin system appears idle to an onlooker, as miners are working to discover the next block, but without apparent progress on the consensus front. In contradiction, in DecentralChain-M5, the key-blocks can be small because they need to contain only the coinbase transaction, which defines the public key that the miner will be using to sign microblocks. Because a key-block requires proof of stake, miners can not just produce one and expropriate the leadership at will. Following the key-block, the lead miner can quickly issue microblocks, simply by signing them with the private key corresponding to the public key named in the key-block’s coinbase (Figure 4).

<<<<<<< HEAD .. image:: _static/02_intermediate/images/15_DecentralChain-M5-Operations.png ======= .. image:: _static/02_intermediate/images/image.jpg >>>>>>> b83a891fea7eef2d472ac2e336795eea50776d03

Figure 4: Key-blocks and Micro-blocks signing process.

Leader Blocks

They’re also called «Key Blocks», these blocks are generated with proof of stake but do not contain transactions. They serve as a leader election mechanism and contain a public key that identifies the chosen leader. Each block has a header that contains, among other fields, the unique reference of its predecessor which is a cryptographic hash of the predecessor header (either a key block or a microblock).

Micro Blocks

Once a node generates a key block it becomes the leader. As a leader, the node is allowed to generate microblocks at a set rate smaller than a predefined maximum. These micro blocks will contain the ledger entries with no requirement for any Proof of Stake and they’re generated by the elected leader in every block-generation cycle. This block-generation cycle is initiated by a leader block. The only requirement is to sign the micro blocks with the elected leader’s private key. The micro blocks can be generated at a very high speed by the elected leader(miner), thus resulting in increased performance and transaction speed.

For a microblock to be valid, all its entries must be valid according to the specification of the state machine, and the signature has to be valid. Figure 5 illustrates the structure. Note that microblocks do not affect the weight of the chain, as they do not contain proof of stake. When all micro blocks have been validated, they will be merged with their key block into one block.

DecentralChain-M5 Reward Mechanisms

Remuneration consists of two parts. First, each key block entitles its generator a set amount. Second, each ledger entry carries a fee. This fee is split by the leader that places this entry in a microblock and the subsequent leader that generates the next key block.

In order to motivate participants to follow the protocol, DecentralChain-M5 uses the following mechanisms: Each transaction pays a fee to the system, but unlike Bitcoin, this fee is distributed, with \(40\%\) to the leader, and \(60\%\) to the subsequent leader. Finally, if a leader forks the chain by generating two microblocks with the same parent, it is punished by revoking the subsidy revenue; whoever detects the fraud wins a nominal fee, (Figure 5).

<<<<<<< HEAD .. image:: _static/02_intermediate/images/16_DecentralChain-M5-Reward-Mechanisms.png ======= .. image:: _static/02_intermediate/images/image.jpg >>>>>>> b83a891fea7eef2d472ac2e336795eea50776d03

Figure 5: chain structure of the DecentralChain-M5 Protocol. Microblocks (circles) are signed with the private key matching with the public key in the last key block (squares). The fee is distributed \(40\%\) to the leader and \(60\%\) to the next one.

In practice, the remuneration is implemented by having each key block contain a single coinbase transaction that mints new coins and deposits the funds to the current and previous leaders. As in Bitcoin, this transaction can only be spent after a maturity period of \(100\) key blocks, to avoid non-mergeable transactions following a fork.

Fair Proof of Stake

In this model, the choice of account that has the right to generate the next block and receive the corresponding transaction fees is based on the number of tokens in the account. The more tokens that are held in the account, the greater the chance that account will earn the right to generate a block.

In DecentralChain, we are convinced that each participant in the blockchain should participate in the block generation process proportionally to his stake: we have decided to correct the PoS formula. At the moment we do not have the goal of completely changing the algorithm, since there is no need; we simply want to make some adjustments. We presented an improved PoS algorithm that makes the choice of block creator fair and reduces vulnerability to the multi-branching attacks, in accordance with the shortcomings of the current algorithm.

We analyzed the model of the new algorithm for its correspondence to the stake share and the share of blocks, and the results were positive. Also, the algorithm was analyzed for vulnerability to attacks, and results obtained with the new model were better than with the old one. The attacks’ results for the attacker were not so successful in terms of the profits gained. The number of forks and their length decreased.

Blockchain Data Types

The blockchain data types are the data types that are used to describe 02_intermediate of blockchain entities. Here’s a list of blockchain data types:

Blockchain Data Types

#

Keyword

Possible values

Variable size in bytes

\(1\)

Booleano

\(0\) and \(1\).

\(1\)

\(2\)

Byte

Integer from \(-128\) to \(127\) inclusive.

\(1\)

\(3\)

Int

Integer from \(-2,147,483,648\) to \(2,147,483,647\) inclusive.

\(4\)

\(4\)

Long

Integer from \(-9,223,372,036,854,775,808\) to \(9,223,372,036,854,775,807\) inclusive.

\(8\)

\(5\)

Short

Integer from \(-32,768\) to \(32,767\) inclusive.

\(2\)

\(6\)

Cadena de caracteres

From \(0\) to \(2,147,483,647\) characters inclusive.

From \(1\) to \(4\) bytes per character.

Formato Binario

Address Binary Format

Learn more about address.

Address Binary Format

Field order number

Field

Field type

Field size in bytes

Comments

\(1\)

Entity type

Byte

\(1\)

Value must be \(1\).

\(2\)

Chain ID

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(3\)

Account public key hash

Matriz de bytes

\(20\)

First \(20\) bytes of the result of the Keccak256 (Blake2b256 (publicKey)) hashing function. Here publicKey is the array of bytes of the account public key.

\(4\)

Checksum

Matriz de bytes

\(4\)

First \(4\) bytes of the result of the Keccak256 (Blake2b256 (data)) hashing function. Here data is the array of bytes of three fields put together: 1) Entity type. 2) Chain ID. 3) Account public key hash.

Alias Binary Format

Learn more about alias.

Alias Binary Format

Field order number

Field

Field type

Field size in bytes

Comments

\(1\)

Entity type

Byte

\(1\)

Value must be \(2\).

\(2\)

Chain ID

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(3\)

Number of characters in the alias

Short

\(2\)

\(4\)

Alias

Matriz de bytes

From \(4\) to \(30\).

Block Binary Format

Learn more about block.

Blocks are stored on the blockchain in a binary format (byte representation). Node extensions such as gRPC server can work directly with data in binary format.

Version 5

message Block {
  message Header {
    int32 chain_id = 1;
    bytes reference = 2;
    int64 base_target = 3;
    bytes generation_signature = 4;
    repeated uint32 feature_votes = 5;
    int64 timestamp = 6;
    int32 version = 7;
    bytes generator = 8;
    int64 reward_vote = 9;
    bytes transactions_root = 10;
  }

  Header header = 1;
  bytes signature = 2;
  repeated SignedTransaction transactions = 3;
}
Block Binary Format Version 5

Field

Description

chain_id

Chain ID

reference

BLAKE2b-256 hash of the previous block header.

base_target

Base target: а variable that is used in the block generation algorithm.

generation_signature

«Generation signature: а variable that is used in the block generation algorithm (\(32\) bytes).»

feature_votes

List of features for which the block generator votes. See the features.

timestamp

Block timestamp: Unix time in milliseconds.

version

Block version: \(5\).

generator

Block generator’s account public key (\(32\) bytes).

reward_vote

Block generation reward for which the block generator votes. \(-1\) means that block generator votes for the current reward size.

transactions_root

Transactions Root Hash (\(32\) bytes).

signature

Block header signature (\(64\) bytes).

transactions

For each transaction: 1) Body bytes: up to \(165,487\) bytes. 2) Proofs: up to \(531\) bytes. See the transaction binary format article for details.

Version 4

Block Binary Format Version 4

#

Field

Field type

Field size in bytes

Comments

\(1\)

Block version

Byte

\(1\)

The value must be \(4\).

\(2\)

Block timestamp

Long

\(8\)

Unix time in milliseconds.

\(3\)

Signature of the previous block

Array[Byte]

\(64\)

\(4\)

Base target

Long

\(8\)

\(5\)

Generation signature

Array[Byte]

\(32\)

\(6\)

Number of transactions in the block

Integer

\(4\)

\(7.1\)

Transaction 1

Array[Byte]

Body bytes: up to \(165,996\) bytes. Proofs: up to \(531\) bytes.

Bytes of the 1st transaction in binary format.

\(7.2\)

Transaction 2

Array[Byte]

Body bytes: up to \(165,996\) bytes. Proofs: up to \(531\) bytes.

Bytes of the 2nd transaction in binary format.

\(7.[N]\)

Transaction N

Array[Byte]

Body bytes: up to \(165,996\) bytes. Proofs: up to \(531\) bytes.

Bytes of the Nth transaction in binary format.

\(8\)

Number of features for which the block generator votes

\(4\)

Integer

\(9.1\)

Feature 1

\(2\)

Short

\(9.[M]\)

Feature M

\(2\)

Short

\(10\)

Block generation reward for which the block generator votes

\(8\)

Long

\(-1\) means that block generator votes for the current reward size.

\(11\)

Block generator’s account public key

\(32\)

Array[Byte]

\(12\)

Block signature

\(64\)

Array[Byte]

Version 3

Block Binary Format Version 3

#

Field

Field type

Field size in bytes

Comments

\(1\)

Block version

Byte

\(1\)

The value must be \(4\).

\(2\)

Block timestamp

Long

\(8\)

Unix time in milliseconds.

\(3\)

Signature of the previous block

Array[Byte]

\(64\)

\(4\)

Base target

Long

\(8\)

\(5\)

Generation signature

Array[Byte]

\(32\)

\(6\)

Number of transactions in the block

Integer

\(4\)

\(7.1\)

Transaction 1

Array[Byte]

Body bytes: up to \(165,996\) bytes. Proofs: up to \(531\) bytes.

Bytes of the 1st transaction in binary format.

\(7.2\)

Transaction 2

Array[Byte]

Body bytes: up to \(165,996\) bytes. Proofs: up to \(531\) bytes.

Bytes of the 2nd transaction in binary format.

\(7.[N]\)

Transaction N

Array[Byte]

Body bytes: up to \(165,996\) bytes. Proofs: up to \(531\) bytes.

Bytes of the Nth transaction in binary format.

\(8\)

Block generator’s account public key

Array[Byte]

\(32\)

\(9\)

Block signature

Array[Byte]

\(64\)

Network Message Binary Format

Block Message Binary Format

Block message is a reply to GetBlock message.

Block Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x17)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Block bytes (N)

Bytes

N

Checkpoint Message Binary Format
Checkpoint Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x64)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Checkpoint items count (N)

Int

\(4\)

\(7\)

Checkpoint #1 height

Long

\(8\)

\(8\)

Checkpoint #1 signature

Bytes

\(64\)

\(6 + 2 * N - 1\)

Checkpoint #N height

Long

\(8\)

\(6 + 2 * N\)

Checkpoint #N signature

Bytes

\(64\)

Get Block Message Binary Format
Get Block Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x16)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Block ID

Bytes

\(64\)

Get Peers Message Binary Format

Get peers message is sent when one sending node wants to know about other nodes on the network.

Get Peers Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x01)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

Get Signatures Message Binary Format
Get Signatures Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x14)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Block IDs count (N)

Int

\(4\)

\(7\)

Block #1 ID

Long

\(64\)

\(6 + N\)

Block #N ID

Bytes

\(64\)

Handshake Message Binary Format

Handshake is used to start communication between two nodes.

Handshake Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Application name length (N)

Byte

\(1\)

\(2\)

Application name (UTF-8 encoded bytes)

Bytes

N

\(3\)

Application version major

Int

\(4\)

\(4\)

Application version minor

Int

\(4\)

\(1\)

Application version patch

Int

\(4\)

\(6\)

Node name length (M)

Byte

\(1\)

\(7\)

Node name (UTF-8 encoded bytes)

Bytes

M

\(8\)

Node nonce

Long

\(8\)

\(9\)

Declared address length (K) or \(0\) if no declared address was set

Int

\(4\)

\(10\)

Declared address bytes (if length is not \(0\))

Bytes

K

\(11\)

Timestamp

Long

\(8\)

Peers Message Binary Format

Peers message is a response to get peers message.

Peers Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x02)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Peers count (N)

Int

\(4\)

\(7\)

Peer #1 IP address

Bytes

\(4\)

\(8\)

Peer #1 port

Int

\(4\)

\(6 + 2 * N - 1\)

Peer #N IP address

Bytes

\(4\)

\(6 + 2 * N\)

Peer #N port

Int

\(4\)

Score Message Binary Format
Score Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x18)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Score (N bytes)

Int

\(N\)

Signatures Message Binary Format
Signatures Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x15)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Block signatures count (N)

Int

\(4\)

\(7\)

Block #1 signature

Bytes

\(64\)

\(6 + N\)

Block #N signature

Bytes

\(64\)

Transaction Message Binary Format
Transaction Message Binary Format

#

Field name

Type

Length in Bytes

\(1\)

Packet length (BigEndian)

Int

\(4\)

\(2\)

Magic Bytes

Bytes

\(4\)

\(3\)

Content ID (0x19)

Byte

\(1\)

\(4\)

Payload length

Int

\(4\)

\(5\)

Payload checksum

Bytes

\(4\)

\(6\)

Transaction (N bytes)

Bytes

N

Order Binary Format

Learn more about order.

  • An exchange transaction of version 3 can accept orders of versions 1–4.

  • An exchange transaction of version 2 can accept orders of versions 1–3.

  • An exchange transaction of version 1 can accept orders of version 1 only.

Version 4

message AssetPair {
    bytes amount_asset_id = 1;
    bytes price_asset_id = 2;
};

message Order {
  enum Side {
    BUY = 0;
    SELL = 1;
  };

  int32 chain_id = 1;
  bytes sender_public_key = 2;
  bytes matcher_public_key = 3;
  AssetPair asset_pair = 4;
  Side order_side = 5;
  int64 amount = 6;
  int64 price = 7;
  int64 timestamp = 8;
  int64 expiration = 9;
  Amount matcher_fee = 10;
  int32 version = 11;
  repeated bytes proofs = 12;
};

message Amount {
  bytes asset_id = 1;
  int64 amount = 2;
};
Order Binary Format Version 4

Field

Size

Description

chain_id

\(1\) byte

Chain ID

sender_public_key

\(32\) bytes

Public key of the order sender.

matcher_public_key

\(32\) bytes

Public key of matcher.

asset_pair.amount_asset_id

\(32\) bytes for asset. \(0\) for DecentralCoins.

ID of the amount asset.

asset_pair.price_asset_id

\(32\) bytes for asset. \(0\) for DecentralCoins.

ID of the price asset.

order_side

\(1\) byte

Order type: buy or sell.

amount

\(8\) bytes

Amount of the amount asset, specified in the minimum fraction (“cent”) of asset.

price

\(8\) bytes

Price for the amount asset nominated in the price asset, multiplied by \(108\).

timestamp

\(8\) bytes

Order timestamp: Unix time in milliseconds.

expiration

\(8\) bytes

Unix time in milliseconds when the order will be expired.

matcher_fee.asset_id

\(32\) bytes for asset. \(0\) for DecentralCoins.

Matcher fee token ID.

matcher_fee.amount

\(8\) bytes

Matcher fee

version

\(1\) byte

Order version: 4.

proofs

Each proof up to \(64\) bytes, up to \(8\) proofs.

Order proofs that are used to check the validity of the order.

Version 3

Order Binary Format Version 3

#

Field name

JSON field name

Field type

Length in bytes

Value

\(1\)

Order binary format version number

version

Byte

\(1\)

Must be \(3\).

\(2\)

Order sender public key

senderPublicKey

Array[Byte]

\(32\)

\(3\)

Matcher public key

matcherPublicKey

Array[Byte]

\(32\)

\(4.1\)

Asset B (amount asset) flag

Byte

\(1\)

If token is DecentralCoins, then value is \(0\), else \(1\).

\(4.2\)

Asset B (amount Asset) ID

amountAsset

Array[Byte]

S

If token is not DecentralCoins, then \(S = 32\), else the field should be absent.

\(5.1\)

Asset A (price asset) flag

Byte

\(1\)

If token is DecentralCoins, then value is \(0\), else \(1\).

\(5.2\)

Asset A (price asset) ID

priceAsset

Array[Byte]

S

If token is not DecentralCoins, then \(S = 32\), else the field should be absent.

\(6\)

Order type

orderType

Byte

\(1\)

If order is for buying, then value is \(0\), if order is for selling, then value is \(1\).

\(7\)

Amount of asset B (amount asset), which the order sender offers for one price asset(asset A)

price

Long

\(8\)

Bytes in big-endian notation.

\(8\)

Amount of asset B (price asset), which the order sender wants to buy or send depending on order type

amount

Long

\(8\)

Bytes in big-endian notation.

\(9\)

Amount of milliseconds from the beginning of Unix epoch till the moment of validation of order by matcher

timestamp

Long

\(8\)

Bytes in big-endian notation.

\(10\)

Amount of milliseconds from the beginning of Unix epoch till the unfulfilled order cancellation

expiration

Long

\(8\)

Bytes in big-endian notation.

\(11\)

Matcher fee

matcherFee

Long

\(8\)

Bytes in big-endian notation.

\(12\)

Matcher fee token flag

Byte

\(1\)

If token is DecentralCoins, then value is \(0\), else \(1\)

\(13\)

Matcher fee token

matcherFeeAssetId

Array[Byte]

F

If token is not DecentralCoins, then \(F = 32\), else the field should be absent.

\(14\)

Proofs

proofs

Array[Proof]

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + (P_{1} + P_{2} + ... + P_{n})\), where \(N\) is amount of proofs in the array, \(P_{n}\) — size N-th proof in bytes. Maximum amount of proofs in the array is \(8\). Maximum length of each proof is \(64\) bytes.

JSON Representation of Order Version 3

{
  "version": 3,
  "senderPublicKey": "FMc1iASTGwTC1tDwiKtrVHtdMkrVJ1S3rEBQifEdHnT2",
  "matcherPublicKey": "7kPFrHDiGw1rCm7LPszuECwWYL3dMf6iMifLRDJQZMzy",
  "assetPair": {
    "amountAsset": "BrjUWjndUanm5VsJkbUip8VRYy6LWJePtxya3FNv4TQa",
    "priceAsset": null
  },
  "orderType": "buy",
  "amount": 150000000,
  "timestamp": 1548660872383,
  "expiration": 1551252872383,
  "matcherFee": 300000,
  "proofs": [
    "YNPdPqEUGRW42bFyGqJ8VLHHBYnpukna3NSin26ERZargGEboAhjygenY67gKNgvP5nm5ZV8VGZW3bNtejSKGEa"
  ],
  "id": "Ho6Y16AKDrySs5VTa983kjg3yCx32iDzDHpDJ5iabXka",
  "sender": "3PEFvFmyyZC1n4sfNWq6iwAVhzUT87RTFcA",
  "price": 1799925005,
}

Version 2

Order Binary Format Version 2

#

Field name

Type

Length in Bytes

\(1\)

Version

Byte (constant, value = \(2\))

\(1\)

\(2\)

Sender’s public key

PublicKey (Array[Byte])

\(32\)

\(3\)

Matcher’s public key

PublicKey (Array[Byte])

\(32\)

\(4.1\)

Amount asset flag (\(1\) - asset, \(0\) - DecentralCoins)

Byte

\(1\)

\(4.2\)

Amount asset

AssetId (ByteStr = Array[Byte])

\(32\) or \(0\) (depends on the byte in 4.1).

\(5.1\)

Price asset flag (\(1\) - asset, \(1\) - DecentralCoins)

Byte

\(1\)

\(5.2\)

Price asset

AssetId (ByteStr = Array[Byte])

\(32\) or \(0\) (depends on the byte in 5.1).

\(6\)

Order type (\(0\) - Buy, \(1\) - Sell)

Byte

\(1\)

\(7\)

Price

Long

\(8\)

\(8\)

Amount

Long

\(8\)

\(9\)

Timestamp

Long

\(8\)

\(10\)

Expiration

Long

\(8\)

\(11\)

Matcher’s fee

Long

\(8\)

\(12\)

Proofs

Proofs

Version 1

Order Binary Format Version 1

#

Field name

Type

Length in Bytes

\(1\)

Sender’s public key

PublicKey (Array[Byte])

\(32\)

\(2\)

Matcher’s public key

PublicKey (Array[Byte])

\(32\)

\(3.1\)

Amount asset flag (\(1\) - asset, \(0\) - DecentralCoins)

\(1\)

\(3.2\)

Amount asset

AssetId (ByteStr = Array[Byte])

\(32\) or \(0\) (depends on the byte in 3.1).

\(4.1\)

Price asset flag (\(1\) - asset, \(0\) - DecentralCoins)

\(1\)

\(4.2\)

Price asset

AssetId (ByteStr = Array[Byte])

\(32\) or \(0\) (depends on the byte in 4.1).

\(5\)

Order type (\(0\) - Buy, \(1\) - Sell)

Byte

\(1\)

\(6\)

Price

Long

\(8\)

\(7\)

Amount

Long

\(8\)

\(8\)

Timestamp

Long

\(8\)

\(9\)

Expiration

Long

\(8\)

\(10\)

Matcher fee

Long

\(8\)

\(11\)

Signature

Bytes

\(64\)

The price listed for amount asset in price asset \(* 10^8\). Expiration is order time to live, timestamp in future, max \(= 30\) days in future. The signature is calculated from the following bytes:

Order Binary Format Version 1 Bytes

#

Field name

Type

Length in Bytes

\(1\)

Sender’s public key

PublicKey (Array[Byte])

\(32\)

\(2\)

Matcher’s public key

PublicKey (Array[Byte])

\(32\)

\(3.1\)

Amount asset flag (\(1\) - asset, \(0\) - DecentralCoins)

\(1\)

\(3.2\)

Amount asset

AssetId (ByteStr = Array[Byte])

\(32\) or \(0\) (depends on the byte in 3.1).

\(4.1\)

Price asset flag (\(1\) - asset, \(0\) - DecentralCoins)

\(1\)

\(4.2\)

Price asset

AssetId (ByteStr = Array[Byte])

\(32\) or \(0\) (depends on the byte in 4.1).

\(5\)

Order type (\(0\) - Buy, \(1\) - Sell)

Bytes

\(1\)

\(6\)

Price

Long

\(8\)

\(7\)

Amount

Long

\(8\)

\(8\)

Timestamp

Long

\(8\)

\(9\)

Expiration

Long

\(8\)

\(10\)

Matcher fee

Long

\(8\)

Transaction Binary Format

Learn more about transaction.

Transactions are stored on the blockchain in a binary format (byte representation). Node extensions such as gRPC server can work directly with data in binary format. The transaction signature and ID are also formed on the basis of the binary format, namely the transaction body bytes. The contents of transaction body bytes is given in the description of the binary format of each type and version of the transaction. Normally the transaction body bytes include all transaction fields, with the exception of the following fields:

  • Transaction ID (it is not stored on the blockchain),

  • Version flag,

  • Proofs or signature, depending on the version of the transaction.

The guideline for generating a signature and ID is given in the cryptographic practical details article. All strings are UTF-8 encoded.

Protobuf

Protobuf facilitates the development of client libraries for the DecentralChain blockchain, as it avoids serialization errors and streamlines the creation of a correctly signed transaction. How to generate a transaction signature using protobuf:

  • Download the protocol buffers package for your programming language. Generate the Transaction class on the basis of transaction.proto.

  • Fill in the transaction fields.

    • Asset IDs should be specified in the binary format.

    • Addresses should be specified in the shortened binary format (without the first two and the last four bytes). See the address binary format) article.

  • Serialize the transaction object to get transaction body bytes. Detailed instructions for various programming languages are provided in protocol buffers tutorials.

  • Generate the signature for the transaction body bytes with the Curve25519 function using sender private key bytes.

The byte representation of a transaction based on the protobuf schema must not contain default values. Make sure that your protocol buffers compiler does not write the field value when serializing if it is equal to the default value for this data type, otherwise the transaction signature will be invalid. Send the signed transaction to a node:

  • If you use your own node and gRPC server, send the SignedTransaction object.

  • If you use Node REST API, compose the JSON representation of the transaction and add the base58-encoded signature to the proof array. Send the transaction to a node using POST /transactions/broadcast method.

message SignedTransaction {
  Transaction transaction = 1;
  repeated bytes proofs = 2;
}

message Transaction {
  int32 chain_id = 1;
  bytes sender_public_key = 2;
  Amount fee = 3;
  int64 timestamp = 4;
  int32 version = 5;

  oneof data {
    GenesisTransactionData genesis = 101;
    PaymentTransactionData payment = 102;
    IssueTransactionData issue = 103;
    TransferTransactionData transfer = 104;
    ReissueTransactionData reissue = 105;
    BurnTransactionData burn = 106;
    ExchangeTransactionData exchange = 107;
    LeaseTransactionData lease = 108;
    LeaseCancelTransactionData lease_cancel = 109;
    CreateAliasTransactionData create_alias = 110;
    MassTransferTransactionData mass_transfer = 111;
    DataTransactionData data_transaction = 112;
    SetScriptTransactionData set_script = 113;
    SponsorFeeTransactionData sponsor_fee = 114;
    SetAssetScriptTransactionData set_asset_script = 115;
    InvokeScriptTransactionData invoke_script = 116;
    UpdateAssetInfoTransactionData update_asset_info = 117;
  };
};

message Amount {
  bytes asset_id = 1;
  int64 amount = 2;
};
Transaction Binary Format

Field

Size

Description

chain_id

\(1\) byte

Chain ID

sender_public_key

\(32\) bytes

Public key of the transaction sender.

fee.amount

\(8\) bytes

Transaction fee in the minimum fraction (“cent”) of the fee asset.

fee.asset_id

\(32\) bytes for the fee in a sponsored asset. \(0\) for the fee in DecentralCoins

ID of the token of the fee. The fee in a sponsored asset is only available for invoke script transactions and transfer transactions. See the sponsored fee article.

timestamp

\(8\) bytes

Transaction timestamp: Unix time in milliseconds. The transaction won’t be added to the blockchain if the timestamp value is more than \(2\) hours back or \(1.5\) hours forward of the current block timestamp.

version

\(1\) byte

Transaction version.

proofs

Each proof up to \(64\) bytes,up to \(8\) proofs.

Transaction proofs that are used to check the validity of the transaction. The array can contain several transaction signatures (but not limited to signatures only).

The fields that depend on the type of transaction are described in the following articles:

Burn Transaction Binary Format

Learn more about burn transaction.

Version 3

message BurnTransactionData {
  Amount asset_amount = 1;
};

message Amount {
  bytes asset_id = 1;
  int64 amount = 2;
};
Burn Transaction Binary Format Version 3

Field

Size

Description

asset_amount.amount

\(8\) bytes

Amount of token to burn, specified in the minimum fraction (“cents”).

asset_amount.asset_id

\(32\) bytes

ID of token to burn.

Version 2

Burn Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(6\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4\)

Chain ID

chainId

Byte

1

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6\)

ID of the token to burn

assetId

Array[Byte]

\(32\)

\(7\)

Amount of tokens to burn

amount

Long

\(8\)

\(8\)

Transaction fee

fee

Long

\(8\)

\(9\)

Transaction timestamp

timestamp

Long

\(8\)

\(10\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6\), \(7\), \(8\) and \(9\) are the transaction body bytes.

JSON Representation of Transaction

{
  "type":6,
  "id":"csr25XQHT1c965Fg7cY2vJ7XHYVsudPYrUbdaFqgaqL",
  "sender":"3P9QZNrHbyxXj8P9VrJZmVu2euodNtA11UW",
  "senderPublicKey":"9GaQj7gktEiiS1TTTjGbVjU9bva3AbCiawZ11qFZenBX",
  "fee":100000,
  "feeAssetId":null,
  "timestamp":1548660675277,
  "proofs": [
    "61jCivdv3KTuTY6QHgxt4jaGrXcszWg3vb9TmUR26xv7mjWWwjyqs7X5VDUs9c2ksndaPogmdunHDdjWCuG1GGhh"
  ],
  "version":2,
  "assetId":"FVxhjrxZYTFCa9Bd4JYhRqXTjwKuhYbSAbD2DWhsGidQ",
  "amount":9999,
  "chainId":87,
  "height":1370971
}

Version 1

Burn Transaction Binary Format Version 1

#

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(6\).

\(2\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(3\)

ID of the token to burn

Array[Byte]

\(32\)

\(4\)

Amount of tokens to burn

Long

\(8\)

\(5\)

Transaction fee

Long

\(8\)

\(6\)

Transaction timestamp

Long

\(8\)

\(7\)

Transaction signature

Array[Byte]

\(64\)

The fields \(1\), \(2\), \(3\), \(4\), \(5\) and \(6\) are the transaction body bytes.

Create Alias Transaction Binary Format

Learn more about create alias transaction.

Version 3

message CreateAliasTransactionData {
  string alias = 1;
};
Create Alias Transaction Binary Format Version 3

Field

Size

Description

alias

From \(4\) to \(30\) bytes

Alias

Version 2

Create Alias Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(10\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(5\)

Alias length

Short

\(2\)

Number of characters in the alias name.

\(6\)

Alias

alias

String

from \(4\) to \(30\)

\(7\)

Transaction fee

fee

Long

\(8\)

\(8\)

Transaction timestamp

timestamp

Long

\(8\)

\(9\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6\), \(7\) and \(8\) are the transaction body bytes.

JSON Representation of Transaction

{
  "type":10,
  "id":"5CZV9RouJs7uaRkZY741WDy9zV69npX1FTZqxo5fsryL",
  "sender":"3PNaua1fMrQm4TArqeTuakmY1u985CgMRk6",
  "senderPublicKey":"B3f8VFh6T2NGT26U7rHk2grAxn5zi9iLkg4V9uxG6C8q",
  "fee":100000,
  "feeAssetId":null,
  "timestamp":1548666019772,
  "proofs": [
    "3cUM8Eq5KfmbS6q1qHDfzhX98YzER1ocnVjVAHG9HSkQdw86zjqxUfmsUPVwnVgwu5zatt3ETLnNFteobRMyR8bY"
  ],
  "version":2,
  "alias":"2.1.0a",
  "height":1371063
}

Version 1

Create Alias Transaction Binary Format Version 1

#

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(10\).

\(2\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(3\)

Alias length

Short

\(2\)

Number of characters in the alias name.

\(4\)

Alias

Array[Byte]

From \(4\) to \(30\)

\(5\)

Transaction fee

Long

\(8\)

\(6\)

Transaction timestamp

Long

\(8\)

\(7\)

Transaction signature

Array[Byte]

\(64\)

The fields \(1\), \(2\), \(3\), \(4\), \(5\) and \(6\) are the transaction body bytes.

Data Transaction Binary Format

Learn more about data transaction.

Version 2

Data Transaction Binary Format Version 2

Field

Size

Description

key

Up to \(400\) bytes

Entry key.

value

Up to \(32,767\) bytes

Entry value. If omitted, the transaction deletes the entry.

The maximum number of entries is \(100\). The maximum data size (keys + values) is \(165,890\) bytes.

JSON Representation of Transaction

{
  "type":12,
  "id":"EByjQAWDRGrmc8uy7xRGy2zsQXZQq59bav7h8oTTJyHC",
  "sender":"3PLZcCJyYQnfWfzhKXRA4rteCQC9J1ewf5K",
  "senderPublicKey":"BQMVwAHwf2WEEwRsCxtMVcSLrXUhJ3XtCLmSptLx2e6L",
  "fee":600000,
  "feeAssetId":null,
  "timestamp":1532116120299,
  "proofs": [
    "PZiAGq2ssi1ojh2Cc9dWrzmbuw9nJif2omsQ4dvonU31oiwsJQGbZiio3LG28otatFfFbHPfcX1JVCHwP5i4mKy"
  ],
  "version":1,
  "data": [
    {"key":"4900","type":"integer","value":24010000},{"key":"4901","type":"integer","value":24019801},
    {"key":"4902","type":"integer","value":24029604},{"key":"4903","type":"integer","value":24039409},
    {"key":"4904","type":"integer","value":24049216},{"key":"4905","type":"integer","value":24059025},
    {"key":"4906","type":"integer","value":24068836},{"key":"4907","type":"integer","value":24078649},
    {"key":"4908","type":"integer","value":24088464},{"key":"4909","type":"integer","value":24098281},
    {"key":"4910","type":"integer","value":24108100},{"key":"4911","type":"integer","value":24117921},
    {"key":"4912","type":"integer","value":24127744},{"key":"4913","type":"integer","value":24137569},
    {"key":"4914","type":"integer","value":24147396},{"key":"4915","type":"integer","value":24157225},
    {"key":"4916","type":"integer","value":24167056},{"key":"4917","type":"integer","value":24176889},
    {"key":"4918","type":"integer","value":24186724},{"key":"4919","type":"integer","value":24196561},
    {"key":"4920","type":"integer","value":24206400},{"key":"4921","type":"integer","value":24216241},
    {"key":"4922","type":"integer","value":24226084},{"key":"4923","type":"integer","value":24235929},
    {"key":"4924","type":"integer","value":24245776},{"key":"4925","type":"integer","value":24255625},
    {"key":"4926","type":"integer","value":24265476},{"key":"4927","type":"integer","value":24275329},
    {"key":"4928","type":"integer","value":24285184},{"key":"4929","type":"integer","value":24295041},
    {"key":"4930","type":"integer","value":24304900},{"key":"4931","type":"integer","value":24314761},
    {"key":"4932","type":"integer","value":24324624},{"key":"4933","type":"integer","value":24334489},
    {"key":"4934","type":"integer","value":24344356},{"key":"4935","type":"integer","value":24354225},
    {"key":"4936","type":"integer","value":24364096},{"key":"4937","type":"integer","value":24373969},
    {"key":"4938","type":"integer","value":24383844},{"key":"4939","type":"integer","value":24393721},
    {"key":"4940","type":"integer","value":24403600},{"key":"4941","type":"integer","value":24413481},
    {"key":"4942","type":"integer","value":24423364},{"key":"4943","type":"integer","value":24433249},
    {"key":"4944","type":"integer","value":24443136},{"key":"4945","type":"integer","value":24453025},
    {"key":"4946","type":"integer","value":24462916},{"key":"4947","type":"integer","value":24472809},
    {"key":"4948","type":"integer","value":24482704},{"key":"4949","type":"integer","value":24492601},
    {"key":"4950","type":"integer","value":24502500},{"key":"4951","type":"integer","value":24512401},
    {"key":"4952","type":"integer","value":24522304},{"key":"4953","type":"integer","value":24532209},
    {"key":"4954","type":"integer","value":24542116},{"key":"4955","type":"integer","value":24552025},
    {"key":"4956","type":"integer","value":24561936},{"key":"4957","type":"integer","value":24571849},
    {"key":"4958","type":"integer","value":24581764},{"key":"4959","type":"integer","value":24591681},
    {"key":"4960","type":"integer","value":24601600},{"key":"4961","type":"integer","value":24611521},
    {"key":"4962","type":"integer","value":24621444},{"key":"4963","type":"integer","value":24631369},
    {"key":"4964","type":"integer","value":24641296},{"key":"4965","type":"integer","value":24651225},
    {"key":"4966","type":"integer","value":24661156},{"key":"4967","type":"integer","value":24671089},
    {"key":"4968","type":"integer","value":24681024},{"key":"4969","type":"integer","value":24690961},
    {"key":"4970","type":"integer","value":24700900},{"key":"4971","type":"integer","value":24710841},
    {"key":"4972","type":"integer","value":24720784},{"key":"4973","type":"integer","value":24730729},
    {"key":"4974","type":"integer","value":24740676},{"key":"4975","type":"integer","value":24750625},
    {"key":"4976","type":"integer","value":24760576},{"key":"4977","type":"integer","value":24770529},
    {"key":"4978","type":"integer","value":24780484},{"key":"4979","type":"integer","value":24790441},
    {"key":"4980","type":"integer","value":24800400},{"key":"4981","type":"integer","value":24810361},
    {"key":"4982","type":"integer","value":24820324},{"key":"4983","type":"integer","value":24830289},
    {"key":"4984","type":"integer","value":24840256},{"key":"4985","type":"integer","value":24850225},
    {"key":"4986","type":"integer","value":24860196},{"key":"4987","type":"integer","value":24870169},
    {"key":"4988","type":"integer","value":24880144},{"key":"4989","type":"integer","value":24890121},
    {"key":"4990","type":"integer","value":24900100},{"key":"4991","type":"integer","value":24910081},
    {"key":"4992","type":"integer","value":24920064},{"key":"4993","type":"integer","value":24930049},
    {"key":"4994","type":"integer","value":24940036},{"key":"4995","type":"integer","value":24950025},
    {"key":"4996","type":"integer","value":24960016},{"key":"4997","type":"integer","value":24970009},
    {"key":"4998","type":"integer","value":24980004},{"key":"4999","type":"integer","value":24990001}
  ],
  "height":1091300
}

Version 1

Data Transaction Binary Format Version 1

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(12\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(1\).

\(4\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(5\)

Length of the data array

Short

\(2\)

\(6.1\)

Key 1 length

Short

\(2\)

\(6.2\)

Key 1

key

String

Up to \(400\)

Maximum of \(100\) characters.

\(6.3\)

Value 1 type

type

Byte

\(1\)

Options are: 0 - Long. 1 - Boolean. 2 - Array[Byte]. 3 - String.

\(6.4\)

Value 1 length

Short

\(2\)

This field is present only if the value is of type of array of bytes or a string. If the value is of type of integer or a boolean, this field should not be included in the data structure.

\(6.5\)

Value 1

value

T

S

T is one of the following: 1) Long, \(S = 8\). 2) Boolean, \(S = 1\). 3) Array[Byte], \(S ⩽ 32,767\). 4) String, \(S ⩽ 32,767\).

\(6.6\)

Key 2 length

Short

\(2\)

\(6.7\)

Key 2

key

String

Up to \(400\)

Maximum of \(100\) characters.

\(6.8\)

Value 2 type

type

Byte

\(1\)

Options are: 0 - Long. 1 - Boolean. 2 - Array[Byte]. 3 - String.

\(6.9\)

Value 2 length

Short

\(2\)

This field is present only if the value is of type of array of bytes or a string. If the value is of type of integer or a boolean, this field should not be included in the data structure.

\(6.10\)

Value 2

value

T

S

T is one of the following: 1) Long, \(S = 8\). 2) Boolean, \(S = 1\). 3) Array[Byte], \(S ⩽ 32,767\). 4) String, \(S ⩽ 32,767\).

\(6.[5 × N - 4]\)

N-th key length

Short

\(2\)

\(6.[5 × N - 3]\)

N-th key

key

String

Up to \(400\)

Maximum of \(100\) characters.

\(6.[5 × N - 2]\)

N-th value type

type

Byte

\(1\)

Options are: 0 - Long. 1 - Boolean. 2 - Array[Byte]. 3 - String.

\(6.[5 × N - 1]\)

N-th value length

Short

\(2\)

This field is present only if the value is of type of array of bytes or a string. If the value is of type of integer or a boolean, this field should not be included in the data structure.

\(6.[5 × N]\)

N-th value

value

T

S

T is one of the following: 1) Long, \(S = 8\). 2) Boolean, \(S = 1\). 3) Array[Byte], \(S ⩽ 32,767\). 4) String, \(S ⩽ 32,767\).

\(7\)

Transaction timestamp

timestamp

Long

\(8\)

\(8\)

Transaction fee

fee

Long

\(8\)

\(9\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is 64 bytes.

The fields \(1\), \(2\), \(3\), \(4\), \(5\), \(6.1\), \(6.2\), \(6.3\), \(6.4\), \(6.5\), \(6.6\), \(6.7\), \(6.8\), \(6.9\), \(6.10\), \(6.[5 × N - 4]\), \(6.[5 × N - 3]\), \(6.[5 × N - 2]\), \(6.[5 × N - 1]\), \(6.[5 × N]\), \(7\) and \(8\) are the transaction body bytes. The maximum number of records is \(100\). The maximum size of transaction body bytes is \(153,600\) bytes.

Exchange Transaction Binary Format

Learn more about exchange transaction.

Version 3

Exchange transaction of version 3 can accept orders of versions 1 –4.

message ExchangeTransactionData {
  int64 amount = 1;
  int64 price = 2;
  int64 buy_matcher_fee = 3;
  int64 sell_matcher_fee = 4;
  repeated Order orders = 5;
};
Exchange Transaction Binary Format Version 3

Field

Size

Description

amount

\(8\) bytes

Amount of the amount asset (base currency) that the buyer received from the seller, specified in the minimum fraction (“cent”) of asset.

price

\(8\) bytes

Price for the amount asset (base currency) nominated in the price asset (quote currency), multiplied by \(10^{8}\). For more details see the order article.

buy_matcher_fee

\(8\) bytes

Buy matcher fee. The fee token ID is indicated in buy order.

sell_matcher_fee

\(8\) bytes

Sell matcher fee The fee token ID is indicated in sell order.

orders

Buy order and sell order. See the order binary format.

Version 2

Transaction version 2 can accept orders of version 1, 2 and 3.

Exchange Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(7\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4.1\)

Buy order size

Int

\(4\)

Size including flag 4.2.

\(4.2\)

Buy order version flag

order1.version

Byte

S

\(S = 1\) if the order version is \(1\). \(S = 0\) if the order version is 2 or 3.

\(4.3\)

Buy order

order1

Array[Byte]

See order binary format

\(5.1\)

Sell order size

Int

\(4\)

Size including flag 5.2.

\(5.2\)

Sell order version flag

order2.version

Byte

S

\(S = 1\) if the order version is \(1\). \(S = 0\) if the order version is 2 or 3.

\(5.3\)

Sell order

order2

Array[Byte]

See order binary format

\(6\)

Deal price

price

Long

\(8\)

Price for the amount asset (base currency) nominated in the price asset (quote currency).

\(7\)

Amount

amount

Long

\(8\)

Amount of the amount asset (base currency) that the buyer received from the seller.

\(8\)

Buy matcher fee

buyMatcherFee

Long

\(8\)

\(9\)

Sell matcher fee

sellMatcherFee

Long

\(8\)

\(10\)

Transaction fee

fee

Long

\(8\)

\(11\)

Transaction timestamp

timestamp

Long

\(8\)

\(12\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(1\), \(2\), \(3\), \(4.1\), \(4.2\), \(4.3\), \(5.1\), \(5.2\), \(5.3\), \(6\), \(6.6\), \(7\), \(8\), \(9\), \(10\) and \(11\) are the transaction body bytes.

JSON Representation of Transaction

{
   "type":6,
   "id":"csr25XQHT1c965Fg7cY2vJ7XHYVsudPYrUbdaFqgaqL",
   "sender":"3P9QZNrHbyxXj8P9VrJZmVu2euodNtA11UW",
   "senderPublicKey":"9GaQj7gktEiiS1TTTjGbVjU9bva3AbCiawZ11qFZenBX",
   "fee":100000,
   "feeAssetId":null,
   "timestamp":1548660675277,
   "proofs": [
     "61jCivdv3KTuTY6QHgxt4jaGrXcszWg3vb9TmUR26xv7mjWWwjyqs7X5VDUs9c2ksndaPogmdunHDdjWCuG1GGhh"
   ],
   "version":2,
   "assetId":"FVxhjrxZYTFCa9Bd4JYhRqXTjwKuhYbSAbD2DWhsGidQ",
   "amount":9999,
   "chainId":87,
   "height":1370971
 }

Version 1

Transaction version 1 can accept orders of version 1 only.

Exchange Transaction Binary Format Version 1

#

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(6\).

\(2\)

Buy order size

Int

\(4\)

\(3\)

Sell order size

Int

\(4\)

\(4\)

Buy order

Array[Byte]

See order binary format

\(5\)

Sell order

Array[Byte]

See order binary format

\(6\)

Deal price

Long

\(8\)

Price for the amount asset (base currency) nominated in the price asset (quote currency).

\(7\)

Amount

Long

\(8\)

Amount of the amount asset (base currency) that the buyer received from the seller.

\(8\)

Buy matcher fee

Long

\(8\)

\(9\)

Sell matcher fee

Long

\(8\)

\(10\)

Transaction fee

Long

\(8\)

\(11\)

Transaction timestamp

Long

\(8\)

\(12\)

Transaction signature

Array[Byte]

\(64\)

The fields \(1\), \(2\), \(3\), \(4\), \(5\), \(6\), \(7\), \(8\), \(9\), \(10\) and \(11\) are the transaction body bytes.

Genesis Transaction Binary Format

Learn more about genesis transaction.

Genesis Transaction Binary Format

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

type

Byte

\(1\)

Value must be \(1\).

\(2\)

Transaction timestamp

timestamp

Long

\(8\)

\(3\)

Address of the recipient

recipient

Array[Byte]

\(26\)

\(4\)

Amount of DecentralCoins that will be transferred to the account

amount

Long

\(8\)

JSON Representation of Transaction

{
  "type":1,
  "id":"2DVtfgXjpMeFf2PQCqvwxAiaGbiDsxDjSdNQkc5JQ74eWxjWFYgwvqzC4dn7iB1AhuM32WxEiVi1SGijsBtYQwn8",
  "fee":0,
  "timestamp":1465742577614,
  "signature":"2DVtfgXjpMeFf2PQCqvwxAiaGbiDsxDjSdNQkc5JQ74eWxjWFYgwvqzC4dn7iB1AhuM32WxEiVi1SGijsBtYQwn8",
  "recipient":"3PAWwWa6GbwcJaFzwqXQN5KQm7H96Y7SHTQ",
  "amount":9999999500000000,
  "height":1
}
Invoke Script Transaction Binary Format

Learn more about invoke script transaction.

Version 2

message InvokeScriptTransactionData {
  Recipient d_app = 1;
  bytes function_call = 2;
  repeated Amount payments = 3;
};

message Recipient {
  oneof recipient {
    bytes public_key_hash = 1;
    string alias = 2;
  };
};

message Amount {
  bytes asset_id = 1;
  int64 amount = 2;
};
Invoke Script Transaction Binary Format Version 2

Field

Size

Description

d_app.public_key_hash

\(20\) bytes

dApp account public key hash (a component of an address, see the Address binary format article).

d_app.alias

From \(4\) to \(30\) bytes

dApp alias.

function_call

Function name and arguments. Binary format of function call is the same as in version 1.

payments.asset_id

\(32\) bytes for asset. \(0\) for DecentralCoins.

ID of token in payment.

payments.amount

\(8\) bytes

Amount of token in payment, specified in the atomic units.

The maximum size of d_app + function_call + payments is \(5120\) bytes.

JSON Representation of Transaction

{
  "type":16,
  "id":"7CVjf5KGRRYj6UyTC2Etuu4cUxx9qQnCJox8vw9Gy9yq",
  "sender":"3P5rWeMzoaGBrXJDMifQDDjCMKWJGKTiVJU",
  "senderPublicKey":"4kKN9G7cZXGQujLQm9ss5gqB7TKX4A9jtFGt7DnHUoQ6",
  "fee":500000,
  "feeAssetId":null,
  "timestamp":1565537422938,
  "proofs": [
    "28s21sisoa7yHWWmmX8U78fbNHW4KXAS9GHD8XmaN77gJxbnP2Q3DssNWpmSQ6hBq6xS985W4YiTmgvENhfWPNt5"
  ],
  "version":1,
  "dApp":"3PJbknfXMsJzZmksmsKSMz56tVdDqF5GdNM",
  "payment":[],
  "call": {
    "function":"returnSellVST",
    "args": [
      {
        "type":"string",
        "value":"GiEBRfGhEeGqhPmLCjwJcYuakyvaz2GHGCfCzuinSKD"
      }
    ]
  },
  "height":1656369,
  "stateChanges": {
    "data": [
      {
        "key":"sell_GiEBRfGhEeGqhPmLCjwJcYuakyvaz2GHGCfCzuinSKD_spent",
        "type":"integer",
        "value":10000000000
      }
    ],
    "transfers": [
      {
        "address":"3P5rWeMzoaGBrXJDMifQDDjCMKWJGKTiVJU",
        "asset":"4LHHvYGNKJUg5hj65aGD5vgScvCBmLpdRFtjokvCjSL8",
        "amount":10000000000
      }
    ],
    "issues":[],
    "reissues":[],
    "burns":[],
    "sponsorFees":[],
    "leases":[],
    "leaseCancels":[],
    "invokes":[]
  }
}

Version 1

Invoke Script Transaction Binary Format Version 1

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(16\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(1\).

\(4\)

Chain ID

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6\)

Address or alias

dApp

See Address Binary Format, Alias Binary Format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\).

\(7.1\)

Function presence flag

Byte

\(1\)

\(0\) — the default function of the dApp is invoked. \(1\) — function from the current transaction should be invoked in the dApp.

\(7.2\)

Function call ID

Byte

\(1\)

Constant. The value must be \(9\).

\(7.3\)

Function type ID

Byte

\(1\)

Constant. The value must be \(1\).

\(7.4\)

Function name length

Int

\(4\)

\(7.5\)

Function name

function

String

Up to \(255\)

\(7.6.1\)

Amount of arguments of the function

Int

\(4\)

\(7.6.2\)

ID of argument 1 type

type

Byte

\(1\)

\(0\) — argument type is long. \(1\) — argument type is an array of bytes. \(2\) — argument type is a string. \(6\) — argument type is logical True. \(7\) — argument type is logical False. \(11\) – argument type is list.

\(7.6.3\)

Argument 1

value

Options are: 1) Long. 2) Array[Byte]. 3) String. 4) Logical True. 5) Logical False. 6) List.

S

\(S = 8\), if argument type is long. If the argument type is an array of bytes, string, or list, the field size is limited only by the total transaction size. If the type is list, then 1) its length must not exceed \(1000\) elements. 2) amount of its elements represents first \(4\) bytes of the current field. 3) each list element is serialized similarly to the function argument: the element type ID takes first place followed by the element’s value. \(S = 0\), if argument type is logical True or False.

\(7.6.4\)

ID of argument 2 type

type

Byte

\(1\)

\(0\) — argument type is long. \(1\) — argument type is an array of bytes. \(2\) — argument type is a string. \(6\) — argument type is logical True. \(7\) — argument type is logical False. \(11\) – argument type is list.

\(7.6.5\)

Argument 2

value

Options are: 1) Long. 2) Array[Byte]. 3) String. 4) Logical True. 5) Logical False. 6) List.

S

\(S = 8\), if argument type is long. If the argument type is an array of bytes, string, or list, the field size is limited only by the total transaction size. If the type is list, then 1) its length must not exceed \(1000\) elements. 2) amount of its elements represents first \(4\) bytes of the current field. 3) each list element is serialized similarly to the function argument: the element type ID takes first place followed by the element’s value. \(S = 0\), if argument type is logical True or False.

\(7.6.[2 × N]\)

ID of argument N type

type

Byte

\(1\)

0 — argument type is long. 1 — argument type is an array of bytes. 2 — argument type is a string. 6 — argument type is logical True. 7 — argument type is logical False. 11 – argument type is list.

\(7.6.[2 × N + 1]\)

Argument N

value

Options are: 1) Long. 2) Array[Byte]. 3) String. 4) Logical True. 5) Logical False. 6) List.

S

\(S = 8\), if argument type is long. If the argument type is an array of bytes, string, or list, the field size is limited only by the total transaction size. If the type is list, then 1) its length must not exceed \(1000\) elements. 2) amount of its elements represents first \(4\) bytes of the current field. 3) each list element is serialized similarly to the function argument: the element type ID takes first place followed by the element’s value. \(S = 0\), if argument type is logical True or False.

\(8.1\)

Amount of payments

Short

\(2\)

\(8.2\)

Payment 1 length

Short

\(2\)

\(8.3\)

Amount of token in payment 1

amount

Long

\(8\)

\(8.4\)

Flag of payment 1 token

Byte

\(1\)

\(0\)DecentralCoins. \(1\) — other token.

\(8.5\)

ID of payment 1 token

Array[Byte]

\(32\)

Field is applicable if the token is not DecentralCoins.

\(8.[4 × N – 2]\)

Payment N length

Short

\(2\)

\(8.[4 × N – 1]\)

Amount of token in payment N

amount

Long

\(8\)

\(8.[4 × N]\)

Flag of payment N token

Byte

\(1\)

\(0\)DecentralCoins. \(1\) — other token.

\(8.[4 × N + 1]\)

ID of payment N token

Array[Byte]

\(32\)

Field is applicable if the token is not DecentralCoins.

\(9\)

Transaction fee

fee

Long

\(8\)

\(10.1\)

Flag of fee token

Byte

\(1\)

\(0\)DecentralCoins. \(1\) — other token.

\(10.2\)

Fee token ID

feeAssetId

Array[Byte]

S

\(S = 0\), if token is DecentralCoins. \(S = 32\), if it is other token.

\(11\)

Transaction timestamp

timestamp

Long

\(8\)

\(12\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The maximum number of payments is \(10\). The maximum size of transaction including proofs is \(5120\) bytes.

Issue Transaction Binary Format

Learn more about issue transaction.

Version 3

message IssueTransactionData {
  string name = 1;
  string description = 2;
  int64 amount = 3;
  int32 decimals = 4;
  bool reissuable = 5;
  bytes script = 6;
};
Issue Transaction Binary Format Version 3

Field

Size

Description

name

From \(4\) to \(16\) bytes

Token name.

description

From \(0\) to \(1000\) bytes

Token description.

amount

\(8\) bytes

Amount of token to issue, specified in the minimum fraction (“cents”).

decimals

\(1\) byte

Number of decimal places.

reissuable

\(1\) byte

Reissue availability flag.

script

Up to \(8192\) bytes

Asset script.

Version 2

Issue Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(0\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(0\)

Value must be \(3\).

\(3\)

Transaction version

version

Byte

\(0\)

Value must be \(2\).

\(4\)

Chain ID

chainId

Byte

\(0\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

32

\(6.1\)

Token name length

Short

\(2\)

\(6.2\)

Token name

name

Array[Byte]

From \(4\) to \(16\)

\(7.1\)

Token description length

Short

\(2\)

\(7.2\)

Token description

description

Array[Byte]

From \(0\) to \(1000\)

\(8\)

Amount of the token that will be issued

quantity

Short

\(8\)

\(9\)

Number of decimal places of the token

decimals

Byte

\(0\)

\(10\)

Reissue flag

reissuable

Boolean

\(0\)

If the value is \(0\), then token reissue is not possible. If the value is \(1\), then token reissue is possible.

\(11\)

Transaction fee

fee

Short

\(8\)

\(12\)

Transaction timestamp

timestamp

Short

\(8\)

\(13.1\)

Script existence flag

Boolean

\(0\)

If the value is \(0\), then the token does not have a script. If the value is \(1\), then the token has a script.

\(13.2\)

Script length in bytes

Short

S

\(S = 0\) if the value of the script existence flag field is \(0\). \(S = 2\) if the value of the script existence flag field is 1.

\(13.3\)

Asset script

script

String

S

\(S = 0\) if the value of the script existence flag field is \(0\). \(0 < S ≤ 8192\), if the value of the script existence flag field is 1.

\(14\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(82\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6.1\), \(6.2\), \(7.1\), \(7.2\), \(8\), \(9\), \(10\), \(11\), \(12\), \(13.1\), \(13.2\) and \(13.3\) are the transaction body bytes.

JSON Representation of Transaction

{
  "type":3,
  "id":"FTQvw9zdYirRksUFCKDvor3hiu2NiUjXEPTDEcircqti",
  "sender":"3PPP59J1pToCk7fPs4d5EK5PoHJMeQRJCTb",
  "senderPublicKey":"E8Y8ywedRS9usVvvcuczn9hsSg1SNkQVBMcNeQEnjDTP",
  "fee":100000000,
  "feeAssetId":null,
  "timestamp":1548666518362,
  "proofs": [
    "3X7GpKW1ztto1aJN5tQNByaGZ9jGkaxZNo4BT268obZckbXuNQHGKjAUxtqcSEes5aZNMaQi2JYBGeKpcaPTxpSC"
  ],
  "version":2,
  "assetId":"FTQvw9zdYirRksUFCKDvor3hiu2NiUjXEPTDEcircqti",
  "name":"DCVN",
  "quantity":990000000000000000,
  "reissuable":false,
  "decimals":8,
  "description":"Tài chính cho nền dân chủ",
  "script":null,
  "chainId":87,
  "height":1371069
}

Version 1

Issue Transaction Binary Format Version 1

#

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(3\).

\(2\)

Transaction signature

Array[Byte]

\(64\)

\(3\)

Transaction type ID

Byte

\(1\)

This field duplicates field 1.

\(4\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(5.1\)

Token name length

Short

\(2\)

\(5.2\)

Token name

Array[Byte]

From \(4\) to \(16\)

\(6.1\)

Token description length

Short

\(2\)

\(6.2\)

Token description

Array[Byte]

From \(0\) to \(1000\)

\(7\)

Amount of the token that will be issued

Long

\(8\)

\(8\)

Number of decimal places of the token

Byte

\(1\)

\(9\)

Reissue flag

Boolean

\(1\)

\(10\)

Transaction fee

Long

\(8\)

\(11\)

Transaction timestamp

Long

\(8\)

The fields \(3\), \(4\), \(5.1\), \(5.2\), \(6.1\), \(6.2\), \(7\), \(8\), \(9\), \(10\) and \(11\) are the transaction body bytes.

Lease Cancel Transaction Binary Format

Learn more about lease cancel transaction

Version 3

message LeaseCancelTransactionData {
  bytes lease_id = 1;
};
Lease Cancel Transaction Binary Format Version 3

Field

Size

Description

lease_id

\(32\) bytes

Lease ID.

Version 2

Lease Cancel Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(9\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4\)

Chain ID

chainId

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6\)

Transaction fee

fee

Long

\(8\)

\(7\)

Transaction timestamp

timestamp

Long

\(8\)

\(8\)

Lease ID

Array[Byte]

\(32\)

\(9\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6\), \(7\), and \(8\) are the transaction body bytes.

JSON Representation of Transaction

{
  "type":9,
  "id":"7siEtrJAvmVzM1WDX6v9RN4qkiCtk7qQEeD5ZhE6955E",
  "sender":"3PMBXG13f89pq3WyJHHKX2m5zN6kt2CEkHQ",
  "senderPublicKey":"BEPNBjo9Pi9hJ3hVtxpwyEfXCW3qWUNk5dMD7aFdiHsa",
  "fee":100000,
  "feeAssetId":null,
  "timestamp":1548660629957,
  "proofs": [
    "3cqVVsaEDzBz367KTBFGgMXEYJ2r3yLWd4Ha8r3GzmAFsm2CZ3GeNW22wqxfK4LNRFgsM5kCWRVhf6gu2Nv6zVqW"
  ],
  "version":2,
  "leaseId":"BggRaeNCVmzuFGohzF4dQeYXSWr8i5zNSnGtdKc5eGrY",
  "chainId":87,
  "height":1370970,
  "lease": {
    "id":"BggRaeNCVmzuFGohzF4dQeYXSWr8i5zNSnGtdKc5eGrY",
    "originTransactionId":"BggRaeNCVmzuFGohzF4dQeYXSWr8i5zNSnGtdKc5eGrY",
    "sender":"3PMBXG13f89pq3WyJHHKX2m5zN6kt2CEkHQ",
    "recipient":"3PMWRsRDy882VR2viKPrXhtjAQx7ygQcnea",
    "amount":406813214,
    "height":1363095,
    "status":"canceled",
    "cancelHeight":1370970,
    "cancelTransactionId":"7siEtrJAvmVzM1WDX6v9RN4qkiCtk7qQEeD5ZhE6955E"
  }
}

Version 1

Lease Cancel Transaction Binary Format Version 1

Field order number

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(9\).

\(2\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(3\)

Transaction fee

Long

\(8\)

\(4\)

Transaction timestamp

Long

\(8\)

\(5\)

Lease ID

Array[Byte]

\(32\)

\(6\)

Transaction signature

Array[Byte]

\(64\)

The fields \(1\), \(2\), \(3\), \(4\), and \(5\) are the transaction body bytes.

Lease Transaction Binary Format

Learn more about lease transaction.

Version 3

message LeaseTransactionData {
  Recipient recipient = 1;
  int64 amount = 2;
};

message Recipient {
  oneof recipient {
    bytes public_key_hash = 1;
    string alias = 2;
  };
};
Lease Transaction Binary Format Version 3

Field

Size

Description

recipient.public_key_hash

\(20\) bytes

Recipient’s account public key hash (a component of an address, see the address binary format article).

recipient.alias

From \(4\) to \(30\) bytes

Recipient’s alias.

amount

\(8\) bytes

Amount of DecentralCoins to lease (that is, amount of Decentralites multiplied by \(10^{8}\)).

Version 2

Lease Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(8\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4\)

Reserved field

Byte

\(1\)

Value must be equal to \(0\).

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6\)

Address or alias of the recipient

recipient

See address binary format, alias binary format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\).

\(7\)

Amount of DecentralCoins that will be leased to the account

amount

Long

\(8\)

\(8\)

Transaction fee

fee

Long

\(8\)

\(9\)

Transaction timestamp

timestamp

Long

\(8\)

\(10\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6\), \(7\), \(8\) and \(9\) are the transaction body bytes.

JSON Representation of Transaction

{
  "type":8,
  "id":"J6jZCzLpWJX8EDVhopKFx1mcbFizLGHVb44dvqPzH4QS",
  "sender":"3PMYNm8hshzCNjZ8GpPta5SyN7qBTEzS7Kw",
  "senderPublicKey":"GNswAY61mER5ZyUFeDBo1UyKGkPSSmmnd6yj7axN2n8f",
  "fee":100000,
  "feeAssetId":null,
  "timestamp":1548660916755,
  "proofs": [
    "2opTj7mGKXLRajkJ78wN4ctSWqTeWtvisHaR8BnL2amqJ2KB313BbcpDYJKcqr7o7EpYjL5tppMz2pGjUMWbJe9b"
  ],
  "version":2,
  "amount":14000000000,
  "recipient":"3PMWRsRDy882VR2viKPrXhtjAQx7ygQcnea",
  "height":1370973,
  "status":"canceled"
}

Version 1

Lease Transaction Binary Format Version 1

#

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(8\).

\(2\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(3\)

Address or alias of the recipient

See address binary format, alias binary format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\).

\(4\)

Amount of DecentralCoins that will be leased to the account

Long

\(8\)

\(5\)

Transaction fee

Long

\(8\)

\(6\)

Transaction timestamp

Long

\(8\)

\(7\)

Transaction signature

Array[Byte]

\(64\)

The fields \(1\), \(2\), \(3\), \(4\), \(5\) and \(6\) are the transaction body bytes.

Mass Transfer Transaction Binary Format

Learn more about mass transfer transaction.

Version 2

message MassTransferTransactionData {
  message Transfer {
    Recipient recipient = 1;
    int64 amount = 2;
  };
  bytes asset_id = 1;
  repeated Transfer transfers = 2;
  bytes attachment = 3;
};

message Recipient {
  oneof recipient {
    bytes public_key_hash = 1;
    string alias = 2;
  };
}
Mass Transaction Binary Format Version 2

Field

Size

Description

asset_id

\(32\) bytes

ID of token to transfer.

transfers.recipient.public_key_hash

\(20\) bytes

Recipient’s account public key hash (a component of an address, see the address binary format article).

transfers.recipient.alias

From \(4\) to \(30\) bytes

Recipient’s alias.

transfers.amount

\(8\) bytes

Amount of token to transfer, specified in the minimum fraction (“cents”).

attachment

Up to \(140\) bytes

Arbitrary data (typically a comment to transfer).

The maximim number of transfers is \(100\).

JSON Representation of Transaction

{
  "type":11,
  "id":"3LRfudet7avpQcW1AdauiBGb8SSRAaoCugDzngDPLVcv",
  "sender":"3P2rvn2Hpz6pJcH8oPNrwLsetvYP852QQ2m",
  "senderPublicKey":"5DphrhGy6MM4N3yxfB2uR2oFUkp2MNMpSzhZ4uJEm3U1",
  "fee":5100000,
  "feeAssetId":null,
  "timestamp":1528973951321,
  "proofs": [
    "FmGBaWABAy5bif7Qia2LWQ5B4KNmBnbXETL1mE6XEy4AAMjftt3FrxAa8x2pZ9ux391oY5c2c6ZSDEM4nzrvJDo"
  ],
  "version":1,
  "assetId":"Fx2rhWK36H1nfXsiD4orNpBm2QG1JrMhx3eUcPVcoZm2",
  "attachment":"xZBWqm9Ddt5BJVFvHUaQwB7Dsj78UQ5HatQjD8VQKj4CHG48WswJxUUeHEDZJkHgt9LycUpHBFc8ENu8TF8vvnDJCgfy1NeKaUNydqy9vkACLZjSqaVmvfaM3NQB",
  "transferCount":6,
  "totalAmount":500000000000,
  "transfers": [
    {"recipient":"3PHnjQrdK389SbzwPEJHYKzhCqWvaoy3GQB","amount":5000000000},
    {"recipient":"3PGNLwUG2GPpw74teTAxXFLxgFt3T2uQJsF","amount":5000000000},
    {"recipient":"3P5kQneM9EdpVUbFLgefD385LLYTXY5J32c","amount":5000000000},
    {"recipient":"3P2j9FZyygnVDCQvmSc41VCAKwwCQm8QUhA","amount":5000000000},
    {"recipient":"3PNBZutLvMpjzxGAiQGqQuDyanhWyLi2Fhi","amount":5000000000},
    {"recipient":"3P84vdYxzDPFbS5zj9J6yCkmKKA2QMo1DKA","amount":5000000000},
  ],
  "height":1041197
}

Version 1

Mass Transaction Binary Format Version 1

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

type

Byte

\(1\)

Value must be \(11\).

\(2\)

Transaction version

version

Byte

\(1\)

Value must be \(1\).

\(3\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(4.1\)

Flag DecentralCoins/token

Byte

\(1\)

Value is \(0\) for transferring DecentralCoins. Value is \(1\) for transferring other tokens.

\(4.2\)

Id del Token

assetId

Array[Byte]

S

\(S = 0\) if the value of the flag DecentralCoins/token field is \(0\). \(S = 32\) if the value of the flag DecentralCoins/token field is \(1\).

\(5.1\)

Number of transfers

transferCount

Short

\(2\)

\(5.2\)

Address or alias of the recipient

recipient

See address binary format, alias binary format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\).

\(5.3\)

Amount of tokens in the transfer 1

amount

Long

\(8\)

\(5.4\)

Address or alias of the recipient

recipient

See address binary format, alias binary format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\).

\(5.5\)

Amount of tokens in the transfer 2

amount

Long

\(8\)

\(5.[2 × N]\)

Address or alias of the recipient

recipient

See address binary format, alias binary format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\).

\(5.[2 × N + 1]\)

Amount of tokens in the transferN

amount

Long

\(8\)

\(6\)

Transaction timestamp

timestamp

Long

\(8\)

\(7\)

Transaction fee

fee

Long

\(8\)

\(8.1\)

Attachment length

Short

\(2\)

\(8.2\)

Attachment

Array[Byte]

\(2\)

Arbitrary data attached to the transaction.

\(9\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(1\), \(2\), \(3\), \(4.1\), \(4.2\), \(5.1\), \(5.2\), \(5.3\), \(5.4\), \(5.5\), \(5.[2 × N]\), \(5.[2 × N + 1]\), \(6\), \(7\), \(8.1\) and \(8.2\) are the transaction body bytes.

Reissue Transaction Binary Format

Learn more about reissue transaction.

Version 3

message ReissueTransactionData {
  Amount asset_amount = 1;
  bool reissuable = 2;
};

message Amount {
  bytes asset_id = 1;
  int64 amount = 2;
};
Reissue Transaction Binary Format Version 3

Field

Size

Description

asset_id

\(32\) bytes

ID of token to reissue.

asset_amount.amount

\(8\) bytes

Amount of token to reissue, specified in the minimum fraction (“cents”).

reissuable

\(1\) byte

Reissue availability flag.

Version 2

Reissue Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is 2 or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(5\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4\)

Chain ID

chainId

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6\)

Id del Token

assetId

Array[Byte]

\(32\)

\(7\)

Amount of token that will be reissued

quantity

Long

\(8\)

\(8\)

Reissue flag

reissuable

Boolean

\(1\)

If the value is \(0\), then token reissue is not possible. If the value is \(1\), then token reissue is possible.

\(9\)

Transaction fee

fee

Long

\(8\)

\(10\)

Transaction timestamp

timestamp

Long

\(8\)

\(11\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6\), \(7\), \(8\), \(9\) and \(10\) are the transaction body bytes.

JSON Representation of Transaction

{
  "type":5,
  "id":"27ETigYaHym2Zbdp4x1gnXnZPF1VJCqQpXmhszC35Qac",
  "sender":"3PLJciboJqgKsZWLj7k1VariHgre6uu4S2T",
  "senderPublicKey":"DjYEAb3NsQiB6QdmVAzkwJh7iLgUs3yDLf7oFEeuZjfM",
  "fee":100000000,
  "feeAssetId":null,
  "timestamp":1548521785933,
  "proofs": [
    "5mEveeUwBdBqe8naNoV5eAe5vj6fk8U743eHGkhxhs3v9PMsb3agHqpe4EtzpUFdpASJegXyjrGSbynZg557cnSq"
  ],
  "version":2,
  "assetId":"GA4gB3Lf3AQdF1vBCbqGMTeDrkUxY7L83xskRx6Z7kEH",
  "quantity":200000,
  "reissuable":true,
  "chainId":87,
  "height":1368623
}

Version 1

Reissue Transaction Binary Format Version 1

Field order number

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(5\).

\(2\)

Transaction signature

Array[Byte]

\(64\)

\(3\)

Transaction type ID

Byte

\(1\)

This field duplicates field \(1\).

\(4\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(5\)

Id del Token

Array[Byte]

\(32\)

\(6\)

Amount of token that will be reissued

Long

\(8\)

\(7\)

Reissue flag

Boolean

\(1\)

If the value is \(0\), then token reissue is not possible. If the value is \(1\), then token reissue is possible.

\(8\)

Transaction fee

Long

\(8\)

\(9\)

Transaction timestamp

Long

\(8\)

The fields \(3\), \(4\), \(5\), \(6\), \(7\), \(8\) and \(9\) are the transaction body bytes.

Set Asset Script Transaction Binary Format

Learn more about set asset script transaction.

Version 2

message SetAssetScriptTransactionData {
  bytes asset_id = 1;
  bytes script = 2;
};
Set Asset Script Transaction Binary Format Version 2

Field

Size

Description

asset_id

\(32\) bytes

ID of asset.

script

Up to \(8192\) bytes

Asset script.

The maximim number of transfers is \(100\).

JSON Representation of Transaction

{
  "type":15,
  "id":"FwYSpmVDbWQ2BA5NCBZ9z5GSjY39PSyfNZzBayDiMA88",
  "sender":"3P67JUW8Djit7hMjKhADmn6CWvKPbRuh2sQ",
  "senderPublicKey":"AwQYJRHZNd9bvF7C13uwnPiLQfTzvDFJe7DTUXxzrGQS",
  "fee":100000000,
  "feeAssetId":null,
  "timestamp":1547201038106,
  "proofs": [
    "nzYhVKmRmd7BiFDDfrFVnY6Yo98xDGsKrBLWentF7ibe4P9cGWg4RtomHum2NEMBhuyZb5yjThcW7vsCLg7F8NQ"
  ],
  "version":1,
  "assetId":"7qJUQFxniMQx45wk12UdZwknEW9cDgvfoHuAvwDNVjYv",
  "script":"base64:AQa3b8tH",
  "chainId":87,
  "height":1346345
}

Version 1

Set Asset Script Transaction Binary Format Version 1

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(15\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(1\).

\(4\)

Chain ID

chainId

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6\)

Token ID to which the asset script is attached

assetId

Array[Byte]

\(32\)

\(7\)

Transaction fee

fee

Long

\(8\)

\(8\)

Transaction timestamp

timestamp

Long

\(8\)

\(9.1\)

Script existence flag

Boolean

\(1\)

If the value is \(0\), then the token does not have a script. If the value is \(1\), then the token has a script.

\(9.2\)

Script size in bytes

Short

S

\(S = 0\) if the value of the script existence flag field is \(0\). \(S = 2\) if the value of the script existence flag field is \(1\).

\(9.3\)

Asset script

script

String

S

\(S = 0\) if the value of the script existence flag field is \(0\). \(0 < S ≤ 8192\), if the value of the script existence flag field is \(1\).

\(10\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

The fields \(2\), \(3\), \(4\), \(5\), \(6\), \(7\), \(8\), \(9.1\), \(9.2\) and \(9.3\) are the transaction body bytes.

Set Script Transaction Binary Format

Learn more about set script transaction.

Version 2

message SetScriptTransactionData {
  bytes script = 1;
};
Set Script Transaction Binary Format Version 2

Field

Size

Description

script

Up to \(32,768\) bytes

Account script or dApp script.

JSON Representation of Transaction

{
  "type":13,
  "id":"8Nwjd2tcQWff3S9WAhBa7vLRNpNnigWqrTbahvyfMVrU",
  "sender":"3PBSduYkK7GQxVFWkKWMq8GQkVdAGX71hTx",
  "senderPublicKey":"3LZmDK7vuSBsDmFLxJ4qihZynUz8JF9e88dNu5fsus5p",
  "fee":2082496,
  "feeAssetId":null,
  "timestamp":1537973512182,
  "proofs": [
    "V45jPG1nuEnwaYb9jTKQCJpRskJQvtkBcnZ45WjZUbVdNTi1KijVikJkDfMNcEdSBF8oGDYZiWpVTdLSn76mV57"
  ],
  "version":1,
  "script":"base64:AQQAAAAEaW5hbAIAAAAESW5hbAQAAAAFZWxlbmECAAAAB0xlbnVza2EEAAAABGxvdmUCAAAAC0luYWxMZW51c2thCQAAAAAAAAIJAAEsAAAAAgUAAAAEaW5hbAUAAAAFZWxlbmEFAAAABGxvdmV4ZFt5",
  "chainId":87,
  "height":1190001
}

Version 1

Set Script Transaction Binary Format Version 1

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(13\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(1\).

\(4\)

Chain ID

chainId

Byte

\(1\)

\(87\) — for Mainnet. \(84\) — for Testnet. \(83\) — for Stagenet.

\(5\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(6.1\)

Script existence flag

Boolean

\(1\)

If the value is \(0\), then the token does not have a script. If the value is \(1,\) then the token has a script.

\(6.2\)

Script length

Short

S

\(S = 0\) if the value of the script existence flag field is \(0\). \(S = 2\) if the value of the script existence flag field is \(1\).

\(6.3\)

Script

script

String

S

\(S = 0\) if the value of the script existence flag field is \(0\). \(0 < S ≤ 32,768\), if the value of the script existence flag field is \(1\).

\(7\)

Transaction fee

fee

Long

\(8\)

\(8\)

Transaction timestamp

timestamp

Long

\(8\)

\(9\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where \(N\) is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

Transfer Transaction Binary Format

Learn more about transfer transaction.

Version 3

message TransferTransactionData {
  Recipient recipient = 1;
  Amount amount = 2;
  bytes attachment = 3;
};

message Recipient {
  oneof recipient {
    bytes public_key_hash = 1;
    string alias = 2;
  };

message Amount {
  bytes asset_id = 1;
  int64 amount = 2;
};
Transfer Transaction Binary Format Version 3

Field

Size

Description

recipient.public_key_hash

\(20\) bytes

Recipient’s account public key hash (a component of an address, see the address binary format article).

recipient.alias

From \(4\) to \(30\) bytes

Recipient’s alias.

amount.asset_id

\(32\) bytes

ID of token to transfer.

amount.amount

\(8\) bytes

Amount of token to transfer, specified in the minimum fraction (“cents”).

attachment

Up to \(140\) bytes

Arbitrary data (typically a comment to transfer).

Version 2

Transfer Transaction Binary Format Version 2

#

Field

JSON field name

Field type

Field size in bytes

Comment

\(1\)

Version flag

Byte

\(1\)

Indicates the transaction version is \(2\) or higher. Value must be \(0\).

\(2\)

Transaction type ID

type

Byte

\(1\)

Value must be \(4\).

\(3\)

Transaction version

version

Byte

\(1\)

Value must be \(2\).

\(4\)

Public key of the transaction sender

senderPublicKey

Array[Byte]

\(32\)

\(5.1\)

Transferring token type flag

Byte

\(1\)

Value is \(0\) for transferring DecentralCoins. Value is \(1\) for transferring other token.

\(5.2\)

Transferring token ID

assetId

Array[Byte]

S

math:S = 0 if the value of the flag 5.1 is \(0\). \(S = 32\) if the value of the flag 5.1 is \(1\).

\(6.1\)

Fee token type flag

Byte

\(1\)

Value is 0 for fee in DecentralCoins. Value is \(1\) for fee in other token.

\(6.2\)

Fee token ID

feeAssetId

Array[Byte]

S

Token to pay the fee. \(S = 0\) if the value of the flag 6.1 is \(0\). \(S = 32\) if the value of the flag 6.1 field is \(1\).

\(7\)

Transaction timestamp

timestamp

Long

\(8\)

\(8\)

Amount of token in the transfer

amount

Long

\(8\)

\(9\)

Transaction fee

fee

Long

\(8\)

\(10\)

Address or alias

recipient

See address binary format, alias binary format

S

If the first byte of the field is \(1\), then it is followed by address. S in this case equals \(26\). If the first byte of the field is \(2\), then it is followed by alias. In this case \(8 <= S <= 34\)

\(11.1\)

Attachment length

Short

\(2\)

\(11.2\)

Attachment

attachment

Array[Byte]

Up to \(140\) bytes

Arbitrary data attached to the transaction.

\(12\)

Transaction proofs

proofs

See transaction proofs binary format

S

If the array is empty, then \(S = 3\). If the array is not empty, then \(S = 3 + 2 × N + 64 × N\), where N is the number of proofs in the array. The maximum number of proofs in the array is \(8\). The size of each proof is \(64\) bytes.

JSON Representation of Transaction

{
  "type":4,
  "id":"2UMEGNXwiRzyGykG8voDgxnwHA7w5aX5gmxdcf9DZZjL",
  "sender":"3PCeQD3nAyHmzDSYBUnSPDWf9qxqzVU2sjh",
  "senderPublicKey":"6kn1XPDh2XUjVAgznxNousHq3EnKKLx7BRWyJzVFU76J",
  "fee":100000,
  "feeAssetId":null,
  "timestamp":1583160322998,
  "proofs": [
    "2z5fnoigbsCBqRPWqTDeDmGJF6qJwnm2WLspen6c6qziTc73sBh9Kh81kPhUT9DGg7ANwqsXMxQauEvyw3RxNH7z"
  ],
  "version":2,
  "recipient":"3P45uRnyVygTnbEJNxc2CHLUiC4izQxbuuS",
  "assetId":"51LxAtwBXapvvTFSbbh4nLyWFxH6x8ocfNvrXxbTChze",
  "feeAsset":null,
  "amount":30077000000,
  "attachment":"2d6RhvQATwGbyv7dKT3L77758iJx",
  "height":1954598
}

Version 1

Transfer Transaction Binary Format Version 1

#

Field

Field type

Field size in bytes

Comment

\(1\)

Transaction type ID

Byte

\(1\)

Value must be \(4\).

\(2\)

Transaction signature

Array[Byte]

\(64\)

\(3\)

Transaction type ID

Byte

\(1\)

This field duplicates field \(1\).

\(4\)

Public key of the transaction sender

Array[Byte]

\(32\)

\(5.1\)

Transferring token type flag

Byte

\(1\)

Value is \(0\) for transferring DecentralCoins. Value is 1 for transferring other token.

\(5.2\)

Transferring token ID

Array[Byte]

S

\(S = 0\) if the value of the flag 5.1 is \(0\). \(S = 32\) if the value of the flag 5.1 is \(1\).

\(6.1\)

Fee token type flag

Byte

\(1\)

Value is \(0\) for fee in DecentralCoins. Value is \(1\) for fee in other token.

\(6.2\)

Fee token ID

Array[Byte]

S

Token to pay the fee. \(S = 0\) if the value of the flag 6.1 is 0. \(S = 32\) if the value of the flag 6.1 field is \(1\).

\(7\)

Transaction timestamp

Long

\(8\)

\(8\)

Amount of token in the transfer

amount

Long

\(8\)

\(9\)

Transaction fee

fee

Long

\(8\)

\(10\)

Address or alias

recipient

See address binary format, alias binary format

S

\(11.1\)

Attachment length

Short

\(2\)

\(11.2\)

Attachment

attachment

Array[Byte]

Up to \(140\) bytes.

Update Asset Info Transaction Binary Format

Learn more about update asset info transaction.

Version 1

message UpdateAssetInfoTransactionData {
  bytes asset_id = 1;
  string name = 2;
  string description = 3;
}
Update Asset Transaction Binary Format Version 1

Field

Size

Description

asset_id

\(32\) bytes

Token ID.

name

From \(4\) to \(16\) bytes

Token name.

description

From \(0\) to \(1000\) bytes

Token description.

Transaction Proofs Binary Format

Tableholder

The maximum number of proofs is \(8\).

Validation Rules

Account Validation

Account is valid then it is a valid Base58 string and the length of the corresponding array is \(26\) bytes. Version of address (1st byte) is equal to \(1\). The network byte (2nd byte) is equal to network ID. The checksum of address (last \(4\) bytes) is correct.

Transactions Validation

Transfer Transaction Validation

Transfer transaction is valid then:

  • Recipient address is valid. If not, InvalidAddress validation result will be returned.

  • Size of attachment is less than or equals MaxAttachementSize(\(140\) bytes). In other case TooBigArray validation result will be returned.

  • Transaction’s amount is more than \(0\), otherwise NegativeAmount validation result is returned.

  • Transaction’s fee is positive, otherwise InsufficientFee validation result is returned.

  • Adding fee to amount does not lead to Long overflow. In case of Long overflow OverflowError validation result will be returned.

  • Transaction’s signature is valid, otherwise InvalidSignature validation result is returned.

Issue Transaction Validation

Issue transaction is valid then:

  • Sender’s address is valid. If not, InvalidAddress validation result will be returned.

  • Quantity of asset is positive, otherwise NegativeAmount validation result is returned.

  • Transaction’s fee is more than or equals MinFee(\(100000000\) Decentralites = \(1\) DecentralCoin), in other case InsufficientFee validation result is returned.

  • Size of description is less than or equals MaxDescriptionLength(\(1000\) bytes), otherwise TooBigArray is returned.

  • Size of name is more than or equals MinAssetNameLength and less or equals MaxAssetNameLength, in other case InvalidName validation result will be returned.

  • Decimals is positive and less than or equals MaxDecimals, in other case TooBigArray is returned.

  • Transaction’s signature is valid, otherwise InvalidSignature validation result is returned.

Reissue Transaction Validation

Reissue transaction is valid then:

  • Sender’s account is valid. Otherwise InvalidAddress validation result is returned.

  • Quantity is positive, in other case NegativeAmount validation result will be returned.

  • Transaction’s fee is positive, in other case InsufficientFee result will be returned.

  • Transaction’s signature is valid, otherwise InvalidSignature validation result is returned.

Block Validations

Block is valid then:

  • Block chain contains referenced blocks.

  • Block’s signature is valid.

  • Block’s consensus data is valid.

  • Block’s transactions are valid.

Consensus Data Validation

Block’s consensus data is valid then:

  • Block creation time is no more than MaxTimeDrift(\(15\) seconds) in future.

  • Block’s transactions are sorted. This rule works only after \(1477958400000\) on Testnet and \(1479168000000\) on Mainnet.

  • Block chain contains parent block or block chain height is equal \(1\).

  • Block’s base target is valid.

  • Block’s generator signature is valid.

  • Generator’s balance is more than or equals MinimalEffectiveBalanceForGeneration(\(1000000000000\) Decentralites). This rule always works on Testnet and works only after \(1479168000000\) on Mainnet.

  • Block’s hit is less than calculated block’s target.

  • Voted features are sorted in ascending order and are not repeated.

Transactions Data Validation

Block’s transactions are valid then:

  • Creation time of every transaction in block is less than block’s creation time no more than on MaxTxAndBlockDiff(\(2\) hours).

  • All transactions are valid against state.

Transaction validation against state. Transactions are valid then:

  • Transaction is valid by transaction validation rules.

  • Transaction creation time more than block’s creation time no more than on MaxTimeForUnconfirmed(\(90\) minutes). This limitation works always on Testnet and only after \(1479168000000\) on Mainnet.

  • Application of transaction to accounts should not lead to temporary negative balance. This rule works after \(1479168000000\) on Mainnet and after \(1477958400000\) on Testnet.

  • Changes made by transaction should be sorted by their amount. This rule works on both Mainnet and Testnet after \(1479416400000\).

  • Application of transaction’s amount to current balance should not lead to Long overflow.

  • After application of all block’s transactions affected balances should not be negative.

Unconfirmed Transactions Pool Validation

Transaction could be inserted in unconfirmed transactions pool then:

  • Transaction is valid by transaction validation rules.

  • If transaction’s fee is more than or equals minimum fee that was set by the owner of a node.

  • There is a space for a new transaction if unconfirmed transactions pool. By default the pool is limited by \(1000\) transactions.

  • unconfirmed transactions pool does not contain transaction with the same ID.

  • Transaction created not later than MaxTimeForUncofimed(\(90\) minutes) after the last block was created.

  • Transaction creation time is no more than MaxTimeDrift(\(15\) seconds) in future.

  • Transaction is valid against state.

Glossary

A

Cuenta

An account is a cryptographically connected pair of public and on the private key. Accounts uniquely correlate transactions and orders with their senders.

Almacenamiento de Datos de la Cuenta

An account data storage is the store of data records in the key-value format associated with the account. Each account has single data storage. The size of the account data storage is unlimited.

Account Script

An account script is a Ride script that has the following directives:

{-# CONTENT_TYPE EXPRESSION #-}
{-# SCRIPT_TYPE ACCOUNT #-}

The account script is attached to the account using the set script transaction. Only one script can be attached to an account. An account with an account script attached is called a smart account.

Dirección

An address is a unique account identifier. The address can be represented as an alphanumeric string.

Airdrop

An airdrop is a simultaneous sending of tokens to multiple addresses. As a rule, the airdrop is used as an incentive for holders of a certain token as part of a marketing campaign to promote a project, increase its recognition, and attract investors.

Alias

An alias is a short, easy-to-remember address name. There cannot be two aliases with the same name. A single address can have multiple aliases.

Asset

An asset is a synonym for the token.

Asset Script

An asset script is a Ride script that has the following directives:

{-# CONTENT_TYPE EXPRESSION #-}
{-# SCRIPT_TYPE ASSET #-}

The asset script is attached to the asset using the set asset script transaction. You can attach a script to an asset only at the time of the asset creation. However, you can change the script later, if needed. An asset with a script attached to it is called a smart asset.

B

Block

A block is a unit of the blockchain chain. The block contains transactions: from \(0\) to \(6000\) inclusive. The maximum block size is \(1\) MB.

Blockchain

A blockchain is a continuous sequential chain of blocks that are linked using cryptography. The blockchain has its own blockchain height.

Block Height

A block height is the block’s sequence number in the blockchain.

Blockchain Height

A blockchain height is a sequence number of the last block in the blockchain.

Blockchain Network

A blockchain network is a computer network that consists of node.

Block Signature

A block signature is a hash that the mining node receives when it signs the generated block with the private key of the mining account.

C

Consensus

The consensus is a set of rules in accordance with which blockchain operates. DecentralChain uses the LPoS consensus.

Cryptocurrency

A cryptocurrency is a type of digital currency, the creation and control of which is based on cryptographic methods.

D

dApp

A dApp is an account with the dApp script attached.

dApp Script

A dApp script is a Ride script used to create dApp. The dApp script has the following directive:

{-# CONTENT_TYPE DAPP #-}

dApp Script can be attached to the account using the set script transaction, and, as a result, the dApp will be created.

Decentralized Application

A decentralized application is an application that is stored and executed on the blockchain network.

E

Explorer

Explorer (or DecentralChain Explorer) is an online service that displays DecentralChain blockchain data in a human-readable form.

F

Faucet

A test network faucet (or faucet) is a DecentralChain Explorer tool that refills the test network accounts with the DecentralCoins test tokens. For one recharge, the user receives \(10\) testnet DecentralCoins.

G

Gateway

Gateway is a centralized payment solution that allows transferring cryptocurrencies from one blockchain to another and vice versa; as well as transferring fiat money to and out of the blockchain.

Genesis Block

The genesis block (or genesis) is the very first block of the blockchain. The genesis block contains one or several genesis transactions.

Genesis Transaction

Genesis transaction is a genesis block transaction that charges DecentralCoins to an account. The genesis transactions define the initial distribution of DecentralCoins between accounts during the creation of the blockchain.

H

Hash

A hash is a result of applying a hash function.

Hash Function

A hash function (or fold function) is a function that converts an array of input data of arbitrary length into a bit string of a fixed length, performed by a certain algorithm.

I

J

K

L

Leasing

Leasing is a temporary reversible transfer of DecentralCoins from one account to another to increase the stability and security of the network, as well as potentially get mining reward. Note that the DecentralCoin tokens are not actually being transferred to another account, they remain on the sender’s balance, however, they are “frozen” and cannot participate in the buying and selling operations, as well as they cannot be sent to another account. The leased tokens provide the leasing recipient with a greater chance of mining a block. The recipient of the lease can share the income from mining with the one who leased DecentralCoins to him. However, the DecentralChain protocol does not regulate the payment process for LPoS mining, this remains at the discretion of the miner. At any time, the sender can “unfreeze” tokens by invoking the Lease Cancel transaction.

LPoS

LPoS (or Leased Proof-of-Stake) is a consensus algorithm in which the probability of generating the next block by the participant is proportional to the share of cryptocurrencies belonging to this participant or leased to this participant from their total supply. In other words, the more tokens on the account of the miner (own and leased to them), the higher the probability of generating the next block.

M

Mainnet

The mainnet (or main network) is the main DecentralChain blockchain network.

Matcher

Matcher is a service that executes orders on the exchange.

Matcher Fee

A matcher fee is a fee that matcher takes from both accounts that participate in the exchange of the pair of tokens.

Miner

A miner is the owner of the mining node.

Mining

Mining is the process of generating a block by a mining node, as a result of which a new block is added to the blockchain and DecentralCoin tokens are issued. For block generation, miners receive a reward for mining, as well as transaction fees, according to the rules of the DecentralChain-M5 protocol.

Mining Account

A mining account is an account that the mining node uses to block the generated blocks.

Mining Node

A mining node is a node that can perform mining. Each mining node is a validating node node.

Multisignature

Multisignature is an implementation of an electronic signature that requires the use of several private key as a condition for transactions execution.

N

NFT

NFT (Non-Fungible Token) is a tokens with unique ID. Two “regular” tokens can not be distinguished from each other — they are the same, i.e. fungible. Each NFT is unique; there cannot be two identical NFTs. Most often NFTs are used in games.

Node

A node is a host that is connected to the blockchain network using the DecentralChain node application. The node stores blocks, sends and validates transactions.

O

Oracle

Oracle is a provider of data from the outside world to the blockchain.

Oracle Card

An oracle card is a public description of the oracle in the blockchain according to a standardized protocol in the form of a data transaction.

Order

Order (or exchange order) is an instruction to buy or sell a tokens on the exchange.

P

PoS

PoS (Proof-of-Stake) is a consensus algorithm in which the probability of generating the next block is proportional to the share of cryptocurrencies belonging to this participant from their total supply. In other words, the more tokens on the account of a miner, the higher the probability of generating the next block.

PoW

PoW (Proof-of-Work) is a consensus algorithm in which it is required to perform a complex calculation in order to generate a new block. That is, the higher the performance of the miner’s equipment, the higher the probability of generating the next block.

Private Key

The private key is one of a pair of account keys. The account owner signs the transaction with the private key before sending it, and, as a result, gets the digital signature of the transaction.

Public Key

An account script is a Ride script that has the following directives:

Q

R

Ride

The Ride is a functional expression-based programming language. Ride is used to write scripts. The language has strong static typing, it is case sensitive, has no loops and goto-like expressions, and therefore it is Turing-incomplete

S

Script

A script is the source code on the Ride language. There are three types of scripts: dApp script, account script, asset script.

Secret Phrase

Secret phrase (or Seed) is a set of characters (usually, it is 15 English words with spaces between them) that allows you to access your DecentralChain address and, accordingly, the funds on your account. When registering an account, you are asked to keep your secret phrase safe.

Smart Account

A smart account is an account with an account script attached. Only one script can be attached to an account. The account script is attached to the account using the set script transaction.

Smart Asset

A smart asset is a tokens with an asset script attached.

Stagenet

Stagenet (or staging network) is the DecentralChain blockchain network, which is used for experiments, intermediate testing of new functionality, as well as providing access for the DecentralChain community to intermediate releases. It is important to consider that this network is unstable, a frequent rollback of blockchain data to the N-th height in the past is possible.

T

Test Network

Test network (or testnet) is a DecentralChain blockchain test network, which is used by developers to test their products, and by users to get acquainted with the blockchain.

Token

A token is a blockchain object that represents another object from the physical or virtual world or an abstract concept.

Transaction

Transaction is an action on the blockchain on behalf of the account. Transactions can be sent only from the account — thus, any transaction can be correlated with a certain account.

Transaction Body Bytes

An account script is a Ride script that has the following directives:

U

UTX pool

UTX pool (or Unconfirmed Transactions pool) is a pool of unconfirmed node transactions that are waiting for validation.

V

Validating Node

A validating node is a node that validates transactions.

W

Decentralites

One Decentralite is 1/100 000 000 DecentralCoin. 1 Decentralite is the minimum number of DecentralCoins that you can work with within the DecentralChain blockchain.

DecentralCoins

DecentralCoin is the main token of the DecentralChain blockchain. 1 DecentralCoin equals 100,000,000 Decentralites.

WCT

An account script is a Ride script that has the following directives:

X

Y

Z