ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-28 15:45:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: rename deprecated i18n to l10n

Browse Source
This commit is contained in:
Vova Rutskyi
2024-09-23 15:13:11 +03:00
committed by amarantha-k
parent 6cbb3a036f
commit 9a0c010600
502 changed files with 984 additions and 122 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
@l10n/ja/docs/concepts/tokens/decentralized-exchange/autobridging.md Normal file
View File

@@ -0,0 +1,29 @@
---
html: autobridging.html
parent: decentralized-exchange.html
seo:
description: オートブリッジングは、コストが下がる場合はXRPを仲介として使用してオーダーブックを自動的に接続します。
labels:
- XRP
- 分散型取引所
---
# オートブリッジング
XRP Ledgerの[分散型取引所](index.md)で、XRP以外の2種類の通貨を交換する[オファー](offers.md)があった場合、合成されたオーダーブックで[XRP](../../../introduction/what-is-xrp.md)が中間通貨として使用されることがあります。これは _オートブリッジング_ によるものです。この機能は、通貨を直接交換するよりも安く済む場合にXRPを使用し、あらゆる通貨ペアの流動性を向上させる役割を担います。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。XRP Ledgerのオートブリッジングシステムは、あるトレーダーからXRPをGBPで購入し、そのXRPを別のトレーダーに支払ってBRLを購入することで、Anitaのオファーを履行できる方法を見つけます。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_
オートブリッジングは、あらゆる[OfferCreateトランザクション][]で自動的に行われます。[Paymentトランザクション](../../../references/protocol/transactions/types/payment.md)ではオートブリッジングはデフォルトでは _行われません_ が、path-findingにより同様の効果のある[パス](../fungible-tokens/paths.md)を検索できます。
[![オートブリッジングによる直接注文と合成注文の組み合わせを示す図](/docs/img/autobridging.png)](/docs/img/autobridging.png)
## 関連項目
- [開発者ブログ: オートブリッジング](https://xrpl.org/blog/2014/introducing-offer-autobridging.html)
- [オファーの優先度](offers.md#オファーの優先度)
- [ペイメントパス](../fungible-tokens/paths.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

136
@l10n/ja/docs/concepts/tokens/decentralized-exchange/automated-market-makers.md Normal file
View File

@@ -0,0 +1,136 @@
---
seo:
description: 自動マーケットメーカー（AMM）は、資産ペア間の流動性を提供し、分散型取引所のオーダーブックを補完すると同時に、流動性提供者に利益を提供します。
labels:
- XRP
- 分散型取引所
- AMM
---
# 自動マーケットメーカー(AMM)とは?
_([AMM amendment][]により追加されました。)_
自動マーケットメーカー(AMM)は、XRP Ledgerの分散型取引所において流動性を提供します。個々のAMMは2つの資産のプールを保有します。ユーザは数式で定められた取引レートによりその2つの資産間でスワップが可能です。
![自動マーケットメーカー](/docs/img/cpt-amm.png)
資産をAMMに預ける人は、_流動性供給者(LP/Liquidity Provider)_ と呼ばれます。その対価として流動性供給者はAMMからLPトークンを受け取ります。
![流動性提供者によるLPトークンの受け取り](/docs/img/cpt-amm-lp-receiving-lpts.png)
流動性供給者はLPトークンを利用して以下のことが可能になります。
- LPトークンを、AMMのプール内の資産の一部（プールが得た手数料を含む）と交換する。
- AMMの手数料設定を変更するために投票する。票は、投票者が保有するLPトークンの数に基づいて重み付けされます。
- AMMの取引手数料の一時的な割引を得るために、LPトークンの一部を入札する。
## AMMの仕組み
AMMは2つの異なる資産を保有します。そのうちの最大1つはXRPとすることができ、そのうちの1つまたは両方が[トークン](../index.md)であることができます。
任意の資産ペアに対して、レジャーには最大1つのAMMが存在することができます。存在しない場合、誰でもその資産ペアのAMMを作成することができます。また、すでに存在している場合、AMMに預け入れることができます。
分散型取引所で取引を行う場合、[オファー](offers.md)と[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)は、自動的にAMMを使用して取引を成立させることができます。単一の取引は、オファー、AMM、またはその両方の組み合わせによって、よりコストが低い方法で実行されることになります。
![オファーやAMMまたはその両方を利用する1つの取引](/docs/img/cpt-amm-or-offer.png)
{% admonition type="info" name="注記" %}
`Payment`または`OfferCreate`トランザクションがAMMとやり取りしたかどうかは、トランザクションメタデータにある[`RippleState`](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)レジャーエントリを確認することで判断できます。`Flags`値が`16777216`の場合、AMMの流動性が消費されたことを示します。
{% /admonition %}
AMMは、プール内の資産残高に基づき取引レートを設定します。AMMに対して取引を行うと、AMMが保有する資産残高の変動に応じて、取引レートが調整されます。一方の資産の量が減れば、その資産の価格が上がり、他方の資産の量が増えれば、その資産の価格が下がります。
![資産残高が増えると価格が下がり、資産残高が減ると価格が上がる](/docs/img/cpt-amm-balance.png)
AMMは、プール内の資産残高が多いほど、一般的により良い取引レートを提供します。同一取引であればプール内の残高が大きい方がAMMの資産バランスに生じる変化は小さくなるからです。AMMの2つの資産のバランスが崩れれば崩れるほど、交換レートは極端に悪化します。
また、AMMは交換レートに加え、一定割合の取引手数料を徴収しています。
XRP Ledgerの実装は、重みパラメータを0.5とした _幾何平均_ AMMですので、_定積_ マーケットメーカーのように機能します。 _定積_ AMMの公式や一般的なAMMの経済学についての詳しい説明は、[Kris Machowski's Introduction to Automated Market Makers](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/)をご覧ください。
### トークン発行者
発行者が異なるトークンは異なる資産と見なされます。つまり、同じ通貨コードで異なる発行者の2つのトークンに対してAMMを作成することができます。例えば、WayGateによって発行された _FOO_ は、StableFooによって発行された _FOO_ とは異なるトークンです。同様に、トークンは同じ発行者で異なる通貨コードを持つことができます。取引方向は関係ありません。FOO.WayGateからXRPへのAMMは、XRPからFOO.WayGateへのAMMと同じです。
### 資産の制限
資産間の資金の流れが比較的活発でバランスが取れている場合、手数料は流動性供給者に対する受動的な収入源となります。しかし、資産間の相対価格が変動すると、流動性供給者は[通貨リスク](https://www.investopedia.com/terms/c/currencyrisk.asp)による損失を被ることになります。
### 資産の制限 <a id="restrictions-on-assets"></a>
不正利用を防ぐため、AMMで利用できる資産にはいくつかの制限があります。これらの制約を満たさない資産でAMMを作成しようとすると、トランザクションは失敗します。ルールは以下のとおりです。
- 他のAMMのLPTokenをAMMの資産として利用することはできません。
- 資産が、発行者が[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)を使用しているトークンである場合、AMMの作成者はそれらのトークンを保有する権限がなければなりません。認可されているトラストラインだけが、そのトークンをAMMに預けたり引き出したりすることができます。
- [Clawback Amendment][] が有効な場合、Clawbackが有効なトークンでAMMを作成することはできません。
## LPトークン
AMMの作成者は、最初の流動性供給者となり、AMMのプール内の資産の100％の所有権を表すLPトークンを受け取ります。LPトークンの一部または全部を交換して、現在のプール残高に比例した資産をAMMから引き出せます。(この比率は、人々がAMMに対して取引を行うにつれて変化します）AMMは、同時に両方の資産を引き出す際に手数料はかかりません。
例えば、5ETHと5USDでAMMを作成し、その後誰かが1.26USDを1ETHに交換したとすると、現在プールには4ETHと6.26USDが入っています。LPトークンの半分を使用して、2ETHと3.13USDを引き出すことができます。
![AMMとの取引とLPトークンの引き出しの例](/docs/img/cpt-amm-lp-tokens.png)
誰でも既存のAMMに資産を預けることができます。預け入れると、その金額に応じて新しいLPトークンを受け取ります。流動性供給者がAMMから引き出すことができる金額は、発行済みのLPトークンの総数に対する流動性提供者のLPトークンの保有割合に基づきます。
LPトークンはXRP Ledgerの他のトークンと同様に、様々な種類の支払いで使用したり、分散型取引所で取引したり、新しいAMMの資産として預けることも可能です。(LPトークンを支払い(Payment)として受け取るには、AMMアカウントを発行元として、限度額が0でない[トラストライン](../fungible-tokens/index.md)を設定する必要があります)。ただし、LPトークンをAMMに直接送る(換金する)には[AMMWithdraw][]トランザクションタイプを使用し、他のタイプの支払いは使用できません。同様に、AMMのプールに資産を送るには、[AMMDeposit][]トランザクションタイプを使用する必要があります。
AMMは、発行済のLPトークンがない場合に限り、AMMの資産プールが空になるように設計されています。こうした状況は、[AMMWithdraw][]トランザクションの結果としてのみ発生し、発生した時点でAMMは自動的に削除されます。
### LPトークンの通貨コード
LPトークンは、160ビットの16進法["非標準"フォーマット](../../../references/protocol/data-types/currency-formats.md#非標準通貨コード)の特別なタイプの通貨コードを使用します。これらのコードの最初の8ビットは`0x03`です。残りのコードは、2つの資産の通貨コードとその発行者のSHA-512ハッシュで、最初の152ビットまで切り捨てたものです。(資産は、数値の低い通貨と発行者のペアを最初にする「正規化された順序」で配置されます。)その結果、LPトークンは、通貨と発行者のペアを最初にする「正規化された順序」で配置されます。その結果、ある資産ペアのAMMのLPトークンは、予測可能で一貫した通貨コードを持っています。
## 取引手数料
取引手数料は流動性供給者の収益源であり、プールの資産に対して他者に取引をさせることによる為替リスクを相殺するものであり、取引手数料は流動性提供者に直接支払われずにAMMに支払われます。流動性供給者は自分のLPトークンをAMMのプールの一定割合と交換することができるため、利益を得ることができます。
流動性供給者は、投票によって取引手数料を0％から1％まで、0.001％刻みで設定することが出来ます。流動性供給者は取引手数料を適切に設定するインセンティブがあり、手数料が高すぎる場合、トレーダーはより良いレートを得るために代わりにオーダーブックを使用することになります。手数料が低すぎる場合、流動性供給者はこのプールへの貢献に対してメリットが得られなくなります。
AMMは、流動性プロバイダに対して、保有するLPトークンの数に応じて、手数料に関する投票権を与えます。投票するには、流動性供給者が[AMMVote][]トランザクションを送信します。誰かが新しい票を入れるたびに、AMMは手数料を再計算し、直近の票の平均を、それらの投票者が保有するLPトークンの数で重み付けしたものにします。この方法では、最大8つの流動性供給者の投票がカウントされます。それ以上の流動性供給者が投票しようとすると、上位8つの投票（保有LPトークンの多い順）だけがカウントされます。流動性供給者のLPトークンのシェアは、様々な理由(例えば[オファー](offers.md)を使ったトークンの取引)で急速に変化しますが、取引手数料は誰かが新しい票を入れるたびに再計算されます（その票がトップ8に入っていない場合でも計算されます)。
### オークションスロット
XRP LedgerのAMMの設計には「オークションスロット」が含まれています。流動性プロバイダはLPトークンを落札に利用してオークションスロットを獲得し、24時間取引手数料の割引を受けることができます。落札に利用されたLPトークンはAMMに回収されます。
AMMの資産価格が外部市場で大きく変動すると、トレーダーはAMMから利益を得るために裁定取引を行うことができます。これは流動性プロバイダに損失をもたらします。オークションメカニズムは、その価値の一部を流動性プロバイダに返し、AMMの価格をより迅速に外部市場とバランスを取ることを意図しています。
一度に複数のアカウントがオークションスロットを保持することはできませんが、落札者は割引を受けるために追加で最大4つのアカウントを指定することができます。スロットが現在使用中の場合、現在のスロット保持者を追い出すために落札する必要があります。追い出された場合、残り時間に応じて一部の落札金額が返却されます。アクティブなオークションスロットを保持している間は、そのAMMに対して取引を行う際に、通常の取引手数料の1/10（10分の1）の割引が適用されます。
オークションスロットの最小入札額は、空または期限切れの場合、現在のLPトークンの総数に取引手数料を掛けたものを25で割ったものです。(擬似コードで表すと、`MinBid = LPTokens * TradingFee / 25`です。) オークションスロットが占有されている場合、現在のスロット保持者が支払った金額の105%までの最小入札額を支払う必要があります。
## 台帳上の表示
台帳の状態データでは、AMMは複数の[レジャーエントリのタイプ](../../../references/protocol/ledger-data/ledger-entry-types/index.md)で構成されています。
- 自動マーケットメーカー自体を記述した[AMMエントリ][]
- AMMのLPトークンを発行し、AMMのXRP（保有している場合）を保有する特別な[AccountRootエントリ][]
このAccountRootのアドレスは、AMMの作成時にランダムに選ばれ、AMMを削除して再作成した場合にも異なるアドレスが選ばれます。これは、AMMのアカウントにユーザが事前にXRPで資金を供給することを防止するためです。
- AMMのプールにあるトークンのAMM専用アカウントへの[トラストライン](../fungible-tokens/index.md)
これらのレジャーエントリはどのアカウントにも所有されていないため、[準備金要件](../../accounts/reserves.md)は適用されません。ただし、スパムを防ぐため、AMMを作成するための取引には特別な[トランザクションコスト](../../transactions/transaction-cost.md)があり、通常よりも多くのXRPを消費する必要があります。
## 削除
AMMは、[AMMWithdrawトランザクション][]がそのプールから全てのアセットを引き出すと削除されます。これは、AMMのすべての発行済みLPトークンを償還することによってのみ発生します。AMMの削除には、以下のようなAMMに関連するすべてのレジャーエントリの削除も含まれます。
- AMM
- AccountRoot
- AMMのLPトークンのトラストライン。これらのトラストラインは残高が0ですが、限度額など他の詳細がデフォルト以外の値に設定されている可能性があります。
- AMMのプールに存在するトークンのトラストライン。
AMMアカウントが削除されるときに、512を超えるトラストラインが設定されていた場合、出金は成功し、可能な限り多くのトラストラインを削除します。
AMMのプールに資産がない間は、誰でも[AMMDeleteトランザクション][]を送信してAMMを削除することができます。別の方法として、誰でも[特別な入金](../../../references/protocol/transactions/types/ammdeposit.md#空のammの場合の特殊なケース)を行うことで、AMMにあたかも新規であるかのように入金することができます。資産プールが空のAMMに対しては、他の操作は無効です。
空のAMMを削除することによる払い戻しやインセンティブはありません。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

72
@l10n/ja/docs/concepts/tokens/decentralized-exchange/index.md Normal file
View File

@@ -0,0 +1,72 @@
---
html: decentralized-exchange.html
parent: tokens.html
metadata:
indexPage: true
seo:
description: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザはトークンをXRPに、あるいはXRPをトークンにに交換できます。
---
# 分散型取引所
XRP Ledgerには、世界でおそらく最も古い _分散型取引所_ (「DEX」と略されることもあります)があり、2012年のXRP Ledgerのローンチ以来、現在まで稼働し続けています。この取引所では、ユーザが[トークン](../index.md)をXRPや他のトークンと売買することができ、ネットワーク自体に課される[手数料](../../transactions/fees.md)はごく僅かです。(いかなる当事者にも支払われることはありません)
{% admonition type="warning" name="注意" %}誰でも好きな通貨コードやティッカーシンボルで[トークンを発行](../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)して、分散型取引所で販売することができます。トークンを購入する前に必ずデューデリジェンスを行い、発行者に注意を払うようにしてください。さもなければ、価値あるものを手放し、それと引き換えに価値のないトークンを受け取ることになるかもしれません。{% /admonition %}
## 構造
XRP Ledgerの分散型取引所は、無制限の通貨ペアで構成されており、ユーザが取引を行う際にオンデマンドで追跡されます。通貨ペアは、XRPとトークン、または2つの異なるトークンから構成されます。トークンは常に、発行者と通貨コードの組み合わせによって識別されます。同じ通貨コードで異なる発行者のトークン同士、または同じ発行者で異なる通貨コードのトークン同士の取引も可能です。
XRP Ledgerのすべての変更がそうであるように、取引を行うには[トランザクション](../../transactions/index.md)を送信する必要があります。XRP Ledgerにおける取引は、[オファー](offers.md)と呼ばれています。オファーは事実上、ある通貨(XRPまたはトークン)を特定の金額で他の通貨と売買するための[_指値注文_](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%83%88%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC)です。ネットワークがオファーを実行する際、同じ通貨ペアでマッチングするオファーがあれば、最も良い取引レートから順に約定されます。
オファーは、全額または一部が約定されることがあります。すぐに全額が約定されなかった場合は、残りの金額は台帳上のOfferオブジェクトとなります。その後、他のオファーや[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)がオファーにマッチし、約定する可能性があります。このため、Offerは最初に注文したときは指定した取引レートよりも高いレートで約定し、後で注文したときは指定した取引レートと全く同じレートで約定することがあります。（端数処理のためのわずかな差は除きます）
オファーは、発注後、手動または自動でキャンセルすることができます。この機能およびその他の機能については、[オファー](offers.md)をご覧ください。
2つのトークンを取引する際、トークンとトークンを直接取引するよりも、トークンとXRP、XRPとトークンを取引した方が安くなる場合、[オートブリッジ](autobridging.md)によって自動的に取引レートと流動性を向上させることができます。
### 取引の例
[{% inline-svg file="/docs/img/decentralized-exchange-example-trade.ja.svg" /%}](/docs/img/decentralized-exchange-example-trade.ja.svg "図: XRPでトークンを購入する注文が一部約定する。")
上の図は、分散型取引所での取引例です。この例では、Tranというトレーダーが、WayGateという架空の企業が発行するFOOという通貨コードのトークン100個の購入オファーを出しています。(簡潔にするため、「FOO.WayGate」はこれらのトークンを指します。)Tranは、合計で最大1000XRPまで支払う意思があることを明記しています。Tranのトランザクションが処理されると、次のようなことが起こります。
1. ネットワークは、購入する通貨額を支払う通貨額で割ることによって、TranのOfferの取引レートを計算します。
0. このオーダーブックには、金額や取引レートが異なる他のトレーダーからのオファーがすでに複数存在します。このケースでは、FOO.WayGateの売りとXRPの買いのオーダーブックを意味します。
0. Tranのオファーが全額約定するか、Tranのオファーは、Tranのオファーで指定されたレートと同等以上の取引レートのオファーがなくなるまで、最良の取引レートから順に、オファーを約定していきます。この例では、22 FOO.WayGateのみが指定されたレート以上で取引可能です。約定したオファーはオーダーブックから削除されます。
0. Tranは、この取引で調達できたFOO.WayGateの量を、それまで売り注文を出していた様々なトレーダーから受け取ります。これらのトークンはWayGateのFOOに対するTranの[トラストライン](../fungible-tokens/index.md)に送られます。(Tranがまだトラストラインを持っていなかった場合、自動的に作成されます。)
0. その見返りとして、それらのトレーダーは、提示された取引レートに従って、TranからXRPを受け取ります。
0. ネットワークはTranのオファーの残りを計算します。元々のオファーが100 FOO.WayGateの購入で、これまでTranは22を受け取っているので、残りは78 FOO.WayGateとなります。元の取引レートを使用すると、Tranのオファーの残りは780 XRPで78 FOO.WayGateを購入することになります。
0. この「残り」は、Tranの取引と同じ向きの取引、つまりXRPの売りとFOO.WayGateの買いのオーダーブックに載せられます。
同じ台帳でTranの直後に実行されたものも含め、その後の取引は更新されたオーダーブックを使って行われるため、Tranのオファーが全額約定するかTranがキャンセルするまで、その一部または全額を約定することができます。
{% admonition type="info" name="注記" %}元帳がクローズされ、検証される際の取引の実行順序は、取引が送信された順序と同じではありません。複数のトランザクションが同じ台帳の同じオーダーブックに影響を与える場合、それらのトランザクションの最終結果は、トランザクション送信時に計算された暫定的な結果とは大きく異なる可能性があります。取引結果が確定する場合、確定しない場合の詳細については、[結果のファイナリティー](../../transactions/finality-of-results/index.md)をご覧ください。{% /admonition %}
## 制限事項
分散型取引所は、以下のような制限を設けて設計されています。
取引は新しい台帳がクローズするたびに（約3～5秒ごと）実行されるだけなので、XRP Ledgerは[高頻度取引](https://ja.wikipedia.org/wiki/%E9%AB%98%E9%A0%BB%E5%BA%A6%E5%8F%96%E5%BC%95)には適していません。台帳内で取引が実行される順番は、[フロントランニング](https://en.wikipedia.org/wiki/Front_running)を阻止するため、予測できないように設計されています。
XRP Ledgerは、成行注文、指値注文、レバレッジ取引などの概念をネイティブに表現するものではありません。カスタムトークンやOfferのプロパティをクリエイティブに利用することで、いくつかは実現できるかもしれません。
分散型システムであるXRP Ledgerは、取引に関わる[アカウント](../../accounts/index.md)の背後にいる実際の人々や組織に関する情報を一切持っていません。また、ユーザや発行者は、様々な種類の裏付け資産を表すトークンの取引を規制するために、関連する法律に従う必要があります。[凍結](../fungible-tokens/freezes.md)や[認可トラストライン](../fungible-tokens/authorized-trust-lines.md)などの機能は、発行者が関連法規を順守できるよう意図しています。
## 関連項目
- **コンセプト:**
- [Offers](offers.md): XRP Ledgerでのトレードの仕組みについて
- [トークン](../index.md): XRP Ledgerで様々な種類の価値を表現する方法の概要について
- **リファレンス:**
- [account_offersメソッド][]: アカウントから注文されたオファーを検索
- [book_offersメソッド][]: 指定された通貨ペアの売買のオファーを検索
- [OfferCreateトランザクション][]: 新規オファーを発注や既存のオファーの置き換え
- [OfferCancelトランザクション][]: 既存のオファーをキャンセル
- [Offerオブジェクト][] 台帳のオファーのデータ構造
- [DirectoryNodeオブジェクト][]: 特定の通貨ペアと取引レートのすべてのオファーを追跡するデータ構造
{% raw-partial file="/docs/_snippets/common-links.md" /%}
{% child-pages /%}

109
@l10n/ja/docs/concepts/tokens/decentralized-exchange/offers.md Normal file
View File

@@ -0,0 +1,109 @@
---
html: offers.html
parent: decentralized-exchange.html
seo:
description: オファーはXRP Ledgerの通貨取引に関する機能の一つです。オファーのライフサイクルと特性について説明します。
labels:
- 分散型取引所
---
# オファー
XRP Ledgerの[分散型取引所](index.md)では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと[トークン](../index.md)の取引、またはトークン間の取引（同一通貨コードだが発行者が異なるトークンを含む）を行うことができます。（同一通貨コードで発行者が異なる通貨は、[rippling](../fungible-tokens/rippling.md)によって取引することもできます。）
- オファーを作成するには、[OfferCreateトランザクション][]を送信します。
- 即時に約定されないオファーはレジャーデータの[Offerオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは約定されます。
- [クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)はオファーを約定して流動性を提供します。
## オファーのライフサイクル
[OfferCreate トランザクション][]は、2つのトークン、またはトークンとXRPの間で取引を行なうための命令です。それぞれのトランザクションは購入額（`TakerPays`）と売却額（`TakerGets`）を含みます。トランザクションが処理されると、自動的に約定またはクロスするオファーが可能な限り約定されます。その結果、新しいオファーを完全に約定しきれない場合、残りは台帳上のOfferオブジェクトとなります。
Offerオブジェクトは、他のオファーやクロスカレンシー決済で完全に約定されるまで、台帳に保存されます。オファーを作成したアカウントは、そのオファーの所有者と呼ばれます。自分が作成したオファーは、専用の[OfferCancelトランザクション][]、または[OfferCreateトランザクション][]のオプションとして、いつでもキャンセルすることが可能です。
台帳にOfferオブジェクトがある間は、あなたのXRPの一部が[所有者準備金](../../accounts/reserves.md)として設定されます。何らかの理由でOfferオブジェクトが削除されると、そのXRPは再び使えるようになります。
### 必要となる資金
オファーを作成する際、その取引で売却する資産の一部でも保有していない場合、取引は「資金不足」として拒否されます。
具体的には
**トークンを売却する** には、以下のいずれかが必要です。
- そのトークンの任意の正の量を保持する、_または_
- そのトークンの発行者になる。
ただし、オファーで指定された全額を保有する必要はありません。オファーを作成することで資金が拘束されるわけではないので、同じトークン（またはXRP）を売却するために複数のオファーを作成したり、オファーを作成した後で十分なトークンまたはXRPを調達することも可能です。
**XRPを売却する** には、Offerオブジェクトを台帳に保存するための準備金と、購入するトークンを保存するためのトラストラインの準備金を含む、必要な[準備金](../../accounts/reserves.md)を確保する必要があります。準備金を確保した後にXRPが残っていれば、Offerオブジェクトを作成することができます。
他のオファーと自身のオファーがマッチした場合、両方のオファーが、その時点における所有者の資金の範囲内で実行されます。マッチングしたオファーがあり、自分のオファーが完全に約定される前に資金が尽きてしまった場合、残りのオファーはキャンセルされます。トークンの発行者でない限り、オファーによってトークンの残高がマイナスになることはありません。(発行者であれば、オファーを使って、オファーで指定された合計金額まで新しいトークンを発行できます。発行したトークンは、発行者の立場からはマイナス残高として表示されます)。
台帳に存在する自身のオファーと重なるオファーを作成した場合、金額にかかわらず、重なった古いオファーは自動的にキャンセルされます。
次のような場合には、オファーが一時的または長期に渡って「資金不足」になる可能性があります。
- 所有者が売却する資産を一切保有しなくなった場合。
- オーナーがその資産を再度取得すると、オファーに資金が供給されるようになります。
- 売却する資産が[凍結されたトラストライン](../fungible-tokens/freezes.md)に含まれるトークンである場合。
- トラストラインが凍結解除されると、オファーは再び資金が供給されるようになります。
- オファーが新しいトラストラインを作成する必要があるが、オーナーがその[準備金](../../accounts/reserves.md)の増加に伴う十分なXRPを持っていない場合。
- オーナーが追加のXRPを調達するか、準備金の必要量が減少すると、オファーは自動的に使用可能になります。
- オファーが失効した場合。([オファーの有効期限](#オファーの有効期限)を参照)
資金不足のOfferオブジェクトは、トランザクションによって削除されるまで、台帳に残ります。台帳からOfferオブジェクトを削除するには、以下の方法があります。
- 約定するオファーまたは[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)によってオファーが全額約定される。
- 所有者が明示的にオファーをキャンセルする。
- 所有者が交差する新しいオファーを作成することにより、暗黙のうちにオファーをキャンセルする。
- トランザクション処理中にオファーが資金不足または期限切れであることが判明する。
- これには、オファーが支払うことができる残額がゼロになる場合も含まれます。
### 資金不足のオファーの追跡
すべてのオファーの資金状況の追跡は、コンピュータにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金状況に影響することがあります。このため、XRP Ledgerでは資金不足や期限切れのオファーの検出と削除を _積極的には_ 行なっていません。
クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](../../../references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
## オファーとトラスト
トラストラインの限度額（[TrustSet](../../../references/protocol/transactions/types/trustset.md)を参照）はオファーに影響しません。つまり、オファーを使用して、発行者に対して設定したトラストラインの限度額を上回る額を取得できます。
ただし、トークンを保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが約定されると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](../../accounts/reserves.md)ため、新しいトラストラインを必要とするオファーがある場合、アカウントはそのトラストラインの準備金として十分なXRPを保有している必要があります。
トラストラインの制限は、あなたの希望以上のトークンを受け取ることを防ぐためのものです。オファーとは、トークンをどれだけ欲しいかを明示的に示すものであるため、この制限を超えることができます。
## オファーの優先度
台帳内のOfferオブジェクトは取引レートによってグループにまとめられます。取引レートは、`TakerGets`と`TakerPays`の比率として計算されます。取引レートが高いOfferオブジェクトが優先的に処理されます。（つまり、オファーを約定する人は、支払われる通貨額に対して可能な限り多くの額を受領します。）同じ取引レートのオファーは、オファーの作成タイミングを基準にして処理されます。
同じ取引レートのOfferオブジェクトが同じ台帳ブロックに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/XRPLF/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source Code: Applying transactions")ための[正規順序](https://github.com/XRPLF/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source Code: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。
## オファーの有効期限
オファーを設定する際、オプションで有効期限を追加することができます。デフォルトでは、オファーに有効期限はありません。すでに有効期限切れのオファーを新たに作成することはできません。
有効期限は秒単位で指定できますが、オファーが期限切れとなる時刻は、実際には正確ではありません。オファーが期限切れとなるのは、期限切れ時刻が直前の台帳のクローズ時刻より前か等しい場合です。それ以外の場合は、現実の時刻がオファー期限よりも後でも、オファーが約定する可能性があります。言い換えると、有効期限が最新の有効な台帳のクローズ時刻よりも遅ければ、実際の時計がどうであろうと、オファーはまだ「有効」なのです。
これは、ネットワークのコンセンサス形成の仕組みによるものです。ピアツーピアネットワーク全体が合意に達するには、トランザクションを実行する際に、すべてのサーバがどのオファーが期限切れであるかに合意する必要があります。個々のサーバはシステム時刻の設定にわずかな違いがあるため、各サーバが「現在」時刻を使用した場合、どのオファーが期限切れであるかについて同じ結論に達しない可能性があります。台帳のクローズ時刻は、その台帳のトランザクションが実行されるまで分からないため、サーバは「前の台帳」の正式なクローズ時刻を代わりに使用します。[台帳のクローズ時刻は丸められます](../../ledgers/ledger-close-times.md)。このため、オファーが期限切れかどうかを判断するための時刻と実世界の時刻の差が生じる場合があるのです。
{% admonition type="info" name="注記" %}期限切れのOfferオブジェクトは、トランザクションによって削除されるまで、台帳内に残ります。それまでは、APIから取得したデータ（[ledger_entryメソッド][]などを使用）に表示され続ける可能性があります。トランザクションは、有効期限が切れたOfferオブジェクトや資金不足のOfferオブジェクトを見つけると自動的に削除します。通常、オファーやクロスカレンシー決済を実行すると、そのOfferオブジェクトはマッチングまたはキャンセルされます。Offerオブジェクトに対応する所有者準備金は、Offerオブジェクトが実際に削除されたときにのみ再び利用可能になります。{% /admonition %}
## 関連項目
- **コンセプト:**
- [トークン](../index.md)
- [パス](../fungible-tokens/paths.md)
- **リファレンス:**
- [account_offersメソッド][]
- [book_offersメソッド][]
- [OfferCreateトランザクション][]
- [OfferCancelトランザクション][]
- [Offerオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/offer.md)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

28
@l10n/ja/docs/concepts/tokens/decentralized-exchange/ticksize.md Normal file
View File

@@ -0,0 +1,28 @@
---
html: ticksize.html
parent: decentralized-exchange.html
seo:
description: 発行者は、為替レートのごくわずかな差を超えて、頻繁な取引を抑制するためにオーダーブックで通貨のカスタムチックサイズを設定することができます。
labels:
- 分散型取引所
- トークン
---
# ティックサイズ
_（[TickSize Amendment][]により追加されました。）_
オファーがオーダーブックに対して発行されると、そのオファーに関係する通貨の発行者によって設定された`TickSize`の値に基づいて、為替レートが切り捨てられます。トレーダーがXRPとトークンを交換するオファーを出した場合は、そのトークンの発行者からの`TickSize`が適用されます。トレーダーが2種類のトークンを交換するオファーを出した場合は、小さい方の`TickSize`の値（有効数字の桁数が少ない値）がこのオファーに適用されます。いずれの通貨にも`TickSize`が設定されていない場合、デフォルトが適用されます。
オーダーブックにオファーが発行されると、`TickSize` によりオファーの為替レートの _有効数字_ の桁数が切り捨てられます。発行者は[AccountSetトランザクション][]を使用して`TickSize`を`3`～`15`の整数に設定できます。為替レートは有効数字と指数で表されますが、`TickSize`は指数には影響しません。これにより、XRP Ledgerでは価値が大きく異なる資産（ハイパーインフレ通貨と希少通貨など）間の為替レートを表せます。発行者が設定する`TickSize`が小さいほど、トレーダーはより多くの増分をオファーして、既存のオファーよりも高い為替レートと見えるようにする必要があります。
`TickSize`は、オファーの即時に実行可能な部分には影響しません。（この理由から、`tfImmediateOrCancel`が指定されたOfferCreateトランザクションは`TickSize` の値の影響を受けません。）オファーを完全に実行できない場合、トランザクション処理エンジンは`TickSize`に基づいて為替レートを計算して切り捨てを行います。次にエンジンは、切り捨てた後の為替レートに一致するように、「重要性が低い」側からのオファーの残額を丸めます。デフォルトのOfferCreateトランザクション（「買い」オファー）の場合、`TakerPays`の額（購入額）が丸められます。`tfSell`フラグが有効な場合（「売り」オファー）`TakerGets`の額（売却額）が丸められます。
発行者が`TickSize`を有効化、無効化、または変更する場合、以前の設定で発行されたオファーはその影響を受けません。
## 参照項目
- [Dev Blog: Introducing the TickSize Amendment](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#ticksize-amendment-overview)
- [AccountSetトランザクション][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}

128
@l10n/ja/docs/concepts/tokens/fungible-tokens/authorized-trust-lines.md Normal file
View File

@@ -0,0 +1,128 @@
---
html: authorized-trust-lines.html
parent: trust-lines-and-issuing.html
seo:
description: 認可トラストラインとは、トークンを保有できる人を制限するための設定です。
labels:
- トークン
- セキュリティ
---
# 認可トラストライン
XRP Ledgerの認可トラストライン機能により、発行者は、発行者が許可したアカウントのみが保有できるトークンを作成することができます。認可トラストライン機能はトークンにのみ適用され、XRPには影響しません。
認可トラストライン機能を使用するには、発行アドレスで**RequireAuth**フラグを有効にします。その後、他のアカウントは、あなたがそのアカウントのトラストラインをあなたの発行アカウントに承認した場合にのみ、あなたが発行したトークンを保持することができます。
発行アドレスから[TrustSetトランザクション][]を送信し、自分のアカウントと認可するアカウントとの間のトラストラインを設定することで、トラストラインを認可することができます。トラストラインを認可した後、その認可を取り消すことはできません。(ただし、必要に応じてトラストラインを[凍結](freezes.md)することは可能です)。
トラストラインを認可するためのトランザクションは、発行アドレスの署名が必要であり、残念ながらそのアドレスのリスクエクスポージャーが増加することを意味します。
{% admonition type="warning" name="注意" %}Require Authを有効にできるのは、アカウントにトラストラインがなく、XRP LedgerにOffersがない場合だけなので、トークンの発行前に使用するかどうかを決定する必要があります。{% /admonition %}
## ステーブルコインの発行
XRP Ledger上のステーブルコインと認可トラストラインの使用により、新規顧客の獲得プロセスは以下のようなものになります。
1. 顧客は、ステーブルコイン発行会社のシステムに登録し、身元を証明する情報（「Know Your Customer」（KYC）情報とも呼ばれる）を送信します。
2. 顧客とステーブルコイン発行者は、お互いのXRP Ledgerアドレスを提示し合います。
3. 顧客は[TrustSetトランザクション][]を送信し、発行者のアドレスにトラストラインを作成し、正のリミットを設定します。
4. 発行者はTrustSetトランザクションを送信し、顧客のトラストラインを認可します。
{% admonition type="success" name="ヒント" %}2つのTrustSetトランザクション（ステップ3および4）は、どちらの順序で発生しても構いません。発行者がトラストラインを先に認可した場合、これにより限度額が0に設定されたトラストラインが作成され、顧客のTrustSetトランザクションは、事前に認可されたトラストラインの限度額を設定することになります。([TrustSetAuth amendment][]により追加されました。)_{% /admonition %}
## 注意事項
認可トラストラインを使用するつもりがない場合でも、[運用アカウントと予備アカウント](../../accounts/account-types.md)のRequire Auth設定を有効にし、これらのアカウントにトラストラインを認可させないようにすることができます。これは、これらのアカウントが誤ってトークンを発行することを防止します（たとえば、ユーザが誤って間違ったアドレスをトラストしてしまった場合など）。これはあくまで予防措置であり、運用アカウントと予備アカウントが意図したとおりに _発行者の_ トークンを転送することを止めるものではありません。
## 技術情報
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
### RequireAuthの有効化
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使って、`asfRequireAuth`フラグを使ってRequire Authを有効にする[AccountSetトランザクション][]を送信する例です。（このメソッドは、アドレスが発行アドレス、運用アドレス、待機アドレスのいずれであっても同様に機能します。）
リクエスト:
```json
POST http://localhost:5005/
{
"method": "submit",
"params": [
{
"secret": "s████████████████████████████",
"tx_json": {
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
"Fee": "15000",
"Flags": 0,
"SetFlag": 2,
"TransactionType": "AccountSet"
}
}
]
}
```
{% partial file="/@l10n/ja/docs/_snippets/secret-key-warning.md" /%}
## アカウントのRequireAuthの有効化の確認
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)と比較します。
`Flags`値と`lsfRequireAuth`フラグ値（`0x00040000`）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
## トラストラインの認可
認可トラストライン機能を使用している場合、他のアカウントからのトラストラインを認可しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数のトークンを発行する場合には、各通貨のトラストラインを個別に認可する必要があります。
トラストラインを認可するには、`LimitAmount`の`issuer`として信頼するユーザを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](../../../references/protocol/transactions/types/trustset.md#trustsetのフラグ)フラグを有効にします。
以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス`rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`がアドレス`rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`で発行したUSDを持つことを認可するTrustSetトランザクションを送信する例です。
リクエスト:
```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
}
}
]
}
```
{% partial file="/@l10n/ja/docs/_snippets/secret-key-warning.md" /%}
## トラストラインの認可状況の確認
トラストラインの認可状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。レスポンスの`account`フィールドに顧客のアドレスを指定し、`peer`フィールドに発行者のアドレスを指定します。
レスポンスの`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、発行者（レスポンスの`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
## 関連項目
- **コンセプト:**
- [Deposit Authorization](../../accounts/depositauth.md)
- [トークンの凍結](freezes.md)
- **リファレンス:**
- [account_linesメソッド][]
- [account_infoメソッド][]
- [AccountSetトランザクション][]
- [TrustSetトランザクション][]
- [AccountRootフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
- [RippleState (トラストライン) フラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

40
@l10n/ja/docs/concepts/tokens/fungible-tokens/clawing-back-tokens.md Normal file
View File

@@ -0,0 +1,40 @@
---
html: clawing-back-tokens.html
parent: trust-lines-and-issuing.html
seo:
description: 発行者は、トークンを発行する前にClawback機能を有効にすると、規制遵守の目的でトークンを取り戻すことができます。
labels:
- トークン
---
# トークンの回収
{% partial file="/@l10n/ja/docs/_snippets/clawback-disclaimer.md" /%}
規制上の目的から、トークンがアカウントに送信された後にトークンを回収する機能を必要とする発行者が存在します。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を「回収」することができます。
発行者は、発行アカウントで**Allow Clawback**フラグを有効にすることで、トークンを回収する権限を得ることができます。発行者がすでにトークンを発行している場合、このフラグを有効にすることはできません。
{% admonition type="info" name="注記" %}アカウント自身が発行したトークンのみを回収することができます。この方法でXRPを回収することはできません。{% /admonition %}
Clawback機能はデフォルトで無効になっています。使用するには、[AccountSetトランザクション][]を送信して、**Allow Trust Line Clawback**設定を有効にする必要があります。**既存のトークンを持つ発行者はClawback機能を有効にすることはできません**。**Allow Trust Line Clawback**を有効にできるのは、所有者ディレクトリが完全に空の場合のみです。つまり、トラストライン、オファー、エスクロー、ペイメントチャネル、チェック、または署名者リストを設定する前に有効にする必要があります。
`lsfNoFreeze`が設定されているときに`lsfAllowTrustLineClawback`を設定しようとすると、トランザクションは`tecNO_PERMISSION`を返します。
逆に、`lsfAllowTrustLineClawback`が設定されている時に`lsfNoFreeze`を設定しようとすると、トランザクションは`tecNO_PERMISSION`を返します。
## Clawbackトランザクションの例
```json
{
"TransactionType": "Clawback",
"Account": "rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9S",
"Amount": {
"currency": "FOO",
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"value": "314.159"
}
}
```
このトランザクションが成功した場合、rp6abvbTbjoce8ZDJkT6snvxTZSYMBCC9Sが発行し、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWが保有する最大314.159FOOを回収することになります。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

34
@l10n/ja/docs/concepts/tokens/fungible-tokens/common-misconceptions-about-freezes.md Normal file
View File

@@ -0,0 +1,34 @@
---
parent: freezes.html
html: common-misconceptions-about-freezes.html
seo:
description: XRP Ledgerのフリーズ機能について、よくある誤解を解いていきます。
labels:
- トークン
---
# トークンの凍結に関するよくある誤解
PayPalのような中央集権的なサービスがアカウントを停止して資金にアクセスできないようにするのと同様に、Ripple社などがXRPを凍結することができるというのはよくある誤解です。XRP Ledgerには[凍結機能](freezes.md)がありますが、これは発行トークンにのみ使用可能で、XRPには使用できません。 **XRPを凍結することは誰にもできません**。
XRP Ledgerのトークンは、[XRPとは根本的に異なる](../../../references/protocol/data-types/currency-formats.md#comparison)ものです。トークンは常にトラストライン上に存在し、それは凍結される可能性があります。XRPはアカウントに含まれており、凍結されることはありません。
## XRPは単なるRipple社のトークンではないのか？
いいえ、XRPはトークンとは異なります。XRPはXRP Ledger上の唯一のネイティブアセットであり、XRP Ledger上で取引を行うために必要なものです。XRPにはカウンタパーティが存在しません。つまり、誰かがXRPを保有するとき、その人は負債を保有しているのではなく、実際の通貨であるXRPを保有しているのです。この事実により、 _**<u>XRPはいかなる団体や個人によっても凍結することができません</u>**_ 。
## Ripple社またはXRP Ledger財団は私のトークンを凍結することができますか？
XRP Ledgerは分散型であり、Ripple社やXRP Ledger財団、そして他のいかなる存在もそれをコントロールすることはできません。
あるトークンの発行者は、 _そのトークンに限定して_ あなたのトラストラインを凍結することができます。あなたのアカウントの他の部分や、異なる発行者のトークンを凍結することはできませんし、あなたがXRP Ledgerを使うのを止めることもできないのです。
さらに、トークン発行者は、トークンを凍結する能力を自主的かつ永久的に放棄することができます。この["No Freeze"](freezes.md#no-freeze)設定は、他者がトークンの使用を止めることができないという意味で、トークンがより実際の現金のように振る舞うことを想定しています。
## しかし、Ripple社がJed McCaleb氏のXRPを凍結したと聞きましたが？
これは、2015年から2016年にかけて実際に起こった事件の誤報です。2013年にRipple社の創業者で同社を退社したJed McCaleb氏は、100万USドル以上のXRPをカストディ取引所であるBitstampで売却しようと試みました。Ripple社の代理人は、この売却はJed氏とRipple社が2014年に締結した契約に違反すると主張しました。Ripple社の要求により、[BitstampはJedのBitstampアカウントを凍結](https://www.coindesk.com/markets/2015/04/02/1-million-legal-fight-ensnares-ripple-bitstamp-and-jed-mccaleb/)し、裁判に持ち込まれました。この裁判は[最終的に和解](https://www.coindesk.com/markets/2016/02/12/ripple-settles-1-million-lawsuit-with-former-executive-and-founder/)となり、双方がその結果に納得したと表明しています。
注目すべきは、この「凍結」はXRP Ledger上で起こったものではなく、XRP Ledgerの凍結機能を使ったものでもないことです。他のカストディアン取引所と同様に、Bitstampはユーザのアカウントを凍結し、特にそれらの資金が法的紛争に巻き込まれている場合、取引や資金の引き出しを停止する権限を持っています。
一方、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)で取引する場合は、自分で資産を管理するので、XRPの取引を止めることは誰にもできないのです。

127
@l10n/ja/docs/concepts/tokens/fungible-tokens/demurrage.md Normal file
View File

@@ -0,0 +1,127 @@
---
html: demurrage.html
parent: trust-lines-and-issuing.html
seo:
description: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
status: removed
---
# デマレージ
{% admonition type="warning" name="注意" %}デマレージは非推奨の機能であり、継続的なサポートはありません。このページでは、旧バージョンのXRP Ledgerソフトウェアの過去の動作について説明します。{% /admonition %}
[デマレージ](https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%9E%E3%83%AC%E3%83%BC%E3%82%B8) とは、保有資産にかかるマイナスの金利で、その資産を保有するためのコストを表すものです。 XRP Ledgerで発行された通貨のデマレージを表現するために、デマレージレートを示すカスタム[通貨コード](../../../references/protocol/data-types/currency-formats.md#通貨コード) を使って追跡することができます。 これによって、様々なデマレージの量に対応した別々のバージョンの通貨が効果的に作成されます。クライアントアプリケーションは、通貨コードと一緒に年率でデマレージ通貨コードを表現することによって、これをサポートすることができます。例えば、以下のようになります。"XAU (-0.5%pa)".
## 通貨量の表記について
XRP Ledgerのすべての金額を継続的に更新するのではなく、有利子通貨や減耗通貨の金額を2種類の金額に分割する方法です。XRP Ledgerに記録される「レジャー値」と、人に見せる「表示値」の2種類に分けます。「レジャー値」は、ある一定時点、すなわち2000年1月1日午前0時の「リップルエポック」での通貨の価値を表しています。「表示値」は、リップルエポックからその時点までの連続した利息やデマレージを計算した後の時点（通常は現在時刻）での金額を表しています。
{% admonition type="success" name="ヒント" %}デマレージはインフレに似ていると考えることができます。インフレの影響を受けたすべての資産の価値は時間とともに減少しますが、レジャーには常に2000年の値で金額が記録されます。これは実際のインフレを反映しているわけではなく、デマレージはむしろ一定の割合での仮想的なインフレのようなものです。{% /admonition %}
したがって、クライアントソフトウェアは2つの変換を適用する必要があります。
- ある時点の表示値を取り込み、レジャー値に変換して記録すること。
- レジャー値を、ある時点の表示値に変換すること。
### デマレージの計算
通貨に関するデマレージの完全な計算式は以下の通りです。
```
D = A × ( e ^ (t ÷ τ) )
```
- **D** はデマレージ後の金額
- **A** はグローバルレジャーに記録されたデマレージ前金額です。
- **e** はオイラー数
- **t** はリップルエポック（UTC2000年1月1日0時）からの経過秒数
- **τ** は、e倍加時間の時間（秒）です。この値は［希望する金利から計算］（#e倍加時間の計算）されます。 <!-- SPELLING_IGNORE: τ -->
表示金額とレジャー金額の変換は、以下の手順で行います。
1. `( e ^ (t ÷ τ) )`の値を計算する。この数値を「デマレージ係数」と呼ぶ。デマレージ係数は常に現在時刻など特定の時刻からの相対値である。
2. 変換する量に適用します。
- レジャー値を表示値に変換する場合は、デマレージ係数を乗じる。
- 表示値をレジャー値に変換する場合は、デマレージ係数で割ってください。
3. 必要であれば、結果値が望ましい精度で表現できるように調整する。XRP Ledgerの[発行通貨形式](../../../references/protocol/data-types/currency-formats.md#トークンの精度)により、レジャー値の精度は小数点以下15桁までとされています。
## 利子付き通貨コードフォーマット
[標準通貨コード形式](../../../references/protocol/data-types/currency-formats.md#標準通貨コード)ではなく、正の金利や負の金利（Demurrage）を持つ通貨は、以下の形式の160ビット通貨コードを使用します。
![通貨コード形式を削除する](/docs/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倍加時間（秒）です。
{% admonition type="info" name="注記" %}XRP Ledgerの利息・デマレージルールでは、慣習上、1年あたりの固定秒数（31536000）が使用されており、閏日や閏秒の調整は行われていません。{% /admonition %}
## クライアントサポート
利息通貨とデマレージ通貨をサポートするために、クライアントアプリケーションはいくつかの機能を実装する必要があります。
- レジャーやトランザクションデータから取得した通貨を減耗して表示する場合、クライアント側でレジャー値から表示値への変換が必要です。(デマレージでは、表示値はレジャー値より小さくなる)。
- デマレージ通貨の入力を受け付ける場合、クライアントは金額を表示形式からレジャー形式に変換する必要があります。(デマレッジの場合、ユーザ入力値よりレジャー値の方が大きい)。クライアントは、支払い、オファー、その他のトランザクションを作成する際に、レジャーの値を使用しなければなりません。
- クライアントは、金利やデマレージが発生する通貨と発生しない通貨、および金利やデマレージの利率が異なる通貨を区別する必要があります。クライアントは、[利子付き通貨コードフォーマット](#利子付き通貨コードフォーマット)を解析して、「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" }
```

101
@l10n/ja/docs/concepts/tokens/fungible-tokens/freezes.md Normal file
View File

@@ -0,0 +1,101 @@
---
html: freezes.html
parent: trust-lines-and-issuing.html
seo:
description: 発行者はコンプライアンス目的でトークンの取引を停止できます。
labels:
- トークン
---
# トークンの凍結
発行者は発行したトークンをXRP Ledgerで凍結することができます。**これはXRP LedgerのネイティブアセットであるXRPには適用されません。**
特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外のトークンの残高を急きょ凍結することがあります。
{% admonition type="success" name="ヒント" %}誰もXRP LedgerのXRPを凍結することはできません。しかし、カストディアル取引所は、自らの裁量で常に保管資金を凍結することができます。詳しくは、[凍結に関するよくある誤解](common-misconceptions-about-freezes.md)をご覧ください。{% /admonition %}
凍結については、3種類の設定があります。
* [**Individual Freeze(個別の凍結)**](#individual-freeze) - 1件の取引相手を凍結します。
* [**Global Freeze(全体の凍結)**](#global-freeze) - 取引相手全員を凍結します。
* [**No Freeze(凍結機能の放棄)**](#no-freeze) - 個々の取引相手の凍結機能と、Global Freeze機能を永久に放棄します。
凍結対象の残高がプラス、マイナスにかかわらず、すべての凍結設定を行うことができます。通貨イシュアーまたは通貨保持者のいずれかがトラストラインを凍結できますが、通貨保持者がイシュアーを凍結しても、その影響はわずかです。
## Individual Freeze
**Individual Freeze**機能は、[トラストライン](index.md)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
* 取引相手が凍結されたトラストライン上のトークンの売りオファーを出した場合、[資金不足とみなされます](../decentralized-exchange/offers.md#オファーのライフサイクル)。
再確認: トラストラインではXRPは保持されません。XRPは凍結できません。
金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](../../accounts/account-types.md)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
## Global Freeze
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべてのトークンに対して以下のルールが適用されます:
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](../../accounts/account-types.md)にも影響します。）
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
* 凍結アドレスによるトークンの売りオファーはすべて、[資金不足とみなされます](../decentralized-exchange/offers.md#オファーのライフサイクル)。
再確認: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](../../accounts/account-types.md)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
また、金融機関が新しい[発行アドレス](../../accounts/account-types.md)への移行や、営業の停止を予定している場合にも、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設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](../../../references/protocol/transactions/types/setregularkey.md)または[マルチシグトランザクション](../../accounts/multi-signing.md)を使用してNo Freezeを有効にすることはできません。
# 関連項目
- [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/_code-samples/freeze)
- **コンセプト:**
- [トラストラインとトークンの発行](index.md)
- **Tutorials:**
- [No Freezeを有効化](../../../tutorials/how-tos/use-tokens/enable-no-freeze.md)
- [Global Freezeの実行](../../../tutorials/how-tos/use-tokens/enact-global-freeze.md)
- [トラストラインの凍結](../../../tutorials/how-tos/use-tokens/freeze-a-trust-line.md)
- **References:**
- [account_linesメソッド][]
- [account_infoメソッド][]
- [AccountSetトランザクション][]
- [TrustSetトランザクション][]
- [AccountRootフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
- [RippleState(trust line)フラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

94
@l10n/ja/docs/concepts/tokens/fungible-tokens/index.md Normal file
View File

@@ -0,0 +1,94 @@
---
html: trust-lines-and-issuing.html
parent: tokens.html
seo:
description: トラストラインの特性と根本原理について説明します。
labels:
- トークン
---
# 代替可能トークン
非公式な"借用書"から、法定通貨を担保とするステーブルコイン、純粋なデジタルファンジブルトークンやセミファンジブルトークンなど、誰でもXRP Ledger上で代替可能なトークンを発行することができます。
代替可能トークンは交換可能で、互いに区別がつきません。トークンは交換可能で、同等の価値を持つ他のトークンと置き換えることができます。交換可能なトークンを作成するには、2つのアカウント間で会計関係の一種である「トラストライン」を設定し、それらのアカウント間で支払いを送信します。ほとんどのユースケースでは、最初に設定する必要がある設定もあります。
## トラストライン
トラストラインとは、XRP Ledgerにおける[トークン](../index.md)を保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。この制限は、XRP Ledgerのユースケースである[コミュニティクレジット](../index.md#コミュニティクレジット)などを実現するために不可欠なものです。
それぞれの「トラストライン」は、以下のような _双方向_ の関係から成り立っています。
- トラストラインが接続する **2つの[アカウント](../../accounts/index.md)** の識別子
- 一方のアカウントから見てプラス、他方のアカウントから見てマイナスとなる、単一の共有された**残高**
- 残高がマイナスのアカウントは、一般的にトークンの「発行者」とみなされます。ただし、[API](../../../references/http-websocket-apis/index.md)では、`issuer`という名称はどちらを指すこともあるようです。
- 様々な **設定** とメタデータ。2つのアカウントの _それぞれ_ は、トラストライン上の設定を制御することができます。
- 最も重要なことは、各サイドがトラストラインに **限度額** を設定できることです。これはデフォルトでは0です。各アカウントの残高は(トラストラインから見て)そのアカウントの上限を超えることはできません。ただし、[アカウント自身の操作](#限度額以上を保有する)を除きます。
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
トラストラインの残高は、それをどちらの側から見るかによって負または正になります。負の残高を持つ側は「発行者」と呼ばれ、トークンの振る舞いに関するいくつかのプロパティを制御できます。トークンを発行者ではない別のアカウントに送ると、そのトークンは発行者や、おそらく同じ通貨コードを使用している他のアカウントを通じて「ripple(波及)」します。これは便利な場合もありますが、予期しない望ましくない動作を引き起こす場合もあります。トラストラインに[No Rippleフラグ](rippling.md)を使用することで、トラストラインが波及しないようにすることができます。
## 作成
アカウントはいずれも、ゼロでない上限と独自の設定を持つ[TrustSetトランザクション][]を送信することによって、他のアカウントに対して一方的にトークンを「トラスト」することができます。これによって、残高ゼロのトラストラインが作成され、相手側の設定がデフォルトとして設定されます。
トラストラインは、[分散型取引所](../decentralized-exchange/index.md)でトークンを購入するときなど、いくつかのトランザクションによって暗黙的に作成されることがあります。この場合、トラストラインはデフォルト設定をそのまま使用します。
## 限度額以上を保有する
トラストラインの限度額よりも _大きい_ 残高を保有できるケースは次の3つがあります。
1. [トレード](../decentralized-exchange/index.md)によって、限度額以上のトークンを取得した場合
2. プラスの残高があるトラストラインの限度額を減らした場合
3. [チェックの現金化](../../payment-types/checks.md)によって、トークンを限度額以上取得する場合 (_[CheckCashMakesTrustLine amendment][]により追加されました。_)
## トラストラインの設定
アカウントごとに、共通残高のほかに、トラストラインの設定項目があり、その構成は以下のとおりです。
- **Limit**: 0から[トークンの上限量](../../../references/protocol/data-types/currency-formats.md)の範囲内の数字です。支払いや他のアカウントの操作によって、(このアカウントから見た)トラストラインの残高が限度額を超えることはできません。デフォルトは`0`です。
- **Authorized**: [Authorized Trust Lines](authorized-trust-lines.md)と併用し、このアカウントが発行するトークンを相手側に保持させることを許可するための値(true/false)です。デフォルトは`false`です。一度`true`に設定すると、元に戻すことはできません。
- **No Ripple**: トークンがこのトラストラインを通過して[ripple](rippling.md)するかどうかを設定するための値(true/false)です。デフォルトはアカウントの"Default Ripple"設定に依存します。新しいアカウントでは"Default Ripple"はoffで、つまり`true`がNo Rippleのデフォルト値となります。通常、発行者はrippleを許可し、非発行者はコミュニティクレジットのためにトラストラインを使用していない限り、rippleを無効にするべきです。
- **Freeze**: このトラストラインに[個別の凍結](freezes.md#individual-freeze)が適用されているかどうかを示す値(true/false)です。デフォルトは`false です。
- **Quality In** および **Quality Out**: この設定により、このトラストライン上の他のアカウントで発行されたトークンを額面より少なく（または多く）評価することができます。たとえば、ステーブルコインの発行者が、オフレッジャーにある同等の資産に対してトークンの引き出しに3%の手数料を課している場合、この設定を使用して、それらのトークンを額面の97%で評価することが可能です。デフォルトは`0`で、額面価格を表しています。
## 準備金と削除
トラストラインは台帳のスペースを使用するため、[トラストラインはあなたのアカウントが準備金として保持しなければならないXRPを増加させます](../../accounts/reserves.md)。 トラストラインのどちらか、または両方のアカウントにトラストラインの準備金が負担されることがあります。トラストラインの設定がデフォルトでない場合、またはプラス残高を保持している場合、所有者準備金の1つとしてカウントされます。
一般に、トラストラインを作成したアカウントが準備金を負担し、発行者は負担しないという意味です。<!-- STYLE_OVERRIDE: is responsible for -->
トラストラインは、両者の設定がデフォルトの状態で、残高が0であれば自動的に削除されます。つまり、トラストラインを削除するには次の方法があります。
1. 設定した内容をデフォルトに戻すために、[TrustSetトランザクション][]を送信する。
2. トラストラインにあるプラスの残高をすべて処分します。これは[支払い](../../payment-types/cross-currency-payments.md)によって通貨を送るか、[分散型取引所](../decentralized-exchange/index.md)で通貨を売却することで可能です。
残高がマイナス（あなたが発行者）の場合や、相手側の設定が初期状態でない場合、トラストラインを完全に削除させることはできませんが、同様の手順で所有者準備金にカウントされないようにすることが可能です。
**Authorized** の設定は、一度オンにするとオフにできないため、トラストラインの初期状態にはカウントされません。
## 無料のトラストライン
[[Source]](https://github.com/XRPLF/rippled/blob/72377e7bf25c4eaee5174186d2db3c6b4210946f/src/ripple/app/tx/impl/SetTrust.cpp#L148-L168)
トラストラインはXRP Ledgerの強力な機能であるため、アカウントの最初の2つのトラストラインを「無料」にする特別な機能が用意されています。
アカウントが新しいトラストラインを作成する際、台帳の中で新しいトラストラインを含む最大2つのオブジェクトを所有している場合、アカウントの所有者準備金は通常の量ではなく、0として扱われます。これにより、アカウントが台帳内のオブジェクトを所有するために必要な準備金の増加分を満たすだけのXRPを保有していない場合でも、取引を成功させることができます。
アカウントが台帳に3つ以上のオブジェクトを所有している場合、所有者準備金が全額適用されます。
## 関連項目
- **コンセプト:**
- [分散型取引所](../decentralized-exchange/index.md)
- [リップリング](rippling.md)
- **リファレンス:**
- [account_linesメソッド][] - 指定されたアカウントに関連付けられたトラストラインを確認
- [gateway_balancesメソッド][] - 発行者の発行残高を確認
- [RippleStateオブジェクト](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) - 台帳の状態データのうち、トラストラインのデータ形式
- [TrustSetトランザクション][] - トラストラインを作成・変更するトランザクション
{% raw-partial file="/docs/_snippets/common-links.md" /%}

116
@l10n/ja/docs/concepts/tokens/fungible-tokens/paths.md Normal file
View File

@@ -0,0 +1,116 @@
---
html: paths.html
parent: trust-lines-and-issuing.html
seo:
description: トークンによる支払いは、接続されているユーザのパスとオーダーブックを通す必要があります。
labels:
- 支払い
- クロスカレンシー
---
# パス
XRP Ledgerでは、[トークン](../index.md)の支払いが送金元から受取人に届くまでにたどる中間ステップの道筋をパスによって定義します。パスは、XRP Ledgerの[分散型取引所](../decentralized-exchange/index.md)の注文と[自動マーケットメーカー](../../../concepts/tokens/decentralized-exchange/automated-market-makers.md)を介して送金元と受取人を結び付けることで、[クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)を可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
XRPは任意のアドレスに直接送金できるため、[XRP間のトランザクション](../../payment-types/direct-xrp-payments.md)ではパスは使用されません。
## パスのステップ
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
* 同一通貨の別のアドレスを通じたRippling
* オーダーブックとAMMでの通貨の取引
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.md)をご覧ください。
[トークンとXRPの交換](../decentralized-exchange/index.md)は、オーダーブックまたはAMMを介して行われます。トランザクションは、送金元と受取人の間で最も良い交換レートを提供するオーダーブックまたはAMMを見つけるために、パスのステップを使用します。パスのステップは、通貨の変換先を指定しますが、オーダーブックのOfferの状態を記録しません。トランザクションの順序は、レジャーが検証されるまで確定しないため、トランザクションが取引するOfferやAMMを確定することはできません。(ただし、各トランザクションは最終的なレジャーで最良の利用可能な交換レートを取得します。)
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](../transfer-fees.md)、AMM手数料、トラストライン残高の増減、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
[{% inline-svg file="/docs/img/paths-examples.ja.svg" /%}](/docs/img/paths-examples.ja.svg "3つのパスの例を示す図")
# 技術詳細
## Pathfinding
`rippled` APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][]（WebSocketのみ）は、レジャーが閉鎖するか、またはサーバがより適切なパスを検出するたびに、フォローアップレスポンスによって検索を拡大します。
署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](../../../references/http-websocket-apis/public-api-methods/transaction-methods/submit.md#署名と送信モード)へのリクエストに`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
{% admonition type="warning" name="注意" %}`rippled`は可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できない`rippled`インスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。{% /admonition %}
パスの検出は、新しいレジャーが検証されるたびに数秒ごとに変化する非常に難しい課題であるため、`rippled`は完全に最適なパスを検出するようには設計されていません。ただし、いくつかの有効なパスを検出し、特定額の送金コストを推定することができます。
## 暗黙のステップ
規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](../../../references/protocol/transactions/types/payment.md)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
* パスの1番目のステップは、トランザクションの`Account`フィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。
* トランザクションに、そのトランザクションの送信者ではない`issuer`が指定されている`SendMax`フィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。
* `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](../../../references/protocol/transactions/types/payment.md#sendmaxおよびamountで使用する特殊なissuerの値)をご覧ください。
* トランザクションの`Amount`フィールドに、トランザクションの`Destination`とは異なる`issuer`が指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。
* 最後に、トランザクションの`Destination`フィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
## デフォルトパス
明示的に指定されたパスの他に、トランザクションは _デフォルトパス_ に沿って実行できます。デフォルトパスは、トランザクションの[暗黙のステップ](#暗黙のステップ)を接続する最も簡単な方法です。
デフォルトパスは次のいずれかになります。
* トランザクションで（イシュアーに関係なく）1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
* `SendMax`が省略されているか、または`SendMax`の`issuer`が送金元の場合、デフォルトパスが機能するためには送金元`Account`から宛先`Amount`の`issuer`へのトラストラインが必要です。
* `SendMax`と`Amount`に異なる`issuer`値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
* クロスカレンシー支払いの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックやAMMを使用します。
有効なすべてのデフォルトパスを次の図に示します。
[{% inline-svg file="/docs/img/default-paths.ja.svg" /%}](/docs/img/default-paths.ja.svg "デフォルトパスの図")
デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](../../../references/protocol/transactions/types/payment.md#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
## パスの仕様
パスセットは配列です。パスセットの各要素は、個々の _パス_ を表す別の配列です。パスの各要素は、ステップを指定するオブジェクトです。ステップのフィールドを次に示します。
| フィールド | 値 | 説明 |
|:-----------|:-----------------------|:---------------------------------------|
| `account` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップに`currency`フィールドまたは`issuer`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックやAMMを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
| `issuer` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨の発行者を定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップが発行者を定義します。`currency`が省略され、このフィールドが指定されている場合、発行者が異なる同名の通貨間でオーダーブックやAMMを使用するパスステップを示します。`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`フィールドが指定されています。 |
## 関連項目
- **コンセプト:**
- [クロスカレンシー支払い](../../payment-types/cross-currency-payments.md)
- [分散型取引所](../decentralized-exchange/index.md)
- [Partial Payments](../../payment-types/partial-payments.md)
- **リファレンス:**
- [Paymentトランザクション][]
- [path_findメソッド][]（WebSocketのみ）
- [ripple_path_findメソッド][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}

99
@l10n/ja/docs/concepts/tokens/fungible-tokens/rippling.md Normal file
View File

@@ -0,0 +1,99 @@
---
html: rippling.html
parent: trust-lines-and-issuing.html
seo:
description: Ripplingは、複数当事者間でのトークン残高の自動ネット決済です。
labels:
- トークン
- クロスカレンシー
---
# Rippling
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](index.md)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingはトークンの基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](../decentralized-exchange/offers.md)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
Ripplingは、支払[パス](paths.md)でのみ発生します。[XRP間の直接決済](../../payment-types/direct-xrp-payments.md)にはRipplingは使用されません。
発行アカウント以外のアカウントでは、Ripplingが望ましくない場合があります。Ripplingを使えば、他のユーザが同一通貨のイシュアー間で債権債務を移動できるようになるためです。このため、アカウントの[DefaultRippleフラグ](#defaultrippleフラグ)を有効にして、アカウントがデフォルトでRipplingを有効にしない限り、デフォルトでは[NoRippleフラグ](#norippleフラグ)により着信トラストラインでのRipplingが無効になっています。
{% admonition type="warning" name="注意" %}別のアドレスへのトラストラインを作成する場合、そのトラストラインのあなたの側でRipplingをブロックするには、tfSetNoRippleフラグを明示的に有効にする必要があります。{% /admonition %}
## Ripplingの例
「Rippling」は、支払いを行うために複数のトラストラインが調整されたときに発生します。たとえば、AliceがCharlieにお金を借りており、さらにAliceはBobからもお金を借りている場合、XRP Ledgerではトラストラインは次のようになります:
[{% inline-svg file="/docs/img/noripple-01.svg" /%}](/docs/img/noripple-01.svg "Charlie --($10)-- Alice -- ($20) -- Bob")
BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
[{% inline-svg file="/docs/img/noripple-02.svg" /%}](/docs/img/noripple-02.svg "Charlie --($13)-- Alice --($17)-- Bob")
2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
## NoRippleフラグ
発行アカウント以外のアカウント、特に手数料やポリシーが異なる複数のイシュアーの残高を保有している流動性プロバイダーは、一般的に残高がRipplingされることを望みません。
「NoRipple」フラグは、トラストライン上の設定です。2つのトラストラインの両方で、同じアドレスによってNoRippleが有効に設定されている場合、第三者からの支払を、これらのトラストラインでこのアドレスを通じて「Rippling」することはできません。これにより、同一通貨の複数イシュアー間で流動性プロバイダーの残高が予期せず移動されるのを防ぎます。
アカウントは1つのトラストラインでNoRippleを無効にできます。これにより、そのトラストラインを含む任意のペアを通じてのRipplingが可能になります。アカウントにてデフォルトでRipplingを有効にするには、[DefaultRippleフラグ](#defaultrippleフラグ)を有効にします。
たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
[{% inline-svg file="/docs/img/noripple-03.svg" /%}](/docs/img/noripple-03.svg "Charlie --（$10）-- 金融機関A --（$1）-- Emily --（$100）-- 金融機関B --（$2）-- Daniel")
CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
[{% inline-svg file="/docs/img/noripple-04.svg" /%}](/docs/img/noripple-04.svg "Charlie --（$0）-- 金融機関A --（$11）-- Emily --（$90）-- 金融機関B --（$12）-- Daniel")
この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
例:
[{% inline-svg file="/docs/img/noripple-05.svg" /%}](/docs/img/noripple-05.svg "Charlie --（$10）-- 金融機関A --（$1、NoRipple）-- Emily --（$100、NoRipple）-- 金融機関B --（$2）-- Daniel")
このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
### 詳細
NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
[{% inline-svg file="/docs/img/noripple-06.ja.svg" /%}](/docs/img/noripple-06.ja.svg "処理を行うためには同一アドレスによって両方のトラストラインにNoRippleが設定されている必要があることを示す図")
## DefaultRippleフラグ
DefaultRippleフラグは、デフォルトで着信トラストラインでのRipplingを有効にするアカウント設定です。ゲートウェイやその他の通貨イシュアーは、顧客が通貨を相互に送金できるようにするには、このフラグを有効にする必要があります。
アカウントのDefaultRipple設定は、他者があなたに対してオープンしたトラストラインにのみ影響し、あなたが作成するトラストラインには影響しません。アカウントのDefaultRipple設定を変更する場合、変更前に作成したトラストラインでは既存のNoRipple設定が維持されます。アドレスの新しいデフォルトに合わせてトラストラインのNoRipple設定を変更するには、[TrustSetトランザクション][]を使用します。
## NoRippleを使用する
<!--{# TODO: move these things into their own tutorials #}-->
### NoRippleを有効/無効にする
トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
[`rippled` API](../../../references/http-websocket-apis/index.md)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
### NoRippleステータスの確認
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
[`rippled` API](../../../references/http-websocket-apis/index.md)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
## 関連項目
- **コンセプト:**
- [パス](paths.md)
- **リファレンス:**
- [account_linesメソッド][]
- [account_infoメソッド][]
- [AccountSetトランザクション][]
- [TrustSetトランザクション][]
- [AccountRootのフラグ](../../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
- [RippleState（トラストライン）のフラグ](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestateのフラグ)
{% raw-partial file="/docs/_snippets/common-links.md" /%}

125
@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md Normal file
View File

@@ -0,0 +1,125 @@
---
html: stablecoin-compliance-guidelines.html
parent: stablecoins.html
seo:
description: ステーブルコインの発行者は、現地の規制を遵守し、適切な機関に報告する責任があります。
labels:
- トークン
---
# ステーブルコインのコンプライアンス指針
トークン発行者は、各国の規制を遵守し、適切な機関に報告する責任があります。規制は国や州によって異なりますが、以下のセクションで説明する報告やコンプライアンスの要件が含まれる場合があります。トークンを発行する前に、管轄区域やユースケースの要件について、専門家の法的助言を求める必要があります。以下のリソースは、背景情報として参考になる可能性があります。
### Know Your Customer (KYC)
KYC(Know Your Customer)とは、金融機関が犯罪行為に利用されるのを防ぐために、顧客の身元を特定し確認するために行うデューデリジェンス活動のことです。金融用語でいう犯罪行為には、マネーロンダリング、テロ資金調達、金融詐欺、個人情報盗難などが含まれます。顧客は、個人、仲介者、企業のいずれもあり得ます。
KYCプロセスは、一般的に次のことを目的としています。
- 顧客(組織や企業の場合は、実質的な所有者)の特定
- 取引関係の目的および意図された事項の理解
- 想定される取引活動の把握
KYCは、金融機関や関連企業にとって、リスク、特に法的リスクや風評リスクを軽減するために重要です。KYCプログラムが不十分であったり、存在しなかったりすると、金融機関や従業員個人に対して民事上・刑事上の罰則が科される可能性があります。
関連項目:
- [(米国）銀行秘密保護法／マネーロンダリング防止審査マニュアル](https://bsaaml.ffiec.gov/manual/Introduction/01)
- [金融活動作業部会(FATF)が定めたKYCに関する米国以外の基準について](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
### マネーロンダリング対策(AML)およびテロ資金供与防止対策(CFT)
マネーロンダリングとは、合法的な金融ルートや信頼できる機関を通じて合法的に資金を入手または分配できるように、資金源、性質、所有者を偽装することによって違法な資金を移動させるプロセスのことです。つまり、「汚いお金」を「きれいなお金」に変えることです。アンチマネーロンダリング（AML）とは、マネーロンダリングの発生を阻止するために設計された法律と手続きを指します。
テロ資金供与とは、テロ活動に従事する組織、またはテロやその拡散を支援する組織に対する資金の勧誘、収集、提供のことを指します。。テロ資金供与防止対策(CFT)とは、テロ資金に使われる資金の流れを特定、報告、阻止するプロセスを指します。
関連項目:
- ["マネーロンダリングとテロリズム・拡散の資金調達との闘いに関する国際基準" FATF、2012年](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
- ["仮想通貨： 主要な定義と潜在的なAML/CFTリスク". FATF、2014年](http://www.fatf-gafi.org/publications/methodsandtrends/documents/virtual-currency-definitions-aml-cft-risk.html)
### 資金源
金融機関は、不正な資金がシステムを通過するのを防ぐために、顧客の資金源が犯罪行為と関連しているかどうかを合理的に判断する必要があります。
すべての顧客の正確な資金源を特定することは、管理上実行不可能な場合があります。その結果、規制当局の中には、すべての口座について特定の規制やガイダンスを提供しない場合もある。しかし、特定の場合には、当局は金融機関に対して資金源を特定し報告することを求めることができる。FATFのガイダンスでは、マネーロンダリングやテロ資金供与のリスクが高い場合(一般に「リスクに応じたアプローチ」と呼ばれる)、金融機関は顧客の資金源を特定することを含むがこれに限定されないデューデリジェンスの強化を行うことを勧告しています。
### 疑わしい取引の報告
金融機関は、資金が犯罪行為に関連している可能性があると疑われる場合、適切な規制当局に疑わしい取引の届出/Suspicious Activity Report (SAR)を提出する必要があります。疑わしい取引を報告しなかった場合、金融機関は罰則を受ける可能性があります。
関連項目:
- [不審行為報告書の概要(米国FFIEC)](https://bsaaml.ffiec.gov/manual/RegulatoryRequirements/04_ep)
- [FATF勧告16：不審な取引の報告およびコンプライアンス](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
### トラベルルール
トラベルルールとは、銀行機密保護法(BSA)に基づき、資金送金が米ドル換算で3,000ドル以上の場合、資金送金を行う金融機関に特定の情報を次の金融機関に転送することを義務付けるルールです。送金指示書には、以下の情報を記載する必要があります。
- 送信者の氏名
- 送信者の口座番号(使用する場合)
- 送信者の住所
- 送金者の金融機関の名称
- 送信指示の金額
- 送金注文の金額、送金注文の実行日
- 受取人の金融機関の名称
関連項目:
- [ファンドの「トラベル」規制について： 質問と回答](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers)
### 手数料の開示と資金の追跡
- 米国では、Dodd Frank 1073 Electronic Fund Transfer Act (Regulation E)により、銀行は米国発の国際決済について、為替レート、手数料、外国の指定受取人が受け取る金額など、コストと配送条件に関する情報を提供することが義務付けられています。「Pre-payment disclosure」は国際電子決済を依頼する際に消費者に提供され、「Receiption disclosure」は消費者が送金を許可する際に消費者に提供されます。
関連項目
- [消費者金融保護局の説明による、銀行に対する規制とその適用範囲について](https://www.consumerfinance.gov/rules-policy/final-rules/electronic-fund-transfers-regulation-e/#rule)
- 欧州連合(EU)では、EU資金移動規制により、マネーロンダリングやテロ資金供与を検知、調査、防止するために、送金元の銀行、受取人の銀行、仲介銀行がトランザクションの詳細に支払人と受取人の特定の情報を含めることが義務付けられています。
関連項目:
- [EU規則(EC) No 1781/2006の説明](http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2006:345:0001:0009:EN:PDF)
- [2017年6月26日より施行 資金移動に付随する情報に関する規則2015/847号](http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32015R0847)
### 外国資産管理局(OFAC)
外国資産管理局(OFAC)は、米国財務省の機関であり、米国の外交政策および国家安全保障上の目的を支援するために、経済制裁および貿易制裁を管理・執行しています。すべての米国人、米国法人およびその海外支店は、OFACの規制に従う必要があります。OFACの規制では、米国の金融機関は、OFACの許可または法令による明示的な除外がない限り、OFACが管理・執行する制裁または禁輸プログラム下の個人、団体、または国との取引およびその他の取引を行うことが禁止されています。
関連項目:
- [OFAC関連資料の一覧](https://www.treasury.gov/resource-center/faqs/Sanctions/Pages/ques_index.aspx)
### 暗号資産・マネーサービス事業に関する指針
- 米国:
- [仮想通貨に関するFinCENのガイダンスと定義(2013年3月18日付)](https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-persons-administering)
- [FinCEN、仮想通貨のマイナーと投資家に関する2つの裁定を発表 2014年1月30日](https://www.fincen.gov/news/news-releases/fincen-publishes-two-rulings-virtual-currency-miners-and-investors)
- ヨーロッパ:
- [仮想通貨に関する欧州銀行監督機構意見書(2014年7月4日付)](http://www.eba.europa.eu/documents/10180/657547/EBA-Op-2014-08+Opinion+on+Virtual+Currencies.pdf)
- FATFの金融事業者向けガイダンス:
- [金融活動作業部会、2009年7月](http://www.fatf-gafi.org/media/fatf/documents/reports/Guidance-RBA-money-value-transfer-services.pdf)

101
@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/configuration.md Normal file
View File

@@ -0,0 +1,101 @@
---
html: stablecoin-configuration.html
parent: stablecoins.html
seo:
description: ステーブルコインの設定を行い、ステーブルコインの機能を詳細に調整します。
labels:
- トークン
---
# ステーブルコイン発行者の設定
トークンの発行を始める前に、XRP Ledgerアカウントで設定する必要がある項目がいくつかあります。これらの設定の例については、[代替可能トークンの発行](../../../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)をご覧ください。
設定すべき項目は以下の通りです。
| 設定 | 備考 |
|-----------------------|------|
| Default Ripple | 発行者は、このフィールドを**必ず**有効にする必要があります。 |
| Deposit Authorization | 明示的に承認していないユーザからの入金をすべてブロックします。 |
| Require Auth | トークンの保持を、明示的に承認したユーザに限定します。 |
| Tick Size | 分散型取引所の取引所為替レートを四捨五入して、より迅速な価格決定を可能にします。 |
| Transfer Fee | ユーザ同士がトークンを送信する際に、一定割合の手数料を徴収します。 |
## Default Ripple
Default Rippleフラグは、トラストラインの残高をデフォルトで[Ripplingを許可](../rippling.md)するかどうかを制御します。Ripplingは顧客同士のトークンの送信や取引を可能にするものなので、発行者はその発行アドレスへのすべてのトラストラインでのRipplingを許可しなければなりません(MUST)。
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行者はそのアドレスのDefault Rippleフラグを有効にする必要があります。そうでない場合、発行者は、他のアドレスが作成した各トラストラインのNo Rippleフラグを個別に無効化する必要があります。
運用ウォレットやスタンバイウォレットなど、他のアドレスではDefault Rippleフラグを有効にすべきではありません。
## Deposit Authorization
Deposit Authorizationの設定は、以下のいずれかを行わない限り、アカウントへのすべての入金をブロックします。
- 事前に送信者を認可している。
- 資金を受け取るためにトランザクションを送信します。例えば、他人が作成したエスクローを終了させるなど。
Deposit Authorizationは、不要なXRPの支払いをブロックするのに最も有効です。なぜなら、発行元へのトラストラインを作成しない限り、既にトークンを受け取ることはできないからです。しかし、ステーブルコインの発行者としては、ステーブルコインをレジャー外の価値と交換するために、ユーザからの支払いを受け取ることができる必要があります。顧客を事前認可することはできますが、そうすると、顧客それぞれのアドレスについてレジャーにオブジェクトを格納する必要があり、準備金が大幅に増加します。
したがって、未知または制裁を受けたエンティティからお金を受け取ることに関する規制要件を満たすために必要でない限り、Deposit Authorizationはステーブルコインの発行者に推奨されません。
より詳細な情報は[Deposit Authorization](../../../accounts/depositauth.md)をご覧ください。
## Disallow Incoming Trust Line
Disallow Incoming Trust Lineの設定は、他のユーザがアドレスにトラストラインを開くことを防ぎます。予防措置として、運用アドレスと待機アドレスでこの設定を有効にすることで、誤ってこれらのアカウントからトークンを発行できないようにします。発行アドレスではこの設定を有効にしないでください。
この設定を有効にするには、[AccountSetトランザクション](../../../../references/protocol/transactions/types/accountset.md)で`"SetFlag"： 15` (`asfDisallowIncomingTrustline`)を設定します。
## Disallow XRP
Disallow XRPの設定は、XRP Ledgerのユーザが誤ってXRPをアドレスに送信することを阻止するために設計されています。これは、XRPの受信と保持を意図していないアドレスからの不必要な返金コストと労力を削減するものです。なぜなら、そうすることでアドレスがXRPを誤って送金した場合に返金されずにXRPを失う可能性があるからです。クライアントアプリケーションは、デフォルトでDisallow XRPフラグを尊重すべきですが、ユーザがそれを無視することを許可する場合もあります。
DisallowXRPフラグは任意ですが、もしあなたが顧客からXRPを受け取るつもりがないのであれば、発行アドレスとすべての運用アドレスでこのフラグを有効にしておくとよいでしょう。
## Require Auth
Require Authの設定は、事前にトラストラインを明示的に承認しない限り、発行したトークンをユーザが保持することをブロックします。XRP Ledger内で誰があなたのトークンを保持するかが重要である場合、規制要件を満たすためにこの設定を使用することができます。しかし、この設定は、ユーザへの承認がトークンを使用するためのボトルネックとなるため、トークンの利便性を低下させる可能性があります。
また、トラストラインを認可するたびに発行アドレスを使用する必要があります。多くのトラストラインを認可する必要がある場合、発行アドレスを頻繁に使用することになるため、発行アドレスのセキュリティが損なわれる可能性があります。(発行アドレスの使用頻度が少ない場合は、秘密鍵の保護を強化することができます。使用頻度が高ければ高いほど、その保護は大きな負担となります)。
詳しくは[認可トラストライン](../authorized-trust-lines.md)をご覧ください。
## Tick Size
Tick Sizeは、[分散型取引所](../../decentralized-exchange/index.md)で為替レートを計算する際に使用する小数点以下の桁数を制御する設定です。Tick Sizeを大きくすると、より精度が高くなり、さまざまな取引の金額で丸め込みが少なくなります。取引は主に取引レートに基づいてランク付けされるため、トレーダーがリストの上位にわずかな金額を提供することができるため、精度が高すぎると不都合になることがあります。Tick Sizeを小さくすると、オークションの最低入札額と同じような効果があり、無関係な小額を徐々に入札する時間と労力が省けます。しかし、Tick Sizeを小さくすると四捨五入が多くなり、取引コストが高くなります。また、四捨五入前は完全に一致するように見えた2つのオファーが、四捨五入後は一致しなくなるという意外な結果になることもあります。
Tick Sizeはアカウントレベルの設定であり、同じアドレスで発行されたすべてのトークンに適用されます。
Tick Sizeは取引レートの精度を制御するだけで、トークン自体の精度を制御するものではありません。ユーザは、トークンの発行者が設定したTick Sizeに関係なく、非常に大きな金額や非常に小さな金額を送ったり保有したりすることができます。
詳しくは[Tick Size](../../decentralized-exchange/ticksize.md)をご覧ください。
## Transfer Fees
Transfer Feesは、ユーザ同士がトークンを送金する際に、一定割合の手数料を請求するものです。送金手数料は、トークンを発行したり、発行アドレスで直接トークンを交換したりする場合には適用されません。(ユーザが発行アドレスに送金するときには適用されません。)同じアドレスから複数のトークンを発行する場合、すべてのトークンに対して同じ送金手数料が適用されます。
ユーザが送金手数料が設定されたトークンを送信すると、送信側から送金先金額に加えて送金手数料の金額が引き落とされますが、受信側には送金先金額のみが入金されます。手数料の金額はXRP Ledgerから「消える」のです。ステーブルコインの発行者としては、XRP Ledgerの外にある準備金にそれだけ自己資本が増える、言い換えれば、ユーザが送金手数料を支払うたびに担保として持っておく必要がある金額が減少することを意味します。
プロトコルレベルでは、送金手数料はアカウント設定の`TransferRate`で定義され、これは10億から20億までの整数で指定されます。
詳しくは[送金手数料](../../transfer-fees.md)をご覧ください。
### 運用アドレスと待機アドレスによる送金手数料
運用アドレスや待機アドレスを含むすべてのXRP Ledgerアドレスは、トークンを送信する際に発行者の送金手数料がかかります。送金手数料をゼロ以外に設定した場合、運用アドレスや待機アドレスから支払いを行う際に、(送金手数料を支払うために)余分に送金しなければなりません。つまり、これらのアドレスは、支払いを行うたびに、あなたの発行アドレスが作った残高を少し返金する必要があります。
トランザクションパラメータ`SendMax`を送信先の`Amount`パラメータよりも`TransferRate`設定に基づく割合で高く設定します。
{% admonition type="info" name="注記" %}発行アドレスから、または発行アドレスへ直接トークンを送信する場合、送金手数料は適用されません。発行アドレスは、常にそのトークンをXRP Ledgerの額面価格で受け入れなければなりません。つまり、顧客が発行アドレスに直接支払いを送る場合は送金手数料を支払う必要はありませんが、運用アドレスに送る場合は支払う必要があります。両方のアドレスで支払いを受け付ける場合、顧客が運用アドレスに支払いを送る際に、顧客が支払う送金手数料を補うために、記録システムで顧客に入金する金額を調整する必要がある場合があります。{% /admonition %}
例えば、次のようなものです。ACMEが送金手数料を1％に設定した場合、顧客のアドレスからACMEの発行アドレスに5 EUR.ACMEを届けるためのXRP Ledger支払いは、ちょうど5 EUR.ACMEの費用がかかります。しかし、顧客は5 EUR.ACMEをACMEの運用アドレスに届けるために、5.05 EUR.ACMEを送る必要があります。ACMEの運用アドレスへの支払いを顧客に入金する際、ACMEは運用アドレスに届けられた金額と送金手数料を顧客に入金し、顧客はACMEのシステムで5.05ユーロを受け取ることができます。

38
@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/index.md Normal file
View File

@@ -0,0 +1,38 @@
---
html: stablecoins.html
parent: trust-lines-and-issuing.html
seo:
description: XRP Ledger上で取引される一般的なステーブルコインには5種類あります。
labels:
- XRP
- ステーブルコイン
---
# ステーブルコイン
ステーブルコインは、XRP Ledgerの外の資産の価値を保持し、レジャー上の同等の価値を表すトークンを発行します。この種類の発行者は、そのサービスを通じてXRP Ledgerの内外に通貨を移動させることができるため、 _ゲートウェイ_ と呼ばれることがあります。もしトークンの裏付けとなる資産が、レジャー上のトークンと同じ金額と額面であれば、そのトークンは"ステーブルコイン"とみなすことができます。
ステーブルコインの発行者は、トークンをXRP Ledgerの外の世界の実際の通貨や資産と交換するために、_入金_ と _出金_ の機能を提供する必要があります。
実際には、XRP Ledgerはコンピュータシステムであり、それ自身の外部にルールを強制することはできないため、XRP Ledger上のステーブルコインはその発行者に依存しています。もしあなたが、そのステーブルコインの発行者があなたのトークンを要求に応じて本物と交換してくれることを期待できないのであれば、そのステーブルコインがその価値を維持することを期待すべきではありません。ユーザとしては、トークンを発行しているのが誰なのか、信頼性があり、合法的で、支払能力があるのか、に気を配る必要があります。そうでない場合は、そのトークンを保有しない方がよいでしょう。
XRP Ledgerで取引される通貨トークンには、一般的に5つの種類があります。
## 法定通貨による担保
法定通貨を担保とするステーブルコインは、EUR、USD、YENなどの既存の通貨に基づいています。取引レートは1:1です。これはシンプルで安定したオプションですが、中央集権的でハッキングの影響を受けやすいという欠点があります。最も厳密な「ステーブルコイン」の定義では、100%法定通貨で担保されたトークンのみが対象となります。
## 暗号資産による担保
暗号通貨を担保とするステーブルコインは、フィアット担保のステーブルコインと似ていますが、一定額の暗号通貨を担保として準備します。非中央集権的で、カストディアンや監査、規制を必要としません。また、ボラティリティが高く、基礎となる暗号通貨の安定性に依存します。
## コモディティによる担保
コモディティを担保とするステーブルコインは、金、不動産、石油、電力などの交換可能な資産に基づいています。コモディティは比較的安定していて流動性がありますが、中央集権的で、その価値を確認するために定期的な監査が必要です。
## 金融商品による担保
ステーブルコインは、債券や株式などの金融商品で裏付けすることができます。
## 担保なし
非担保トークンは、トークンの供給や売却をアルゴリズム生成スマートコントラクトに依存し、中央銀行が通貨を印刷・破棄するアプローチに似ています。トークンの発行に担保は必要ありません。価値は、価格を安定させるアルゴリズムを通じて需要と供給によって制御されます。非担保トークンはボラティリティが高いため、一般的にステーブルコインとはみなされません。

55
@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/precautions.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: stablecoin-precautions.html
parent: stablecoins.html
seo:
description: XRPLでステーブルコイン資金の入出金時の注意点を説明します。
labels:
- トークン
---
# ステーブルコインに関する注意事項
XRP Ledgerとの間の決済処理には当然リスクが伴いますので、発行者はこれらの処理を実施する際に十分な注意を払う必要があります。ステーブルコインの発行者としては、以下の注意点を考慮する必要があります。
## インフラストラクチャ
あなた自身のセキュリティとネットワークの安定性のために、XRP Ledgerを利用する事業者は、1つの[バリデータ](../../../networks-and-servers/rippled-server-modes.md#validators)を含む[独自のXRP Ledgerサーバ](../../../../infrastructure/installation/index.md)を実行すべきです。
## ツールのセキュリティ
XRP Ledgerのトランザクションを送信する際には、秘密鍵を使って署名する必要があります。秘密鍵は、あなたのXRP Ledgerアドレスを完全にコントロールします。秘密鍵を他人が運営するサーバに決して送らないでください。自身のサーバを使うか、クライアントライブラリを使ってローカルでトランザクションに署名してください。安全な設定の手順と例については、[安全な署名の設定](../../../transactions/secure-signing.md)をご覧ください。
XRP Ledgerへの接続方法は、ニーズや既存のソフトウェアに応じて、いくつかのインターフェイスを使用することができます。
- [HTTP / WebSocket API](../../../../references/http-websocket-apis/index.md)は、XRP Ledgerのすべてのコア機能への低レベルのインターフェースとして使用することができます。
- [クライアントライブラリ](../../../../references/client-libraries.md)は、いくつかのプログラミング言語で利用でき、XRP Ledgerにアクセスするための便利なユーティリティを提供します。
- その他、[xApps](https://xumm.readme.io/docs/xapps)などのツールも利用可能です。
- サードパーティのウォレットアプリケーションも、特に待機アドレスの担当者には便利かもしれません。
ただし、公式な配布チャネルから信頼できるツールだけを使用するように注意してください。悪意のあるサーバ、ライブラリ、アプリは、攻撃者に秘密鍵を漏らすように設定されている可能性があります。
## XRP Ledgerからの送金
XRP Ledgerから送金を受ける際、プロセスや統合ソフトウェアが悪用されることのないよう、いつ送金が確定したかを把握し、正しい金額を顧客にクレジットすることが重要です。詳細とよくある落とし穴については、[入金のモニタリング](../../../payment-types/robustly-monitoring-for-payments.md)をご覧ください。
予期しない、または不要な支払いを受け取った場合の標準的な対応は、送信者にそれを返却することです。追加費用を発生させずにこれを行う方法の詳細については、[不明な入金の返金](../../../payment-types/bouncing-payments.md)をご覧ください。
XRP Ledgerからの支払いを処理する前に、顧客の身元を確認してください。そうすることで、匿名の攻撃者による詐欺が難しくなります。ほとんどのマネーロンダリング対策規制は、いずれにせよこの確認を要求しています。XRP Ledgerから送金するユーザは、XRP Ledgerで最初にお金を受け取ったユーザとは異なる可能性があるため、これは特に重要です。詳しくは、[ステーブルコインのコンプライアンス指針](compliance-guidelines.md)をご覧ください。
## XRP Ledgerへの送金
XRP Ledgerに送金を行う際には、手数料の過払いや迂回経路を避けるため、ベストプラクティスに従ってください。詳しくは[顧客への送金](../../../payment-types/sending-payments-to-customers.md)をご覧ください。
銀行預金やクレジット/デビット決済など、外部システムからの支払いを受け入れる場合は、可逆的な入金に注意してください。XRP Ledgerの支払いは不可逆ですが、他の多くのデジタル支払いはそうではありません。詐欺師はこれを悪用し、あなたがすでにXRP Ledgerの支払いを送った後に、XRPL以外の取引をキャンセルすることで、元金を取り戻すことができます。
さらに、停電やネットワーク停止のようなまれな状況でも、XRP Ledgerのトランザクションの最終結果を確実に知ることができるように、[信頼できるトランザクションの送信](../../../transactions/reliable-transaction-submission.md)に従ってください。
## その他の注意事項
- XRP Ledger内の債務と残高を追跡し、担保口座の資産と比較してください。両者が一致しない場合は、不一致を解決するまで引き出しと入金の処理を停止してください。
- 曖昧な状況を避けてください。すべてのアドレスで適切な設定を行うことで、誤って間違ったアドレスからトークンを発行したり、ユーザが間違った場所に送金したりするようなケースを避けることができます。推奨事項については、[ステーブルコインの設定](configuration.md)をご覧ください。
- 疑わしい行動や不正な行動を監視します。例えば、ユーザがXRP Ledgerに繰り返し資金を出し入れすることで、実質的に運用アドレスの残高を空にするサービス拒否攻撃が可能です。XRP Ledgerの支払いを処理しないことで、そのアドレスが疑わしい行動に関与している顧客を一時停止します。

101
@l10n/ja/docs/concepts/tokens/fungible-tokens/stablecoins/settings.md Normal file
View File

@@ -0,0 +1,101 @@
---
html: stablecoin-settings.html
parent: stablecoins.html
seo:
description: Settings to configure before issuing your stablecoin.
labels:
- XRP
- ステーブルコイン
---
# ステーブルコインの設定
新しいステーブルコインを発行する前に、最初にコインを発行すると変更不可能とする設定を行う必要があります。
## 発行および配布アカウントの作成
「コールド」ウォレットと呼ばれることもある、「発行者」として指定する新しいアカウントを作成します。アカウント自体には特別な違いはありません。このアカウントを使ってステーブルコインを発行します。
ほとんどの実装では、"ウォーム"ウォレットとしてスタンバイアカウントを使用します。信頼できる人間のオペレータは、スタンバイアカウントを使用してステーブルコインを運用アカウントに配布します。
<div align="center">
<img src="img/uc-stablecoin-distribution-flow.png" height="50%" width="50%"></image>
</div>
運用アカウント、または「ホット」ウォレットは、XRPL上で他のアカウントと取引します。自動化されたインターネット接続システムは、これらのアドレスの秘密鍵を使用して、顧客やパートナーへの送金などの日常業務を行います。
スタンバイアカウントと運用アカウントを使用することで、発行アカウントをハッキング攻撃から守ることができ、またステーブルコインの作成と破棄を監視しやすくなります。
## 取引手数料の設定
送金手数料の設定は、アカウント間でトークンを送金する際にパーセンテージの手数料をユーザに請求します。
ユーザが送金手数料ありのトークンを送信すると、送信側からは送信金額に加えて送金手数料が引き落とされ、受信側には送信金額のみが入金されます。送金手数料の金額はXRP Ledgerから「消滅」します。つまり、ユーザが送金手数料を支払うたびに、担保として保持する必要のある金額が減少するのです。
詳しくは[送金手数料](../../transfer-fees.md)をご覧ください。
## ティックサイズの設定
ティックサイズは、[分散型取引所](../../decentralized-exchange/index.md)で取引レートを計算する際に使用される小数点以下の桁数を制御します。ティックサイズが大きいほど(小数点以下の桁数が多いほど)精度が高くなり、さまざまな取引金額の四捨五入が少なくなります。ティックサイズが小さいほど、オークションにおける最低入札額と同じように機能し、無駄に小さい金額で徐々に価格を競り上げる時間と労力を節約できます。
ティックサイズはアカウントレベルの設定で、同じアドレスで発行されたすべてのトークンに適用されます。
[ティックサイズ](../../decentralized-exchange/ticksize.md)をご覧ください。
## Default Rippleフラグの設定
Default Rippleフラグはトラストラインの残高をデフォルトでRipple(波及)させるかどうかを制御します。Ripplingは顧客間でトークンを送ったり取引したりすることを可能にするものです。発行者はその発行アドレスへの全てのトラストラインでRipplingを許可しなければなりません(MUST)。
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行アドレスのDefault Rippleフラグを有効にしてください。そうでない場合は、他のアドレスが作成したトラストラインごとに、個別にNo Rippleフラグを無効にする必要があります。
[Rippling](../rippling.md)をご覧ください。
## 宛先タグの有効化
ステーブルコインのアプリケーションが複数の顧客の代わりにトランザクションを処理する場合、どのアカウントに入金すべきかがわからないことがあります。宛先タグは、送金者に受取人や送金先を指定させることで、このような状況を回避するのに役立ちます。RequireDestフラグを有効にするには、`AccountSet`トランザクションの`SetFlag`フィールドに`asfRequireDest`値(1)を設定してください。
[送信元と送信先のタグ](../../../transactions/source-and-destination-tags.md)をご覧ください。
## 資産の管理機能
ステーブルコインの作成と配布をコントロールするには、いくつかのオプションがあります。
### 認可トラストライン
KYC(Know Your Customer)やAML(Anti-Money Laundering)などのコンプライアンスルールに従う必要がある場合、トラストラインを使用して、ステーブルコインの配布を許可されたプールを作成することができます。これにより、資金が誰に送金されるかを確認することができます。
[認可トラストライン](../authorized-trust-lines.md)をご覧ください。
### Freezeフラグ
保有者アカウント内のステーブルコインを凍結することができます。これは、詐欺行為が疑われる場合、または保有を強制する場合に行うことができます。個々のトラストラインを凍結することも、グローバルに凍結することもできます。
逆に、トークンを凍結する能力を永久に放棄する「No Freeze」を設定することもできます。これにより、発行者がトークン同士の取引を妨害でき無くなるという意味で、そのステーブルコインはより現実の通貨に近くなります。
[トークンの凍結](../freezes.md)をご覧ください。
### Clawbackフラグ
_([Clawback amendment](/resources/known-amendments.md#clawback) が必要です。)_
Clawbackにより、特定の状況下でトラストラインからステーブルコインを回収(クローバック)することができます。これにより、アカウントへのアクセス不能や悪意のある活動などの課題に対応する能力が追加されます。
[Clawback](../../../../references/protocol/transactions/types/clawback.md)をご覧ください。
### 固定供給量
ステーブルコインを固定枚数に制限することで、将来さらにトークンを発行することになっても、ステーブルコインの価値が希釈されないことが保証されます。
固定供給とするためには、
1. 発行するウォレットと同様の設定で配布ウォレットを作成します。
2. 発行ウォレットと配布ウォレットの間にトラストラインを設定します。
3. 発行ウォレットから配布ウォレットにすべてのトークンを送信します。
4. 発行アカウントをブラックホール化します。

78
@l10n/ja/docs/concepts/tokens/index.md Normal file
View File

@@ -0,0 +1,78 @@
---
parent: concepts.html
html: tokens.html
seo:
description: XRP Ledger上でデジタルな価値を表すトークンを作成することができます。
labels:
- トークン
---
# トークン
XRP以外のすべての資産は、XRP Ledgerでは **トークン** として扱うことができます。通常のトークンは、アカウント間の[トラストライン](fungible-tokens/index.md) と呼ばれる関係で管理されます。すべてのアカウントは、トークンを保有することを許可する他のアカウントにはトークンを発行できますが、トークンを必要としないアカウントに一方的にトークンを配付することはできません。トークンは、台帳の外に存在する資産に裏付けられた「ステーブルコイン」、XRP Ledger上で独自に作成された純粋なデジタルトークン、コミュニティクレジットなど、様々な種類の価値を表すことが出来ます。
{% admonition type="info" name="注記" %}XRP Ledger上のトークンは、過去に「IOUs」（[I-owe-you](https://en.wikipedia.org/wiki/IOU)の略）および「発行済み通貨」とも呼ばれてきました。しかし、これらの呼称は、XRP Ledgerのトークンが表すことのできるデジタル資産の全範囲をカバーしていないため、望ましくないとされています。<!-- STYLE_OVERRIDE: ious -->{% /admonition %}
通常のトークンは代替可能です。つまり、同じトークンはすべて代替可能であり、区別がつきません。非代替トークン(NFT)も可能です。XRP Ledgerでのネイティブ対応の詳細については、[非代替トークン(NFT)](nfts/index.md)をご覧ください。
トークンは[クロスカレンシー支払い](../payment-types/cross-currency-payments.md)に使用でき、[分散型取引所(DEX)](decentralized-exchange/index.md)で取引することができます。
トラストラインの残高は、どちら側から見るかによって、プラスまたはマイナスで表されます。マイナスの残高を持つ側は「発行者」と呼ばれ、そのトークンに関するいくつかの機能を設定することができます。発行者ではない別のアカウントにトークンを送ると、それらのトークンは発行者、場合によっては同じ通貨コードを使用している他のアカウントに「ripple」します。これは便利な場合もありますが、想定外の挙動を引き起こす可能性もあります。トラストラインに[No Ripple flag](fungible-tokens/rippling.md)を使用すると、トラストラインがripplingしないように設定することができます。
## ステーブルコイン
XRP Ledger におけるトークンの代表的なモデルとして、発行者が XRP Ledgerの外部に価値ある資産を保有し、その価値を表すトークンをLedger上で発行するというものがあります。このタイプの発行者は、そのサービスを通じてXRP Ledgerに通貨を送受信できることから、 _ゲートウェイ_ と呼ばれることもあります。トークンの裏付けとなる資産が、台帳上のトークンと同じ金額と額面を使用している場合、そのトークンは「ステーブルコイン」といえるでしょう。なぜなら、そのトークンと台帳外の資産との交換レートは理論上1：1で安定するはずだからです。
ステーブルコインの発行者は、XRP Ledgerの外側において、トークンを実際の通貨や資産と交換するための _入金_ と _出金_ のサービスを提供する必要があります。
実際には、XRP Ledger はただのシステムであり、その外側にいかなるルールも適用することはできません。そのため、XRP Ledger上のステーブルコインは、その発行者を信頼し、その発行者が要求に応じてトークンを現物資産へ交換することができなければ、そのステーブルコインの価値が維持されないと考えるべきでしょう。ユーザは、誰がトークンを発行しているのか、信頼できるのか、合法的なのか、支払能力があるのか、という点について十分に注意をしなければなりません。信頼できない場合は、そのトークンを保有するべきではないでしょう。
[Stablecoin Issuer](../../use-cases/tokenization/stablecoin-issuer.md)をご覧ください。
## コミュニティクレジット
XRP Ledgerのもう一つの利用方法として、「コミュニティクレジット」という、知人同士がXRP Ledgerを利用して、誰が誰にいくら借金があるのかを把握する仕組みがあります。この借金を自動的かつアトミックに活用し、[rippling](fungible-tokens/rippling.md)を通じて支払いを決済できるのが、XRP Ledgerの優れた機能です。
例えば、AsheeshがMarcusに20ドル、MarcusがBharathに50ドルの借金がある場合、BharathはAsheeshのMarcusに対する借金を帳消しにする代わりに、その分のMarcusに対する借金を帳消しすることによってAsheeshに20ドルを「支払う」ことができる。逆もまた可能である。AsheeshはMarcusを通してBharathに支払うことで、それぞれの負債を減らすことができるのです。XRP Ledgerは、このように複雑な連鎖的な取引を、中間にいるアカウントが何もせずとも、単一の取引で決済することができるのです。
このタイプの使用法については、[paths](fungible-tokens/paths.md)をご覧ください。<!--{# TODO: コミュニティクレジットのもっと例示的なページへのリンクができるといいですね。#}-->
## その他のトークン
XRP Ledgerで発行されるトークンには、その他にも使用例があります。例えば、セカンダリアドレスに一定数量の通貨を発行し、発行者に「キーを渡す」ことで、「ICO（Initial Coin Offering）」を行うことができます。
{% admonition type="danger" name="警告" %}ICOは米国では[証券と見なされ、規制対象となる](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings)可能性があります。{% /admonition %}
金融サービスビジネスを始める前に、関連規制を調査されることを強くお勧めします。
## トークンの特性
XRP Ledgerにおけるトークンは、[XRPと異なる性質](../../references/protocol/data-types/currency-formats.md#comparison)を持ちます。トークンは常に _トラストライン内_ に存在し、トークンのすべての移動はトラストラインに沿って行われます。他のアカウントに、トラストラインに設定された上限を超えるトークンを保有させることはできません。(自分のトラストラインを制限以上に増やすことは _可能_ です。例えば、[分散型取引所](decentralized-exchange/index.md)でさらに購入したり、すでにプラスの残高がある状態で上限値を下げたりすることができます。)
トークンは、精度が15桁の10進数（基数10）と指数を用いて、非常に大きな値（最大9999999999999999×10<sup>80</sup>）から、非常に小さな値（最小1.0×10<sup>-81</sup>まで）を表現することができます。
必要なトラストラインが設定されていれば、誰でも[Paymentトランザクション][]を送信することでトークンを発行することができます。トークンを発行者に送り返せば、トークンを「burn」することができます。また、発行者の設定により、[クロスカレンシー支払い](../payment-types/cross-currency-payments.md)やトレードでトークンをさらに生み出せるケースもあります。
発行者は、ユーザがトークンを送金する際に自動で差し引かれる「送金手数料」(transfer-fees.html)を設定することができます。発行者は、自分のトークンを含む取引レートの[ティックサイズ](decentralized-exchange/ticksize.md)を定義することもできます。発行者と一般アカウントのどちらも、トラストラインを[凍結](fungible-tokens/freezes.md)することができ、トラストライン内のトークンの使用方法を制限することができます。( XRPにはこのいずれも適用されません。)
トークン発行の技術的な手順については、[代替可能トークンの発行](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md) をご覧ください。
## 関連項目
- **コンセプト:**
- [XRP?](../../introduction/what-is-xrp.md)
- [クロスカレンシー支払い](../payment-types/cross-currency-payments.md)
- [分散型取引所](decentralized-exchange/index.md)
- **チュートリアル:**
- [代替可能トークンの発行](../../tutorials/how-tos/use-tokens/issue-a-fungible-token.md)
- [XRP Ledgerゲートウェイの開設](../../use-cases/tokenization/stablecoin-issuer.md)
- [トランザクションの結果の確認](../transactions/finality-of-results/look-up-transaction-results.md)
- [専門化した支払いタイプの使用](../../tutorials/how-tos/use-specialized-payment-types/index.md)
- **リファレンス:**
- [Paymentトランザクション][]
- [TrustSetトランザクション][]
- [RippleStateオブジェクト](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md)
- [account_linesメソッド][]
- [account_currenciesメソッド][]
- [gateway_balancesメソッド][]
{% raw-partial file="/docs/_snippets/common-links.md" /%}

58
@l10n/ja/docs/concepts/tokens/nfts/authorizing-another-minter.md Normal file
View File

@@ -0,0 +1,58 @@
---
html: nftoken-authorized-minting.html
parent: non-fungible-tokens.html
seo:
description: NFTのMintを他のアカウントに代行してもらうことができます。
labels:
- 非代替性トークン, NFT
---
# NFT処理を他のアカウントに委任
各アカウントは、自分に代わってNFTをMintすることができる認可されたMinterを最大一人設定することができまます。認可Minter機能を利用することで、クリエイターは別のアカウントにNFTをMintさせることができ、より多くのNFTを作ることに集中することができます。
## 認可Minterの割り当て
認可Minterを`AccountSet`トランザクションで設定します。
```js
tx_json = {
"TransactionType": "AccountSet",
"Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
"NFTokenMinter": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
"SetFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
}
```
`NFTokenMinter` 同じXRP Ledgerインスタンス上のアカウントのIDです。`asfAuthorizedNFTokenMinter`フラグは`NFTokenMinter`に指定するアカウントが`Account`の代理としてNFTをMintすることを許可します。
*注記*: `asfAuthorizedNFTokenMinter`フラグは`AccountSet`トランザクションでのみ使用されます。これは、トランザクションがAccountRoot上のNFTokenMinterフィールドの存在または値に影響を与えるかどうかを示します。実際、AccountRootには対応するフラグはありません。
## 認可Minterの割り当て解除
認可Minterを削除するには、`AccountSet`トランザクションを使用して、`asfAuthorizedNFTokenMinter`フラグをクリアしてください。
```js
tx_json = {
"TransactionType": "AccountSet",
"Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
"ClearFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
}
```
## 他のアカウントのNFTをMintする
標準的な `NFTokenMint` トランザクションを使用して、別のアカウントのNFTをMintすることができます。違いは、`Issuer`フィールド、つまりNFTをMintするアカウントのIDを含める必要があることです。
```js
const transactionBlob = {
"TransactionType": "NFTokenMint",
"Account": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
"URI": xrpl.convertStringToHex("ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"),
"Flags": 8,
"TransferFee": 5000,
"NFTokenTaxon": 0,
"Issuer": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m", // 別アカウントでMintする際に必要
}
```
NFTの所有者がNFTを売却した場合、取引手数料（売却額に対する割合）が`Issuer`に指定したアカウントに送金されまれます。

40
@l10n/ja/docs/concepts/tokens/nfts/batch-minting.md Normal file
View File

@@ -0,0 +1,40 @@
---
html: nftoken-batch-minting.html
parent: non-fungible-tokens.html
seo:
description: NFTokenオブジェクトを一括でMintする。
labels:
- 非代替性トークン, NFT
---
# NFTのバッチMint
NFTokenオブジェクトを一括でMintする方法には、一般的に、オンデマンドでMintする方法とスクリプトでMintする方法の2つがあります。
## オンデマンドMint (遅延Minting)
オンデマンドMintモデルを使用する場合、発行者または潜在的購入者は、XRP LedgerからNFTokenオブジェクトの初期販売に対して購入または売却オファーを出します。初期販売を開始する準備ができたら、トークンをMintして、売却オファーを作成するか、購入オファーを受け入れて、取引を完了させます。
### メリット
* 売れ残りのNFTokenオブジェクトを保有するための準備金が発生しません。
* 売れると分かった時点でリアルタイムにNFTokenオブジェクトをMintします。 <!-- STYLE_OVERRIDE: will -->
### デメリット
NFTokenオブジェクトの初回販売以前の市場活動は、XRP Ledgerには記録されません。これは、一部のアプリケーションでは問題にならない場合があります。
## スクリプトMinting
プログラムまたはスクリプトを使用して、一度に多数のトークンをMintします。[チケット](../../accounts/tickets.md)を使えば、1度に200件までのトランザクションを並行して処理することができます。
実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](../../../tutorials/javascript/nfts/batch-mint-nfts.md)をご覧ください
### メリット
* NFToken オブジェクトは事前にMintされます。
* NFTokenオブジェクトの初回販売の市場活動は台帳に記録されます。
### デメリット
NFTokenオブジェクトをMintする際には、[準備金要件](../../accounts/reserves.md)を満たす必要があります。目安としては、現在の準備金レートで、NFTokenオブジェクトあたりおよそ1/12XRPです。十分なXRPがない場合は、XRPが調達できるまで、Mintトランザクションは失敗します。

17
@l10n/ja/docs/concepts/tokens/nfts/collections.md Normal file
View File

@@ -0,0 +1,17 @@
---
html: nft-collections.html
parent: non-fungible-tokens.html
seo:
description: NFTのTaxonフィールドを使用して、NFTをコレクションとしてミントすることができます。
labels:
- 非代替性トークン, NFT
---
# NFTのコレクション化
`NFTokenTaxon`フィールドを使用すると、NFTをコレクションにグループ化することができます。ミント担当者は、`0x0`から`0xFFFFFFF`までの任意の数値を選択し、NFTを作成する際にそれを割り当てることができます。Taxon(分類群)の定義付けは完全に自由です。
例えば、最初のコレクションでは、`NFTokenTaxon`を`1`に設定します。NFTのコレクションで、Taxonの値が`316`、`420`、`911`であるものがあるかもしれません。NFTの種類を示すために、数字で始まるタクソンを使用することもできます（たとえば、すべての不動産NFTは`2`で始まるTaxonを持っているなど）。
`NFTokenTaxon`フィールドは必須ですが、コレクションを作成するつもりがなければ`0`を設定するのもよいでしょう。
[NFTokenの分類群](../../../references/protocol/data-types/nftoken.md#nftokentaxon分類群)をご覧ください。

23
@l10n/ja/docs/concepts/tokens/nfts/guaranteeing-a-fixed-supply.md Normal file
View File

@@ -0,0 +1,23 @@
---
html: nft-fixed-supply.html
parent: non-fungible-tokens.html
seo:
description: 新しいアカウントを使って一定数のNFTをミントし、そのアカウントをブラックホール化します。
labels:
- 非代替性トークン, NFT
---
# NFTの固定供給
プロジェクトによっては、発行アカウントから一定数以上のNFTがミントされないことを保証したい場合があります。
一定数のNFTを保証するためには、
1. 新しいアカウント、_発行者_ を作成し、資金を提供します。このアカウントは、コレクション内のトークンの発行者となります。[アカウントの作成](../../accounts/index.md#アカウントの作成)をご覧ください。
1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](authorizing-another-minter.md)をご覧ください。
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[Mintのバッチ処理](batch-minting.md)をご覧ください
1. 発行者の認可Minterである自分の運用するウォレットを削除するために、`AccountSet`を使用します。
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](../../../tutorials/how-tos/manage-account-settings/disable-master-key-pair.md)をご覧ください。
この時点で、発行者のアドレスを発行アカウントとする新たなトークンのミントは不可能となります。
{% admonition type="warning" name="注意" %}一度、アカウントを「ブラックホール化」すると、あなた自身を含め、誰も将来のNFTの販売に対するロイヤリティを受け取ることができなくなります。{% /admonition %}

44
@l10n/ja/docs/concepts/tokens/nfts/index.md Normal file
View File

@@ -0,0 +1,44 @@
---
html: non-fungible-tokens.html
parent: tokens.html
seo:
description: XRPL NFTを紹介します。
labels:
- 非代替性トークン, NFT
---
# 非代替性トークン(NFT)
XRP Ledgerは、非代替性トークン(NFT)をネイティブにサポートしています。 非代替性トークンは、芸術作品やゲーム内アイテムなど、ユニークな物理的、非物理的、あるいは純粋なデジタル商品の所有権を証明する役割を果たします。
_([NonFungibleTokensV1_1 amendment][]により追加されました。)_
このようなデジタル資産を表現するには、XRP LedgerのNon-Fungible Tokens機能（スタンダードドラフト番号で[XLS-20](https://github.com/XRPLF/XRPL-Standards/discussions/46)と呼ばれることもあります）を使用します。
## XRP Ledger上のNFT
XRP Ledger上では、non-fungible tokenは[NFToken][]オブジェクトとして表されます。NFTokenはユニークで分割できない単位で、決済には使用できません。ユーザはこのようなトークンを発行（作成）、保有、購入、売却、焼却（破棄）することができます。
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の`NFToken`オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の`NFToken`オブジェクトに対する[準備金](../../accounts/reserves.md)は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
また、アカウントは、自分に代わってNFTokenオブジェクトを発行・販売するブローカー（代理発行者）を指定することができます。
`NFToken`オブジェクトは、トークンが発行された時点で確定し、後で変更することが出来ない設定項目を持ちます。これらは以下の通りです。
- トークンを一意に定義する各種識別データ。
- 発行者が、現在の保有者に関係なく、トークンを焼却できるかどうか。
- トークンの保持者がトークンを他者に転送できるかどうか。(`NFToken`は常に発行者に直接送信したり、発行者から送信することが可能です)。
- 転送が許可されている場合、発行者は販売価格に対する一定の割合で手数料を徴収することができます。
- NFTokenを[トークン](../index.md)で売却できるか、XRPのみでしか売却できないか。
## `NFToken`のライフサイクル
誰もが[NFTokenMint トランザクション][]を使って新しい`NFToken`を作成することができます。`NFToken`は発行者アカウントの[NFTokenPage オブジェクト][]に格納されます。所有者または利害関係者は[NFTokenCreateOffer トランザクション][]を送信して`NFToken`の売買を提案できます。レジャーは提案された転送を[NFTokenOffer オブジェクト][]として追跡し、一方が承諾またはキャンセルすると`NFTokenOffer`を削除します。`NFToken`が転送可能であれば、アカウント間で複数回取引することができます。
[NFTokenBurn トランザクション][]を使用して、自分が所有する`NFToken`を破棄することができます。発行者が`tfBurnable`フラグを有効にしてトークンを発行した場合、発行者は現在の所有者に関係なくトークンを破棄することが可能です。(例えば、あるイベントのチケットを表すトークンである場合、そのチケットをある時点で消費するといった場合に便利です)。
![The NFT Lifecycle](/docs/img/nft-lifecycle.png "NFT Lifecycle Image")
`NFToken`オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](trading.md)をご覧ください。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

55
@l10n/ja/docs/concepts/tokens/nfts/nft-apis.md Normal file
View File

@@ -0,0 +1,55 @@
---
html: nft-apis.html
parent: non-fungible-tokens.html
seo:
description: 専用のAPIを使用すると、有用なNFTメタデータにアクセスできます。
labels:
- 非代替性トークン, NFT
---
# NFTのAPI
このページでは、NFTに関連するトランザクションとリクエストを一覧でご紹介します。
## NFTのオブジェクト
- [NFToken][]データ型 - 台帳に保存されるNFTのオブジェクト。
- レジャーオブジェクト
- [NFTokenOfferオブジェクト][] - NFTを売買するためのオファー。
- [NFTokenPageオブジェクト][] - NFTページは最大32個のNFTオブジェクトを保持します。実際には、各NFTページは通常16～24個のNFTを保持します。
## NFTのトランザクション
- [NFTokenMint][] - NFTをミントする。
- [NFTokenCreateOffer][] - NFTを売買するためのオファーを作成します。
- [NFTokenCancelOffer][] - NFTを売買するためのオファーをキャンセルします。
- [NFTokenAcceptOffer][] - NFTを売買するためのオファーを承認します。
- [NFTokenBurn][] - 永久的にNFTをバーンします。
## NFTのリクエスト
- [account_nftsメソッド][] - アカウントが所有するNFTのリストを取得します。
- [nft_buy_offersメソッド][] - 指定したNFTokenオブジェクトの購入オファーのリストを取得します。
- [nft_sell_offersメソッド][] - 指定したNFTokenオブジェクトの売却オファーのリストを取得します。
- [subscribeメソッド][] - 特定のテーマに関する最新情報をリッスンします。例えば、マーケットプレイスは、自身のプラットフォームに出品されているNFTのステータスに関する最新情報をリアルタイムで提供することができます。
- [unsubscribeメソッド][] - 特定のテーマに関する最新情報のリッスンを停止します。
## Clio
Clioサーバは、キャッシュに基づいて情報のリクエストを処理することで、ネットワーク全体のパフォーマンスを向上させ、XRP Ledger上のバリデータをトランザクション処理に集中させることができます。一般的なXRP Ledgerのリクエストタイプに加えて、Clioサーバはより詳細なレスポンスを提供する追加のリクエストタイプを処理します。
### Clio特有のNFTのリクエスト
- [nft_info](../../../references/http-websocket-apis/public-api-methods/clio-methods/nft_info.md) - 指定されたNFTに関する現在のステータスを取得します。
- [nft_history](../../../references/http-websocket-apis/public-api-methods/clio-methods/nft_history.md) - 指定されたNFTの過去のトランザクションメタデータを取得します。
<!--
[nfts_by_issuer](nfts_by_issuer.html) - 指定した発行者が作成したNFTの一覧を取得します。
-->
パブリックClioサーバにアクセスするには、そのURLとClioポート（通常51233）にリクエストを送信します。パブリックClio APIサーバには、SLAも優先的に処理する責任もありません。ビジネスユースケースで継続的な監視や情報リクエストが必要な場合は、独自のClioサーバインスタンスをセットアップすることを検討してください。[UbuntuにClioをインストール](../../../infrastructure/installation/install-clio-on-ubuntu.md)をご覧ください。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

15
@l10n/ja/docs/concepts/tokens/nfts/non-transferable-tokens.md Normal file
View File

@@ -0,0 +1,15 @@
---
seo:
description: ユーザ間で売買ができないNFTを作成する
labels:
- 非代替性トークン, NFT
---
# 譲渡不可トークン
XRP Ledgerは、[非代替性トークン](./index.md)の一種として、ソウルバウンドトークン(SBT/SoulBound Token)と呼ばれることもある譲渡不可トークン(NTT/Non-Transferable Token)をサポートしています。譲渡不可トークンは、証明書やIDトークン、ゲームにおける実績、あるいはトークンの目的が特定の一人に限定されるような場合に使用されます。
XRP Ledger内のNFTで**Transferable**フラグが無効になっているものは、譲渡不可トークンです。このフラグは、NFTをミントするために利用する[NFTokenMintトランザクション][]にて設定されます。NFTがミントされると、譲渡可能かどうかは[NFTokenオブジェクト](/ja/docs/references/protocol/data-types/nftoken/)の`lsfTransferable`フラグで記録されます。
譲渡不可トークンは、トークンの発行者からまたは発行者へ直接トークンを送信することはできますが、第三者間でトークンを譲渡することはできません。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

29
@l10n/ja/docs/concepts/tokens/nfts/payload-storage.md Normal file
View File

@@ -0,0 +1,29 @@
---
html: nft-storage.html
parent: non-fungible-tokens.html
seo:
description: NFTのペイロードのストレージオプション。
labels:
- 非代替性トークン, NFT
---
# NFTペイロードのストレージ
NFTはブロックチェーン上で作成されます。しかし、メディア、メタデータ、属性を含むNFTのコンテンツは、XRP Ledger上、XRP Ledger外の分散型、XRP Ledger外の中央集権型など、様々な方法で保存することができます。
## XRP Ledger上
データが256バイトより小さい場合は、`data://`URIを使用し、URIフィールドに直接埋め込むことを検討することができます。これには、信頼性が高く、永続的で、レスポンス性の高いデータベースにデータを保存できるという利点があります。
## 分散型, XRP Ledger外
NFTのメタデータには、既存の分散ストレージソリューションを使用できます。
IPFSやArweaveは分散化ソリューションを提供しています。しかし、メタデータの効率的なフェッチが問題になることがあります。IPFSやArweaveに直接クエリしてメタデータをフェッチするのは、高品質なメディアを含むNFTの複数ページをスクロールするユーザからのすばやいレスポンスを必要とする最新のウェブサイトには十分な速度ではありません。
クラウドストレージソリューションの例については、ブログポスト[NFT Payload Storage Options](https://dev.to/ripplexdev/nft-payload-storage-options-569i)をご覧ください。
## 中央集権型, XRP Ledger外
URIフィールドを使用して、ペイロードが提供されるWebサーバを指定できます。
別の方法として、レジャー上のスペースを節約するために、`AccountSet`を使用して発行者の`Domain`フィールドを設定し、トークンのNFT IDをそのドメイン上のパスとして扱うこともできます。例えば、NFTのIDが`123ABC`で、発行者のドメインが`example.com`の場合、ペイロードは`example.com/tokens/123ABC`から送信されます。

67
@l10n/ja/docs/concepts/tokens/nfts/reserve-requirements.md Normal file
View File

@@ -0,0 +1,67 @@
---
html: nft-reserve-requirements.html
parent: non-fungible-tokens.html
seo:
description: NFTのMintと保有に必要な準備金について学びましょう。
labels:
- 非代替性トークン, NFT
---
# NFTの準備金要件
NFTをミントし、保有し、販売するためには、XRPを準備金として保有しておく必要があります。準備金の額は急激に膨れ上がる可能性があります。準備金の要件を理解することは、ビジネスケースに最適なアプローチを選択するのに役立ちます。
## 基本準備金
アカウントでは、基本準備金（現在10XRP）を用意する必要があります。基本準備金のXRPの金額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)をご覧ください。
## 所有者準備金
XRP Ledgerで所有する各オブジェクトには、現在2XRPの所有者準備金が必要とされています。これは、ユーザが不必要なデータで台帳にスパムをかけることを抑制し、不要になったデータを削除することを促すためのものです。所有者準備金の額は変更される可能性があります。[基本準備金と所有者準備金](../../accounts/reserves.md#基本準備金と所有者準備金)をご覧ください。
NFTの場合、 _オブジェクト_ はそれぞれのNFTを指すのではなく、アカウントが所有する`NFTokenPage`オブジェクトを指します。`NFTokenPage`オブジェクトは最大32個のNFTを格納することができます。
しかし、NFTは使用するスペースを最小限にするため、ページに集約されることはありません。64個のNFTがある場合、`NFTokenPage`オブジェクトが2つだけとは限りません。
目安として、それぞれの`NFTokenPage`には平均して24NFTが格納されると考えてください。
したがって、 _N_ 個のNFTをミントまたは所有するために必要な準備金は、(24N)/2、つまりNFTあたり1/12XRPと見積もることができます。
NFTの保有枚数や保有ページ数によって、所有者準備金の総額がどの程度になるか、次の表に例を示します。
| NFTの保有数 | 最良のケース | 標準的なケース | 最悪のケース |
|:------------|:----------|:-------------|:-----------|
| 32以下 | 2 XRP | 2 XRP | 2 XRP |
| 50 | 4 XRP | 6 XRP | 8 XRP |
| 200 | 14 XRP | 18 XRP | 26 XRP |
| 1000 | 64 XRP | 84 XRP | 126 XRP |
## `NFTokenOffer`の準備金
各`NFTokenOffer`オブジェクトは、オファーを出すアカウントに対して準備金の1つの増加を必要とします。この記事の執筆時点では、準備金の増分は2XRPです。準備金は、オファーをキャンセルすることで取り戻すことができます。また、オファーが受け入れられると、XRP Ledgerからオファーが削除され、準備金は取り戻されます。
## Practical Considerations
NFTをミントし、保有し、売買のオファーをする場合、必要な準備金は急激に膨れ上がる可能性があります。その結果、取引中にアカウントの残高が必要準備金を下回ることがあります。必要準備金を下回ると、XRPLでの取引が制限されることがあります。[必要準備金を下回る](../../accounts/reserves.md#必要準備金を下回る)をご覧ください。
新しいアカウントを作成し、NFTをミントし、XRP Ledgerに`NFTokenSellOffer`を作成する場合、最低14XRPが準備金として必要です。
| 準備金の種類 | 準備金の額 |
|:--------------------|--------:|
| 基本 | 10 XRP |
| NFTokenページ | 2 XRP |
| NFTokenオファー | 2 XRP |
| 合計 | 14 XRP |
| | |
{% admonition type="info" name="注記" %}準備金要件ではありませんが、ミントと売却のプロセスにおけるトランザクションの些細な手数料（通常12drops、または.000012XRP）を負担するために、少なくとも必要準備金より1XRPより多く用意しておきくべきです。{% /admonition %}
仮に200個のNFTをミントし、それぞれに「NFTokenSellOffer」を作成すると、436XRPもの準備金が必要になります。
| 準備金の種類 | 準備金の額 |
|:--------------------|--------:|
| 基本 | 10 XRP |
| NFTokenページ | 26 XRP |
| NFTokenオファー | 400 XRP |
| 合計 | 436 XRP |
| | |
必要準備金の額が余裕を持って確保できる額を超える場合は、オンデマンドミントモデルを使用して、一度に保有するNFTとオファーの数を減らすことを検討してください。[オンデマンドMint](batch-minting.md#オンデマンドmint-遅延minting)をご覧ください。

64
@l10n/ja/docs/concepts/tokens/nfts/running-an-nft-auction.md Normal file
View File

@@ -0,0 +1,64 @@
---
html: nftoken-auctions.html
parent: non-fungible-tokens.html
seo:
description: NFTのMintを他のアカウントに代行してもらうことができます。
labels:
- 非代替性トークン, NFT
---
# NFTオークションの実施
オークションの運営にはいくつかの方法があり、それぞれにメリットとデメリットがあります。
## XRPL外でオークションを行い、XRPL上で取引を成立させる
このフローが最もわかりやすいと思います。`NFTokenOffer`オブジェクトは常にその作成者によってキャンセルされる可能性があるため、拘束力のあるオファーを実装することはできないことに注意してください。
1. 入札内容を非公開のデータベースに保存します。
2. 落札額の一部を手数料として徴収します。
3. 買い手/売り手へXRPLトランザクションを送信し、取引を完了させます。
## 最低落札価格ありのオークション
最低落札価格ありのオークションとして、ブローカー方式で運営する。
![ブローカー方式で最低落札価格ありのオークション](/docs/img/nft-auction1.png "ブローカー方式で最低落札価格ありのオークション")
1. 売り手はNFTを作成し，`NFTokenCreateOffer`を用い，ブローカーアカウントを宛先に設定して，オークションの最低落札価格を設定します。
1. 入札者は`NFTokenCreateOffer`を使ってオファーを出し、ブローカーアカウントを宛先として設定します。
1. ブローカーは落札した入札を選択し、`NFTokenAcceptOffer`を使用して取引を成立させ、ブローカー手数料を徴収します。その後、ブローカーは`NFTokenCancelOffer`を使って競り負けた入札をキャンセルします。
**長所:**
- ブローカー手数料を含め、すべてのオークションはXRPLで行われます。
- 売り手は最低落札価格をオンチェーンで表示します。
- これは買い手側にとって、拘束力のあるオファーに近いものです。
**短所:**
- 売り手とブローカーの間には、ブローカーが事前に合意したレート以上を取らないという暗黙の信頼関係が必要です。最低落札価格が1XRPで、落札価格が1000XRPだった場合、ブローカーが999XRPを手数料として徴収し、売り手には最低落札価格の利益しか残らないということが起き得ます。これを防ぐオンチェーンの仕組みは存在しません。
このデメリットの大きな軽減要素は、もしこのような行動が起これば、ブローカーは市場シェアをすべて失うことになるため、売り手はこの点を理解すべきです。
## 最低落札価格なしのオークション
この3つのうち、最も複雑なワークフローとなります。
![ブローカー方式で最低落札価格なしのオークション](/docs/img/nft-auction2.png "ブローカー方式で最低落札価格なしのオークション")
1. 売り手は`NFTokenMint`を使用してNFTを作成します。
1. 入札者は`NFTokenCreateOffer`を使って、ブローカーを宛先としてオファーを出します。
1. ブローカーは落札者を選択し、手数料として徴収する金額を差し引いた後、`NFTokenCreateOffer`を介してこの金額で売却のための署名を売り手に要求します。
1. 売り手は要求されたオファーに署名し、宛先としてブローカーを設定します。
1. ブローカーは`NFTokenAcceptOffer`を使って取引を完了させ、ブローカー手数料を受け取ります。
1. ブローカーは`NFTokenCancelOffer`を使って競り負けた入札をキャンセルします。
**長所:**
- このフローは参加者間のトラストが全く必要ないため、ほとんどの人がブロックチェーン上で期待するオプションとなっています。
- 売り手はブローカーが手数料をいくら徴収するか正確に把握でき、チェーン上でそれに同意しなければなりません。
**短所:**
- オークション終了後は、売り手が最終入札額とブローカー手数料の額に合意することが売却の条件となります。つまり、売り手はオークション終了後に出品を取り消すことができ、また、売り手は注意散漫や通知を見逃すことで、決済を遅らせてしまうことがありえます。
- オークション終了後、出品者は落札を拒否し、他の出品者に売却することができてしまいます。

81
@l10n/ja/docs/concepts/tokens/nfts/trading.md Normal file
View File

@@ -0,0 +1,81 @@
---
name: NFTの取引
html: non-fungible-token-transfers.html
parent: non-fungible-tokens.html
seo:
description: NFTokenをダイレクトモードまたはブローカーモードで取引する。
labels:
- 非代替性トークン, NFT
---
# XRP Ledger上でNFTokenを売買する
XRP Ledger上のアカウント間で`NFToken`オブジェクトを転送することができます。`NFToken`の売買をオファーしたり、他のアカウントから自分が保有するNFTokenへの売買オファーを受け入れることができます。`NFToken`を無料(価格が0)で売却することで、`NFToken`を配布することもできます。すべてのオファーは[NFTokenCreateOfferトランザクション][]を使って作成されます。
_([NonFungibleTokensV1_1 amendment][]により追加されました)_
## 売却オファー
### 売却オファーの作成
`NFToken`オブジェクトの所有者であれば、`tfSellToken`フラグを指定して[NFTokenCreateOfferトランザクション][]を使用して売却オファーを作成することができます。`NFTokenID`と、対価として受け取る金額`Amount`を指定します。オプションで、そのオファーが無効になる`Expiration`と、その`NFToken`を購入することができる唯一のアカウントである`Destination`を指定することができます。
### 売却オファーを受け入れる
販売されている`NFToken`を購入するには、`NFTokenAcceptOffer`トランザクションを使用します。`NFTokenOffer`オブジェクトの所有者アカウントと`NFTokenOfferID`を指定し、受け入れることを決定します。
## 購入オファー
### 購入オファーの作成
どのアカウントでも`NFToken`の購入オファーを作成することができます。`tfSellToken`のフラグを指定せずに、[NFTokenCreateOffer][]を使用することで、購入オファーを作成することが可能です。`Owner`アカウント、`NFTokenID`、オファーの`Amount`を指定します。
### 購入オファーを受け入れる
`NFTokenAcceptOffer`トランザクションを使用して`NFToken`を転送します。`NFTokenOfferID`と所有者アカウントを指定して、トランザクションを完了させてください。
## 取引モード
`NFToken`を取引する場合、購入者と販売者の間で直接取引を行う、 _ダイレクト_ 取引と、第三者の口座が売りと買いのオファーをマッチングして取引を仲介する、 _ブローカー_ 取引を選択することができます。
ダイレクトモードでの取引では、販売者が転送をコントロールすることができます。販売者は誰でも購入できるように`NFToken`を出品するか、特定の取引先アカウントに`NFToken`を販売することができます。販売者はNFTokenの販売価格全額を受け取ります。
ブローカーモードでは、販売者は第三者のアカウントに`NFToken`の販売を仲介させます。ブローカーアカウントは、合意したレートで仲介手数料を徴収し、転送を行います。購入はリアルタイムで完了し、ブローカーと販売者には購入資金から支払われ、ブローカーによる前払いは必要ありません。
### ブローカーモードを使用する場合
`NFToken`の作成者が適切な購入者を探す時間と忍耐力がある場合、作成者は販売から得たすべての収益を得ることができます。これは、少数の`NFToken`オブジェクトを様々な価格で販売するクリエイターにとって、非常に有効な方法です。
一方、クリエイターは、創作に時間を割くことができるのに、販売に時間を割くのは抵抗があるのではないでしょうか。そのような場合、個別に対応するのではなく、第三者であるブローカーのアカウントに販売業務を委託することが可能です。
ブローカーを利用すると、いくつかの利点があります。例えば
* ブローカーは仲介者として、`NFToken`の販売価格を最大化するために活動することができます。ブローカーが販売価格の何割かを受け取る場合、価格が高ければ高いほど、ブローカーの収入も増えます。
* ブローカーは、ニッチな市場や価格帯などの基準に基づいて`NFToken`オブジェクトの管理を行う管理者として活動することができます。これによって、クリエイターの作品を発見できないような購入者のグループを呼び込むことができるでしょう。
* ブローカーは、Opensea.ioのようなマーケットプレイスとして機能し、アプリケーション層でオークション機能を提供することもできます。
### ブローカー販売のワークフロー
最も単純なワークフローでは、クリエイターが新しい`NFToken`を発行します。クリエイターは売却オファーを作成する際、最低売却価格を入力し、売却先にブローカーを設定します。購入希望者はブローカーを経由して`NFToken`に入札を行います。ブローカーは落札者を選び、取引を完了させ、ブローカー手数料を受け取ります。ベストプラクティスとして、ブローカーは`NFToken`に対して残っている購入オファーをすべてキャンセルします。
![Brokered Mode with Reserve](/docs/img/nft-brokered-mode-with-reserve.png)
もう1つのワークフローは、クリエイターが販売をよりコントロールできるようにするものです。このワークフローでは、クリエイターが新しい`NFToken`を発行します。入札者はオファーを作成し、ブローカーを宛先として設定します。ブローカーは落札者を選び、仲介手数料を差し引き、`NFTokenCreateOffer`を使用してクリエイターに署名の依頼をします。クリエーターは要求されたオファーに署名し、ブローカーを宛先として設定します。ブローカーは`NFTokenAcceptOffer`を使って売却を完了し、仲介手数料を保持します。ブローカーは`NFTokenCancelOffer`を使用して`NFToken`に対する残りの入札をキャンセルします。
![Brokered Mode without Reserve](/docs/img/nft-brokered-mode-without-reserve.png)
所有者が他のアカウントで作成した`NFToken`をリセールする場合にも、同じワークフローを使用することができます。
{% raw-partial file="/docs/_snippets/common-links.md" /%}

82
@l10n/ja/docs/concepts/tokens/transfer-fees.md Normal file
View File

@@ -0,0 +1,82 @@
---
html: transfer-fees.html
parent: tokens.html
seo:
description: トークンの発行者は、自己のトークンの送金に手数料を課すことができます。
labels:
- 手数料
- トークン
---
# 送金手数料
[トークン](index.md)の発行者は、`TransferRate`の設定を使用して、ユーザに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づく割合で引き落とされ、送金先へ入金されます。差額が送金手数料となります。
標準的なトークンの場合、送金手数料として支払われたトークンはバーンされ、XRP Ledgerでは記録されなくなります。トークンがレジャー外の資産で裏付けされている場合、これは発行者がXRP Ledgerでの債務を果たすために準備金として保有しなければならないそれらの資産の量を減らします。送金手数料は通常、外部資産で裏付けられていないトークンには適切ではありません。
非代替性トークンにも送金手数料がかかりますが、その仕組みは異なります。詳細は[非代替性トークン](nfts/index.md)をご覧ください。
送金手数料は、発行アカウントと直接送受信する場合には適用されませんが、[運用アドレス](../accounts/account-types.md)から他のユーザへ送金する場合には適用されます。
XRPは発行者が存在しないため、送金手数料がかかることはありません。
## 例
この例では、ACME銀行はXRP Ledger上でEURステーブルコインを発行します。ACME Bankは送金手数料を1%に設定するかもしれません。支払いの受取人が2 EUR.ACMEを得るためには、送金者は2.02 EUR.ACMEを送らなければなりません。トランザクションの後、XRP LedgerにおけるACMEの未払い債務は0.02ユーロ減少し、ACMEはEURステーブルコインの裏付けとなる銀行口座にその金額を保持する必要がなくなります。
以下の図は、AliceからCharlieへの2EUR.ACMEのXRP Ledger支払いを、送金手数料1%で表しています。
[{% inline-svg file="/docs/img/transfer-fees.ja.svg" /%}](/docs/img/transfer-fees.ja.svg "Aliceが2,02€を送金し、Charlieが2,00€を受け取り、ACMEはXRP Ledgerで0,02€を受け取ります。")
会計用語では、Alice、ACME、Charlieの貸借対照表はこのように変わっているでしょう。
[{% inline-svg file="/docs/img/transfer-fees-balance-sheets.ja.svg" /%}](/docs/img/transfer-fees-balance-sheets.ja.svg "Aliceの資産は2,02€減少、Charlieは2,00€増加、ACMEの負債は0,02€減少。")
## ペイメントパスでの送金手数料
<!--{# TODO: Update this for OnwerPaysFee amendment when that gets added #}-->
送金手数料は、各送金においてイシュアンスが発行アカウントを通じて当事者間を移動するたびに適用されます。さらに複雑なトランザクションでは、手数料が複数回適用されます。送金手数料は、送金の終わりの時点から逆方向に適用されるので、最終的には支払いの送金者がすべての手数料をカバーするのに十分な額を送金する必要があります。例:
[{% inline-svg file="/docs/img/transfer-fees-in-paths.ja.svg" /%}](/docs/img/transfer-fees-in-paths.ja.svg "手数料が適用されたクロスカレンシー支払いの図")
このシナリオでは、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設定は同一アカウントにより発行されるすべての通貨に適用されます。通貨によって異なる送金手数料のパーセンテージを適用するには、通貨ごとに異なる発行アドレスを使用します。
送金手数料は`TransferRate`フィールドで指定します。このフィールドは受信者が同じトークンを10億単位で取得するために送金しなければならない金額を表す整数です。`TransferRate`が`1005000000`の場合、送金手数料は0.5%に相当します。デフォルトでは`TransferRate`は0%に設定されています。`TransferRate`の値を`1000000000`未満（"0%"未満の手数料）または`2000000000`以上（”100%”超の手数料）に設定することはできません。値`0`は手数料無料の特別な場合で、`1000000000`と同じです。
トークン発行者は、[AccountSetトランザクション][]を送信することで、発行するトークンすべての`TransferRate`を変更することができます。
アカウントの`TransferRate`は[account_infoメソッド][]で誰でも確認できます。もし`TransferRate`が省略されていれば、手数料は無料です。
{% admonition type="info" name="注記" %}`rippled`v0.80.0で導入され2017-11-14に有効となった[fix1201 Amendment](../networks-and-servers/amendments.md)により、最大送金手数料は実効限度である約329%（32ビット整数の最大サイズに基づく）から100%に引き下げられました。送金手数料の設定が100%（`TransferRate`が`2000000000`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。{% /admonition %}
## クライアントライブラリのサポート
いくつかの[クライアントライブラリ](../../references/client-libraries.md)は`TransferRate`を取得・設定するための便利な関数を持っています。
**JavaScript:** `xrpl.percentToTransferRate()`を使うと、文字列からパーセンテージの送金手数料を対応する`TransferRate`値に変換することができます。
## 関連項目
- **コンセプト:**
- [手数料（曖昧さの回避）](../transactions/fees.md)
- [トランザクションコスト](../transactions/transaction-cost.md)
- [パス](fungible-tokens/paths.md)
- **リファレンス:**
- [account_linesメソッド][]
- [account_infoメソッド][]
- [AccountSetトランザクション][]
- [AccountRootのフラグ](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md#accountrootのフラグ)
{% raw-partial file="/docs/_snippets/common-links.md" /%}