mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
Move more amendment disclaimers to end of section
This commit is contained in:
@@ -1,15 +1,11 @@
|
||||
---
|
||||
html: decentralized-identifiers.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: Decentralized identifiers enable verifiable, decentralized digital identities.
|
||||
labels:
|
||||
- DID
|
||||
- DID
|
||||
---
|
||||
# Decentralized Identifiers
|
||||
|
||||
{% amendment-disclaimer name="DID" /%}
|
||||
|
||||
A Decentralized Identifier (DID) is a new type of identifier defined by the World Wide Web Consortium (W3C) that enables verifiable, digital identities. DIDs are fully under the control of the DID owner, independent from any centralized registry, identity provider, or certificate authority.
|
||||
|
||||
The key principles of a DID are:
|
||||
@@ -24,6 +20,8 @@ The key principles of a DID are:
|
||||
|
||||
{% admonition type="info" name="Note" %}The implementation of DIDs on the XRP Ledger conforms to the requirements in the [DID v1.0 specification](https://www.w3.org/TR/did-core/).{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="DID" /%}
|
||||
|
||||
|
||||
## How It Works
|
||||
|
||||
|
||||
@@ -3,14 +3,12 @@ seo:
|
||||
title: Automated Market Makers (AMMs)
|
||||
description: Automated Market Makers (AMMs) are an essential part of cryptocurrency, providing liquidity between asset pairs. Learn more about AMMs and the XRP Ledger.
|
||||
labels:
|
||||
- XRP
|
||||
- Decentralized Exchange
|
||||
- AMM
|
||||
- XRP
|
||||
- Decentralized Exchange
|
||||
- AMM
|
||||
---
|
||||
# Automated Market Makers
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
Automated Market Makers (AMMs) provide liquidity in the XRP Ledger's decentralized exchange (DEX). Each AMM holds a pool of two assets. You can swap between the two assets at an exchange rate set by a mathematical formula.
|
||||
|
||||

|
||||
@@ -25,10 +23,8 @@ LP tokens enable liquidity providers to:
|
||||
- Vote to change the AMM fee settings, each vote weighted by how many LP tokens the voter holds.
|
||||
- Bid some of their LP tokens to receive a temporary discount on the AMM trading fees.
|
||||
|
||||
<!--
|
||||
## What is an AMM?
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
-->
|
||||
|
||||
## How the AMM Works
|
||||
|
||||
|
||||
@@ -100,14 +100,14 @@ This is a consequence of how the network reaches agreement. For the entire peer-
|
||||
|
||||
## Permissioned and Hybrid Offers
|
||||
|
||||
{% amendment-disclaimer name="PermissionedDEX" /%}
|
||||
|
||||
By specifying a valid **permissioned domain ID**, you can place offers into a permissioned DEX instead of using the open DEX. You can only place a _permissioned offer_ if you hold the [credentials](../../decentralized-storage/credentials.md) required by the permissioned domain, and permissioned offers can only match other offers in the same permissioned domain. You can also place a _hybrid offer_ by using a domain ID and the Hybrid flag. Hybrid offers work like permissioned offers except that they can also match offers in the open DEX. Businesses with strict compliance requirements may want to use a permissioned DEX exclusively while traders with more relaxed compliance requirements can use hybrid offers to provide liquidity in more places.
|
||||
|
||||
In most ways, permissioned and hybrid offers function like regular offers. They support all the same options, such as Fill-or-Kill, and are subject to the same requirements like the reserve per offer. One difference is that offers in a permissioned DEX can become _invalid_ if the account placing the offer loses access to the permissioned domain, for example because their credentials expired.
|
||||
|
||||
For more information, see [Permissioned DEXes](./permissioned-dexes.md).
|
||||
|
||||
{% amendment-disclaimer name="PermissionedDEX" /%}
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
@@ -1,17 +1,13 @@
|
||||
---
|
||||
html: cross-chain-bridges.html
|
||||
parent: xrpl-sidechains.html
|
||||
seo:
|
||||
description: Cross-chain bridges for the XRP Ledger enable value in the form of XRP and other tokens (IOUs) to move efficiently between blockchains.
|
||||
status: not_enabled
|
||||
labels:
|
||||
- Blockchain
|
||||
- Interoperability
|
||||
- Blockchain
|
||||
- Interoperability
|
||||
---
|
||||
# Cross-Chain Bridges
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
Cross-chain bridges enable you to move XRP and tokens between the XRP Ledger and other blockchains. When referring to the blockchains connected by a bridge, one is the locking chain and the other the issuing chain.
|
||||
|
||||
A locking chain is where the digital asset originates from. These assets are locked in a trust when sent across a bridge to an issuing chain.
|
||||
@@ -22,6 +18,8 @@ An issuing chain is an independent ledger with its own consensus algorithm and t
|
||||
|
||||
Both the locking and issuing chains operate as parallel networks with independent nodes and validators. They rely on independent [witness servers](witness-servers.md) to watch transactions between the two chains and attest that assets have moved into specifically designated accounts.
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
|
||||
## How Do Bridges Work?
|
||||
|
||||
|
||||
@@ -1,16 +1,12 @@
|
||||
---
|
||||
html: xrpl-sidechains.html
|
||||
parent: concepts.html
|
||||
seo:
|
||||
description: An XRPL sidechain is an independent ledger with its own consensus algorithm, transaction types, and rules.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Interoperability
|
||||
- Blockchain
|
||||
- Interoperability
|
||||
---
|
||||
# XRPL Sidechains
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
A sidechain is an independent ledger with its own consensus algorithm, transaction types, rules, and nodes. It acts as its own blockchain, running parallel to the mainchain (XRP Ledger), enabling value to move between the two without compromising the speed, efficiency, and throughput of the mainchain.
|
||||
|
||||
Sidechains can customize the XRP Ledger protocol to the needs of a specific use case or project and run it as its own blockchain. Some examples include:
|
||||
@@ -20,6 +16,8 @@ Sidechains can customize the XRP Ledger protocol to the needs of a specific use
|
||||
* Building your own algorithmic stable coin with customised ledger types and transaction rules.
|
||||
* Building permissioned or nearly permissionless, centralized or largely decentralized ledgers whose assets can be traded on the Mainnet [decentralized exchange](../tokens/decentralized-exchange/index.md).
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
|
||||
**Notes:**
|
||||
|
||||
|
||||
@@ -1,18 +1,14 @@
|
||||
---
|
||||
html: witness-servers.html
|
||||
parent: xrpl-sidechains.html
|
||||
seo:
|
||||
description: A witness server is a light-weight server that witnesses and signs transactions between the XRP Ledger and another chain.
|
||||
status: not_enabled
|
||||
labels:
|
||||
- Blockchain
|
||||
- Interoperability
|
||||
- Blockchain
|
||||
- Interoperability
|
||||
---
|
||||
# Witness Servers
|
||||
[[Source]](https://github.com/seelabs/xbridge_witness "Source")
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
A _witness server_ acts as a neutral witness for transactions between a locking chain and an issuing chain. It listens to the door accounts on both sides of a bridge and signs attestations that confirm a transaction occurred. They are essentially acting as an oracle to “prove” that value was locked or burned on a source account, which allows the recipient to then claim (via minting or unlocking) the equivalent funds on the destination account.
|
||||
|
||||
The bridge between the locking chain and the issuing chain includes the following information in its configuration:
|
||||
@@ -24,6 +20,8 @@ Anyone can run a witness server. However, the burden is on the participants of t
|
||||
|
||||
{% admonition type="info" name="Note" %}Issuing chains may choose to configure a bridge with only one witness server initially and run the witness server itself. This strategy is helpful in the initial period, when the issuing chain hasn't established itself yet in the marketplace.{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
|
||||
## Witness Server Configuration
|
||||
|
||||
|
||||
@@ -1,18 +1,16 @@
|
||||
---
|
||||
html: account_channels.html
|
||||
parent: account-methods.html
|
||||
seo:
|
||||
description: Get a list of payment channels where the account is the source of the channel.
|
||||
labels:
|
||||
- Payment Channels
|
||||
- Payment Channels
|
||||
---
|
||||
# account_channels
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/AccountChannels.cpp "Source")
|
||||
|
||||
{% amendment-disclaimer name="PayChan" /%}
|
||||
|
||||
The `account_channels` method returns information about an account's Payment Channels. This includes only channels where the specified account is the channel's source, not the destination. (A channel's "source" and "owner" are the same.) All information retrieved is relative to a particular version of the ledger.
|
||||
|
||||
{% amendment-disclaimer name="PayChan" /%}
|
||||
|
||||
## Request Format
|
||||
An example of the request format:
|
||||
|
||||
|
||||
@@ -887,10 +887,10 @@ rippled json ledger_entry '{ "nft_page": "255DD86DDF59D778081A06D02701E9B2C9F4F0
|
||||
|
||||
### Get MPT Issuance Object
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
Return an `MPTokenIssuance` object.
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
| Field | Type | Description |
|
||||
|:---------------|:-------|:----------------------|
|
||||
| `mpt_issuance` | String | The 192-bit `MPTokenIssuanceID` that's associated with the MPTokenIssuance, as hexadecimal. |
|
||||
@@ -933,10 +933,10 @@ rippled json ledger_entry '{ "mpt_issuance": "000004C463C52827307480341125DA0577
|
||||
|
||||
### Get MPToken Object
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
Return an `MPToken` object.
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
| Field | Type | Description |
|
||||
|:--------------------------|:-----------------|:------------|
|
||||
| `mptoken` | ️Object or String | If a string, interpret as ledger entry ID of the MPToken to retrieve. If an object, requires the sub-fields `account` and `mpt_issuance_id` to uniquely identify the MPToken. |
|
||||
|
||||
@@ -2,17 +2,14 @@
|
||||
seo:
|
||||
description: Calculate the aggregate price of specified Oracle instances.
|
||||
labels:
|
||||
- Oracle
|
||||
- Oracle
|
||||
---
|
||||
# get_aggregate_price
|
||||
|
||||
{% amendment-disclaimer name="PriceOracle" /%}
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/GetAggregatePrice.cpp "Source")
|
||||
|
||||
|
||||
The `get_aggregate_price` method retrieves the aggregate price of specified `Oracle` objects, returning three price statistics: mean, median, and trimmed mean.
|
||||
|
||||
{% amendment-disclaimer name="PriceOracle" /%}
|
||||
|
||||
## Request Format
|
||||
|
||||
|
||||
@@ -62,8 +62,6 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
|
||||
## Special AMM AccountRoot Entries
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
Automated Market Makers use an AccountRoot ledger entry to issue their LP Tokens and hold the assets in the AMM pool, and an [AMM ledger entry](amm.md) for tracking some of the details of the AMM. The address of an AMM's AccountRoot is randomized so that users cannot identify and fund the address in advance of the AMM being created. Unlike normal accounts, AMM AccountRoot objects are created with the following settings:
|
||||
|
||||
- `lsfDisableMaster` **enabled** and no means of authorizing transactions. This ensures no one can control the account directly, and it cannot send transactions.
|
||||
@@ -79,6 +77,8 @@ In addition, the following special rules apply to an AMM's AccountRoot entry:
|
||||
|
||||
Other than those exceptions, these accounts are like ordinary accounts; the LP Tokens they issue behave like other [tokens](../../../../concepts/tokens/index.md) except that those tokens can also be used in AMM-related transactions. You can check an AMM's balances and the history of transactions that affected it the same way you would with a regular account.
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
## AccountRoot Flags
|
||||
|
||||
Many AccountRoot flags correspond to options you can change with an [AccountSet transaction][]. However, the bit values used in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with **`lsf`**.
|
||||
|
||||
@@ -2,17 +2,17 @@
|
||||
seo:
|
||||
description: List of validators currently believed to be offline.
|
||||
labels:
|
||||
- Blockchain
|
||||
- Blockchain
|
||||
---
|
||||
# NegativeUNL
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/f64cf9187affd69650907d0d92e097eb29693945/include/xrpl/protocol/detail/ledger_entries.macro#L85-L91 "Source")
|
||||
|
||||
{% amendment-disclaimer name="NegativeUNL" /%}
|
||||
|
||||
The `NegativeUNL` ledger entry type contains the current status of the [Negative UNL](../../../../concepts/consensus-protocol/negative-unl.md), a list of trusted validators currently believed to be offline.
|
||||
|
||||
Each ledger version contains **at most one** `NegativeUNL` entry. If no validators are currently disabled or scheduled to be disabled, there is no `NegativeUNL` entry.
|
||||
|
||||
{% amendment-disclaimer name="NegativeUNL" /%}
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
```json
|
||||
|
||||
@@ -76,22 +76,22 @@ When processing a multi-signed transaction, the server looks up the `Account` va
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
{% amendment-disclaimer name="MultiSignReserve" /%}
|
||||
|
||||
SignerList entries can have the following value in the `Flags` field:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
|:-------------------|:-------------|:--------------|:-------------------------|
|
||||
| `lsfOneOwnerCount` | `0x00010000` | 65536 | If this flag is enabled, this SignerList counts as one item for purposes of the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves). Otherwise, this list counts as N+2 items, where N is the number of signers it contains. This flag is automatically enabled if you add or update a signer list after the [MultiSignReserve amendment][] is enabled. |
|
||||
|
||||
{% amendment-disclaimer name="MultiSignReserve" /%}
|
||||
|
||||
|
||||
## Signer Lists and Reserves
|
||||
|
||||
A signer list contributes to its owner's [reserve requirement](../../../../concepts/accounts/reserves.md). Removing the signer list frees up the reserve.
|
||||
|
||||
The [MultiSignReserve amendment][] (enabled 2019-04-17) made it so each signer list counts as one item, regardless of how many members it has. As a result, the owner reserve for any signer list added or updated after this time is {% $env.PUBLIC_OWNER_RESERVE %}.
|
||||
{% amendment-disclaimer name="MultiSignReserve" compact=true /%} made it so each signer list counts as one item, regardless of how many members it has. As a result, the owner reserve for any signer list added or updated after this time is {% $env.PUBLIC_OWNER_RESERVE %}.
|
||||
|
||||
A signer list created before the [MultiSignReserve amendment][] itself counts as two items towards the owner reserve, and each member of the list counts as one. As a result, the total owner reserve associated with an old signer list is anywhere from 3 times to 10 times as much as a new signer list. To update a signer list to use the new, reduced reserve, update the signer list by sending a [SignerListSet transaction][].
|
||||
A signer list created before the MultiSignReserve amendment counts as two items towards the owner reserve, plus one for each member of the list. As a result, the total owner reserve associated with an old signer list is anywhere from 3 times to 10 times as much as a new signer list. To update a signer list to use the new, reduced reserve, update the signer list by sending a [SignerListSet transaction][].
|
||||
|
||||
|
||||
## SignerList ID Format
|
||||
|
||||
@@ -175,8 +175,6 @@ Version 1 MPTokens only support direct MPT payment between accounts. They cannot
|
||||
```
|
||||
## Credential IDs
|
||||
|
||||
{% amendment-disclaimer name="Credentials" /%}
|
||||
|
||||
You can send money to an account that uses [Deposit Authorization](../../../../concepts/accounts/depositauth.md) by providing the `CredentialIDs` field with an exact set of credentials that are preauthorized by the recipient. The set of credentials must match a [DepositPreauth entry](../../ledger-data/ledger-entry-types/depositpreauth.md) in the ledger.
|
||||
|
||||
The credentials provided in the `CredentialIDs` field must all be valid, meaning:
|
||||
@@ -192,6 +190,8 @@ If you provide credentials even though the destination account does not use Depo
|
||||
The `CredentialIDs` field is only used for deposit authorization, not for trading in a [permissioned DEX](../../../../concepts/tokens/decentralized-exchange/permissioned-dexes.md), even though Permissioned DEXes also use credentials to grant access. To trade in a permissioned DEX, you use the `DomainID` field to specify a domain for which you hold valid credentials.
|
||||
{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="Credentials" /%}
|
||||
|
||||
## Special Case for Destination Accounts Below the Reserve
|
||||
|
||||
If an account has Deposit Authorization enabled, but its current XRP balance is less than the [reserve requirement](../../../../concepts/accounts/reserves.md), there is a special exception to Deposit Authorization where anyone can send a Payment transaction, without preauthorization, for up to the base account reserve; this exists as an emergency measure to prevent an account from getting "stuck" without enough XRP to transact. To qualify for this special case, the payment MUST NOT use the `CredentialIDs` field.
|
||||
|
||||
@@ -1,23 +1,21 @@
|
||||
---
|
||||
parent: use-tokens.html
|
||||
seo:
|
||||
description: Set up an Automated Market Maker (AMM)
|
||||
embed_xrpl_js: true
|
||||
status: not_enabled
|
||||
filters:
|
||||
- interactive_steps
|
||||
labels:
|
||||
- Decentralized Exchange
|
||||
- Tokens
|
||||
- AMM
|
||||
- Decentralized Exchange
|
||||
- Tokens
|
||||
- AMM
|
||||
steps: ['Connect', 'Generate', 'Acquire tokens', 'Check for AMM', 'Look up AMMCreate cost', 'Create AMM', 'Check AMM info', 'Check trust lines']
|
||||
---
|
||||
# Create an Automated Market Maker
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
An [Automated Market Maker (AMM)](../../../concepts/tokens/decentralized-exchange/automated-market-makers.md) can be an efficient way to facilitate exchanges between two assets while earning its liquidity providers passive income. This tutorial shows how to create an AMM for a given asset pair.
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
<!-- Source for this specific tutorial's interactive bits: -->
|
||||
<script type="application/javascript" src="/js/interactive-tutorial.js"></script>
|
||||
<script type="application/javascript" src="/js/tutorials/create-amm.js"></script>
|
||||
|
||||
@@ -1,18 +1,16 @@
|
||||
---
|
||||
html: set-up-iou-iou-bridge.html
|
||||
parent: use-xrpl-sidechains.html
|
||||
seo:
|
||||
description: Steps to set up an IOU-IOU bridge.
|
||||
labels:
|
||||
- Interoperability
|
||||
- Interoperability
|
||||
---
|
||||
# Set Up an IOU-IOU Bridge
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
Setting up an IOU-IOU bridge enables you to move tokens between chains.
|
||||
|
||||
**Note**: The code samples on this page illustrate how to bridge a hypotethical "TST" token from *Devnet* to *Sidechain-Devnet*, using a supported [client library](/docs/references/client-libraries.md) to query and submit transactions.
|
||||
{% admonition type="info" name="Note" %}The code samples on this page illustrate how to bridge a hypotethical "TST" token from *Devnet* to *Sidechain-Devnet*, using a supported [client library](/docs/references/client-libraries.md) to query and submit transactions.{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
@@ -1,19 +1,16 @@
|
||||
---
|
||||
html: set-up-xrp-xrp-bridge.html
|
||||
parent: use-xrpl-sidechains.html
|
||||
seo:
|
||||
description: Steps to create an XRP-XRP bridge with a new sidechain.
|
||||
labels:
|
||||
- Interoperability
|
||||
- Interoperability
|
||||
---
|
||||
# Set Up an XRP-XRP Bridge
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
Setting up an XRP-XRP bridge enables you to move XRP between chains. The set up requires using the genesis account on the issuing chain as a door account to submit attestations and create transaction submission accounts for witnesses.
|
||||
|
||||
**Note**: The code samples on this page illustrate how a bridge was set up between *Devnet* and *Sidechain-Devnet*, using a supported [client library](/docs/references/client-libraries.md) to query and submit transactions. This bridge is already created, so the process can't be reproduced on these networks.
|
||||
{% admonition type="info" name="Note" %}The code samples on this page illustrate how a bridge was set up between *Devnet* and *Sidechain-Devnet*, using a supported [client library](/docs/references/client-libraries.md) to query and submit transactions. This bridge is already created, so the process can't be reproduced on these networks.{% /admonition %}
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
||||
@@ -1,17 +1,15 @@
|
||||
---
|
||||
html: submit-cross-chain-transactions.html
|
||||
parent: use-xrpl-sidechains.html
|
||||
seo:
|
||||
description: Steps to submit a cross-chain transaction, using a bridge.
|
||||
labels:
|
||||
- Interoperability
|
||||
- Interoperability
|
||||
---
|
||||
# Submit Cross-chain Transactions
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
This tutorial explains how to create a test account on a locking chain (_Devent_), and transfer XRP to an issuing chain (_Sidechain-Devnet_), using a supported [client library](../../../references/client-libraries.md) to query and submit transactions. Witness servers are already set up to monitor the XRP-XRP bridge and submit attestations.
|
||||
|
||||
{% amendment-disclaimer name="XChainBridge" /%}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- The locking and issuing chains are both up and running.
|
||||
|
||||
@@ -2,17 +2,17 @@
|
||||
seo:
|
||||
description: Issue an asset-backed token such as a US Treasury bill using multi-purpose tokens.
|
||||
labels:
|
||||
- Tokens
|
||||
- MPT
|
||||
- Tokens
|
||||
- MPT
|
||||
---
|
||||
# Sending MPTs
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
To send an MPT to another account, the receiving account must first authorize the receipt of the MPT, based on its MPToken Issuance ID. This is to prevent malicious users from spamming accounts with unwanted tokens that could negatively impact storage and XRP reserves.
|
||||
|
||||
Once an account receives an MPT, it can send the MPT to another account, provided the MPT was created with the _Can Transfer_ flag set, and the receiving account authorizes the MPT.
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
## Send MPT Utility
|
||||
|
||||
The Send MPT utility <!-- embedded below -->lets you create an account, authorize it to receive a specific MPT issuance, then send it the authorized MPT from an issuer or holder account. (You can issue an MPT using the [MPT Generator](../../../use-cases/tokenization/creating-an-asset-backed-multi-purpose-token.md) utility.)
|
||||
|
||||
@@ -2,13 +2,11 @@
|
||||
seo:
|
||||
description: Issue an asset-backed token such as a US Treasury bill using multi-purpose tokens.
|
||||
labels:
|
||||
- Tokens
|
||||
- MPT
|
||||
- Tokens
|
||||
- MPT
|
||||
---
|
||||
# Creating an Asset-backed Multi-purpose Token
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
_As a financial professional, I want to use multi-purpose tokens to create an asset-backed token in order to profit from resale transactions._
|
||||
|
||||
A multi-purpose token (MPT) is a compact and flexible object that offers the best aspects of fungible and non-fungible tokens. It is the next generation of tokenization on the XRPL. Notable features include:
|
||||
@@ -21,6 +19,8 @@ A multi-purpose token (MPT) is a compact and flexible object that offers the bes
|
||||
|
||||
To learn more, see [Multi-purpose Tokens](../../concepts/tokens/fungible-tokens/multi-purpose-tokens.md).
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
## MPT Generator
|
||||
|
||||

|
||||
|
||||
@@ -159,14 +159,14 @@ See [Enact Global Freeze](../../tutorials/how-tos/use-tokens/enact-global-freeze
|
||||
|
||||
### Clawback
|
||||
|
||||
{% amendment-disclaimer name="Clawback" /%}
|
||||
|
||||
Clawback is an optional setting that you can choose before you begin to distribute your stablecoin. For regulatory purposes, some issuers _must_ have the ability to recover issued tokens after they are distributed to accounts. For example, if an issuer were to discover that tokens were sent to an account sanctioned for illegal activity, the issuer could recover, or _claw back_, the funds.
|
||||
|
||||
See [Clawback](../../references/protocol/transactions/types/clawback.md).
|
||||
|
||||

|
||||
|
||||
{% amendment-disclaimer name="Clawback" /%}
|
||||
|
||||
### Partial Payments
|
||||
|
||||
Look out for partial payments. Payments with the partial payment flag enabled can be considered "successful" if any non-zero amount is delivered, even minuscule amounts.
|
||||
@@ -206,7 +206,6 @@ Decentralized exchanges (DEXes) are integral to the decentralized finance ecosys
|
||||
|
||||
|
||||
### List on an AMM
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
Automated Market Makers (AMMs) are smart contracts that provide liquidity in the XRP Ledger's decentralized exchange. Each AMM holds a pool of two assets and enables users to swap between them at an exchange rate set by a formula.
|
||||
|
||||
@@ -214,4 +213,6 @@ For any given pair of assets, there can be up to one AMM in the ledger. You can
|
||||
|
||||
See [Automated Market Makers](../../concepts/tokens/decentralized-exchange/automated-market-makers.md).
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
Reference in New Issue
Block a user