mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Merge pull request #304 from mDuo13/authorized-trust-lines
Authorized trust lines
This commit is contained in:
Rome Reginelli
99
content/concept-authorized-trust-lines.md
Normal file
99
content/concept-authorized-trust-lines.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# 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.
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
1. An issuing gateway publishes its issuing address to customers.
|
||||
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. _(Requires the [TrustSetAuth amendment](reference-amendments.html#trustsetauth), which has been enabled in the production XRP Ledger since 2016-07-19.)_
|
||||
|
||||
## RequireAuth Setting
|
||||
|
||||
The `RequireAuth` setting (`requireAuthorization` in [RippleAPI](reference-rippleapi.html)) 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.
|
||||
|
||||
As a precaution, Ripple recommends that issuing gateways always enable `RequireAuth` on [operational addresses and standby addresses](concept-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.
|
||||
|
||||
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.
|
||||
|
||||
**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.
|
||||
|
||||
### Enabling RequireAuth
|
||||
|
||||
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send an [AccountSet transaction][] to enable the RequireAuth flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
|
||||
|
||||
Request:
|
||||
|
||||
```
|
||||
POST http://localhost:5005/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"Fee": "15000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 2,
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include 'snippets/secret-key-warning.md' %}
|
||||
|
||||
## Checking Whether an Account Has RequireAuth Enabled
|
||||
|
||||
To see whether an account has the RequireAuth setting enabled, use the [`account_info` command](reference-rippled.html#account-info) to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](reference-ledger-format.html#accountroot-flags).
|
||||
|
||||
If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (0x00040000) is nonzero, then the account has RequireAuth enabled. If the result is zero, then the account has RequireAuth disabled.
|
||||
|
||||
## Authorizing Trust Lines
|
||||
|
||||
If you are using the Authorized Trust Lines feature, others cannot hold balances you issue unless you first authorize their trust lines to you. If you issue more than one currency, you must separately authorize trust lines for each currency.
|
||||
|
||||
To authorize a trust line, submit a [TrustSet transaction][] from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](reference-transaction-format.html#trustset-flags) flag for the transaction.
|
||||
|
||||
The following is an example of using a locally-hosted `rippled`'s [`submit` command](reference-rippled.html#submit) to send a TrustSet transaction authorizing the customer address rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn to hold issuances of USD from the issuing address rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW:
|
||||
|
||||
Request:
|
||||
|
||||
```
|
||||
POST http://localhost:8088/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"Fee": "15000",
|
||||
"TransactionType": "TrustSet",
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": 0
|
||||
},
|
||||
"Flags": 65536
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include 'snippets/secret-key-warning.md' %}
|
||||
|
||||
## Checking Whether Trust Lines Are Authorized
|
||||
|
||||
To see whether a trust line has been authorized, use the [`account_lines` command](reference-rippled.html#account-lines) to look up the trust line. In the request, provide the customer's address in the `account` field and the issuer's address in the `peer` field.
|
||||
|
||||
In the response's `result.lines` array, find the object whose `currency` field indicates that it represents a trust line for the currency you want. If that object has a `peer_authorized` field with the value `true`, then the issuer (the address you used as the request's `peer` field) has authorized the trust line.
|
||||
|
||||
{% include 'snippets/tx-type-links.md' %}
|
||||
@@ -56,7 +56,7 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (
|
||||
|
||||
## See Also
|
||||
|
||||
- The [Authorized Accounts](tutorial-gateway-guide.html#authorized-accounts) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
|
||||
- The [Authorized Trust Lines](concept-authorized-trust-lines.html) feature (`RequireAuth` flag) limits which counterparties can hold non-XRP currencies issued by an account.
|
||||
- The `DisallowXRP` flag indicates that an account should not receive XRP. This is a softer protection than Deposit Authorization, and is not enforced by the XRP Ledger. (Client applications should honor this flag or at least warn about it.)
|
||||
- The `RequireDest` flag indicates that an account can only receive currency amounts if the sending transaction specifies a [Destination Tag](tutorial-gateway-guide.html#source-and-destination-tags). This protects users from forgetting to indicate the purpose of a payment, but does not protect recipients from unknown senders, who can make up arbitrary destination tags.
|
||||
- [Partial Payments](concept-partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](concept-transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
|
||||
|
||||
@@ -389,7 +389,7 @@ Introduces a `TickSize` field to accounts, which can be set with the [AccountSet
|
||||
|:-----------------------------------------------------------------|:----------|
|
||||
| 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC | Enabled |
|
||||
|
||||
Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Accounts](tutorial-gateway-guide.html#authorized-accounts).
|
||||
Allows pre-authorization of accounting relationships (zero-balance trust lines) when using [Authorized Trust Lines](concept-authorized-trust-lines.html).
|
||||
|
||||
With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](reference-transaction-format.html#trustset-flags) can create a new [`RippleState` ledger object](reference-ledger-format.html#ripplestate) even if it keeps all the other values of the `RippleState` node in their default state. The new `RippleState` node has the [`lsfLowAuth` or `lsfHighAuth` flag](reference-ledger-format.html#ripplestate-flags) enabled, depending on whether the sender of the transaction is considered the low node or the high node. The sender of the transaction must have already enabled [`lsfRequireAuth`](reference-ledger-format.html#accountroot-flags) by sending an [AccountSet transaction](reference-transaction-format.html#accountset) with the [asfRequireAuth flag enabled](reference-transaction-format.html#accountset-flags).
|
||||
|
||||
|
||||
@@ -172,6 +172,8 @@ Each trust line object has some combination of the following fields:
|
||||
| `quality_out` | Unsigned Integer | Rate at which the account values outgoing balances on this trust line, as a ratio of this value per 1 billion units. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
|
||||
| `no_ripple` | Boolean | (May be omitted) `true` if this account has enabled the [NoRipple flag](concept-noripple.html) for this line. If omitted, that is the same as `false`. |
|
||||
| `no_ripple_peer` | Boolean | (May be omitted) `true` if the peer account has enabled the [NoRipple flag](concept-noripple.html). If omitted, that is the same as `false`. |
|
||||
| `authorized` | Boolean | (May be omitted) `true` if this account has [authorized this trust line](concept-authorized-trust-lines.html). If omitted, that is the same as `false`. |
|
||||
| `peer_authorized`| Boolean | (May be omitted) `true` if the peer account has [authorized this trust line](concept-authorized-trust-lines.html). If omitted, that is the same as `false`. |
|
||||
| `freeze` | Boolean | (May be omitted) `true` if this account has [frozen](concept-freeze.html) this trust line. If omitted, that is the same as `false`. |
|
||||
| `freeze_peer` | Boolean | (May be omitted) `true` if the peer account has [frozen](concept-freeze.html) this trust line. If omitted, that is the same as `false`. |
|
||||
|
||||
|
||||
@@ -297,7 +297,7 @@ After the issuances have been created in the XRP Ledger, they can be freely tran
|
||||
|
||||
- Anyone can buy/sell EUR.ACME on Ripple. If ACME issues multiple currencies on Ripple, a separate trust line is necessary for each.
|
||||
- This includes XRP Ledger users who do not have an account in ACME Exchange's systems. To withdraw the funds successfully from ACME, users still have to register with ACME.
|
||||
- Optionally, ACME uses the [Authorized Accounts](#authorized-accounts) feature to limit who can hold EUR.ACME in the XRP Ledger.
|
||||
- Optionally, ACME uses the [Authorized Trust Lines](#authorized-trust-lines) feature to limit who can hold EUR.ACME in the XRP Ledger.
|
||||
- If ACME determines that a customer has acted in bad faith, ACME can [Freeze](#freeze) that user's accounting relationships to ACME in the XRP Ledger, so that the user can no longer trade in the gateway's issuances.
|
||||
- XRP Ledger users trading and sending EUR.ACME to one another requires no intervention by ACME.
|
||||
- All exchanges and balances in the XRP Ledger are publicly viewable.
|
||||
@@ -319,19 +319,11 @@ A gateway can freeze accounting relationships in the XRP Ledger to meet regulato
|
||||
For more information, see the [Freeze article](concept-freeze.html).
|
||||
|
||||
|
||||
## Authorized Accounts
|
||||
## Authorized Trust Lines
|
||||
|
||||
The XRP Ledger's Authorized Accounts feature enables a gateway to limit who can hold that gateway's issuances, so that unknown XRP Ledger addresses cannot hold the currency the gateway issues. Ripple feels this is *not necessary* in most cases, since gateways have full control over the process of redeeming Ripple balances for value in the outside world. (You can collect customer information and impose limits on withdrawals at that stage without worrying about what happens within the XRP Ledger.)
|
||||
The XRP Ledger's Authorized Trust Lines feature (formerly called "Authorized Accounts") enables a gateway to limit who can hold that gateway's issuances, so that unknown XRP Ledger addresses cannot hold the currency the gateway issues. Ripple feels this is *not necessary* in most cases, since gateways have full control over the process of redeeming Ripple balances for value in the outside world. (You can collect customer information and impose limits on withdrawals at that stage without worrying about what happens within the XRP Ledger.)
|
||||
|
||||
To use the Authorized Accounts feature, a gateway enables the `RequireAuth` flag for its issuing address, and then individually approves each accounting relationship. An address can only hold funds issued by a gateway after its accounting relationship with that gateway is approved.
|
||||
|
||||
The transaction to authorize an accounting relationship 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:
|
||||
|
||||
1. ACME publishes its issuing address to customers.
|
||||
2. Alice creates an accounting relationship from her XRP Ledger address to ACME's issuing address, indicating that she is willing to hold ACME's issuances.
|
||||
3. ACME's issuing address sends a transaction authorizing Alice's accounting relationship.
|
||||
|
||||
See [RequireAuth](#requireauth) for technical details on how to use Authorized Accounts.
|
||||
For more information, see [Authorized Trust Lines](concept-authorized-trust-lines.html).
|
||||
|
||||
|
||||
## Source and Destination Tags
|
||||
@@ -582,13 +574,7 @@ Response:
|
||||
|
||||
## RequireAuth
|
||||
|
||||
The `RequireAuth` setting (`requireAuthorization` in RippleAPI) prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty.
|
||||
|
||||
We recommend always [enabling `RequireAuth`](#enabling-requireauth) for operational addresses and standby addresses, and then never approving any accounting relationships. This prevents operational addresses from creating issuances even by accident. This is a purely precautionary measure, and does not stop those addresses from transferring issuances created by the issuing address, as they are intended to do.
|
||||
|
||||
If you want to use the [Authorized Accounts](#authorized-accounts) feature, you must also enable `RequireAuth` on your issuing address. When using Authorized Accounts, your issuing address must [submit a `TrustSet` transaction to approve each accounting relationship](#authorizing-trust-lines) that customers create with your issuing address.
|
||||
|
||||
You can only enable `RequireAuth` if the address owns no accounting relationships (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.
|
||||
The `RequireAuth` setting prevents all counterparties from holding balances issued by an address unless the address has specifically approved an accounting relationship with that counterparty. For more information, see [Authorized Trust Lines](concept-authorized-trust-lines.html).
|
||||
|
||||
### Enabling RequireAuth
|
||||
|
||||
@@ -619,7 +605,7 @@ POST http://localhost:5005/
|
||||
|
||||
### Authorizing Trust Lines
|
||||
|
||||
If you are using the [Authorized Accounts](#authorized-accounts) feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the XRP Ledger.
|
||||
If you are using the [Authorized Trust Lines](concept-authorized-trust-lines.html) feature, customers cannot hold balances you issue unless you first authorize their accounting relationships to you in the XRP Ledger.
|
||||
|
||||
To authorize an accounting relationship, submit a TrustSet transaction from your issuing address, with the user to trust as the `issuer` of the `LimitAmount`. Leave the `value` (the amount to trust them for) as **0**, and enable the [tfSetfAuth](reference-transaction-format.html#trustset-flags) flag for the transaction.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user