Known Amendments

The following is a comprehensive list of all known amendments and their status on the production XAG Ledger:

Name	Introduced	Status
HardenedValidations	v1.6.0-b5
fix1781	v1.6.0-b1
CryptoConditionsSuite	TBD
OwnerPaysFee	TBD
Tickets	TBD
fixQualityUpperBound	v1.5.0
RequireFullyCanonicalSig	v1.5.0
FlowCross	v0.70.0
Checks	v0.90.0
DeletableAccounts	v1.4.0
fixCheckThreading	v1.4.0
fixPayChanRecipientOwnerDir	v1.4.0
fixMasterKeyAsRegularKey	v1.3.1
MultiSignReserve	v1.2.0
fixTakerDryOfferRemoval	v1.2.0
fix1578	v1.2.0
DepositPreauth	v1.1.0
fix1515	v1.1.0
fix1543	v1.0.0
fix1623	v1.0.0
fix1571	v1.0.0
DepositAuth	v0.90.0
fix1513	v0.90.0
fix1201	v0.80.0
fix1512	v0.80.0
fix1523	v0.80.0
fix1528	v0.80.0
SortedDirectories	v0.80.0
EnforceInvariants	v0.70.0
fix1373	v0.70.0
Escrow	v0.60.0
fix1368	v0.60.0
PayChan	v0.33.0
TickSize	v0.50.0
CryptoConditions	v0.50.0
Flow	v0.33.0
TrustSetAuth	v0.30.0
MultiSign	v0.31.0
FeeEscalation	v0.31.0
SHAMapV2	v0.32.1
FlowV2	v0.32.1
SusPay	v0.31.0

Note: In many cases, an incomplete version of the code for an amendment is present in previous versions of the software. The "Introduced" version in the table above is the first stable version. The value "TBD" indicates that the amendment is not yet considered stable.

Checks

Amendment ID	Status
157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1	Enabled

Introduces "Checks" to the XAG Ledger. Checks work similarly to personal paper checks. The sender signs a transaction to create a Check for a specific maximum amount and destination. Later, the destination can cash the Check to receive up to the specified amount. The actual movement of money only occurs when the Check is cashed, so cashing the Check may fail depending on the sender's current balance and the available liquidity. If cashing the Check fails, the Check object remains in the ledger so it may be successfully cashed later.

The sender or the receiver can cancel a Check at any time before it is cashed. A Check can also have an expiration time, after which it cannot be cashed, and anyone can cancel it.

Introduces three new transaction types: CheckCreate, CheckCancel, and CheckCash, and a new ledger object type, Check. Adds a new transaction result code, tecEXPIRED, which occurs when trying to create a Check whose expiration time is in the past.

This amendment 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.

CryptoConditions

Amendment ID	Status
1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146	Enabled

Although this amendment is enabled, it has no effect unless the SusPay amendment is also enabled. Ripple does not expect SusPay to become enabled. Instead, Ripple plans to incorporate crypto-conditions in the Escrow amendment.

CryptoConditionsSuite

Amendment ID	Status
86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90	In Development

Implements several types of crypto-conditions from the official crypto-conditions specification for use in EscrowCreate and EscrowFinish transactions. Without this amendment, only the PREIMAGE-SHA-256 type is supported.

Caution: This amendment is still in development . The version from rippled v0.60.0 to present does not implement the full functionality.

DeletableAccounts

Amendment ID	Status
30CD365592B8EE40489BA01AE2F7555CAC9C983145871DC82A42A31CF5BAE7D9	Enabled

Makes it possible to delete accounts.

Without this amendment, new accounts always start with their Sequence numbers at 1, and there is no way to remove accounts from the state data of the ledger.

With this amendment, new accounts start with their Sequence numbers equal to the Sequence number matching the index of the ledger in which the account is created. This change protects accounts that are deleted and later re-created from having their old transactions executed again.

DepositAuth

Amendment ID	Status
F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064	Enabled

Adds a new account flag, DepositAuth, which lets an account strictly reject any incoming money from transactions sent by other accounts. Businesses can use this flag to comply with strict regulations that require due diligence before receiving money from any source.

When an account enables this flag, Payment transactions fail if the account is the destination, regardless of whether the Payment would have delivered XAG or an issued currency. EscrowFinish and PaymentChannelClaim transactions fail if the account is the destination unless the destination account itself sends those transactions. If the Checks amendment is enabled, the account can receive XAG or issued currencies by sending CheckCash transactions.

As an exception, accounts with DepositAuth enabled can receive Payment transactions for small amounts of XAG (equal or less than the minimum account reserve) if their current XAG balance is below the account reserve.

Also fixes a bug in the EscrowCreate and PaymentChannelCreate transactions where they mistakenly enforced the DisallowXAG flag, which is meant to be a non-binding advisory flag. (By not enforcing DisallowXAG in the ledger itself an account can still receive the necessary XAG to meet its account reserve and pay transaction costs.)

DepositPreauth

Amendment ID	Status
3CBC5C4E630A1B82380295CDA84B32B49DD066602E74E39B85EF64137FA65194	Enabled

Provides users of deposit authorization with a way to preauthorize specific senders so those senders are allowed to send payments directly.

Adds a new transaction type, DepositPreauth for adding or removing preauthorization, and a DepositPreauth ledger object type for tracking preauthorizations from one account to another. Adds a JSON-RPC command, deposit_authorized, to query whether an account is authorized to send payments directly to another.

Also changes the behavior of cross-currency Payments from an account to itself when that account requires deposit authorization. Without this amendment, those payments always fail with the code tecNO_PERMISSION. With this amendment, those payments succeed as they would with Deposit Authorization disabled.

EnforceInvariants

Amendment ID	Status
DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF	Enabled

Adds sanity checks to transaction processing to ensure that certain conditions are always met. This provides an extra, independent layer of protection against bugs in transaction processing that could otherwise cause exploits and vulnerabilities in the XAG Ledger. Ripple expects to add more invariant checks in future versions of rippled without additional amendments.

Introduces two new transaction error codes, tecINVARIANT_FAILED and tefINVARIANT_FAILED. Changes transaction processing to add the new checks.

Examples of invariant checks:

The total amount of XAG destroyed by a transaction must match the transaction cost exactly.
XAG cannot be created.
AccountRoot objects in the ledger cannot be deleted unless DeletableAccounts is enabled. (See also: Deletion of Accounts.)
An object in the ledger cannot change its type. (The LedgerEntryType field is immutable.)
There cannot be a trust line for XAG.

Escrow

Amendment ID	Status
07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104	Enabled

Replaces the SusPay and CryptoConditions amendments.

Provides "suspended payments" for XAG for escrow within the XAG Ledger, including support for Interledger Protocol Crypto-Conditions . Creates a new ledger object type for suspended payments and new transaction types to create, execute, and cancel suspended payments.

FeeEscalation

Amendment ID	Status
42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE	Enabled

Changes the way the transaction cost applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost.

This amendment introduces a fixed-size transaction queue for transactions that were not able to be included in the previous consensus round. If the rippled servers in the consensus network are under heavy load, they queue the transactions with the lowest transaction cost for later ledgers. Each consensus round prioritizes transactions from the queue with the largest transaction cost (Fee value), and includes as many transactions as the consensus network can process. If the transaction queue is full, transactions drop from the queue entirely, starting with the ones that have the lowest transaction cost.

While the consensus network is under heavy load, legitimate users can pay a higher transaction cost to make sure their transactions get processed. The situation persists until the entire backlog of cheap transactions is processed or discarded.

A transaction remains in the queue until one of the following happens:

It gets applied to a validated ledger (regardless of success or failure)
It becomes invalid (for example, the LastLedgerSequence causes it to expire)
It gets dropped because there are too many transactions in the queue with a higher transaction cost.

fix1201

Amendment ID	Status
B4D44CC3111ADD964E846FC57760C8B50FFCD5A82C86A72756F6B058DDDF96AD	Enabled

Correctly implements a limit on transfer fees to a 100% fee, represented by a maximum TransferRate value of 2000000000. (A 100% fee in this case means you must send 2 units of the issued currency for every 1 unit you want to deliver.) Without the amendment, the effective limit is a TransferRate value of 2³²-1, for approximately a 329% fee.

With this amendment enabled, an AccountSet transaction that attempts to set TransferRate higher than 2000000000 fails with the result code temBAD_TRANSFER_RATE. Any existing TransferRate which was set to a higher value under the previous rules continues to apply at the higher rate.

fix1368

Amendment ID	Status
E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA	Enabled

Fixes a minor bug in transaction processing that causes some payments to fail when they should be valid. Specifically, during payment processing, some payment steps that are expected to produce a certain amount of currency may produce a microscopically different amount, due to a loss of precision related to floating-point number representation. When this occurs, those payments fail because they cannot deliver the exact amount intended. The fix1368 amendment corrects transaction processing so payments can no longer fail in this manner.

fix1373

Amendment ID	Status
42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC	Enabled

Fixes a minor bug in transaction processing that causes failures when trying to prepare certain payment paths for processing. As a result, payments could not use certain paths that should have been valid but were invalidly prepared. Without this amendment, those payments are forced to use less-preferable paths or may even fail.

The fix1373 amendment corrects the issue so that the paths are properly prepared and payments can use them. It also disables some inappropriate paths that are currently allowed, including paths whose steps include conflicting fields and paths that loop through the same object more than once.

fix1512

Amendment ID	Status
6C92211186613F9647A89DFFBAB8F94C99D4C7E956D495270789128569177DA1	Enabled

Fixes a bug in transaction processing that causes some invalid PaymentChannelClaim transactions to fail with the wrong error code. Without this amendment, the transactions have a tec-class result code despite not being included in a ledger and therefore not paying the transaction cost.

With this amendment, the transactions fail with a more appropriate result code, temBAD_AMOUNT, instead.

fix1513

Amendment ID	Status
67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172	Enabled

Fixes a bug that resulted in transaction processing not using new STAmountCalcSwitchovers code when the FeeEscalation amendment is enabled.

With this amendment, the new STAmountCalcSwitchovers code applies, which may cause slight changes to transaction processing due to calculation differences. Amounts may be rounded differently and offers may be executed in a different order as a result.

fix1515

Amendment ID	Status
5D08145F0A4983F23AFFFF514E83FAD355C5ABFBB6CAB76FB5BC8519FF5F33BE	Enabled

Changes how Payment transactions consume offers to remove a minor difference in how payment processing and offer processing consume liquidity. (Also affects how OfferCreate transactions are processed if FlowCross is enabled.)

Without the amendment, payment processing gives up on using particular order books if the transaction would consume over 2000 offers at the same exchange rate. In this case, the payment does not use the liquidity from those offers, and does not consider that order book's remaining liquidity when attempting to complete the payment.

With this amendment, if any transaction processes over 1000 offers at the same exchange rate, the transaction consumes the liquidity from the first 1000 offers, then does not consider that order book's remaining liquidity when attempting to complete the payment.

In both cases, transaction processing can still complete by using liquidity from other paths or exchange rates.

fix1523

Amendment ID	Status
B9E739B8296B4A1BB29BE990B17D66E21B62A300A909F25AC55C22D6C72E1F9D	Enabled

Adds tracking by destination account to escrows. Without this amendment, pending escrows are only tracked by sender. This amendment makes it possible to look up pending escrows by the destination address using the account_objects method, excluding any pending escrows that were created before this amendment became enabled. This amendment also makes EscrowCreate transactions appear in the destination's transaction history, as viewed with the account_tx method.

With this amendment, new escrows are added to the owner directories of both the sender and receiver. This amendment also adds a new DestinationNode field to Escrow ledger objects, indicating which page of the destination's owner directory contains the escrow.

fix1528

Amendment ID	Status
1D3463A5891F9E589C5AE839FFAC4A917CE96197098A1EF22304E1BC5B98A454	Enabled

Fixes a bug where validators could build consensus ledgers with different timestamps, potentially delaying the process of declaring validated ledgers. The circumstances for this to occur require precise timing, so validators are unlikely to encounter this bug outside of controlled test conditions.

This amendment changes how validators negotiate the close time of the consensus ledger so that they cannot reach a consensus on ledger contents but build ledger versions with different timestamps.

fix1543

Amendment ID	Status
CA7C02118BA27599528543DFE77BA6838D1B0F43B447D4D7F53523CE6A0E9AC2	Enabled

Enforces reserved flag ranges on some transaction types that did not correctly enforce them already. Transactions of the affected types are now considered invalid if they enable undefined or unknown flags, or flags from the reserved range. (Transactions unaffected by this change already correctly enforce the same rules.)

Without this amendment, transactions of certain types are considered valid even when they have undefined or reserved flags enabled.

The affected transaction types are:

Escrow transactions: EscrowCancel, EscrowCreate, and EscrowFinish
Payment Channel transactions: PaymentChannelClaim, PaymentChannelCreate, and PaymentChannelFund

fix1571

Amendment ID	Status
7117E2EC2DBF119CA55181D69819F1999ECEE1A0225A7FD2B9ED47940968479C	Enabled

Changes Escrow to fix the following issues:

Changes the EscrowCreate transaction to require the Condition or FinishAfter field (or both). Escrows with neither Condition nor FinishAfter that were created before this amendment can be finished by anyone at any time before their CancelAfter time.
Fixes a flaw that incorrectly prevents time-based Escrows from being finished in some circumstances.

fix1578

Amendment ID	Status
FBD513F1B893AC765B78F250E6FFA6A11B573209D1842ADC787C850696741288	Enabled

Changes the result codes returned by two transaction types:

Changes the OfferCreate transaction to return a new result code, tecKILLED, if the offer used the tfFillOrKill flag and was killed. Without this amendment, the offer is killed but the transaction result is tesSUCCESS.
Changes the TrustSet transaction to fail with tecNO_PERMISSION if it tries to enable the NoRipple flag but cannot because the trust line has a negative balance. Without this amendment, the transaction does not enable the NoRipple flag, but the transaction result is tesSUCCESS nonetheless.

fix1623

Amendment ID	Status
58BE9B5968C4DA7C59BA900961828B113E5490699B21877DEF9A31E9D0FE5D5F	Enabled

Adds delivered amount to metadata for CheckCash transactions cashed for a flexible amount. (Has no effect unless the Checks amendment is enabled.)

With this amendment enabled, transaction processing adds a DeliveredAmount field to the metadata of CheckCash transactions for a variable amount (using the DeliverMin field). This change is written to the ledger data, resulting in a different ledger hash than would result from processing the transaction without this amendment. It does not affect the actual amounts delivered. Additionally, with this amendment enabled, the tx method and account_tx method return a delivered_amount field for CheckCash transactions. (The delivered_amount field is calculated when you look up a transaction, and is not part of the data that is written to the ledger.)

The fix1623 amendment has no effect on CheckCash transactions for a fixed amount (using the Amount field) or any other transaction types.

Caution: In rippled 1.0.0, if the Checks amendment is enabled before the fix1623 amendment, the delivered_amount may display as "0" for variable-amount CheckCash transactions from before this amendment was enabled, even if the transaction delivered a nonzero amount. Ripple plans to enable fix1623 at the same time as the Checks amendment on the production network, but this situation may be possible on parallel networks.

fix1781

Amendment ID	Status
25BA44241B3BD880770BFA4DA21C7180576831855368CBEC6A3154FDE4A7676E	In Development

Fixes a bug where certain XAG endpoints were not checked when detecting circular paths.

Without this amendment, it is possible to have a payment path where the input to the path is XAG, and an intermediate path step also outputs XAG. This is a "loop" payment, and the payment engine disallows such paths because they can have different results when executed forward compared to backwards.

With this amendment, those payments fail with the temBAD_PATH_LOOP result code instead.

fixCheckThreading

Amendment ID	Status
8F81B066ED20DAECA20DF57187767685EEF3980B228E0667A650BAF24426D3B4	Enabled

Changes the way Checks transactions affect account metadata, so that Checks are properly added to the account history of the receiving account. (Specifically, they update the PreviousTxnID and PreviousTxnLedgerSeq fields of the receiving account's AccountRoot object, which can be used to trace the "thread" of transactions that affected the account and the objects it owns.)

Without this amendment, Checks transactions (CheckCreate, CheckCash, and CheckCancel) only update the account history of the sender. With this amendment, those transactions affect both the sending and receiving accounts. This amendment has no effect unless the Checks amendment is also enabled.

fixMasterKeyAsRegularKey

Amendment ID	Status
C4483A1896170C66C098DEA5B0E024309C60DC960DE5F01CD7AF986AA3D9AD37	Enabled

Fixes a bug where accounts can set their regular key pair to match their master key pair, but cannot send transactions signed by the key if the master key is disabled.

Without this fix, a user can unintentionally "black hole" their account by setting the regular key to match the master key, then disabling the master key. The network rejects transactions signed with the both-master-and-regular key pair because the code interprets them as being signed with the disabled master key before it recognizes that they are signed by the currently-enabled regular key.

With this amendment enabled, a SetRegularKey transaction cannot set the regular key to match the master key; such a transaction results in the transaction code temBAD_REGKEY. Additionally, this amendment changes the signature verification code so that accounts which already have their regular key set to match their master key can send transactions successfully using the key pair.

fixPayChanRecipientOwnerDir

Amendment ID	Status
621A0B264970359869E3C0363A899909AAB7A887C8B73519E4ECF952D33258A8	Enabled

fixQualityUpperBound

Amendment ID	Status
89308AF3B8B10B7192C4E613E1D2E4D9BA64B2EE2D5232402AE82A6A7220D953	Open for Voting

Fixes a bug in unused code for estimating the ratio of input to output of individual steps in cross-currency payments.

This amendment has no known impact on transaction processing.

fixTakerDryOfferRemoval

Amendment ID	Status
2CD5286D8D687E98B41102BDD797198E81EA41DF7BD104E6561FEB104EFF2561	Enabled

Fixes a bug in auto-bridging that can leave a dry offer in the XAG Ledger. A dry offer is an offer that, if crossed, cannot yield any funds.

Without this fix, the dry offer remains on the ledger and counts toward its owner's reserve requirement without providing any benefit to the owner. Another offer crossing of the right type and quality can remove the dry offer. However, if the required offer crossing type and quality are rare, it may take a while for the dry offer to be removed.

With this amendment enabled, the XAG Ledger removes these dry offers when they're matched in auto-bridging.

Flow

Amendment ID	Status
740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11	Enabled

Replaces the payment processing engine with a more robust and efficient rewrite called the Flow engine. The new version of the payment processing engine is intended to follow the same rules as the old one, but occasionally produces different results due to floating point rounding. This Amendment supersedes the FlowV2 amendment.

The Flow Engine also makes it easier to improve and expand the payment engine with further Amendments.

FlowCross

Amendment ID	Status
3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC	Open for Voting

Streamlines the offer crossing logic in the XAG Ledger's decentralized exchange. Uses the updated code from the Flow amendment to power offer crossing, so OfferCreate transactions and Payment transactions share more code. This has subtle differences in how offers are processed:

Rounding is slightly different in some cases.
Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially.
The new logic may delete more or fewer offers than the old logic. (This includes cases caused by differences in rounding and offers that were incorrectly removed as unfunded by the old logic.)

FlowV2

Amendment ID	Status
5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26	Vetoed

This is a previous version of the Flow amendment. It was rejected due to a bug and removed in version 0.33.0.

HardenedValidations

Amendment ID	Status
1F4AFA8FA1BC8827AD4C0F682C03A8B671DCDF6B5C4DE36D44243A684103EF88	In Development

Allows validators to include a new optional field in their validations to attest to the hash of the latest ledger that that validator considers to be fully validated. The consensus process can use this information to increase the robustness of consensus.

MultiSign

Amendment ID	Status
4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373	Enabled

Introduces multi-signing as a way to authorize transactions. Creates the SignerList ledger object type and the SignerListSet transaction type. Adds the optional Signers field to all transaction types. Modifies some transaction result codes.

This amendment allows addresses to have a list of signers who can authorize transactions from that address in a multi-signature. The list has a quorum and 1 to 8 weighted signers. This allows various configurations, such as "any 3-of-5" or "signature from A plus any other two signatures."

Signers can be funded or unfunded addresses. Funded addresses in a signer list can sign using a regular key (if defined) or master key (unless disabled). Unfunded addresses can sign with a master key. Multi-signed transactions have the same permissions as transactions signed with a regular key.

An address with a SignerList can disable the master key even if a regular key is not defined. An address with a SignerList can also remove a regular key even if the master key is disabled. The tecMASTER_DISABLED transaction result code is renamed tecNO_ALTERNATIVE_KEY. The tecNO_REGULAR_KEY transaction result is retired and replaced with tecNO_ALTERNATIVE_KEY. Additionally, this amendment adds the following new transaction result codes:

temBAD_SIGNER
temBAD_QUORUM
temBAD_WEIGHT
tefBAD_SIGNATURE
tefBAD_QUORUM
tefNOT_MULTI_SIGNING
tefBAD_AUTH_MASTER

MultiSignReserve

Amendment ID	Status
586480873651E106F1D6339B0C4A8945BA705A777F3F4524626FF1FC07EFE41D	Enabled

Reduces the owner reserve counted against your XAG Ledger account when it owns a multi-signing SignerList.

Without this amendment, the owner reserve for a SignerList ranges from 15 to 50 XAG, depending on the number of signers in the list.

With this amendment enabled, the owner reserve for a new SignerList is 5 XAG, regardless of the number of signers. The reserve requirement for previously-created SignerList objects remains unchanged. To reduce the reserve requirement of SignerList objects created before this amendment was enabled, use a SignerListSet transaction to replace the SignerList after this amendment has been enabled. (The replacement can be identical to the previous version.)

OwnerPaysFee

Amendment ID	Status
9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871	In Development

Fixes an inconsistency in the way transfer fees are calculated between OfferCreate and Payment transaction types. Without this amendment, the holder of the issuances pays the transfer fee if an offer is executed in offer placement, but the initial sender of a transaction pays the transfer fees for offers that are executed as part of payment processing. With this amendment, the holder of the issuances always pays the transfer fee, regardless of whether the offer is executed as part of a Payment or an OfferCreate transaction. Offer processing outside of payments is unaffected.

This Amendment requires the Flow Amendment to be enabled.

Note: An incomplete version of this amendment was introduced in v0.33.0 and removed in v0.80.0. (It was never enabled.) Ripple plans to re-add the amendment when the code is stable enough.

PayChan

Amendment ID	Status
08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647	Enabled

Creates "Payment Channels" for XAG. Payment channels are a tool for facilitating repeated, unidirectional payments or temporary credit between two parties. Ripple expects this feature to be useful for the Interledger Protocol . One party creates a Payment Channel and sets aside some XAG in that channel for a predetermined expiration. Then, through off-ledger secure communications, the sender can send "Claim" messages to the receiver. The receiver can redeem the Claim messages before the expiration, or choose not to in case the payment is not needed. The receiver can verify Claims individually without actually distributing them to the network and waiting for the consensus process to redeem them, then redeem the batched content of many small Claims later, as long as it is within the expiration.

Creates three new transaction types: PaymentChannelCreate, PaymentChannelClaim, and PaymentChannelFund. Creates a new ledger object type, PayChannel. Defines an off-ledger data structure called a Claim, used in the ChannelClaim transaction. Creates new rippled API methods: channel_authorize (creates a signed Claim), channel_verify (verifies a signed Claim), and account_channels (lists Channels associated with an account).

For more information, see the Payment Channels Tutorial.

RequireFullyCanonicalSig

Amendment ID	Status
00C1FC4A53E60AB02C864641002B3172F38677E29C26C5406685179B37E1EDAC	Open for Voting

Changes the signature requirements for the XAG Ledger protocol so that non-fully-canonical signatures are no longer valid in any case. This protects against transaction malleability on all transactions, instead of just transactions with the tfFullyCanonicalSig flag enabled.

Without this amendment, a transaction is malleable if it uses a secp256k1 signature and does not have tfFullyCanonicalSig enabled. Most signing utilities enable tfFullyCanonicalSig by default, but there are exceptions.

With this amendment, no single-signed transactions are malleable. (Multi-signed transactions may still be malleable if signers provide more signatures than are necessary.) All transactions must use the fully canonical form of the signature, regardless of the tfFullyCanonicalSig flag. Signing utilities that do not create fully canonical signatures are not supported. All of Ripple's signing utilities have been providing fully-canonical signatures exclusively since at least 2014.

For more information, see rippled issue #3042 .

SHAMapV2

Amendment ID	Status
C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3	Vetoed

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.

When this amendment is activated, the XAG Ledger will undergo a brief scheduled unavailability while the network calculates the changes to the hash tree structure.

SortedDirectories

Amendment ID	Status
CC5ABAE4F3EC92E94A59B1908C2BE82D2228B6485C00AFF8F22DF930D89C194E	Enabled

Sorts the entries in DirectoryNode ledger objects and fixes a bug that occasionally caused pages of owner directories not to be deleted when they should have been.

Warning: Older versions of rippled that do not know about this amendment may crash when they encounter a DirectoryNode sorted by the new rules. To avoid this problem, upgrade to rippled version 0.80.0 or later.

SusPay

Amendment ID	Status
DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13	Vetoed

This amendment was replaced by the Escrow amendment.

Tickets

Amendment ID	Status
C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490	In Development

Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the Ticket ledger object type and the transaction types TicketCreate and TicketCancel.

Caution: This amendment is still in development.

TickSize

Amendment ID	Status
532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164	Enabled

Changes the way Offers are ranked in order books, so that currency issuers can configure how many significant digits are taken into account when ranking Offers by exchange rate. With this amendment, the exchange rates of Offers are rounded to the configured number of significant digits, so that more Offers have the same exact exchange rate. The intent of this change is to require a meaningful improvement in price to outrank a previous Offer. If used by major issuers, this should reduce the incentive to spam the ledger with Offers that are only a tiny fraction of a percentage point better than existing offers. It may also increase the efficiency of order book storage in the ledger, because Offers can be grouped into fewer exchange rates.

Introduces a TickSize field to accounts, which can be set with the AccountSet transaction type. If a currency issuer sets the TickSize field, the XAG Ledger truncates the exchange rate (ratio of funds in to funds out) of Offers to trade the issuer's currency, and adjusts the amounts of the Offer to match the truncated exchange rate. If only one currency in the trade has a TickSize set, that number of significant digits applies. When trading two currencies that have different TickSize values, whichever TickSize indicates the fewest significant digits applies. XAG does not have a TickSize.

TrustSetAuth

Amendment ID	Status
6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC	Enabled

Allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Trust Lines.

With this amendment enabled, a TrustSet transaction with tfSetfAuth enabled can create a new RippleState ledger object 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 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 by sending an AccountSet transaction with the asfRequireAuth flag enabled.