* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity. * Cancel escrow: fix notes * Add draft of updated cancel-escrow.js. * Update intro to escrows. * Add Escrow Tutorial * Minor corrections * Fix headings, add HTML * Update escrow docs This commit re-createsf205a92db2with some adjustments: - Omit the accidentally-created dir full of junk - Fix some typos and one mistake in the Escrow limitations section - Add a table to the EscrowCreate ref to clarify valid combos of fields. * Concept info from send-a-time-held-escrow added to escrow.md * IA: Move "Consensus Network" files This re-creates some work from the original commit56fffe0b9f* Rewrite escrows article (re-created) This commit re-creates relevant work from the following commits:9a4a588f2bUpdate escrow.md context infoe1b017dc83Remove references to using escrow for interledger payments. * IA: Move "XRPL servers" files This re-creates some work from original commit7611979abf* IA: move "production readiness" files. Re-creates work from the following commit:692438693aMove tutorials to concepts * New intro articles Original commit:56fffe0b9f* IA: Reorg account concepts Re-creates some work from original commit56fffe0b9f* IA: reorg transaction concepts Original commits:9d4eff9940WIP - reorg accounts7611979abfWIP dir. reorg * IA: reorg consensus concepts Original commit:56fffe0b9f* IA: Reorg ledger docs Original commit:56fffe0b9f- Rephrased some details of the section * IA: rename issuing/operational addresses page Original commit:56fffe0b9f* Moving use cases * Fleshing out Use Cases Note, the dactyl-config.yml file has not been fully updated. * Clean up checks conceptual info. * Remove redundant checks use case section Original commit:3c29e9c05e* IA: move Dex under tokens Original commit:d08b3ba7d7* Touch up stablecoin issuer use case (#1856) * Consolidate stablecoin use case * Stablecoin issuer: cleanup progress through sending * Stablecoin issuer: reorg second half (Note: the dactyl-config.yml is not fully reconciled yet) * Move rippled and clio tutorials into infrastructure * Remove link to checks amendement. * Add note to account_objects.md about commandline interface type field. * Merge expiration case with lifecycle section. * Interoperability Use Cases * Add graphics to intro * Move escrow use cases to dedicated page. * Update use case page intros and corresponding concept info. * Clarify meaning of direct XRP payments. * Intro link updates * Payment use cases * Remove some unnecessary links in transactions section Original commit:e6fcf4a4dc* Link cleanup in Tokens section Original commit:9588dd5e70* Touch up 'Configure Peering' section Original commit:fc8f0990b8* Clean up links in accounts section Original commit:3da5fde7a8* Add NFT mkt use case * p2p payments: edits to Wallets * Clean up payments use cases * Refine history description * IA: use case cleanup * IA: reconcile servers, ledgers sections * IA: reconcile payment types, tx, tokens * IA: reconcile accounts section * IA: reconcile infra * IA: Fix most broken links * Full Docs Index: omit from sidebar * IA: fix up most broken links * fix Absolute path link to internal content * Quick updates to Software Ecosystem * Remove some absolute links to internal resources * Fix remaining broken links in JA target * Contributing: tweak formatting * Tutorials: fix some minor issues * remove interop use cases * remove intro image and personal references to dennis * alphabetize-transaction-nav * Remove unused files * Add QS escrow tutorials * IA: move ledgers, consensus protocol files around * IA: update nav for new page hierarchy * reordering of topics under new networks and servers top-nav * Move "Naming" to "What is XRP?" * Update dactyl-config.yml Remove xrp.md from the TOC. * Update list-xrp-as-an-exchange.md Update link to what-is-xrp * Update list-xrp-as-an-exchange.ja.md Change link to what-is-xrp * Update currency-formats.md Change link to what-is-xrp * Update currency-formats.ja.md Change link to what-is-xrp * Update cancel-an-expired-escrow.md Change link to what-is-xrp * Update paymentchannelfund.md Change link to what-is-xml * Update look-up-escrows.md Change link to what-is-xrp * Update tokens.md change link to what-is-xrp * Update use-payment-channels.md * Update send-a-time-held-escrow.md Update link to what-is-xml * fix broken links * Update parallel-networks.md Change link to what-is-xml * Update parallel-networks.ja.md * Update invariant-checking.md Remove link to xrp.html * Update invariant-checking.ja.md Remove link to xrp.html * Update transaction-cost.md Change link to what-is-xrp * Update transaction-cost.ja.md Change link to what-is-xrp * Update send-a-conditionally-held-escrow.md Change link to what-is-xrp * Update stablecoin-issuer.md Change link to what-is-xrp * Update tokens.ja.md Change link to what-is-xml * Update autobridging.ja.md Change link to what-is-xrp * Update currency-formats.md update text * reorganize infrastructure nav section * Update currency-formats.md Try removing link altogether. * Update currency-formats.ja.md Remove link to what-is-xrp.html * move commandline usage topic to infrastructure * initial intro rewrite * minor update to language * IA.v3: rm Production Readiness * Delete xrp.md * Update xrp link in snippet * Add redirect for old xrp.html URL * Small edits to 'What is XRP?' article * Add missing imgs * XRP - copy edit per @DennisDawson * restructure tutorials nav and pages * fix broken links * more broken link fixes * Algo trading: 1st draft * Algo trading: notes on taxes * Algo trading: edits per review * algo trading: fix broken link * Ledger structure: rewrite for accuracy and clarity * Update links to removed 'tree format' header * Ledger Structure: Update diagrams * Re-gen CSS for ledger structure changes * Ledger structure: edits per review * IA.v3: fix broken NFT links introduced by rebase * Desktop Wallet (py): update little stuff * Update some capacity/storage details * contribute doc nav update * fix image link in create diagram page * IAv3: Fix 'Ledgers' blurb * Update full history requirements with details from community members * add reviewer suggestions * Edits per @trippled review * Apply suggestions from peer review Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> * FH: reword file size limit note per review * Update software ecosystem * updates per review * Minor tweaks to graphics * fixTypos * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * [JA] update AccountDelete cost * custom transactors doc * add doc to dactyl config * [JA] fix NonFungibleTokensV1_1 amendment status * [JA] update NFTokenOffer page * Remove old, unused XRP article (#2039) * add reviewer suggestions * Add tooling to check for file/nav consistency - From the repo top, run tool/check_file_consistency.py to look for Markdown files that exist in the "content/" directory but aren't used in the documentation. - New "enforce_filenames" filter prints a warning to console when building, if a file's path and filename don't match expectations based on its place in the nav and top heading. * File consistency checker: correctly handle filenames starting in _ * Remove unused old 'get started' and associated code * Create Resources section & reorg some files - Rename some files/folders based on their place in the nav - Move a bunch of non-documentation stuff, and docs on contributing code and/or docs to the new "Resources" section. - Known issue: nav spills into a second row on page widths between 993px-1110px. To be fixed in a later CSS update, maybe along with making the Resources dropdown multi-column. * Fix #2078 code tab bug CSS not built yet, to reduce merge conflicts. Won't have any effect until that happens. * fix Transaction JSON * [JA] translate contributing contents * fix contributing-to-documentation parent * fix contribute-code blurb * Top nav: add cols for Resources, fix broken links * CSS: fix top nav overflows * Fix broken link from redirect not in JA target * Top nav: add Infra to article types * Update contrib info & rename intro file * [ja] Update link to suggested first page to translate * [ja] fix contribute docs organization * Run private network with docker tutorial (#2065) * [NO-ISSUE] Run private network with docker tutorial Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker. Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it. * Add minor link fixes and Japanese target * Apply suggestions from code review Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Add link to ripple-docker-testnet setup scripts in See Also section * Update repo URL --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * add intro gfx (#2036) * add intro gfx * Move graphic up * Update some graphics with their revised versions * Add updated version of the custodial vs non-custodial graphic --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com> * Update to reflect current UNL publishers * [ja] update contributing Co-authored-by: tequ <git@tequ.dev> * Incorporate feedback on "What is XRP" page. (#2099) * Add trademark info for XRP * Revert section to previous state * Fix broken link (#2101) --------- Co-authored-by: Oliver Eggert <oeggert@ripple.com> Co-authored-by: ddawson <dennis.s.dawson@gmail.com> Co-authored-by: Maria Shodunke <mshodunke@ripple.com> Co-authored-by: tequ <git@tequ.dev> Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: develoQ <develoQ.jp@gmail.com> Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
28 KiB
html, parent, blurb, embed_xrpl_js, filters, labels
| html | parent | blurb | embed_xrpl_js | filters | labels | ||
|---|---|---|---|---|---|---|---|
| issue-a-fungible-token.html | use-tokens.html | Create your own token and issue it on the XRP Ledger Testnet. | true |
|
|
Issue a Fungible Token
Anyone can issue various types of tokens in the XRP Ledger, ranging from informal "IOUs" to fiat-backed stablecoins, purely digital fungible and semi-fungible tokens, and more. This tutorial shows the technical steps of creating a token in the ledger. For more information on how XRP Ledger tokens work, see Issued Currencies; for more on the business decisions involved in issuing a stablecoin, see Stablecoin Issuer.
Prerequisites
- You need two funded XRP Ledger accounts, each with an address, secret key, and some XRP. For this tutorial, you can generate new test credentials as needed.
- Each address needs enough XRP to satisfy the reserve requirement including the additional reserve for a trust line.
- You need a connection to the XRP Ledger network. As shown in this tutorial, you can use public servers for testing.
- You should be familiar with the Getting Started instructions for your preferred client library. This page provides examples for the following:
- JavaScript with the xrpl.js library. See Get Started Using JavaScript for setup steps.
- Python with the
xrpl-pylibrary. See Get Started using Python for setup steps. - Java with the xrpl4j library. See Get Started Using Java for setup steps.
- You can also read along and use the interactive steps in your browser without any setup.
Example Code
Complete sample code for all of the steps of these tutorials is available under the MIT license.
- See Code Samples: Issue a Fungible Token in the source repository for this website.
Steps
{% set n = cycler(* range(1,99)) %}
{{n.next()}}. Get Credentials
To transact on the XRP Ledger, you need an address and secret key, and some XRP. You also need one or more recipients who are willing to hold the tokens you issue: unlike in some other blockchains, in the XRP Ledger you cannot force someone to hold a token they do not want.
The best practice is to use "cold" and "hot" addresses. The cold address is the issuer of the token. The hot address is like a regular user's address that you control. It receives tokens from the cold address, which you can then transfer to other users. A hot address is not strictly necessary, since you could send tokens directly to users from the cold address, but it is good practice for security reasons. In production, you should take extra care of the cold address's cryptographic keys (for example, keeping them offline) because it is much harder to replace a cold address than a hot address.
In this tutorial, the hot address receives the tokens you issue from the cold address. You can get the keys for two addresses using the following interface.
{% if use_network is undefined or use_network == "Testnet" %} {% set use_network = "Testnet" %} {% set faucet_url = "https://faucet.altnet.rippletest.net/accounts" %} {% elif use_network == "Devnet" %} {% set faucet_url = "https://faucet.devnet.rippletest.net/accounts" %} {# No faucet for Mainnet! #} {% endif %} {{ start_step("Generate") }} Get {{use_network}} credentials
{{ end_step() }}Caution: Ripple provides the Testnet and Devnet for testing purposes only, and sometimes resets the state of these test networks along with all balances. As a precaution, do not use the same addresses on Testnet/Devnet and Mainnet.
When you're building production-ready software, you should use an existing account, and manage your keys using a secure signing configuration.
{{n.next()}}. Connect to the Network
You must be connected to the network to submit transactions to it. The following code shows how to connect to a public XRP Ledger Testnet server with a supported client library:
JavaScript
{{ include_code("_code-samples/get-started/js/base.js", language="js") }}
Python
{{ include_code("_code-samples/issue-a-token/py/issue-a-token.py", start_with="# Connect", end_before="# Get credentials", language="py") }}
Java
{{ include_code("_code-samples/issue-a-token/java/IssueToken.java", start_with="// Construct a network client", end_before="// Create cold", language="java") }}
Note: The JavaScript code samples in this tutorial use the async/await pattern. Since await needs to be used from within an async function, the remaining code samples are written to continue inside the main() function started here. You can also use Promise methods .then() and .catch() instead of async/await if you prefer.
For this tutorial, click the following button to connect:
{% include '_snippets/interactive-tutorials/connect-step.md' %}
{{n.next()}}. Configure Issuer Settings
First, configure the settings for your cold address (which will become the issuer of your token). Most settings can be reconfigured later, with the following exceptions:
- Default Ripple: This setting is required so that users can send your token to each other. It's best to enable it before setting up any trust lines or issuing any tokens.
- Authorized Trust Lines: (Optional) This setting (also called "Require Auth") limits your tokens to being held only by accounts you've explicitly approved. You cannot enable this setting if you already have any trust lines or offers for any token. Note: To use authorized trust lines, you must perform additional steps that are not shown in this tutorial.
Other settings you may want to, optionally, configure for your cold address (issuer):
| Setting | Recommended Value | Summary |
|---|---|---|
| Require Destination Tags | Enabled or Disabled | Enable if you process withdrawals of your token to outside systems. (For example, your token is a stablecoin.) |
| Disallow XRP | Enabled or Disabled | Enable if this address isn't meant to process XRP payments. |
| Transfer Fee | 0–1% | Charge a percentage fee when users send your token to each other. |
| Tick Size | 5 | Limit the number of decimal places in exchange rates for your token in the decentralized exchange. A tick size of 5-6 reduces churn of almost-equivalent offers and speeds up price discovery compared to the default of 15. |
| Domain | (Your domain name) | Set to a domain you own so can verify ownership of the accounts. This can help reduce confusion or impersonation attempts. |
You can change these settings later as well.
Note: Many issuing settings apply equally to all tokens issued by an address, regardless of the currency code. If you want to issue multiple types of tokens in the XRP Ledger with different settings, you should use a different address to issue each different token.
The following code sample shows how to send an [AccountSet transaction][] to enable the recommended cold address settings:
JavaScript
{{ include_code("_code-samples/issue-a-token/js/issue-a-token.js", start_with="// Configure issuer", end_before="// Configure hot", language="js") }}
Python
{{ include_code("_code-samples/issue-a-token/py/issue-a-token.py", start_with="# Configure issuer", end_before="# Configure hot", language="py") }}
Java
{{ include_code("_code-samples/issue-a-token/java/IssueToken.java", start_with="// Configure issuer", end_before="// Configure hot", language="java") }}
{{ start_step("Configure Issuer") }}
{{n.next()}}. Wait for Validation
Most transactions are accepted into the next ledger version after they're submitted, which means it may take 4-7 seconds for a transaction's outcome to be final. You should wait for your earlier transactions to be fully validated before proceeding to the later steps, to avoid unexpected failures from things executing out of order. For more information, see Reliable Transaction Submission.
The code samples in this tutorial use helper functions to wait for validation when submitting a transaction:
- JavaScript: The
submit_and_verify()function, as defined in the submit-and-verify code sample. - Python: The
submit_and_wait()method of the xrpl-py library. - Java: The
submitAndWaitForValidation()method in the sample Java class.
Tip: Technically, you can configure the hot address in parallel with configuring the issuer address. For simplicity, this tutorial waits for each transaction one at a time.
{{ start_step("Wait (Issuer Setup)") }} {% include '_snippets/interactive-tutorials/wait-step.md' %} {{ end_step() }}
{{n.next()}}. Configure Hot Address Settings
The hot address does not strictly require any settings changes from the default, but the following are recommended as best practices:
| Setting | Recommended Value | Summary |
|---|---|---|
| Default Ripple | Disabled | Leave this setting disabled. (This is the default.) |
| Authorized Trust Lines | Enabled | Enable this setting on the hot address—and never approve any trust lines to the hot address—to prevent accidentally issuing tokens from the wrong address. (Optional, but recommended.) |
| Require Destination Tags | Enabled or Disabled | Enable if you process withdrawals of your token to outside systems. (For example, your token is a stablecoin.) |
| Disallow XRP | Enabled or Disabled | Enable if this address isn't meant to process XRP payments. |
| Domain | (Your domain name) | Set to a domain you own so can verify ownership of the accounts. This can help reduce confusion or impersonation attempts. |
The following code sample shows how to send an [AccountSet transaction][] to enable the recommended hot address settings:
JavaScript
{{ include_code("_code-samples/issue-a-token/js/issue-a-token.js", start_with="// Configure hot address", end_before="// Create trust line", language="js") }}
Python
{{ include_code("_code-samples/issue-a-token/py/issue-a-token.py", start_with="# Configure hot address", end_before="# Create trust line", language="py") }}
Java
{{ include_code("_code-samples/issue-a-token/java/IssueToken.java", start_with="// Configure hot address", end_before="// Create trust line", language="java") }}
{{ start_step("Configure Hot Address") }}
{{n.next()}}. Wait for Validation
As before, wait for the previous transaction to be validated by consensus before continuing.
{{ start_step("Wait (Hot Address Setup)") }} {% include '_snippets/interactive-tutorials/wait-step.md' %} {{ end_step() }}
{{n.next()}}. Create Trust Line from Hot to Cold Address
Before you can receive tokens, you need to create a trust line to the token issuer. This trust line is specific to the currency code of the token you want to issue, such as USD or FOO. You can choose any currency code you want; each issuer's tokens are treated as separate in the XRP Ledger protocol. However, users' balances of tokens with the same currency code can ripple between different issuers if the users enable rippling settings.
The hot address needs a trust line like this before it can receive tokens from the issuer. Similarly, each user who wants to hold your token must also create a trust line¹. Each trust line increases the reserve requirement of the hot address, so you must hold enough spare XRP to pay for the increased requirement. Your reserve requirement goes back down if you remove the trust line.
Tip: A trust line has a "limit" on how much the recipient is willing to hold; others cannot send you more tokens than your specified limit. For community credit systems, you may want to configure limits per individual based on how much you trust that person. For other types and uses of tokens, it is normally OK to set the limit to a very large number.
To create a trust line, send a [TrustSet transaction][] from the hot address with the following fields:
| Field | Value |
|---|---|
TransactionType |
"TrustSet" |
Account |
The hot address. (More generally, this is the account that wants to receive the token.) |
LimitAmount |
An object specifying how much, of which token, from which issuer, you are willing to hold. |
LimitAmount.currency |
The currency code of the token. |
LimitAmount.issuer |
The cold address. |
LimitAmount.value |
The maximum amount of the token you are willing to hold. |
The following code sample shows how to send a [TrustSet transaction][] from the hot address, trusting the issuing address for a limit of 1 billion FOO:
JavaScript
{{ include_code("_code-samples/issue-a-token/js/issue-a-token.js", start_with="// Create trust line", end_before="// Send token", language="js") }}
Python
{{ include_code("_code-samples/issue-a-token/py/issue-a-token.py", start_with="# Create trust line", end_before="# Send token", language="py") }}
Java
{{ include_code("_code-samples/issue-a-token/java/IssueToken.java", start_with="// Create trust line", end_before="// Send token", language="java") }}
{{ start_step("Make Trust Line") }}
Currency code:
<div class="input-group row mt-2">
<div class="input-group-prepend">
<div class="input-group-text form-check bg-transparent">
<input type="radio" id="use-hex-code" name="currency-code-type" />
</div>
</div>
<label for="use-hex-code" class="input-group-text col-lg-3">Non-standard:</label>
<input type="text" id="currency-code-hex" pattern="[0-9A-F]{40}" value="015841551A748AD2C1F76FF6ECB0CCCD00000000" title="40 hexadecimal characters" class="form-control col-lg-8" />
</div>
<div class="input-group row mt-4">
<label for="trust-limit" class="input-group-text col-lg-3">Limit:</label>
<input type="number" id="trust-limit" min="0" value="1000000000" title="Maximum amount the hot address can hold" class="form-control col-lg-9" />
</div>
Note: If you use Authorized Trust Lines, there is an extra step after this one: the cold address must approve the trust line from the hot address. For details of how to do this, see Authorizing Trust Lines.
{{n.next()}}. Wait for Validation
As before, wait for the previous transaction to be validated by consensus before continuing.
{{ start_step("Wait (TrustSet)") }} {% include '_snippets/interactive-tutorials/wait-step.md' %} {{ end_step() }}
{{n.next()}}. Send Token
Now you can create tokens by sending a [Payment transaction][] from the cold address to the hot address. This transaction should have the following attributes (dot notation indicates nested fields):
| Field | Value |
|---|---|
TransactionType |
"Payment" |
Account |
The cold address issuing the token. |
Amount |
An token amount specifying how much of which token to create. |
Amount.currency |
The currency code of the token. |
Amount.value |
Decimal amount of the token to issue, as a string. |
Amount.issuer |
The cold address issuing the token. |
Destination |
The hot address (or other account receiving the token) |
Paths |
Omit this field when issuing tokens. |
SendMax |
Omit this field when issuing tokens. |
DestinationTag |
Any whole number from 0 to 232-1. You must specify something here if you enabled Require Destination Tags on the hot address. |
You can use auto-filled values for all other required fields.
The following code sample shows how to send a [Payment transaction][] to issue 88 FOO from the cold address to the hot address:
JavaScript
{{ include_code("_code-samples/issue-a-token/js/issue-a-token.js", start_with="// Send token", end_before="// Check balances", language="js") }}
Python
{{ include_code("_code-samples/issue-a-token/py/issue-a-token.py", start_with="# Send token", end_before="# Check balances", language="py") }}
Java
{{ include_code("_code-samples/issue-a-token/java/IssueToken.java", start_with="// Send token", end_before="// Check balances", language="java") }}
{{ start_step("Send Token") }}
{{n.next()}}. Wait for Validation
As before, wait for the previous transaction to be validated by consensus before continuing.
{{ start_step("Wait (Payment)") }} {% include '_snippets/interactive-tutorials/wait-step.md' %} {{ end_step() }}
{{n.next()}}. Confirm Token Balances
You can check the balances of your token from the perspective of either the token issuer or the hot address. Tokens issued in the XRP Ledger always have balances that sum to 0: negative from the perspective of the issuer and positive from the perspective of the holder.
Use the [account_lines method][] to look up the balances from the perspective of the holder. This lists each trust line along with its limit, balance, and settings.
Use the [gateway_balances method][] to look up balances from the perspective of a token issuer. This provides a sum of all tokens issued by a given address.
Tip: Since the XRP Ledger is fully public, you can check the balances of any account at any time without needing any cryptographic keys.
The following code sample shows how to use both methods:
JavaScript
{{ include_code("_code-samples/issue-a-token/js/issue-a-token.js", start_with="// Check balances", end_before="// End of", language="js") }}
Python
{{ include_code("_code-samples/issue-a-token/py/issue-a-token.py", start_with="# Check balances", language="py") }}
Java
{{ include_code("_code-samples/issue-a-token/java/IssueToken.java", start_with="// Check balances", end_before="// Helper", language="java") }}
{{ start_step("Confirm Balances") }} Confirm Balances
{{ end_step() }}Next Steps
Now that you've created the token, you can explore how it fits into features of the XRP Ledger:
- Send tokens from the hot address to other users.
- Trade it in the decentralized exchange.
- Monitor for incoming payments of your token.
- Create an xrp-ledger.toml file and set up domain verification for your token's issuer.
- Learn about other features of XRP Ledger tokens.
Footnotes
¹ Users can hold your token without explicitly creating a trust line if they buy your token in the decentralized exchange. Buying a token in the exchange automatically creates the necessary trust lines. This is only possible if someone is selling your token in the decentralized exchange.
{% include '_snippets/rippled-api-links.md' %} {% include '_snippets/tx-type-links.md' %} {% include '_snippets/rippled_versions.md' %}
