ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 09:18:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Reword content articles to use "tokens"

Browse Source 
This replaces the old wording of "issued currencies" and introduces
broader usage of the term "stablecoins" to more closely match the
terminology in use by the wider industry.

I've also added a draft "Common Misunderstandings about Freezes" page so
that the Freeze page doesn't have to protest quite so much, and written
a very brief word on tokens' use for community credit.

This commit only covers the Concepts section, in English, and likely
leaves some links to the old URLs for the renamed pages.
This commit is contained in:
mDuo13
2022-02-11 17:58:39 -08:00
parent d0dd8e75b0
commit a6d9b53b61
25 changed files with 445 additions and 368 deletions
Download Patch File Download Diff File Expand all files Collapse all files

112
content/concepts/tokens/authorized-trust-lines.ja.md Normal file
View File

@@ -0,0 +1,112 @@
---
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' %}

136
content/concepts/tokens/authorized-trust-lines.md Normal file
View File

@@ -0,0 +1,136 @@
---
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.)
The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address.
**Caution:** You can only enable `RequireAuth` if your account has no trust lines and no Offers in the XRP Ledger, so you must decide whether or not to use it _before_ you start issuing tokens.
## With Stablecoin Issuing
With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process of onboarding a new customer might look something like the following:
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.
**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 a purely precautionary measure, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
## Technical Details
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
### 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.)
Request:
```json
POST http://localhost:5005/
{
"method": "submit",
"params": [
{
"secret": "s████████████████████████████",
"tx_json": {
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
"Fee": "15000",
"Flags": 0,
"SetFlag": 2,
"TransactionType": "AccountSet"
}
}
]
}
```
{% 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).
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.
## Authorizing Trust Lines
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.
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:
```json
POST http://localhost:8088/
{
"method": "submit",
"params": [
{
"secret": "s████████████████████████████",
"tx_json": {
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"Fee": "15000",
"TransactionType": "TrustSet",
"LimitAmount": {
"currency": "USD",
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"value": 0
},
"Flags": 65536
}
}
]
}
```
{% 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.
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:**
- [Deposit Authorization](depositauth.html)
- [Freezing Issued Currencies](freezes.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.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' %}

32
content/concepts/tokens/common-misconceptions-about-freezes.md Normal file
View File

@@ -0,0 +1,32 @@
---
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.

126
content/concepts/tokens/demurrage.ja.md Normal file
View File

@@ -0,0 +1,126 @@
---
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ビット通貨コードを使用します。
![通貨コード形式を削除する](img/demurrage-currency-code-format.png)
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" }
```

127
content/concepts/tokens/demurrage.md Normal file
View File

@@ -0,0 +1,127 @@
---
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#issued-currency-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:
![Demurraging Currency Code Format](img/demurrage-currency-code-format.png)
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" }
```

97
content/concepts/tokens/freezes.ja.md Normal file
View File

@@ -0,0 +1,97 @@
---
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' %}

104
content/concepts/tokens/freezes.md Normal file
View File

@@ -0,0 +1,104 @@
---
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 issued currencies 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' %}

77
content/concepts/tokens/issuing-and-operational-addresses.ja.md Normal file
View File

@@ -0,0 +1,77 @@
---
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)](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' %}

88
content/concepts/tokens/issuing-and-operational-addresses.md Normal file
View File

@@ -0,0 +1,88 @@
---
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' %}

83
content/concepts/tokens/non-fungible-tokens.md Normal file
View File

@@ -0,0 +1,83 @@
---
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, also known as _IOUs_ or [_issued currencies_](issued-currencies.html). 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.
![Jenny Stamps](img/nft-concepts1.png "Jenny Stamps")
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.
![Jenny Stamps](img/nft-concepts2.png "Jenny Stamps")
Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
The XRPL Labs team has created a framework that supports non-fungible tokens (NFTs, or “nifties” in the vernacular). 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.
## NFT Extensions
Extensions to the XRP Ledger support two new objects and a new ledger structure.
The [NFToken][] is a native NFT type. It has operations to enumerate, purchase, sell, and hold such tokens. An `NFToken` is a unique, indivisible unit that is not used for payments.
The [NFTokenPage object][] contains a set of `NFToken` objects owned by the same account.
You create a new `NFToken` using the [NFTokenMint transaction][].
[NFTokenOffer object][] is a new object that describes an offer to buy or sell a single `NFToken`.
You destroy an `NFToken` using the [NFTokenBurn transaction][].
## `NFToken` Lifecycle
You create a NFT using the `NFTokenMint` transaction. The `NFToken` lives on the `NFTokenPage` of the issuing account. You can create an `NFTokenOffer` to sell the `NFToken`, creating an entry to the XRP Ledger. Another account can accept the `NFTokenOffer`, transferring the `NFToken` to the accepting account’s `NFTokenPage`. If the `lsfTransferable `flag is set to _true_ (0x000008) when the `NFToken` is minted, the `NFToken` can be traded multiple times between accounts. The `NFToken` can be permanently destroyed by its owner using the `NFTokenBurn` transaction.
![The NFT Lifecycle](img/nft-lifecycle.png "NFT Lifecycle Image")
## 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`
* `nft_sell_offers`
* `nft_buy_offers`
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

118
content/concepts/tokens/paths.ja.md Normal file
View File

@@ -0,0 +1,118 @@
---
html: paths.html
parent: tokens.html
blurb: 発行済み通貨の支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。
labels:
- 支払い
- 複数通貨間
---
# パス
XRP Ledgerでは、[発行済み通貨](issued-currencies-overview.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)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
[![3つのパスの例を示す図](img/paths-examples.ja.png)](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で使用する特殊なイシュアーの値)を参照してください。
* トランザクションの`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)](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' %}

121
content/concepts/tokens/paths.md Normal file
View File

@@ -0,0 +1,121 @@
---
html: paths.html
parent: tokens.html
blurb: Payments of issued currencies 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.
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.
## Path Steps
A path is made of steps that connect the sender to the receiver of the payment. Every step is either:
* 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.
[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 -->
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.
{{ include_svg("img/paths-examples.svg", "Diagram of three example paths") }}
# Technical Details
## 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.
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.
**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.
Finding paths is a very challenging problem that changes slightly every few seconds as new ledgers are validated, so `rippled` is not designed to find the absolute best path. Still, you can find several possible paths and estimate the cost of delivering a particular amount.
## 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:
* 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 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.
## Default Paths
In addition to explicitly specified paths, a transaction can execute along the _default path_. The default path is the simplest possible way to connect the [implied steps](#implied-steps) of the transaction.
The default path could be any of the following:
* If the transaction is uses only one token (regardless of issuer), then the default path assumes the payment should ripple through the addresses involved. This path only works if those addresses are connected by trust lines.
* If `SendMax` is omitted, or the `issuer` of the `SendMax` is the sender, the default path needs a trust line from the sending `Account` to the `issuer` of the destination `Amount` to work.
* If the `SendMax` and `Amount` have different `issuer` values, and neither are the sender or receiver, the default path is probably not useful because it would need to ripple across a trust line between the two issuers. Ripple (the company) typically discourages issuers from trusting one another directly.
* For cross-currency transactions, the default path uses the order book between the source currency (as specified in the `SendMax` field) and the destination currency (as specified in the `Amount` field).
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.
## Path Specifications
A path set is an array. Each member of the path set is another array that represents an individual _path_. Each member of a path is an object that specifies the step. A step has the following fields:
| Field | Value | Description |
|:-----------|:-----------------------|:---------------------------------------|
| `account` | String - Address | _(Optional)_ If present, this path step represents rippling through the specified address. MUST NOT be provided if this step specifies the `currency` or `issuer` fields. |
| `currency` | String - Currency Code | _(Optional)_ If present, this path step represents changing currencies through an order book. The currency specified indicates the new currency. MUST NOT be provided if this step specifies the `account` field. |
| `issuer` | String - Address | _(Optional)_ If present, this path step represents changing currencies and this address defines the issuer of the new currency. If omitted in a step with a non-XRP `currency`, a previous step of the path defines the issuer. If present when `currency` is omitted, indicates a path step that uses an order book between same-named currencies with different issuers. MUST be omitted if the `currency` is XRP. MUST NOT be provided if this step specifies the `account` field. |
| `type` | Integer | **DEPRECATED** _(Optional)_ An indicator of which other fields are present. |
| `type_hex` | String | **DEPRECATED**: _(Optional)_ A hexadecimal representation of the `type` field. |
In summary, the following combination of fields are valid, optionally with `type`, `type_hex`, or both:
- `account` by itself
- `currency` by itself
- `currency` and `issuer` as long as the `currency` is not XRP
- `issuer` by itself
Any other use of `account`, `currency`, and `issuer` fields in a path step is invalid.
The `type` field, used for the binary serialization of a path set, is actually constructed through bitwise operations on a single integer. The bits are defined as follows:
| Value (Hex) | Value (Decimal) | Description |
|-------------|-----------------|-------------|
| `0x01` | 1 | A change of address (rippling): the `account` field is present. |
| `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:**
- [Cross-Currency Payments](cross-currency-payments.html)
- [Decentralized Exchange](decentralized-exchange.html)
- [Partial Payments](partial-payments.html)
- **References:**
- [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' %}

105
content/concepts/tokens/rippling.ja.md Normal file
View File

@@ -0,0 +1,105 @@
---
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ではトラストラインは次のようになります:
![Charlie --（$10）-- Alice -- （$20） -- Bob](img/noripple-01.png)
BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
![Charlie --（$13）-- Alice --（$17）-- Bob](img/noripple-02.png)
2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
## NoRippleフラグ
発行アカウント以外のアカウント、特に手数料やポリシーが異なる複数のイシュアーの残高を保有している流動性プロバイダーは、一般的に残高がRipplingされることを望みません。
「NoRipple」フラグは、トラストライン上の設定です。2つのトラストラインの両方で、同じアドレスによってNoRippleが有効に設定されている場合、第三者からの支払を、これらのトラストラインでこのアドレスを通じて「Rippling」することはできません。これにより、同一通貨の複数イシュアー間で流動性プロバイダーの残高が予期せず移動されるのを防ぎます。
アカウントは1つのトラストラインでNoRippleを無効にできます。これにより、そのトラストラインを含む任意のペアを通じてのRipplingが可能になります。アカウントにてデフォルトでRipplingを有効にするには、[DefaultRippleフラグ](#defaultrippleフラグ)を有効にします。
たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
![Charlie --（$10）-- 金融機関A --（$1）-- Emily --（$100）-- 金融機関B --（$2）-- Daniel](img/noripple-03.png)
CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
![Charlie --（$0）-- 金融機関A --（$11）-- Emily --（$90）-- 金融機関B --（$12）-- Daniel](img/noripple-04.png)
この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
例:
![Charlie --（$10）-- 金融機関A --（$1、NoRipple）-- Emily --（$100、NoRipple）-- 金融機関B --（$2）-- Daniel](img/noripple-05.png)
このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
### 詳細
NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
![処理を行うためには同一アドレスによって両方のトラストラインにNoRippleが設定されている必要があることを示す図](img/noripple-06.png)
## 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](rippled-api.html)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
### NoRippleステータスの確認
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
[`rippled` API](rippled-api.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' %}

104
content/concepts/tokens/rippling.md Normal file
View File

@@ -0,0 +1,104 @@
---
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.
Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) 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).
**Caution:** When you create a trust line, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line.
## Example of Rippling
"Rippling" occurs when more than one trust line is adjusted to make a payment. For example, if Alice owes Charlie money, and Alice also owes Bob money, then you could represent that in the XRP Ledger with trust lines like so:
{{ include_svg("img/noripple-01.svg", "Charlie --($10)-- Alice -- ($20) -- Bob") }}
If Bob wants to pay $3 to Charlie, then he could say, "Alice, take $3 of the money you owe me, and pay it to Charlie." Alice transfers some of the debt from Bob to Charlie. In the end, the trust lines work out like so:
{{ include_svg("img/noripple-02.svg", "Charlie --($13)-- Alice --($17)-- Bob") }}
We call this process, where two addresses pay each other by adjusting the balances of trust lines in between them, "rippling". This is a useful and important feature of the XRP Ledger. Rippling occurs when addresses are linked by trust lines that use the same [currency code][]. The issuer does not need to be the same: in fact, larger chains always involve changing issuers.
## The No Ripple Flag
Non-issuing accounts, especially liquidity providers who may hold balances from different issuers with different fees and policies, usually do not want their balances to ripple.
The **No Ripple** flag is a setting on a trust line. When two trust lines both have No Ripple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers using the same currency code.
An account can disable No Ripple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag).
For example, imagine Emily has money issued by two different financial institutions, like so
{{ include_svg("img/noripple-03.svg", "Charlie --($10)-- Institution A --($1)-- Emily --($100)-- Institution B --($2)-- Daniel") }}
Now Charlie can pay Daniel by rippling through Emily's address. For example, if Charlie pays Daniel $10:
{{ include_svg("img/noripple-04.svg", "Charlie --($0)-- Institution A --($11)-- Emily --($90)-- Institution B --($12)-- Daniel") }}
This may surprise Emily, who does not know Charlie or Daniel. Even worse, if Institution A charges her higher fees to withdraw her money than Institution B, this could cost Emily money. The No Ripple flag exists to avoid this scenario. If Emily sets it on both trust lines, then payments cannot ripple through her address using those two trust lines.
For example:
{{ include_svg("img/noripple-05.svg", "Charlie --($10)-- Institution A --($1, No Ripple)-- Emily --($100, No Ripple)-- Institution B --($2)-- Daniel") }}
Now the above scenario, where Charlie pays Daniel while rippling through Emily's address, is no longer possible.
### Specifics
The No Ripple flag makes certain paths invalid, so that they cannot be used to make payments. A path is considered invalid if and only if it enters **and** exits an address node through trust lines where No Ripple has been enabled for that address.
{{ include_svg("img/noripple-06.svg", "Diagram demonstrating that No Ripple has to be set on both trust lines by the same address to do anything") }}
## The Default Ripple Flag
The **Default Ripple** flag is an account setting that enables rippling on all _incoming_ trust lines by default. Issuers MUST enable this flag for their customers to be able to send tokens to each other.
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).
## Using No Ripple
<!--{# TODO: move these things into their own tutorials #}-->
### Enabling / Disabling No Ripple
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.
### 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](rippled-api.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.
## See Also
- **Concepts:**
- [Paths](paths.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.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' %}

69
content/concepts/tokens/tokens.ja.md Normal file
View File

@@ -0,0 +1,69 @@
---
parent: concepts.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' %}

82
content/concepts/tokens/tokens.md Normal file
View File

@@ -0,0 +1,82 @@
---
parent: concepts.html
blurb: Anyone can make tokens representing digital value on the XRP Ledger.
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) 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.
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.
Tokens can used for [cross-currency payments](cross-currency-payments.html) and can be traded in the [decentralized exchange](decentralized-exchange.html).
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.
## 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 pays 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 issued currencies 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.
## 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 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.
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.)
For a tutorial of the technical steps involved in issuing a token, see [Issue a Fungible Token](issue-a-fungible-token.html).
## See Also
- **Concepts:**
- [XRP](xrp.html)
- [Cross-Currency Payments](cross-currency-payments.html)
- [Decentralized Exchange](decentralized-exchange.html)
- **Tutorials:**
- [Issue a Fungible Token](issue-a-fungible-token.html)
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Use Specialized Payment Types](use-specialized-payment-types.html)
- **References:**
- [Payment transaction][]
- [TrustSet transaction][]
- [RippleState object](ripplestate.html)
- [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' %}

71
content/concepts/tokens/transfer-fees.ja.md Normal file
View File

@@ -0,0 +1,71 @@
---
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%）を示します。
![Aliceが2,02€を送金し、Charlieが2,00€を受領し、XRP LedgerでのACMEの負債が0,02€減少します](img/e2g-with_transferrate.png)
## ペイメントパスでの送金手数料
<!--{# TODO: Update this for OnwerPaysFee amendment when that gets added #}-->
送金手数料は、各送金においてイシュアンスが発行アカウントを通じて当事者間を移動するたびに適用されます。さらに複雑なトランザクションでは、手数料が複数回適用されます。送金手数料は、送金の終わりの時点から逆方向に適用されるので、最終的には支払いの送金者がすべての手数料をカバーするのに十分な額を送金する必要があります。例:
![手数料が適用された複数通貨間の支払いの図](img/transfer_fees_example.png)
このシナリオでは、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' %}

90
content/concepts/tokens/transfer-fees.md Normal file
View File

@@ -0,0 +1,90 @@
---
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.
For standard tokens, the tokens paid in the transfer fee are burned, and no longer tracked in the XRP Ledger. If the token is backed by off-ledger assets, this reduces the amount of those assets the issuer has to hold in reserve to meet its obligations in the XRP Ledger. Transfer fees are usually not appropriate for tokens that aren't backed with outside assets.
Non-fungible tokens :not_enabled: can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.
[operational address]: issuing-and-operational-addresses.html
[issuing address]: issuing-and-operational-addresses.html
XRP never has a transfer fee, because it never has an issuer.
## Example
In this example, ACME Bank issues a EUR stablecoin on the XRP Ledger. ACME Bank might set the transfer fee to 1%. For the recipient of a payment to get 2 EUR.ACME, the sender must send 2.02 EUR.ACME. After the transaction, ACME's outstanding obligations in the XRP Ledger have decreased by 0.02€, which means that ACME no longer needs to hold that amount in the bank account backing its EUR stablecoin.
The following diagram shows an XRP Ledger payment of 2 EUR.ACME from Alice to Charlie with a transfer fee of 1%:
{{ include_svg("img/transfer-fees.svg", "Alice sends 2,02€, Charlie receives 2,00€, and ACME owes 0,02€ less in the XRP Ledger") }}
In accounting terms, Alice's, ACME's, and Charlie's balance sheets may have changed like this:
{{ include_svg("img/transfer-fees-balance-sheets.svg", "Alice's assets are down 2,02€, Charlie's are up 2,00€, and ACME's liabilities are down 0,02€") }}
## Transfer Fees in Payment Paths
<!--{# TODO: Update this for OwnerPaysFee amendment when that gets added #}-->
A transfer fee applies whenever an individual transfer would move tokens from one party to another (except when going to/from the issuing account directly). In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example:
{{ include_svg("img/transfer-fees-in-paths.svg", "Diagram of cross-currency payment with transfer fees") }}
In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to deliver 100 USD issued by WayGate to Rosa (the recipient). FXMaker is a trader with the best offer in the order book, at a rate of 1 USD.WayGate for every 0.9 EUR.ACME. If there were no transfer fees, Salazar could deliver 100 USD to Rosa by sending 90 EUR. However, ACME has a transfer fee of 1% and WayGate has a transfer fee of 0.2%. This means:
* FXMaker must send 100.20 USD.WayGate for Rosa to receive 100 USD.WayGate.
* FXMaker's current ask is 90.18 EUR.ACME to send 100.20 USD.WayGate.
* For FXMaker to receive 90.18 EUR.ACME, Salazar must send 91.0818 EUR.ACME.
<!-- SPELLING_IGNORE: waygate, fxmaker -->
# Technical Details
The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The transfer fee applies to all tokens issued by the same account. If you want to have different transfer fees for different tokens, use multiple [issuing addresses][issuing address].
In the [XRP Ledger protocol](protocol-reference.html), the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same token. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` ("0%" fee) or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`.
A token issuer can submit an [AccountSet transaction][] from its [issuing address][] to change the `TransferRate` for all its tokens.
Anyone can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.
**Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% (a `TransferRate` of `2000000000`) from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% because transfer fees that were already set continue to apply at their stated rate.
## Client Library Support
Some [client libraries](client-libraries.html) have convenience functions for getting and setting `TransferRate` functions.
**JavaScript:** Use `xrpl.percentToTransferRate()` to convert a percentage transfer fee from a string to the corresponding `TransferRate` value.
## See Also
- **Concepts:**
- [Fees (Disambiguation)](fees.html)
- [Transaction Cost](transaction-cost.html)
- [Paths](paths.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- **References:**
- [account_lines method][]
- [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' %}

31
content/concepts/tokens/trust-lines-and-issuing.ja.md Normal file
View File

@@ -0,0 +1,31 @@
---
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' %}

48
content/concepts/tokens/trust-lines-and-issuing.md Normal file
View File

@@ -0,0 +1,48 @@
---
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
[Tokens](tokens.html) in the XRP Ledger are often "stablecoins" backed by value held by the issuer in the world outside the XRP Ledger. The is expected to pay the equivalent amount back, outside of the XRP Ledger, when users redeem their stablecoins by returning them to the issuer in the XRP Ledger. In other cases, XRP Ledger tokens represent community credit that can be swapped between people within relatively small limits.
Since a computer program cannot force a someone to keep a promise in the outside world, trust lines represent a way of configuring how much you trust an issuer to hold on your behalf. Since a large, reputable financial institution is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuer "owe" you in the XRP Ledger. If the issuer defaults or goes out of business, you can lose up to that much money because the tokens you hold in the XRP Ledger can no longer be exchanged for equivalent balances elsewhere. (You can still keep or trade those tokens within the XRP Ledger, but there is probably no longer any reason to consider that token to be worth anything.)
There are three cases where you can hold a balance on a trust line that is _greater_ than your limit:
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:_)
Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](reserves.html). This applies to the account extending trust, not to the account receiving it.
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 trust line in either direction for any given currency code.
## Trust Line Settings
Trust lines are represented in the ledger's state data as [RippleState objects](ripplestate.html). A single RippleState object represents the potential for a trust line in either direction or both: it has a limit and settings for each side, but a single shared net balance between the two sides.
A trust line with settings in the default state is equivalent to no trust line.
The default state of all trust line flags is off, except for the [No Ripple flag](rippling.html), whose default state depends on the Default Ripple flag.
## 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][]
- [gateway_balances method][]
- [RippleState (trust line) object](ripplestate.html)
- [TrustSet transaction][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}