mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 19:55:54 +00:00
Use amendment status icons in body text
This commit is contained in:
mDuo13
@@ -1,6 +1,6 @@
|
||||
# Tick Size
|
||||
|
||||
_Requires the [TickSize amendment](known-amendments.html#ticksize)._
|
||||
_((ENABLED_ICON) Requires the [TickSize amendment](known-amendments.html#ticksize).)_
|
||||
|
||||
When an Offer is placed into an order book, its exchange rate is truncated based on the `TickSize` values set by the issuers of the currencies involved in the Offer. When a trader offers to exchange XRP and an issued currency, the `TickSize` from the issuer of the currency applies. When a trader offers to exchange two issued currencies, the offer uses the smaller `TickSize` value (that is, the one with fewer significant digits). If neither currency has a `TickSize` set, the default behavior applies.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ The transaction to authorize a trust line must be signed by the issuing 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. _(Requires the [TrustSetAuth amendment](known-amendments.html#trustsetauth), which has been enabled in the production XRP Ledger since 2016-07-19.)_
|
||||
**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. _((ENABLED_ICON) Requires the [TrustSetAuth amendment](known-amendments.html#trustsetauth).)_
|
||||
|
||||
## RequireAuth Setting
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Deposit Authorization
|
||||
|
||||
_(Requires the [DepositAuth amendment](known-amendments.html#depositauth).)_
|
||||
_((ENABLED_ICON) Requires the [DepositAuth amendment](known-amendments.html#depositauth).)_
|
||||
|
||||
Deposit Authorization is an optional feature of an [account](accounts.html) in the XRP Ledger. With Deposit Authorization enabled, transactions cannot send value of any kind to the account unless the sender of those transactions is the account itself. This includes transfers of XRP and issued currencies.
|
||||
|
||||
@@ -14,7 +14,7 @@ The Deposit Authorization flag introduces an option for those using the XRP Ledg
|
||||
|
||||
When you have Deposit Authorization enabled, you can receive money from [Checks](known-amendments.html#checks), [Escrow](escrow.html), and [Payment Channels](known-amendments.html#paychan). In these transactions' "two-step" model, first the source sends a transaction to authorize sending funds, then the destination sends a transaction to authorize receiving those funds.
|
||||
|
||||
To receive money from [Payment transactions][] when you have Deposit Authorization enabled, you must [preauthorize](#preauthorization) the senders of those Payments. _(Requires the [DepositPreauth amendment][])_
|
||||
To receive money from [Payment transactions][] when you have Deposit Authorization enabled, you must [preauthorize](#preauthorization) the senders of those Payments. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
|
||||
|
||||
## Recommended Usage
|
||||
|
||||
@@ -29,15 +29,15 @@ To get the full effect of Deposit Authorization, Ripple recommends also doing th
|
||||
An account with Deposit Authorization enabled:
|
||||
|
||||
- **Cannot** be the destination of [Payment transactions][], with **the following exceptions**:
|
||||
- If the destination has [preauthorized](#preauthorization) the sender of the Payment. _(Requires the [DepositPreauth amendment][])_
|
||||
- If the destination has [preauthorized](#preauthorization) the sender of the Payment. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
|
||||
- If the account's XRP balance is equal to or below the minimum account [reserve requirement](reserves.html), it can be the destination of an XRP Payment whose `Amount` is equal or less than the minimum account reserve (currently 20 XRP). This is to prevent an account from becoming "stuck" by being unable to send transactions but also unable to receive XRP. The account's owner reserve does not matter for this case.
|
||||
- Can receive XRP from [PaymentChannelClaim transactions][] **only in the following cases**:
|
||||
- The sender of the PaymentChannelClaim transaction is the destination of the payment channel.
|
||||
- The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim. _(Requires the [DepositPreauth amendment][])_
|
||||
- The destination of the PaymentChannelClaim transaction has [preauthorized](#preauthorization) the sender of the PaymentChannelClaim. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
|
||||
- Can receive XRP from [EscrowFinish transactions][] **only in the following cases**:
|
||||
- The sender of the EscrowFinish transaction is the destination of the escrow.
|
||||
- The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish. _(Requires the [DepositPreauth amendment][])_
|
||||
- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _(Requires the [Checks amendment](known-amendments.html#checks).)_
|
||||
- The destination of the EscrowFinish transaction has [preauthorized](#preauthorization) the sender of the EscrowFinish. _((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
|
||||
- **Can** receive XRP or issued currencies by sending a [CheckCash][] transaction. _((NOT_ENABLED_ICON) Requires the [Checks amendment](known-amendments.html#checks).)_
|
||||
- **Can** receive XRP or issued currencies by sending [OfferCreate transactions][].
|
||||
- If the account sends an OfferCreate transaction that is not fully executed immediately, it **can** receive the remainder of the ordered XRP or issued currency later when the offer is consumed by other accounts' [Payment][] and [OfferCreate][] transactions.
|
||||
- If the account has created any trust lines without the [NoRipple flag](rippling.html) enabled, or has enabled the DefaultRipple flag and issued any currency, the account **can** receive the issued currencies of those trust lines in [Payment transactions][] as a result of rippling. It cannot be the destination of those transactions.
|
||||
@@ -64,7 +64,7 @@ If the result of the `Flags` value bitwise-AND the `lsfDepositAuth` flag value (
|
||||
|
||||
## Preauthorization
|
||||
|
||||
_(Requires the [DepositPreauth amendment][])_
|
||||
_((ENABLED_ICON) Requires the [DepositPreauth amendment][])_
|
||||
|
||||
Accounts with DepositAuth enabled can _preauthorize_ certain senders, to allow payments from those senders to succeed even with DepositAuth enabled. This allows specific senders to send funds directly without the receiver taking action on each transaction individually. Preauthorization is not required to use DepositAuth, but can make certain operations more convenient.
|
||||
|
||||
@@ -99,7 +99,6 @@ You can use the [deposit_authorized method][] to see if an account is authorized
|
||||
- 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](become-an-xrp-ledger-gateway.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](partial-payments.html) provide a way for accounts to return unwanted payments while subtracting [transfer fees](transfer-fees.html) and exchange rates from the amount delivered instead of adding them to the amount sent.
|
||||
<!--{# TODO: Add links for Preauth-related reference material DOC-1652 #}-->
|
||||
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -43,7 +43,7 @@ The `AccountRoot` object has the following fields:
|
||||
| `EmailHash` | String | Hash128 | _(Optional)_ The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). |
|
||||
| `MessageKey` | String | VariableLength | _(Optional)_ A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. No more than 33 bytes. |
|
||||
| `RegularKey` | String | AccountID | _(Optional)_ The address of a keypair that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
|
||||
| `TickSize` | Number | UInt8 | _(Optional)_ How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Requires the [TickSize amendment](known-amendments.html#ticksize).)_ |
|
||||
| `TickSize` | Number | UInt8 | _(Optional)_ How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _((ENABLED_ICON) Requires the [TickSize amendment](known-amendments.html#ticksize).)_ |
|
||||
| `TransferRate` | Number | UInt32 | _(Optional)_ A [transfer fee](https://ripple.com/knowledge_center/transfer-fees/) to charge other users for sending currency issued by this account to each other. |
|
||||
| `WalletLocator` | String | Hash256 | _(Optional)_ **DEPRECATED**. Do not use. |
|
||||
| `WalletSize` | Number | UInt32 | _(Optional)_ **DEPRECATED**. Do not use. |
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Check
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170 "Source")
|
||||
|
||||
_Requires the [Checks Amendment](known-amendments.html#checks)._
|
||||
_((NOT_ENABLED_ICON) Requires the [Checks Amendment](known-amendments.html#checks).)_
|
||||
|
||||
A `Check` object describes a check, similar to a paper personal check, which can be cashed by its destination to get money from its sender. (The potential payment has already been approved by its sender, but no money moves until it is cashed. Unlike an [Escrow](escrow.html), the money for a Check is not set aside, so cashing the Check could fail due to lack of funds.)
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Escrow
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101 "Source")
|
||||
|
||||
_(Requires the [Escrow Amendment](known-amendments.html#escrow).)_
|
||||
_((ENABLED_ICON) Requires the [Escrow Amendment](known-amendments.html#escrow).)_
|
||||
|
||||
The `Escrow` object type represents a held payment of XRP waiting to be executed or canceled. An [EscrowCreate transaction][] creates an `Escrow` object in the ledger. A successful [EscrowFinish][] or [EscrowCancel][] transaction deletes the object. If the ``Escrow`` object has a [_crypto-condition_](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), the payment can only succeed if an EscrowFinish transaction provides the corresponding _fulfillment_ that satisfies the condition. (The only supported crypto-condition type is [PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1).) If the `Escrow` object has a `FinishAfter` time, the held payment can only execute after that time.
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# PayChannel
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L141-L155 "Source")
|
||||
|
||||
_(Requires the [PayChan Amendment](known-amendments.html#paychan).)_
|
||||
_((ENABLED_ICON) Requires the [PayChan Amendment](known-amendments.html#paychan).)_
|
||||
|
||||
The `PayChannel` object type represents a payment channel. Payment channels enable small, rapid off-ledger payments of XRP that can be later reconciled with the consensus ledger. A payment channel holds a balance of XRP that can only be paid out to a specific destination address until the channel is closed. Any unspent XRP is returned to the channel's owner (the source address that created and funded it) when the channel closes.
|
||||
|
||||
|
||||
@@ -1,7 +1,10 @@
|
||||
# SignerList
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127 "Source")
|
||||
|
||||
The `SignerList` object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using a [SignerListSet transaction][]. This object type is introduced by the [MultiSign amendment](known-amendments.html#multisign). [New in: rippled 0.31.0][]
|
||||
_((ENABLED_ICON) Requires the [MultiSign amendment](known-amendments.html#multisign).)_
|
||||
|
||||
The `SignerList` object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a SignerList using a [SignerListSet transaction][].
|
||||
|
||||
|
||||
## Example {{currentpage.name}} JSON
|
||||
|
||||
@@ -68,7 +71,7 @@ When processing a multi-signed transaction, the server dereferences the `Account
|
||||
|
||||
## {{currentpage.name}} Flags
|
||||
|
||||
_Requires the [MultiSignReserve Amendment](known-amendments.html#multisignreserve)._
|
||||
_((NOT_ENABLED_ICON) Requires the [MultiSignReserve Amendment](known-amendments.html#multisignreserve).)_
|
||||
|
||||
SignerList objects can have the following flag value:
|
||||
|
||||
@@ -82,7 +85,7 @@ A SignerList contributes to its owner's [reserve requirement](reserves.html).
|
||||
|
||||
Without the [MultiSignReserve Amendment](known-amendments.html#multisignreserve), the SignerList itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with a SignerList is anywhere from 3 times to 10 times the reserve required by a single trust line ([RippleState](ripplestate.html)) or [Offer](offer.html) object in the ledger.
|
||||
|
||||
With the [MultiSignReserve Amendment](known-amendments.html#multisignreserve) enabled, the SignerList counts as one object, regardless of how many members it has. As a result, the owner reserve associated with a SignerList is 5 XRP, regardless of how many members it has.
|
||||
(NOT_ENABLED_ICON) With the [MultiSignReserve Amendment](known-amendments.html#multisignreserve) enabled, the SignerList counts as one object, regardless of how many members it has. As a result, the owner reserve associated with a SignerList is 5 XRP, regardless of how many members it has.
|
||||
|
||||
The reserve requirement does not change for SignerLists created before the MultiSignReserve amendment. To take advantage of the new reserve, update the SignerList by sending a [SignerListSet transaction][].
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# CheckCancel
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CancelCheck.cpp "Source") <!--{# TODO: change from develop to master when 0.90.0 is released #}-->
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/CancelCheck.cpp "Source")
|
||||
|
||||
_Requires the [Checks Amendment](known-amendments.html#checks)._
|
||||
_(NOT_ENABLED_ICON) Requires the [Checks Amendment](known-amendments.html#checks)._
|
||||
|
||||
Cancels an unredeemed Check, removing it from the ledger without sending any money. The source or the destination of the check can cancel a Check at any time using this transaction type. If the Check has expired, any address can cancel it.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user