mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 07:35:50 +00:00
Bulk update to concepts
This commit is contained in:
ddawson
@@ -1,112 +0,0 @@
|
||||
---
|
||||
html: authorized-trust-lines.html
|
||||
parent: tokens.html
|
||||
blurb: 通貨発行者が自己の発行済み通貨を保有できる人を制限できる、Authorized Trust Lineについて説明します。
|
||||
labels:
|
||||
- トークン
|
||||
- セキュリティ
|
||||
---
|
||||
# Authorized Trust Lines
|
||||
|
||||
XRP LedgerのAuthorized Trust Lines機能により、通貨イシュアーは自身の（XRP以外の）発行済み通貨を保有できるユーザーを制限できます。これにより、不明なXRP Ledgerアドレスは発行済み通貨を保有できなくなります。Authorized Trust Lines機能は発行済み通貨にのみ適用され、XRPには影響しません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、発行アドレスでRequireAuthフラグを有効にします。その後、発行アドレスは他のアドレスからのトラストラインを承認する[TrustSetトランザクション][]を送信できます。RequireAuthが有効であるときに発行アドレスから発行された資金を他のアドレスが保有できるのは、発行アドレスへのトラストラインが承認されている場合だけです。
|
||||
|
||||
トラストラインを承認するトランザクションには発行アドレスによる署名が必要ですが、これにより発行アドレスが危険にさらされる可能性が高くなります。RequireAuthが有効であるXRP Ledgerへの資金の送金プロセスは次のようになります。
|
||||
|
||||
1. 発行ゲートウェイがその発行アドレスを顧客に公開します。
|
||||
2. 顧客のXRP Ledgerアドレスからゲートウェイの発行アドレスへのトラストラインを作成するために顧客は[TrustSetトランザクション][]を送信します。これは、ゲートウェイが発行した特定通貨を特定の限度額まで保有することを顧客が望んでいることを意味します。
|
||||
3. ゲートウェイの発行アドレスは、顧客のトラストラインを承認するTrustSetトランザクションを送信します。
|
||||
|
||||
**ヒント:** 発行ゲートウェイは、顧客がトラストラインの作成を完了する前に、そのトラストラインを事前に承認できます（ステップ3）。これにより限度額がゼロのトラストラインが作成されます。顧客のTrustSetトランザクション（ステップ2）により、事前承認されたトラストラインに限度額が設定されます。_（[TrustSetAuth Amendment][]が必要です。）_
|
||||
|
||||
## RequireAuth設定
|
||||
|
||||
`RequireAuth`設定をすることで、発行アドレスが当該通貨に関してその取引相手とのトラストラインを具体的に承認している場合を除き、すべての取引相手はアドレスから発行された残高を保有できなくなります。
|
||||
|
||||
用心として、発行ゲートウェイが[運用アドレスとスタンバイアドレス](issuing-and-operational-addresses.html)に対して`RequireAuth`を常に有効にし、これらのアドレスへのトラストラインを一切承認しないことが推奨されます。これにより、運用アドレスとスタンバイアドレスがXRP Ledgerで誤って通貨を発行することを防止できます。これは純粋な予防措置であり、発行アドレスにより作成された発行済み通貨の残高を、これらのアドレスが意図したとおりに送金することを阻止するものではありません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、イシュアーがその発行アドレスの`RequireAuth`も有効にする必要もあります。その後、発行アドレスは顧客からの[各トラストラインを承認する`TrustSet`トランザクションを送信する](#トラストラインの承認)必要があります。
|
||||
|
||||
**注意:** アカウントが`RequireAuth`を有効にできるのは、アカウントがトラストラインを所有しておらず、またXRP Ledgerにオファーがない場合に限られます。したがってXRP Ledgerで取引を開始する前に、この設定を使用するかどうかを決定しておく必要があります。
|
||||
|
||||
### RequireAuthの有効化
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、RequireAuthフラグを有効にする[AccountSetトランザクション][]を送信する例を以下に示します。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
|
||||
要求:
|
||||
|
||||
```json
|
||||
POST http://localhost:5005/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"Fee": "15000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 2,
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## アカウントのRequireAuthの有効化の確認
|
||||
|
||||
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
|
||||
`Flags`値と`lsfRequireAuth`フラグ値（0x00040000）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
|
||||
|
||||
## トラストラインの承認
|
||||
|
||||
Authorized Trust Lines機能を使用している場合、他のアカウントからのトラストラインを最初に承認しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数の通貨を発行する場合には、各通貨のトラストラインを個別に承認する必要があります。
|
||||
|
||||
トラストラインを承認するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn）が発行アドレス（rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW）からのUSDのイシュアンスを保有することを承認するTrustSetトランザクションを送信する例を以下に示します。
|
||||
|
||||
要求:
|
||||
|
||||
```json
|
||||
POST http://localhost:8088/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"Fee": "15000",
|
||||
"TransactionType": "TrustSet",
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": 0
|
||||
},
|
||||
"Flags": 65536
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## トラストラインの承認状況の確認
|
||||
|
||||
トラストラインの承認状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。要求の`account`フィールドに顧客のアドレスを指定し、`peer`フィールドにイシュアーのアドレスを指定します。
|
||||
|
||||
応答の`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、イシュアー（要求の`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,18 +1,10 @@
|
||||
---
|
||||
html: authorized-trust-lines.html
|
||||
parent: tokens.html
|
||||
blurb: Authorized trust lines is a setting to limit who can hold a token.
|
||||
labels:
|
||||
- Tokens
|
||||
- Security
|
||||
---
|
||||
# Authorized Trust Lines
|
||||
|
||||
The Authorized Trust Lines feature enables issuers to create tokens that can only be held by accounts that the issuer specifically authorizes. This feature only applies to tokens, not XRP.
|
||||
|
||||
To use the Authorized Trust Lines feature, enable the `RequireAuth` flag on your issuing account. While the setting is enabled, other accounts can only hold tokens you issue if you have authorized those accounts' trust lines to your issuing account.
|
||||
|
||||
You can authorize a trust line by sending a [TrustSet transaction][] from your issuing address, configuring the trust line between your account and the account to authorize. After you have authorized a trust line, you can never revoke that authorization. (You can, however, [freeze](freezes.html) that trust line if you need to.)
|
||||
You can authorize a trust line by sending a `TrustSet` transaction from your issuing address, configuring the trust line between your account and the account to authorize. After you have authorized a trust line, you can never revoke that authorization. (You can, however, [freeze](freezing-tokens.md) that trust line if you need to.)
|
||||
|
||||
The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address.
|
||||
|
||||
@@ -24,14 +16,14 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process
|
||||
|
||||
1. The customer registers with the stablecoin issuer's systems and sends proof of their identity (also known as "Know Your Customer", or KYC, information).
|
||||
2. The customer and stablecoin issuer tell each other their XRP Ledger addresses.
|
||||
3. The customer sends a [TrustSet transaction][] to create a trust line to the issuer's address, with a positive limit.
|
||||
4. The issuer sends a TrustSet transaction to authorize the customer's trust line.
|
||||
3. The customer sends a `TrustSet` transaction to create a trust line to the issuer's address, with a positive limit.
|
||||
4. The issuer sends a `TrustSet` transaction to authorize the customer's trust line.
|
||||
|
||||
**Tip:** The issuer can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_
|
||||
**Tip:** The issuer can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the TrustSetAuth amendment.)_
|
||||
|
||||
## As a Precaution
|
||||
|
||||
Even if you don't intend to use Authorized Trust Lines, you can enable the `RequireAuth` setting on [operational and standby accounts](issuing-and-operational-addresses.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
|
||||
Even if you don't intend to use Authorized Trust Lines, you can enable the `RequireAuth` setting on [operational and standby accounts](../accounts/account-types.md), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
|
||||
|
||||
|
||||
## Technical Details
|
||||
@@ -39,7 +31,7 @@ Even if you don't intend to use Authorized Trust Lines, you can enable the `Requ
|
||||
|
||||
### Enabling RequireAuth
|
||||
|
||||
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the `RequireAuth` flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
|
||||
The following is an example of using a locally-hosted `rippled`'s `submit method` to send an `AccountSet` transaction to enable the `RequireAuth` flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
|
||||
|
||||
Request:
|
||||
|
||||
@@ -61,13 +53,13 @@ POST http://localhost:5005/
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## Checking Whether an Account Has RequireAuth Enabled
|
||||
|
||||
To see whether an account has the `RequireAuth` setting enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](accountroot.html).
|
||||
To see whether an account has the `RequireAuth` setting enabled, use the `account_info` method to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the bitwise flags defined for an `AccountRoot` ledger object.
|
||||
|
||||
If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (`0x00040000`) is nonzero, then the account has `RequireAuth` enabled. If the result is zero, then the account has `RequireAuth` disabled.
|
||||
|
||||
@@ -75,9 +67,9 @@ If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (
|
||||
|
||||
If you are using the Authorized Trust Lines feature, others cannot hold balances you issue unless you first authorize their trust lines to you. If you issue more than one currency, you must separately authorize trust lines for each currency.
|
||||
|
||||
To authorize a trust line, submit a [TrustSet transaction][] from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [`tfSetfAuth`](trustset.html#trustset-flags) flag for the transaction.
|
||||
To authorize a trust line, submit a `TrustSet` transaction from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as *0*, and enable the `tfSetfAuth` flag for the transaction.
|
||||
|
||||
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a TrustSet transaction authorizing the customer address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` to hold USD issued by the address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`:
|
||||
The following is an example of using a locally-hosted `rippled`'s `submit` method to send a TrustSet transaction authorizing the customer address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` to hold USD issued by the address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`:
|
||||
|
||||
Request:
|
||||
|
||||
@@ -104,17 +96,17 @@ POST http://localhost:8088/
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!--
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## Checking Whether Trust Lines Are Authorized
|
||||
|
||||
To see whether a trust line has been authorized, use the [account_lines method][] to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
|
||||
To see whether a trust line has been authorized, use the `account_lines` method to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
|
||||
|
||||
In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.
|
||||
|
||||
|
||||
<!--
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
@@ -129,8 +121,4 @@ In the response's `result.lines` array, find the object whose `currency` field i
|
||||
- [TrustSet transaction][]
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
-->
|
||||
@@ -1,32 +0,0 @@
|
||||
---
|
||||
parent: freezes.html
|
||||
blurb: Clarify common misunderstandings about the XRP Ledger's freeze feature.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Common Misunderstandings about Freezes
|
||||
|
||||
It is a common misconception that Ripple or others can freeze XRP, similar to how centralized services like PayPal can suspend your account and prevent you from accessing your funds. In reality, while the XRP Ledger does have a [freeze feature](freezes.html), it can only be used on issued tokens, not on XRP. **No one can freeze XRP.**
|
||||
|
||||
Tokens in the XRP Ledger are [fundamentally different than XRP](currency-formats.html#comparison). Tokens always exist _in trust lines_, which _can_ be frozen. XRP exists in accounts, which _cannot_ be frozen.
|
||||
|
||||
## Isn't XRP Just Ripple's Token?
|
||||
|
||||
No, XRP is different from tokens. XRP is the only native asset on the XRP Ledger and is required to conduct transactions on the XRP Ledger. XRP has no counterparty, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**<u>XRP CANNOT be frozen by any entity or individual</u>**_.
|
||||
|
||||
## Can Ripple Freeze My Tokens? Or the XRP Ledger Foundation?
|
||||
|
||||
The XRP Ledger is decentralized so that no one party has control over it—not Ripple, not the XRP Ledger Foundation, and not anyone else.
|
||||
|
||||
The _issuer_ of a token can freeze your trust line for _that token specifically_. They can't freeze the rest of your account, or any tokens from different issuers, and they can't stop you from using the XRP Ledger.
|
||||
|
||||
Furthermore, token issuers can voluntarily and permanently _give up_ their ability to freeze tokens. This ["No Freeze"](freezes.html#no-freeze) setting is intended to allow tokens to behave more like physical cash, in that third parties can't stop you from using it.
|
||||
|
||||
|
||||
## But I Heard Ripple Froze Jed McCaleb's XRP?
|
||||
|
||||
This is a misrepresentation of events that actually happened in 2015–2016. Jed McCaleb, a Ripple founder who left the company in 2013, attempted to sell over $1 million US worth of XRP on Bitstamp, a custodial exchange. Ripple representatives argued that this sale would breach an agreement that Jed and Ripple made in 2014. At Ripple's request, [Bitstamp froze Jed's Bitstamp account](https://www.coindesk.com/markets/2015/04/02/1-million-legal-fight-ensnares-ripple-bitstamp-and-jed-mccaleb/) and took the dispute to court. The case was [eventually settled](https://www.coindesk.com/markets/2016/02/12/ripple-settles-1-million-lawsuit-with-former-executive-and-founder/) with both sides declaring they were happy with the outcome.
|
||||
|
||||
Notably, the "freeze" did not happen on the XRP Ledger and did not involve the XRP Ledger's freeze feature. Like any custodial exchange, Bitstamp has the ability to freeze its users' accounts and stop them from trading or withdrawing funds, especially if those funds are involved in a legal dispute.
|
||||
|
||||
In contrast, when trading in the XRP Ledger's [decentralized exchange](decentralized-exchange.html), you custody your own assets so no one can stop you from dealing in XRP.
|
||||
@@ -1,126 +0,0 @@
|
||||
---
|
||||
html: demurrage.html
|
||||
parent: tokens.html
|
||||
blurb: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
|
||||
status: removed
|
||||
---
|
||||
# デマレージ
|
||||
|
||||
**注意:** デマレージは非推奨の機能であり、継続的なサポートはありません。このページでは、旧バージョンのXRP Ledgerソフトウェアの過去の動作について説明します。
|
||||
|
||||
[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](currency-formats.html#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
|
||||
|
||||
## 通貨量の表記について
|
||||
|
||||
XRP Ledgerのすべての金額を継続的に更新するのではなく、有利子通貨や減耗通貨の金額を2種類の金額に分割する方法です。XRP Ledgerに記録される「レジャー値」と、人に見せる「表示値」の2種類に分けます。「レジャー値」は、ある一定時点、すなわち2000年1月1日午前0時の「リップルエポック」での通貨の価値を表しています。「表示値」は、リップルエポックからその時点までの連続した利息やデマレージを計算した後の時点（通常は現在時刻）での金額を表しています。
|
||||
|
||||
**ヒント:** デマレージはインフレに似ていると考えることができます。インフレの影響を受けたすべての資産の価値は時間とともに減少しますが、レジャーには常に2000年の値で金額が記録されます。これは実際のインフレを反映しているわけではなく、デマレージはむしろ一定の割合での仮想的なインフレのようなものです。
|
||||
|
||||
したがって、クライアントソフトウェアは2つの変換を適用する必要があります。
|
||||
|
||||
- ある時点の表示値を取り込み、レジャー値に変換して記録すること。
|
||||
- レジャー値を、ある時点の表示値に変換すること。
|
||||
|
||||
### デマレージの計算
|
||||
|
||||
通貨に関するデマレージの完全な計算式は以下の通りです。
|
||||
|
||||
```
|
||||
D = A × ( e ^ (t ÷ τ) )
|
||||
```
|
||||
|
||||
- **D** はデマレージ後の金額
|
||||
- **A** はグローバルレジャーに記録されたデマレージ前金額です。
|
||||
- **e** はオイラー数
|
||||
- **t** はリップルエポック（UTC2000年1月1日0時）からの経過秒数
|
||||
- **τ** は、e倍加時間の時間（秒）です。この値は［希望する金利から計算］（#e倍加時間の計算）されます。 <!-- SPELLING_IGNORE: τ -->
|
||||
|
||||
表示金額とレジャー金額の変換は、以下の手順で行います。
|
||||
|
||||
1. `( e ^ (t ÷ τ) )`の値を計算する。この数値を「デマレージ係数」と呼ぶ。デマレージ係数は常に現在時刻など特定の時刻からの相対値である。
|
||||
2. 変換する量に適用します。
|
||||
- レジャー値を表示値に変換する場合は、デマレージ係数を乗じる。
|
||||
- 表示値をレジャー値に変換する場合は、デマレージ係数で割ってください。
|
||||
3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](currency-formats.html#発行済み通貨の精度)により、レジャー値の精度は小数点以下15桁までとされています。.
|
||||
|
||||
|
||||
## 利子付き通貨コードフォーマット
|
||||
|
||||
[標準通貨コード形式](currency-formats.html#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
|
||||
|
||||
|
||||
|
||||
1. 最初の8ビットは `0x01` でなければなりません。
|
||||
2. 次の24ビットはASCIIの3文字を表します。
|
||||
これはISO 4217のコードと予想されます。標準フォーマットのASCII文字と同じ文字をサポートしています。
|
||||
3. 次の24ビットはすべて「0」でなければなりません。
|
||||
4. 次の64ビットは通貨の金利で、IEEE754ダブルフォーマットで「[e-folding time](http://en.wikipedia.org/wiki/E-folding)」と表現される。
|
||||
5. 次の24ビットは予約されており，すべて`0`でなければなりません
|
||||
|
||||
### e倍加時間の計算
|
||||
|
||||
レジャー金額と表示金額の変換や、有利子/不利子通貨の通貨コードの計算には、「e倍加時間」としての金利が必要です。e倍加時間とは、ある数量が_e_（オイラー数）の倍数だけ増加するのにかかる時間のことである。慣例として、e倍加時間は数式では**τ**という文字で表記される。
|
||||
|
||||
ある年率パーセントの利息に対するe倍加時間の時間を計算すること。
|
||||
|
||||
1. 100%に金利を足すと、年利を適用した後の初期金額に対する割合が算出されます。デマレージには、マイナスの金利を使用します。例えば、0.5%のデマレージは-0.5%の金利となり、**99.5%**の残存率となります。
|
||||
2. パーセンテージを小数で表します。例えば、99.5%は**0.995**となります。
|
||||
3. その数値の自然対数をとります。例えば、**ln(0.995) = -0.005012541823544286** となります。(この数値は、当初の金利がプラスであればプラス、マイナスであればマイナスになります)。
|
||||
4. 1年間の秒数（31536000）を、前のステップの自然対数の結果で割ってください。例えば、**31536000 ÷ -0.005012541823544286 = -6291418827.045599** となります。この結果が、e倍加時間（秒）です。
|
||||
|
||||
**注記:** XRP Ledgerの利息・デマレージルールでは、慣習上、1年あたりの固定秒数（31536000）が使用されており、閏日や閏秒の調整は行われていません。
|
||||
|
||||
## クライアントサポート
|
||||
|
||||
利息通貨とデマレージ通貨をサポートするために、クライアントアプリケーションはいくつかの機能を実装する必要があります。
|
||||
|
||||
- レジャーやトランザクションデータから取得した通貨を減耗して表示する場合、クライアント側でレジャー値から表示値への変換が必要です。(デマレージでは、表示値はレジャー値より小さくなる)。
|
||||
|
||||
- デマレージ通貨の入力を受け付ける場合、クライアントは金額を表示形式からレジャー形式に変換する必要があります。(デマレッジの場合、ユーザー入力値よりレジャー値の方が大きい)。クライアントは、支払い、オファー、その他のトランザクションを作成する際に、レジャーの値を使用しなければなりません。
|
||||
|
||||
- クライアントは、金利やデマレージが発生する通貨と発生しない通貨、および金利やデマレージの利率が異なる通貨を区別する必要があります。クライアントは、[利子付き通貨コードフォーマット](#利子付き通貨コードフォーマット)を解析して、「XAU (-0.5% pa)」などの表示にできるようにしなければなりません。
|
||||
|
||||
### ripple-lib サポート
|
||||
|
||||
デマレージは ripple-lib のバージョン **0.7.37** から **0.12.9** まででサポートされていました。デマレージは、最近のほとんどのライブラリでは***サポートされていません***。
|
||||
|
||||
以下のコードサンプルは、互換性のあるバージョンのripple-libを使用して、レジャー値と表示値の変換を行う方法を示しています。また、[Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/)も参照してください。
|
||||
|
||||
表示値からレジャー値に変換するには、`Amount.from_human()`を使用する。
|
||||
|
||||
```js
|
||||
// デマレージ通貨の表示金額を表す Amount オブジェクトを作成し、
|
||||
// 現在の日付を表すreference_dateを渡します。
|
||||
// (この場合、2017-11-04T00:07:50Zに、年0.5%の脱税で台帳値10 XAU。)。
|
||||
var demAmount = ripple.Amount.from_human('10 0158415500000000C1F76FF6ECB0BAC600000000',
|
||||
{reference_date:563069270});
|
||||
|
||||
// 発行者を設定します
|
||||
demAmount.set_issuer("rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh");
|
||||
|
||||
// get the JSON format for the ledger amount
|
||||
console.log(demAmount.to_json());
|
||||
|
||||
// { "value": "10.93625123082769",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
|
||||
レジャー値から表示値へ変換する場合、
|
||||
|
||||
```js
|
||||
// レジャー値を持つ Amount オブジェクトを作成します。
|
||||
ledgerAmount = ripple.Amount.from_json({
|
||||
"currency": "015841551A748AD2C1F76FF6ECB0CCCD00000000",
|
||||
"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"value": "10.93625123082769"})
|
||||
|
||||
// 表示金額を得るために現在時刻までの利息を適用する
|
||||
var displayAmount = demAmount.applyInterest(new Date());
|
||||
|
||||
console.log(displayAmount.to_json());
|
||||
|
||||
// { "value": "9.999998874657716",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
@@ -1,127 +0,0 @@
|
||||
---
|
||||
html: demurrage.html
|
||||
parent: tokens.html
|
||||
blurb: (Obsolete) Some older XRP Ledger tools used to support currency codes with built-in interest and negative interest rates.
|
||||
status: removed
|
||||
---
|
||||
# Demurrage
|
||||
|
||||
**Warning:** Demurrage is a deprecated feature with no ongoing support. This page describes historical behavior of older versions of XRP Ledger software.
|
||||
|
||||
[Demurrage](http://en.wikipedia.org/wiki/Demurrage_%28currency%29) is a negative interest rate on assets held that represents the cost of holding those assets. To represent the demurrage on a token in the XRP Ledger, you can track it using a custom [currency code](currency-formats.html#currency-codes) that indicates the demurrage rate. This effectively creates separate versions of the token for each varying amount of demurrage. Client applications can support this by representing the demurraging currency code with an annual percentage rate alongside the currency code. For example: "XAU (-0.5%pa)".
|
||||
|
||||
## Representing Demurraging Token Amounts
|
||||
|
||||
Rather than continuously update all amounts in the XRP Ledger, this approach divides amounts of interest-bearing or demurraging tokens into two types of amount: "ledger values" recorded in the XRP Ledger, and "display values" shown to people. The "ledger values" represent the value of the currency at a fixed point, namely the "Ripple Epoch" of midnight January 1, 2000. The "display values" represent the amount at a later point in time (usually the current time) after calculating continuous interest or demurrage from the Ripple Epoch until that time.
|
||||
|
||||
**Tip:** You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not reflect actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate.
|
||||
|
||||
Thus, client software must apply two conversions:
|
||||
|
||||
- Taking display values at a given time and converting them to ledger values to be recorded.
|
||||
- Taking ledger values and converting them to a display value at a given point in time.
|
||||
|
||||
### Calculating Demurrage
|
||||
|
||||
The full formula for calculating demurrage is as follows:
|
||||
|
||||
```
|
||||
D = A × ( e ^ (t ÷ τ) )
|
||||
```
|
||||
|
||||
- **D** is the amount after demurrage
|
||||
- **A** is the pre-demurrage amount as recorded in the global ledger
|
||||
- **e** is Euler's number
|
||||
- **t** is the number of seconds since the Ripple Epoch (0:00 on January 1, 2000 UTC)
|
||||
- **τ** is the e-folding time in seconds. This value is [calculated from the desired interest rate](#calculating-e-folding-time). <!-- SPELLING_IGNORE: τ -->
|
||||
|
||||
To convert between display amounts and ledger amounts, you can use the following steps:
|
||||
|
||||
1. Calculate the value of `( e ^ (t ÷ τ) )`. We call this number the "demurrage coefficient". The demurrage coefficient is always relative to a specific time, such as the current time.
|
||||
2. Apply it to the amount to convert:
|
||||
- To convert ledger values to display values, multiply by the demurrage coefficient.
|
||||
- To convert display values to ledger values, divide by the demurrage coefficient.
|
||||
3. If necessary, adjust the resulting value so that it can be represented to the desired accuracy. Ledger values are limited to 15 decimal digits of precision, according to the XRP Ledger's [token format](currency-formats.html#token-precision).
|
||||
|
||||
|
||||
## Interest-Bearing Currency Code Format
|
||||
|
||||
Rather than using the [standard currency code format](currency-formats.html#currency-codes), tokens that have positive interest or negative interest (demurrage) use a 160-bit currency code in the following format:
|
||||
|
||||
|
||||
|
||||
1. The first 8 bits must be `0x01`.
|
||||
2. The next 24 bits represent 3 characters of ASCII.
|
||||
This is expected to be an ISO 4217 code. It supports the same characters as the standard format's ASCII characters.
|
||||
3. The next 24 bits MUST be all `0`s.
|
||||
4. The next 64 bits are the interest rate of the currency, represented as "[e-folding time](http://en.wikipedia.org/wiki/E-folding)" in an IEEE 754 double format.
|
||||
5. The next 24 bits are reserved and should be all `0`s.
|
||||
|
||||
### Calculating e-folding Time
|
||||
|
||||
To convert between ledger amounts and display amounts, or to calculate a currency code for an interest-bearing/demurraging currency, you need the interest rate as an "e-folding time". The e-folding time is the amount of time it takes a quantity to increase by a factor of _e_ (Euler's number). By convention, e-folding time is written as the letter **τ** in formulas.
|
||||
|
||||
To calculate an e-folding time for a given rate of annual percent interest:
|
||||
|
||||
1. Add the interest rate to 100% to get the percentage of the initial amount present after applying annual interest. For demurrage, use a negative interest rate. For example, 0.5% demurrage would be an interest rate of -0.5%, resulting in **99.5%** remaining.
|
||||
2. Represent the percentage as a decimal. For example, 99.5% becomes **0.995**.
|
||||
3. Take the natural log of that number. For example, **ln(0.995) = -0.005012541823544286**. (This number is positive if the initial interest rate was positive, and negative if the interest rate was negative.)
|
||||
4. Take the number of seconds in one year (31536000) and divide by the natural log result from the previous step. For example, **31536000 ÷ -0.005012541823544286 = -6291418827.045599**. This result is the e-folding time in seconds.
|
||||
|
||||
**Note:** By convention, the XRP Ledger's interest/demurrage rules use a fixed number of seconds per year (31536000), which is not adjusted for leap days or leap seconds.
|
||||
|
||||
## Client Support
|
||||
|
||||
To support interest-bearing and demurraging tokens, client applications must implement several features:
|
||||
|
||||
- When displaying the amount of a demurraging token retrieved from ledger or transaction data, the client must convert from the ledger value to the display value. (With demurrage, the display values are smaller than the ledger values.)
|
||||
|
||||
- When accepting input for a demurraging token, the client must convert amounts from a display format to the ledger format. (With demurrage, the ledger values are larger than the user input value.) The client must use the ledger value when creating payments, offers, and other types of transaction.
|
||||
|
||||
- Clients must distinguish between tokens that do and do not have interest or demurrage, and among tokens that have different rates of interest or demurrage. Clients should be able to parse the [Interest-Bearing Currency Code Format](#interest-bearing-currency-code-format) into a display such as "XAU (-0.5% pa)".
|
||||
|
||||
### ripple-lib Support
|
||||
|
||||
Demurrage was supported in ripple-lib versions **0.7.37** through **0.12.9**. Demurrage is ***not supported*** in most modern libraries.
|
||||
|
||||
The following code samples demonstrate how to use compatible versions of ripple-lib to convert between ledger values and display values. Also see the [Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/).
|
||||
|
||||
To convert from a display value to a ledger value, use `Amount.from_human()`:
|
||||
|
||||
```js
|
||||
// create an Amount object for the display amount of the demurring currency
|
||||
// and pass in a reference_date that represents the current date
|
||||
// (in this case, ledger value 10 XAU with 0.5% annual demurrage,
|
||||
// at 2017-11-04T00:07:50Z.)
|
||||
var demAmount = ripple.Amount.from_human('10 0158415500000000C1F76FF6ECB0BAC600000000',
|
||||
{reference_date:563069270});
|
||||
|
||||
// set the issuer
|
||||
demAmount.set_issuer("rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh");
|
||||
|
||||
// get the JSON format for the ledger amount
|
||||
console.log(demAmount.to_json());
|
||||
|
||||
// { "value": "10.93625123082769",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
|
||||
To convert from a ledger value to a display value:
|
||||
|
||||
```js
|
||||
// create an Amount object with the ledger value,
|
||||
ledgerAmount = ripple.Amount.from_json({
|
||||
"currency": "015841551A748AD2C1F76FF6ECB0CCCD00000000",
|
||||
"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"value": "10.93625123082769"})
|
||||
|
||||
// apply interest up to the current time to get the display amount
|
||||
var displayAmount = demAmount.applyInterest(new Date());
|
||||
|
||||
console.log(displayAmount.to_json());
|
||||
|
||||
// { "value": "9.999998874657716",
|
||||
// "currency": "0158415500000000C1F76FF6ECB0BAC600000000",
|
||||
// "issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh" }
|
||||
```
|
||||
@@ -1,97 +0,0 @@
|
||||
---
|
||||
html: freezes.html
|
||||
parent: tokens.html
|
||||
blurb: 凍結では、コンプライアンス目的で発行済み通貨の取引を停止できます。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 発行済み通貨の凍結
|
||||
|
||||
XRPは発行済み通貨ではありません。XRPはXRP Ledgerのネイティブ資産であり、XRP Ledgerでのトランザクションの実行に必要となります。XRPは取引相手を必要としません。つまり、XRPを保有しているということは負債ではなく実際の通貨であるXRPを保有していることになります。このため、_**<u>いかなる組織または個人もXRPを凍結できません</u>**_。
|
||||
|
||||
XRP Ledgerでは、XRP以外の通貨はすべて発行済み通貨として表すことができます。このような発行済み通貨（「イシュアンス」または「IOU」とも呼ばれます）は、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスも（XRP以外の）通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
|
||||
|
||||
特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外の発行済み通貨の残高を急きょ凍結することがあります。
|
||||
|
||||
**ヒント:** 誰もXRPを凍結することはできません。
|
||||
|
||||
凍結については、3種類の設定があります。
|
||||
|
||||
* [**Individual Freeze**](#individual-freeze) - 1件の取引相手を凍結します。
|
||||
* [**Global Freeze**](#global-freeze) - 取引相手全員を凍結します。
|
||||
* [**No Freeze**](#no-freeze) - 個々の取引相手の凍結機能と、Global Freezeを終了できる機能を永久に放棄します。
|
||||
|
||||
凍結機能は発行済み通貨にのみ適用されます。XRP Ledgerには特権的な立場の当事者は存在しないため、凍結機能では、取引相手が、XRPまたはその他の取引相手が発行した資金で取引を実行することを阻止できません。Rippleを含め誰もXRPを凍結することはできません。
|
||||
|
||||
凍結対象の残高がプラス、マイナスにかかわらず、すべての凍結設定を行うことができます。通貨イシュアーまたは通貨保持者のいずれかがトラストラインを凍結できますが、通貨保持者がイシュアーを凍結しても、その影響はわずかです。
|
||||
|
||||
|
||||
## Individual Freeze
|
||||
|
||||
**Individual Freeze**機能は、[トラストライン](trust-lines-and-issuing.html)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
|
||||
|
||||
* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
|
||||
* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
|
||||
* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
|
||||
* 取引相手が凍結されたトラストライン上の発行済み通貨の売りオファーを出した場合、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: トラストラインではXRPは保持されません。XRPは凍結できません。
|
||||
|
||||
金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
|
||||
|
||||
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](issuing-and-operational-addresses.html)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
|
||||
|
||||
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
|
||||
|
||||
[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
|
||||
|
||||
|
||||
## Global Freeze
|
||||
|
||||
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべての発行済み通貨に対して以下のルールが適用されます:
|
||||
|
||||
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](issuing-and-operational-addresses.html)にも影響します。）
|
||||
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
|
||||
* 凍結アドレスによる発行済み通貨の売りオファーはすべて、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
|
||||
|
||||
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](issuing-and-operational-addresses.html)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
|
||||
|
||||
また、金融機関が新しい[発行アドレス](issuing-and-operational-addresses.html)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザーは他の通貨で取引することができなくなります。
|
||||
|
||||
Global Freezeは、当該アドレスによって発行および保有されている _すべての_ 通貨に適用されます。1つの通貨のみに対してGlobal Freezeを有効にすることはできません。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
アドレスのGlobal Freeze設定はいつでも有効にできます。ただし、アドレスの[No Freeze](#no-freeze)設定を有効にすると、Global Freezeを _無効にする_ ことはできません。
|
||||
|
||||
|
||||
## No Freeze
|
||||
|
||||
**No Freeze**機能をアドレスに設定すると、取引相手が発行した通貨を凍結する機能を永久に放棄します。この機能を使用すれば、企業は自社が発行した資金を「物理的なお金のように」扱うことができます。これにより、企業は顧客どうしがその資金を取引することに介入できなくなります。
|
||||
|
||||
確認事項: XRPはすでに凍結できません。No Freeze機能は、XRP Ledgerで発行された他の通貨にのみ適用されます。
|
||||
|
||||
No Freeze設定には次の2つの効果があります。
|
||||
|
||||
* 発行アドレスは、すべての取引相手とのトラストラインに対してIndividual Freezeを有効にできなくなります。
|
||||
* 発行アドレスは、Global Freezeを有効にしてグローバル凍結を施行できますが、Global Freezeを _無効にする_ ことはできません。
|
||||
|
||||
XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行することを強制できません。このため、Global Freezeを有効にする機能を放棄しても顧客を保護できません。ただし、Global Freezeを _無効にする_ 機能を放棄することで、Global Freeze機能が一部の顧客に対して不当に適用されないようにすることができます。
|
||||
|
||||
No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチ署名済みトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
|
||||
|
||||
|
||||
<!--{# TODO: update "See Also" with new tutorials' technical details #}-->
|
||||
|
||||
|
||||
# 関連項目
|
||||
|
||||
* [GB-2014-02新機能残高凍結](https://ripple.com/files/GB-2014-02.pdf)
|
||||
* [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,104 +0,0 @@
|
||||
---
|
||||
html: freezes.html
|
||||
parent: tokens.html
|
||||
blurb: Issuers can freeze their issued tokens for compliance purposes.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Freezing Tokens
|
||||
|
||||
Issuers can freeze the tokens they issue in the XRP Ledger. **This does not apply to XRP,** which is the native asset of the XRP Ledger, not an issued token.
|
||||
|
||||
In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway may want to freeze token balances.
|
||||
|
||||
**Tip:** No one can freeze XRP in the XRP Ledger. However, custodial exchanges can always freeze the funds they custody at their own discretion. For more details, see [Common Misunderstandings about Freezes](common-misconceptions-about-freezes.html).
|
||||
|
||||
There are three settings related to freezes:
|
||||
|
||||
* [**Individual Freeze**](#individual-freeze) - Freeze one counterparty.
|
||||
* [**Global Freeze**](#global-freeze) - Freeze all counterparties.
|
||||
* [**No Freeze**](#no-freeze) - Permanently give up the ability to freeze individual counterparties, as well as the ability to end a global freeze.
|
||||
|
||||
All freeze settings can be enacted regardless of whether the balance(s) to be frozen are positive or negative. Either the token issuer or the currency holder can freeze a trust line; however, the effect is minimal when a currency holder enacts a freeze.
|
||||
|
||||
|
||||
## Individual Freeze
|
||||
|
||||
The **Individual Freeze** feature is a setting on a [trust line](trust-lines-and-issuing.html). When an issuer enables the Individual Freeze setting, the following rules apply to the tokens in that trust line:
|
||||
|
||||
* Payments can still occur directly between the two parties of the frozen trust line.
|
||||
* The counterparty of that trust line can no longer decrease its balance on the frozen trust line, except in direct payments to the issuer. The counterparty can only send the frozen currencies directly to the issuer.
|
||||
* The counterparty can still receive payments from others on the frozen trust line.
|
||||
* The counterparty's offers to sell the tokens in the frozen trust line are [considered unfunded](offers.html#lifecycle-of-an-offer).
|
||||
|
||||
Reminder: Trust lines do not hold XRP. XRP cannot be frozen.
|
||||
|
||||
A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution uses that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.)
|
||||
|
||||
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's tokens to the individual address. This type of individual freeze has no effect on offers.
|
||||
|
||||
The Individual Freeze applies to a single trust line. To freeze multiple tokens with a particular counterparty, the address must enable Individual Freeze on the trust lines for each separate currency code.
|
||||
|
||||
An address cannot enable the Individual Freeze setting if it has enabled the [No Freeze](#no-freeze) setting.
|
||||
|
||||
|
||||
## Global Freeze
|
||||
|
||||
The **Global Freeze** feature is a setting on an account. An account can enable a global freeze only on itself. When an issuer enables the Global Freeze feature, the following rules apply to all tokens they issue:
|
||||
|
||||
* All counterparties of the frozen issuer can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects the issuer's own [operational addresses](issuing-and-operational-addresses.html).)
|
||||
* Counterparties of the frozen issuer can still send and receive payments directly to and from the issuing address.
|
||||
* All offers to sell tokens issued by the frozen address are [considered unfunded](offers.html#lifecycle-of-an-offer).
|
||||
|
||||
Reminder: addresses cannot issue XRP. Global freezes do not apply to XRP.
|
||||
|
||||
It can be useful to enable Global Freeze on a financial institution's [issuing account](issuing-and-operational-addresses.html) if the issuer's [secret key](cryptographic-keys.html) is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, the issuer should also suspend activities in its outside systems.
|
||||
|
||||
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
|
||||
|
||||
Global Freeze applies to _all_ tokens issued and held by the address. You cannot enable Global Freeze for only one currency code. If you want to have the ability to freeze some tokens and not others, you should use different addresses for each token.
|
||||
|
||||
An address can always enable the Global Freeze setting. However, if the address has enabled the [No Freeze](#no-freeze) setting, it can never _disable_ Global Freeze.
|
||||
|
||||
|
||||
## No Freeze
|
||||
|
||||
The **No Freeze** feature is a setting on an address that permanently gives up the ability to freeze tokens arbitrarily. An issuer can use this feature to make its tokens as "more like physical money" in the sense that the issuer cannot interfere with counterparties trading the tokens among themselves.
|
||||
|
||||
Reminder: XRP already cannot be frozen. The No Freeze feature only applies to other tokens issued in the XRP Ledger.
|
||||
|
||||
The No Freeze setting has two effects:
|
||||
|
||||
* The issuer can no longer enable Individual Freeze on trust lines to any counterparty.
|
||||
* The issuer can still enact a Global Freeze, but cannot _disable_ the Global Freeze.
|
||||
|
||||
The XRP Ledger cannot force an issuer to honor the obligations that its issued funds represent, so No Freeze does stop a stablecoin issuer from defaulting on its obligations. However, No Freeze ensures that an issuer does not use the Global Freeze feature unfairly against specific users.
|
||||
|
||||
The No Freeze setting applies to all tokens issued to and from an address. If you want to be able to freeze some tokens but not others, you should use different addresses for each.
|
||||
|
||||
You can only enable the No Freeze setting with a transaction signed by your address's master key secret. You cannot use a [Regular Key](setregularkey.html) or a [multi-signed transaction](multi-signing.html) to enable No Freeze.
|
||||
|
||||
|
||||
|
||||
# See Also
|
||||
|
||||
- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
|
||||
- [Freeze Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
- **Concepts:**
|
||||
- [Trust Lines and Issuing](trust-lines-and-issuing.html)
|
||||
- **Tutorials:**
|
||||
- [Enable No Freeze](enable-no-freeze.html)
|
||||
- [Enact Global Freeze](enact-global-freeze.html)
|
||||
- [Freeze a Trust Line](freeze-a-trust-line.html)
|
||||
- **References:**
|
||||
- [account_lines method][]
|
||||
- [account_info method][]
|
||||
- [AccountSet transaction][]
|
||||
- [TrustSet transaction][]
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
html: issuing-and-operational-addresses.html
|
||||
parent: tokens.html
|
||||
blurb: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
|
||||
labels:
|
||||
- トークン
|
||||
- セキュリティ
|
||||
---
|
||||
# 発行アドレスと運用アドレス
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.ja.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## 資金のライフサイクル
|
||||
|
||||
XRP LedgerのXRP以外の残高はすべて、2つのXRP Ledgerアドレス間の会計上の関係に関連付けられている _発行済み通貨_ です。Rippleが推奨する役割の分割を金融機関が行うと、その金融機関に関連する資金の流れは循環する傾向にあります。
|
||||
|
||||
[](img/funds_flow_diagram.png)
|
||||
|
||||
発行アドレスはペイメントの送金時に、XRP Ledgerの会計上の関係に残高を作成します。ユーザーはXRP Ledger内のさまざまな会計上の関係と残高を交換できます。このため、XRP以外の残高を表す用語として _イシュアンス_ を使用します。イシュアンスの額は、発行アドレスの側から見ると債務を表すため、マイナスです。同じイシュアンスの額を発行アドレスの相手側から見ると、プラスになります。発行アドレスがペイメントを受領すると、送信されたイシュアンスが消去され、発行アドレスの債務が減少します。
|
||||
|
||||
イシュアンスは発行アドレスからスタンバイアドレスに送信されるか、または運用アドレスに直接送信されます。これらのイシュアンスはスタンバイアドレスから運用アドレスに送信されます。運用アドレスから他の取引相手（流動性プロバイダー、パートナー、その他の顧客など）にペイメントが送信されます。すべてのイシュアンスは発行アドレスとの会計上の関係に関連付けられているため、イシュアンスのペイメントと取引は、発行アドレスを「通じてRippling」されます。ペイメントが行われると、送金元と発行アドレスの会計上の関係において送金元の残高から支払額が引き落とされ、受取人と発行アドレスの会計上の関係において受取人の残高に支払額が入金されます。XRP Ledgerでは、オーダーブックや[資金のRipplingに対応する流動性プロバイダー](rippling.html)を通じて複数のイシュアーを結び付ける、より複雑な[パス](paths.html)もサポートされています。
|
||||
|
||||
## 発行アドレス
|
||||
|
||||
発行アドレスは、金庫に似ています。パートナーアドレス、顧客アドレス、運用アドレスは、発行アドレスとの間で会計上の関係（トラストライン）を作成しますが、発行アドレスから送信されるトランザクションは可能な限り少ない数に抑えられます。人間のオペレーターが定期的に、発行アドレスからトランザクションを作成、署名し、スタンバイアドレスまたは運用アドレスの残高を補充します。このようなトランザクションの署名に使用されるシークレットキーには、インターネットに接続されたどのコンピューターからもアクセスできないことが極めて重要です。
|
||||
|
||||
金庫とは異なり、発行アドレスは顧客またはパートナーからのペイメントを直接受領できます。XRP Ledgerのトランザクションはすべて公開されているため、自動システムは発行アドレスからのペイメントを監視する際にシークレットキーを必要としません。
|
||||
|
||||
### 発行アドレスの漏えい
|
||||
|
||||
不正使用者は金融機関の発行アドレスのシークレットキーを入手すると、際限なく新しいイシュアンスを作成し、分散型取引所でそのイシュアンスを取引できるようになります。これにより、金融機関が正式に取得したイシュアンスを識別して適切に清算することが難しくなります。金融機関の発行アドレスが乗っ取られた場合には、金融機関が新たに発行アドレスを作成する必要があり、また古い発行アドレスと会計上の関係を有するすべてのユーザーは新しいアドレスで、アカウントとの関係を新たに作成する必要があります。
|
||||
|
||||
### 複数の発行アドレス
|
||||
|
||||
金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行できます。ただし、いくつかの設定（[送金手数料](transfer-fees.html)のパーセンテージや[Global Freeze](freezes.html)の状況など）は、1つのアドレスから発行されるすべての通貨に同様に適用されます。金融機関が通貨ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
|
||||
|
||||
## 運用アドレス
|
||||
|
||||
運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わってペイメントを行います。トランザクションに自動的に署名するには、運用アドレスのシークレットキーをインターネットに接続されたサーバーに保管する必要があります。（シークレットキーは暗号化して保管できますが、サーバーがトランザクションに署名する際にシークレットキーを暗号化解除する必要があります。）顧客とパートナーは、運用アドレスとの会計上の関係を作成すべきではありません。
|
||||
|
||||
各運用アドレスではイシュアンスの残高が限られています。運用アドレスの残高が少なくなると、金融機関は残高を補充するため、発行アドレスまたはスタンバイアドレスから送金します。
|
||||
|
||||
### 運用アドレスの漏えい
|
||||
|
||||
不正使用者が運用アドレスのシークレットキーを入手した場合に金融機関が失う可能性のある通貨額は、最大でも運用アドレスが保有している額までです。金融機関は、顧客やパートナーからのアクションなしに、新しい運用アドレスに切り替えることができます。
|
||||
|
||||
## スタンバイアドレス
|
||||
|
||||
金融機関がリスクと利便性のバランスを保つためのもう1つの手段として、発行アドレスと運用アドレスの中間ステップとして「スタンバイアドレス」を利用することができます。金融機関はスタンバイアドレスという追加のXRP Ledgerアドレスに資金を供給できます。このアドレスのキーはオンライン上に保管されず、別の信頼できるユーザーに預けられています。
|
||||
|
||||
運用アドレスの資金が少なくなると、信頼できるユーザーがスタンバイアドレスを使用して運用アドレスの残高を補充できます。スタンバイアドレスの資金が少なくなると、金融機関は発行アドレスを使用して1回のトランザクションでスタンバイアドレスにより多くの額の通貨を送金できます。スタンバイアドレスは、送金された通貨を必要に応じてスタンバイアドレス間で分散できます。これにより発行アドレスのセキュリティが強化され、発行アドレスが実行する合計トランザクション数が減少し、1つの自動化システムの管理下に過剰な資金が残ることがなくなります。
|
||||
|
||||
運用アドレスと同様に、スタンバイアドレスは顧客やパートナーではなく発行アドレスとの間に会計上の関係を確立する必要があります。運用アドレスに適用される注意事項はすべてスタンバイアドレスにも適用されます。
|
||||
|
||||
### スタンバイアドレスの漏えい
|
||||
|
||||
スタンバイアドレスの漏えいが発生した場合、運用アドレスが漏えいした場合と同様の影響が及びます。不正使用者がスタンバイアドレスに保有される残高を盗むことが可能となり、金融機関は顧客やパートナーからのアクションなしに新しいスタンバイアドレスに切り替えることができます。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [アカウント](accounts.html)
|
||||
- [暗号鍵](cryptographic-keys.html)
|
||||
- **チュートリアル:**
|
||||
- [XRP Ledgerゲートウェイの開設](become-an-xrp-ledger-gateway.html)
|
||||
- [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
|
||||
- [レギュラーキーペアの変更または削除](change-or-remove-a-regular-key-pair.html)
|
||||
- **リファレンス:**
|
||||
- [account_infoメソッド][]
|
||||
- [SetRegularKeyトランザクション][]
|
||||
- [AccountRootオブジェクト](accountroot.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
html: issuing-and-operational-addresses.html
|
||||
parent: tokens.html
|
||||
blurb: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
|
||||
labels:
|
||||
- Tokens
|
||||
- Security
|
||||
---
|
||||
# Issuing and Operational Addresses
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## Funds Lifecycle
|
||||
|
||||
When a token issuer follows this separation of roles, funds tend to flow in specific directions, as in the following diagram:
|
||||
|
||||
{{ include_svg("img/issued-currency-funds-flow.svg", "Diagram: Funds flow from the issuing address to standby addresses, to operational addresses, to customer and partner addresses, and finally back to the issuing address.")}}
|
||||
|
||||
The issuing address creates tokens by sending payments to standby addresses. These tokens have negative value from the perspective of the issuing address, since they (often) represent obligations. The same tokens have positive value from other perspectives, including from the perspective of a standby address.
|
||||
|
||||
The standby addresses, which are operated by actual humans, send those tokens to operational addresses. This step allows the issuing address to be used as little as possible after this point, while having at least some tokens available on standby.
|
||||
|
||||
Operational addresses, which are operated by automated systems, send payments to other counterparties, such as liquidity providers, partners, and other customers. Those counterparties may send funds freely among themselves multiple times.
|
||||
|
||||
As always, token payments must "ripple through" the issuer across trust lines with sufficient limits.
|
||||
|
||||
Eventually, someone sends tokens back to the issuer. This destroys those tokens, reducing the issuer's obligations in the XRP Ledger. If the token is a stablecoin, this is the first step of redeeming the tokens for the corresponding off-ledger assets.
|
||||
|
||||
|
||||
## Issuing Address
|
||||
|
||||
The issuing address is like a vault. Partners, customers, and operational addresses create trust lines to the issuing address, but this address sends as few transactions as possible. Periodically, a human operator creates and signs a transaction from the issuing address to refill the balances of a standby or operational address. Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.
|
||||
|
||||
Unlike a vault, the issuing address can receive payments directly from customers and partners. Since all transactions in the XRP Ledger are public, automated systems can watch for payments to the issuing address without needing a secret key.
|
||||
|
||||
### Issuing Address Compromise
|
||||
|
||||
If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new tokens and send them to users or trade them in the decentralized exchange. This can make a stablecoin issuer insolvent. It can become difficult for the financial institution to distinguish legitimately-obtained tokens and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have trust lines to the old issuing address must create new trust lines with the new address.
|
||||
|
||||
### Multiple Issuing Addresses
|
||||
|
||||
A financial institution can issue more than one type of token in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all (fungible) tokens issued from an address, including the percentage for [transfer fees](transfer-fees.html) and the [global freeze](freezes.html) status. If the financial institution wants the flexibility to manage settings differently for each type of token, the institution must multiple issuing addresses.
|
||||
|
||||
|
||||
## Operational Addresses
|
||||
|
||||
An operational address is like a cash register. It makes payments on behalf of the institution by transferring tokens to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create trust lines to an operational address.
|
||||
|
||||
Each operational address has a limited balance of tokens and XRP. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address.
|
||||
|
||||
### Operational Address Compromise
|
||||
|
||||
If a malicious actor learns the secret key behind an operational address, the financial institution can only lose as much as that operational address holds. The institution can switch to a new operational address with no action from customers and partners.
|
||||
|
||||
|
||||
## Standby Addresses
|
||||
|
||||
Another optional step that an institution can take to balance risk and convenience is to use "standby addresses" as an intermediate step between the issuing address and operational addresses. The institution can fund additional XRP Ledger addresses as standby addresses, whose keys are not available to always-online servers, but are entrusted to different trusted users.
|
||||
|
||||
When an operational address is running low on funds (either tokens or XRP), a trusted user can use a standby address to refill the operational address's balance. When a standby addresses run low on funds, the institution can use the issuing address to send more funds to a standby address in a single transaction, and the standby addresses can distribute those funds among themselves if necessary. This improves security of the issuing address, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.
|
||||
|
||||
As with operational addresses, a standby address must have an accounting relationship with the issuing address, and not with customers or partners. All precautions that apply to operational addresses also apply to standby addresses.
|
||||
|
||||
### Standby Address Compromise
|
||||
|
||||
If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Accounts](accounts.html)
|
||||
- [Cryptographic Keys](cryptographic-keys.html)
|
||||
- **Tutorials:**
|
||||
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
|
||||
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
|
||||
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
|
||||
- **References:**
|
||||
- [account_info method][]
|
||||
- [SetRegularKey transaction][]
|
||||
- [AccountRoot object](accountroot.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,14 +1,3 @@
|
||||
---
|
||||
html: nftoken-batch-minting.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: Minting NFToken objects in batches.
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# Batch minting
|
||||
|
||||
There are two common approaches to minting NFToken objects in batches: mint on demand and scripted minting.
|
||||
@@ -30,7 +19,7 @@ Any market activity prior to the initial sale of the NFToken object is not recor
|
||||
|
||||
Use a program or script to mint many tokens at once. You might find the XRP Ledger ticket functionality helps you submit transactions in parallel, up to a current limit of 200 transactions in one group.
|
||||
|
||||
For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutorial.
|
||||
For a practical example, see the [Batch Mint NFTokens](../../../tutorials/quickstart/batch-minting.md) tutorial.
|
||||
|
||||
### Benefits
|
||||
|
||||
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
html: non-fungible-token-transfers.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTokenをダイレクトモードまたはブローカーモードで取引する。
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# XRP Ledger上でNFTokenを売買する
|
||||
{% include '_snippets/nfts-disclaimer.ja.md' %}
|
||||
|
||||
XRP Ledger上のアカウント間で`NFToken`オブジェクトを転送することができます。`NFToken` の売買をオファーしたり、他のアカウントから自分が保有する NFToken への売買オファーを受け入れることができます。`NFToken` を 無料(価格が0)で売却することで、`NFToken` を配布することもできます。すべてのオファーは [NFTokenCreateOfferトランザクション][] を使って作成されます。
|
||||
|
||||
|
||||
## 売却オファー
|
||||
|
||||
|
||||
### 売却オファーの作成
|
||||
|
||||
`NFToken` オブジェクトの所有者であれば、`tfSellToken` フラグを指定して [NFTokenCreateOffer トランザクション][] を使用して売却オファーを作成することができます。`NFTokenID` と、対価として受け取る金額 `Amount` を指定します。オプションで、そのオファーが無効になる `Expiration` と、その `NFToken` を購入することができる唯一のアカウントである `Destination` を指定することができます。
|
||||
|
||||
|
||||
### 売却オファーを受け入れる
|
||||
|
||||
販売されている `NFToken` を購入するには、`NFTokenAcceptOffer` トランザクションを使用します。`NFTokenOffer` オブジェクトの所有者アカウントと `NFTokenOfferID` を指定し、受け入れることを決定します。
|
||||
|
||||
|
||||
## 購入オファー
|
||||
|
||||
|
||||
### 購入オファーの作成
|
||||
|
||||
どのアカウントでも `NFToken` の購入オファーを作成することができます。`tfSellToken` のフラグを指定せずに、[NFTokenCreateOffer][] を使用することで、購入オファーを作成することが可能です。`Owner`アカウント、`NFTokenID`、オファーの `Amount` を指定します。
|
||||
|
||||
|
||||
### 購入オファーを受け入れる
|
||||
|
||||
`NFTokenAcceptOffer` トランザクションを使用して `NFToken` を転送します。`NFTokenOfferID` と所有者アカウントを指定して、トランザクションを完了させてください。
|
||||
|
||||
|
||||
## 取引モード
|
||||
|
||||
`NFToken`を取引する場合、購入者と販売者の間で直接取引を行う、 _ダイレクト_ 取引と、第三者の口座が売りと買いのオファーをマッチングして取引を仲介する、 _ブローカー_ 取引を選択することができます。
|
||||
|
||||
ダイレクトモードでの取引では、販売者が転送をコントロールすることができます。販売者は誰でも購入できるように `NFToken` を出品するか、特定の取引先アカウントに `NFToken` を販売することができます。販売者はNFTokenの販売価格全額を受け取ります。
|
||||
|
||||
ブローカーモードでは、販売者は第三者のアカウントに`NFToken`の販売を仲介させます。ブローカーアカウントは、合意したレートで仲介手数料を徴収し、転送を行います。購入はリアルタイムで完了し、ブローカーと販売者には購入資金から支払われ、ブローカーによる前払いは必要ありません。
|
||||
|
||||
|
||||
### ブローカーモードを使用する場合
|
||||
|
||||
`NFToken`の作成者が適切な購入者を探す時間と忍耐力がある場合、作成者は販売から得たすべての収益を得ることができます。これは、少数の`NFToken`オブジェクトを様々な価格で販売するクリエイターにとって、非常に有効な方法です。
|
||||
|
||||
一方、クリエイターは、創作に時間を割くことができるのに、販売に時間を割くのは抵抗があるのではないでしょうか。そのような場合、個別に対応するのではなく、第三者であるブローカーのアカウントに販売業務を委託することが可能です。
|
||||
|
||||
ブローカーを利用すると、いくつかの利点があります。例えば
|
||||
|
||||
* ブローカーは仲介者として、`NFToken`の販売価格を最大化するために活動することができます。ブローカーが販売価格の何割かを受け取る場合、価格が高ければ高いほど、ブローカーの収入も増えます。
|
||||
* ブローカーは、ニッチな市場や 価格帯などの基準に基づいて`NFToken`オブジェクトの管理を行う管理者として活動することができます。これによって、クリエイターの作品を発見できないような購入者のグループを呼び込むことができるでしょう。
|
||||
* ブローカーは、Opensea.ioのようなマーケットプレイスとして機能し、アプリケーション層でオークション機能を提供することもできます。
|
||||
|
||||
|
||||
### ブローカー販売のワークフロー
|
||||
|
||||
最も単純なワークフローでは、クリエイターが新しい`NFToken`を発行します。クリエイターは売却オファーを作成する際、最低売却価格を入力し、売却先にブローカーを設定します。購入希望者はブローカーを経由して`NFToken`に入札を行います。ブローカーは落札者を選び、取引を完了させ、ブローカー手数料を受け取ります。ベストプラクティスとして、ブローカーは`NFToken`に対して残っている購入オファーをすべてキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
もう1つのワークフローは、クリエイターが販売をよりコントロールできるようにするものです。このワークフローでは、クリエイターが新しい`NFToken`を発行します。入札者はオファーを作成し、ブローカーを宛先として設定します。ブローカーは落札者を選び、仲介手数料を差し引き、`NFTokenCreateOffer`を使用してクリエイターに署名の依頼をします。クリエーターは要求されたオファーに署名し、ブローカーを宛先として設定します。ブローカーは `NFTokenAcceptOffer` を使って売却を完了し、仲介手数料を保持します。ブローカーは `NFTokenCancelOffer` を使用して `NFToken` に対する残りの入札をキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所有者が他のアカウントで作成した `NFToken` をリセールする場合にも、同じワークフローを使用することができます。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,18 +1,7 @@
|
||||
---
|
||||
html: non-fungible-token-transfers.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: Trading NFTokens in direct or brokered mode.
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# Trading NFTokens on the XRP Ledger
|
||||
{% include '_snippets/nfts-disclaimer.md' %}
|
||||
|
||||
You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0. All offers are created using [NFTokenCreateOffer transaction][].
|
||||
You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0. All offers are created using `NFTokenCreateOffer` transaction.
|
||||
|
||||
|
||||
## Sell Offers
|
||||
@@ -20,7 +9,7 @@ You can transfer `NFToken` objects between accounts on the XRP Ledger. You can o
|
||||
|
||||
### Create a Sell Offer
|
||||
|
||||
As the owner of a `NFToken` object, you can create a sell offer using a [NFTokenCreateOffer transaction][] with the `tfSellToken` flag. You provide the `NFTokenID` and the `Amount` you are willing to accept in payment. You can optionally specify an `Expiration` date, after which the offer is no longer valid, and a `Destination` account, which is the only account that is allowed to purchase the `NFToken`.
|
||||
As the owner of a `NFToken` object, you can create a sell offer using a `NFTokenCreateOffer` transaction with the `tfSellToken` flag. You provide the `NFTokenID` and the `Amount` you are willing to accept in payment. You can optionally specify an `Expiration` date, after which the offer is no longer valid, and a `Destination` account, which is the only account that is allowed to purchase the `NFToken`.
|
||||
|
||||
|
||||
### Accept a Sell Offer
|
||||
@@ -33,7 +22,7 @@ To purchase a `NFToken` that is offered for sale, you use a `NFTokenAcceptOffer`
|
||||
|
||||
### Create a Buy Offer
|
||||
|
||||
Any account can offer to buy a `NFToken`. You can create a buy offer using [NFTokenCreateOffer][] _without_ the `tfSellToken` flag. You provide the `Owner` account, `NFTokenID`, and the `Amount` of your offer.
|
||||
Any account can offer to buy a `NFToken`. You can create a buy offer using `NFTokenCreateOffer` _without_ the `tfSellToken` flag. You provide the `Owner` account, `NFTokenID`, and the `Amount` of your offer.
|
||||
|
||||
|
||||
### Accept a Buy Offer
|
||||
@@ -68,19 +57,13 @@ Using a broker offers several advantages. For example:
|
||||
In the most straightforward workflow, a creator mints a new `NFToken`. The creator initiates a sell offer, entering the minimum acceptable sale price and setting the broker as the destination. Potential buyers make bids for the `NFToken`, setting the broker as the destination for the bid. The broker selects a winning bid and completes the transaction, taking a broker’s fee. As a best practice, the broker then cancels any remaining buy offers for the `NFToken`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Another potential workflow would give the creator more control over the sale. In this workflow, the creator mints a new `NFToken`. Bidders create their offers, setting the broker as the destination. The broker selects the winning bid, subtracts their broker fee, and uses `NFTokenCreateOffer` to request that the creator sign off on the offer. The creator signs the requested offer, setting the broker as the destination. The broker completes the sale using `NFTokenAcceptOffer`, retaining the broker fee. The broker cancels any remaining bids for the `NFToken` using `NFTokenCancelOffer`.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
The same workflows can be used when an owner resells a `NFToken` created by another account.
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
The same workflows can be used when an owner resells a `NFToken` created by another account.
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
html: non-fungible-tokens.html
|
||||
parent: tokens.html
|
||||
blurb: XRPL NFTの紹介。
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# NFTのコンセプトの概要
|
||||
{% include '_snippets/nfts-disclaimer.ja.md' %}
|
||||
|
||||
XRP Ledgerは、_IOUs_ としても知られる[発行済み通貨(tokens.html)のサポートを提供しています。このような資産は、主に、代替可能(Fungible)です。
|
||||
|
||||
> 代替可能性
|
||||
>
|
||||
> 1. 個々の単位が本質的に交換可能であり、各部分が別の部分と区別できない商品または商品の特性である
|
||||
|
||||
代替可能トークンは、XRP Ledgerの分散型取引所において、ユーザー間でXRPや他の発行済み通貨と手軽に交換することができます。そのため、決済に適しています。
|
||||
|
||||
|
||||
例えば、切手などがそうです。1919年当時、あなたが航空便で手紙を送る必要がある場合、24セントの切手を購入し、封筒に張ったでしょう。もしその切手をなくしてしまったら、別の24セント切手を使うか、10セント切手2枚と2セント切手2枚を使うことができます。非常に使い勝手がいいのです。
|
||||
|
||||
|
||||
|
||||
しかし、1919年という時代のことですから、切手の飛行機が偶然にも逆さまに印刷されている24セントの航空郵便切手が出回るかもしれません。これが世界的に有名な「インバート・ジェニー」切手です。1枚の切手シートで100枚しか流通しなかったため、非常に希少で人気の高い切手です。現在、鑑定では一枚150万円以上の価値があるとされています。
|
||||
|
||||
|
||||
|
||||
これらの切手は、他の24セント切手と交換することはできません。非代替(Non-fungible)になってしまったのです。
|
||||
|
||||
[NonFungibleTokensV1の修正][] :現在有効ではありません: は、XRP Ledgerに非代替性トークン（NFT）のサポートをネイティブで追加するものです。 非代替性トークンは、芸術品やゲーム内アイテムなど、ユニークな物理的、非物理的、あるいは純粋なデジタル商品の所有権をコード化する役割を果たします。
|
||||
|
||||
|
||||
## XRP Ledger上のNFT
|
||||
|
||||
XRP Ledger上では、non-fungible tokenは[NFToken][]オブジェクトとして表されます。NFTokenはユニークで分割できない単位で、決済には使用できません。ユーザーはこのようなトークンを発行（作成）、保有、購入、売却、焼却（破棄）することができます。
|
||||
|
||||
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の `NFToken` オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の `NFToken` オブジェクトに対する [準備金] (reserves.html) は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
|
||||
|
||||
また、アカウントは、自分に代わってNFTokenオブジェクトを発行・販売するブローカー（代理発行者）を指定することができます。
|
||||
|
||||
`NFToken` オブジェクトは、トークンが発行された時点で確定し、後で変更することが出来ない設定項目を持ちます。これらは以下の通りです。
|
||||
|
||||
- トークンを一意に定義する各種識別データ。
|
||||
- 発行者が、現在の保有者に関係なく、トークンを焼却できるかどうか。
|
||||
- トークンの保持者がトークンを他者に転送できるかどうか。( `NFToken` は常に発行者に直接送信したり、発行者から送信することが可能です)。
|
||||
- 転送が許可されている場合、発行者は販売価格に対する一定の割合で手数料を徴収することができます。
|
||||
- NFTokenを[発行済み通貨](tokens.html)で売却できるか、XRPのみでしか売却できないか。
|
||||
|
||||
|
||||
## `NFToken`のライフサイクル
|
||||
|
||||
誰もが [NFTokenMint トランザクション][] を使って新しい `NFToken` を作成することができます。`NFToken` は発行者アカウントの [NFTokenPage オブジェクト][] に格納されます。所有者または利害関係者は [NFTokenCreateOffer トランザクション][]を送信して `NFToken` の売買を提案できます。レジャーは提案された転送を [NFTokenOffer オブジェクト][]として追跡し、一方が承諾またはキャンセルすると `NFTokenOffer` を削除します。`NFToken` が転送可能であれば、アカウント間で複数回取引することができます。
|
||||
|
||||
[NFTokenBurn トランザクション][] を使用して、自分が所有する `NFToken` を破棄することができます。発行者が `tfBurnable` フラグを有効にしてトークンを発行した場合、発行者は現在の所有者に関係なくトークンを破棄することが可能です。( 例えば、あるイベントのチケットを表すトークンである場合、そのチケットをある時点で消費するといった場合に便利です)。
|
||||
|
||||
|
||||
|
||||
`NFToken` オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](non-fungible-token-transfers.html) を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [NFToken][] データ型
|
||||
- レジャーオブジェクト
|
||||
- [NFTokenOffer オブジェクト][]
|
||||
- [NFTokenPage オブジェクト][]
|
||||
- トランザクション
|
||||
- [NFTokenMint トランザクション][]
|
||||
- [NFTokenCreateOffer トランザクション][]
|
||||
- [NFTokenCancelOffer トランザクション][]
|
||||
- [NFTokenAcceptOffer トランザクション][]
|
||||
- [NFTokenBurn トランザクション][]
|
||||
- API メソッド
|
||||
- [account_nfts メソッド][]
|
||||
- [nft_sell_offers メソッド][]
|
||||
- [nft_buy_offers メソッド][]
|
||||
- [nft_info メソッド][] (Clioサーバのみ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,86 +0,0 @@
|
||||
---
|
||||
html: non-fungible-tokens.html
|
||||
parent: tokens.html
|
||||
blurb: Introduction to XRPL NFTs.
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# NFT Conceptual Overview
|
||||
{% include '_snippets/nfts-disclaimer.md' %}
|
||||
|
||||
The XRP Ledger offers support for [tokens](tokens.html), also known as _IOUs_. Such assets are, primarily, fungible.
|
||||
|
||||
> Fun·gi·ble /ˈfənjəbəl/ (adj)
|
||||
>
|
||||
> 1. able to replace or be replaced by another identical item; mutually interchangeable.
|
||||
|
||||
Fungible tokens can be easily traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
|
||||
|
||||
|
||||
A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would purchase a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
|
||||
|
||||
|
||||
|
||||
But since you are standing around in 1919, you might be offered 24-cent airmail stamps where the aeroplane on the stamp is accidentally printed upside down. These are the world famous “Inverted Jenny” stamps. Only 100 were circulated on a single sheet of stamps, making them extremely rare and sought after. The current value of each mint condition stamp is appraised at over $1.5 million dollars.
|
||||
|
||||
|
||||
|
||||
Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
|
||||
|
||||
The [NonFungibleTokensV1 amendment][] :not_enabled: adds support for non-fungible tokens (NFTs, or “nifties” in the vernacular) natively on the XRP Ledger. Non-fungible tokens serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
|
||||
|
||||
|
||||
## NFTs on the XRP Ledger
|
||||
|
||||
On the XRP Ledger, a non-fungible token is represented as a [NFToken][] object. A `NFToken` is a unique, indivisible unit that is not used for payments. Users can mint (create), hold, buy, sell, and burn (destroy) such tokens.
|
||||
|
||||
The ledger stores up to 32 `NFToken` objects owned by the same account in a single [NFTokenPage object][] to save space. As a result, the owner's [reserve requirement](reserves.html) for `NFToken` objects only increases when the ledger needs to make a new page to store additional tokens.
|
||||
|
||||
Accounts can also designate a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
|
||||
|
||||
`NFToken` objects have several settings that are defined when the token is minted and cannot be changed later. These include:
|
||||
|
||||
- Various identifying data that uniquely defines the token.
|
||||
- Whether the issuer can burn the token regardless of who currently holds it.
|
||||
- Whether the holder of the token can transfer it to others. (The `NFToken` can always be sent to or from the issuer directly.)
|
||||
- If transfers are allowed, the issuer can charge a transfer fee as a percentage of the sale price.
|
||||
- Whether the holder can sell the `NFToken` for [fungible token](tokens.html) amounts, or only for XRP.
|
||||
|
||||
|
||||
## `NFToken` Lifecycle
|
||||
|
||||
Anyone can create a new `NFToken` using the [NFTokenMint transaction][] type. The `NFToken` lives on the [NFTokenPage object][] of the issuing account. Either the owner or an interested party can send a [NFTokenCreateOffer transaction][] to propose buying or selling the `NFToken`; the ledger tracks the proposed transfer as a [NFTokenOffer object][], and deletes the `NFTokenOffer` when either side accepts or cancels the offer. If the `NFToken` is transferable, it can be traded multiple times between accounts.
|
||||
|
||||
You can destroy a `NFToken` you own using the [NFTokenBurn transaction][]. If the issuer minted the token with `tfBurnable` flag enabled, the issuer can also burn the token regardless of the current owner. (This could be useful, for example, for a token that represents a ticket to an event which is used up at some point.)
|
||||
|
||||
|
||||
|
||||
For more info about transferring `NFToken` objects, see [Trading NFTokens on the XRP Ledger](non-fungible-token-transfers.html).
|
||||
|
||||
|
||||
## Reference
|
||||
|
||||
- [NFToken][] data type
|
||||
- Ledger Objects
|
||||
- [NFTokenOffer object][]
|
||||
- [NFTokenPage object][]
|
||||
- Transactions
|
||||
- [NFTokenMint transaction][]
|
||||
- [NFTokenCreateOffer transaction][]
|
||||
- [NFTokenCancelOffer transaction][]
|
||||
- [NFTokenAcceptOffer transaction][]
|
||||
- [NFTokenBurn transaction][]
|
||||
- API Methods
|
||||
- [account_nfts method][]
|
||||
- [nft_sell_offers method][]
|
||||
- [nft_buy_offers method][]
|
||||
- [nft_info method][] (Clio server only)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
html: paths.html
|
||||
parent: tokens.html
|
||||
blurb: 発行済み通貨の支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。
|
||||
labels:
|
||||
- 支払い
|
||||
- 複数通貨間
|
||||
---
|
||||
# パス
|
||||
|
||||
XRP Ledgerでは、[発行済み通貨](tokens.html)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](decentralized-exchange.html)のオーダーを介して送金元と受取人を結び付けることで、[複数通貨間の支払い](cross-currency-payments.html)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
|
||||
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
|
||||
|
||||
XRPは任意のアドレスに直接送金できるため、[XRP間のトランザクション](direct-xrp-payments.html)ではパスは使用されません。
|
||||
|
||||
## パスのステップ
|
||||
|
||||
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
|
||||
|
||||
* 同一通貨の別のアドレスを通じたRippling
|
||||
* オーダーブックでの通貨の取引
|
||||
|
||||
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.html)を参照してください。
|
||||
|
||||
通貨取引ステップの場合、パスステップにより変換先の通貨が指定されますが、オーダーブックにはオファーの状態は記録されません。レジャーが検証されるまではトランザクションの正規の順序は最終的ではないため、トランザクションの検証が完了するまでは、トランザクションがどのオファーをとるかは不明です。（各トランザクションは最終レジャーでの実行時に利用可能なオファーの中から最適なオファーをとるため、経験に基づいて推測することができます。） <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](transfer-fees.html)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
|
||||
[](img/paths-examples.ja.png)
|
||||
|
||||
|
||||
|
||||
# 技術詳細
|
||||
|
||||
## Pathfinding
|
||||
|
||||
`rippled` APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][]（WebSocketのみ）は、レジャーが閉鎖するか、またはサーバーがより適切なパスを検出するたびに、フォローアップ応答によって検索を拡大します。
|
||||
|
||||
署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](submit.html#署名と送信モード)への要求に`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
|
||||
|
||||
**注意:** `rippled`は可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できない`rippled`インスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。
|
||||
|
||||
パスの検出は、新しいレジャーが検証されるたびに数秒ごとに変化する非常に難しい課題であるため、`rippled`は完全に最適なパスを検出するようには設計されていません。ただし、いくつかの有効なパスを検出し、特定額の送金コストを推定することができます。
|
||||
|
||||
|
||||
## 暗黙のステップ
|
||||
|
||||
規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](payment.html)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
|
||||
|
||||
* パスの1番目のステップは、トランザクションの`Account`フィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。
|
||||
* トランザクションに、そのトランザクションの送信者ではない`issuer`が指定されている`SendMax`フィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。
|
||||
* `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](payment.html#sendmaxおよびamountで使用する特殊なissuerの値)を参照してください。
|
||||
* トランザクションの`Amount`フィールドに、トランザクションの`Destination`とは異なる`issuer`が指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。
|
||||
* 最後に、トランザクションの`Destination`フィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
|
||||
|
||||
|
||||
## デフォルトパス
|
||||
|
||||
明示的に指定されたパスの他に、トランザクションは _デフォルトパス_ に沿って実行できます。デフォルトパスは、トランザクションの[暗黙のステップ](#暗黙のステップ)を接続する最も簡単な方法です。
|
||||
|
||||
デフォルトパスは次のいずれかになります。
|
||||
|
||||
* トランザクションで（イシュアーに関係なく）1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
|
||||
* `SendMax`が省略されているか、または`SendMax`の`issuer`が送金元の場合、デフォルトパスが機能するためには送金元`Account`から宛先`Amount`の`issuer`へのトラストラインが必要です。
|
||||
* `SendMax`と`Amount`に異なる`issuer`値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
|
||||
* 複数通貨間のトランザクションの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックを使用します。
|
||||
|
||||
有効なすべてのデフォルトパスを次の図に示します。
|
||||
[](img/paths-default_paths.ja.png)
|
||||
|
||||
デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](payment.html#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
|
||||
|
||||
|
||||
## パスの仕様
|
||||
|
||||
パスセットは配列です。パスセットの各要素は、個々の _パス_ を表す別の配列です。パスの各要素は、ステップを指定するオブジェクトです。ステップのフィールドを次に示します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:-----------|:-----------------------|:---------------------------------------|
|
||||
| `account` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップに`currency`フィールドまたは`issuer`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `issuer` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨のイシュアーを定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップがイシュアーを定義します。`currency`が省略され、このフィールドが指定されている場合、イシュアーが異なる同名の通貨間でオーダーブックを使用するパスステップを示します。`currency`がXRPの場合は省略する必要があります。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `type` | 整数 | **廃止予定**_（省略可）_ 他にどのフィールドが指定されているかを示します。 |
|
||||
| `type_hex` | 文字列 | **廃止予定**: _（省略可）_`type`フィールドの16進数表現です。 |
|
||||
|
||||
要約すると、以下のフィールドの組み合わせが有効であり、またオプションで`type`、`type_hex`のいずれかまたは両方を指定できます。
|
||||
|
||||
- `account`のみ
|
||||
- `currency`のみ
|
||||
- `currency`と`issuer`（`currency`がXRP以外の場合）
|
||||
- `issuer`のみ
|
||||
|
||||
パスステップで`account`、`currency`、`issuer`の各フィールドを上記以外の方法で指定することは無効です。
|
||||
|
||||
パスセットのバイナリシリアル化に使用される`type`フィールドは、実際には1つの整数上でビット演算により作成されます。ビットの定義は次のとおりです。
|
||||
|
||||
| 値（16進数） | 値（10進数） | 説明 |
|
||||
|-------------|-----------------|-------------|
|
||||
| 0x01 | 1 | アドレスの変更（Rippling）:`account`フィールドが指定されています。 |
|
||||
| 0x10 | 16 | 通貨の変更:`currency`フィールドが指定されています。 |
|
||||
| 0x20 | 32 | イシュアーの変更:`issuer`フィールドが指定されています。 |
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [複数通貨間の支払い](cross-currency-payments.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [Partial Payments](partial-payments.html)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [path_findメソッド][]（WebSocketのみ）
|
||||
- [ripple_path_findメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,18 +1,10 @@
|
||||
---
|
||||
html: paths.html
|
||||
parent: tokens.html
|
||||
blurb: Payments of tokens must traverse paths of connected users and order books.
|
||||
labels:
|
||||
- Payments
|
||||
- Cross-Currency
|
||||
---
|
||||
# Paths
|
||||
|
||||
In the XRP Ledger, paths define a way for [tokens](tokens.html) to flow through intermediary steps as part of a payment. Paths enable [cross-currency payments](cross-currency-payments.html) by connecting sender and receiver through orders in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). Paths also enable complex settlement of offsetting debts.
|
||||
In the XRP Ledger, paths define a way for [tokens](tokens.md) to flow through intermediary steps as part of a payment. Paths enable [cross-currency payments](../transactions/payments/cross-currency-payments.md) by connecting sender and receiver through orders in the XRP Ledger's decentralized exchange. Paths also enable complex settlement of offsetting debts.
|
||||
|
||||
A single Payment transaction in the XRP Ledger can use multiple paths, combining liquidity from different sources to deliver the desired amount. Thus, a transaction includes a _path set_, which is a collection of possible paths to take. All paths in a path set must start with the same currency, and must also end with the same currency as each other.
|
||||
|
||||
Since XRP can be sent directly to any address, an [XRP-to-XRP transaction](direct-xrp-payments.html) does not use any paths.
|
||||
Since XRP can be sent directly to any address, an XRP-to-XRP transaction does not use any paths.
|
||||
|
||||
## Path Steps
|
||||
|
||||
@@ -21,11 +13,11 @@ A path is made of steps that connect the sender to the receiver of the payment.
|
||||
* Rippling through another address with the same currency
|
||||
* Trading tokens or XRP using an order book
|
||||
|
||||
[Rippling](rippling.html) is the process of exchanging equivalent tokens using the same currency code. In the typical case, rippling through an issuer involves reducing the tokens issued to one party and increasing the tokens issued to another party by an equal amount. The path step specifies which account to ripple through.
|
||||
[Rippling](rippling.md) is the process of exchanging equivalent tokens using the same currency code. In the typical case, rippling through an issuer involves reducing the tokens issued to one party and increasing the tokens issued to another party by an equal amount. The path step specifies which account to ripple through.
|
||||
|
||||
[Trading tokens and possibly XRP](decentralized-exchange.html) involves going to an order book and finding the best exchange rate between the assets involved for the amount being sent. The path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) <!-- STYLE_OVERRIDE: will -->
|
||||
Trading tokens and possibly XRP involves going to an order book and finding the best exchange rate between the assets involved for the amount being sent. The path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.html), trust line quality settings, or rounding.
|
||||
In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.md), trust line quality settings, or rounding.
|
||||
|
||||
{{ include_svg("img/paths-examples.svg", "Diagram of three example paths") }}
|
||||
|
||||
@@ -35,9 +27,9 @@ In both types of steps, each intermediate address gains and loses approximately
|
||||
|
||||
## Pathfinding
|
||||
|
||||
The `rippled` API has two methods that can be used for pathfinding. The [ripple_path_find method][] does a one-time lookup of possible path sets. The [path_find method][] (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.
|
||||
The `rippled` API has two methods that can be used for pathfinding. The `ripple_path_find` method does a one-time lookup of possible path sets. The `path_find` method (WebSocket only) expands on the search with follow-up responses whenever a ledger closes or the server finds a better path.
|
||||
|
||||
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the [sign method][] or [`submit` command (sign-and-submit mode)](submit.html#sign-and-submit-mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
|
||||
You can have `rippled` automatically fill in paths when you sign it, by including the `build_path` field in a request to the `sign` method or `submit` command (sign-and-submit mode). However, we recommend pathfinding separately and confirming the results before signing, to avoid surprises.
|
||||
|
||||
**Caution:** Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit. The actual cost to execute a payment along a path can change between submission and transaction execution.
|
||||
|
||||
@@ -46,11 +38,11 @@ Finding paths is a very challenging problem that changes slightly every few seco
|
||||
|
||||
## Implied Steps
|
||||
|
||||
By convention, several steps of a path are implied by the [fields of the Payment transaction](payment.html): specifically, the `Account` (sender), `Destination` (receiver), `Amount` (currency and amount to be delivered) and `SendMax` (currency and amount to be sent, if specified). The implied steps are as follows:
|
||||
By convention, several steps of a path are implied by the [fields of the Payment transaction](../transactions/payments/payment-types.md): specifically, the `Account` (sender), `Destination` (receiver), `Amount` (currency and amount to be delivered) and `SendMax` (currency and amount to be sent, if specified). The implied steps are as follows:
|
||||
|
||||
* The first step of a path is always implied to be the sender of the transaction, as defined by the transaction's `Account` field.
|
||||
* If the transaction includes a `SendMax` field with an `issuer` that is not the sender of the transaction, that issuer is implied to be the second step of the path.
|
||||
* If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines for the given currency code. See [special values for `SendMax` and `Amount`](payment.html#special-issuer-values-for-sendmax-and-amount) for details.
|
||||
* If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines for the given currency code. See [special values for `SendMax` and `Amount`](../transactions/payments/payment-types.md) for details.
|
||||
* If the `Amount` field of the transaction includes an `issuer` that is not the same as the `Destination` of the transaction, that issuer is implied to be the second-to-last step of the path.
|
||||
* Finally, last step of a path is always implied to be the receiver of a transaction, as defined by the transaction's `Destination` field.
|
||||
|
||||
@@ -70,7 +62,7 @@ The following diagram enumerates all possible default paths:
|
||||
|
||||
{{ include_svg("img/default-paths.svg", "Diagram of default paths") }}
|
||||
|
||||
You can use the [`tfNoDirectRipple` flag](payment.html#payment-flags) to disable the default path. In this case, the transaction can only execute using the paths explicitly included in the transaction. Traders can use this option to take arbitrage opportunities.
|
||||
You can use the `tfNoDirectRipple` flag to disable the default path. In this case, the transaction can only execute using the paths explicitly included in the transaction. Traders can use this option to take arbitrage opportunities.
|
||||
|
||||
|
||||
## Path Specifications
|
||||
@@ -102,7 +94,7 @@ The `type` field, used for the binary serialization of a path set, is actually c
|
||||
| `0x10` | 16 | A change of currency: the `currency` field is present. |
|
||||
| `0x20` | 32 | A change of issuer: the `issuer` field is present. |
|
||||
|
||||
|
||||
<!--
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
@@ -113,9 +105,4 @@ The `type` field, used for the binary serialization of a path set, is actually c
|
||||
- [Payment transaction][]
|
||||
- [path_find method][] (WebSocket only)
|
||||
- [ripple_path_find method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
-->
|
||||
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
html: rippling.html
|
||||
parent: tokens.html
|
||||
blurb: Ripplingは、複数当事者間での発行済み通貨残高の自動ネット決済です。
|
||||
labels:
|
||||
- トークン
|
||||
- 複数通貨間
|
||||
---
|
||||
# Rippling
|
||||
|
||||
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](trust-lines-and-issuing.html)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingは発行済み通貨の基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザーは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](offers.html)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
|
||||
|
||||
Ripplingは、支払[パス](paths.html)でのみ発生します。[XRP間の直接決済](direct-xrp-payments.html)にはRipplingは使用されません。
|
||||
|
||||
発行アカウント以外のアカウントでは、Ripplingが望ましくない場合があります。Ripplingを使えば、他のユーザーが同一通貨のイシュアー間で債権債務を移動できるようになるためです。このため、アカウントの[DefaultRippleフラグ](#defaultrippleフラグ)を有効にして、アカウントがデフォルトでRipplingを有効にしない限り、デフォルトでは[NoRippleフラグ](#norippleフラグ)により着信トラストラインでのRipplingが無効になっています。
|
||||
|
||||
**注意:** 別のアドレスへのトラストラインを作成する場合、そのトラストラインのあなたの側でRipplingをブロックするには、tfSetNoRippleフラグを明示的に有効にする必要があります。
|
||||
|
||||
## Ripplingの例
|
||||
|
||||
「Rippling」は、支払いを行うために複数のトラストラインが調整されたときに発生します。たとえば、AliceがCharlieにお金を借りており、さらにAliceはBobからもお金を借りている場合、XRP Ledgerではトラストラインは次のようになります:
|
||||
|
||||
|
||||
|
||||
BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
|
||||
|
||||
|
||||
|
||||
2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
|
||||
|
||||
## NoRippleフラグ
|
||||
|
||||
発行アカウント以外のアカウント、特に手数料やポリシーが異なる複数のイシュアーの残高を保有している流動性プロバイダーは、一般的に残高がRipplingされることを望みません。
|
||||
|
||||
「NoRipple」フラグは、トラストライン上の設定です。2つのトラストラインの両方で、同じアドレスによってNoRippleが有効に設定されている場合、第三者からの支払を、これらのトラストラインでこのアドレスを通じて「Rippling」することはできません。これにより、同一通貨の複数イシュアー間で流動性プロバイダーの残高が予期せず移動されるのを防ぎます。
|
||||
|
||||
アカウントは1つのトラストラインでNoRippleを無効にできます。これにより、そのトラストラインを含む任意のペアを通じてのRipplingが可能になります。アカウントにてデフォルトでRipplingを有効にするには、[DefaultRippleフラグ](#defaultrippleフラグ)を有効にします。
|
||||
|
||||
たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
|
||||
|
||||
|
||||
|
||||
CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
|
||||
|
||||
|
||||
|
||||
この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
|
||||
|
||||
例:
|
||||
|
||||
|
||||
|
||||
このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
|
||||
|
||||
### 詳細
|
||||
|
||||
NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
|
||||
|
||||
|
||||
|
||||
|
||||
## DefaultRippleフラグ
|
||||
|
||||
DefaultRippleフラグは、デフォルトで着信トラストラインでのRipplingを有効にするアカウント設定です。ゲートウェイやその他の通貨イシュアーは、顧客が通貨を相互に送金できるようにするには、このフラグを有効にする必要があります。
|
||||
|
||||
アカウントのDefaultRipple設定は、他者があなたに対してオープンしたトラストラインにのみ影響し、あなたが作成するトラストラインには影響しません。アカウントのDefaultRipple設定を変更する場合、変更前に作成したトラストラインでは既存のNoRipple設定が維持されます。アドレスの新しいデフォルトに合わせてトラストラインのNoRipple設定を変更するには、[TrustSetトランザクション][]を使用します。
|
||||
|
||||
詳細は、[「XRP Ledgerゲートウェイの開設」のDefaultRipple](become-an-xrp-ledger-gateway.html#default-ripple)を参照してください。
|
||||
|
||||
|
||||
## NoRippleを使用する
|
||||
<!--{# TODO: move these things into their own tutorials #}-->
|
||||
|
||||
### NoRippleを有効/無効にする
|
||||
|
||||
トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
|
||||
|
||||
|
||||
### NoRippleステータスの確認
|
||||
|
||||
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
|
||||
|
||||
[`rippled` API](http-websocket-apis.html)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [パス](paths.html)
|
||||
- **チュートリアル:**
|
||||
- [XRP Ledgerゲートウェイの開設](become-an-xrp-ledger-gateway.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
|
||||
- [RippleState（トラストライン）のフラグ](ripplestate.html#ripplestateのフラグ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,16 +1,10 @@
|
||||
---
|
||||
html: rippling.html
|
||||
parent: tokens.html
|
||||
blurb: Rippling is automatic multi-party net settlement of token balances.
|
||||
labels:
|
||||
- Tokens
|
||||
- Cross-Currency
|
||||
---
|
||||
# Rippling
|
||||
|
||||
In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](trust-lines-and-issuing.html) for the same token. Rippling is essential, because it allows users who hold tokens to send those to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way [exchange order](offers.html) with no limit and a 1:1 exchange rate for two tokens with the same currency code but different issuers.
|
||||
In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](../transactions/trust-lines-and-issuing.md) for the same token. Rippling is essential, because it allows users who hold tokens to send those to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way exchange order with no limit and a 1:1 exchange rate for two tokens with the same currency code but different issuers.
|
||||
|
||||
Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling.
|
||||
<!-- [exchange order](../server/offers.md) -->
|
||||
|
||||
Rippling only occurs along the [paths](paths.md) of a payment. [Direct XRP-to-XRP payments](../transactions/payments/direct-xrp-payments.md) do not involve rippling.
|
||||
|
||||
For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between tokens with the same currency code but different issuers. The [No Ripple Flag](#the-no-ripple-flag) disables rippling by default when others open trust lines to your account, unless you enable rippling by default using the [Default Ripple flag](#the-default-ripple-flag).
|
||||
|
||||
@@ -65,7 +59,7 @@ The **Default Ripple** flag is an account setting that enables rippling on all _
|
||||
|
||||
The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a [TrustSet transaction][] to change the No Ripple setting of a trust line to match your address's new default.
|
||||
|
||||
For more information, see [Default Ripple in 'Becoming an XRP Ledger Gateway'](become-an-xrp-ledger-gateway.html#default-ripple).
|
||||
For more information, see Default Ripple in 'Becoming an XRP Ledger Gateway'. <!--](become-an-xrp-ledger-gateway.html#default-ripple).-->
|
||||
|
||||
|
||||
## Using No Ripple
|
||||
@@ -75,14 +69,20 @@ For more information, see [Default Ripple in 'Becoming an XRP Ledger Gateway'](b
|
||||
|
||||
The No Ripple flag can only be enabled on a trust line if the address has a positive or zero balance on that trust line. This is so that the feature cannot be abused to default on the obligation the trust line balance represents. (Of course, you can still default by abandoning the address.)
|
||||
|
||||
To enable the No Ripple flag, send a [TrustSet transaction][] with the `tfSetNoRipple` flag. You can disable the No Ripple flag (that is, allow rippling) with the `tfClearNoRipple` flag instead.
|
||||
To enable the No Ripple flag, send a `TrustSet` transaction with the `tfSetNoRipple` flag. You can disable the No Ripple flag (that is, allow rippling) with the `tfClearNoRipple` flag instead.
|
||||
|
||||
|
||||
### Looking Up No Ripple Status
|
||||
|
||||
In the case of two accounts that mutually trust each other, the No Ripple flag is tracked separately for each account.
|
||||
|
||||
Using the [HTTP / WebSocket APIs](http-websocket-apis.html) or your preferred [client library](client-libraries.html), look up trust lines with the [account_lines method][]. For each trust line, the `no_ripple` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the No Ripple flag.
|
||||
Using the HTTP/WebSocket APIs or your preferred [client library](../../../references/client-libraries.md), look up trust lines with the `account_lines method`. For each trust line, the `no_ripple` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the No Ripple flag.
|
||||
|
||||
<!--
|
||||
|
||||
[HTTP / WebSocket APIs](http-websocket-apis.html)
|
||||
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
@@ -98,7 +98,3 @@ Using the [HTTP / WebSocket APIs](http-websocket-apis.html) or your preferred [c
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
parent: concepts.html
|
||||
html: tokens.html
|
||||
blurb: 発行済み通貨の概要と、XRP Ledgerにおけるその特性について説明します。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 発行済み通貨の概要
|
||||
|
||||
XRP Ledgerでは、XRP以外の通貨はすべて**発行済み通貨**とされます。このようなデジタル資産（「イシュアンス」または「IOU」とも呼ばれます）は、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスも（XRP以外の）通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
|
||||
|
||||
発行済み通貨は、同一通貨コードを使用する複数のイシュアーと保有者を通じて「Rippling」されます。これが役立つ場合もありますが、予期しない結果や望ましくない結果が生じることもあります。トラストライン上で[NoRippleフラグ](rippling.html)を使用すれば、トラストラインを通じたRipplingを防ぐことができます。
|
||||
|
||||
XRP Ledgerの分散型取引所では、発行済み通貨対XRPの取引や、発行済み通貨間の取引を行えます。
|
||||
|
||||
一般的なモデルでは、発行済み通貨は、XRP Ledger外部で保有されている通貨またはその他の資産に結び付けられています。通貨のイシュアー（_ゲートウェイ_）は、XRP Ledger外部の通貨を、XRP Ledgerの発行済み通貨の同等の残高と交換するための入出金処理を行います。ゲートウェイの運用方法についての詳細は、[XRP Ledgerのゲートウェイになる](become-an-xrp-ledger-gateway.html)を参照してください。
|
||||
|
||||
XRP Ledgerの発行済み通貨は他の用途にも使えます。たとえば、固定量の通貨をセカンダリアドレスに発行し、イシュアーへキーを譲渡すれば、「イニシャルコインオファリング」（ICO）を作成できます。
|
||||
|
||||
**警告:** ICOは米国では[証券と見なされ、規制対象となる](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings)可能性があります。
|
||||
|
||||
金融サービスビジネスを始める前に、関連規制を調査されることを強くお勧めします。
|
||||
|
||||
## 発行済み通貨の使用方法
|
||||
|
||||
トラストラインは、ゲートウェイの債務を負う意思を明示的に表明するものです。（つまり、「あなたはXRP Ledgerの外部で私からこれだけのお金を借りることができます。」ということです。）
|
||||
|
||||
発行済み通貨の使用方法として想定されるモデルは、信頼できる金融機関である _ゲートウェイ_ で使用することです。ゲートウェイでは、外界の資産を管理し、[複数通貨間の支払い](cross-currency-payments.html)や[分散型取引所](decentralized-exchange.html)での取引のためにXRP Ledgerで使用できるようにします。この流れは以下のようになります。
|
||||
|
||||
1. 顧客がゲートウェイに通貨を送金します。通貨は、法定通貨やBitcoinなど、XRP Ledgerのネイティブ資産でないものが考えられます。
|
||||
2. ゲートウェイは、その通貨を保管して記録します。
|
||||
3. ゲートウェイは、その顧客に属するアドレスに対して、XRP Ledgerでの残高を同じ通貨建てで発行します。
|
||||
4. 顧客は、[複数通貨間の支払い](cross-currency-payments.html)の送金や[分散型取引所](decentralized-exchange.html)での取引などによって、発行済み通貨をXRP Ledgerで自由に使用できます。
|
||||
5. 顧客（必ずしも最初に預金した顧客ではない）は、発行済み通貨をゲートウェイのXRP Ledgerのアドレスに送金します。
|
||||
6. ゲートウェイは、XRP Ledgerの資金の残高を送信した顧客のIDを確認し、対応する金額を _XRP Ledgerの外部で_ その顧客に付与します。
|
||||
|
||||
XRP Ledgerへの「入金」や「出金」のプロセスに関する詳細は、ゲートウェイ、法的管轄、関連する資産のタイプなどの要因に基づいて異なります。
|
||||
|
||||
## 発行済み通貨の特性
|
||||
|
||||
XRP Ledger内の発行済み通貨はすべてトラストラインに存在し、レジャーのデータでは[RippleStateオブジェクト](ripplestate.html)として表示されます。発行済み通貨を作成するには、発行アドレスは、対象となる通貨に対し非ゼロ制限のあるイシュアーへのトラストラインを持つアドレスに対し、[Paymentトランザクション][]を送信します。（発行済み通貨は、このようなトラストラインを通じてRipplingする方法でも作成できます。）発行済み通貨を消去するには、通貨をイシュアーに戻します。
|
||||
|
||||
通貨のイシュアーは、2名の当事者が発行済み通貨で取引をする際に差し引かれる[送金手数料](transfer-fees.html)のパーセンテージを定義できます。
|
||||
|
||||
アドレスは発行済み通貨を[凍結](freezes.html)することもでき、企業が当該地域の金融規制に準拠する際に有用です。この機能が不要で、通貨を凍結しない場合は、アドレスが有する個別のトラストラインを凍結する機能と、Global Freezeを取り消す機能を放棄できます。XRPは凍結できません。
|
||||
|
||||
発行済み通貨は、あらゆる種類の通貨または資産（額面価格が極めて低い、または高いものを含む）に相当するとされています。通貨コードの種類と発行済み通貨の表記の数値制限に関する技術的な詳細は、[通貨フォーマットのリファレンス](currency-formats.html)を参照してください。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [XRP](xrp.html)
|
||||
- [複数通貨間の支払い](cross-currency-payments.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- **チュートリアル:**
|
||||
- [XRP Ledgerゲートウェイの開設](become-an-xrp-ledger-gateway.html)
|
||||
- [トランザクションの結果の確認](look-up-transaction-results.html)
|
||||
- [専門化した支払いタイプの使用](use-specialized-payment-types.html)
|
||||
- **リファレンス:**
|
||||
- [Paymentトランザクション][]
|
||||
- [TrustSetトランザクション][]
|
||||
- [RippleStateオブジェクト](ripplestate.html)
|
||||
- [account_linesメソッド][]
|
||||
- [account_currenciesメソッド][]
|
||||
- [gateway_balancesメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,61 +1,42 @@
|
||||
---
|
||||
html: tokens.html
|
||||
parent: concepts.html
|
||||
blurb: Anyone can make tokens representing digital value on the XRP Ledger.
|
||||
blurb: The XRP Ledger is a blockchain that records transactions of XRP and other tokens between accounts.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Tokens
|
||||
|
||||
All assets other than XRP can be represented in the XRP Ledger as **tokens**. Standard tokens are tracked in relationships called [trust lines](trust-lines-and-issuing.html) between accounts. Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who don't want them. Tokens can represent any type of value, including "stablecoins" backed by assets that exist outside of the ledger, purely digital tokens created specifically on the XRP Ledger, community credit, and more.
|
||||
All assets other than XRP can be represented in the XRP Ledger as **tokens**. Standard tokens are tracked in relationships called [trust lines](trust-lines-and-issuing.html) between accounts. Tokens can represent any type of value, including "stablecoins" backed by assets that exist outside of the ledger, purely digital tokens created specifically on the XRP Ledger, community credit, and more.
|
||||
|
||||
**Note:** Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent.
|
||||
|
||||
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) :not_enabled: for details of the XRP Ledger's native support.
|
||||
Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who do not want them.
|
||||
|
||||
Tokens can used for [cross-currency payments](cross-currency-payments.html) and can be traded in the [decentralized exchange](decentralized-exchange.html).
|
||||
Standard tokens are fungible, meaning all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible.md) for details of the XRP Ledger's native support.
|
||||
|
||||
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling.
|
||||
Tokens can used for [cross-currency payments](../transactions/payments/cross-currency-payments.md) and can be traded in the <!-- * -->decentralized exchange.
|
||||
|
||||
<!-- * [decentralized exchange](../server/decentralized-exchange.md) -->
|
||||
|
||||
## Stablecoins
|
||||
|
||||
A common model for tokens in the XRP Ledger is that an issuer holds assets of equivalent value outside of the XRP Ledger, and issues tokens representing that value on the ledger. This type of issuer is sometimes called a _gateway_ because currency can move into and out of the XRP Ledger through their service. If the assets that back a token use the same amounts and denomination as the tokens in the ledger, that token can be considered a "stablecoin" because—in theory—the exchange rate between that token and its off-ledger representation should be stable at 1:1.
|
||||
|
||||
A stablecoin issuer should offer _deposits_ and _withdrawals_ to exchange the tokens for the actual currency or asset in the world outside the XRP Ledger.
|
||||
|
||||
In practice, the XRP Ledger is a computer system that cannot enforce any rules outside of itself, so stablecoins on the XRP Ledger depend on their issuer's integrity. If you can't count on the stablecoin's issuer to redeem your tokens for the real thing on demand, then you shouldn't expect the stablecoin to retain its value. As a user, you should be mindful of who's issuing the tokens: are they reliable, lawful, and solvent? If not, it's probably best not to hold those tokens.
|
||||
|
||||
For more information on how to run a gateway, see the [Becoming an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html).
|
||||
|
||||
|
||||
## Community Credit
|
||||
|
||||
Another way you can use the XRP Ledger is for "community credit", a system where individuals who know each other can use the XRP Ledger to track who owes who else how much money. A powerful feature of the XRP Ledger is that it can automatically and atomically use these debts to settle payments through [rippling](rippling.html).
|
||||
|
||||
For example, if Asheesh owes Marcus $20, and Marcus owes Bharath $50, Bharath can "pay" Asheesh $20 by canceling that much of Marcus's debt to him in exchange for canceling Asheesh's debt to Marcus. The reverse is also possible: Asheesh can pay Bharath through Marcus by increasing their respective debts. The XRP Ledger can settle complex chains of exchanges like this in a single transaction without the accounts in the middle needing to do anything manually.
|
||||
|
||||
For more on this type of usage, see [paths](paths.html). <!--{# TODO: It would be nice to be able to link to a page with more illustrative examples of community credit. #}-->
|
||||
|
||||
|
||||
## Other Tokens
|
||||
|
||||
There are other use cases for tokens issued in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer.
|
||||
|
||||
**Warning:** ICOs may be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->
|
||||
|
||||
Be sure to research the relevant regulations before engaging in any financial service business.
|
||||
|
||||
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.md#the-no-ripple-flag) on trust lines to prevent those trust lines from rippling.
|
||||
|
||||
## Token Properties
|
||||
|
||||
Tokens in the XRP Ledger are [fundamentally different than XRP](currency-formats.html#comparison). Tokens always exist _in trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the [decentralized exchange](decentralized-exchange.html) or by decreasing the limit after you already have a positive balance.)
|
||||
Tokens in the XRP Ledger are <!--*-->fundamentally different than XRP. Tokens always exist _in trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the <!-- -->decentralized exchange or by decreasing the limit after you already have a positive balance.)
|
||||
|
||||
<!-- * [fundamentally different than XRP](currency-formats.md#comparison) -->
|
||||
<!-- [decentralized exchange](../servers/decentralized-exchange.md) -->
|
||||
|
||||
Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
|
||||
|
||||
Anyone can issue tokens by sending a [Payment transaction][] if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](cross-currency-payments.html) or trades can also create more tokens according to an issuer's settings.
|
||||
Anyone can issue tokens by sending a `Payment` transaction if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](../transactions/payments/cross-currency-payments.md) or trades can also create more tokens according to an issuer's settings.
|
||||
|
||||
Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a [tick size](ticksize.html) for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezes.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
|
||||
Issuers can charge a [transfer fee](transfer-fees.md) that is automatically deducted when users transfer their tokens. Issuers can also define a <!-- * -->tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.md) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
|
||||
|
||||
<!-- * [tick size](ticksize.md) -->
|
||||
|
||||
<!--
|
||||
For a tutorial of the technical steps involved in issuing a token, see [Issue a Fungible Token](issue-a-fungible-token.html).
|
||||
|
||||
|
||||
@@ -77,8 +58,4 @@ For a tutorial of the technical steps involved in issuing a token, see [Issue a
|
||||
- [account_lines method][]
|
||||
- [account_currencies method][]
|
||||
- [gateway_balances method][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
-->
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
html: transfer-fees.html
|
||||
parent: tokens.html
|
||||
blurb: 通貨発行者は、自己の発行済み通貨の送金に手数料を課すことができます。
|
||||
labels:
|
||||
- 手数料
|
||||
- トークン
|
||||
---
|
||||
# 送金手数料
|
||||
|
||||
[XRP Ledgerで通貨を発行する金融機関](become-an-xrp-ledger-gateway.html)は、XRP Ledgerの`TransferRate`設定を使用して、 その金融機関が発行する通貨を送金するユーザーに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づくパーセンテージが引き落とされ、送金先には予定額が入金されます。差額が送金手数料です。送金手数料は発行アドレスの資産となり、XRP Ledgerではこれ以上追跡されません。発行アカウントとの _直接_ の送金と入金には送金手数料は適用されませんが、[運用アドレス][]から別のユーザーへの送金には送金手数料が適用されます。
|
||||
|
||||
[運用アドレス]: issuing-and-operational-addresses.html
|
||||
[発行アドレス]: issuing-and-operational-addresses.html
|
||||
|
||||
XRPにはイシュアーがいないため、送金手数料が発生することはありません。
|
||||
|
||||
たとえばACME BankがACMEイシュアンスの送金手数料を1%に設定するとします。支払いの受取人が2 EUR.ACMEを受領するには、送金元が2.02 EUR.ACMEを送金する必要があります。このトランザクションの後、XRP LedgerのACMEの債務残高は0.02€減少します。つまり、ACMEはそのXRP Ledgerイシュアンスの担保となるアカウントで当該の額を保有する必要がありません。
|
||||
|
||||
次の図は、XRP LedgerによるAliceからCharlieへの2 EUR.ACMEの支払い（送金手数料1%）を示します。
|
||||
|
||||
|
||||
|
||||
## ペイメントパスでの送金手数料
|
||||
|
||||
<!--{# TODO: Update this for OnwerPaysFee amendment when that gets added #}-->
|
||||
|
||||
送金手数料は、各送金においてイシュアンスが発行アカウントを通じて当事者間を移動するたびに適用されます。さらに複雑なトランザクションでは、手数料が複数回適用されます。送金手数料は、送金の終わりの時点から逆方向に適用されるので、最終的には支払いの送金者がすべての手数料をカバーするのに十分な額を送金する必要があります。例:
|
||||
|
||||
|
||||
|
||||
このシナリオでは、ACMEが発行したEURをSalazar（送金元）が保有しており、WayGateが発行した100 USDをRosa（受取人）に送金したいと思っています。FXMakerはオーダーブックで最も良いレート（1 USD.WayGate = 0.9 EUR.ACME）のオファーを提供する通貨取引業者です。もし手数料がなければ、Salazarは90 EURを送金すればRosaに100 USDを送金することができます。しかしながら、ACMEで1%の送金手数料が発生し、WayGateで0.2%の送金手数料が発生します。つまり、次のようになります。
|
||||
|
||||
* Rosaが100 USD.WayGateを受領するには、FXMakerから100.20 USD.WayGateを送金する必要があります。
|
||||
* 100.20 USD.WayGateを送金する場合のFXMakerの現在の買値は90.18 EUR.ACMEです。
|
||||
* FXMakerが90.18 EUR.ACMEを受領するには、Salazarが91.0818 EUR.ACMEを送金する必要があります。
|
||||
|
||||
# 技術詳細
|
||||
|
||||
送金手数料は[発行アドレス][]の設定により表されます。送金手数料には、0%未満の値と100%を超える値は指定できず、0.0000001%の位までで切り捨てられます。TransferRate設定は同一アカウントにより発行されるすべての通貨に適用されます。通貨によって異なる送金手数料のパーセンテージを適用するには、通貨ごとに異なる[発行アドレス][]を使用します。
|
||||
|
||||
**注記:** `rippled` v0.80.0で導入され2017-11-14に有効となった[fix1201 Amendment](amendments.html)により、最大送金手数料は実効限度である約329%（32ビット整数の最大サイズに基づく）から100%に引き下げられました。送金手数料の設定が100%（`TransferRate`が`2000000000`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。
|
||||
|
||||
## rippled
|
||||
|
||||
`rippled`のJSON-RPC APIおよびWebSocket APIでは、送金手数料は`TransferRate`フィールドに10進数で指定され、この数字は受取人が同一通貨を10億単位受領できるよう送金する必要のある額を表します。`TransferRate`が`1005000000`の場合、送金手数料0.5%に相当します。デフォルトでは`TransferRate`は手数料なしに設定されています。`TransferRate`には、`1000000000`（手数料「0%」）未満の値と`2000000000`（手数料「100%」）を上回る値は指定できません。値`0`は手数料なしの特殊なケースであり、`1000000000`に相当します。
|
||||
|
||||
金融機関は、[発行アドレス][]から[AccountSetトランザクション][]を送信して、イシュアンスの`TransferRate`を変更することができます。
|
||||
|
||||
アカウントの`TransferRate`を確認するには、[account_infoメソッド][]を使用します。`TransferRate`が省略されている場合は、手数料はありません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [手数料（曖昧さの回避）](fees.html)
|
||||
- [トランザクションコスト](transaction-cost.html)
|
||||
- [パス](paths.html)
|
||||
- **チュートリアル:**
|
||||
- [XRP Ledgerゲートウェイの開設](become-an-xrp-ledger-gateway.html)
|
||||
- **リファレンス:**
|
||||
- [account_linesメソッド][]
|
||||
- [account_infoメソッド][]
|
||||
- [AccountSetトランザクション][]
|
||||
- [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,11 +1,3 @@
|
||||
---
|
||||
html: transfer-fees.html
|
||||
parent: tokens.html
|
||||
blurb: Token issuers can charge a fee for transferring their tokens.
|
||||
labels:
|
||||
- Fees
|
||||
- Tokens
|
||||
---
|
||||
# Transfer Fees
|
||||
|
||||
[Token](tokens.html) issuers can charge a _transfer fee_ that applies when users transfer those tokens among themselves. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee.
|
||||
@@ -82,9 +74,3 @@ Some [client libraries](client-libraries.html) have convenience functions for ge
|
||||
- [account_info method][]
|
||||
- [AccountSet transaction][]
|
||||
- [AccountRoot Flags](accountroot.html#accountroot-flags)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
|
||||
@@ -1,31 +0,0 @@
|
||||
---
|
||||
html: trust-lines-and-issuing.html
|
||||
parent: tokens.html
|
||||
blurb: トラストラインの特性と根本原理について説明します。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# トラストラインと発行
|
||||
|
||||
XRP Ledgerの[発行済み通貨](issued-currencies.html)は、XRP Ledger外部で _ゲートウェイ_ が保有する価値をしばしば表します。ユーザーがXRP Ledgerの残高をイシュアーに返却して清算するときには、XRP Ledger内でこれらの資金を発行するアドレスが、XRP Ledger外部で残高を払い戻すことが期待されます。
|
||||
|
||||
コンピュータープログラムは外界で約束を守ることを誰にも強制できないため、トラストラインは、イシュアーがあなたの代わりに保有する価値の量として、あなたが信頼できる量を設定する手段となります。信用のある大手金融機関は、お金のないルームメートに比べれば返済能力は高いため、トラストラインごとに異なる限度を設定して、XRP Ledgerでイシュアーがあなたから「借用」できる上限額を指定できます。イシュアーが債務不履行になった場合や、倒産した場合には、XRP Ledgerでの保有残高をその他の等価の資産と交換できなくなるため、設定した上限額まで失う可能性があります。（XRP Ledgerで引き続き発行済み通貨を保持または取引できますが、発行済み通貨に価値があると見なされる理由がなくなる可能性があります。）
|
||||
|
||||
次の2つの場合、残高が限度額を _超過_ しても、トラストラインにその残高を保有できます。[取引](decentralized-exchange.html)によりその通貨をさらに積み増しする場合と、トラストラインの限度を引き下げる場合。
|
||||
|
||||
トラストラインはレジャーのスペースを使用するため、[トラストラインにより、アカウントの準備金として保有する必要のあるXRPが増加します](reserves.html)。これは、信頼を受けているアカウントではなく、信頼を拡大しているアカウントに適用されます。
|
||||
|
||||
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
|
||||
|
||||
## トラストラインの設定
|
||||
|
||||
トラストラインは、レジャーの状態データでは[RippleStateオブジェクト](ripplestate.html)として表されます。1つのRippleStateオブジェクトは、一方向または両方向のトラストラインの可能性を表します。このオブジェクトにはトラストラインのそれぞれのサイドに対する制限やその他の設定が含まれていますが、両サイドは1つの正味残高を共有しています。
|
||||
|
||||
トラストラインの設定がデフォルトの状態である場合、トラストラインがないのと同等です。
|
||||
|
||||
[NoRippleフラグ](rippling.html)（デフォルトの設定はDefaultRippleフラグの設定に応じて異なる）を除き、トラストラインフラグのすべてのフラグは、デフォルトでオフになっています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
html: trust-lines-and-issuing.html
|
||||
parent: tokens.html
|
||||
blurb: Learn about the properties and rationale of trust lines.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
# Trust Lines and Issuing
|
||||
|
||||
Trust lines are structures in the XRP Ledger for holding [tokens](tokens.html). Trust lines enforce the XRP Ledger's rule that you cannot cause someone else to hold a token they don't want. This precaution is necessary to enable the XRP Ledger's use case for [community credit](tokens.html#community-credit) among other benefits.
|
||||
|
||||
Each "trust line" is a _bidirectional_ relationship consisting of:
|
||||
|
||||
- The identifiers for the **two [accounts](accounts.html)** that the trust line connects.
|
||||
- A single, shared **balance**, which is positive from the perspective of one account and negative from the other perspective.
|
||||
- The account with a negative balance is generally considered the "issuer" of the tokens. However, in the [APIs](http-websocket-apis.html), the name `issuer` can refer to either side.
|
||||
- Various **settings** and metadata. _Each_ of the two accounts can control its own settings on the trust line.
|
||||
- Most importantly, each side sets a **limit** on the trust line, which is 0 by default. Each account's balance (from its perspective on the trust line) can't go above that account's limit, except [through that account's own actions](#going-above-the-limit).
|
||||
|
||||
Each trust line is specific to a given [currency code][]. Two accounts can have any number of trust lines between them for different currency codes, but only one shared trust line for any particular currency code.
|
||||
|
||||
|
||||
## Creation
|
||||
|
||||
Any account can unilaterally "trust" another account to issue a token by sending a [TrustSet transaction][] with a nonzero limit and their own settings. This creates a line with a zero balance, and sets the other side's settings to the default.
|
||||
|
||||
Trust lines can be implicitly created by some transactions, such as when you buy a token in the [decentralized exchange](decentralized-exchange.html). In this case, the trust line uses entirely default settings.
|
||||
|
||||
|
||||
## Going Above the Limit
|
||||
|
||||
There are three cases where you can hold a balance that is _greater_ than your limit on that trust line:
|
||||
|
||||
1. When you acquire more of that token through [trading](decentralized-exchange.html).
|
||||
2. When you decrease the limit on a trust line that has a positive balance.
|
||||
3. When you acquire more of that token by [cashing a Check](checks.html). (_Requires the [CheckCashMakesTrustLine amendment][] :not_enabled:_)
|
||||
|
||||
|
||||
## Trust Line Settings
|
||||
|
||||
In addition to the shared balance, each account has its own settings on the trust line, which consist of the following:
|
||||
|
||||
- The **Limit**, a number from 0 to the [maximum token amount](currency-formats.html). Payments and other accounts' actions cannot cause the trust line's balance (from this account's perspective) to go over the limit. The default is `0`.
|
||||
- **Authorized**: A true/false value used with [Authorized Trust Lines](authorized-trust-lines.html) to allow the other side to hold tokens this account issues. The default is `false`. Once set to `true`, this cannot be changed back.
|
||||
- **No Ripple**: A true/false value to control whether tokens can [ripple](rippling.html) through this trust line. The default depends on the account's "Default Ripple" setting; for new accounts, "Default Ripple" is off which means that `true` is the default for No Ripple. Usually, issuers should allow rippling and non-issuers should disable rippling unless they are using trust lines for community credit.
|
||||
- **Freeze**: A true/false value indicating whether an [individual freeze](freezes.html#individual-freeze) is in effect on this trust line. The default is `false`.
|
||||
- **Quality In** and **Quality Out** settings, which allow the account to value tokens issued by the other account on this trust line at less (or more) than face value. For example, if a stablecoin issuer charges a 3% fee for withdrawing tokens for the equivalent off-ledger assets, you could use these settings to value those tokens at 97% of face value. The default, `0`, represents face value.
|
||||
|
||||
|
||||
## Reserves and Deletion
|
||||
|
||||
Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](reserves.html). Either or both accounts in the trust line may be charged the reserve for the trust line, depending on the status of the trust line: if any of your settings are not the default, or if you hold a positive balance, it counts as one item toward your owner reserve.
|
||||
|
||||
Generally, this means that the account that created the trust line is responsible for the reserve and the issuer is not.
|
||||
|
||||
Trust lines are automatically deleted if both sides' settings are in the default state and the balance is 0. This means that, to delete a trust line, you need to:
|
||||
|
||||
1. Send a [TrustSet transaction][] to set your settings to the defaults.
|
||||
2. Offload any positive balance you have on the trust line. You could do this by sending a [payment](cross-currency-payments.html), or by selling the currency in the [decentralized exchange](decentralized-exchange.html).
|
||||
|
||||
If your balance is negative (you are the issuer) or the other side's settings are not in the default state, you cannot cause the trust line to be totally deleted, but you can make it so that it does not count towards your owner reserve by following the same steps.
|
||||
|
||||
Since the **Authorized** setting cannot be turned off after it has been turned on, it does not count toward the trust line's default state.
|
||||
|
||||
### Free Trust Lines
|
||||
[[Source]](https://github.com/ripple/rippled/blob/72377e7bf25c4eaee5174186d2db3c6b4210946f/src/ripple/app/tx/impl/SetTrust.cpp#L148-L168)
|
||||
|
||||
Since trust lines are a powerful feature of the XRP Ledger, there is a special feature to make an account's first two trust lines "free".
|
||||
|
||||
When an account creates a new trust line, if the account owns at most 2 items in the ledger including the new line, the account's owner reserve is treated as zero instead of the normal amount. This allows the transaction to succeed even if the account does not hold enough XRP to meet the increased reserve requirement for owning objects in the ledger.
|
||||
|
||||
When an account owns 3 or more objects in the ledger, the full owner reserve applies.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Decentralized Exchange](decentralized-exchange.html)
|
||||
- [Rippling](rippling.html)
|
||||
- **Tutorials:**
|
||||
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
|
||||
- **References:**
|
||||
- [account_lines method][] - Look up trust lines attached to a given account
|
||||
- [gateway_balances method][] - Look up an issuer's total balance issued
|
||||
- [RippleState object](ripplestate.html) - The data format for trust lines in the ledger's state data.
|
||||
- [TrustSet transaction][] - The transaction to create or modify trust lines.
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Reference in New Issue
Block a user