mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 03:35:51 +00:00
[JA] follow #2296
This commit is contained in:
tequ
18
content/@i18n/ja/concepts/payment-types/bouncing-payments.md
Normal file
18
content/@i18n/ja/concepts/payment-types/bouncing-payments.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
html: bouncing-payments.html
|
||||
parent: payment-types.html
|
||||
blurb: 支払いの目的が不明確な場合は、送り主に返却してください。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 不明な入金の返金
|
||||
|
||||
アドレスが不明な支払いを受け取った場合、送金者に返金することが推奨されます。これは、資金を保管するよりも手間がかかりますが、顧客に対する誠意を示すことになります。オペレーターが手動で支払いを返金することもできますし、自動的に返金するシステムを構築することもできます。
|
||||
|
||||
返金の失敗を防ぐための第一の条件は、[入金を適切に監視する](robustly-monitoring-for-payments.html)ことです。顧客から送られてきた金額以上の金額を誤って返金してしまうことは避けなければなりません！(悪意のあるユーザは、[部分支払い](partial-payments.html#partial-payments-exploit)を送信して、脆弱なシステムを利用します。)
|
||||
|
||||
第二に、返金を部分支払い(Partial Payment)として送信することです。第三者はアドレス間のパスのコストを操作することができるので、部分支払いを使えば、XRP Ledger内の取引レートを気にすることなく、支払い金額の全額を手放すことができます。利用規約の一部に、支払い失敗時のポリシーを公表する必要があります。失敗された支払いを、運用中のアドレスまたは待機中のアドレスのいずれかから送信します。
|
||||
|
||||
部分支払いを送信するには、トランザクションの[`tfPartialPayment`フラグ](payment.html#payment-flags)を有効にします。`Amount`フィールドに受け取った金額を設定し、`SendMax`フィールドは省略します。受信した支払いの`SourceTag`値を、返金する支払いの`DestinationTag`値として使用する必要があります。
|
||||
|
||||
2つのシステムで返金が繰り返されるのを防ぐため、送信する返金に新しい送信タグを設定することができます。もしシステムが予期しない支払いを受け取った場合で、その支払いの宛先タグが送信した返金の送信元タグと一致する場合は、その支払いを再び返金させないようにします。
|
||||
@@ -36,7 +36,7 @@ XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。た
|
||||
|
||||
### ユースケース: 支払いの承認
|
||||
|
||||
**課題:** [BSA、KYC、AML、CFT](stablecoin-issuer.html#コンプライアンス指針)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合にはトークンを）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
|
||||
**課題:** [BSA、KYC、AML、CFT](stablecoin-compliance-guidelines.html)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合にはトークンを）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
|
||||
|
||||
**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](accountset.html)することにより、[Deposit Authorization](depositauth.html)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。
|
||||
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
html: robustly-monitoring-for-payments.html
|
||||
parent: payment-types.html
|
||||
blurb: 不正な入金がないかを監視するための推奨事項を説明します。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 入金のモニタリング
|
||||
|
||||
入金チェックを確実に行うために、発行者は以下のことを行う必要があります。
|
||||
|
||||
* 直近に処理したトランザクションとレジャーを記録しておく。そうすれば、一時的に接続ができなくなったとしても、どこまで遡ればいいのか分かります。
|
||||
* 受信したすべての支払いの結果コードを確認する。一部の支払いは、失敗したにもかかわらず、スパム対策料金を請求するためにレジャーに登録されます。結果コード`tesSUCCESS`を持つトランザクションだけが、XRP以外の残高を変更できます。また、検証されたレジャーからのトランザクションのみが確定的なものとなります。
|
||||
* [部分支払い](partial-payments.html)に注意してください。partial paymentフラグを有効にした場合、0以上の金額であれば、少額でも「成功」と判断されることがあります。
|
||||
* トランザクションに[`delivered_amount`フィールド](partial-payments.html#the-delivered_amount-field)があるかどうか確認してください。もし存在すれば、そのフィールドは`Destination`アドレスに実際にどれだけの金額が支払われたかを示しています。
|
||||
* xrpl.jsでは、[`xrpl.getBalanceChanges()`メソッド](https://js.xrpl.org/modules.html#getBalanceChanges)を使って、各アドレスがいくら受け取ったかを見ることができます。場合によっては、これを異なるトラストラインで複数回に分けて表示することも可能です
|
||||
* トランザクションの中には、アドレスの1つへの直接の支払いやアドレスからの支払いでなくても、残高を変更するものがあります。
|
||||
|
||||
顧客の利便性を高めるため、運用アドレスと発行アドレスの両方への支払いを受け付けることをお勧めします。
|
||||
|
||||
追加の防止策として、新しいXRP Ledgerの各レジャーバージョンにおいて、発行アドレスの残高と内部会計システムにおける担保資金を比較することをお勧めします。発行アドレスのマイナス残高は、ネットワーク外のXRP Ledgerに割り当てた資産と一致するはずです。もし両者が一致しないのであれば、その不一致を解決するまでXRP Ledgerへの出入りの支払い処理を中断する必要があります。
|
||||
|
||||
* 残高を確認するには、`gateway_balances`メソッドを使用します。
|
||||
* Transfer Feeが設定されている場合、他のXRP Ledgerアドレスがあなたのトークンを転送するたびに、XRP Ledger内でのあなたの負債はわずかに減少します。
|
||||
|
||||
受信したトランザクションの詳細を確認する方法については、[トランザクションの結果の確認](look-up-transaction-results.html)をご覧ください。
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
html: sending-payments-to-customers.html
|
||||
parent: payment-types.html
|
||||
blurb: Construct payments carefully to thwart malicious actors.
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 顧客への送金
|
||||
|
||||
顧客のためにXRP Ledgerに支払いを送信する自動化システムを構築する際には、支払いが確実に行われるように注意する必要があります。悪意のある行為者は常に、システムを騙して必要以上の金額を支払わせる方法を見つけようとしています。
|
||||
|
||||
一般的に、ステーブルコインを送る場合は[Paymentトランザクション][]を使用します。初めてトークンを発行するのか、ホットウォレットから顧客へ送金するのかによって、細かい点が異なる部分もあります。注意すべき点は以下の通りです。
|
||||
|
||||
- トークンの発行元(`issuer`フィールド)には、必ず発行アドレスを指定してください。そうしないと、他のアドレスが発行した同じ通貨を配信するパスを誤って使用してしまう可能性があります。
|
||||
- XRP Ledgerに支払いを送信する前に、支払いのコストを再確認してください。あなたの運用アドレスから顧客への支払いは、着金金額とあなたが設定した送金手数料よりも高くなるべきではありません。
|
||||
- 発行アドレスから新しいトークンを発行する場合、`SendMax`フィールドを省略する必要があります。そうしないと、悪意のあるユーザは、意図した宛先の`Amount`だけでなく、`SendMax`の全量を発行するように設定を変更することができます。
|
||||
- ホットウォレットからトークンを送信する場合、送金手数料がゼロでない場合は`SendMax`を指定する必要があります。この場合、`SendMax`フィールドに`Amount`フィールドで指定した金額と送金手数料を設定します。(計算の精度がXRP Ledgerと正確に一致しない場合に備えて、少し切り上げるとよいでしょう)。例えば、`Amount`フィールドに99.47USDが指定され、送金手数料が0.25%のトランザクションを送信する場合、`SendMax`フィールドを124.3375、または切り上げる場合は124.34USDに設定すべきです。
|
||||
- `Paths`フィールドを省略します。このフィールドは、発行元から直接送信する場合や、送信するトークンと受信するトークンの通貨コードと発行元が同じである限り、つまり同じステーブルコインである限り、ホットウォレットから設定する必要はありません。`Paths`フィールドは[クロスカレンシー支払い](cross-currency-payments.html)やより長いマルチホップ(rippling)支払いを対象としています。単純に経路探索を行い、トランザクションにパスを設定すると、直接の経路が利用できない場合、支払いは失敗するのではなく、より高価な遠回りのパスを取るかもしれません。悪意のあるユーザはこれを利用して利益を得る可能性があります。
|
||||
- `tecPATH_DRY`の結果コードが表示された場合、通常、必要なトラストラインを顧客がまだ設定していないか、発行者のripplingが正しく設定されていないことを意味します
|
||||
|
||||
XRP Ledger上でステーブルコインやその他のトークンを発行するための詳しいチュートリアルは、[代替可能トークンの発行](issue-a-fungible-token.html)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -8,7 +8,6 @@ labels:
|
||||
- 分散型取引所
|
||||
- AMM
|
||||
---
|
||||
|
||||
# 自動マーケットメーカー
|
||||
_([AMM amendment][] :not_enabled:が必要です。)_
|
||||
|
||||
|
||||
@@ -5,7 +5,13 @@ blurb: トラストラインの特性と根本原理について説明します
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# トラストラインと発行
|
||||
# 代替可能トークン
|
||||
|
||||
非公式な"借用書"から、法定通貨を担保とするステーブルコイン、純粋なデジタルファンジブルトークンやセミファンジブルトークンなど、誰でもXRP Ledger上で代替可能なトークンを発行することができます。
|
||||
|
||||
代替可能トークンは交換可能で、互いに区別がつきません。トークンは交換可能で、同等の価値を持つ他のトークンと置き換えることができます。交換可能なトークンを作成するには、2つのアカウント間で会計関係の一種である「トラストライン」を設定し、それらのアカウント間で支払いを送信します。ほとんどのユースケースでは、最初に設定する必要がある設定もあります。
|
||||
|
||||
## トラストライン
|
||||
|
||||
トラストラインとは、XRP Ledgerにおける[トークン](tokens.html)を保持するための仕組みを指します。トラストラインは、XRP Ledgerのルールである「不要なトークンを他者に保有させることはできない」という原則を強制するものです。この制限は、XRP Ledgerのユースケースである[コミュニティクレジット](tokens.html#コミュニティクレジット)などを実現するために不可欠なものです。
|
||||
|
||||
@@ -19,12 +25,15 @@ labels:
|
||||
|
||||
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
|
||||
|
||||
トラストラインの残高は、それをどちらの側から見るかによって負または正になります。負の残高を持つ側は「発行者」と呼ばれ、トークンの振る舞いに関するいくつかのプロパティを制御できます。トークンを発行者ではない別のアカウントに送ると、そのトークンは発行者や、おそらく同じ通貨コードを使用している他のアカウントを通じて「ripple(波及)」します。これは便利な場合もありますが、予期しない望ましくない動作を引き起こす場合もあります。トラストラインに[No Rippleフラグ](rippling.html)を使用することで、トラストラインが波及しないようにすることができます。
|
||||
|
||||
## 作成
|
||||
|
||||
アカウントはいずれも、ゼロでない上限と独自の設定を持つ[TrustSetトランザクション][]を送信することによって、他のアカウントに対して一方的にトークンを「トラスト」することができます。これによって、残高ゼロのトラストラインが作成され、相手側の設定がデフォルトとして設定されます。
|
||||
|
||||
トラストラインは、[分散型取引所](decentralized-exchange.html)でトークンを購入するときなど、いくつかのトランザクションによって暗黙的に作成されることがあります。この場合、トラストラインはデフォルト設定をそのまま使用します。
|
||||
|
||||
|
||||
## 限度額以上を保有する
|
||||
|
||||
トラストラインの限度額よりも _大きい_ 残高を保有できるケースは次の3つがあります。
|
||||
@@ -33,6 +42,7 @@ labels:
|
||||
2. プラスの残高があるトラストラインの限度額を減らした場合
|
||||
3. [チェックの現金化](checks.html)によって、トークンを限度額以上取得する場合 (_[CheckCashMakesTrustLine amendment][]により追加されました。_)
|
||||
|
||||
|
||||
## トラストラインの設定
|
||||
|
||||
アカウントごとに、共通残高のほかに、トラストラインの設定項目があり、その構成は以下のとおりです。
|
||||
@@ -43,6 +53,7 @@ labels:
|
||||
- **Freeze**: このトラストラインに[個別の凍結](freezes.html#individual-freeze)が適用されているかどうかを示す値(true/false)です。デフォルトは`false です。
|
||||
- **Quality In** および **Quality Out**: この設定により、このトラストライン上の他のアカウントで発行されたトークンを額面より少なく（または多く）評価することができます。たとえば、ステーブルコインの発行者が、オフレッジャーにある同等の資産に対してトークンの引き出しに3%の手数料を課している場合、この設定を使用して、それらのトークンを額面の97%で評価することが可能です。デフォルトは`0`で、額面価格を表しています。
|
||||
|
||||
|
||||
## 準備金と削除
|
||||
|
||||
トラストラインは台帳のスペースを使用するため、[トラストラインはあなたのアカウントが準備金として保持しなければならないXRPを増加させます](reserves.html)。 トラストラインのどちらか、または両方のアカウントにトラストラインの準備金が負担されることがあります。トラストラインの設定がデフォルトでない場合、またはプラス残高を保持している場合、所有者準備金の1つとしてカウントされます。
|
||||
@@ -58,7 +69,7 @@ labels:
|
||||
|
||||
**Authorized** の設定は、一度オンにするとオフにできないため、トラストラインの初期状態にはカウントされません。
|
||||
|
||||
## Free Trust Lines
|
||||
## 無料のトラストライン
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/72377e7bf25c4eaee5174186d2db3c6b4210946f/src/ripple/app/tx/impl/SetTrust.cpp#L148-L168)
|
||||
|
||||
トラストラインはXRP Ledgerの強力な機能であるため、アカウントの最初の2つのトラストラインを「無料」にする特別な機能が用意されています。
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
html: stablecoin-compliance-guidelines.html
|
||||
parent: stablecoins.html
|
||||
blurb: ステーブルコインの発行者は、現地の規制を遵守し、適切な機関に報告する責任があります。
|
||||
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)
|
||||
|
||||
@@ -0,0 +1,101 @@
|
||||
---
|
||||
html: stablecoin-configuration.html
|
||||
parent: stablecoins.html
|
||||
blurb: ステーブルコインの設定を行い、ステーブルコインの機能を詳細に調整します。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# ステーブルコイン発行者の設定
|
||||
|
||||
トークンの発行を始める前に、XRP Ledgerアカウントで設定する必要がある項目がいくつかあります。これらの設定の例については、[代替可能トークンの発行](issue-a-fungible-token.html)をご覧ください。
|
||||
|
||||
設定すべき項目は以下の通りです。
|
||||
|
||||
|
||||
| 設定 | 備考 |
|
||||
|-----------------------|------|
|
||||
| Default Ripple | 発行者は、このフィールドを**必ず**有効にする必要があります。 |
|
||||
| Deposit Authorization | 明示的に承認していないユーザからの入金をすべてブロックします。 |
|
||||
| Require Auth | トークンの保持を、明示的に承認したユーザに限定します。 |
|
||||
| Tick Size | 分散型取引所の取引所為替レートを四捨五入して、より迅速な価格決定を可能にします。 |
|
||||
| Transfer Fee | ユーザ同士がトークンを送信する際に、一定割合の手数料を徴収します。 |
|
||||
|
||||
|
||||
## Default Ripple
|
||||
|
||||
Default Rippleフラグは、トラストラインの残高をデフォルトで[Ripplingを許可](rippling.html)するかどうかを制御します。Ripplingは顧客同士のトークンの送信や取引を可能にするものなので、発行者はその発行アドレスへのすべてのトラストラインでのRipplingを許可しなければなりません(MUST)。
|
||||
|
||||
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行者はそのアドレスのDefault Rippleフラグを有効にする必要があります。そうでない場合、発行者は、他のアドレスが作成した各トラストラインのNo Rippleフラグを個別に無効化する必要があります。
|
||||
|
||||
運用ウォレットやスタンバイウォレットなど、他のアドレスではDefault Rippleフラグを有効にすべきではありません。
|
||||
|
||||
|
||||
## Deposit Authorization
|
||||
|
||||
Deposit Authorizationの設定は、以下のいずれかを行わない限り、アカウントへのすべての入金をブロックします。
|
||||
|
||||
- 事前に送信者を認可している。
|
||||
- 資金を受け取るためにトランザクションを送信します。例えば、他人が作成したエスクローを終了させるなど。
|
||||
|
||||
Deposit Authorizationは、不要なXRPの支払いをブロックするのに最も有効です。なぜなら、発行元へのトラストラインを作成しない限り、既にトークンを受け取ることはできないからです。しかし、ステーブルコインの発行者としては、ステーブルコインをレジャー外の価値と交換するために、ユーザからの支払いを受け取ることができる必要があります。顧客を事前認可することはできますが、そうすると、顧客それぞれのアドレスについてレジャーにオブジェクトを格納する必要があり、準備金が大幅に増加します。
|
||||
|
||||
したがって、未知または制裁を受けたエンティティからお金を受け取ることに関する規制要件を満たすために必要でない限り、Deposit Authorizationはステーブルコインの発行者に推奨されません。
|
||||
|
||||
より詳細な情報は[Deposit Authorization](depositauth.html)をご覧ください。
|
||||
|
||||
|
||||
## Disallow Incoming Trust Line
|
||||
|
||||
Disallow Incoming Trust Lineの設定は、他のユーザがアドレスにトラストラインを開くことを防ぎます。予防措置として、運用アドレスと待機アドレスでこの設定を有効にすることで、誤ってこれらのアカウントからトークンを発行できないようにします。発行アドレスではこの設定を有効にしないでください。
|
||||
|
||||
この設定を有効にするには、[AccountSetトランザクション](accountset.html)で`"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.html)をご覧ください。
|
||||
|
||||
|
||||
## Tick Size
|
||||
|
||||
Tick Sizeは、[分散型取引所](decentralized-exchange.html)で為替レートを計算する際に使用する小数点以下の桁数を制御する設定です。Tick Sizeを大きくすると、より精度が高くなり、さまざまな取引の金額で丸め込みが少なくなります。取引は主に取引レートに基づいてランク付けされるため、トレーダーがリストの上位にわずかな金額を提供することができるため、精度が高すぎると不都合になることがあります。Tick Sizeを小さくすると、オークションの最低入札額と同じような効果があり、無関係な小額を徐々に入札する時間と労力が省けます。しかし、Tick Sizeを小さくすると四捨五入が多くなり、取引コストが高くなります。また、四捨五入前は完全に一致するように見えた2つのオファーが、四捨五入後は一致しなくなるという意外な結果になることもあります。
|
||||
|
||||
Tick Sizeはアカウントレベルの設定であり、同じアドレスで発行されたすべてのトークンに適用されます。
|
||||
|
||||
Tick Sizeは取引レートの精度を制御するだけで、トークン自体の精度を制御するものではありません。ユーザは、トークンの発行者が設定したTick Sizeに関係なく、非常に大きな金額や非常に小さな金額を送ったり保有したりすることができます。
|
||||
|
||||
詳しくは[Tick Size](ticksize.html)をご覧ください。
|
||||
|
||||
|
||||
## Transfer Fees
|
||||
|
||||
Transfer Feesは、ユーザ同士がトークンを送金する際に、一定割合の手数料を請求するものです。送金手数料は、トークンを発行したり、発行アドレスで直接トークンを交換したりする場合には適用されません。(ユーザが発行アドレスに送金するときには適用されません。)同じアドレスから複数のトークンを発行する場合、すべてのトークンに対して同じ送金手数料が適用されます。
|
||||
|
||||
ユーザが送金手数料が設定されたトークンを送信すると、送信側から送金先金額に加えて送金手数料の金額が引き落とされますが、受信側には送金先金額のみが入金されます。手数料の金額はXRP Ledgerから「消える」のです。ステーブルコインの発行者としては、XRP Ledgerの外にある準備金にそれだけ自己資本が増える、言い換えれば、ユーザが送金手数料を支払うたびに担保として持っておく必要がある金額が減少することを意味します。
|
||||
|
||||
プロトコルレベルでは、送金手数料はアカウント設定の`TransferRate`で定義され、これは10億から20億までの整数で指定されます。
|
||||
|
||||
詳しくは[送金手数料](transfer-fees.html)をご覧ください。
|
||||
|
||||
|
||||
### 運用アドレスと待機アドレスによる送金手数料
|
||||
|
||||
運用アドレスや待機アドレスを含むすべてのXRP Ledgerアドレスは、トークンを送信する際に発行者の送金手数料がかかります。送金手数料をゼロ以外に設定した場合、運用アドレスや待機アドレスから支払いを行う際に、(送金手数料を支払うために)余分に送金しなければなりません。つまり、これらのアドレスは、支払いを行うたびに、あなたの発行アドレスが作った残高を少し返金する必要があります。
|
||||
|
||||
トランザクションパラメータ`SendMax`を送信先の`Amount`パラメータよりも`TransferRate`設定に基づく割合で高く設定します。
|
||||
|
||||
**注記:** 発行アドレスから、または発行アドレスへ直接トークンを送信する場合、送金手数料は適用されません。発行アドレスは、常にそのトークンをXRP Ledgerの額面価格で受け入れなければなりません。つまり、顧客が発行アドレスに直接支払いを送る場合は送金手数料を支払う必要はありませんが、運用アドレスに送る場合は支払う必要があります。両方のアドレスで支払いを受け付ける場合、顧客が運用アドレスに支払いを送る際に、顧客が支払う送金手数料を補うために、記録システムで顧客に入金する金額を調整する必要がある場合があります。
|
||||
|
||||
例えば、次のようなものです。ACMEが送金手数料を1％に設定した場合、顧客のアドレスからACMEの発行アドレスに5 EUR.ACMEを届けるためのXRP Ledger支払いは、ちょうど5 EUR.ACMEの費用がかかります。しかし、顧客は5 EUR.ACMEをACMEの運用アドレスに届けるために、5.05 EUR.ACMEを送る必要があります。ACMEの運用アドレスへの支払いを顧客に入金する際、ACMEは運用アドレスに届けられた金額と送金手数料を顧客に入金し、顧客はACMEのシステムで5.05ユーロを受け取ることができます。
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
html: stablecoins.html
|
||||
parent: trust-lines-and-issuing.html
|
||||
blurb: XRP Ledger上で取引される一般的なステーブルコインには5種類あります。
|
||||
labels:
|
||||
- XRP
|
||||
- ステーブルコイン
|
||||
---
|
||||
# ステーブルコイン
|
||||
|
||||
ステーブルコインは、XRP Ledgerの外の資産の価値を保持し、レジャー上の同等の価値を表すトークンを発行します。この種類の発行者は、そのサービスを通じてXRP Ledgerの内外に通貨を移動させることができるため、 _ゲートウェイ_ と呼ばれることがあります。もしトークンの裏付けとなる資産が、レジャー上のトークンと同じ金額と額面であれば、そのトークンは"ステーブルコイン"とみなすことができます。
|
||||
|
||||
ステーブルコインの発行者は、トークンをXRP Ledgerの外の世界の実際の通貨や資産と交換するために、_入金_ と _出金_ の機能を提供する必要があります。
|
||||
|
||||
実際には、XRP Ledgerはコンピュータシステムであり、それ自身の外部にルールを強制することはできないため、XRP Ledger上のステーブルコインはその発行者に依存しています。もしあなたが、そのステーブルコインの発行者があなたのトークンを要求に応じて本物と交換してくれることを期待できないのであれば、そのステーブルコインがその価値を維持することを期待すべきではありません。ユーザとしては、トークンを発行しているのが誰なのか、信頼性があり、合法的で、支払能力があるのか、に気を配る必要があります。そうでない場合は、そのトークンを保有しない方がよいでしょう。
|
||||
|
||||
XRP Ledgerで取引される通貨トークンには、一般的に5つの種類があります。
|
||||
|
||||
## 法定通貨による担保
|
||||
|
||||
法定通貨を担保とするステーブルコインは、EUR、USD、YENなどの既存の通貨に基づいています。取引レートは1:1です。これはシンプルで安定したオプションですが、中央集権的でハッキングの影響を受けやすいという欠点があります。最も厳密な「ステーブルコイン」の定義では、100%法定通貨で担保されたトークンのみが対象となります。
|
||||
|
||||
## 暗号資産による担保
|
||||
|
||||
暗号通貨を担保とするステーブルコインは、フィアット担保のステーブルコインと似ていますが、一定額の暗号通貨を担保として準備します。非中央集権的で、カストディアンや監査、規制を必要としません。また、ボラティリティが高く、基礎となる暗号通貨の安定性に依存します。
|
||||
|
||||
## コモディティによる担保
|
||||
|
||||
コモディティを担保とするステーブルコインは、金、不動産、石油、電力などの交換可能な資産に基づいています。コモディティは比較的安定していて流動性がありますが、中央集権的で、その価値を確認するために定期的な監査が必要です。
|
||||
|
||||
## 金融商品による担保
|
||||
|
||||
ステーブルコインは、債券や株式などの金融商品で裏付けすることができます。
|
||||
|
||||
## 担保なし
|
||||
|
||||
非担保トークンは、トークンの供給や売却をアルゴリズム生成スマートコントラクトに依存し、中央銀行が通貨を印刷・破棄するアプローチに似ています。トークンの発行に担保は必要ありません。価値は、価格を安定させるアルゴリズムを通じて需要と供給によって制御されます。非担保トークンはボラティリティが高いため、一般的にステーブルコインとはみなされません。
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
html: stablecoin-precautions.html
|
||||
parent: stablecoins.html
|
||||
blurb: XRPLでステーブルコイン資金の入出金時の注意点を説明します。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# ステーブルコインに関する注意事項
|
||||
|
||||
XRP Ledgerとの間の決済処理には当然リスクが伴いますので、発行者はこれらの処理を実施する際に十分な注意を払う必要があります。ステーブルコインの発行者としては、以下の注意点を考慮する必要があります。
|
||||
|
||||
|
||||
## インフラストラクチャ
|
||||
|
||||
あなた自身のセキュリティとネットワークの安定性のために、XRP Ledgerを利用する事業者は、1つの[バリデータ](rippled-server-modes.html#validators)を含む[独自のXRP Ledgerサーバ](install-rippled.html)を実行すべきです。
|
||||
|
||||
|
||||
## ツールのセキュリティ
|
||||
|
||||
XRP Ledgerのトランザクションを送信する際には、秘密鍵を使って署名する必要があります。秘密鍵は、あなたのXRP Ledgerアドレスを完全にコントロールします。秘密鍵を他人が運営するサーバに決して送らないでください。自身のサーバを使うか、クライアントライブラリを使ってローカルでトランザクションに署名してください。安全な設定の手順と例については、[安全な署名の設定](secure-signing.html)をご覧ください。
|
||||
|
||||
XRP Ledgerへの接続方法は、ニーズや既存のソフトウェアに応じて、いくつかのインターフェイスを使用することができます。
|
||||
|
||||
- [HTTP / WebSocket API](http-websocket-apis.html)は、XRP Ledgerのすべてのコア機能への低レベルのインターフェースとして使用することができます。
|
||||
- [クライアントライブラリ](client-libraries.html)は、いくつかのプログラミング言語で利用でき、XRP Ledgerにアクセスするための便利なユーティリティを提供します。
|
||||
- その他、[xApps](https://xumm.readme.io/docs/xapps)などのツールも利用可能です。
|
||||
- サードパーティのウォレットアプリケーションも、特に待機アドレスの担当者には便利かもしれません。
|
||||
|
||||
ただし、公式な配布チャネルから信頼できるツールだけを使用するように注意してください。悪意のあるサーバ、ライブラリ、アプリは、攻撃者に秘密鍵を漏らすように設定されている可能性があります。
|
||||
|
||||
|
||||
## XRP Ledgerからの送金
|
||||
|
||||
XRP Ledgerから送金を受ける際、プロセスや統合ソフトウェアが悪用されることのないよう、いつ送金が確定したかを把握し、正しい金額を顧客にクレジットすることが重要です。詳細とよくある落とし穴については、[入金のモニタリング](robustly-monitoring-for-payments.html)をご覧ください。
|
||||
|
||||
予期しない、または不要な支払いを受け取った場合の標準的な対応は、送信者にそれを返却することです。追加費用を発生させずにこれを行う方法の詳細については、[不明な入金の返金](bouncing-payments.html)をご覧ください。
|
||||
|
||||
XRP Ledgerからの支払いを処理する前に、顧客の身元を確認してください。そうすることで、匿名の攻撃者による詐欺が難しくなります。ほとんどのマネーロンダリング対策規制は、いずれにせよこの確認を要求しています。XRP Ledgerから送金するユーザは、XRP Ledgerで最初にお金を受け取ったユーザとは異なる可能性があるため、これは特に重要です。詳しくは、[ステーブルコインのコンプライアンス指針](stablecoin-compliance-guidelines.html)をご覧ください。
|
||||
|
||||
|
||||
## XRP Ledgerへの送金
|
||||
|
||||
XRP Ledgerに送金を行う際には、手数料の過払いや迂回経路を避けるため、ベストプラクティスに従ってください。詳しくは[顧客への送金](sending-payments-to-customers.html)をご覧ください。
|
||||
|
||||
銀行預金やクレジット/デビット決済など、外部システムからの支払いを受け入れる場合は、可逆的な入金に注意してください。XRP Ledgerの支払いは不可逆ですが、他の多くのデジタル支払いはそうではありません。詐欺師はこれを悪用し、あなたがすでにXRP Ledgerの支払いを送った後に、XRPL以外の取引をキャンセルすることで、元金を取り戻すことができます。
|
||||
|
||||
さらに、停電やネットワーク停止のようなまれな状況でも、XRP Ledgerのトランザクションの最終結果を確実に知ることができるように、[信頼できるトランザクションの送信](reliable-transaction-submission.html)に従ってください。
|
||||
|
||||
|
||||
## その他の注意事項
|
||||
|
||||
- XRP Ledger内の債務と残高を追跡し、担保口座の資産と比較してください。両者が一致しない場合は、不一致を解決するまで引き出しと入金の処理を停止してください。
|
||||
- 曖昧な状況を避けてください。すべてのアドレスで適切な設定を行うことで、誤って間違ったアドレスからトークンを発行したり、ユーザーが間違った場所に送金したりするようなケースを避けることができます。推奨事項については、[ステーブルコインの設定](stablecoin-configuration.html)をご覧ください。
|
||||
- 疑わしい行動や不正な行動を監視します。例えば、ユーザーがXRP Ledgerに繰り返し資金を出し入れすることで、実質的に運用アドレスの残高を空にするサービス拒否攻撃が可能です。XRP Ledgerの支払いを処理しないことで、そのアドレスが疑わしい行動に関与している顧客を一時停止します。
|
||||
@@ -0,0 +1,100 @@
|
||||
---
|
||||
html: stablecoin-settings.html
|
||||
parent: stablecoins.html
|
||||
blurb: 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.html)をご覧ください。
|
||||
|
||||
|
||||
## ティックサイズの設定
|
||||
|
||||
ティックサイズは、[分散型取引所](decentralized-exchange.html)で取引レートを計算する際に使用される小数点以下の桁数を制御します。ティックサイズが大きいほど(小数点以下の桁数が多いほど)精度が高くなり、さまざまな取引金額の四捨五入が少なくなります。ティックサイズが小さいほど、オークションにおける最低入札額と同じように機能し、無駄に小さい金額で徐々に価格を競り上げる時間と労力を節約できます。
|
||||
|
||||
ティックサイズはアカウントレベルの設定で、同じアドレスで発行されたすべてのトークンに適用されます。
|
||||
|
||||
[ティックサイズ](ticksize.html)をご覧ください。
|
||||
|
||||
|
||||
## Default Rippleフラグの設定
|
||||
|
||||
Default Rippleフラグはトラストラインの残高をデフォルトでRipple(波及)させるかどうかを制御します。Ripplingは顧客間でトークンを送ったり取引したりすることを可能にするものです。発行者はその発行アドレスへの全てのトラストラインでRipplingを許可しなければなりません(MUST)。
|
||||
|
||||
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行アドレスのDefault Rippleフラグを有効にしてください。そうでない場合は、他のアドレスが作成したトラストラインごとに、個別にNo Rippleフラグを無効にする必要があります。
|
||||
|
||||
[Rippling](rippling.html)をご覧ください。
|
||||
|
||||
|
||||
## 宛先タグの有効化
|
||||
|
||||
ステーブルコインのアプリケーションが複数の顧客の代わりにトランザクションを処理する場合、どのアカウントに入金すべきかがわからないことがあります。宛先タグは、送金者に受取人や送金先を指定させることで、このような状況を回避するのに役立ちます。RequireDestフラグを有効にするには、`AccountSet`トランザクションの`SetFlag`フィールドに`asfRequireDest`値(1)を設定してください。
|
||||
|
||||
[送信元と送信先のタグ](source-and-destination-tags.html)をご覧ください。
|
||||
|
||||
## 資産の管理機能
|
||||
|
||||
ステーブルコインの作成と配布をコントロールするには、いくつかのオプションがあります。
|
||||
|
||||
|
||||
### 認可トラストライン
|
||||
|
||||
KYC(Know Your Customer)やAML(Anti-Money Laundering)などのコンプライアンスルールに従う必要がある場合、トラストラインを使用して、ステーブルコインの配布を許可されたプールを作成することができます。これにより、資金が誰に送金されるかを確認することができます。
|
||||
|
||||
[認可トラストライン](authorized-trust-lines.html)をご覧ください。
|
||||
|
||||
|
||||
### Freezeフラグ
|
||||
|
||||
保有者アカウント内のステーブルコインを凍結することができます。これは、詐欺行為が疑われる場合、または保有を強制する場合に行うことができます。個々のトラストラインを凍結することも、グローバルに凍結することもできます。
|
||||
|
||||
逆に、トークンを凍結する能力を永久に放棄する「No Freeze」を設定することもできます。これにより、発行者がトークン同士の取引を妨害でき無くなるという意味で、そのステーブルコインはより現実の通貨に近くなります。
|
||||
|
||||
[トークンの凍結](freezes.html)をご覧ください。
|
||||
|
||||
|
||||
### Clawbackフラグ
|
||||
|
||||
_([Clawback amendment](known-amendments.html#clawback) :not_enabled: が必要です。)_
|
||||
|
||||
Clawbackにより、特定の状況下でトラストラインからステーブルコインを回収(クローバック)することができます。これにより、アカウントへのアクセス不能や悪意のある活動などの課題に対応する能力が追加されます。
|
||||
|
||||
[Clawback](clawback.html)をご覧ください。
|
||||
|
||||
|
||||
### 固定供給量
|
||||
|
||||
ステーブルコインを固定枚数に制限することで、将来さらにトークンを発行することになっても、ステーブルコインの価値が希釈されないことが保証されます。
|
||||
|
||||
固定供給とするためには、
|
||||
|
||||
1. 発行するウォレットと同様の設定で配布ウォレットを作成します。
|
||||
2. 発行ウォレットと配布ウォレットの間にトラストラインを設定します。
|
||||
3. 発行ウォレットから配布ウォレットにすべてのトークンを送信します。
|
||||
4. 発行アカウントをブラックホール化します。
|
||||
@@ -1,12 +1,11 @@
|
||||
---
|
||||
name: 代理Mint
|
||||
html: nftoken-authorized-minting.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTのMintを他のアカウントに代行してもらうことができます。
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# 他のアカウントでNFTを処理することを許可する
|
||||
# NFT処理を他のアカウントに委任
|
||||
|
||||
各アカウントは、自分に代わってNFTをMintすることができる認可されたMinterを最大一人設定することができまます。認可Minter機能を利用することで、クリエイターは別のアカウントにNFTをMintさせることができ、より多くのNFTを作ることに集中することができます。
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
|
||||
# バッチMint
|
||||
# NFTのバッチMint
|
||||
|
||||
NFTokenオブジェクトを一括でMintする方法には、一般的に、オンデマンドでMintする方法とスクリプトでMintする方法の2つがあります。
|
||||
|
||||
@@ -27,7 +27,7 @@ NFTokenオブジェクトの初回販売以前の市場活動は、XRP Ledgerに
|
||||
|
||||
プログラムまたはスクリプトを使用して、一度に多数のトークンをMintします。[チケット](tickets.html)を使えば、1度に200件までのトランザクションを並行して処理することができます。
|
||||
|
||||
実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](batch-mint-nfts-using-javascript.html)を参照してください。
|
||||
実用例としては、チュートリアルの[JavaScriptでNFTをバッチMint](batch-mint-nfts-using-javascript.html)をご覧ください
|
||||
|
||||
### メリット
|
||||
|
||||
|
||||
@@ -5,7 +5,7 @@ blurb: 新しいアカウントを使って一定数のNFTをミントし、そ
|
||||
labels:
|
||||
- 非代替性トークン, NFT
|
||||
---
|
||||
# NFTの一定の供給量を保証する
|
||||
# NFTの固定供給
|
||||
|
||||
プロジェクトによっては、発行アカウントから一定数以上のNFTがミントされないことを保証したい場合があります。
|
||||
|
||||
@@ -13,9 +13,9 @@ labels:
|
||||
|
||||
1. 新しいアカウント、_発行者_ を作成し、資金を提供します。このアカウントは、コレクション内のトークンの発行者となります。[アカウントの作成](accounts.html#アカウントの作成)を参照してください。
|
||||
1. `AccountSet`を使用して、自分の運用するウォレットを発行者の認可Minterとして割り当てます。[代理Mint](nftoken-authorized-minting.html)を参照してください。
|
||||
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[バッチMint](nftoken-batch-minting.html)を参照してください。
|
||||
1. 運用アカウントで`NFTokenMint`を使ってトークンをミントします。運用中のウォレットには、発行者のためにMintされたすべてのトークンが保管されます。[Mintのバッチ処理](nftoken-batch-minting.html)をご覧ください
|
||||
1. 発行者の認可Minterである自分の運用するウォレットを削除するために、`AccountSet`を使用します。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](disable-master-key-pair.html)を参照してください。
|
||||
1. 発行者アカウントを"ブラックホール化"する。[マスターキーペアの無効化](disable-master-key-pair.html)をご覧ください。
|
||||
|
||||
この時点で、発行者のアドレスを発行アカウントとする新たなトークンのミントは不可能となります。
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ labels:
|
||||
2. 落札額の一部を手数料として徴収します。
|
||||
3. 買い手/売り手へXRPLトランザクションを送信し、取引を完了させます。
|
||||
|
||||
## 最低落札価格ありのオークションを実施する
|
||||
## 最低落札価格ありのオークション
|
||||
|
||||
最低落札価格ありのオークションとして、ブローカー方式で運営する。
|
||||
|
||||
@@ -39,7 +39,7 @@ labels:
|
||||
|
||||
このデメリットの大きな軽減要素は、もしこのような行動が起これば、ブローカーは市場シェアをすべて失うことになるため、売り手はこの点を理解すべきです。
|
||||
|
||||
## 最低落札価格なしのオークションを実施する
|
||||
## 最低落札価格なしのオークション
|
||||
|
||||
この3つのうち、最も複雑なワークフローとなります。
|
||||
|
||||
|
||||
@@ -33,6 +33,8 @@ Paymentは、[アカウントを作成](#アカウントの作成)する唯一
|
||||
}
|
||||
```
|
||||
|
||||
[Query example transaction. >](websocket-api-tool.html?server=wss%3A%2F%2Fxrplcluster.com%2F&req=%7B%22id%22%3A%22example_Payment%22%2C%22command%22%3A%22tx%22%2C%22transaction%22%3A%227BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E%22%2C%22binary%22%3Afalse%7D)
|
||||
|
||||
{% include '_snippets/tx-fields-intro.ja.md' %}
|
||||
<!--{# fix md highlighting_ #}-->
|
||||
|
||||
@@ -64,8 +66,11 @@ Paymentトランザクションタイプは、いくつかの異なるタイプ
|
||||
[クロスカレンシー（通貨間）決済]: cross-currency-payments.html
|
||||
[Partial payment]: partial-payments.html
|
||||
|
||||
|
||||
## SendMaxおよびAmountで使用する特殊なissuerの値
|
||||
|
||||
|
||||
|
||||
ほとんどの場合、XRP以外の[通貨額][]の`issuer`フィールドは、金融機関の[発行アドレス](account-types.html)を示しています。ただし、支払いを記述するにあたって、支払いの`Amount`フィールドと`SendMax`フィールドにある`issuer`フィールドについては、特殊なルールが存在します。
|
||||
|
||||
* 2つのアドレス間で、同一の通貨に関して存在する残高は常に1つです。つまり、金額の`issuer`フィールドが実際に表しているのは、イシュアンスを作成したアドレスではなく、イシュアンスを換金する相手方であることがあります。
|
||||
@@ -97,15 +102,15 @@ Payment型のトランザクションでは、資金供給のないアドレス
|
||||
|
||||
Payment型のトランザクションについては、[`Flags`フィールド](transaction-common-fields.html#flagsフィールド)で以下の値が追加でサポートされます。
|
||||
|
||||
| フラグの名前 | 16進値 | 10進値 | 説明 |
|
||||
|:-----------------|:-----------|:--------------|:-----------------------------|
|
||||
| tfNoDirectRipple | 0x00010000 | 65536 | デフォルトパスを使用せず、`Paths`フィールドに含まれているパスのみ使用します。これによりトランザクションは強制的に裁定機会を活用することになります。ほとんどのクライアントでは、これは必要ありません。 |
|
||||
| tfPartialPayment | 0x00020000 | 131072 | `SendMax`を超えていないのに指定された`Amount`を送金できない場合、即座に失敗とするのではなく、受取られる額を減額します。詳細は、[Partial Payments](partial-payments.html)を参照してください。 |
|
||||
| tfLimitQuality | 0x00040000 | 262144 | すべての変換で、入力と出力との比率が`Amount`と`SendMax`との比率と同一であるか、さらに有利となるパスのみを採用します。詳細は、[クオリティの制限](#クオリティの制限)を参照してください。 |
|
||||
| フラグの名前 | 16進値 | 10進値 | 説明 |
|
||||
|:-------------------|:-------------|:--------------|:-----------------------------|
|
||||
| `tfNoDirectRipple` | `0x00010000` | 65536 | デフォルトパスを使用せず、`Paths`フィールドに含まれているパスのみ使用します。これによりトランザクションは強制的に裁定機会を活用することになります。ほとんどのクライアントでは、これは必要ありません。 |
|
||||
| `tfPartialPayment` | `0x00020000` | 131072 | `SendMax`を超えていないのに指定された`Amount`を送金できない場合、即座に失敗とするのではなく、受取られる額を減額します。詳細は、[Partial Payments](partial-payments.html)を参照してください。 |
|
||||
| `tfLimitQuality` | `0x00040000` | 262144 | すべての変換で、入力と出力との比率が`Amount`と`SendMax`との比率と同一であるか、さらに有利となるパスのみを採用します。詳細は、[クオリティの制限](#クオリティの制限)を参照してください。 |
|
||||
|
||||
## Partial Payments
|
||||
|
||||
Partial Paymentsを利用すると、受取られる金額を減額することによって、支払いを成功させることができます。Partial Paymentsが有用なのは、追加的なコストを発生させずに[支払いを返金](stablecoin-issuer.html#不明な入金の返金)する場合です。その一方で、成功したトランザクションの`Amount`フィールドに、送金された金額が常に正しく記述されていることを前提としている環境において、悪用されるおそれもあります。
|
||||
Partial Paymentsを利用すると、受取られる金額を減額することによって、支払いを成功させることができます。Partial Paymentsが有用なのは、追加的なコストを発生させずに[支払いを返金](bouncing-payments.html)する場合です。その一方で、成功したトランザクションの`Amount`フィールドに、送金された金額が常に正しく記述されていることを前提としている環境において、悪用されるおそれもあります。
|
||||
|
||||
Partial Paymentsとは、**tfPartialPayment**フラグが有効になっている[Paymentトランザクション][]です。Partial Paymentsは、`SendMax`値を超える金額を送金することなく、`DeliverMin`フィールド以上の正の金額（`DeliverMin`が指定されていない場合、任意の正の金額）を送金する場合に成功します。
|
||||
|
||||
|
||||
@@ -146,9 +146,9 @@ Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
- アカウントセキュリティを強化するために、[マルチシグを設定する](set-up-multi-signing.html)。
|
||||
- 明示的に承認した送金、または事前に承認した相手からの送金のみを受け取れるようにするために、[DepositAuthを有効にする](depositauth.html)。
|
||||
- ユーザーがあなたの許可なくあなたへの[トラストライン](trust-lines-and-issuing.html)を開けないようにするために、[RequireAuthを有効にする](authorized-trust-lines.html#requireauthの有効化)。XRP Ledgerの分散型取引所やトークン機能を使用する予定がない場合は、これを対策として行うことをお勧めします。
|
||||
- トークン[ゲートウェイ](stablecoin-issuer.html)には次のような追加の設定がある場合があります。
|
||||
- トークンを送金するユーザーに対して[TransferRateを設定する](stablecoin-issuer.html#transfer-fees)。
|
||||
- このアドレスをトークンのみに使用する予定の場合は、[XRPペイメントを禁止する](stablecoin-issuer.html#disallow-xrp)。
|
||||
- [トークン発行者](stablecoin-issuer.html)には次のような追加の設定がある場合があります。
|
||||
- トークンを送金するユーザーに対してTransferRateを設定する。
|
||||
- このアドレスをトークンのみに使用する予定の場合は、XRPペイメントを禁止する。
|
||||
|
||||
この段階では、トランザクションに署名をするだけで、まだ送信しません。各トランザクションに対して、`Fee`（[トランザクションコスト](transaction-cost.html)）や`Sequence`（[シーケンス番号][]）など、通常は自動入力可能なフィールドを含めて、すべてのフィールドに入力する必要があります。一度に複数のトランザクションを準備する場合は、トランザクションの実行順にシーケンシャルに増やした`Sequence`番号を使用する必要があります。
|
||||
|
||||
|
||||
@@ -41,17 +41,17 @@ XRPをサポートするために、Alpha Exchangeでは以下を行う必要が
|
||||
|
||||
関連項目:
|
||||
|
||||
* [コンプライアンス指針](stablecoin-issuer.html#コンプライアンス指針) — ゲートウェイと取引所は異なりますが、取引所は地域の規制に準拠し、適切な当局の監督下になければなりません。
|
||||
* [コンプライアンス指針](stablecoin-compliance-guidelines.html) — ゲートウェイと取引所は異なりますが、取引所は地域の規制に準拠し、適切な当局の監督下になければなりません。
|
||||
|
||||
* [XRP Ledgerへ送金するための要件](stablecoin-issuer.html#xrp-ledgerへ送金するための要件)
|
||||
<!-- * [XRP Ledgerへ送金するための要件](stablecoin-issuer.html#xrp-ledgerへ送金するための要件)
|
||||
|
||||
* [XRP Ledgerへの入金の要件](stablecoin-issuer.html#xrp-ledgerへの入金の要件)
|
||||
* [XRP Ledgerへの入金の要件](stablecoin-issuer.html#xrp-ledgerへの入金の要件) -->
|
||||
|
||||
* [注意事項](stablecoin-issuer.html#注意事項)
|
||||
* [注意事項](stablecoin-precautions.html)
|
||||
|
||||
### Partial Payments
|
||||
|
||||
追加の前に、取引所は[Partial Payments](partial-payments.html)機能について知っておく必要があります。この機能を使用すると、XRP Ledgerのユーザーは、`SendMax`を増やさずに、受取金額を減額して、支払いを正常に送信できます。この機能は、送信者側に追加費用が発生せず、[支払いの返金](stablecoin-issuer.html#不明な入金の返金)に便利です。
|
||||
追加の前に、取引所は[Partial Payments](partial-payments.html)機能について知っておく必要があります。この機能を使用すると、XRP Ledgerのユーザーは、`SendMax`を増やさずに、受取金額を減額して、支払いを正常に送信できます。この機能は、送信者側に追加費用が発生せず、[支払いの返金](bouncing-payments.html)に便利です。
|
||||
|
||||
#### Partial Paymentsに関する警告
|
||||
|
||||
|
||||
@@ -37,8 +37,8 @@ NFTokenのURLは、NFTのコンテンツが保存されている場所へのリ
|
||||
|
||||
* [コレクションとしてNFTをミントする](nft-collections.html)
|
||||
TokenTaxonフィールドを使用して、特定のテーマや目的をもったNFTのセットを作成します。
|
||||
* [NFTの一定の供給量を保証する](nft-fixed-supply.html)
|
||||
また、「使い捨て」アカウントでNFTを作成し、別のアカウントで一定数のNFTを取得した後、ミントに使用した「使い捨て」アカウントを削除することで、作成したNFTの希少性を確保することができます。[NFTの一定の供給量を保証する](nft-fixed-supply.html)をご覧ください。
|
||||
* [NFTの固定供給](nft-fixed-supply.html)
|
||||
また、「使い捨て」アカウントでNFTを作成し、別のアカウントで一定数のNFTを取得した後、ミントに使用した「使い捨て」アカウントを削除することで、作成したNFTの希少性を確保することができます。[NFTの固定供給](nft-fixed-supply.html)をご覧ください。
|
||||
|
||||
## NFTの取引
|
||||
|
||||
|
||||
@@ -1,542 +1,217 @@
|
||||
---
|
||||
html: stablecoin-issuer.html
|
||||
parent: tokenization.html
|
||||
blurb: XRP Ledgerの外部の同価値の資産に基づき、独自のステーブルコインを発行する。
|
||||
blurb: XRP Ledgerの外にある同価値の資産に基づいて、ステーブルコインを発行することができます。
|
||||
labels:
|
||||
- トークン
|
||||
- ステーブルコイン
|
||||
---
|
||||
# ステーブルコインの発行者
|
||||
|
||||
**ステーブルコイン**は、外部世界の資産に裏付けられた[トークン](tokens.html)です。ステーブルコインにより、ユーザは身近な通貨で取引を行うことができ、ブロックチェーンへの資金の出し入れを便利にすることができます。ステーブルコインの発行者は、これらのサービスを提供する代わりに、ステーブルコインの出金や送金にかかる手数料など、さまざまな方法で収益を得ることができます。
|
||||
_金融の専門家として、私はステーブルコインを発行し、ステーブルコインの引き出しや送金に手数料を課すことで収入を得たいと考えています。_
|
||||
|
||||
XRP Ledgerでは、誰でも任意の通貨コードを持つトークンを発行することができますが、ステーブルコインの価値は、対応する資産と交換できるという保証に基づきます。また、ステーブルコインの発行には、管轄区域によって異なる規制上の制約がある場合があります。これらの理由から、一般的に、ステーブルコインの発行には、信頼できる事業者が必要です。
|
||||
ステーブルコインは、XRPL外の資産によって裏付けられたトークンです。ステーブルコインにより、ユーザは使い慣れた通貨で取引を行うことができ、資金をXRPLブロックチェーンに出し入れする便利な方法を提供します。
|
||||
|
||||
**注記:** XRP Ledger上のステーブルコイン発行者は、以前は「ゲートウェイ」と呼ばれていました。
|
||||
ステーブルコイン発行の仕組みは複雑ではありません。
|
||||
|
||||
この記事では、ステーブルコインを発行する前に知っておくべき情報、ステーブルコイン発行者の設定に関わる選択肢のまとめ、XRP Ledgerとの技術統合を実装するためのリソースを提供します。
|
||||
1. ステーブルコインの名前を決めます(3文字のISO標準に従うか、160ビットの16進文字列を使用します。[通貨コード](currency-formats.html#通貨コード)をご覧ください)。
|
||||
2. 発行アカウントと消費者のアカウントの間にトラストラインを作成し、送金するステーブルコインの最大数を設定します。
|
||||
3. トラストラインの最大金額までのステーブルコインの支払いを消費者に送信します。
|
||||
|
||||
誰でもXRP Ledgerの任意の通貨コードでトークンを発行することができますが、ステーブルコインの価値は、対応する資産と交換できるという保証から生まれます。ステーブルコインの発行には、管轄区域によって異なる規制上の義務が伴う可能性があります。このような理由から、ステーブルコインの発行は、信頼できる事業者が成功する可能性が高いといえます。
|
||||
|
||||
[](img/uc-stablecoin-flow.png)
|
||||
|
||||
新しいステーブルコインのリリース準備には、多くの決定事項や作成すべき成果物があります。XRPL財団の[自己評価アンケート](https://foundation.xrpl.org/wp-content/uploads/2022/03/self_assessment_questionnaire_140322.pdf)を出発点として、ローンチを成功させるために必要な情報を集め、作成することができます。
|
||||
|
||||
## ステーブルコインの種類を選択する
|
||||
|
||||
最初のステップは、作成したいステーブルコインの種類を決定することです。選択したステーブルコインの種類によっては、財務パートナーや監査パートナーとの署名など、追加のステップが必要になる場合があります。
|
||||
|
||||
|
||||
|
||||
XRPLで作成できる通貨トークンには、法定通貨担保、暗号資産担保、コモディティ担保、金融商品担保、非担保の5つの一般的なタイプがあります。[ステーブルコイン](stablecoins.html)をご覧ください。
|
||||
|
||||
## 自身のノードサービスを設定する
|
||||
|
||||
小規模なユースケースや個人であれば、無料のパブリックサーバを利用することができます。しかし、XRP Ledgerの利用が本格的になればなるほど、独自のインフラを持つことが重要になります。
|
||||
|
||||
独自のサーバを運用すべき理由はたくさんありますが、そのほとんどは、「自分のサーバが信頼できる」、「ワークロードをコントロールできる」、「いつ、どのようにアクセスするかを他人に依存しない」という点に集約されます。[独自サーバを運用する理由](networks-and-servers.html#独自サーバーを運用する理由)をご覧ください。
|
||||
|
||||
または、OpenNodeのような外部のノードサービスプロバイダを使用することもできます。[OpenNode](https://www.opennodecloud.com)をご覧ください。
|
||||
|
||||
## サンドボックスへのアクセス
|
||||
|
||||
|
||||
|
||||
テスト目的の場合、XRPL TestnetまたはDevnetサーバ上でステーブルコインを実装、デプロイ、取引することができます。XRP Faucetsページにアクセスし、テストネットワークの認証情報を生成してください。そのページに記載されているサーバURIを使用して、選択したテストネットワークに接続し、相互作用します。[XRP Faucets](xrp-testnet-faucet.html)をご覧ください。
|
||||
|
||||
|
||||
## 背景情報
|
||||
## ステーブルコインの設定
|
||||
|
||||
### トラストラインとトークン
|
||||
新しいステーブルコインを発行する前に、最初にコインを発行すると変更不可能とする設定を行う必要があります。
|
||||
|
||||
ネイティブ暗号通貨であるXRPを除くXRP Ledgerのすべての資産は、 _トークン_ として表され、その意味を定義する特定の発行者に結びつけられています。XRP Ledgerは、ユーザが望むトークンだけを保有し、受け取ることができるようにするために、 _トラストライン_ と呼ばれる双方向のアカウントの関係を持つシステムを備えています。
|
||||
[ステーブルコインの設定](stablecoin-settings.html)をご覧ください。
|
||||
|
||||
何らかの外部システムの資金に裏打ちされたトークンは、 _ステーブルコイン_ と呼ばれることがあります。これには、銀行口座の不換紙幣、別のブロックチェーン上の暗号通貨、あるいは他の種類の資産や価値の形態に裏打ちされたトークンが含まれます。「ステーブルコイン」という言葉は、トークンとそれが表す資産との交換レートが1：1(手数料を差し引いた値)で「安定」しているという考えに由来しています。
|
||||
設定機能の詳細については[ステーブルコイン発行者の設定](stablecoin-configuration.html)をご覧ください。
|
||||
|
||||
より詳細な情報は[トラストラインとトークン発行](trust-lines-and-issuing.html)をご覧ください。
|
||||
## 資産の情報
|
||||
|
||||
潜在的なトレーダーがコインの安全性を確認できるように、あなたのステーブルコインに関する標準的な情報を公開してください。
|
||||
|
||||
|
||||
### XRP
|
||||
### 資産の名称
|
||||
|
||||
**XRP**は、XRP Ledgerのネイティブ暗号通貨です。XRPは、どのXRP Ledgerのアドレスからでも、他のアドレスに直接送ることができます。これはXRPをブリッジ通貨として活用するのに便利です。
|
||||
通貨コードには3文字の文字列を選択してください。ISO4217では、非国家通貨コードは _X_ で始まります。[ISO 4217](https://ja.wikipedia.org/wiki/ISO_4217#X通貨)をご覧ください。
|
||||
|
||||
トークン発行者は、XRPを蓄積したり交換したりする必要はありません。準備金要件を満たし、ネットワークを通じてトランザクションを送信するコストを支払うために、少量のXRP残高を保有する必要があるだけです。XRP換算で10USドルあれば、取引量の多い発行者にとっては、少なくとも1年間のトランザクションコストを賄えるはずです。
|
||||
通貨コードは一意である必要はありません。例えば、ある国の法定通貨を担保とするステーブルコインを発行する場合、その通貨の公式コード、例えば _EUR_ を使用する方が良いでしょう。
|
||||
|
||||
より詳細な情報は[XRPとは？](what-is-xrp.html)や[準備金](reserves.html)、[トランザクションコスト](transaction-cost.html)をご覧ください。
|
||||
### xrp-ledger.toml
|
||||
|
||||
自身のWebサイトで`xrp-ledger.toml`を公開することで、どの通貨を発行し、どのXRP Ledgerアドレスを管理しているかという情報を公開することで、偽者や混乱から守ることができます。この機械読み取り可能なフォーマットは、クライアントアプリケーションが処理するのに便利です。XRP Ledgerバリデータを実行する場合、同じファイルでキーを公開することもできます。
|
||||
|
||||
_Currencies_ テーブルを使って、あなたのステーブルコインに関する追加情報を提供することができます。これにより、あなたの暗号通貨に関する情報に、期待される場所と形式でアクセスできるようになり、透明性が高まります。[xrp-ledger.tomlファイル](xrp-ledger-toml.html#通貨)をご覧ください。
|
||||
|
||||
|
||||
### 流動性と取引
|
||||
## アカウントと秘密鍵の管理
|
||||
|
||||
XRP Ledgerには分散型取引所があり、どのユーザもXRPとトークンを任意の組み合わせで交換するための注文を出し、それを約定することができます。分散型取引所は、アトミックな[クロスカレンシー決済](cross-currency-payments.html)を可能にする流動性も提供します。
|
||||
### マルチシグの方式
|
||||
|
||||
ステーブルコインの発行者は、分散型取引所を直接利用する必要はありませんが、すべてのトークンは自動的に取引可能になります。トークンが広く使われていれば、ユーザ同士で自然に取引され、他の人気アセットへの流動性が生まれるはずです。発行者は、特にそのトークンが新しい場合、XRPや他の人気のあるトークンに基準レートで流動性を提供したいと考えるかもしれません。ステーブルコインの発行者が流動性を提供する場合のベストプラクティスは、**取引用と発行用で異なるアドレスを使用することです**。
|
||||
複数のキーと署名の重みを使用することで、発行者と資産保有者は、異なるユーザとシステム間で、アカウントのトランザクションを承認するための信頼と責任を分散することができます。これにより、内部プロセスやコントロールを使用して署名を管理する柔軟性が生まれます。
|
||||
|
||||
分散型取引所の詳細については、[分散型取引所](decentralized-exchange.html)をご覧ください。
|
||||
[マルチシグ](multi-signing.html)をご覧ください。
|
||||
|
||||
<!-- TODO: figure out what to do with this
|
||||
Liquidity providers can use the [HTTP / WebSocket APIs](http-websocket-apis.html), [client libraries](client-libraries.html), or another application to access the distributed exchange. It may also help client applications to display information about your business if you provide an [`xrp-ledger.toml` file](xrp-ledger-toml.html).
|
||||
<!--
|
||||
### Omnibus Wallets
|
||||
|
||||
For customers who prefer not to take custody of their own wallets, you can create an omnibus account with subaccounts, then assign these accounts to customers.
|
||||
|
||||
## Treasury Management
|
||||
|
||||
### Reconciliation
|
||||
|
||||
Periodically audit to verify that distributed stablecoins and stablecoins in escrow equal the total number of stablecoins.
|
||||
|
||||
### Checking Reserves
|
||||
|
||||
How to check reserves.
|
||||
|
||||
### Proof of Reserves
|
||||
|
||||
How to transparently report the current number of stablecoins held in reserve.
|
||||
-->
|
||||
|
||||
## トークンの運用
|
||||
|
||||
## 推奨されるビジネスプラクティス
|
||||
### ステーブルコインの発行
|
||||
|
||||
XRP Ledgerにおけるステーブルコイン発行者のトークンの価値は、顧客が必要なときにトークンを換金できるという信頼に直結します。事業停止のリスクを減らすには、以下のベストプラクティスに従う必要があります。
|
||||
ステーブルコインを発行するのは簡単です。実際には、ユーザが安心して取引できるステーブルコインを発行するには、多くの考慮事項があります。
|
||||
|
||||
* ネットワーク上のリスク要因を限定するため、[発行・運用アドレス](account-types.html)を分けて使用する。
|
||||
* [銀行秘密保護法](http://en.wikipedia.org/wiki/Bank_Secrecy_Act)など、管轄区域のマネーロンダリング防止規制に従う。これには通常、["Know-Your-Customer" (KYC) 情報](https://ja.wikipedia.org/wiki/KYC)を収集する要件が含まれます。
|
||||
* XRP Ledger財団の[トークン発行者自己評価](https://foundation.xrpl.org/token-assessment-framework/)を完了する。
|
||||
* すべての方針と手数料を公表する。
|
||||
ステーブルコインを発行する前に、[自己評価アンケート](https://foundation.xrpl.org/wp-content/uploads/2022/03/self_assessment_questionnaire_140322.pdf)の質問をダウンロードして読んでください。ステーブルコインを配布する準備ができたら、公開されている[トークン発行者自己評価アンケート](https://foundation.xrpl.org/token-assessment-framework/)に記入してください。これにより、あなたの新しいステーブルコインについてXRPLコミュニティに透明性を提供することができます。
|
||||
|
||||
その他の考慮事項については、こちらをご覧ください、
|
||||
|
||||
### ホットウォレットとコールドウォレット
|
||||
- [ステーブルコイン発行者 - 注意事項](stablecoin-precautions.html)
|
||||
- [ステーブルコイン発行者 - コンプライアンス指針](stablecoin-compliance-guidelines.html)
|
||||
- [代替可能トークンの発行](issue-a-fungible-token.html)
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.ja.md' %}
|
||||
### トラストラインの作成
|
||||
|
||||
主な記事: [発行アドレスと運用アドレス](account-types.html)
|
||||
トラストラインは、トークンを保持するためのXRP Ledgerの仕組みです。トラストラインは、XRP Ledgerのルールである、他人が望んでいないトークンを保持することを禁止するものです。このような予防措置は、XRP Ledgerのユースケースであるコミュニティクレジットを可能にするために必要です。
|
||||
|
||||
各「トラストライン」は、次の要素から構成される双方向の関係です。
|
||||
|
||||
## 手数料および収益源
|
||||
- トラストラインが接続する2つのアカウントの識別子。
|
||||
- 一方のアカウントから見てプラス、他方のアカウントから見てマイナスの、単一の共有残高。
|
||||
- 様々な設定とメタデータ。2つのアカウントはそれぞれ、トラストライン上の独自の設定を制御できます。それぞれがトラストラインの上限を設定します。
|
||||
|
||||
ステーブルコイン発行者は、以下のような様々な方法で収益を得ることができます。
|
||||
各トラストラインは、指定された通貨コードに対して固有のものです。2つのアカウントは、異なる通貨コードのトラストラインをいくつでも持つことができますが、特定の通貨コードの共有トラストラインは1つだけです。
|
||||
|
||||
- 出金または入金の手数料。発行者は、XRP Ledgerに資金を出し入れするサービスに対して、少額の手数料(1％など)を請求することができます。この手数料はXRP Ledger上では請求されませんが、発行者がユーザに発行または入金する金額を決定する際に、独自のシステムで請求されます。
|
||||
- 送金手数料。発行者は、ユーザがXRP Ledger内でステーブルコインを送金する際に請求する手数料をパーセンテージで設定することができます。この金額は、ユーザが取引を行うたびにXRP Ledgerから引き落とされ、発行者がレジャーの外で保有する資産の量を減らすことなく、ステーブルコインの発行者がレジャー内でユーザに対する債務の総額を減少させることができます。
|
||||
- 付加価値による間接的な収益。ステーブルコインは、他の関連するサービスの導入を容易にすることができる便利な機能を提供します。
|
||||
- 担保への利息。担保の利子について発行者は、ステーブルコインの担保となる資産を利子のつく口座で保有することができます。もちろん、顧客の引き出しに対応できる十分な資金に常にアクセスできるようにする必要があります。
|
||||
- 金融取引所。事業者は分散型取引所で自社のステーブルコインを売買し、クロスカレンシー決済に流動性を与え、場合によっては利益を得ることができます。(すべての金融取引と同様に、利益は保証されません)。
|
||||
[トラストライン](trust-lines-and-issuing.html#トラストライン)をご覧ください。
|
||||
|
||||
### 認可トラストライン
|
||||
|
||||
### 手数料の選択
|
||||
認可トラストライン機能は、発行者が特別に認可したアカウントでのみ保有できるトークンを作成することを可能にします。この機能はトークンにのみ適用され、XRPには適用されません。
|
||||
|
||||
トークンの手数料はオプションです。高い手数料は、そのトークンが使用されたときに、より多くの収益を得ることができます。一方、手数料が高いと、顧客のサービス使用意欲を低下させます。他の発行者、特に同じ種類の資産を裏付けとするトークンを持つ他の発行者が請求する手数料や、送金手数料のようなXRP Ledger以外の伝統的な決済システムなどを考慮するとよいでしょう。正しい手数料体系を選択するためには、あなたの価格設定と市場が支払うことを望んでいる価格とのバランスをとることが重要です。
|
||||
認可トラストライン機能を使用するには、発行アカウントで`Require Auth`フラグを有効にします。この設定を有効にしている間、他のアカウントはあなたが発行したトークンを保持することができます。
|
||||
|
||||
[認可トラストライン](authorized-trust-lines.html)をご覧ください。
|
||||
|
||||
## コンプライアンス指針
|
||||
|
||||
トークン発行者は、各国の規制を遵守し、適切な機関に報告する責任があります。規制は国や州によって異なりますが、以下のセクションで説明する報告やコンプライアンスの要件が含まれる場合があります。トークンを発行する前に、管轄区域やユースケースの要件について、専門家の法的助言を求める必要があります。以下のリソースは、背景情報として参考になる可能性があります。
|
||||
### トラストラインのFreeze
|
||||
|
||||
### Know Your Customer (KYC)
|
||||
XRP Ledgerでトークンを発行する場合、_No Freeze_ 設定を有効にすることで、XRP Ledgerのトークン凍結機能を利用することを永久に停止することができます。(注意点として、これは発行されたトークンにのみ適用され、XRPには適用されません)。
|
||||
|
||||
KYC(Know Your Customer)とは、金融機関が犯罪行為に利用されるのを防ぐために、顧客の身元を特定し確認するために行うデューデリジェンス活動のことです。金融用語でいう犯罪行為には、マネーロンダリング、テロ資金調達、金融詐欺、個人情報盗難などが含まれます。顧客は、個人、仲介者、企業のいずれでもあり得ます。
|
||||
_No Freeze_ 設定を有効にしない場合、アカウントが疑わしい動きを示したり、金融機関の利用規約に違反したりした場合、問題を解決する間、トラストラインを凍結する選択肢があります。
|
||||
|
||||
KYCプロセスは、一般的に次のことを目的としています。
|
||||
[トラストラインの凍結](freezes.html)をご覧ください。
|
||||
|
||||
- 顧客(組織や企業の場合は、実質的な所有者)の特定
|
||||
|
||||
- 取引関係の目的および意図された事項の理解
|
||||
### Global Freeze
|
||||
|
||||
- 想定される取引活動の把握
|
||||
不審な活動の兆候が見られた場合、アカウントをグローバルに凍結し、ユーザがトークンを相互に送信したり、分散型取引所でトークンを取引したりできないようにすることができます。
|
||||
|
||||
KYCは、金融機関や関連企業にとって、リスク、特に法的リスクや風評リスクを軽減するために重要です。KYCプログラムが不十分であったり、存在しなかったりすると、金融機関や従業員個人に対して民事上・刑事上の罰則が科される可能性があります。
|
||||
|
||||
|
||||
関連項目:
|
||||
[Global Freezeの実行](enact-global-freeze.html)をご覧ください。
|
||||
|
||||
- [(米国）銀行秘密保護法／マネーロンダリング防止審査マニュアル](https://bsaaml.ffiec.gov/manual/Introduction/01)
|
||||
|
||||
- [金融活動作業部会(FATF)が定めたKYCに関する米国以外の基準について](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
|
||||
### Clawback
|
||||
|
||||
### マネーロンダリング防止(AML)およびテロ資金調達対策(CFT)について
|
||||
_([Clawback amendment][] :not_enabled: が必要です。)_
|
||||
|
||||
マネーロンダリングとは、資金源、性質、所有者を偽装することによって違法な資金を移動させ、合法的な金融チャネルや信頼できる機関を通じて資金を合法的にアクセスまたは分配できるようにするプロセスである。つまり、「不正なお金」を「不正でないお金」に変換することです。アンチマネーロンダリング(AML)とは、マネーロンダリングの発生を阻止するために作られた法律と手続きのことです。
|
||||
Clawbackは、ステーブルコインの配布を開始する前に選択できるオプション設定です。規制上の目的から、発行者の中には発行されたトークンをアカウントに配布した後に回収する能力を持たなければならない場合があります。例えば、トークンが違法行為で制裁を受けたアカウントに送られたことが発覚した場合、発行者はその資金を回収することができます。
|
||||
|
||||
テロ資金とは、テロ活動に従事する組織、またはテロやその拡散を支援する組織に対する資金の勧誘、収集、提供のことです。テロ資金調達対策(CFT)とは、テロ資金調達に使われる資金の流れを特定し、報告し、阻止するプロセスを指します。
|
||||
[Clawback](clawback.html)をご覧ください。
|
||||
|
||||
関連項目:
|
||||
|
||||
|
||||
- ["マネーロンダリングとテロリズム・拡散の資金調達との闘いに関する国際基準" 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)
|
||||
部分支払い(Partial Payment)に注意してください。partial paymentフラグが有効になっている支払いは、0でない金額が着金した場合、微々たる金額であっても"成功"とみなされます。
|
||||
* トランザクションに`delivered_amount`フィールドがあるか確認してください。もし存在すれば、そのフィールドは`Destination`アドレスに実際にいくら着金したかを示します。
|
||||
* xrpl.jsでは、[`xrpl.getBalanceChanges()`メソッド](https://js.xrpl.org/modules.html#getBalanceChanges)を使って、各アドレスがいくら受け取ったかを見ることができます。場合によっては、これを複数のトラストラインに分けることもできます。
|
||||
*
|
||||
[Partial Payments](partial-payments.html)をご覧ください。
|
||||
|
||||
### 資金源
|
||||
### バーン
|
||||
|
||||
金融機関は、不正な資金がシステムを通過するのを防ぐために、顧客の資金源が犯罪行為と関連しているかどうかを合理的に判断する必要があります。
|
||||
トークンの価値を管理する一つの方法は、トークンを破棄すること、つまりトークンを「バーン」することです。XRP Ledger上では、発行アドレスにトークンが送られると、代替可能なトークンは自動的に「バーン」されます。しかし、発行者は自由にトークンを増やすことができます。
|
||||
|
||||
すべての顧客の正確な資金源を特定することは、管理上実行不可能な場合があります。その結果、規制当局の中には、すべての口座について特定の規制やガイダンスを提供しない場合もある。しかし、特定の場合には、当局は金融機関に対して資金源を特定し報告することを求めることができる。FATFのガイダンスでは、マネーロンダリングやテロ資金供与のリスクが高い場合(一般に「リスクに応じたアプローチ」と呼ばれる)、金融機関は顧客の資金源を特定することを含むがこれに限定されないデューデリジェンスの強化を行うことを勧告しています。
|
||||
供給量の上限を確実にするために、トークンを発行した後、発行者のレギュラーキーを`rrrrrrrrrrrrrrrrrrrrrhoLvTp`のような誰も秘密鍵を知らないアドレスに設定し、マスターキーペアを無効にすることで、「ブラックホール化」することができます。
|
||||
|
||||
### 不審行為報告書
|
||||
**注意:** ブラックホール済アカウントはトランザクションを送信する手段を持たないため、その後アカウントに関する設定を更新したり、メンテナンスを行ったりすることはできません！
|
||||
|
||||
金融機関は、資金が犯罪行為に関連している可能性があると疑われる場合、適切な規制当局に不審行為報告書/Suspicious Activity Report (SAR)を提出する必要があります。疑わしい活動を報告しなかった場合、金融機関は罰則を受ける可能性があります。
|
||||
[マスターキーペアの無効化](disable-master-key-pair.html)をご覧ください。
|
||||
|
||||
関連項目:
|
||||
### 信頼できるトランザクションの送信
|
||||
|
||||
- [不審行為報告書の概要(米国FFIEC)](https://bsaaml.ffiec.gov/manual/RegulatoryRequirements/04_ep)
|
||||
確実にトランザクションを送信するためには、以下の2つの条件を有限の時間で実現する必要があります：
|
||||
|
||||
- [FATF勧告16：不審な取引の報告およびコンプライアンス](http://www.fatf-gafi.org/publications/fatfrecommendations/documents/fatf-recommendations.html)
|
||||
* 冪等性 - トランザクションは一度だけ処理されるか、まったく処理されないこと。
|
||||
* 検証可能性 - アプリケーションはトランザクションの最終結果を判断できること。
|
||||
|
||||
### トラベルルール
|
||||
トランザクションを確実に送信するには、以下のガイドラインに従ってください。
|
||||
|
||||
トラベルルールとは、銀行機密保護法(BSA)に基づき、資金送金が米ドル換算で3,000ドル以上の場合、資金送金を行う金融機関に特定の情報を次の金融機関に転送することを義務付けるルールです。送金指示書には、以下の情報を記載する必要があります。
|
||||
* トランザクションを送信する前にトランザクションの内容を永続化すること。
|
||||
* `LastLedgerSequence`パラメーターを使用すること。(多くの[クライアントライブラリ](client-libraries.html)はデフォルトでそうなっています)。
|
||||
* 現在の[レジャーインデックス][]がトランザクションの`LastLedgerSequence`パラメータ以下である検証済みのレジャーにトランザクションが表示されていない場合、トランザクションを再送信してください。
|
||||
|
||||
- 送信者の氏名
|
||||
- 送信者の口座番号(使用する場合)
|
||||
- 送信者の住所
|
||||
- 送金者の金融機関の名称
|
||||
- 送信指示の金額
|
||||
- 送金注文の金額、送金注文の実行日
|
||||
- 受取人の金融機関の名称
|
||||
詳しくは[信頼できるトランザクションの送信](reliable-transaction-submission.html)をご覧ください。
|
||||
|
||||
関連項目:
|
||||
### XRPLネイティブDEXへのリスト
|
||||
|
||||
- [ファンドの「トラベル」規制について： 質問と回答](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers)
|
||||
分散型取引所(DEX)は分散型金融エコシステムに不可欠です。あなたのトークンをXRP Ledger組み込みのDEXに上場することで、その認知度と流動性を高めることができます。まず、[Sologenic](https://sologenic.org/trade)のような適切なインターフェイスを使って売りのオファーを出しましょう。念のため、取引には発行アドレスではなく別のアカウントを使用してください。
|
||||
|
||||
### 手数料の開示と資金の追跡
|
||||
|
||||
- 米国では、Dodd Frank 1073 Electronic Fund Transfer Act (Regulation E)により、銀行は米国発の国際決済について、為替レート、手数料、外国の指定受取人が受け取る金額など、コストと配送条件に関する情報を提供することが義務付けられています。「Pre-payment disclosure」は国際電子決済を依頼する際に消費者に提供され、「Receiption disclosure」は消費者が送金を許可する際に消費者に提供されます。
|
||||
### AMMへのリスト
|
||||
_([AMM amendment][] :not_enabled: が必要です。)_
|
||||
|
||||
関連項目
|
||||
自動マーケットメイカー(AMM)は、XRP Ledgerの分散型取引所で流動性を提供するスマートコントラクトです。各AMMは2つの資産のプールを保有し、計算式で設定された取引レートでユーザがそれらの間でスワップを行うことを可能にします。
|
||||
|
||||
- [消費者金融保護局の説明による、銀行に対する規制とその適用範囲について](https://www.consumerfinance.gov/rules-policy/final-rules/electronic-fund-transfers-regulation-e/#rule)
|
||||
どの資産ペアに対しても、レジャーには最大1つのAMMが存在します。資産ペアのAMMがまだ存在しない場合は、新しいトークンでAMMを作成するか、別の既存のAMMに預けることができます。AMMに資産を預ける人は、流動性提供者(LP)と呼ばれ、AMMからLPトークンを受け取ります。
|
||||
|
||||
- 欧州連合(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)
|
||||
|
||||
|
||||
|
||||
|
||||
# XRP Ledgerの統合
|
||||
|
||||
本書では、ACME Exchangeという架空の暗号資産取引所が、XRP Ledger上でEURステーブルコインを発行することを決定した例を用いて、ステーブルコインの全体プロセスや資金フローを説明します。
|
||||
|
||||
## 統合前
|
||||
|
||||
暗号資産取引所としてのACMEは、すでに何らかのシステム(アプリやウェブサイトなど)を使って顧客からの出金や入金を受け付けています。ACMEは、各ユーザが数種類の資産のそれぞれをどれだけ取引所に保有しているかを追跡するための「記録システム」を持っています。このようなシステムは、単純な貸借対照表でモデル化することができますが、実際には、データベースやアプリケーションサーバ、その他信頼性や情報セキュリティなどを確保するためのさまざまなインフラが必要でしょう。
|
||||
|
||||
以下の図では、ACME Exchangeは、Bobの所有する1ユーロ、Charlieの所有する2ユーロ、さらにACME自身の所有する2ユーロの資本を含み、手元に5ユーロでスタートする。Aliceが5ユーロを入金したので、ACMEは彼女をバランスシートに加え、最終的に10ユーロになります。
|
||||
|
||||
|
||||
|
||||
**前提条件:** XRP Ledgerと連携するために、ACMEのような取引所が以下の前提を満たしていることを想定しています。
|
||||
|
||||
* ACMEはすでに、何らかの外部の決済手段から入出金を受け付けるシステムを持っています。
|
||||
* ACMEは、ACMEの記録システムに入金される前に、入金の処理を待ちます。
|
||||
* ACMEは、その条件に従って、要求に応じて引き出しを行うのに十分な資金を常に手元に置いています。
|
||||
* ACMEは、そのビジネスモデルの必要に応じて、手数料、最低出金額、入出金の遅延時間などを設定することができます。
|
||||
|
||||
## XRP Ledgerへの送金
|
||||
|
||||
XRP Ledgerに _お金を送る_ には、ACMEがユーザの代わりに保有している金額に対して、新しいステーブルコインを発行する必要があります。フロー例としては、以下のようなものがあります。
|
||||
|
||||
1. AliceはACMEの残高のうち3ユーロをXRP Ledgerに送るよう依頼します。
|
||||
2. ACMEの記録システムでは、アリスの残高€3が差し引かれます。
|
||||
3. ACMEはXRP Ledgerのトランザクションを提出し、アリスのXRP Ledgerのアドレスに3ユーロを送ります。3ユーロはXRP Ledgerで、ACMEによって「発行」されたものとしてマークされます(3 EUR.ACME)。
|
||||
|
||||
**前提条件:**
|
||||
|
||||
* AliceはすでにACMEアカウントとは別にXRP Ledgerにアドレスを持っています。Aliceは、サードパーティのクライアントアプリケーション(ウォレット)を使って、自分のXRP Ledgerのアドレスを管理しています。
|
||||
|
||||
|
||||
|
||||
<!--{# Disabled: UMLet version of this diagram.
|
||||
{{ include_svg("img/gateway-to-xrpl.svg", "Diagram: ACME issues 3 EUR.ACME to Alice on the XRP Ledger") }}
|
||||
#}-->
|
||||
|
||||
この後、Aliceは自分のEUR.ACMEをXRP Ledgerの他のユーザに任意で送金したり取引したりすることができます。ACMEはいつでも、XRP Ledgerに照会して、誰が現在そのトークンを保持しているかを確認することができます。
|
||||
|
||||
### XRP Ledgerへ送金するための要件
|
||||
|
||||
そのためには、ACMEが満たさなければならない前提条件がいくつかあります。
|
||||
|
||||
- ACMEは、自社のステーブルコインを支える資金を確保します。その方法にはいくつか考えられます。
|
||||
- ACMEは、ACMEの記録システムにおいてXRP Ledger用担保口座を作成する。
|
||||
- ACMEは、XRP Ledgerに割り当てられた資金を、別の銀行口座に保管することもできます。
|
||||
- ステーブルコインが暗号資産によって支えられている場合、ACMEはXRP Ledgerに割り当てられた資金を保持するための別のウォレットを作成し、その準備金を公に検証可能な証明とすることができます。
|
||||
- ACME は、2つの別々のXRP Ledgerアドレスを管理する必要があります。詳細は[発行・運用アドレス](account-types.html)をご覧ください。
|
||||
- ACMEは、顧客がそのトークンを送受信するために、その発行アドレスでDefault Rippleフラグを有効にする必要があります。
|
||||
- Aliceは自分のXRP LedgerアドレスからACMEの発行アドレスへのアカウント関係(トラストライン)を作成する必要があります。彼女はACMEの発行アドレスを知っている限り、どのXRP Ledgerのクライアントアプリケーションからでもトラストラインの作成を行うことができます。
|
||||
- 発行アドレスは、ACMEのウェブサイト上で顧客が見つけることができるように公表する必要があります。また、[`xrp-ledger.toml`ファイル](xrp-ledger-toml.html)を使用して、自動化されたシステムに発行アドレスを公開することも出来ます。
|
||||
- また、ACMEはペイメントを送る代わりに、XRP LedgerにAliceに小切手を送付することもできます。この場合、資金はすぐに移動しませんが、アリスが小切手を現金化する際、トークンが送付されると同時にトラストラインが作成されます。
|
||||
- ACMEは、AliceがACME上の自身の資金をXRP Ledgerへ送ることを依頼するためのユーザインターフェイスを作成しなければなりません。
|
||||
- ACMEはAliceのXRP Ledger・アドレスを把握する必要があります。ACMEはAliceにインターフェイスの一部として彼女のXRP Ledgerアドレスを入力させる事も出来ますし、ACMEはAliceに彼女のXRP Ledgerアドレスを事前に入力し、確認するよう要求する事も出来ます。
|
||||
|
||||
|
||||
## XRP Ledgerからの送金
|
||||
|
||||
XRP Ledgerからの支払いは、発行者がXRP Ledgerで支払いを受け取り、発行者の記録システムでユーザに入金することを意味します。
|
||||
|
||||
XRP Ledgerから入金されるフロー例
|
||||
|
||||
1. BobはACMEの発行アドレスに1ユーロのXRP Ledgerのトランザクションを送信します。
|
||||
2. ACMEの記録システムでは、ACMEはBobの残高に€1を入金します。
|
||||
3. その後、ボブはACME独自のインターフェースを使って、SEPAシステム(欧州)やACH(米国)を使った銀行預金の依頼、他のブロックチェーンでの支払いの受け取りなど、別の口座にお金を引き出すことができます。
|
||||
|
||||
XRP Ledgerにおける発行者への支払いは、単一通貨建てでもクロスカレンシー建てでも可能ですが、発行者が受け取る金額は通常、発行したステーブルコイン建てとなります。
|
||||
|
||||
|
||||
### XRP Ledgerへの入金の要件
|
||||
|
||||
XRP Ledgerに送信するための要件に加えて、ACMEがXRP Ledgerでの入金を処理するために満たすべき前提条件がいくつかあります。
|
||||
|
||||
- ACMEは、XRP Ledgerのアドレスへの入金を監視する必要があります。
|
||||
- ACMEは、入金された支払いについて、その記録システムでどのユーザに入金すべきかを特定する必要があります。
|
||||
- ACMEは、不明な入金を送信者に返金する必要があります。
|
||||
- 一般的に、入金を識別する方法としては、[宛先タグ](source-and-destination-tags.html)を使用することが推奨されています。
|
||||
|
||||
|
||||
## 注意事項
|
||||
|
||||
XRP Ledgerとの間で支払いを処理することは、当然ながらいくつかのリスクを伴うものであり、発行者はこれらの処理を実施する際には細心の注意を払う必要があります。ステーブルコインの発行者としては、以下の点に注意する必要があります。
|
||||
|
||||
- 可逆的な預金から身を守る。XRP Ledgerの支払いは不可逆的ですが、多くのデジタル支払いはそうではありません。悪質な業者はこれを悪用して、XRP Ledgerでトークンを受け取った後に取引所からの出金をキャンセルして、現金(fiat money)を奪い取ろうとすることがあります。
|
||||
- XRP Ledgerに送金する際は、トークンの発行元として必ず発行者自身のアドレスを指定してください。そうでない場合、他のアドレスが発行した同じ通貨を送金するパスを誤って使用する可能性があります。
|
||||
- XRP Ledgerに支払いを送信する前に、支払いのコストを再確認してください。あなたの運用アドレスから顧客への支払いは、宛先金額とあなたが設定した送金手数料を超える費用は発生しないはずです。
|
||||
- XRP Ledgerから支払いを処理する前に、顧客の身元を確認するようにしてください。これにより、匿名の攻撃者による不正行為が難しくなります。いずれにせよ、ほとんどのマネーロンダリング防止規制はこれを求めています。XRP Ledgerから入金するユーザは、XRP Ledgerで最初に出金ユーザと異なる可能性があるため、これは特に重要です。
|
||||
- XRP Ledgerのトランザクションを送信する際には、信頼性の高いトランザクション送信のためのガイドラインに従ってください。
|
||||
- 入金をしっかりと監視し、正しい金額を把握する。相手が[部分支払い](partial-payments.html)による送金にもかかわらず、間違っても全額を入金しないように注意する必要があります。
|
||||
- XRP Ledger内の負債と残高を追跡し、担保口座の資産と比較してください。一致しない場合は、相違点を解決するまで、引き出しと入金の処理を停止してください。
|
||||
- あいまいな状況を避けることを推奨しています。
|
||||
- 顧客が誤ってXRPを送らないように、発行アドレスとすべての運用アドレスに対して「Disallow XRP」フラグを有効にしてください。(民間取引所は通常XRPを取引するため、このフラグを設定するべきではありません。)
|
||||
- 発行アドレスとすべての運用アドレスに対して、[`RequireDest`フラグ](require-destination-tags.html)を有効にすることで、顧客が誤って入金先を示す宛先タグなしで支払いを送信することがないようにします。
|
||||
- 誤って通貨を発行できないように、すべての運用アドレスで`RequireAuth`フラグを有効にする。
|
||||
- 疑わしい行動や不正な行動を監視する。例えば、ユーザがXRP Ledgerに繰り返し資金を出し入れすることで、運用アドレスの残高を実質的に空にするサービス拒否攻撃などが考えられます。不審な行動に関与している顧客のアドレスのXRP Ledgerの支払いを処理しないことで、その顧客の利用を一時停止することも考えられます。
|
||||
|
||||
## XRP Ledger上での取引
|
||||
|
||||
XRP Ledgerでトークンが送付された後、XRP Ledgerのユーザはトークンを自由に譲渡したり取引したりすることができる。このような状況では、いくつかの影響が生じます。
|
||||
|
||||
- 誰でもXRP Ledger上でEUR.ACMEを売買することができます。ACMEが複数のトークンを発行する場合、それぞれ別のトラストラインが必要です。
|
||||
- これには、ACME Exchangeのシステムにアカウントを持っていないXRP Ledgerのユーザも含まれます。ACMEから資金を適切に引き出すには、ユーザはACMEに登録する必要があります。
|
||||
- オプションとして、ACMEは認可トラストライン機能を使用して、XRP LedgerでEUR.ACMEを保有できる人を制限することができます。
|
||||
- ACMEは、顧客が不正な行為をしたと判断した場合、XRP LedgerにおいてそのユーザのACMEに対する会計関係を凍結し、そのユーザが発行者のトークンを取引できないようにすることができます。
|
||||
- XRP Ledgerのユーザが互いにEUR.ACMEを取引・送信する場合、ACMEによる介入は一切不要です。
|
||||
- XRP Ledger上のすべての取引所と残高はすべて公開されています。
|
||||
|
||||
次の図は、AliceからCharlieに2EUR.ACMEを送るXRP Ledgerの支払いを表しています。ACMEはトランザクションが発生した後、いつでもその残高の更新を確認するためにXRP Ledgerに問い合わせることができます。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## 凍結
|
||||
|
||||
発行者は、規制要件を満たすために、XRP Ledgerの会計関係を凍結することができます。
|
||||
|
||||
* 発行者は、顧客アドレスに不審な動きが見られたり、発行者の利用規約に違反した場合に備えて、個別の会計関係を凍結することができます。
|
||||
* 発行者は、重大なセキュリティ侵害や新しい発行アドレスへの移行に備え、発行したトークンをすべて凍結することもできます。
|
||||
* さらに、発行者は、会計関係を凍結する能力を永久的に放棄することができます。これにより、発行者は「物理的なお金に近い」サービスを提供し続けることを顧客に保証することができます。
|
||||
|
||||
より詳細な情報は[トークンの凍結](freezes.html)をご覧ください。
|
||||
|
||||
|
||||
## 認可トラストライン
|
||||
|
||||
XRP Ledgerの認可トラストライン機能(旧称「認可アカウント」)は、発行者がその発行者のトークンを保有できる人を制限することを可能にし、未知のXRP Ledgerのアドレスがトークンを保有できないようにします。
|
||||
|
||||
より詳細な情報は[認可トラストライン](authorized-trust-lines.html)をご覧ください
|
||||
|
||||
|
||||
## 送信タグと宛先タグ
|
||||
|
||||
*宛先タグ*は、XRP Ledgerの支払いの機能の一つで、支払いの受取人または宛先を示すために使用されます。例えば、XRP Ledgerの発行者への支払いは、どの顧客にその支払いが入金されるかを示すために、宛先タグを含むことができます。発行者は、発行者の記録システムにおいて、宛先タグと口座のマッピングを保持する必要があります。
|
||||
|
||||
同様に、*送金タグ*は、支払の発信者または送信元を示します。最も一般的なのは、支払いの受取人が支払いを返金する場所を知るために、送金タグを含めることです。受信した支払いを返金する場合、受信した支払いの送金タグを送信(返金)する支払いの宛先タグとして使用します。
|
||||
|
||||
顧客が送金しようとするときに、オンデマンドで宛先タグを生成することができます。顧客のプライバシーを守るため、その宛先タグは予定金額の支払いに対してのみ有効であると考え、同じ宛先タグを再利用する他のトランザクションは返金するか無視する必要があります。
|
||||
|
||||
発行アドレスと運用アドレスで[宛先タグを要求する設定](require-destination-tags.html)を有効にすることで、顧客は支払いを送る際に宛先タグを使用して資金の入金先を示す必要が生まれます。
|
||||
|
||||
より詳細な情報は[送信タグと宛先タグ](source-and-destination-tags.html)をご覧ください
|
||||
|
||||
|
||||
# 技術的な内容
|
||||
|
||||
## インフラストラクチャ
|
||||
|
||||
あなた自身のセキュリティとネットワークの安定性のために、XRP Ledgerを利用する事業者は、1つの[バリデータ](rippled-server-modes.html#validators)を含む[独自のXRP Ledgerサーバ](install-rippled.html)を実行すべきです。
|
||||
|
||||
|
||||
### APIとミドルウェア
|
||||
|
||||
XRP Ledgerへの接続方法は、ニーズや 既存のソフトウェアに応じて、いくつかのインターフェイスを使用することができます。
|
||||
|
||||
- [HTTP / WebSocket API](http-websocket-apis.html)は、XRP Ledgerのすべてのコア機能への低レベルのインターフェースとして使用することができます。
|
||||
- [クライアントライブラリ](client-libraries.html)は、いくつかのプログラミング言語で利用でき、XRP Ledgerにアクセスするための便利なユーティリティを提供します。
|
||||
- その他、[xApps](https://xumm.readme.io/docs/xapps)などのツールも利用可能です。
|
||||
- サードパーティのウォレットアプリケーションも、特に待機アドレスを担当する人間には便利かもしれません。
|
||||
|
||||
|
||||
## ツールのセキュリティ
|
||||
|
||||
XRP Ledgerのトランザクションを送信するときはいつでも、あなたの秘密鍵を使って署名する必要があります。秘密鍵は、あなたのXRP Ledgerアドレスを完全にコントロールすることができます。**決して**他人が運営するサーバにあなたの秘密鍵を送ってはいけません。自分のサーバを使うか、クライアントライブラリを使用してローカルでトランザクションに署名してください。
|
||||
|
||||
安全な設定の手順や例については、[安全な署名の設定](secure-signing.html)をご覧ください。
|
||||
|
||||
## 発行者のセットアップ
|
||||
|
||||
トークンの発行を開始する前に、XRP Ledgerアカウントで設定する必要がある設定がいくつかあります。これらの設定の例については、[代替可能トークンを発行するチュートリアル](issue-a-fungible-token.html)をご覧ください。
|
||||
|
||||
設定すべき項目は以下の通りです。
|
||||
|
||||
| 設定 | 備考 |
|
||||
|---------|-------|
|
||||
| Default Ripple | 発行者は、このフィールドを**必ず**有効にする必要があります。 |
|
||||
| Deposit Authorization | 明示的に承認していないユーザからの入金をすべてブロックします。 |
|
||||
| Require Auth | トークンの保持を、明示的に承認したユーザに限定します。 |
|
||||
| Tick Size | 分散型取引所の取引所為替レートを四捨五入して、より迅速な価格決定を可能にします。 |
|
||||
| Transfer Fee | ユーザ同士がトークンを送信する際に、一定割合の手数料を徴収します。 |
|
||||
|
||||
|
||||
### Default Ripple
|
||||
|
||||
Default Rippleフラグは、トラストラインの残高をデフォルトで[Ripplingを許可](rippling.html)するかどうかを制御します。Ripplingは顧客同士のトークンの送信や取引を可能にするものなので、発行者はその発行アドレスへのすべてのトラストラインでのRipplingを許可しなければなりません(MUST)。
|
||||
|
||||
顧客に発行アドレスへのトラストラインの作成を依頼する前に、発行者はそのアドレスのDefault Rippleフラグを有効にする必要があります。そうでない場合、発行者は、他のアドレスが作成した各トラストラインのNo Rippleフラグを個別に無効化する必要があります。
|
||||
|
||||
|
||||
### Deposit Authorization
|
||||
|
||||
Deposit Authorizationの設定は、以下のいずれかを行わない限り、アカウントへのすべての入金をブロックします。
|
||||
|
||||
- 事前に送信者を事前認可している。
|
||||
- 資金を受け取るためにトランザクションを送信します。例えば、他人が開始したエスクローを終了させることができます。
|
||||
|
||||
Deposit Authorizationは、不要なXRPの支払いをブロックするのに最も有効です。なぜなら、発行元へのトラストラインを作成しない限り、既にトークンを受け取ることはできないからです。しかし、ステーブルコインの発行者としては、ステーブルコインをレジャー外の価値と交換するために、ユーザからの支払いを受け取ることができる必要があります。顧客を事前認可することはできますが、そうすると、顧客それぞれのアドレスについてレジャーにオブジェクトを格納する必要があり、準備金が大幅に増加します。
|
||||
|
||||
したがって、未知または制裁を受けたエンティティからお金を受け取ることに関する規制要件を満たすために必要でない限り、Deposit Authorizationはステーブルコインの発行者に推奨されません。
|
||||
|
||||
より詳細な情報は[Deposit Authorization](depositauth.html)をご覧ください。
|
||||
|
||||
|
||||
### Disallow XRP
|
||||
|
||||
Disallow XRPの設定は、XRP Ledgerのユーザが誤ってXRPをアドレスに送信することを阻止するために設計されています。これは、XRPの受信と保持を意図していないアドレスからの不必要な返金コストと労力を削減するものです。なぜなら、そうすることでアドレスがXRPを誤って送金した場合に返金されずにXRPを失う可能性があるからです。クライアントアプリケーションは、デフォルトでDisallow XRPフラグを尊重すべきですが、ユーザがそれを無視することを許可する場合もあります。
|
||||
|
||||
Disallow XRPフラグはオプションですが、顧客からXRPを受け取るつもりがない場合は、発行アドレスとすべての運用アドレスで有効にしておくとよいでしょう。
|
||||
|
||||
|
||||
### Require Auth
|
||||
|
||||
Require Authの設定は、最初にトラストラインを明示的に承認しない限り、発行したトークンをユーザが保持することをブロックします。XRP Ledger内で誰があなたのトークンを保持するかが重要である場合、規制要件を満たすためにこの設定を使用することができます。しかし、この設定は、ユーザへの承認がトークンを使用するためのボトルネックとなるため、トークンの有用性を低下させる可能性があります。
|
||||
|
||||
また、トラストラインを認可するたびに発行アドレスを使用する必要があります。多くのトラストラインを認可する必要がある場合、発行アドレスを頻繁に使用することになるため、発行アドレスのセキュリティが損なわれる可能性があります。(発行アドレスの使用頻度が少ない場合は、秘密鍵の保護を強化することができます。使用頻度が高ければ高いほど、その保護は大きな負担となります)。
|
||||
|
||||
より詳細な情報は[Authorized Trust Lines](authorized-trust-lines.html)をご覧ください。
|
||||
|
||||
|
||||
### Tick Size
|
||||
|
||||
Tick Sizeは、[分散型取引所](decentralized-exchange.html)で為替レートを計算する際に使用する小数点以下の桁数を制御する設定です。Tick Sizeを大きくすると、より精度が高くなり、さまざまな取引の金額で丸め込みが少なくなります。取引は主に取引レートに基づいてランク付けされるため、トレーダーがリストの上位にわずかな金額を提供することができるため、精度が高すぎると不都合になることがあります。Tick Sizeを小さくすると、オークションの最低入札額と同じような効果があり、無関係な小額を徐々に入札する時間と労力が省けます。しかし、Tick Sizeを小さくすると四捨五入が多くなり、取引コストが高くなります。また、四捨五入前は完全に一致するように見えた2つのオファーが、四捨五入後は一致しなくなるという意外な結果になることもあります。
|
||||
|
||||
Tick Sizeはアカウントレベルの設定であり、同じアドレスで発行されたすべてのトークンに適用されます。
|
||||
|
||||
Tick Sizeは取引レートの精度を制御するだけで、トークン自体の精度を制御するものではありません。ユーザは、トークンの発行者が設定したTic Sizeに関係なく、非常に大きな金額や非常に小さな金額を送ったり保有したりすることができます。
|
||||
|
||||
より詳細な情報は[Tick Size](ticksize.html)をご覧ください。
|
||||
|
||||
|
||||
### Transfer Fees
|
||||
|
||||
送金手数料の設定は、ユーザ同士がトークンを送金する際に、一定割合の手数料を請求するものです。送金手数料は、トークンを発行したり、発行アドレスで直接トークンを交換したりする場合には適用されません。(ユーザが発行アドレスに送金ときには適用されます。)同じアドレスから複数のトークンを発行する場合、すべてのトークンに対して同じ送金手数料が適用されます。
|
||||
|
||||
ユーザが送金手数料が設定されたトークンを送信すると、送信側から送金先金額に加えて送金手数料の金額が引き落とされますが、受信側には送金先金額のみが入金されます。手数料の金額はXRP Ledgerから「消える」のです。ステーブルコインの発行者としては、XRP Ledgerの外にある準備金にそれだけ自己資本が増える、言い換えれば、ユーザが送金手数料を支払うたびに担保として持っておく必要がある金額が減少することを意味します。
|
||||
|
||||
プロトコルレベルでは、送金手数料はアカウント設定の`TransferRate`で定義され、これは10億から20億までの整数で指定されます。
|
||||
|
||||
より詳細な情報は[Transfer Fees](transfer-fees.html)をご覧ください。
|
||||
|
||||
|
||||
### 運用アドレスと待機アドレスによる送金手数料
|
||||
|
||||
運用アドレスや待機アドレスを含むすべてのXRP Ledgerアドレスは、トークンを送信する際に発行者の送金手数料がかかります。送金手数料をゼロ以外に設定した場合、運用アドレスや待機アドレスから支払いを行う際に、(送金手数料を支払うために)余分に送金しなければなりません。つまり、あなたのアドレスは、支払いを行うたびに、あなたの発行アドレスが作った残高を少し返金する必要があります。
|
||||
|
||||
[トランザクションパラメータ`SendMax`][Payment]を送信先の`Amount`パラメータよりも`TransferRate`設定に基づく割合で高く設定します。
|
||||
|
||||
**注記:** 発行アドレスから、または発行アドレスへ直接トークンを送信する場合、送金手数料は適用されません。発行アドレスは、常にそのトークンをXRP Ledgerの額面価格で受け入れなければなりません。つまり、顧客が発行アドレスに直接支払いを送る場合は送金手数料を支払う必要はありませんが、運用アドレスに送る場合は支払う必要があります。両方のアドレスで支払いを受け付ける場合、顧客が運用アドレスに支払いを送る際に、顧客が支払う送金手数料を補うために、記録システムで顧客に入金する金額を調整する必要がある場合があります。
|
||||
|
||||
例えば、次のようなものです。ACMEが送金手数料を1％に設定した場合、顧客のアドレスからACMEの発行アドレスに5 EUR.ACMEを届けるためのXRP Ledger支払いは、ちょうど5 EUR.ACMEの費用がかかります。しかし、顧客は5 EUR.ACMEをACMEの運用アドレスに届けるために、5.05 EUR.ACMEを送る必要があります。ACMEの運用アドレスへの支払いを顧客に入金する際、ACMEは運用アドレスに届けられた金額と送金手数料を顧客に入金し、顧客はACMEのシステムで5.05ユーロを受け取ることができます。
|
||||
|
||||
|
||||
## 支払いに関するモニタリングの徹底
|
||||
|
||||
入金チェックを確実に行うために、発行者は以下のことを行う必要があります。
|
||||
|
||||
* 直近に処理したトランザクションとレジャーを記録しておく。そうすれば、一時的に接続ができなくなったとしても、どこまで遡ればいいのか分かります。
|
||||
* 受信したすべての支払いの結果コードを確認する。一部の支払いは、失敗したにもかかわらず、スパム対策料金を請求するためにレジャーに登録されます。結果コード`tesSUCCESS`を持つトランザクションだけが、XRP以外の残高を変更できます。また、検証されたレジャーからのトランザクションのみが確定的なものとなります。
|
||||
* [部分支払い](partial-payments.html)に注意してください。partial paymentフラグを有効にした場合、0以上の金額であれば、少額でも「成功」と判断されることがあります。
|
||||
* トランザクションに[`delivered_amount`フィールド](partial-payments.html#the-delivered_amount-field)があるかどうか確認してください。もし存在すれば、そのフィールドは`Destination`アドレスに実際にどれだけの金額が支払われたかを示しています。
|
||||
* xrpl.jsでは、[`xrpl.getBalanceChanges()`メソッド](https://js.xrpl.org/modules.html#getBalanceChanges)を使って、各アドレスがいくら受け取ったかを見ることができます。場合によっては、これを異なるトラストラインで複数回に分けて表示することも可能です。
|
||||
* トランザクションの中には、アドレスの1つへの直接の支払いやアドレスからの支払いでなくても、残高を変更するものがあります。たとえば、ACMEがゼロ以外の送金手数料を設定した場合、BobとCharlieがACMEのトークンを交換するたびに、ACMEの発行アドレスの未払い負債が減少します。
|
||||
|
||||
顧客の利便性を高めるため、運用アドレスと発行アドレスの両方への支払いを受け付けることをお勧めします。
|
||||
|
||||
追加の防止策として、新しいXRP Ledgerの各レジャーバージョンにおいて、発行アドレスの残高と内部会計システムにおける担保資金を比較することをお勧めします。発行アドレスのマイナス残高は、ネットワーク外のXRP Ledgerに割り当てた資産と一致するはずです。もし両者が一致しないのであれば、その不一致を解決するまでXRP Ledgerへの出入りの支払い処理を中断する必要があります。
|
||||
|
||||
* 残高を確認するには、`gateway_balances`メソッドを使用します。
|
||||
* Transfer Feeが設定されている場合、他のXRP Ledgerアドレスがあなたのトークンを転送するたびに、XRP Ledger内でのあなたの負債はわずかに減少します。
|
||||
|
||||
受信したトランザクションの詳細を確認する方法については、[トランザクションの結果を確認する](look-up-transaction-results.html)をご覧ください。
|
||||
|
||||
|
||||
|
||||
## 顧客への支払いを送信
|
||||
|
||||
顧客のためにXRP Ledgerに支払いを送る自動システムを構築する場合、そのシステムが支払いを厳密に構築していることを確認する必要があります。悪意ある人物は常に、システムを騙して必要以上に支払いをさせる方法を見つけようとしています。
|
||||
|
||||
一般的に、ステーブルコインを送る場合は[Payment トランザクション][]を使用します。初めてトークンを発行するのか、ホットウォレットから顧客へ送金するのかによって、細かい点が異なる部分もあります。注意すべき点は以下の通りです。
|
||||
|
||||
- 発行アドレスから新しいトークンを発行する場合、`SendMax`フィールドを省略する必要があります。そうしないと、悪意のあるユーザは、意図した宛先の`Amount`だけでなく、`SendMax`の全量を発行するように設定を変更することができます。
|
||||
- ホットウォレットからトークンを送信する場合、転送手数料がゼロでない場合は`SendMax`を指定する必要があります。この場合、`SendMax`フィールドに`Amount`フィールドで指定した金額と送金手数料を設定します。(計算の精度がXRP Ledgerと正確に一致しない場合に備えて、少し切り上げるとよいでしょう)。例えば、`Amount`フィールドに99.47 USDが指定され、送金手数料が0.25%のトランザクションを送信する場合、`SendMax`フィールドを124.3375、または切り上げる場合は124.34 USDに設定すべきです。
|
||||
- `Paths`フィールドを省略します。このフィールドは、発行元から直接送信する場合や、送信するトークンと受信するトークンの通貨コードと発行元が同じである限り、つまり同じステーブルコインである限り、ホットウォレットから設定する必要はありません。`Paths`フィールドは[クロスカレンシー支払い](cross-currency-payments.html)やより長いマルチホップ(rippling)支払いを対象としています。単純に経路探索を行い、トランザクションにパスを設定すると、直接の経路が利用できない場合、支払いは失敗するのではなく、より高価な遠回りのパスを取るかもしれません。悪意のあるユーザはこれを利用して利益を上げる可能性があります。
|
||||
- `tecPATH_DRY`の結果コードが表示された場合、通常、必要なトラストラインを顧客がまだ設定していないか、発行者のripplingの設定が正しく設定されていないことを意味します。
|
||||
|
||||
ステーブルコインであろうとなかろうと、XRP Ledger上でトークンを発行するための詳しいチュートリアルは、[代替可能トークンの発行](issue-a-fungible-token.html)をご覧ください。
|
||||
|
||||
|
||||
## 不明な入金の返金
|
||||
|
||||
アドレスが不明な支払いを受け取った場合、送金者に返金することが推奨されます。これは、資金を保管するよりも手間がかかりますが、顧客に対する誠意を示すことになります。オペレーターが手動で支払いを返金することもできますし、自動的に返金するシステムを構築することもできます。
|
||||
|
||||
返金の失敗を防ぐための第一の条件は、入金を適切に監視することです。顧客から送られてきた金額以上の金額を誤って返金してしまうことは避けなければなりません！(悪意のあるユーザは、[部分支払い](partial-payments.html#partial-payments-exploit)を送信して、脆弱なシステムを利用します。)
|
||||
|
||||
第二に、返金を部分支払い(Partial Payment)として送信することです。第三者はアドレス間のパスのコストを操作することができるので、部分支払いを使えば、XRP Ledger内の取引レートを気にすることなく、支払い金額の全額を手放すことができます。利用規約の一部に、支払い失敗時のポリシーを公表する必要があります。失敗された支払いを、運用中のアドレスまたは待機中のアドレスのいずれかから送信します。
|
||||
|
||||
部分支払いを送信するには、トランザクションの[`tfPartialPayment`フラグ](payment.html#payment-flags)を有効にします。`Amount`フィールドに受け取った金額を設定し、`SendMax`フィールドは省略します。受信した支払いの`SourceTag`値を、返金する支払いの`DestinationTag`値として使用する必要があります。
|
||||
|
||||
2つのシステムで返金が繰り返されるのを防ぐため、送信する返金に新しい送信タグを設定することができます。もしシステムが予期しない支払いを受け取った場合で、その支払いの宛先タグが送信した返金の送信元タグと一致する場合は、その支払いを再び返金させないようにします。
|
||||
|
||||
|
||||
## 信頼性の高いトランザクションの送信
|
||||
|
||||
トランザクションを確実に送信するためには、次の2つを有限の時間で実現することが必要です。
|
||||
|
||||
* 冪等性 - トランザクションは一度のみ処理されるか、全く処理されないべきである。
|
||||
* 検証可能性 - アプリケーションはトランザクションの最終結果を確認することができる。
|
||||
|
||||
トランザクションを確実に送信するために、以下のガイドラインに従ってください。
|
||||
|
||||
* トランザクションの詳細を保存してから送信する。
|
||||
* `LastLedgerSequence`パラメータを使用します。(多くの[クライアントライブラリ](client-libraries.html)では、デフォルトでこのパラメータが使用されます)。
|
||||
* レジャーインデックスがトランザクションの`LastLedgerSequence`パラメータ以下である検証済みレジャーにトランザクションが含まれていない場合、トランザクションを再送信します。
|
||||
|
||||
より詳細な情報は[信頼性の高いトランザクションの送信](reliable-transaction-submission.html)をご覧ください。
|
||||
|
||||
|
||||
## xrp-ledger.toml ファイル
|
||||
|
||||
不正や混乱から守るために、どの通貨を発行し、どのXRP Ledgerのアドレスを管理しているかという情報を、[`xrp-ledger.toml`ファイル](xrp-ledger-toml.html)を使って公表することができます。この機械判読可能なフォーマットは、クライアントアプリケーションが処理するのに便利です。XRP Ledgerのバリデータを実行する場合、同じファイルでキーを公開することもできます。
|
||||
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- **コンセプト:**
|
||||
- [トークン](tokens.html)
|
||||
- [分散型取引所](decentralized-exchange.html)
|
||||
- [送信タグと宛先タグ](source-and-destination-tags.html)
|
||||
- **チュートリアル:**
|
||||
- [`rippled`のインストール](install-rippled.html)
|
||||
- [安全な署名の設定](secure-signing.html)
|
||||
- [非代替性トークンの発行](issue-a-fungible-token.html)
|
||||
- [No Freezeの有効化](enable-no-freeze.html)
|
||||
- [トラストラインの凍結](freeze-a-trust-line.html)
|
||||
- [Enact Global Freeze](enact-global-freeze.html)
|
||||
- **リファレンス:**
|
||||
- [Payment トランザクション][]
|
||||
- [AccountSet トランザクション][]
|
||||
- [TrustSet トランザクション][]
|
||||
- [RippleState オブジェクト](ripplestate.html)
|
||||
- [account_lines メソッド][]
|
||||
- [gateway_balances メソッド][]
|
||||
[自動マーケットメーカー](automated-market-makers.html)をご覧ください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -15,7 +15,7 @@ Generally, when sending stablecoins, you use a [Payment transaction][]. Some of
|
||||
- Before sending a payment into the XRP Ledger, double check the cost of the payment. A payment from your operational address to a customer should not cost more than the destination amount plus any transfer fee you have set.
|
||||
- When issuing new tokens from your issuing address, you should omit the `SendMax` field. Otherwise, malicious users can arrange their settings so that you issue the full `SendMax` amount instead of just the intended destination `Amount`.
|
||||
- When sending tokens _from a hot wallet_, you must specify `SendMax` if you have a nonzero transfer fee. In this case, set the `SendMax` field to the amount specified in the `Amount` field plus the transfer fee. (You may want to round up slightly, in case the precision of your calculations doesn't exactly match the XRP Ledger's.) For example, if you send a transaction whose `Amount` field specifies 99.47 USD, and your transfer fee is 0.25%, you should set the `SendMax` field to 124.3375, or 124.34 USD if you round up.
|
||||
- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for [Cross-Currency Payments](cross-currency-payments.html) and longer multi-hop (rippling) payments. If you naively perform pathfinding and attach the paths to your transaction, your payment may take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to
|
||||
- Omit the `Paths` field. This field is unnecessary when sending directly from the issuer, or from a hot wallet as long as the tokens being sent and the tokens being received have the same currency code and issuer—that is, they're the same stablecoin. The `Paths` field is intended for [Cross-Currency Payments](cross-currency-payments.html) and longer multi-hop (rippling) payments. If you naively perform pathfinding and attach the paths to your transaction, your payment may take a more expensive indirect route rather than failing if the direct path is not available; malicious users can even set this up to.
|
||||
- If you get a `tecPATH_DRY` result code, this usually indicates that either the customer doesn't have the necessary trust line set up already, or your issuer's rippling settings aren't configured correctly.
|
||||
|
||||
For a detailed tutorial on issuing a token on the XRP Ledger, whether a stablecoin or otherwise, see [Issue a Fungible Token](issue-a-fungible-token.html).
|
||||
|
||||
@@ -54,7 +54,9 @@ See [Rippling](rippling.html).
|
||||
|
||||
## Enable Destination Tags
|
||||
|
||||
If your stablecoin application handles transactions on behalf of several customers, it might not be immediately obvious to which account you should credit. Destination tags help to avoid this situation by requiring the sender to specify the beneficiary or destination for a payment. To enable the `RequireDest` flag, set the `asfRequireDest` value (1) in the `SetFlag` field of an `AccountSet` transaction. See [Source and Destination Tags](source-and-destination-tags.html).
|
||||
If your stablecoin application handles transactions on behalf of several customers, it might not be immediately obvious to which account you should credit. Destination tags help to avoid this situation by requiring the sender to specify the beneficiary or destination for a payment. To enable the `RequireDest` flag, set the `asfRequireDest` value (1) in the `SetFlag` field of an `AccountSet` transaction.
|
||||
|
||||
See [Source and Destination Tags](source-and-destination-tags.html).
|
||||
|
||||
## Asset Control Features
|
||||
|
||||
|
||||
@@ -153,7 +153,7 @@ If you see signs of suspicious activity, you can enact a global freeze on your a
|
||||
|
||||
|
||||
|
||||
See [Enact Global Freeze](enact-global-freeze.html)
|
||||
See [Enact Global Freeze](enact-global-freeze.html).
|
||||
|
||||
|
||||
### Clawback
|
||||
@@ -195,7 +195,7 @@ To submit transactions reliably, follow these guidelines:
|
||||
|
||||
* Persist details of the transaction before submitting it.
|
||||
* Use the `LastLedgerSequence` parameter. (Many [client libraries](client-libraries.html) do this by default.)
|
||||
* Resubmit a transaction if it has not appeared in a validated ledger whose [ledger index][] is less than or equal to the transaction's `LastLedgerSequence` parameter.
|
||||
* Resubmit a transaction if it has not appeared in a validated ledger whose [ledger index][] is bigger than or equal to the transaction's `LastLedgerSequence` parameter.
|
||||
|
||||
For more information, see [Reliable Transaction Submission](reliable-transaction-submission.html).
|
||||
|
||||
|
||||
@@ -1025,22 +1025,28 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate
|
||||
- md: concepts/payment-types/robustly-monitoring-for-payments.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/payment-types/robustly-monitoring-for-payments.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate
|
||||
- md: concepts/payment-types/sending-payments-to-customers.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/payment-types/sending-payments-to-customers.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate
|
||||
- md: concepts/payment-types/bouncing-payments.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/payment-types/bouncing-payments.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# Tokens ------------------------------------------------------------------
|
||||
@@ -1057,7 +1063,6 @@ pages:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/fungible-tokens/index.md"
|
||||
outdated_translation: true
|
||||
targets:
|
||||
- ja
|
||||
|
||||
@@ -1069,30 +1074,44 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO - Translate all files under /stablecoins/ directory
|
||||
- md: concepts/tokens/fungible-tokens/stablecoins/index.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/fungible-tokens/stablecoins/index.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/fungible-tokens/stablecoins/settings.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/fungible-tokens/stablecoins/settings.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/fungible-tokens/stablecoins/configuration.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/fungible-tokens/stablecoins/configuration.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/fungible-tokens/stablecoins/precautions.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/fungible-tokens/stablecoins/precautions.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/fungible-tokens/stablecoins/compliance-guidelines.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/fungible-tokens/clawing-back-tokens.md
|
||||
@@ -1182,7 +1201,6 @@ pages:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/nfts/authorizing-another-minter.md"
|
||||
outdated_translation: true
|
||||
targets:
|
||||
- ja
|
||||
|
||||
@@ -1191,7 +1209,6 @@ pages:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/nfts/running-an-nft-auction.md"
|
||||
outdated_translation: true
|
||||
targets:
|
||||
- ja
|
||||
|
||||
@@ -1211,10 +1228,12 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate
|
||||
- md: concepts/tokens/nfts/nft-apis.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/nfts/nft-apis.md"
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: concepts/tokens/transfer-fees.md
|
||||
@@ -1270,7 +1289,6 @@ pages:
|
||||
- en
|
||||
|
||||
- md: "@i18n/ja/concepts/tokens/decentralized-exchange/automated-market-makers.md"
|
||||
outdated_translation: true
|
||||
targets:
|
||||
- ja
|
||||
|
||||
|
||||
Reference in New Issue
Block a user