Merge commit '2bf9323ffd35b9f17a14b31be2510b5fed25264f' into japanese-amm

This commit is contained in:
develoQ
2023-03-01 11:20:54 +09:00
11 changed files with 492 additions and 238 deletions

View File

@@ -16,7 +16,12 @@ The following is a comprehensive list of all known [amendments](amendments.html)
|:----------------------------------|:-----------|:------------------------------|
| [fixTrustLinesToSelf][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [CheckCashMakesTrustLine][] | v1.8.0 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.8.1.html "BADGE_80d0e0") |
| [DisallowIncoming][] | v1.10.0 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixNonFungibleTokensV1_2][] | v1.10.0 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixUniversalNumber][] | v1.10.0 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [ImmediateOfferKilled][] | v1.10.0 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [XRPFees][] | v1.10.0 | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [CheckCashMakesTrustLine][] | v1.8.0 | [Enabled: 2023-01-23](https://livenet.xrpl.org/transactions/4C8546305583F72E056120B136EB251E7F45E8DFAAE65FDA33B22181A9CA4557 "BADGE_GREEN") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [Enabled: 2022-10-31](https://livenet.xrpl.org/transactions/251242639A640CD9287A14A476E7F7C20BA009FDE410570926BAAF29AA05CEDE "BADGE_GREEN") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [Enabled: 2022-10-27](https://livenet.xrpl.org/transactions/2A67DB4AC65D688281B76334C4B52038FD56931694A6DD873B5CCD9B970AD57C "BADGE_GREEN") |
| [ExpandedSignerList][] | v1.9.1 | [Enabled: 2022-10-13](https://livenet.xrpl.org/transactions/802E2446547BB86397217E32A78CB9857F21B048B91C81BCC6EF837BE9C72C87 "BADGE_GREEN") |
@@ -76,10 +81,10 @@ The following is a comprehensive list of all known [amendments](amendments.html)
## CheckCashMakesTrustLine
[CheckCashMakesTrustLine]: #checkcashmakestrustline
| Amendment | CheckCashMakesTrustLine |
|:----------|:-----------|
| Amendment | CheckCashMakesTrustLine |
|:-------------|:------------------------|
| Amendment ID | 98DECF327BF79997AEC178323AD51A830E457BFC6D454DAF3E46E5EC42DC619F |
| Status | Open for Voting |
| Status | Enabled |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -93,10 +98,10 @@ This amendment does not change the fact that you cannot force anyone to hold tok
## Checks
[Checks]: #checks
| Amendment | Checks |
|:----------|:-----------|
| Amendment | Checks |
|:-------------|:-------|
| Amendment ID | 157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -110,10 +115,10 @@ Introduces three new transaction types: CheckCreate, CheckCancel, and CheckCash,
## CryptoConditions
[CryptoConditions]: #cryptoconditions
| Amendment | CryptoConditions |
|:----------|:-----------|
| Amendment | CryptoConditions |
|:-------------|:-----------------|
| Amendment ID | 1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -123,10 +128,10 @@ Although this amendment is enabled, it has no effect unless the [SusPay](#suspay
## CryptoConditionsSuite
[CryptoConditionsSuite]: #cryptoconditionssuite
| Amendment | CryptoConditionsSuite |
|:----------|:-----------|
| Amendment | CryptoConditionsSuite |
|:-------------|:----------------------|
| Amendment ID | 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 |
| Status | Obsolete |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -138,10 +143,10 @@ However, the amendment was added to `rippled` v0.60.0 before implementation was
## DeletableAccounts
[DeletableAccounts]: #deletableaccounts
| Amendment | DeletableAccounts |
|:----------|:-----------|
| Amendment | DeletableAccounts |
|:-------------|:------------------|
| Amendment ID | 30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -155,10 +160,10 @@ With this amendment, new accounts start with their `Sequence` numbers equal to t
## DepositAuth
[DepositAuth]: #depositauth
| Amendment | DepositAuth |
|:----------|:-----------|
| Amendment | DepositAuth |
|:-------------|:------------|
| Amendment ID | F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -172,12 +177,12 @@ Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where
## DepositPreauth
[DepositPreauthAmendment]: #depositpreauth
[DepositPreauth]: #depositpreauth
| Amendment | DepositPreauth |
|:----------|:-----------|
| Amendment | DepositPreauth |
|:-------------|:---------------|
| Amendment ID | 3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -190,13 +195,37 @@ Changes the behavior of cross-currency Payments from an account to itself when t
Also changes the OfferCreate transaction to return `tecEXPIRED` when trying to create an Offer whose expiration time is in the past. Without this amendment, an OfferCreate whose expiration time is in the past returns `tesSUCCESS` but does not create or execute an Offer.
## DisallowIncoming
[DisallowIncoming]: #disallowincoming
| Amendment | DisallowIncoming |
|:-------------|:-----------------|
| Amendment ID | 47C3002ABA31628447E8E9A8B315FAA935CE30183F9A9B86845E469CA2CDC3DF |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Provides options to categorically block incoming Checks, Payment Channels, NFTokenOffers, and trust lines from reaching your account. When an account has these options enabled, other accounts cannot create those types of objects with the account as the destination.
Adds 4 new AccountSet Flags and modifies the AccountSet transaction to allow enabling and disabling them:
- asfDisallowIncomingCheck
- asfDisallowIncomingPayChan
- asfDisallowIncomingNFTOffer
- asfDisallowIncomingTrustline
Changes transaction processing to check the status of those flags before creating the corresponding type of object. If the destination account has the flag enabled, the transaction fails with the error code `tecNO_PERMISSION`.
Without this amendment, any account can create these objects with any object as the destination; while this is usually harmless, it can block an account from later being deleted, and may also be used as part of scams.
## EnforceInvariants
[EnforceInvariants]: #enforceinvariants
| Amendment | EnforceInvariants |
|:----------|:-----------|
| Amendment | EnforceInvariants |
|:-------------|:------------------|
| Amendment ID | DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -216,10 +245,10 @@ Examples of invariant checks:
## Escrow
[Escrow]: #escrow
| Amendment | Escrow |
|:----------|:-----------|
| Amendment | Escrow |
|:-------------|:-------|
| Amendment ID | 07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -231,10 +260,10 @@ Provides "suspended payments" for XRP for escrow within the XRP Ledger, includin
## ExpandedSignerList
[ExpandedSignerList]: #expandedsignerlist
| Amendment | ExpandedSignerList |
|:----------|:-----------|
| Amendment | ExpandedSignerList |
|:-------------|:-------------------|
| Amendment ID | B2A4DB846F0891BF2C76AB2F2ACC8F5B4EC64437135C6E56F3F859DE5FFD5856 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -248,10 +277,10 @@ With this amendment, the maximum [SignerList object][] size is 32 entries. Addit
## FeeEscalation
[FeeEscalation]: #feeescalation
| Amendment | FeeEscalation |
|:----------|:-----------|
| Amendment | FeeEscalation |
|:-------------|:--------------|
| Amendment ID | 42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -271,10 +300,10 @@ A transaction remains in the queue until one of the following happens:
## fix1201
[fix1201]: #fix1201
| Amendment | fix1201 |
|:----------|:-----------|
| Amendment | fix1201 |
|:-------------|:--------|
| Amendment ID | B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -286,10 +315,10 @@ With this amendment enabled, an [AccountSet][] transaction that attempts to set
## fix1368
[fix1368]: #fix1368
| Amendment | fix1368 |
|:----------|:-----------|
| Amendment | fix1368 |
|:-------------|:--------|
| Amendment ID | E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -299,10 +328,10 @@ Fixes a minor bug in transaction processing that causes some payments to fail wh
## fix1373
[fix1373]: #fix1373
| Amendment | fix1373 |
|:----------|:-----------|
| Amendment | fix1373 |
|:-------------|:--------|
| Amendment ID | 42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -314,10 +343,10 @@ The fix1373 amendment corrects the issue so that the paths are properly prepared
## fix1512
[fix1512]: #fix1512
| Amendment | fix1512 |
|:----------|:-----------|
| Amendment | fix1512 |
|:-------------|:--------|
| Amendment ID | 6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -329,10 +358,10 @@ With this amendment, the transactions fail with a more appropriate result code,
## fix1513
[fix1513]: #fix1513
| Amendment | fix1513 |
|:----------|:-----------|
| Amendment | fix1513 |
|:-------------|:--------|
| Amendment ID | 67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -344,10 +373,10 @@ With this amendment, the new `STAmountCalcSwitchovers` code applies, which may c
## fix1515
[fix1515]: #fix1515
| Amendment | fix1515 |
|:----------|:-----------|
| Amendment | fix1515 |
|:-------------|:--------|
| Amendment ID | 5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -363,10 +392,10 @@ In both cases, transaction processing can still complete by using liquidity from
## fix1523
[fix1523]: #fix1523
| Amendment | fix1523 |
|:----------|:-----------|
| Amendment | fix1523 |
|:-------------|:--------|
| Amendment ID | B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -378,10 +407,10 @@ With this amendment, new escrows are added to the [owner directories](directoryn
## fix1528
[fix1528]: #fix1528
| Amendment | fix1528 |
|:----------|:-----------|
| Amendment | fix1528 |
|:-------------|:--------|
| Amendment ID | 1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -393,10 +422,10 @@ This amendment changes how validators negotiate the close time of the consensus
## fix1543
[fix1543]: #fix1543
| Amendment | fix1543 |
|:----------|:-----------|
| Amendment | fix1543 |
|:-------------|:--------|
| Amendment ID | CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -413,10 +442,10 @@ The affected transaction types are:
## fix1571
[fix1571]: #fix1571
| Amendment | fix1571 |
|:----------|:-----------|
| Amendment | fix1571 |
|:-------------|:--------|
| Amendment ID | 7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -429,10 +458,10 @@ Changes Escrow to fix the following issues:
## fix1578
[fix1578]: #fix1578
| Amendment | fix1578 |
|:----------|:-----------|
| Amendment | fix1578 |
|:-------------|:--------|
| Amendment ID | FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -445,10 +474,10 @@ Changes the result codes returned by two transaction types:
## fix1623
[fix1623]: #fix1623
| Amendment | fix1623 |
|:----------|:-----------|
| Amendment | fix1623 |
|:-------------|:--------|
| Amendment ID | 58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -462,10 +491,10 @@ The fix1623 amendment has no effect on [CheckCash transactions][] for a fixed am
## fix1781
[fix1781]: #fix1781
| Amendment | fix1781 |
|:----------|:-----------|
| Amendment | fix1781 |
|:-------------|:--------|
| Amendment ID | 25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -479,10 +508,10 @@ With this amendment, those payments fail with the [`temBAD_PATH_LOOP` result cod
## fixAmendmentMajorityCalc
[fixAmendmentMajorityCalc]: #fixamendmentmajoritycalc
| Amendment | fixAmendmentMajorityCalc |
|:----------|:-----------|
| Amendment | fixAmendmentMajorityCalc |
|:-------------|:-------------------------|
| Amendment ID | 4F46DF03559967AC60F2EB272FEFE3928A7594A45FF774B87A7E540DB0F8F068 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -494,10 +523,10 @@ Without this amendment, the minimum threshold for amendment activation is any va
## fixCheckThreading
[fixCheckThreading]: #fixcheckthreading
| Amendment | fixCheckThreading |
|:----------|:-----------|
| Amendment | fixCheckThreading |
|:-------------|:------------------|
| Amendment ID | 8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -509,10 +538,10 @@ Without this amendment, Checks transactions ([CheckCreate][], [CheckCash][], and
## fixMasterKeyAsRegularKey
[fixMasterKeyAsRegularKey]: #fixmasterkeyasregularkey
| Amendment | fixMasterKeyAsRegularKey |
|:----------|:-----------|
| Amendment | fixMasterKeyAsRegularKey |
|:-------------|:-------------------------|
| Amendment ID | C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -526,10 +555,10 @@ With this amendment enabled, a SetRegularKey transaction cannot set the regular
## fixNFTokenDirV1
[fixNFTokenDirV1]: #fixnftokendirv1
| Amendment | fixNFTokenDirV1 |
|:----------|:-----------|
| Amendment | fixNFTokenDirV1 |
|:-------------|:----------------|
| Amendment ID | 0285B7E5E08E1A8E4C15636F0591D87F73CB6A7B6452A932AD72BBC8E5D1CBE3 |
| Status | Obsolete |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -541,10 +570,10 @@ This amendment has no effect unless the [NonFungibleTokensV1][] amendment is ena
## fixNFTokenNegOffer
[fixNFTokenNegOffer]: #fixnftokennegoffer
| Amendment | fixNFTokenNegOffer |
|:----------|:-----------|
| Amendment | fixNFTokenNegOffer |
|:-------------|:-------------------|
| Amendment ID | 36799EA497B1369B170805C078AEFE6188345F9B3E324C21E9CA3FF574E3C3D6 |
| Status | Open for Voting |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -553,13 +582,54 @@ This amendment fixes a bug in the [NonFungibleTokensV1][] amendment code where N
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. This amendment is obsolete because its effects are included as part of [NonFungibleTokensV1_1][].
## fixNonFungibleTokensV1_2
[fixNonFungibleTokensV1_2]: #fixnonfungibletokensv1_2
| Amendment | fixNonFungibleTokensV1_2 |
|:-------------|:-------------------------|
| Amendment ID | 73761231F7F3D94EC3D8C63D91BDD0D89045C6F71B917D1925C01253515A6669 |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Amendment `fixNonFungibleTokensV1_2` is a combination of bug fixes that have been individually merged into feature/nft-fixes through the pull request process:
**Fix Unburnable NFT**
Currently, an NFT cannot be burned when it has over 500 offers. To remove this restriction, this change deletes exactly 500 offers upon burning the NFT, leaving any remaining offers untouched. This addresses a concern where the issuer account cannot burn an NFT that has enabled the `lsfBurnable` flag, due to the exceeding number of offers.
See [PR 4346](https://github.com/XRPLF/rippled/pull/4346).
**Fix 3 Issues Around NFToken Offer Acceptance**
Issue 1: Resolve situation where an account is unable to broker a deal due to an erroneous insufficient funds condition.
Issue 2: Resolve situation where a buyer has insufficient funds to cover a transfer fee on the account.
Issue 3: Enable currency issuers to buy and sell NFTs using their own currency.
See [PR 4380](https://github.com/XRPLF/rippled/pull/4380).
**Prevent Brokered Sale of NFToken to Owner (fix #4374)**
This fix prevents a broker from selling an NFT to the account that already owns the token.
See [Issue 4374](https://github.com/XRPLF/rippled/issues/4374).
**Only allow the destination to settle an NFT offer through brokerage (fix #4373)**
If you set a destination on an NFT offer, only that destination can settle through brokerage (fix #4373).
See [Issue 4373](https://github.com/XRPLF/rippled/issues/4373).
## fixPayChanRecipientOwnerDir
[fixPayChanRecipientOwnerDir]: #fixpaychanrecipientownerdir
| Amendment | fixPayChanRecipientOwnerDir |
|:----------|:-----------|
| Amendment | fixPayChanRecipientOwnerDir |
|:-------------|:----------------------------|
| Amendment ID | 621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -571,10 +641,10 @@ This change prevents accounts from being deleted if they are the recipient for o
## fixQualityUpperBound
[fixQualityUpperBound]: #fixqualityupperbound
| Amendment | fixQualityUpperBound |
|:----------|:-----------|
| Amendment | fixQualityUpperBound |
|:-------------|:---------------------|
| Amendment ID | 89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -586,10 +656,10 @@ This amendment has no known impact on transaction processing.
## fixRemoveNFTokenAutoTrustLine
[fixRemoveNFTokenAutoTrustLine]: #fixremovenftokenautotrustline
| Amendment | fixRemoveNFTokenAutoTrustLine |
|:----------|:-----------|
| Amendment | fixRemoveNFTokenAutoTrustLine |
|:-------------|:------------------------------|
| Amendment ID | DF8B4536989BDACE3F934F29423848B9F1D76D09BE6A1FCFE7E7F06AA26ABEAD |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -605,10 +675,10 @@ This amendment has no effect unless either [NonFungibleTokensV1][] or [NonFungib
## fixRmSmallIncreasedQOffers
[fixRmSmallIncreasedQOffers]: #fixrmsmallincreasedqoffers
| Amendment | fixRmSmallIncreasedQOffers |
|:----------|:-----------|
| Amendment | fixRmSmallIncreasedQOffers |
|:-------------|:---------------------------|
| Amendment ID | B6B3EEDC0267AB50491FDC450A398AF30DBCD977CECED8BEF2499CAB5DAC19E2 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -622,10 +692,10 @@ With this amendment, payments and trades can remove these types of Offers the sa
## fixSTAmountCanonicalize
[fixSTAmountCanonicalize]: #fixstamountcanonicalize
| Amendment | fixSTAmountCanonicalize |
|:----------|:-----------|
| Amendment | fixSTAmountCanonicalize |
|:-------------|:------------------------|
| Amendment ID | 452F5906C46D46F407883344BFDD90E672B672C5E9943DB4891E3A34FEEEB9DB |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -635,10 +705,10 @@ Fixes an edge case in [deserializing](serialization.html) Amount-type fields. Wi
## fixTakerDryOfferRemoval
[fixTakerDryOfferRemoval]: #fixtakerdryofferremoval
| Amendment | fixTakerDryOfferRemoval |
|:----------|:-----------|
| Amendment | fixTakerDryOfferRemoval |
|:-------------|:------------------------|
| Amendment ID | 2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -652,10 +722,10 @@ With this amendment enabled, the XRP Ledger removes these dry offers when they'r
## fixTrustLinesToSelf
[fixTrustLinesToSelf]: #fixtrustlinestoself
| Amendment | fixTrustLinesToSelf |
|:----------|:-----------|
| Amendment | fixTrustLinesToSelf |
|:-------------|:--------------------|
| Amendment ID | F1ED6B4A411D8B872E65B9DCB4C8B100375B0DD3D62D07192E011D6D7F339013 |
| Status | In Development |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -664,13 +734,28 @@ This amendment removes two trust lines from an account to itself that were creat
On test networks that do not have these trust lines, the amendment has no effect.
## fixUniversalNumber
[fixUniversalNumber]: #fixuniversalnumber
| Amendment | fixUniversalNumber |
|:-------------|:-------------------|
| Amendment ID | 2E2FB9CF8A44EB80F4694D38AADAE9B8B7ADAFD2F092E10068E61C98C4F092B0 |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Simplifies and unifies the code for decimal floating point math. In some cases, this provides slightly better accuracy than the previous code, resulting in calculations whose least significant digits are different than when calculated with the previous code. The different results may cause other edge case differences where precise calculations are used, such as ranking of Offers or processing of payments that use several different paths.
Without this amendment, the code continues to use separate calculations for `STAmount` and `IOUAmount` objects, and [Automated Market Maker (XLS-30d)](https://github.com/XRPLF/XRPL-Standards/discussions/78) uses a third class for calculations.
## Flow
[Flow]: #flow
| Amendment | Flow |
|:----------|:-----------|
| Amendment | Flow |
|:-------------|:-----|
| Amendment ID | 740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -682,10 +767,10 @@ The Flow Engine also makes it easier to improve and expand the payment engine wi
## FlowCross
[FlowCross]: #flowcross
| Amendment | FlowCross |
|:----------|:-----------|
| Amendment | FlowCross |
|:-------------|:----------|
| Amendment ID | 3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -699,10 +784,10 @@ Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange.
## FlowSortStrands
[FlowSortStrands]: #flowsortstrands
| Amendment | FlowSortStrands |
|:----------|:-----------|
| Amendment | FlowSortStrands |
|:-------------|:----------------|
| Amendment ID | AF8DF7465C338AE64B1E937D6C8DA138C0D63AD5134A68792BBBE1F63356C422 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -714,10 +799,10 @@ Without this change, the engine simulates a payment through each possible path t
## FlowV2
[FlowV2]: #flowv2
| Amendment | FlowV2 |
|:----------|:-----------|
| Amendment | FlowV2 |
|:-------------|:-------|
| Amendment ID | 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 |
| Status | Vetoed |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
This is a previous version of the [Flow](#flow) amendment. It was [rejected due to a bug](https://xrpl.org/blog/2016/flowv2-vetoed.html) and removed in version 0.33.0.
@@ -726,10 +811,10 @@ This is a previous version of the [Flow](#flow) amendment. It was [rejected due
## HardenedValidations
[HardenedValidations]: #hardenedvalidations
| Amendment | HardenedValidations |
|:----------|:-----------|
| Amendment | HardenedValidations |
|:-------------|:--------------------|
| Amendment ID | 1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -737,13 +822,28 @@ Allows validators to include a new optional field in their validations to attest
the latest ledger that the validator considers to be fully validated. The consensus process can use this information to increase the robustness of consensus.
## ImmediateOfferKilled
[ImmediateOfferKilled]: #immediateofferkilled
| Amendment | ImmediateOfferKilled |
|:-------------|:---------------------|
| Amendment ID | 75A7E01C505DD5A179DFE3E000A9B6F1EDDEB55A12F95579A23E15B15DC8BE5A |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Changes OfferCreate transactions so that if an Offer uses `tfImmediateOrCancel` and transaction processing kills the Offer without moving any funds, the transaction uses the result code `tecKILLED` instead of `tesSUCCESS`. If the Offer exchanges any amount of funds, even a small amount, the transaction still uses `tesSUCCESS`. There are no other changes to the processing of the transaction (for example, in terms of whether it cleans up expired and unfunded Offers that were encountered in the ledger during transaction processing).
Without this amendment, "Immediate or Cancel" Offers that failed to move any funds returned a `tesSUCCESS` result code, which could be confusing because the transaction effectively did nothing.
## MultiSign
[MultiSign]: #multisign
| Amendment | MultiSign |
|:----------|:-----------|
| Amendment | MultiSign |
|:-------------|:----------|
| Amendment ID | 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -767,10 +867,10 @@ An address with a SignerList can disable the master key even if a regular key is
## MultiSignReserve
[MultiSignReserve]: #multisignreserve
| Amendment | MultiSignReserve |
|:----------|:-----------|
| Amendment | MultiSignReserve |
|:-------------|:-----------------|
| Amendment ID | 586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -784,10 +884,10 @@ With this amendment enabled, the owner reserve for a new SignerList is 5 XRP, re
## NegativeUNL
[NegativeUNL]: #negativeunl
| Amendment | NegativeUNL |
|:----------|:-----------|
| Amendment | NegativeUNL |
|:-------------|:------------|
| Amendment ID | B4E4F5D2D6FB84DF7399960A732309C9FD530EAE5941838160042833625A6076 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -797,10 +897,10 @@ Implements a "Negative UNL" system, where the network can track which validators
## NonFungibleTokensV1
[NonFungibleTokensV1]: #nonfungibletokensv1
| Amendment | NonFungibleTokensV1 |
|:----------|:-----------|
| Amendment | NonFungibleTokensV1 |
|:-------------|:--------------------|
| Amendment ID | 3C43D9A973AA4443EF3FC38E42DD306160FBFFDAB901CD8BAA15D09F2597EB87 |
| Status | Obsolete |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -829,10 +929,10 @@ It also modifies the [AccountSet transaction][] type to allow you to set the `NF
## NonFungibleTokensV1_1
[NonFungibleTokensV1_1]: #nonfungibletokensv1_1
| Amendment | NonFungibleTokensV1_1 |
|:----------|:-----------|
| Amendment | NonFungibleTokensV1_1 |
|:-------------|:----------------------|
| Amendment ID | 32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -852,10 +952,10 @@ It has no other effects.
## OwnerPaysFee
[OwnerPaysFee]: #ownerpaysfee
| Amendment | OwnerPaysFee |
|:----------|:-----------|
| Amendment | OwnerPaysFee |
|:-------------|:-------------|
| Amendment ID | 9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871 |
| Status | In Development |
| Status | In Development |
| Default Vote (Latest stable release) | N/A |
| Pre-amendment functionality retired? | No |
@@ -869,10 +969,10 @@ This Amendment requires the [Flow Amendment](#flow) to be enabled.
## PayChan
[PayChan]: #paychan
| Amendment | PayChan |
|:----------|:-----------|
| Amendment | PayChan |
|:-------------|:--------|
| Amendment ID | 08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -886,10 +986,10 @@ For more information, see the [Payment Channels Tutorial](use-payment-channels.h
## RequireFullyCanonicalSig
[RequireFullyCanonicalSig]: #requirefullycanonicalsig
| Amendment | RequireFullyCanonicalSig |
|:----------|:-----------|
| Amendment | RequireFullyCanonicalSig |
|:-------------|:-------------------------|
| Amendment ID | 00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -905,10 +1005,10 @@ For more information, see [`rippled` issue #3042](https://github.com/ripple/ripp
## SHAMapV2
[SHAMapV2]: #shamapv2
| Amendment | SHAMapV2 |
|:----------|:-----------|
| Amendment | SHAMapV2 |
|:-------------|:---------|
| Amendment ID | C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3 |
| Status | Vetoed |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
Changes the hash tree structure that `rippled` uses to represent a ledger. The new structure is more compact and efficient than the previous version. This affects how ledger hashes are calculated, but has no other user-facing consequences.
@@ -919,10 +1019,10 @@ When this amendment is activated, the XRP Ledger will undergo a brief scheduled
## SortedDirectories
[SortedDirectories]: #sorteddirectories
| Amendment | SortedDirectories |
|:----------|:-----------|
| Amendment | SortedDirectories |
|:-------------|:------------------|
| Amendment ID | CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -934,10 +1034,10 @@ Sorts the entries in [DirectoryNode ledger objects](directorynode.html) and fixe
## SusPay
[SusPay]: #suspay
| Amendment | SusPay |
|:----------|:-----------|
| Amendment | SusPay |
|:-------------|:-------|
| Amendment ID | DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 |
| Status | Vetoed |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
This amendment was replaced by the [Escrow](escrow-object.html) amendment.
@@ -946,10 +1046,10 @@ This amendment was replaced by the [Escrow](escrow-object.html) amendment.
## TicketBatch
[TicketBatch]: #ticketbatch
| Amendment | TicketBatch |
|:----------|:-----------|
| Amendment | TicketBatch |
|:-------------|:------------|
| Amendment ID | 955DF3FA5891195A9DAEFA1DDC6BB244B545DDE1BAA84CBB25D5F12A8DA68A0C |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -961,10 +1061,10 @@ Standards Draft: [XLS-13d](https://github.com/XRPLF/XRPL-Standards/issues/16). <
## Tickets
[Tickets]: #tickets
| Amendment | Tickets |
|:----------|:-----------|
| Amendment | Tickets |
|:-------------|:--------|
| Amendment ID | C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 |
| Status | Vetoed |
| Status | Vetoed |
| Pre-amendment functionality retired? | No |
This amendment was replaced by the [TicketBatch][] amendment.
@@ -973,10 +1073,10 @@ This amendment was replaced by the [TicketBatch][] amendment.
## TickSize
[TickSize]: #ticksize
| Amendment | TickSize |
|:----------|:-----------|
| Amendment | TickSize |
|:-------------|:---------|
| Amendment ID | 532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164 |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -988,10 +1088,10 @@ Introduces a `TickSize` field to accounts, which can be set with the [AccountSet
## TrustSetAuth
[TrustSetAuth]: #trustsetauth
| Amendment | TrustSetAuth |
|:----------|:-----------|
| Amendment | TrustSetAuth |
|:-------------|:-------------|
| Amendment ID | 6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC |
| Status | Enabled |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
@@ -1000,6 +1100,25 @@ Allows pre-authorization of accounting relationships (zero-balance trust lines)
With this amendment enabled, a `TrustSet` transaction with [`tfSetfAuth` enabled](trustset.html#trustset-flags) can create a new [`RippleState` ledger object](ripplestate.html) 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](ripplestate.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`](accountroot.html#accountroot-flags) by sending an [AccountSet transaction](accountset.html) with the [`asfRequireAuth` flag enabled](accountset.html#accountset-flags).
## XRPFees
[XRPFees]: #xrpfees
| Amendment | XRPFees |
|:-------------|:--------|
| Amendment ID | 93E516234E35E08CA689FA33A6D38E103881F8DCB53023F728C307AA89D515A7 |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Simplifies transaction cost calculations to use XRP directly rather than calculating indirectly in "fee units" and translating the results to XRP. Updates all instances of "fee units" in the protocol and ledger data to be drops of XRP instead, including:
- Updates the Fee Voting protocol to use drops of XRP
- Updates the FeeSettings ledger entry type. Replaces `BaseFee`, `ReferenceFeeUnits`, `ReserveBase`, and `ReserveIncrement` fields with `BaseFeeDrops`, `ReserveBaseDrops`, and `ReserveIncrementDrops`.
- Updates the SetFee transaction type. Replaces `BaseFee`, `ReferenceFeeUnits`, `ReserveBase`, `ReserveIncrement` fields with `BaseFeeDrops`, `ReserveBaseDrops`, `ReserveIncrementDrops`.
Without this amendment, the format of the transaction and ledger entry are the same.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

View File

@@ -22,7 +22,7 @@ As a cryptographic system, the owners of XRP Ledger accounts are identified by _
### The Double Spend Problem
The "double spend" problem is a fundamental challenge to operating any sort of payment system. The problem comes from the requirement that when money is spent in one place, it can't also be spent in another place. More generally, the problem occurs when you have any two transactions such that either one is valid but not both together.
The "double spend" problem is a fundamental challenge to any digital payment system. The problem comes from the requirement that when money is spent in one place, it can't also be spent in another place. More generally, the problem occurs when you have any two transactions such that either one is valid but not both together.
Suppose Alice, Bob, and Charlie are using a payment system, and Alice has a balance of $10. For the payment system to be useful, Alice must be able to send her $10 to Bob, or to Charlie. However, if Alice tries to send $10 to Bob and also send $10 to Charlie at the same time, that's where the double spend problem comes in.

View File

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

View File

@@ -66,8 +66,6 @@ As a decentralized system, the XRP Ledger does not have any information on the a
- [Offer object][] for the data structure of passive Offers in the ledger
- [DirectoryNode object][] for the data structure that tracks all the Offers for a given currency pair and exchange rate.
<!-- NOTE: There aren't really any tutorials for using the DEX. When there are, add them here. -->
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

View File

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

View File

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

View File

@@ -1,5 +1,6 @@
---
parent: freezes.html
html: common-misconceptions-about-freezes.html
blurb: Clarify common misunderstandings about the XRP Ledger's freeze feature.
labels:
- Tokens

View File

@@ -1,16 +1,16 @@
---
html: offer.html
parent: ledger-object-types.html
blurb: 通貨取引を行うためのオーダーです。
blurb: 通貨取引を行う注文
labels:
- 分散型取引所
---
# Offer
[[ソース]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57 "Source")
`Offer`オブジェクトタイプは、XRP Ledgerの分散型取引所での(従来は _オーダー_ と呼ばれていた)通貨取引オファーを記述します。[OfferCreateトランザクション][]は、レジャーにすでに含まれている他のオファーを消費することでは完全にオファーを実行できない場合に、レジャー`Offer`オブジェクトを作成します。
台帳の`Offer`項目は、XRP Ledgerの[分散型取引所](decentralized-exchange.html)で通貨を交換する[オファー](offers.html)を表しています。(金融ではより伝統的に _オーダー_ として知られています。[OfferCreateトランザクション][]は台帳にある他のOfferを全額約定できない場合、台帳`Offer`項目を作成します。
オファーがレジャーに存在している間に、ネットワークの他のアクティビティによってオファーが資金化されないことあります。ただし`rippled`ではトランザクション処理において資金化されないオファーはすべて自動的に取り除かれます(レジャー状態を変更できるのはトランザクションだけであることから、これはトランザクション処理で _のみ_ 行われます)。
オファーがネットワークの他の活動によって資金不足になることありますが、元帳には残ります。トランザクション処理する際、ネットワークはトランザクションが見つけた資金不足のオファーを自動的に削除します。( _トランザクションのみ_ が台帳の状態を変更できるため、削除が行われないと資金不足のオファーが残ってしまいます。)
詳細は、[オファー](offers.html)を参照してください。
@@ -41,31 +41,31 @@ labels:
`Offer`オブジェクトのフィールドを次に示します。
| 名前 | JSONの型 | [内部の型][] | 説明 |
|-------------------|-----------|---------------|-------------|
| `LedgerEntryType` | 文字列 | UInt16 | 値が`0x006F`(文字列`Offer`にマッピング)の場合は、このオブジェクトが通貨取引オーダーを記述することを示します。 |
| `Flags` | 数値 | UInt32 | このオファーに対して有効になっているブール値フラグのビットマップ。 |
| `Account` | 文字列 | AccountID | このオファーを所有するアカウントのアドレス。 |
| `Sequence` | 数値 | UInt32 | `Offer`オブジェクトを作成した[OfferCreate][]トランザクションの`Sequence` 値。`Account`とこのフィールドの組み合わせによってこのオファーが識別されます。 |
| `TakerPays` | 文字列またはオブジェクト | Amount | オファー作成者が要求する残額と通貨の種類。 |
| `TakerGets` | 文字列またはオブジェクト | Amount | オファー作成者が提供する残額と通貨の種類。 |
| `BookDirectory` | 文字列 | Hash256 | このオファーにリンクしている[オファーディレクトリー](directorynode.html)のID。 |
| `BookNode` | 文字列 | UInt64 | オファーディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。 |
| `OwnerNode` | 文字列 | UInt64 | 所有者ディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒントです。**注記:** このオファーには、オファーを含む所有者ディレクトリーへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `Expiration` | 数値 | UInt32 | (省略可)このオファーが資金化されなかったとみなされる時刻を示します。詳細は、[時間の指定][]を参照してください。 |
| 名前 | JSONの型 | [内部の型][] | 必須? | 説明 |
|-------------------|-----------|-----------|------|-------|
| `Account` | 文字列 | AccountID | はい | このオファーを所有するアカウントのアドレス。 |
| `BookDirectory` | 文字列 | Hash256 | はい | このオファーにリンクしている[オファーディレクトリー](directorynode.html)のID。 |
| `BookNode` | 文字列 | UInt64 | はい | Offerディレクトリが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒント。 |
| `Expiration` | 数値 | UInt32 | いいえ | (省略可)このオファーが資金不足とみなされる時刻。詳細は、[時間の指定][]を参照してください。 |
| `Flags` | 数値 | UInt32 | はい | このオファーに対して有効になっているブール値フラグのビットマップ。 |
| `LedgerEntryType` | 文字列 | UInt16 | はい | 値が`0x006F`(文字列`Offer`にマッピング)の場合は、このオブジェクトが通貨取引オーダーを記述することを示す。 |
| `OwnerNode` | 文字列 | UInt64 | はい | 所有者ディレクトリーが複数ページで構成されている場合に、このオブジェクトにリンクしているページを示すヒント。**注記:** このオファーには、オファーを含む所有者ディレクトリーへの直接リンクは含まれていません。これは、その値を`Account`から取得できるためです。 |
| `PreviousTxnID` | 文字列 | Hash256 | はい | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
| `Sequence` | 数値 | UInt32 | はい | `Offer`オブジェクトを作成した[OfferCreate][]トランザクションの`Sequence`値。`Account`とこのフィールドの組み合わせによってこのオファーが識別されます。 |
| `PreviousTxnLgrSeq` | 数値 | UInt32 | はい | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
| `TakerPays` | 文字列またはオブジェクト | Amount | はい | オファー作成者が要求する残額と通貨の種類。 |
| `TakerGets` | 文字列またはオブジェクト | Amount | はい | オファー作成者が提供する残額と通貨の種類。 |
## Offerのフラグ
[OfferCreateトランザクション][]でOfferオブジェクトを作成するときに有効化または無効化できる各種オプションがあります。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 _lsf_ で始まる名前が付いています。
[OfferCreateトランザクション][]でOfferオブジェクトを作成するときに有効化または無効化できる各種オプションがあります。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 **`lsf`** で始まる名前が付いています。
`Offer` オブジェクトには以下のフラグ値を指定できます。
`Offer`オブジェクトには以下のフラグ値を指定できます。
| フラグ名 | 16進値 | 10進値 | 説明 | 対応する[OfferCreateフラグ](offercreate.html#offercreateフラグ) |
| フラグ名 | 16進値 | 10進値 | 対応する[OfferCreateフラグ](offercreate.html#offercreateフラグ) | 説明 |
|-----------|-----------|---------------|-------------|------------------------|
| lsfPassive | 0x00010000 | 65536 | オブジェクトはパッシブオファーとして配置されました。レジャー内のオブジェクトには影響しません。 | tfPassive |
| lsfSell | 0x00020000 | 131072 | オブジェクトはセルオファーとして配置されました。レジャー内のオブジェクトの影響ありません。これは、要求したレートよりも良いレートを得た場合にのみtfSellが関連するためです。この状況はオブジェクトがレジャーに記録された後では発生することはありません。 | tfSell |
| lsfPassive | `0x00010000` | 65536 | tfPassive | オブジェクトはパッシブオファーとして発注されています。レジャー内のオブジェクトには影響しません。 |
| lsfSell | `0x00020000` | 131072 | tfSell | オブジェクトは売却オファーとして発注されています。これは台帳にあるオブジェクトには何の影響ありません (`tfSell`は指定したレートよりも良いレートが存在する場合にのみ意味を持ち、台帳にこのフラグを持ったオブジェクトが入ることはありません。)。 |
## オファーIDのフォーマット
@@ -73,7 +73,9 @@ labels:
* Offerスペースキー`0x006F`
* オファーを行うアカウントのAccountID
* オファーを作成した[OfferCreateトランザクション][]のシーケンス番号
* オファーを作成した[OfferCreateトランザクション][]のシーケンス番号
OfferCreateトランザクションが[Ticket](tickets.html)を使用した場合、代わりに`TicketSequence`値を使用します。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

View File

@@ -55,7 +55,7 @@ Besides errors that can occur for all transactions, {{currentpage.name}} transac
| `tecDST_TAG_NEEDED` | Occurs if the `Destination` account requires a [destination tag](source-and-destination-tags.html), but the `DestinationTag` field was not provided. |
| `tecNO_DST` | Occurs if the `Destination` account is not a funded account in the ledger. |
| `tecNO_PERMISSION` | Occurs if the `Destination` account requires [deposit authorization](depositauth.html) and the sender is not preauthorized. |
| `tecTOO_SOON` | Occurs if the sender's `Sequence` number is too high. The transaction's `Sequence` number plus 256 must be less than the current [Ledger Index][]. |
| `tecTOO_SOON` | Occurs if the sender's `Sequence` number is too high. The transaction's `Sequence` number plus 256 must be less than the current [Ledger Index][]. This prevents replay of old transactions if this account is resurrected after it is deleted. |
| `tecHAS_OBLIGATIONS` | Occurs if the account to be deleted is connected to objects that cannot be deleted in the ledger. (This includes objects created by other accounts, such as [escrows](escrow.html) and for example [NFT's minted](nftokenmint.html), [even if owned by another account](https://github.com/XRPLF/rippled/blob/develop/src/ripple/app/tx/impl/DeleteAccount.cpp#L197).) |
| `tefTOO_BIG` | Occurs if the sending account is linked to more than 1000 objects in the ledger. The transaction could succeed on retry if some of those objects were deleted separately first. |

View File

@@ -44,8 +44,8 @@ The mode in which the transaction operates depends on the presence of the `NFTok
| `NFTokenSellOffer` | `NFTokenBuyOffer` | Mode |
|:-------------------|:------------------|:---------|
| ✔️ | ✔️ | Brokered |
| ✔️ | X | Direct |
| X | ✔️ | Direct |
| ✔️ | | Direct |
| | ✔️ | Direct |
If neither of those fields is specified, the transaction is malformed and produces a `tem` class error.

View File

@@ -840,10 +840,12 @@ pages:
targets:
- ja
# TODO: translate
- md: concepts/tokens/common-misconceptions-about-freezes.md
targets:
- en
- md: concepts/tokens/common-misconceptions-about-freezes.ja.md
targets:
- ja
- md: concepts/tokens/rippling.md
@@ -887,12 +889,10 @@ pages:
- ja
- md: concepts/decentralized-exchange/decentralized-exchange.md
targets:
- en
- name: 分散型取引所
html: decentralized-exchange.html
parent: concepts.html
template: pagetype-category.html.jinja
blurb: XRP Ledgerには多機能な取引所が含まれており、この取引所を利用してユーザーは発行済み通貨をXRPに、あるいはXRPを発行済み通貨に交換できます。
- md: concepts/decentralized-exchange/decentralized-exchange.ja.md
targets:
- ja