mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-05 04:15:50 +00:00
Move more amendment disclaimers to end of section
This commit is contained in:
mDuo13
@@ -78,8 +78,6 @@ Deposit Authorizationが有効化されているアカウントの特徴は次
|
||||
|
||||
## 事前承認
|
||||
|
||||
{% amendment-disclaimer name="DepositPreauth" /%}
|
||||
|
||||
DepositAuthが有効なアカウントは、特定の送金元を _事前承認_ することにより、DepositAuthが有効になっていても、これらの送金元からの支払を受領することができます。これにより、特定の送金元からの資金の直接送金が可能となり、受取人はトランザクションごとに個別にアクションを実行する必要がなくなります。事前承認はDepositAuthの使用にあたり必須の要件ではありませんが、事前承認により特定の操作を実行しやすくなります。
|
||||
|
||||
事前承認は通貨に依存しません。特定の通貨のみについてアカウントを事前承認することはできません。
|
||||
@@ -96,6 +94,8 @@ DepositPreauthトランザクションの処理が完了すると、承認済み
|
||||
|
||||
事前承認は、DepositAuthが有効なアカウントへのその他の送金方法には影響しません。詳しいルールについては、[詳細なセマンティクス](#詳細なセマンティクス)をご覧ください。
|
||||
|
||||
{% amendment-disclaimer name="DepositPreauth" /%}
|
||||
|
||||
### 承認の確認
|
||||
|
||||
[deposit_authorizedメソッド][]を使用して、特定のアカウントに対し別のアカウントへの入金が許可されているかどうかを確認できます。このメソッドは次の2点を確認します。
|
||||
|
||||
@@ -1,18 +1,16 @@
|
||||
---
|
||||
html: tickets.html
|
||||
parent: accounts.html
|
||||
seo:
|
||||
description: トランザクションを非連続的な順序で送信する
|
||||
labels:
|
||||
- アカウント
|
||||
- トランザクション送信
|
||||
- アカウント
|
||||
- トランザクション送信
|
||||
---
|
||||
# Ticket
|
||||
|
||||
{% amendment-disclaimer name="TicketBatch" /%}
|
||||
|
||||
XRP Ledgerのチケットは、取引をすぐに送信せずに、その取引のために[シーケンス番号][]を確保する方法です。チケットを使うことで、通常の順序以外で取引を送信することができます。この使用例としては、必要な署名を集めるのに時間がかかるような[マルチサイン取引](multi-signing.md)などが挙げられます。
|
||||
|
||||
{% amendment-disclaimer name="TicketBatch" /%}
|
||||
|
||||
## 背景
|
||||
|
||||
[トランザクション](../transactions/index.md)にはシーケンス番号が付いているので、任意のトランザクションを2回以上実行することはできません。シーケンス番号はまた、任意のトランザクションが一意であることを保証します。全く同じ金額を同じ人に複数回送信する場合、シーケンス番号は毎回異なることが保証される1つの詳細です。最後に、シーケンス番号は、ネットワーク全体に送信される際に一部のトランザクションが順不同で届いたとしても、トランザクションを一貫した順序で並べるためのエレガントな方法を提供します。
|
||||
|
||||
@@ -8,8 +8,6 @@ labels:
|
||||
---
|
||||
# 自動マーケットメーカー(AMM)とは?
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
自動マーケットメーカー(AMM)は、XRP Ledgerの分散型取引所において流動性を提供します。個々のAMMは2つの資産のプールを保有します。ユーザは数式で定められた取引レートによりその2つの資産間でスワップが可能です。
|
||||
|
||||
|
||||
@@ -24,6 +22,8 @@ labels:
|
||||
- AMMの手数料設定を変更するために投票する。票は、投票者が保有するLPトークンの数に基づいて重み付けされます。
|
||||
- AMMの取引手数料の一時的な割引を得るために、LPトークンの一部を入札する。
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
## AMMの仕組み
|
||||
|
||||
AMMは2つの異なる資産を保有します。そのうちの最大1つはXRPとすることができ、そのうちの1つまたは両方が[トークン](../index.md)であることができます。
|
||||
|
||||
@@ -62,8 +62,6 @@ labels:
|
||||
|
||||
## AMMの特殊なAccountRootエントリ
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
[自動マーケットメーカー](../../../../concepts/tokens/decentralized-exchange/automated-market-makers.md)(AMM)は、AMMの詳細の一部を追跡するための[AMMレジャーエントリ](amm.md)に加えて、LPトークンを発行しAMMプール内の資産を保持するためにAccountRootレジャーエントリを使用します。AMMに関連するAccountRootのアドレスは、AMMが作成される前にユーザがそのアドレスを特定し資金を提供できないように、ランダム化されています。AMMのAccountRootは、通常のアカウントとは異なり、以下のような設定で作成されます。
|
||||
|
||||
- `lsfDisableMaster` **有効** : トランザクションへ署名する手段はありません。これにより、誰もそのアカウントを直接操作することができず、トランザクションを送信することができなくなります。
|
||||
@@ -79,6 +77,8 @@ labels:
|
||||
|
||||
LPトークンは他の[トークン](../../../../concepts/tokens/index.md)と同様に動作しますが、これらのトークンはAMM関連のトランザクションでも使用することができます。AMMの残高や、AMMに影響を与えたトランザクションの履歴は、通常のアカウントと同じように確認することができます。
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
## AccountRootのフラグ
|
||||
|
||||
AccountRootフラグの多くは、[AccountSetトランザクション][]で変更できるオプションに対応しています。ただし、レジャーで使用されるビット値は、トランザクションでそれらのフラグを有効または無効にするために使用される値とは異なります。レジャーのフラグは **lsf`** で始まる名前を持ちます。
|
||||
|
||||
@@ -159,14 +159,14 @@ _No Freeze_ 設定を有効にしない場合、アカウントが疑わしい
|
||||
|
||||
### Clawback
|
||||
|
||||
_([Clawback amendment][])_
|
||||
|
||||
Clawbackは、ステーブルコインの配布を開始する前に選択できるオプション設定です。規制上の目的から、発行者の中には発行されたトークンをアカウントに配布した後に回収する能力を持たなければならない場合があります。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を回収することができます。
|
||||
|
||||
[Clawback](../../references/protocol/transactions/types/clawback.md)をご覧ください。
|
||||
|
||||
|
||||
|
||||
{% amendment-disclaimer name="Clawback" /%}
|
||||
|
||||
### 部分支払い
|
||||
|
||||
部分支払い(Partial Payment)に注意してください。partial paymentフラグが有効になっている支払いは、0でない金額が着金した場合、微々たる金額であっても"成功"とみなされます。
|
||||
@@ -206,7 +206,6 @@ Clawbackは、ステーブルコインの配布を開始する前に選択でき
|
||||
|
||||
|
||||
### AMMへのリスト
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
自動マーケットメイカー(AMM)は、XRP Ledgerの分散型取引所で流動性を提供するスマートコントラクトです。各AMMは2つの資産のプールを保有し、計算式で設定された取引レートでユーザがそれらの間でスワップを行うことを可能にします。
|
||||
|
||||
@@ -214,4 +213,6 @@ Clawbackは、ステーブルコインの配布を開始する前に選択でき
|
||||
|
||||
[自動マーケットメーカー](../../concepts/tokens/decentralized-exchange/automated-market-makers.md)をご覧ください。
|
||||
|
||||
{% amendment-disclaimer name="AMM" /%}
|
||||
|
||||
{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -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