mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Compare commits
3 Commits
rippled-2.
...
issue-mpto
| Author | SHA1 | Date | |
|---|---|---|---|
|
20555a956b | ||
|
|
003927517f | ||
|
|
9c8c231900 |
@@ -1,35 +1,40 @@
|
||||
import { stringToHex, hexToString } from '@xrplf/isomorphic/dist/utils/index.js'
|
||||
import { MPTokenIssuanceCreateFlags, Client } from 'xrpl'
|
||||
import {
|
||||
MPTokenIssuanceCreateFlags,
|
||||
Client,
|
||||
encodeMPTokenMetadata,
|
||||
decodeMPTokenMetadata
|
||||
} from 'xrpl'
|
||||
|
||||
// Connect to network and get a wallet
|
||||
const client = new Client('wss://s.devnet.rippletest.net:51233')
|
||||
await client.connect()
|
||||
|
||||
console.log('Funding new wallet from faucet...')
|
||||
const { wallet } = await client.fundWallet()
|
||||
console.log('=== Funding new wallet from faucet...===')
|
||||
const { wallet: issuer } = await client.fundWallet()
|
||||
console.log(`Issuer address: ${issuer.address}`)
|
||||
|
||||
// Define metadata as JSON
|
||||
const mpt_metadata = {
|
||||
t: 'TBILL',
|
||||
n: 'T-Bill Yield Token',
|
||||
d: 'A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.',
|
||||
i: 'https://example.org/tbill-icon.png',
|
||||
ac: 'rwa',
|
||||
as: 'treasury',
|
||||
in: 'Example Yield Co.',
|
||||
us: [
|
||||
ticker: 'TBILL',
|
||||
name: 'T-Bill Yield Token',
|
||||
desc: 'A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.',
|
||||
icon: 'https://example.org/tbill-icon.png',
|
||||
asset_class: 'rwa',
|
||||
asset_subclass: 'treasury',
|
||||
issuer_name: 'Example Yield Co.',
|
||||
uris: [
|
||||
{
|
||||
u: 'https://exampleyield.co/tbill',
|
||||
c: 'website',
|
||||
t: 'Product Page'
|
||||
uri: 'https://exampleyield.co/tbill',
|
||||
category: 'website',
|
||||
title: 'Product Page'
|
||||
},
|
||||
{
|
||||
u: 'https://exampleyield.co/docs',
|
||||
c: 'docs',
|
||||
t: 'Yield Token Docs'
|
||||
uri: 'https://exampleyield.co/docs',
|
||||
category: 'docs',
|
||||
title: 'Yield Token Docs'
|
||||
}
|
||||
],
|
||||
ai: {
|
||||
additional_info: {
|
||||
interest_rate: '5.00%',
|
||||
interest_type: 'variable',
|
||||
yield_source: 'U.S. Treasury Bills',
|
||||
@@ -38,8 +43,13 @@ const mpt_metadata = {
|
||||
}
|
||||
}
|
||||
|
||||
// Convert JSON to a string (without excess whitespace), then string to hex
|
||||
const mpt_metadata_hex = stringToHex(JSON.stringify(mpt_metadata))
|
||||
// Encode the metadata.
|
||||
// The encodeMPTokenMetadata function converts the JSON metadata object into
|
||||
// a compact, hex-encoded string, following the XLS-89 standard.
|
||||
// https://xls.xrpl.org/xls/XLS-0089-multi-purpose-token-metadata-schema.html
|
||||
console.log('\n=== Encoding metadata...===')
|
||||
const mpt_metadata_hex = encodeMPTokenMetadata(mpt_metadata)
|
||||
console.log("Encoded mpt_metadata_hex:", mpt_metadata_hex)
|
||||
|
||||
// Define the transaction, including other MPT parameters
|
||||
const mpt_issuance_create = {
|
||||
@@ -54,32 +64,39 @@ const mpt_issuance_create = {
|
||||
}
|
||||
|
||||
// Prepare, sign, and submit the transaction
|
||||
console.log('Sending MPTokenIssuanceCreate transaction...')
|
||||
const submit_response = await client.submitAndWait(mpt_issuance_create, { wallet, autofill: true })
|
||||
console.log('\n=== Sending MPTokenIssuanceCreate transaction...===')
|
||||
const submit_response = await client.submitAndWait(mpt_issuance_create,
|
||||
{ wallet, autofill: true }
|
||||
)
|
||||
|
||||
// Check transaction results and disconnect
|
||||
console.log(JSON.stringify(submit_response, null, 2))
|
||||
// Check transaction results
|
||||
console.log('\n=== Checking MPTokenIssuanceCreate results...===')
|
||||
if (submit_response.result.meta.TransactionResult !== 'tesSUCCESS') {
|
||||
const result_code = response.result.meta.TransactionResult
|
||||
const result_code = submit_response.result.meta.TransactionResult
|
||||
console.warn(`Transaction failed with result code ${result_code}.`)
|
||||
await client.disconnect()
|
||||
process.exit(1)
|
||||
}
|
||||
|
||||
const issuance_id = submit_response.result.meta.mpt_issuance_id
|
||||
console.log(`MPToken created successfully with issuance ID ${issuance_id}.`)
|
||||
console.log(`- MPToken created successfully with issuance ID: ${issuance_id}`)
|
||||
// View the MPT issuance on the XRPL Explorer
|
||||
console.log(`\n- Explorer URL: https://devnet.xrpl.org/mpt/${issuance_id}`)
|
||||
|
||||
// Look up MPT Issuance entry in the validated ledger
|
||||
console.log('Confirming MPT Issuance metadata in the validated ledger.')
|
||||
console.log('\n=== Confirming MPT Issuance metadata in the validated ledger... ===')
|
||||
const ledger_entry_response = await client.request({
|
||||
"command": "ledger_entry",
|
||||
"mpt_issuance": issuance_id,
|
||||
"ledger_index": "validated"
|
||||
})
|
||||
|
||||
// Decode the metadata
|
||||
// Decode the metadata.
|
||||
// The decodeMPTokenMetadata function takes a hex-encoded string representing MPT metadata,
|
||||
// decodes it to a JSON object, and expands any compact field names to their full forms.
|
||||
const metadata_blob = ledger_entry_response.result.node.MPTokenMetadata
|
||||
const decoded_metadata = JSON.parse(hexToString(metadata_blob))
|
||||
console.log('Decoded metadata:', decoded_metadata)
|
||||
|
||||
const decoded_metadata = decodeMPTokenMetadata(metadata_blob)
|
||||
console.log('Decoded MPT metadata: ', decoded_metadata)
|
||||
|
||||
// Disconnect from the client
|
||||
client.disconnect()
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"dependencies": {
|
||||
"xrpl": "^4.4.0"
|
||||
"xrpl": "^4.4.3"
|
||||
},
|
||||
"type": "module"
|
||||
}
|
||||
|
||||
@@ -1 +1 @@
|
||||
xrpl-py==4.3.0
|
||||
xrpl-py==4.4.3
|
||||
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
category: 2025
|
||||
date: "2025-11-19"
|
||||
template: '../../@theme/templates/blogpost'
|
||||
seo:
|
||||
title: Introducing XRP Ledger version 2.6.2
|
||||
description: rippled version 2.6.2 is now available. This version contains a new amendment and critical bug fix.
|
||||
labels:
|
||||
- rippled Release Notes
|
||||
markdown:
|
||||
editPage:
|
||||
hide: true
|
||||
---
|
||||
# Introducing XRP Ledger version 2.6.2
|
||||
|
||||
Version 2.6.2 of `rippled`, the reference server implementation of the XRP Ledger protocol, is now available. This release adds a new `fixDirectoryLimit` amendment and critical bug fix.
|
||||
|
||||
|
||||
## Action Required
|
||||
|
||||
If you run an XRP Ledger server, upgrade to version 2.6.2 as soon as possible to ensure service continuity.
|
||||
|
||||
|
||||
## Install / Upgrade
|
||||
|
||||
On supported platforms, see the [instructions on installing or updating `rippled`](../../docs/infrastructure/installation/index.md).
|
||||
|
||||
| Package | SHA-256 |
|
||||
|:--------|:--------|
|
||||
| [RPM for Red Hat / CentOS (x86-64)](https://repos.ripple.com/repos/rippled-rpm/stable/rippled-2.6.2-1.el9.x86_64.rpm) | `e3b041906a75c3c52cc6423219d7ba9c199a5d736d2e3978a5ce0ac5ef693fdf` |
|
||||
| [DEB for Ubuntu / Debian (x86-64)](https://repos.ripple.com/repos/rippled-deb/pool/stable/rippled_2.6.2-1_amd64.deb) | `0887b5a77c43c362ea7680b83df40b955a5748b712924acf2212b2de29e3373b` |
|
||||
|
||||
For other platforms, please [build from source](https://github.com/XRPLF/rippled/blob/master/BUILD.md). The most recent commit in the git log should be the change setting the version:
|
||||
|
||||
```text
|
||||
commit df24ee077438e03673a9c6661c41e8f070b90cd9
|
||||
Author: Vladislav Vysokikh <vvysokikh@gmail.com>
|
||||
Date: Tue Nov 18 09:28:59 2025 +0000
|
||||
|
||||
Version 2.6.2
|
||||
```
|
||||
|
||||
|
||||
## Full Changelog
|
||||
|
||||
### Amendments
|
||||
|
||||
The following amendment is open for voting with this release:
|
||||
|
||||
- **fixDirectoryLimit** - Removes directory page limits. Object reserve requirements provide enough incentive to avoid creating unnecessary objects on the XRP Ledger. ([#5935](https://github.com/XRPLF/rippled/pull/5935))
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Fixed an assertion failure when all the inner transactions of a `Batch` transaction were invalid. ([#5670](https://github.com/XRPLF/rippled/pull/5670))
|
||||
|
||||
|
||||
## Credits
|
||||
|
||||
The following GitHub users contributed to this release:
|
||||
|
||||
- RippleX Engineering
|
||||
- RippleX Docs
|
||||
- RippleX Product
|
||||
|
||||
|
||||
## Bug Bounties and Responsible Disclosures
|
||||
|
||||
We welcome reviews of the `rippled` code and urge researchers to responsibly disclose any issues they may find.
|
||||
|
||||
To report a bug, please send a detailed report to: <bugs@xrpl.org>
|
||||
@@ -10,7 +10,6 @@
|
||||
- group: '2025'
|
||||
expanded: false
|
||||
items:
|
||||
- page: 2025/rippled-2.6.2.md
|
||||
- page: 2025/rippled-2.6.1.md
|
||||
- page: 2025/vulnerabilitydisclosurereport-bug-sep2025.md
|
||||
- page: 2025/devnet-reset-oct.md
|
||||
|
||||
@@ -27,7 +27,7 @@ A transaction that fails with a `tec` code destroys the XRP paid as a [transacti
|
||||
| `tecCANT_ACCEPT_OWN_NFTOKEN_OFFER` | 157 | The transaction tried to accept an offer that was placed by the same account to buy or sell a [non-fungible token](../../../../concepts/tokens/nfts/index.md). {% amendment-disclaimer name="NonFungibleTokensV1_1" /%} |
|
||||
| `tecCLAIM` | 100 | Unspecified failure, with transaction cost destroyed. |
|
||||
| `tecCRYPTOCONDITION_ERROR` | 146 | This [EscrowCreate][] or [EscrowFinish][] transaction contained a malformed or mismatched crypto-condition. |
|
||||
| `tecDIR_FULL` | 121 | The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
| `tecDIR_FULL` | 121 | The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger. |
|
||||
| `tecDUPLICATE` | 149 | The transaction tried to create an object (such as a [DepositPreauth][] authorization) that already exists. |
|
||||
| `tecDST_TAG_NEEDED` | 143 | The [Payment transaction][] omitted a [destination tag](../../../../concepts/transactions/source-and-destination-tags.md), but the destination account has the `lsfRequireDestTag` flag enabled. |
|
||||
| `tecEMPTY_DID` | 187 | The transaction tried to create a [DID entry][] with no contents. A DID must not be empty. {% amendment-disclaimer name="DID" /%} |
|
||||
|
||||
@@ -40,18 +40,14 @@ Create an on-ledger [check](../../../../concepts/payment-types/checks.md), which
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, {% $frontmatter.seo.title %} transactions can result in the following [transaction result codes](../transaction-results/index.md):
|
||||
|
||||
| Error Code | Description |
|
||||
|:-----------|:------------|
|
||||
| `tecNO_PERMISSION` | The `Destination` account is blocking incoming Checks. {% amendment-disclaimer name="DisallowIncoming" /%} |
|
||||
| `temREDUNDANT` | The `Destination` is the sender of the transaction. |
|
||||
| `tecNO_DST` | The `Destination` [account](../../../../concepts/accounts/index.md) does not exist in the ledger. |
|
||||
| `tecDST_TAG_NEEDED` | The `Destination` account has the `RequireDest` flag enabled but the transaction does not include a `DestinationTag` field. |
|
||||
| `tecFROZEN` | `SendMax` specifies a token which is [frozen](../../../../concepts/tokens/fungible-tokens/freezes.md). |
|
||||
| `tecEXPIRED` | The `Expiration` of the transaction is in the past. |
|
||||
| `tecINSUFFICIENT_RESERVE` | The sender does not have enough XRP to meet the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves) after adding the Check. |
|
||||
| `tecDIR_FULL` | Either the sender or the destination of the Check cannot own more objects in the ledger.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
- If the `Destination` account is blocking incoming Checks, the transaction fails with the result code `tecNO_PERMISSION`. {% amendment-disclaimer name="DisallowIncoming" /%}
|
||||
- If the `Destination` is the sender of the transaction, the transaction fails with the result code `temREDUNDANT`.
|
||||
- If the `Destination` [account](../../../../concepts/accounts/index.md) does not exist in the ledger, the transaction fails with the result code `tecNO_DST`.
|
||||
- If the `Destination` account has the `RequireDest` flag enabled but the transaction does not include a `DestinationTag` field, the transaction fails with the result code `tecDST_TAG_NEEDED`.
|
||||
- If `SendMax` specifies a token which is [frozen](../../../../concepts/tokens/fungible-tokens/freezes.md), the transaction fails with the result `tecFROZEN`.
|
||||
- If the `Expiration` of the transaction is in the past, the transaction fails with the result `tecEXPIRED`.
|
||||
- If the sender does not have enough XRP to meet the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`.
|
||||
- If either the sender or the destination of the Check cannot own more objects in the ledger, the transaction fails with the result `tecDIR_FULL`.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
@@ -65,7 +65,7 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
|
||||
| Error Code | Description |
|
||||
|:--------------------------|:------------|
|
||||
| `tecDIR_FULL` | The sender owns too many items in the ledger already.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
| `tecDIR_FULL` | The sender owns too many items in the ledger already. |
|
||||
| `tecINSUFFICIENT_RESERVE` | The sender does not have enough XRP to meet the [reserve requirement](/docs/concepts/accounts/reserves.md) of creating a new Delegate ledger entry. |
|
||||
| `tecNO_PERMISSION` | At least one permission in the `Permissions` list is not delegatable. See [Permission Values](../../data-types/permission-values.md) for which permissions are not delegatable. |
|
||||
| `tecNO_TARGET` | The account specified in the `Authorize` field does not exist in the ledger. |
|
||||
|
||||
@@ -24,7 +24,6 @@ This example assumes that the issuer of the token is the signer of the transacti
|
||||
"AssetScale": 4,
|
||||
"TransferFee": 0,
|
||||
"MaximumAmount": "50000000",
|
||||
"Flags": 83659,
|
||||
"MPTokenMetadata": "7B2274223A225442494C4C222C226E223A22542D42696C6C205969656C6420546F6B656E222C2264223A2241207969656C642D62656172696E6720737461626C65636F696E206261636B65642062792073686F72742D7465726D20552E532E205472656173757269657320616E64206D6F6E6579206D61726B657420696E737472756D656E74732E222C2269223A226578616D706C652E6F72672F7462696C6C2D69636F6E2E706E67222C226163223A22727761222C226173223A227472656173757279222C22696E223A224578616D706C65205969656C6420436F2E222C227573223A5B7B2275223A226578616D706C657969656C642E636F2F7462696C6C222C2263223A2277656273697465222C2274223A2250726F647563742050616765227D2C7B2275223A226578616D706C657969656C642E636F2F646F6373222C2263223A22646F6373222C2274223A225969656C6420546F6B656E20446F6373227D5D2C226169223A7B22696E7465726573745F72617465223A22352E303025222C22696E7465726573745F74797065223A227661726961626C65222C227969656C645F736F75726365223A22552E532E2054726561737572792042696C6C73222C226D617475726974795F64617465223A22323034352D30362D3330222C226375736970223A22393132373936525830227D7D",
|
||||
"Fee": "12",
|
||||
"Flags": 122,
|
||||
|
||||
@@ -56,7 +56,7 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
|
||||
| `temBAD_AMOUNT` | The `Amount` field is not valid. For example, the amount was zero for a buy offer, or the amount is denominated in fungible tokens but the `NFToken` has the [`lsfOnlyXRP` flag](../../data-types/nftoken.md#nftoken-flags) enabled. |
|
||||
| `temBAD_EXPIRATION` | The specified `Expiration` time is invalid (for example, `0`). |
|
||||
| `tecDIR_FULL` | The sender already owns too many objects in the ledger, or there are already too many offers to buy or sell this token.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
| `tecDIR_FULL` | The sender already owns too many objects in the ledger, or there are already too many offers to buy or sell this token. |
|
||||
| `tecEXPIRED` | The specified `Expiration` time has already passed. |
|
||||
| `tecFROZEN` | The `Amount` is denominated in fungible tokens, but one of the trust lines that would receive tokens from this offer is [frozen](../../../../concepts/tokens/fungible-tokens/freezes.md). This could be the seller's trust line or the `NFToken`'s issuer's trust line (if the `NFToken` has a transfer fee). |
|
||||
| `tecINSUFFICIENT_RESERVE` | The sender does not have enough XRP to meet the [reserve requirement](../../../../concepts/accounts/reserves.md) after placing this offer. |
|
||||
|
||||
@@ -58,7 +58,7 @@ Transactions of the OfferCreate type support additional values in the [`Flags` f
|
||||
|
||||
| Error Code | Description |
|
||||
|:-------------------------|:--------------------------------------------------|
|
||||
| `tecDIR_FULL` | The owner owns too many items in the ledger, or the order book contains too many Offers at the same exchange rate already.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
| `tecDIR_FULL` | The owner owns too many items in the ledger, or the order book contains too many Offers at the same exchange rate already. |
|
||||
| `tecEXPIRED` | The transaction specifies an `Expiration` time that has already passed. |
|
||||
| `tecFROZEN` | The transaction involves a token on a [frozen](../../../../concepts/tokens/fungible-tokens/freezes.md) trust line (including local and global freezes). The `TakerPays` (buy amount) token has been deep-frozen by the issuer. |
|
||||
| `tecINSUF_RESERVE_OFFER` | The owner does not have enough XRP to meet the reserve requirement of adding a new offer ledger entry, and the transaction did not convert any currency. (If the transaction successfully traded any amount, the transaction succeeds with the result code `tesSUCCESS`, but does not create an offer ledger entry for the remainder.) |
|
||||
|
||||
@@ -55,7 +55,7 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
|
||||
| Error Code | Description |
|
||||
|:--------------------------|:------------|
|
||||
| `tecDIR_FULL` | The transaction would create a new PermissionedDomain, but the sender's owner directory is full.<br>This error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
| `tecDIR_FULL` | The transaction would create a new PermissionedDomain, but the sender's owner directory is full. |
|
||||
| `tecINSUFFICIENT_RESERVE` | The transaction would create a new PermissionedDomain, but the sender does not have enough XRP to meet the increased owner reserve. |
|
||||
| `tecNO_ENTRY` | The transaction attempted to modify a Domain that does not exist. Check the `DomainID` field of the transaction. |
|
||||
| `tecNO_ISSUER` | At least one of the issuers specified in the `AcceptedCredentials` field is does not exist in the XRP Ledger. Check the `Issuer` field of each member of the array. |
|
||||
|
||||
@@ -43,7 +43,7 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| Error Code | Description |
|
||||
|:--------------------------|:-------------------------------------------------|
|
||||
| `temINVALID_COUNT` | The `TicketCount` field is invalid. It must be an integer from 1 to 250. |
|
||||
| `tecDIR_FULL` | This transaction would cause the account to own more than the limit of 250 Tickets at a time, or more than the maximum number of ledger objects in general.<br>The maximum ledger objects error is effectively impossible to receive if {% amendment-disclaimer name="fixDirectoryLimit" compact=true /%} is enabled. |
|
||||
| `tecDIR_FULL` | This transaction would cause the account to own more than the limit of 250 Tickets at a time, or more than the maximum number of ledger objects in general. |
|
||||
| `tecINSUFFICIENT_RESERVE` | The sending account does not have enough XRP to meet the [owner reserve](../../../../concepts/accounts/reserves.md) of all the requested Tickets. |
|
||||
|
||||
## See Also
|
||||
|
||||
147
docs/tutorials/how-tos/use-tokens/issue-a-multi-purpose-token.md
Normal file
147
docs/tutorials/how-tos/use-tokens/issue-a-multi-purpose-token.md
Normal file
@@ -0,0 +1,147 @@
|
||||
---
|
||||
seo:
|
||||
description: Issue a Multi-Purpose Token (MPT) with arbitrary metadata on the XRP Ledger.
|
||||
metadata:
|
||||
indexPage: true
|
||||
labels:
|
||||
- Multi-Purpose Token
|
||||
- MPT
|
||||
- Token Issuance
|
||||
---
|
||||
# Issue a Multi-Purpose Token (MPT)
|
||||
|
||||
A [Multi-Purpose Token (MPT)](../../../concepts/tokens/fungible-tokens/multi-purpose-tokens.md) lets you to quickly access powerful, built-in tokenization features on the XRP Ledger with minimal code.
|
||||
|
||||
This tutorial shows you how to issue an MPT with on-chain metadata such as the token's ticker, name, or description, encoded according to the MPT [metadata schema](../../../concepts/tokens/fungible-tokens/multi-purpose-tokens.md#metadata-schema) defined in [XLS-89](https://xls.xrpl.org/xls/XLS-0089-multi-purpose-token-metadata-schema.html).
|
||||
|
||||
## Goals
|
||||
|
||||
By the end of this tutorial, you will be able to:
|
||||
|
||||
- Issue a new MPT using the `MPTokenIssuanceCreate` transaction.
|
||||
- Encode or decode token metadata following MPT standards best practices.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
To complete this tutorial, you should:
|
||||
|
||||
- Have a basic understanding of the XRP Ledger and token issuance.
|
||||
- Have an XRP Ledger client library set up in your development environment. This page provides examples for the following:
|
||||
- **JavaScript** with the [xrpl.js library](https://github.com/XRPLF/xrpl.js). See [Get Started Using JavaScript](../../javascript/build-apps/get-started.md) for setup steps.
|
||||
|
||||
## Source Code
|
||||
|
||||
You can find the complete source code for this tutorial's example in the [code samples section of this website's repository](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/issue-mpt-with-metadata).
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Install dependencies
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
From the code sample folder, use npm to install dependencies:
|
||||
|
||||
```bash
|
||||
npm install xrpl
|
||||
```
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 2. Set up client and fund issuer wallet
|
||||
|
||||
Import the client library, instantiate a client to connect to the XRPL, and fund a new wallet to act as the token issuer.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" before="// Define metadata as JSON" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 3. Define and encode MPT metadata
|
||||
|
||||
Define your token's metadata as a JSON object:
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" from="// Define metadata as JSON" before="// Encode the metadata" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
The metadata schema supports both long field names (e.g., `ticker`, `name`, `desc`) and compact short keys (e.g., `t`, `n`, `d`). To save space on the ledger, it’s recommended to use short key names. The MPT metadata field has a 1024-byte limit, so using compact keys allows you to include more information.
|
||||
|
||||
The SDK libraries provide utility functions to encode or decode the metadata for you, so you don't have to. If long field names are provided in the metadata JSON, the _encoding_ utility function automatically shortens them to their compact key equivalents before encoding. Similarly, when decoding, the _decoding_ utility function converts the shorthands back to the respective long names.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
Use the `encodeMPTokenMetadata()` function to encode metadata with `xrpl.js`.
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" from="// Encode the metadata" before="// Define the transaction" /%}
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
{% admonition type="warning" name="Warning" %}
|
||||
While the encoding utility formats the JSON for you correctly and replaces the full key names with shorthands, it does **not** validate the metadata content or size.
|
||||
{% /admonition %}
|
||||
|
||||
### 4. Prepare the MPTokenIssuanceCreate transaction
|
||||
|
||||
Create the transaction object, specifying the issuer, asset scale, maximum amount, transfer/trade flags, and the encoded metadata.
|
||||
|
||||
| Field | Value |
|
||||
|:------------------|:---------------------------------------------------------------------|
|
||||
| `TransactionType` | The type of transaction, in this case `MPTokenIssuanceCreate`. |
|
||||
| `Account` | The wallet address of the account that is issuing the MPT. |
|
||||
| `AssetScale` | The number of decimal places for the token. |
|
||||
| `MaximumAmount` | The maximum supply of the token to be issued. |
|
||||
| `TransferFee` | The transfer fee (if any) to charge for token transfers. |
|
||||
| `Flags` | Flags to control transfer/trade permissions. |
|
||||
| `MPTokenMetadata` | The hex-encoded metadata for the token. |
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" from="// Define the transaction" before="// Prepare, sign, and submit the transaction" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 5. Submit the transaction
|
||||
|
||||
Sign and submit the transaction, then wait for validation.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" from="// Prepare, sign, and submit the transaction" before="// Check transaction results" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
### 6. Check transaction result
|
||||
|
||||
Verify that the transaction succeeded and retrieve the MPT issuance ID.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" from="// Check transaction results" before="// Look up MPT Issuance entry" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
A `tesSUCCESS` result indicates that the MPT issuance transaction was processed successfully and the token was created.
|
||||
|
||||
### 7. Confirm MPT issuance and decode metadata
|
||||
|
||||
Look up the MPT issuance entry in the validated ledger and decode the metadata to verify it matches your original input.
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Javascript" %}
|
||||
{% code-snippet file="/_code-samples/issue-mpt-with-metadata/js/issue-mpt-with-metadata.js" language="js" from="// Look up MPT Issuance entry" /%}
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
The _decoding_ utility function converts the metadata shorthand key names back to their respective long names.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts**:
|
||||
- [Multi-Purpose Tokens (MPT)](../../../concepts/tokens/fungible-tokens/multi-purpose-tokens.md)
|
||||
- **References**:
|
||||
- [MPTokenIssuanceCreate Transaction](../../../references/protocol/transactions/types/mptokenissuancecreate.md)
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -742,19 +742,6 @@ Changes the way Checks transactions affect account metadata, so that Checks are
|
||||
Without this amendment, Checks transactions ([CheckCreate][], [CheckCash][], and [CheckCancel][]) only update the account history of the sender. With this amendment, those transactions affect both the sending and receiving accounts. This amendment has no effect unless the [Checks amendment](#checks) is also enabled.
|
||||
|
||||
|
||||
### fixDirectoryLimit
|
||||
[fixDirectoryLimit]: #fixdirectorylimit
|
||||
|
||||
| Amendment | fixdirectorylimit |
|
||||
|:-------------|:----------------------|
|
||||
| Amendment ID | 41765F664A8D67FF03DDB1C1A893DE6273690BA340A6C2B07C8D29D0DD013D3A |
|
||||
| Status | Open for Voting |
|
||||
| Default Vote (Latest stable release) | No |
|
||||
| Pre-amendment functionality retired? | No |
|
||||
|
||||
This amendment removes the directory page limit. Object reserve requirements provide enough incentive to avoid creating unnecessary objects on the XRP Ledger.
|
||||
|
||||
|
||||
### fixDisallowIncomingV1
|
||||
[fixDisallowIncomingV1]: #fixdisallowincomingv1
|
||||
|
||||
|
||||
Reference in New Issue
Block a user