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

Reword content articles to use "tokens"

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

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

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

2
content/_snippets/issuing-and-operational-addresses-intro.md
View File

@@ -1,4 +1,4 @@
In the XRP Ledger, financial institutions typically use multiple XRP Ledger addresses to minimize the risk associated with a compromised secret key. Ripple strongly recommends the following separation of roles: In the XRP Ledger, financial institutions typically use multiple XRP Ledger addresses to minimize the risk associated with a compromised secret key. The industry standard is to separate roles as follows:
* One **issuing address**, also known as a "cold wallet." This address is the hub of the financial institution's accounting relationships in the ledger, but sends as few transactions as possible. <!-- STYLE_OVERRIDE: cold wallet, wallet --> * One **issuing address**, also known as a "cold wallet." This address is the hub of the financial institution's accounting relationships in the ledger, but sends as few transactions as possible. <!-- STYLE_OVERRIDE: cold wallet, wallet -->
* One or more **operational addresses**, also known as "hot wallets." Automated, internet-connected systems use the secret keys to these addresses to conduct day-to-day business like transfers to customers and partners. <!-- STYLE_OVERRIDE: hot wallet, wallet --> * One or more **operational addresses**, also known as "hot wallets." Automated, internet-connected systems use the secret keys to these addresses to conduct day-to-day business like transfers to customers and partners. <!-- STYLE_OVERRIDE: hot wallet, wallet -->

110
content/concepts/issued-currencies/freezes.md
View File

@@ -1,110 +0,0 @@
---
html: freezes.html
parent: issued-currencies.html
blurb: Freezes can suspend trading of issued currencies for compliance purposes.
labels:
- Tokens
---
# Freezing Issued Currencies
Issuers can freeze the tokens they issue in the XRP Ledger.
XRP is not an issued currency. XRP is the only native asset on the XRP Ledger and is required to conduct transactions on the XRP Ledger. XRP has no counterparty, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**<u>XRP CANNOT be frozen by any entity or individual</u>**_.
All non-XRP currencies can be represented in the XRP Ledger as issued currencies. These issued currencies (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. <!-- STYLE_OVERRIDE: IOUs -->
In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway may want to quickly freeze non-XRP issued currency balances.
**Tip:** No one can freeze XRP in the XRP Ledger. However, custodial exchanges can always freeze the funds they custody at their own discretion.
There are three settings related to freezes:
* [**Individual Freeze**](#individual-freeze) - Freeze one counterparty.
* [**Global Freeze**](#global-freeze) - Freeze all counterparties.
* [**No Freeze**](#no-freeze) - Permanently give up the ability to freeze individual counterparties, as well as the ability to end a global freeze.
The freeze feature only applies to issued currencies. Because no party has a privileged place in the XRP Ledger, the freeze feature cannot prevent a counterparty from conducting transactions in XRP or funds issued by other counterparties. No one can freeze XRP.
All freeze settings can be enacted regardless of whether the balance(s) to be frozen are positive or negative. Either the currency issuer or the currency holder can freeze a trust line; however, the effect of a currency holder freezing an issuer is minimal.
## Individual Freeze
The **Individual Freeze** feature is a setting on a [trust line](trust-lines-and-issuing.html). When an issuing address enables the Individual Freeze setting, the following rules apply to the currency of that trust line:
* Payments can still occur directly between the two parties of the frozen trust line.
* The counterparty of that trust line can no longer decrease its balance on the frozen trust line, except in direct payments to the issuer. The counterparty can only send the frozen currencies directly to the issuer.
* The counterparty can still receive payments from others on the frozen trust line.
* The counterparty's offers to sell the currency issued on the frozen trust line are [considered unfunded](offers.html#lifecycle-of-an-offer).
Reminder: Trust lines do not hold XRP. XRP cannot be frozen.
A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution uses that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.)
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's issued currencies to the individual address. This type of individual freeze has no effect on offers.
The Individual Freeze applies to a single currency only. To freeze multiple currencies with a particular counterparty, the address must enable Individual Freeze on the trust lines for each currency individually.
An address cannot enable the Individual Freeze setting if it has enabled the [No Freeze](#no-freeze) setting.
## Global Freeze
The **Global Freeze** feature is a setting on an address. When an issuing address enables the Global Freeze feature, the following rules apply to all currencies they issue:
* All counterparties of the frozen issuing address can no longer decrease the balances in their trust lines to the frozen address, except in direct payments to the issuer. (This also affects any [operational addresses](issuing-and-operational-addresses.html).)
* Counterparties of the frozen issuing address can still send and receive payments directly to and from the issuing address.
* All offers to sell currencies issued by the frozen address are [considered unfunded](offers.html#lifecycle-of-an-offer).
Reminder: addresses cannot issue XRP. Global freezes do not apply to XRP.
It can be useful to enable Global Freeze on a financial institution's [issuing address](issuing-and-operational-addresses.html) if the secret key to an operational address is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, a financial institution should also suspend activities in its connectors to outside systems.
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
Global Freeze applies to _all_ currencies issued and held by the address. You cannot enable Global Freeze for only one currency. If you want to have the ability to freeze some currencies and not others, you should use different addresses for each currency.
An address can always enable the Global Freeze setting. However, if the address has enabled the [No Freeze](#no-freeze) setting, it can never _disable_ Global Freeze.
## No Freeze
The **No Freeze** feature is a setting on an address that permanently gives up the ability to freeze issued currencies arbitrarily. An issuer can use this feature to treat its issued funds as "more like physical money" in the sense that the issuer cannot interfere with counterparties trading the currency among themselves.
Reminder: XRP already cannot be frozen. The No Freeze feature only applies to other currencies issued in the XRP Ledger.
The No Freeze setting has two effects:
* The issuing address can no longer enable Individual Freeze on trust lines to any counterparty.
* The issuing address can still enable Global Freeze to enact a global freeze, but the address cannot _disable_ Global Freeze.
The XRP Ledger cannot force an issuer to honor the obligations that its issued funds represent, so No Freeze does stop an issuer from defaulting on its obligations. However, No Freeze ensures that an issuer does not use the Global Freeze feature unfairly against specific users.
The No Freeze setting applies to all currencies issued to and from an address. If you want to be able to freeze some currencies but not others, you should use different addresses for each currency.
You can only enable the No Freeze setting with a transaction signed by your address's master key secret. You cannot use a [Regular Key](setregularkey.html) or a [multi-signed transaction](multi-signing.html) to enable No Freeze.
# See Also
- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
- [Freeze Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
- **Concepts:**
- [Trust Lines and Issuing](trust-lines-and-issuing.html)
- **Tutorials:**
- [Enable No Freeze](enable-no-freeze.html)
- [Enact Global Freeze](enact-global-freeze.html)
- [Freeze a Trust Line](freeze-a-trust-line.html)
- **References:**
- [account_lines method][]
- [account_info method][]
- [AccountSet transaction][]
- [TrustSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

73
content/concepts/issued-currencies/issued-currencies-overview.md
View File

@@ -1,73 +0,0 @@
---
html: issued-currencies-overview.html
parent: issued-currencies.html
blurb: Get an overview of issued currencies and their properties in the XRP Ledger.
labels:
- Tokens
---
# Issued Currencies Overview
All currencies other than XRP can be represented in the XRP Ledger as **issued currencies**. These digital assets (sometimes called "IOUs") are tracked in accounting relationships, called "trust lines," between addresses. Issued currencies are typically considered as liabilities from one perspective and assets from the other, so the balance of a trust line is negative or positive depending on which side you view it from. Any address may freely issue (non-XRP) currencies, limited only by how much other addresses are willing to hold. <!-- STYLE_OVERRIDE: ious -->
Issued currencies can "ripple" through multiple issuers and holders if they use the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling.
Issued currencies can be traded with XRP or each other in the XRP Ledger's decentralized exchange.
In the typical model, an issued currency is tied to holdings of currency or other assets outside the XRP Ledger. The issuer of the currency, called a _gateway_, handles deposits and withdrawals to exchange currency outside the XRP Ledger for equivalent balances of issued currency in the XRP Ledger. For more information on how to run a gateway, see the [Becoming an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html).
There are other use cases for issued currencies in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer.
**Warning:** ICOs may be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->
Be sure to research the relevant regulations before engaging in any financial service business.
## Issued Currency Usage
A trust line represents an explicit statement of willingness to hold gateway debt obligations. (In other words: "I'll allow you to owe me up to this much money outside the XRP Ledger.")
The intended model for issued currency usage is with _gateways_, trusted financial institutions that custody outside-world assets and allow them to be used in the XRP Ledger for [cross-currency payments](cross-currency-payments.html) and trading in the [decentralized exchange](decentralized-exchange.html). The flow looks something like this:
1. A customer sends money to a gateway. This could be fiat money, Bitcoin, or any other assets that aren't native to the XRP Ledger.
2. The gateway takes custody of the money and records it.
3. The gateway issues a balance in the XRP Ledger, denominated in the same currency, to an address belonging to the customer.
4. The customer uses the issued currency in the XRP Ledger however they want, such as by sending [cross-currency payments](cross-currency-payments.html) or by trading in the [decentralized exchange](decentralized-exchange.html).
5. A customer (not necessarily the one who deposited the money initially) sends the issued currency to the gateway's XRP Ledger address.
6. The gateway confirms the identity of the customer who sent the balance in the XRP Ledger funds, and gives the corresponding amount of money _outside the XRP Ledger_ to that customer.
The details of the process of sending money "into" and "out of" the XRP Ledger can vary based on the gateway, the jurisdiction, the type of assets involved, and other factors.
## Issued Currency Properties
All issued currencies in the XRP Ledger exist in trust lines, represented in the ledger's data as [RippleState objects](ripplestate.html). To create an issued currency, the issuing address sends a [Payment transaction][] to an address which has a trust line to the issuer with a nonzero limit for that currency. (You can also create issued currency by rippling "through" such a trust line.) You can erase issued currency by sending it back to the issuer.
The issuer of a currency can define a percentage [transfer fee](transfer-fees.html) to deduct when two parties transact in its issued currencies.
Addresses can also [freeze](freezes.html) issued currencies, which may be useful for businesses to comply with financial regulations in their jurisdiction. If you do not need this feature and do not want to freeze currencies, you can give up your address's ability to freeze individual trust lines and to undo a global freeze. XRP cannot be frozen.
Issued currencies are designed to be able to represent any kind of currency or asset, including those with very small or very large nominal values. For detailed technical information on the types of currency codes and the numeric limits of issued currency representation, see the [currency format reference](currency-formats.html).
## See Also
- **Concepts:**
- [XRP](xrp.html)
- [Cross-Currency Payments](cross-currency-payments.html)
- [Decentralized Exchange](decentralized-exchange.html)
- **Tutorials:**
- [Issue a Fungible Token](issue-a-fungible-token.html)
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Use Specialized Payment Types](use-specialized-payment-types.html)
- **References:**
- [Payment transaction][]
- [TrustSet transaction][]
- [RippleState object](ripplestate.html)
- [account_lines method][]
- [account_currencies method][]
- [gateway_balances method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

81
content/concepts/issued-currencies/issuing-and-operational-addresses.md
View File

@@ -1,81 +0,0 @@
---
html: issuing-and-operational-addresses.html
parent: issued-currencies.html
blurb: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
labels:
- Tokens
- Security
---
# Issuing and Operational Addresses
{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
<!--{#_ #}-->
## Funds Lifecycle
All non-XRP balances in the XRP Ledger are _issued currencies_ which are tied to accounting relationships between two XRP Ledger addresses. When a financial institution uses Ripple's recommended separation of roles, funds relating to that institution tend to flow in a cycle.
{{ include_svg("img/issued-currency-funds-flow.svg", "Diagram: Funds flow from the issuing address to standby addresses, to operational addresses, to customer and partner addresses, and finally back to the issuing address.")}}
When the issuing address sends payments, it creates balances in the accounting relationships in the XRP Ledger. Within the XRP Ledger, users can exchange balances across different accounting relationships, so we use the term _issued currency_ to describe any non-XRP balance. (These can represent any type of value, not only "currencies" in the traditional sense.) Issued currencies have negative value from the perspective of the issuing address, since they represent obligations. The same issued currencies have positive value from the perspective of the issuing address's counterparties. When the issuing address receives a payment, this reduces its obligations, erasing the issued currencies that were sent.
The issuing address sends issued currencies to a standby address, or directly to an operational address. The standby addresses send those issued currencies to operational addresses. Operational addresses send payments to other counterparties, such as liquidity providers, partners, and other customers. Because all issued currencies are tied to accounting relationships with the issuing address, payments and exchanges of issued currencies "ripple through" the issuing address. The payment debits the sender's balance in its accounting relationship with the issuing address and credits the recipient's balance in the recipient's accounting relationship with the issuing address. The XRP Ledger also supports more complicated [paths](paths.html) that connect multiple issuers through order books and [liquidity providers who allow their funds to ripple](rippling.html).
## Issuing Address
The issuing address is like a vault. Partners, customers, and operational addresses create accounting relationships (trust lines) to the issuing address, but this address sends as few transactions as possible. Periodically, a human operator creates and signs a transaction from the issuing address to refill the balances of a standby or operational address. Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.
Unlike a vault, the issuing address can receive payments directly from customers and partners. Since all transactions in the XRP Ledger are public, automated systems can monitor for payments to the issuing address without needing a secret key.
### Issuing Address Compromise
If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new issued currencies without limit and trade them in the decentralized exchange. This would make it difficult for the financial institution to distinguish legitimately-obtained issued currencies and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have accounting relationships with the old issuing address must create new accounting relationships with the new address.
### Multiple Issuing Addresses
A financial institution can issue more than one currency in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all currencies issued from an address, including the percentage for [transfer fees](transfer-fees.html) and the [global freeze](freezes.html) status. If the financial institution wants the flexibility to manage settings differently for each currency, the institution must use a different issuing address for each currency.
## Operational Addresses
An operational address is like a cash register. It makes payments on behalf of the institution by transferring issued currencies to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create accounting relationships with an operational address.
Each operational address has a limited balance of issued currencies. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address.
### Operational Address Compromise
If a malicious actor learns the secret key behind an operational address, the financial institution can only lose as much currency as that operational address holds. The institution can switch to a new operational address with no action from customers and partners.
## Standby Addresses
Another optional step that an institution can take to balance risk and convenience is to use "standby addresses" as an intermediate step between the issuing address and operational addresses. The institution can fund additional XRP Ledger addresses as standby addresses, whose keys are not stored online, but are entrusted to different trusted users.
When an operational address is running low on funds, a trusted user can use a standby address to refill the operational address's balance. When a standby addresses run low on funds, the institution can use the issuing address to send more currency to a standby address in a single transaction, and the standby addresses can distribute that currency among themselves if necessary. This improves security of the issuing address, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.
As with operational addresses, a standby address must have an accounting relationship with the issuing address, and not with customers or partners. All precautions that apply to operational addresses also apply to standby addresses.
### Standby Address Compromise
If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
## See Also
- **Concepts:**
- [Accounts](accounts.html)
- [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- **References:**
- [account_info method][]
- [SetRegularKey transaction][]
- [AccountRoot object](accountroot.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/concepts/issued-currencies/authorized-trust-lines.ja.md → content/concepts/tokens/authorized-trust-lines.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: authorized-trust-lines.html html: authorized-trust-lines.html
parent: issued-currencies.html parent: tokens.html
blurb: 通貨発行者が自己の発行済み通貨を保有できる人を制限できる、Authorized Trust Lineについて説明します。 blurb: 通貨発行者が自己の発行済み通貨を保有できる人を制限できる、Authorized Trust Lineについて説明します。
labels: labels:
- トークン - トークン

35
content/concepts/issued-currencies/authorized-trust-lines.md → content/concepts/tokens/authorized-trust-lines.md
View File

@@ -1,36 +1,41 @@
--- ---
html: authorized-trust-lines.html html: authorized-trust-lines.html
parent: issued-currencies.html parent: tokens.html
blurb: Learn about authorized trust lines, which enable a currency issuer to limit who can hold its issued (non-XRP) currencies. blurb: Authorized trust lines is a setting to limit who can hold a token.
labels: labels:
- Tokens - Tokens
- Security - Security
--- ---
# Authorized Trust Lines # Authorized Trust Lines
The XRP Ledger's Authorized Trust Lines feature enables a currency issuer to limit who can hold its issued (non-XRP) currencies, so that unknown XRP Ledger addresses cannot hold those currencies. The Authorized Trust Lines feature only applies to issued currencies and has no effect on XRP. The Authorized Trust Lines feature enables issuers to create tokens that can only be held by accounts that the issuer specifically authorizes. This feature only applies to tokens, not XRP.
To use the Authorized Trust Lines feature, enable the `RequireAuth` flag on your issuing address. After doing so, your issuing address can send [TrustSet transactions][] to authorize trust lines from other addresses. While RequireAuth is enabled, other addresses can only hold funds issued by your address if the trust line to your issuing address has been authorized. To use the Authorized Trust Lines feature, enable the `RequireAuth` flag on your issuing account. While the setting is enabled, other accounts can only hold tokens you issue if you have authorized those accounts' trust lines to your issuing account.
The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address. The process for sending funds into the XRP Ledger with `RequireAuth` enabled looks like the following: You can authorize a trust line by sending a [TrustSet transaction][] from your issuing address, configuring the trust line between your account and the account to authorize. After you have authorized a trust line, you can never revoke that authorization. (You can, however, [freeze](freezes.html) that trust line if you need to.)
1. An issuing gateway publishes its issuing address to customers. The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address.
2. A customer sends a [TrustSet transaction][] to create a trust line from her XRP Ledger address to the gateway's issuing address. This indicates that she is willing to hold a specific currency issued by the gateway, up to a specific numeric limit.
3. The gateway's issuing address sends a TrustSet transaction authorizing the customer's trust line.
**Tip:** An issuing gateway can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_ **Caution:** You can only enable `RequireAuth` if your account has no trust lines and no Offers in the XRP Ledger, so you must decide whether or not to use it _before_ you start issuing tokens.
## RequireAuth Setting ## With Stablecoin Issuing
<!-- SPELLING_IGNORE: requireauth --> With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process of onboarding a new customer might look something like the following:
The `RequireAuth` setting prevents all counterparties from holding balances issued by an address unless the issuing address has specifically approved a trust line with that counterparty for the currency in question. 1. The customer registers with the stablecoin issuer's systems and sends proof of their identity (also known as "Know Your Customer", or KYC, information).
2. The customer and stablecoin issuer tell each other their XRP Ledger addresses.
3. The customer sends a [TrustSet transaction][] to create a trust line to the issuer's address, with a positive limit.
4. The issuer sends a TrustSet transaction to authorize the customer's trust line.
As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](issuing-and-operational-addresses.html), and then never approve any trust lines to those addresses. This prevents operational addresses and standby addresses from issuing currency in the XRP Ledger even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issued currency balances created by the issuing address, as they are intended to do. **Tip:** The issuer can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_
To use the Authorized Trust Lines feature, an issuer must also enable `RequireAuth` on its issuing address. After doing so, the issuing address must [submit a `TrustSet` transaction to approve each trust line](#authorizing-trust-lines) from a customer. ## As a Precaution
**Caution:** An account can only enable `RequireAuth` if it owns no trust lines and no offers in the XRP Ledger, so you must decide whether or not to use it before you start doing business in the XRP Ledger. Even if you don't intend to use Authorized Trust Lines, you can enable the `RequireAuth` setting on [operational and standby accounts](issuing-and-operational-addresses.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is a purely precautionary measure, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
## Technical Details
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
### Enabling RequireAuth ### Enabling RequireAuth

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

@@ -0,0 +1,32 @@
---
parent: freezes.html
blurb: Clarify common misunderstandings about the XRP Ledger's freeze feature.
labels:
- Tokens
---
# Common Misunderstandings about Freezes
It is a common misconception that Ripple or others can freeze XRP, similar to how centralized services like PayPal can suspend your account and prevent you from accessing your funds. In reality, while the XRP Ledger does have a [freeze feature](freezes.html), it can only be used on issued tokens, not on XRP. **No one can freeze XRP.**
Tokens in the XRP Ledger are [fundamentally different than XRP](currency-formats.html#comparison). Tokens always exist _in trust lines_, which _can_ be frozen. XRP exists in accounts, which _cannot_ be frozen.
## Isn't XRP Just Ripple's Token?
No, XRP is different from tokens. XRP is the only native asset on the XRP Ledger and is required to conduct transactions on the XRP Ledger. XRP has no counterparty, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**<u>XRP CANNOT be frozen by any entity or individual</u>**_.
## Can Ripple Freeze My Tokens? Or the XRP Ledger Foundation?
The XRP Ledger is decentralized so that no one party has control over it—not Ripple, not the XRP Ledger Foundation, and not anyone else.
The _issuer_ of a token can freeze your trust line for _that token specifically_. They can't freeze the rest of your account, or any tokens from different issuers, and they can't stop you from using the XRP Ledger.
Furthermore, token issuers can voluntarily and permanently _give up_ their ability to freeze tokens. This ["No Freeze"](freezes.html#no-freeze) setting is intended to allow tokens to behave more like physical cash, in that third parties can't stop you from using it.
## But I Heard Ripple Froze Jed McCaleb's XRP?
This is a misrepresentation of events that actually happened in 2015–2016. Jed McCaleb, a Ripple founder who left the company in 2013, attempted to sell over $1 million US worth of XRP on Bitstamp, a custodial exchange. Ripple representatives argued that this sale would breach an agreement that Jed and Ripple made in 2014. At Ripple's request, [Bitstamp froze Jed's Bitstamp account](https://www.coindesk.com/markets/2015/04/02/1-million-legal-fight-ensnares-ripple-bitstamp-and-jed-mccaleb/) and took the dispute to court. The case was [eventually settled](https://www.coindesk.com/markets/2016/02/12/ripple-settles-1-million-lawsuit-with-former-executive-and-founder/) with both sides declaring they were happy with the outcome.
Notably, the "freeze" did not happen on the XRP Ledger and did not involve the XRP Ledger's freeze feature. Like any custodial exchange, Bitstamp has the ability to freeze its users' accounts and stop them from trading or withdrawing funds, especially if those funds are involved in a legal dispute.
In contrast, when trading in the XRP Ledger's [decentralized exchange](decentralized-exchange.html), you custody your own assets so no one can stop you from dealing in XRP.

2
content/concepts/issued-currencies/demurrage.ja.md → content/concepts/tokens/demurrage.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: demurrage.html html: demurrage.html
parent: issued-currencies.html parent: tokens.html
blurb: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。. blurb: (廃止) 一部の古いXRP Ledgerツールは、組み込み金利やマイナス金利を持つ通貨コードをサポートしていました。.
status: removed status: removed
--- ---

22
content/concepts/issued-currencies/demurrage.md → content/concepts/tokens/demurrage.md
View File

@@ -1,6 +1,6 @@
--- ---
html: demurrage.html html: demurrage.html
parent: issued-currencies.html parent: tokens.html
blurb: (Obsolete) Some older XRP Ledger tools used to support currency codes with built-in interest and negative interest rates. blurb: (Obsolete) Some older XRP Ledger tools used to support currency codes with built-in interest and negative interest rates.
status: removed status: removed
--- ---
@@ -8,11 +8,11 @@ status: removed
**Warning:** Demurrage is a deprecated feature with no ongoing support. This page describes historical behavior of older versions of XRP Ledger software. **Warning:** Demurrage is a deprecated feature with no ongoing support. This page describes historical behavior of older versions of XRP Ledger software.
[Demurrage](http://en.wikipedia.org/wiki/Demurrage_%28currency%29) is a negative interest rate on assets held that represents the cost of holding those assets. To represent the demurrage on an issued currency in the XRP Ledger, you can track it using a custom [currency code](currency-formats.html#currency-codes) that indicates the demurrage rate. This effectively creates separate versions of the currency for each varying amount of demurrage. Client applications can support this by representing the demurraging currency code with an annual percentage rate alongside the currency code. For example: "XAU (-0.5%pa)". [Demurrage](http://en.wikipedia.org/wiki/Demurrage_%28currency%29) is a negative interest rate on assets held that represents the cost of holding those assets. To represent the demurrage on a token in the XRP Ledger, you can track it using a custom [currency code](currency-formats.html#currency-codes) that indicates the demurrage rate. This effectively creates separate versions of the token for each varying amount of demurrage. Client applications can support this by representing the demurraging currency code with an annual percentage rate alongside the currency code. For example: "XAU (-0.5%pa)".
## Representing Demurraging Currency Amounts ## Representing Demurraging Token Amounts
Rather than continuously update all amounts in the XRP Ledger, this approach divides amounts of interest-bearing or demurraging currency into two types of amount: "ledger values" recorded in the XRP Ledger, and "display values" shown to people. The "ledger values" represent the value of the currency at a fixed point, namely the "Ripple Epoch" of midnight January 1, 2000. The "display values" represent the amount at a later point in time (usually the current time) after calculating continuous interest or demurrage from the Ripple Epoch until that time. Rather than continuously update all amounts in the XRP Ledger, this approach divides amounts of interest-bearing or demurraging tokens into two types of amount: "ledger values" recorded in the XRP Ledger, and "display values" shown to people. The "ledger values" represent the value of the currency at a fixed point, namely the "Ripple Epoch" of midnight January 1, 2000. The "display values" represent the amount at a later point in time (usually the current time) after calculating continuous interest or demurrage from the Ripple Epoch until that time.
**Tip:** You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not reflect actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate. **Tip:** You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not reflect actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate.
@@ -23,7 +23,7 @@ Thus, client software must apply two conversions:
### Calculating Demurrage ### Calculating Demurrage
The full formula for calculating demurrage on a currency is as follows: The full formula for calculating demurrage is as follows:
``` ```
D = A × ( e ^ (t ÷ τ) ) D = A × ( e ^ (t ÷ τ) )
@@ -41,12 +41,12 @@ To convert between display amounts and ledger amounts, you can use the following
2. Apply it to the amount to convert: 2. Apply it to the amount to convert:
- To convert ledger values to display values, multiply by the demurrage coefficient. - To convert ledger values to display values, multiply by the demurrage coefficient.
- To convert display values to ledger values, divide by the demurrage coefficient. - To convert display values to ledger values, divide by the demurrage coefficient.
3. If necessary, adjust the resulting value so that it can be represented to the desired accuracy. Ledger values are limited to 15 decimal digits of precision, according to the XRP Ledger's [issued currency format](currency-formats.html#issued-currency-precision). 3. If necessary, adjust the resulting value so that it can be represented to the desired accuracy. Ledger values are limited to 15 decimal digits of precision, according to the XRP Ledger's [token format](currency-formats.html#issued-currency-precision).
## Interest-Bearing Currency Code Format ## Interest-Bearing Currency Code Format
Rather than using the [standard currency code format](currency-formats.html#currency-codes), currencies that have positive interest or negative interest (demurrage) use a 160-bit currency code in the following format: Rather than using the [standard currency code format](currency-formats.html#currency-codes), tokens that have positive interest or negative interest (demurrage) use a 160-bit currency code in the following format:
![Demurraging Currency Code Format](img/demurrage-currency-code-format.png) ![Demurraging Currency Code Format](img/demurrage-currency-code-format.png)
@@ -72,13 +72,13 @@ To calculate an e-folding time for a given rate of annual percent interest:
## Client Support ## Client Support
To support interest-bearing and demurraging currencies, client applications must implement several features: To support interest-bearing and demurraging tokens, client applications must implement several features:
- When displaying the amount of a demurraging currency retrieved from ledger or transaction data, the client must convert from the ledger value to the display value. (With demurrage, the display values are smaller than the ledger values.) - When displaying the amount of a demurraging token retrieved from ledger or transaction data, the client must convert from the ledger value to the display value. (With demurrage, the display values are smaller than the ledger values.)
- When accepting input for a demurraging currency, the client must convert amounts from a display format to the ledger format. (With demurrage, the ledger values are are larger than the user input value.) The client must use the ledger value when creating payments, offers, and other types of transaction. - When accepting input for a demurraging token, the client must convert amounts from a display format to the ledger format. (With demurrage, the ledger values are larger than the user input value.) The client must use the ledger value when creating payments, offers, and other types of transaction.
- Clients must distinguish between currencies that do and do not have interest or demurrage, and among currencies that have different rates of interest or demurrage. Clients should be able to parse the [Interest-Bearing Currency Code Format](#interest-bearing-currency-code-format) into a display such as "XAU (-0.5% pa)". - Clients must distinguish between tokens that do and do not have interest or demurrage, and among tokens that have different rates of interest or demurrage. Clients should be able to parse the [Interest-Bearing Currency Code Format](#interest-bearing-currency-code-format) into a display such as "XAU (-0.5% pa)".
### ripple-lib Support ### ripple-lib Support

2
content/concepts/issued-currencies/freezes.ja.md → content/concepts/tokens/freezes.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: freezes.html html: freezes.html
parent: issued-currencies.html parent: tokens.html
blurb: 凍結では、コンプライアンス目的で発行済み通貨の取引を停止できます。 blurb: 凍結では、コンプライアンス目的で発行済み通貨の取引を停止できます。
labels: labels:
- トークン - トークン

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

@@ -0,0 +1,104 @@
---
html: freezes.html
parent: tokens.html
blurb: Issuers can freeze their issued tokens for compliance purposes.
labels:
- Tokens
---
# Freezing Tokens
Issuers can freeze the tokens they issue in the XRP Ledger. **This does not apply to XRP,** which is the native asset of the XRP Ledger, not an issued token.
In certain cases, to meet regulatory requirements, or while investigating suspicious activity, an exchange or gateway may want to freeze token balances.
**Tip:** No one can freeze XRP in the XRP Ledger. However, custodial exchanges can always freeze the funds they custody at their own discretion. For more details, see [Common Misunderstandings about Freezes](common-misconceptions-about-freezes.html).
There are three settings related to freezes:
* [**Individual Freeze**](#individual-freeze) - Freeze one counterparty.
* [**Global Freeze**](#global-freeze) - Freeze all counterparties.
* [**No Freeze**](#no-freeze) - Permanently give up the ability to freeze individual counterparties, as well as the ability to end a global freeze.
All freeze settings can be enacted regardless of whether the balance(s) to be frozen are positive or negative. Either the token issuer or the currency holder can freeze a trust line; however, the effect is minimal when a currency holder enacts a freeze.
## Individual Freeze
The **Individual Freeze** feature is a setting on a [trust line](trust-lines-and-issuing.html). When an issuer enables the Individual Freeze setting, the following rules apply to the tokens in that trust line:
* Payments can still occur directly between the two parties of the frozen trust line.
* The counterparty of that trust line can no longer decrease its balance on the frozen trust line, except in direct payments to the issuer. The counterparty can only send the frozen currencies directly to the issuer.
* The counterparty can still receive payments from others on the frozen trust line.
* The counterparty's offers to sell the tokens in the frozen trust line are [considered unfunded](offers.html#lifecycle-of-an-offer).
Reminder: Trust lines do not hold XRP. XRP cannot be frozen.
A financial institution can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the financial institution's terms of use. The financial institution should also freeze the counterparty in any other systems the financial institution uses that are connected to the XRP Ledger. (Otherwise, an address might still be able to engage in undesired activity by sending payments through the financial institution.)
An individual address can freeze its trust line to a financial institution. This has no effect on transactions between the institution and other users. It does, however, prevent other addresses, including [operational addresses](issuing-and-operational-addresses.html), from sending that financial institution's issued currencies to the individual address. This type of individual freeze has no effect on offers.
The Individual Freeze applies to a single trust line. To freeze multiple tokens with a particular counterparty, the address must enable Individual Freeze on the trust lines for each separate currency code.
An address cannot enable the Individual Freeze setting if it has enabled the [No Freeze](#no-freeze) setting.
## Global Freeze
The **Global Freeze** feature is a setting on an account. An account can enable a global freeze only on itself. When an issuer enables the Global Freeze feature, the following rules apply to all tokens they issue:
* All counterparties of the frozen issuer can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects the issuer's own [operational addresses](issuing-and-operational-addresses.html).)
* Counterparties of the frozen issuer can still send and receive payments directly to and from the issuing address.
* All offers to sell tokens issued by the frozen address are [considered unfunded](offers.html#lifecycle-of-an-offer).
Reminder: addresses cannot issue XRP. Global freezes do not apply to XRP.
It can be useful to enable Global Freeze on a financial institution's [issuing account](issuing-and-operational-addresses.html) if the issuer's [secret key](cryptographic-keys.html) is compromised, even after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. Besides enacting a Global Freeze in the XRP Ledger, the issuer should also suspend activities in its outside systems.
It can also be useful to enable Global Freeze if a financial institution intends to migrate to a new [issuing address](issuing-and-operational-addresses.html), or if the financial institution intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
Global Freeze applies to _all_ tokens issued and held by the address. You cannot enable Global Freeze for only one currency code. If you want to have the ability to freeze some tokens and not others, you should use different addresses for each token.
An address can always enable the Global Freeze setting. However, if the address has enabled the [No Freeze](#no-freeze) setting, it can never _disable_ Global Freeze.
## No Freeze
The **No Freeze** feature is a setting on an address that permanently gives up the ability to freeze tokens arbitrarily. An issuer can use this feature to make its tokens as "more like physical money" in the sense that the issuer cannot interfere with counterparties trading the tokens among themselves.
Reminder: XRP already cannot be frozen. The No Freeze feature only applies to other tokens issued in the XRP Ledger.
The No Freeze setting has two effects:
* The issuer can no longer enable Individual Freeze on trust lines to any counterparty.
* The issuer can still enact a Global Freeze, but cannot _disable_ the Global Freeze.
The XRP Ledger cannot force an issuer to honor the obligations that its issued funds represent, so No Freeze does stop a stablecoin issuer from defaulting on its obligations. However, No Freeze ensures that an issuer does not use the Global Freeze feature unfairly against specific users.
The No Freeze setting applies to all tokens issued to and from an address. If you want to be able to freeze some tokens but not others, you should use different addresses for each.
You can only enable the No Freeze setting with a transaction signed by your address's master key secret. You cannot use a [Regular Key](setregularkey.html) or a [multi-signed transaction](multi-signing.html) to enable No Freeze.
# See Also
- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
- [Freeze Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
- **Concepts:**
- [Trust Lines and Issuing](trust-lines-and-issuing.html)
- **Tutorials:**
- [Enable No Freeze](enable-no-freeze.html)
- [Enact Global Freeze](enact-global-freeze.html)
- [Freeze a Trust Line](freeze-a-trust-line.html)
- **References:**
- [account_lines method][]
- [account_info method][]
- [AccountSet transaction][]
- [TrustSet transaction][]
- [AccountRoot Flags](accountroot.html#accountroot-flags)
- [RippleState (trust line) Flags](ripplestate.html#ripplestate-flags)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/concepts/issued-currencies/issuing-and-operational-addresses.ja.md → content/concepts/tokens/issuing-and-operational-addresses.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: issuing-and-operational-addresses.html html: issuing-and-operational-addresses.html
parent: issued-currencies.html parent: tokens.html
blurb: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。 blurb: XRP Ledgerで自動的にトランザクションを送信するビジネスは、リスクを最小限に抑えるために目的ごとに別のアドレスを設定することをおすすめします。
labels: labels:
- トークン - トークン

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

@@ -0,0 +1,88 @@
---
html: issuing-and-operational-addresses.html
parent: tokens.html
blurb: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
labels:
- Tokens
- Security
---
# Issuing and Operational Addresses
{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
<!--{#_ #}-->
## Funds Lifecycle
When a token issuer follows this separation of roles, funds tend to flow in specific directions, as in the following diagram:
{{ include_svg("img/issued-currency-funds-flow.svg", "Diagram: Funds flow from the issuing address to standby addresses, to operational addresses, to customer and partner addresses, and finally back to the issuing address.")}}
The issuing address creates tokens by sending payments to standby addresses. These tokens have negative value from the perspective of the issuing address, since they (often) represent obligations. The same tokens have positive value from other perspectives, including from the perspective of a standby address.
The standby addresses, which are operated by actual humans, send those tokens to operational addresses. This step allows the issuing address to be used as little as possible after this point, while having at least some tokens available on standby.
Operational addresses, which are operated by automated systems, send payments to other counterparties, such as liquidity providers, partners, and other customers. Those counterparties may send funds freely among themselves multiple times.
As always, token payments must "ripple through" the issuer across trust lines with sufficient limits.
Eventually, someone sends tokens back to the issuer. This destroys those tokens, reducing the issuer's obligations in the XRP Ledger. If the token is a stablecoin, this is the first step of redeeming the tokens for the corresponding off-ledger assets.
## Issuing Address
The issuing address is like a vault. Partners, customers, and operational addresses create trust lines to the issuing address, but this address sends as few transactions as possible. Periodically, a human operator creates and signs a transaction from the issuing address to refill the balances of a standby or operational address. Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.
Unlike a vault, the issuing address can receive payments directly from customers and partners. Since all transactions in the XRP Ledger are public, automated systems can watch for payments to the issuing address without needing a secret key.
### Issuing Address Compromise
If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new tokens and send them to users or trade them in the decentralized exchange. This can make a stablecoin issuer insolvent. It can become difficult for the financial institution to distinguish legitimately-obtained tokens and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have trust lines to the old issuing address must create new trust lines with the new address.
### Multiple Issuing Addresses
A financial institution can issue more than one type of token in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all (fungible) tokens issued from an address, including the percentage for [transfer fees](transfer-fees.html) and the [global freeze](freezes.html) status. If the financial institution wants the flexibility to manage settings differently for each type of token, the institution must multiple issuing addresses.
## Operational Addresses
An operational address is like a cash register. It makes payments on behalf of the institution by transferring tokens to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create trust lines to an operational address.
Each operational address has a limited balance of tokens and XRP. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address.
### Operational Address Compromise
If a malicious actor learns the secret key behind an operational address, the financial institution can only lose as much as that operational address holds. The institution can switch to a new operational address with no action from customers and partners.
## Standby Addresses
Another optional step that an institution can take to balance risk and convenience is to use "standby addresses" as an intermediate step between the issuing address and operational addresses. The institution can fund additional XRP Ledger addresses as standby addresses, whose keys are not available to always-online servers, but are entrusted to different trusted users.
When an operational address is running low on funds (either tokens or XRP), a trusted user can use a standby address to refill the operational address's balance. When a standby addresses run low on funds, the institution can use the issuing address to send more funds to a standby address in a single transaction, and the standby addresses can distribute those funds among themselves if necessary. This improves security of the issuing address, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.
As with operational addresses, a standby address must have an accounting relationship with the issuing address, and not with customers or partners. All precautions that apply to operational addresses also apply to standby addresses.
### Standby Address Compromise
If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
## See Also
- **Concepts:**
- [Accounts](accounts.html)
- [Cryptographic Keys](cryptographic-keys.html)
- **Tutorials:**
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Assign a Regular Key Pair](assign-a-regular-key-pair.html)
- [Change or Remove a Regular Key Pair](change-or-remove-a-regular-key-pair.html)
- **References:**
- [account_info method][]
- [SetRegularKey transaction][]
- [AccountRoot object](accountroot.html)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

4
content/concepts/nft-concepts/nft-conceptual-overview.md → content/concepts/tokens/non-fungible-tokens.md
View File

@@ -1,6 +1,6 @@
--- ---
html: nft-conceptual-overview.html html: non-fungible-tokens.html
parent: nft-concepts.html parent: tokens.html
blurb: Introduction to XRPL NFTs. blurb: Introduction to XRPL NFTs.
filters: filters:
- include_code - include_code

2
content/concepts/issued-currencies/paths.ja.md → content/concepts/tokens/paths.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: paths.html html: paths.html
parent: issued-currencies.html parent: tokens.html
blurb: 発行済み通貨の支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。 blurb: 発行済み通貨の支払いは、接続されているユーザーのパスとオーダーブックを通す必要があります。
labels: labels:
- 支払い - 支払い

18
content/concepts/issued-currencies/paths.md → content/concepts/tokens/paths.md
View File

@@ -1,6 +1,6 @@
--- ---
html: paths.html html: paths.html
parent: issued-currencies.html parent: tokens.html
blurb: Payments of issued currencies must traverse paths of connected users and order books. blurb: Payments of issued currencies must traverse paths of connected users and order books.
labels: labels:
- Payments - Payments
@@ -8,9 +8,9 @@ labels:
--- ---
# Paths # Paths
In the XRP Ledger, paths define a way for [issued currency](issued-currencies-overview.html) payments to flow through intermediary steps on their way from sender to receiver. Paths enable [cross-currency payments](cross-currency-payments.html) by connecting sender and receiver through orders in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). Paths also enable complex settlement of offsetting debts. In the XRP Ledger, paths define a way for [tokens](tokens.html) to flow through intermediary steps as part of a payment. Paths enable [cross-currency payments](cross-currency-payments.html) by connecting sender and receiver through orders in the XRP Ledger's [decentralized exchange](decentralized-exchange.html). Paths also enable complex settlement of offsetting debts.
A single Payment transaction in the XRP Ledger can use multiple paths, combining liquidity from different sources to deliver the desired amount. Thus, a transaction includes a _path set_, which is a collection of possible paths to take. The paths in a path set must start and end with the same currency. A single Payment transaction in the XRP Ledger can use multiple paths, combining liquidity from different sources to deliver the desired amount. Thus, a transaction includes a _path set_, which is a collection of possible paths to take. All paths in a path set must start with the same currency, and must also end with the same currency as each other.
Since XRP can be sent directly to any address, an [XRP-to-XRP transaction](direct-xrp-payments.html) does not use any paths. Since XRP can be sent directly to any address, an [XRP-to-XRP transaction](direct-xrp-payments.html) does not use any paths.
@@ -19,13 +19,13 @@ Since XRP can be sent directly to any address, an [XRP-to-XRP transaction](direc
A path is made of steps that connect the sender to the receiver of the payment. Every step is either: A path is made of steps that connect the sender to the receiver of the payment. Every step is either:
* Rippling through another address with the same currency * Rippling through another address with the same currency
* Exchanging currency at an order book * Trading tokens or XRP using an order book
Rippling through another address is the process of moving debt around. In the typical case, this involves reducing an issuer's obligation to one party and increasing the obligation to another party. Rippling can occur between any addresses that are connected by trust lines. See [Understanding the No Ripple Flag](rippling.html) for more examples of rippling. [Rippling](rippling.html) is the process of exchanging equivalent tokens using the same currency code. In the typical case, rippling through an issuer involves reducing the tokens issued to one party and increasing the tokens issued to another party by an equal amount. The path step specifies which account to ripple through.
In the case of a currency exchange step, the path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) <!-- STYLE_OVERRIDE: will --> [Trading tokens and possibly XRP](decentralized-exchange.html) involves going to an order book and finding the best exchange rate between the assets involved for the amount being sent. The path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) <!-- STYLE_OVERRIDE: will -->
In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.html), trust line quality, or rounding. In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.html), trust line quality settings, or rounding.
{{ include_svg("img/paths-examples.svg", "Diagram of three example paths") }} {{ include_svg("img/paths-examples.svg", "Diagram of three example paths") }}
@@ -50,7 +50,7 @@ By convention, several steps of a path are implied by the [fields of the Payment
* The first step of a path is always implied to be the sender of the transaction, as defined by the transaction's `Account` field. * The first step of a path is always implied to be the sender of the transaction, as defined by the transaction's `Account` field.
* If the transaction includes a `SendMax` field with an `issuer` that is not the sender of the transaction, that issuer is implied to be the second step of the path. * If the transaction includes a `SendMax` field with an `issuer` that is not the sender of the transaction, that issuer is implied to be the second step of the path.
* If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines in the given currency. See [special values for `SendMax` and `Amount`](payment.html#special-issuer-values-for-sendmax-and-amount) for details. * If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines for the given currency code. See [special values for `SendMax` and `Amount`](payment.html#special-issuer-values-for-sendmax-and-amount) for details.
* If the `Amount` field of the transaction includes an `issuer` that is not the same as the `Destination` of the transaction, that issuer is implied to be the second-to-last step of the path. * If the `Amount` field of the transaction includes an `issuer` that is not the same as the `Destination` of the transaction, that issuer is implied to be the second-to-last step of the path.
* Finally, last step of a path is always implied to be the receiver of a transaction, as defined by the transaction's `Destination` field. * Finally, last step of a path is always implied to be the receiver of a transaction, as defined by the transaction's `Destination` field.
@@ -61,7 +61,7 @@ In addition to explicitly specified paths, a transaction can execute along the _
The default path could be any of the following: The default path could be any of the following:
* If the transaction is uses only one currency (regardless of issuer), then the default path assumes the payment should ripple through the addresses involved. This path only works if those addresses are connected by trust lines. * If the transaction is uses only one token (regardless of issuer), then the default path assumes the payment should ripple through the addresses involved. This path only works if those addresses are connected by trust lines.
* If `SendMax` is omitted, or the `issuer` of the `SendMax` is the sender, the default path needs a trust line from the sending `Account` to the `issuer` of the destination `Amount` to work. * If `SendMax` is omitted, or the `issuer` of the `SendMax` is the sender, the default path needs a trust line from the sending `Account` to the `issuer` of the destination `Amount` to work.
* If the `SendMax` and `Amount` have different `issuer` values, and neither are the sender or receiver, the default path is probably not useful because it would need to ripple across a trust line between the two issuers. Ripple (the company) typically discourages issuers from trusting one another directly. * If the `SendMax` and `Amount` have different `issuer` values, and neither are the sender or receiver, the default path is probably not useful because it would need to ripple across a trust line between the two issuers. Ripple (the company) typically discourages issuers from trusting one another directly.
* For cross-currency transactions, the default path uses the order book between the source currency (as specified in the `SendMax` field) and the destination currency (as specified in the `Amount` field). * For cross-currency transactions, the default path uses the order book between the source currency (as specified in the `SendMax` field) and the destination currency (as specified in the `Amount` field).

2
content/concepts/issued-currencies/rippling.ja.md → content/concepts/tokens/rippling.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: rippling.html html: rippling.html
parent: issued-currencies.html parent: tokens.html
blurb: Ripplingは、複数当事者間での発行済み通貨残高の自動ネット決済です。 blurb: Ripplingは、複数当事者間での発行済み通貨残高の自動ネット決済です。
labels: labels:
- トークン - トークン

14
content/concepts/issued-currencies/rippling.md → content/concepts/tokens/rippling.md
View File

@@ -1,20 +1,20 @@
--- ---
html: rippling.html html: rippling.html
parent: issued-currencies.html parent: tokens.html
blurb: Rippling is automatic multi-party net settlement of issued currency balances. blurb: Rippling is automatic multi-party net settlement of token balances.
labels: labels:
- Tokens - Tokens
- Cross-Currency - Cross-Currency
--- ---
# Rippling # Rippling
In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](trust-lines-and-issuing.html) for the same currency. Rippling is an essential part of issued currencies, because it allows users who trust the same issuer to send issued balances to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way [currency exchange order](offers.html) with no limit and a 1:1 exchange rate for two currencies with the same currency code but different issuers. In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](trust-lines-and-issuing.html) for the same token. Rippling is essential, because it allows users who hold tokens to send those to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way [exchange order](offers.html) with no limit and a 1:1 exchange rate for two tokens with the same currency code but different issuers.
Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling. Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling.
For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between issuers of the same currency. Thus, the [No Ripple Flag](#the-no-ripple-flag) disables rippling on incoming trust lines by default, unless the account enables rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag). For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between tokens with the same currency code but different issuers. The [No Ripple Flag](#the-no-ripple-flag) disables rippling by default when others open trust lines to your account, unless you enable rippling by default using the [Default Ripple flag](#the-default-ripple-flag).
**Caution:** If you create a trust line to another address, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line. **Caution:** When you create a trust line, you must explicitly enable the `tfSetNoRipple` flag to block rippling on your side of that trust line.
## Example of Rippling ## Example of Rippling
@@ -32,7 +32,7 @@ We call this process, where two addresses pay each other by adjusting the balanc
Non-issuing accounts, especially liquidity providers who may hold balances from different issuers with different fees and policies, usually do not want their balances to ripple. Non-issuing accounts, especially liquidity providers who may hold balances from different issuers with different fees and policies, usually do not want their balances to ripple.
The **No Ripple** flag is a setting on a trust line. When two trust lines both have No Ripple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers of the same currency. The **No Ripple** flag is a setting on a trust line. When two trust lines both have No Ripple enabled by the same address, payments from third parties cannot "ripple" through that address on those trust lines. This protects liquidity providers from having balances shift unexpectedly between different issuers using the same currency code.
An account can disable No Ripple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag). An account can disable No Ripple on a single trust line, which can allow rippling through any pair that includes that trust line. The account can also enable rippling by default by enabling the [Default Ripple flag](#the-default-ripple-flag).
@@ -61,7 +61,7 @@ The No Ripple flag makes certain paths invalid, so that they cannot be used to m
## The Default Ripple Flag ## The Default Ripple Flag
The **Default Ripple** flag is an account setting that enables rippling on all incoming trust lines by default. Gateways and other currency issuers MUST enable this flag for their customers to be able to send those currencies to each other. The **Default Ripple** flag is an account setting that enables rippling on all _incoming_ trust lines by default. Issuers MUST enable this flag for their customers to be able to send tokens to each other.
The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a [TrustSet transaction][] to change the No Ripple setting of a trust line to match your address's new default. The Default Ripple setting of your account does not affect trust lines that you create; only trust lines that others open to you. If you change the Default Ripple setting of your account, trust lines that were created before the change keep their existing No Ripple settings. You can use a [TrustSet transaction][] to change the No Ripple setting of a trust line to match your address's new default.

3
content/concepts/issued-currencies/issued-currencies-overview.ja.md → content/concepts/tokens/tokens.ja.md
View File

@@ -1,6 +1,5 @@
--- ---
html: issued-currencies-overview.html parent: concepts.html
parent: issued-currencies.html
blurb: 発行済み通貨の概要と、XRP Ledgerにおけるその特性について説明します。 blurb: 発行済み通貨の概要と、XRP Ledgerにおけるその特性について説明します。
labels: labels:
- トークン - トークン

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

@@ -0,0 +1,82 @@
---
parent: concepts.html
blurb: Anyone can make tokens representing digital value on the XRP Ledger.
labels:
- Tokens
---
# Tokens
All assets other than XRP can be represented in the XRP Ledger as **tokens**. Standard tokens are tracked in relationships called [trust lines](trust-lines-and-issuing) between accounts. Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who don't want them. Tokens can represent any type of value, including "stablecoins" backed by assets that exist outside of the ledger, purely digital tokens created specifically on the XRP Ledger, community credit, and more.
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) :not_enabled: for details of the XRP Ledger's native support.
Tokens can used for [cross-currency payments](cross-currency-payments.html) and can be traded in the [decentralized exchange](decentralized-exchange.html).
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html) on trust lines to prevent those trust lines from rippling.
## Stablecoins
A common model for tokens in the XRP Ledger is that an issuer holds assets of equivalent value outside of the XRP Ledger, and issues tokens representing that value on the ledger. This type of issuer is sometimes called a _gateway_ because currency can move into and out of the XRP Ledger through their service. If the assets that back a token use the same amounts and denomination as the tokens in the ledger, that token can be considered a "stablecoin" because—in theory—the exchange rate between that token and its off-ledger representation should be stable at 1:1.
A stablecoin issuer should offer _deposits_ and _withdrawals_ to exchange the tokens for the actual currency or asset in the world outside the XRP Ledger.
In practice, the XRP Ledger is a computer system that cannot enforce any rules outside of itself, so stablecoins on the XRP Ledger depend on their issuer's integrity. If you can't count on the stablecoin's issuer to redeem your tokens for the real thing on demand, then you shouldn't expect the stablecoin to retain its value. As a user, you should be mindful of who's issuing the tokens: are they reliable, lawful, and solvent? If not, it's probably best not to hold those tokens.
For more information on how to run a gateway, see the [Becoming an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html).
## Community Credit
Another way you can use the XRP Ledger is for "community credit", a system where individuals who know each other can use the XRP Ledger to track who owes who else how much money. A powerful feature of the XRP Ledger is that it can automatically and atomically use these debts to settle payments through [rippling](rippling.html).
For example, if Asheesh owes Marcus $20, and Marcus owes Bharath $50, Bharath can "pay" Asheesh $20 by canceling that much of Marcus's debt to him in exchange for canceling Asheesh's debt to Marcus. The reverse is also possible: Asheesh can pays Bharath through Marcus by increasing their respective debts. The XRP Ledger can settle complex chains of exchanges like this in a single transaction without the accounts in the middle needing to do anything manually.
For more on this type of usage, see [paths](paths.html). <!--{# TODO: It would be nice to be able to link to a page with more illustrative examples of community credit. #}-->
## Other Tokens
There are other use cases for issued currencies in the XRP Ledger. For example, you can create an "Initial Coin Offering" (ICO) by issuing a fixed amount of currency to a secondary address, then "throwing away the key" to the issuer.
**Warning:** ICOs may be [regulated as securities](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings) in the USA. <!-- SPELLING_IGNORE: ico, icos -->
Be sure to research the relevant regulations before engaging in any financial service business.
## Token Properties
Tokens in the XRP Ledger are [fundamentally different than XRP](currency-formats.html#comparison). Tokens always exist _in trust lines_, and all transfers of tokens move along trust lines. You cannot cause someone else's account to hold more of a token than the _limit_ configured on their trust line. (You _can_ cause your own trust line to go over the limit, for example by buying more of it in the [decentralized exchange](decentralized-exchange.html) or by decreasing the limit after you already have a positive balance.)
Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
Anyone can issue tokens by sending a [Payment transaction][] if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](cross-currency-payments.html) or trades can also create more tokens according to an issuer's settings.
Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a [tick size](ticksize.html) for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezes.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
For a tutorial of the technical steps involved in issuing a token, see [Issue a Fungible Token](issue-a-fungible-token.html).
## See Also
- **Concepts:**
- [XRP](xrp.html)
- [Cross-Currency Payments](cross-currency-payments.html)
- [Decentralized Exchange](decentralized-exchange.html)
- **Tutorials:**
- [Issue a Fungible Token](issue-a-fungible-token.html)
- [Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)
- [Look Up Transaction Results](look-up-transaction-results.html)
- [Use Specialized Payment Types](use-specialized-payment-types.html)
- **References:**
- [Payment transaction][]
- [TrustSet transaction][]
- [RippleState object](ripplestate.html)
- [account_lines method][]
- [account_currencies method][]
- [gateway_balances method][]
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

2
content/concepts/issued-currencies/transfer-fees.ja.md → content/concepts/tokens/transfer-fees.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: transfer-fees.html html: transfer-fees.html
parent: issued-currencies.html parent: tokens.html
blurb: 通貨発行者は、自己の発行済み通貨の送金に手数料を課すことができます。 blurb: 通貨発行者は、自己の発行済み通貨の送金に手数料を課すことができます。
labels: labels:
- 手数料 - 手数料

26
content/concepts/issued-currencies/transfer-fees.md → content/concepts/tokens/transfer-fees.md
View File

@@ -1,21 +1,29 @@
--- ---
html: transfer-fees.html html: transfer-fees.html
parent: issued-currencies.html parent: tokens.html
blurb: Currency issuers can charge a fee for transferring their issued currencies. blurb: Token issuers can charge a fee for transferring their tokens.
labels: labels:
- Fees - Fees
- Tokens - Tokens
--- ---
# Transfer Fees # Transfer Fees
The `TransferRate` setting in the XRP Ledger allows [financial institutions that issue currency in the XRP Ledger](become-an-xrp-ledger-gateway.html) to charge users a _transfer fee_ for sending the currencies issued by that financial institution. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee, which becomes the property of the issuing address, and is no longer tracked in the XRP Ledger. The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user. [Token](tokens.html) issuers can charge a _transfer fee_ that applies when users transfer those tokens among themselves. The sender of the transfer is debited an extra percentage based on the transfer fee, while the recipient of the transfer is credited the intended amount. The difference is the transfer fee.
For standard tokens, the tokens paid in the transfer fee are burned, and no longer tracked in the XRP Ledger. If the token is backed by off-ledger assets, this reduces the amount of those assets the issuer has to hold in reserve to meet its obligations in the XRP Ledger. Transfer fees are usually not appropriate for tokens that aren't backed with outside assets.
Non-fungible tokens :not_enabled: can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.
[operational address]: issuing-and-operational-addresses.html [operational address]: issuing-and-operational-addresses.html
[issuing address]: issuing-and-operational-addresses.html [issuing address]: issuing-and-operational-addresses.html
XRP never has a transfer fee, because it never has an issuer. XRP never has a transfer fee, because it never has an issuer.
For example, ACME Bank might set the transfer fee to 1%. For the recipient of a payment to get 2 EUR.ACME, the sender must send 2.02 EUR.ACME. After the transaction, ACME's outstanding obligations in the XRP Ledger have decreased by 0.02€, which means that ACME no longer needs to hold that amount in the account backing its issued currencies. ## Example
In this example, ACME Bank issues a EUR stablecoin on the XRP Ledger. ACME Bank might set the transfer fee to 1%. For the recipient of a payment to get 2 EUR.ACME, the sender must send 2.02 EUR.ACME. After the transaction, ACME's outstanding obligations in the XRP Ledger have decreased by 0.02€, which means that ACME no longer needs to hold that amount in the bank account backing its EUR stablecoin.
The following diagram shows an XRP Ledger payment of 2 EUR.ACME from Alice to Charlie with a transfer fee of 1%: The following diagram shows an XRP Ledger payment of 2 EUR.ACME from Alice to Charlie with a transfer fee of 1%:
@@ -31,11 +39,11 @@ In accounting terms, Alice's, ACME's, and Charlie's balance sheets may have chan
<!--{# TODO: Update this for OwnerPaysFee amendment when that gets added #}--> <!--{# TODO: Update this for OwnerPaysFee amendment when that gets added #}-->
A transfer fee applies whenever an individual transfer would move issued currency from one party to another through the issuing account. In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example: A transfer fee applies whenever an individual transfer would move tokens from one party to another (except when going to/from the issuing account directly). In more complex transactions, this can occur multiple times. Transfer fees apply starting from the end and working backwards, so that ultimately the sender of a payment must send enough to account for all fees. For example:
{{ include_svg("img/transfer-fees-in-paths.svg", "Diagram of cross-currency payment with transfer fees") }} {{ include_svg("img/transfer-fees-in-paths.svg", "Diagram of cross-currency payment with transfer fees") }}
In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to deliver 100 USD issued by WayGate to Rosa (the recipient). FXMaker is a currency trader with the best offer in the order book, at a rate of 1 USD.WayGate for every 0.9 EUR.ACME. If there were no transfer fees, Salazar could deliver 100 USD to Rosa by sending 90 EUR. However, ACME has a transfer fee of 1% and WayGate has a transfer fee of 0.2%. This means: In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to deliver 100 USD issued by WayGate to Rosa (the recipient). FXMaker is a trader with the best offer in the order book, at a rate of 1 USD.WayGate for every 0.9 EUR.ACME. If there were no transfer fees, Salazar could deliver 100 USD to Rosa by sending 90 EUR. However, ACME has a transfer fee of 1% and WayGate has a transfer fee of 0.2%. This means:
* FXMaker must send 100.20 USD.WayGate for Rosa to receive 100 USD.WayGate. * FXMaker must send 100.20 USD.WayGate for Rosa to receive 100 USD.WayGate.
* FXMaker's current ask is 90.18 EUR.ACME to send 100.20 USD.WayGate. * FXMaker's current ask is 90.18 EUR.ACME to send 100.20 USD.WayGate.
@@ -45,15 +53,15 @@ In this scenario, Salazar (the sender) holds EUR issued by ACME, and wants to de
# Technical Details # Technical Details
The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The transfer fee applies to all currencies issued by the same account. If you want to have different transfer fees for different currencies, use different [issuing addresses][issuing address] for each currency. The transfer fee is represented by a setting on the [issuing address][]. The transfer fee cannot be less than 0% or more than 100% and is rounded down to the nearest 0.0000001%. The transfer fee applies to all tokens issued by the same account. If you want to have different transfer fees for different tokens, use multiple [issuing addresses][issuing address].
In the [XRP Ledger protocol](protocol-reference.html), the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same currency. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` ("0%" fee) or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`. In the [XRP Ledger protocol](protocol-reference.html), the transfer fee is specified in the `TransferRate` field, as an integer which represents the amount you must send for the recipient to get 1 billion units of the same token. A `TransferRate` of `1005000000` is equivalent to a transfer fee of 0.5%. By default, the `TransferRate` is set to no fee. The value of `TransferRate` cannot be set to less than `1000000000` ("0%" fee) or more than `2000000000` (a "100%" fee). The value `0` is special case for no fee, equivalent to `1000000000`.
A token issuer can submit an [AccountSet transaction][] from its [issuing address][] to change the `TransferRate` for all its tokens. A token issuer can submit an [AccountSet transaction][] from its [issuing address][] to change the `TransferRate` for all its tokens.
Anyone can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee. Anyone can check an account's `TransferRate` with the [account_info method][]. If the `TransferRate` is omitted, then that indicates no fee.
**Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% (a `TransferRate` of `2000000000`). Any transfer fees already set continue to apply at their stated rate. **Note:** The [fix1201 amendment](amendments.html), introduced in `rippled` v0.80.0 and enabled on 2017-11-14, lowered the maximum transfer fee to 100% (a `TransferRate` of `2000000000`) from an effective limit of approximately 329% (based on the maximum size of a 32-bit integer). The ledger may still contain accounts with a transfer fee setting higher than 100% because transfer fees that were already set continue to apply at their stated rate.
## Client Library Support ## Client Library Support

2
content/concepts/issued-currencies/trust-lines-and-issuing.ja.md → content/concepts/tokens/trust-lines-and-issuing.ja.md
View File

@@ -1,6 +1,6 @@
--- ---
html: trust-lines-and-issuing.html html: trust-lines-and-issuing.html
parent: issued-currencies.html parent: tokens.html
blurb: トラストラインの特性と根本原理について説明します。 blurb: トラストラインの特性と根本原理について説明します。
labels: labels:
- トークン - トークン

14
content/concepts/issued-currencies/trust-lines-and-issuing.md → content/concepts/tokens/trust-lines-and-issuing.md
View File

@@ -1,17 +1,21 @@
--- ---
html: trust-lines-and-issuing.html html: trust-lines-and-issuing.html
parent: issued-currencies.html parent: tokens.html
blurb: Learn about the properties and rationale of trust lines. blurb: Learn about the properties and rationale of trust lines.
labels: labels:
- Tokens - Tokens
--- ---
# Trust Lines and Issuing # Trust Lines and Issuing
[Issued currencies](issued-currencies.html) in the XRP Ledger often represent value held by _gateways_ in the world outside the XRP Ledger. The address that issues those funds in the XRP Ledger is expected to pay the balance back, outside of the XRP Ledger, when users redeem their XRP Ledger balances by returning them to the issuer. [Tokens](tokens.html) in the XRP Ledger are often "stablecoins" backed by value held by the issuer in the world outside the XRP Ledger. The is expected to pay the equivalent amount back, outside of the XRP Ledger, when users redeem their stablecoins by returning them to the issuer in the XRP Ledger. In other cases, XRP Ledger tokens represent community credit that can be swapped between people within relatively small limits.
Since a computer program cannot force a someone to keep a promise in the outside world, trust lines represent a way of configuring how much you trust an issuer to hold on your behalf. Since a large, reputable financial institution is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuer "owe" you in the XRP Ledger. If the issuer defaults or goes out of business, you can lose up to that much money because the balances you hold in the XRP Ledger can no longer be exchanged for equivalent balances elsewhere. (You can still keep or trade the issued currency in the XRP Ledger, but there is probably no longer any reason to consider that issued currency to be worth anything.) Since a computer program cannot force a someone to keep a promise in the outside world, trust lines represent a way of configuring how much you trust an issuer to hold on your behalf. Since a large, reputable financial institution is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuer "owe" you in the XRP Ledger. If the issuer defaults or goes out of business, you can lose up to that much money because the tokens you hold in the XRP Ledger can no longer be exchanged for equivalent balances elsewhere. (You can still keep or trade those tokens within the XRP Ledger, but there is probably no longer any reason to consider that token to be worth anything.)
There are two cases where you can hold a balance on a trust line that is _greater_ than your limit: when you acquire more of that currency through [trading](decentralized-exchange.html), or when you decrease the limit on your trust line. There are three cases where you can hold a balance on a trust line that is _greater_ than your limit:
1. When you acquire more of that token through [trading](decentralized-exchange.html).
2. When you decrease the limit on a trust line that has a positive balance.
3. When you acquire more of that token by [cashing a Check](checks.html). (_Requires the [CheckCashMakesTrustLine amendment][] :not_enabled:_)
Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](reserves.html). This applies to the account extending trust, not to the account receiving it. Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](reserves.html). This applies to the account extending trust, not to the account receiving it.
@@ -19,7 +23,7 @@ Each trust line is specific to a given [currency code][]. Two accounts can have
## Trust Line Settings ## Trust Line Settings
Trust lines are represented in the ledger's state data as [RippleState objects](ripplestate.html). A single RippleState object represents the potential for a trust line in either direction or both: it has a limit and other settings for each side, but a single shared net balance between the two sides. Trust lines are represented in the ledger's state data as [RippleState objects](ripplestate.html). A single RippleState object represents the potential for a trust line in either direction or both: it has a limit and settings for each side, but a single shared net balance between the two sides.
A trust line with settings in the default state is equivalent to no trust line. A trust line with settings in the default state is equivalent to no trust line.

89
dactyl-config.yml
View File

@@ -692,91 +692,102 @@ pages:
targets: targets:
- ja - ja
- name: Issued Currencies - md: concepts/tokens/tokens.md
html: issued-currencies.html
parent: concepts.html
template: pagetype-category.html.jinja
blurb: All currencies other than XRP can be represented in the XRP Ledger as issued currencies. Learn more about how issued currencies function in the XRP Ledger.
targets: targets:
- en - en
- name: 発行済み通貨 - md: concepts/tokens/tokens.ja.md
targets:
- ja
# Redirects from old (emptyish) landing pages.
- name: Tokens
html: issued-currencies.html html: issued-currencies.html
parent: concepts.html template: pagetype-redirect.html.jinja
template: pagetype-category.html.jinja redirect_url: tokens.html
blurb: Anyone can make tokens representing digital value on the XRP Ledger.
targets:
- en
- name: トークン
html: issued-currencies.html
template: pagetype-redirect.html.jinja
redirect_url: tokens.html
blurb: XRP Ledgerでは、XRP以外の通貨はすべて発行済み通貨とされます。XRP Ledgerで発行済み通貨がどのように機能するか説明します。 blurb: XRP Ledgerでは、XRP以外の通貨はすべて発行済み通貨とされます。XRP Ledgerで発行済み通貨がどのように機能するか説明します。
targets: targets:
- ja - ja
- md: concepts/issued-currencies/issued-currencies-overview.md - md: concepts/tokens/trust-lines-and-issuing.md
targets: targets:
- en - en
- md: concepts/issued-currencies/issued-currencies-overview.ja.md - md: concepts/tokens/trust-lines-and-issuing.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/trust-lines-and-issuing.md - md: concepts/tokens/authorized-trust-lines.md
targets: targets:
- en - en
- md: concepts/issued-currencies/trust-lines-and-issuing.ja.md - md: concepts/tokens/authorized-trust-lines.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/authorized-trust-lines.md - md: concepts/tokens/non-fungible-tokens.md
targets:
- en
- ja
- md: concepts/tokens/freezes.md
targets: targets:
- en - en
- md: concepts/issued-currencies/authorized-trust-lines.ja.md - md: concepts/tokens/freezes.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/freezes.md - md: concepts/tokens/common-misconceptions-about-freezes.md
targets:
- en
- ja
- md: concepts/tokens/rippling.md
targets: targets:
- en - en
- md: concepts/issued-currencies/freezes.ja.md - md: concepts/tokens/rippling.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/rippling.md - md: concepts/tokens/transfer-fees.md
targets: targets:
- en - en
- md: concepts/issued-currencies/rippling.ja.md - md: concepts/tokens/transfer-fees.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/transfer-fees.md - md: concepts/tokens/issuing-and-operational-addresses.md
targets: targets:
- en - en
- md: concepts/issued-currencies/transfer-fees.ja.md - md: concepts/tokens/issuing-and-operational-addresses.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/issuing-and-operational-addresses.md - md: concepts/tokens/paths.md
targets: targets:
- en - en
- md: concepts/issued-currencies/issuing-and-operational-addresses.ja.md - md: concepts/tokens/paths.ja.md
targets: targets:
- ja - ja
- md: concepts/issued-currencies/paths.md - md: concepts/tokens/demurrage.md
targets: targets:
- en - en
- md: concepts/issued-currencies/paths.ja.md - md: concepts/tokens/demurrage.ja.md
targets:
- ja
- md: concepts/issued-currencies/demurrage.md
targets:
- en
- md: concepts/issued-currencies/demurrage.ja.md
targets: targets:
- ja - ja
@@ -1019,20 +1030,28 @@ pages:
targets: targets:
- ja - ja
# Redirect old NFT articles
- name: Non-fungible Tokens (NFTs) - name: Non-fungible Tokens (NFTs)
html: nft-concepts.html html: nft-concepts.html
parent: concepts.html template: pagetype-redirect.html.jinja
template: pagetype-category.html.jinja redirect_url: non-fungible-tokens.html
blurb: Explore XRPL-native support for NFTs. blurb: Explore XRPL-native support for NFTs.
nav_omit: true
targets: targets:
- en - en
- ja - ja
- md: concepts/nft-concepts/nft-conceptual-overview.md - name: NFT Conceptual Overview
html: nft-conceptual-overview.html
template: pagetype-redirect.html.jinja
redirect_url: non-fungible-tokens.html
blurb: Explore XRPL-native support for NFTs.
nav_omit: true
targets: targets:
- en - en
- ja - ja
# Tutorials -------------------------------------------------------------------- # Tutorials --------------------------------------------------------------------
- name: Tutorials - name: Tutorials