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.
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. If the order sender in exchange transaction is a dApp or smart account, this does nor affect the minimum fee.
The minimum fee is increased by \(0.004\) DecentralCoins for each smart asset involved, except for:
Smart assets used as matcher fees in exchange transactions.
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.
Transaction type |
Transaction type ID |
Minimum transaction fee in DecentralCoins |
---|---|---|
\(6\) |
\(0.001\) |
|
\(10\) |
\(0.001\) |
|
\(12\) |
\(0.001\) per kilobyte. The size is rounded up to an integer number of kilobytes. |
|
\(7\) |
\(0.003\) |
|
\(16\) |
\(0.005 + K\). \(K\) is the number of assets issued as a result of dApp script invocation that are not non-fungible tokens. |
|
\(3\) |
\(1\) for reqular token. \(0.001\) for non-fungible token. |
|
\(9\) |
\(0.001\) |
|
\(8\) |
\(0.001\) |
|
\(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. |
|
\(5\) |
\(0.001\) |
|
\(15\) |
\(1\) |
|
\(13\) |
\(0.01\) |
|
\(14\) |
\(0.001\) |
|
\(4\) |
\(0.001\) |
|
\(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\).
Sponsored Fees#
Users of DecentralChain-based apps should pay a fee for each transaction. This is the entry threshold for new users. Sometimes users don’t know anything about DecentralCoins or don’t understand how to get DecentralCoins or don’t want to spend money. Sponsorship enables launching apps that do not require DecentralCoins from users.
Sponsored Asset#
An account that issued an asset can enable sponsorship, that is, allow all users to pay a fee in this asset for invoke script transactions and transfer transactions. The sponsor can distribute the sponsored asset among app users.
How to Enable Sponsorship#
You can use Decentral.Exchange online to enable sponsorship.
Make sure you are logged into your account. Find the desired asset in the list, hover cursor over it and in its menu (⋮) click Enable Sponsorship.
Carefully read the Terms and Conditions before proceeding and then in the Amount per transaction box specify the required amount of sponsored asset to be charged to users. Then click Continue.
In the following window double-check the entered data and if everything is correct click Send or click Go Back to make corrections. Activation will be processed with the next block.
After activation you’ll be able to change the specified amount without deactivation. To do so, find your asset in the list, hover cursor over it and in its menu (⋮) click Change Sponsorship.
The fee for this type of transaction is \(0.001\) DecentralCoins.
How to Disable Sponsorship#
You can use Decentral.Exchange online to disable sponsorship.
Make sure you are logged into your account. Find the desired asset in the list, hover cursor over it and in its menu (⋮) click Disable Sponsorship.
In the following window click Sign to deactivate the sponsorship. Deactivation will be processed with the next block.
Restrictions#
Only the issuer of the asset can be a sponsor.
Smart assets cannot be sponsored assets.
Sponsorship only works if the sponsor’s account balance is greater than \(1.005\) DecentralCoins. If the account balance becomes less than \(1.005\) DecentralCoins, the sponsorship is suspended, and if the balance becomes more than \(1.005\) DecentralCoins the sponsorship is resumed.
The fee in the sponsored asset can only be specified for invoke script transactions and transfer transactions.
How It Works#
After enabling sponsorship, if the requirements described in the restrictions section are met, the sponsorship works as follows:
A user broadcasts a transaction and specifies a fee in the sponsored asset.
The sponsor receives the fee in the sponsored asset from the user’s account.
Block generators receive the fee in DecentralCoins from the sponsor’s account (in accordance with the DecentralChain-M5 protocol, the fee is distributed between the current block generator and the next block generator in a ratio of \(\frac{40}{60}\).
The script on the sponsor’s account is not executed and does not affect the sponsorship because the transaction is sent from the user’s account.
The fee in DecentralCoins charged to the sponsor is proportional to the fee specified by the transaction sender:
feeInDecentralCoins = feeInSponsoredAsset × 0,001 / minSponsoredAssetFee
minSponsoredAssetFee is the amount of sponsored asset equivalent to \(0.001\) DecentralCoins. The sponsor sets this value when enabling sponsorship. For example, if the sponsor sets \(3\) tokens = \(0.001\) DecentralCoins, then the minimum fee for invoke script transactions is \(15\) tokens, which corresponds to \(0.005\) DecentralCoins. Please note:
The user can use the sponsored asset to pay for transactions that are not related to a certain app.
The user can specify any amount of fee, such as the one significantly exceeding the minimum.
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
}
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.
Binary Format#
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:
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#
Transaction type ID |
Name |
Description |
---|---|---|
\(3\) |
Issues a token. |
|
\(5\) |
Reissues a token. |
|
\(6\) |
Decreases the amount of token. |
|
\(15\) |
Modifies the asset script. |
|
\(17\) |
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
}
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 |
|
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
}
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 |
|
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
}
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 |
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
}
Field |
Description |
---|---|
assetId |
Token ID base58 encoded. |
chainId |
|
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
}
Field |
Description |
---|---|
name |
Token name. From \(4\) to \(16\) bytes. |
description |
Token description. From \(0\) to \(1000\) bytes. |
chainId |
|
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#
Transaction type ID |
Name |
Description |
---|---|---|
\(4\) |
Transfers a token to another account. |
|
\(7\) |
Exchanges two different tokens between two accounts. Contains two counter orders: a buy order and a sell order. |
|
\(10\) |
Creates alias for the sender’s address. |
|
\(11\) |
Transfers a token, up to \(100\) recipients. |
|
\(12\) |
Adds, modifies and deletes data entries in the sender’s account data storage. |
|
\(13\) |
Assigns the dApp script or account script to the sender’s account. |
|
\(16\) |
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
}
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.
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.
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
}
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
}
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
}
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
}
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
}
Field |
Description |
---|---|
chainId |
|
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": []
}
}
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#
Transaction type ID |
Name |
Description |
---|---|---|
\(8\) |
Leases DecentralCoins. |
|
\(9\) |
Cancels the leasing. |
|
\(14\) |
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
}
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"
}
}
Field |
Description |
---|---|
leaseId |
Lease transaction ID. |
chainId |
|
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.
Sponsor Fee Transaction#
Sponsor fee transaction enables or disables sponsorship. Sponsorship allows any user to pay a fee in the sponsored asset (instead of DecentralCoins) for invoke script transactions and transfer transactions. More about sponsorship.
Only the asset issuer can set up sponsorship. Smart asset cannot be a sponsored asset.
Fee
The minimum fee for the sponsor fee 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": "5HNegWomhj1nzyggf1oAvujNJGCqbzFjM72BLYtrBecw",
"sender": "3N3ErpmUdJWy6DW4ruAr14YDis9UaiTwHd6",
"feeAssetId": null,
"proofs": [
"5jF8WpF7jxf5SBMHMbc2WcfqX3R6fRvssBGSNfzAM8p3uSmno9XzYy5b565ez5fG9vqUGrENFvcrbhk36bzCaqkP"
],
"assetId": "p1vuxnGyfH9VFiuyKmsh25rn6MedjGbQu7d6Zt1sY4U",
"fee": 100000000,
"minSponsoredAssetFee": 100,
"id": "5gHUMzmBfn4KP3tELzHtw3EYR947rzWUp5PuyF7hUW23",
"type": 14,
"version": 1,
"timestamp": 1585725309659,
"height": 934757
}
Field |
Description |
---|---|
minSponsoredAssetFee |
Amount of asset that is equivalent to \(0.001\) DecentralCoins (\(100,000\) Decentralites): an integer value specified in the minimum fraction (“cents”) of asset. null – disable sponsorship. |
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 sponsor fee transaction binary format.
Ride Structure
The SponsorFeeTransaction structure is used for transaction handling in smart contracts.
Genesis#
Transaction type ID |
Name |
Description |
---|---|---|
\(1\) |
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:
Transaction fields check including:
Timestamp check: the transaction timestamp should be not more than \(2\) hours ago or \(1.5\) hours ahead from the current block timestamp.
Transaction version check: all the features required to support this version should be activated.
Transaction type check: all the features required to support this type should be activated.
Check of token amounts: the values must be non-negative.
Check different fields depending on the transaction type.
Sender’s balance check.
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.
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.
The sender’s signature verification
For ordinary accounts (without script).
For account script execution if the sender is a smart account.
For verifier function execution if the sender is dApp.
A similar check is performed for orders in an exchange transaction.
For the invoke script transaction:
Calculation of the result of dApp callable function.
dApp balance check: dApp account should have enough funds for dApp script actions.
Check that the transaction fee is not less than the minimum fee based on script actions.
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.