ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-19 11:15:49 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
8a2eba2603ac50279337f9a5bc8bff6d192b2545
xrpl-dev-portal/concept-amendments.html

721 lines
49 KiB
HTML
Raw Blame History

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<meta name="viewport" content="width=device-width">
<title>Amendments - Ripple Developer Portal</title>
<!-- favicon -->
<link rel="icon" href="favicon.ico" type="image/x-icon">
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon">
<!-- jQuery -->
<script src="assets/vendor/jquery-1.11.1.min.js"></script>
<!-- Custom Stylesheets. ripple.css includes bootstrap, font stuff -->
<link href="assets/css/ripple.css" rel="stylesheet" />
<link href="assets/css/devportal.css" rel="stylesheet" />
<!-- Bootstrap JS -->
<script src="assets/vendor/bootstrap.min.js"></script>
<!-- syntax highlighting -->
<link rel="stylesheet" href="assets/vendor/docco.min.css" />
<script src="assets/vendor/highlight.min.js"></script>
<!-- syntax selection js -->
<script src="assets/js/multicodetab.js"></script>
<script>
$(document).ready(function() {
$(".multicode").minitabs();
hljs.initHighlighting();
make_code_expandable();
});
</script>
<script src="assets/js/expandcode.js"></script>
<script src="assets/js/fixsidebarscroll.js"></script>
<!-- fontawesome icons -->
<link rel="stylesheet" href="assets/vendor/fontawesome/css/font-awesome.min.css" />
</head>
<body class="page page-template page-template-template-dev-portal page-template-template-dev-portal-php sidebar-primary wpb-js-composer js-comp-ver-3.6.2 vc_responsive">
<header role="banner" class="banner navbar navbar-default navbar-fixed-top initial_header">
<div class="container">
<div class="navbar-header">
<a href="index.html" class="navbar-brand"><img src="assets/img/ripple-logo-color.png" class="logo"></a>
</div><!-- /.navbar-header -->
<div class="nav">
<div class="draft-warning">DRAFT PAGE</div>
</div><!-- /.nav -->
</div><!-- /.container -->
<div class="subnav dev_nav">
<div class="container">
<ul id="menu-dev-menu" class="menu">
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">References <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="reference-rippleapi.html">RippleAPI</a></li>
<li><a href="reference-rippled.html">rippled</a></li>
<li><a href="reference-transaction-format.html">Transaction Format</a></li>
<li><a href="reference-ledger-format.html">Ledger Format</a></li>
<li><a href="reference-data-api.html">Ripple Data API v2</a></li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Tutorials <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="tutorial-multisign.html">How to Multi-Sign</a></li>
<li><a href="tutorial-paychan.html">Payment Channels Tutorial</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-reliable-transaction-submission.html">Reliable Transaction Submission</a></li>
<li><a href="tutorial-rippleapi-beginners-guide.html">RippleAPI Beginners Guide</a></li>
<li><a href="tutorial-rippled-setup.html">rippled Setup</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
<li><a href="tutorial-listing-xrp.html">Listing XRP as an Exchange</a></li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Features <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-accounts.html">Accounts</a></li>
<li><a href="concept-amendments.html">Amendments</a></li>
<li><a href="concept-consensus.html">Consensus Process</a></li>
<li><a href="concept-reaching-consensus.html">Reaching Consensus in the XRP Ledger</a></li>
<li><a href="concept-fee-voting.html">Fee Voting</a></li>
<li><a href="concept-fees.html">Fees (Disambiguation)</a></li>
<li><a href="concept-freeze.html">Freeze</a></li>
<li><a href="concept-partial-payments.html">Partial Payments</a></li>
<li><a href="concept-paths.html">Paths</a></li>
<li><a href="concept-reserves.html">Reserves</a></li>
<li><a href="concept-stand-alone-mode.html">Stand-Alone Mode</a></li>
<li><a href="concept-transaction-cost.html">Transaction Cost</a></li>
<li><a href="concept-transfer-fees.html">Transfer Fees</a></li>
<li><a href="concept-noripple.html">Understanding the NoRipple flag</a></li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Gateway Bulletins <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="gb-2015-06.html">GB-2015-06: Corrections to Autobridging</a></li>
<li><a href="gb-2015-05.html">GB-2015-05: Historical Ledger Query Migration</a></li>
</ul>
</li>
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tools <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="ripple-api-tool.html">WebSocket API Tool</a></li>
<li><a href="data-api-v2-tool.html">Data API v2 Tool</a></li>
<li><a href="tool-jsonrpc.html">rippled JSON-RPC Tool</a></li>
</ul>
</li>
<li><a href="https://github.com/ripple/ripple-dev-portal" title="GitHub">Site Source</a></li>
</ul><!-- /#dev-menu -->
</div><!-- /.subnav .container -->
</div><!-- /.subnav -->
</header>
<div class="wrap container" role="document">
<aside class="sidebar" role="complementary">
<div class="dev_nav_wrapper">
<div id="cont">
<h5>In this category:</h5>
<ul class="dev_nav_sidebar">
<li class="level-1"><a href="index.html">Category: Features</a></li>
<li class="level-2"><a href="concept-accounts.html">Accounts</a></li>
<li class="level-2"><a href="concept-amendments.html">Amendments</a></li>
<li class="level-2"><a href="concept-consensus.html">Consensus Process</a></li>
<li class="level-2"><a href="concept-reaching-consensus.html">Reaching Consensus in the XRP Ledger</a></li>
<li class="level-2"><a href="concept-fee-voting.html">Fee Voting</a></li>
<li class="level-2"><a href="concept-fees.html">Fees (Disambiguation)</a></li>
<li class="level-2"><a href="concept-freeze.html">Freeze</a></li>
<li class="level-2"><a href="concept-partial-payments.html">Partial Payments</a></li>
<li class="level-2"><a href="concept-paths.html">Paths</a></li>
<li class="level-2"><a href="concept-reserves.html">Reserves</a></li>
<li class="level-2"><a href="concept-stand-alone-mode.html">Stand-Alone Mode</a></li>
<li class="level-2"><a href="concept-transaction-cost.html">Transaction Cost</a></li>
<li class="level-2"><a href="concept-transfer-fees.html">Transfer Fees</a></li>
<li class="level-2"><a href="concept-noripple.html">Understanding the NoRipple flag</a></li>
</ul>
<hr />
<h5>In this page:</h5>
<ul class="dev_nav_sidebar" id="dactyl_toc_sidebar">
<li class="level-1"><a href="#amendments">Amendments</a></li>
<li class="level-2"><a href="#background">Background</a></li>
<li class="level-2"><a href="#about-amendments">About Amendments</a></li>
<li class="level-2"><a href="#amendment-process">Amendment Process</a></li>
<li class="level-2"><a href="#amendment-voting">Amendment Voting</a></li>
<li class="level-3"><a href="#configuring-amendment-voting">Configuring Amendment Voting</a></li>
<li class="level-3"><a href="#amendment-blocked">Amendment Blocked</a></li>
<li class="level-2"><a href="#testing-amendments">Testing Amendments</a></li>
<li class="level-1"><a href="#known-amendments">Known Amendments</a></li>
<li class="level-2"><a href="#cryptoconditions">CryptoConditions</a></li>
<li class="level-2"><a href="#enforceinvariants">EnforceInvariants</a></li>
<li class="level-2"><a href="#escrow">Escrow</a></li>
<li class="level-2"><a href="#feeescalation">FeeEscalation</a></li>
<li class="level-2"><a href="#fix1368">fix1368</a></li>
<li class="level-2"><a href="#fix1373">fix1373</a></li>
<li class="level-2"><a href="#flow">Flow</a></li>
<li class="level-2"><a href="#flowcross">FlowCross</a></li>
<li class="level-2"><a href="#flowv2">FlowV2</a></li>
<li class="level-2"><a href="#multisign">MultiSign</a></li>
<li class="level-2"><a href="#ownerpaysfee">OwnerPaysFee</a></li>
<li class="level-2"><a href="#paychan">PayChan</a></li>
<li class="level-2"><a href="#shamapv2">SHAMapV2</a></li>
<li class="level-2"><a href="#suspay">SusPay</a></li>
<li class="level-2"><a href="#trustsetauth">TrustSetAuth</a></li>
<li class="level-2"><a href="#ticksize">TickSize</a></li>
<li class="level-2"><a href="#tickets">Tickets</a></li>
</ul>
</div>
</div>
</aside>
<main class="main" role="main">
<div class='content'>
<h1 id="amendments">Amendments</h1>
<p><a href="https://github.com/ripple/rippled/releases/tag/0.31.0" title="Introduced in: rippled 0.31.0"><img alt="Introduced in: rippled 0.31.0" class="dactyl_badge" src="https://img.shields.io/badge/Introduced%20in-rippled%200.31.0-blue.svg"/></a></p>
<p>The Amendments system provides a means of introducing new features to the decentralized Ripple consensus network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires <strong>80% support for two weeks</strong> before it can apply.</p>
<p>When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.</p>
<h2 id="background">Background</h2>
<p>Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some <em>validators</em> (<code>rippled</code> servers <a href="tutorial-rippled-setup.html#reasons-to-run-a-validator">participating in consensus</a>) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, <a href="https://ripple.com/build/ripple-ledger-consensus-process/">the consensus process</a> might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.</p>
<p>Amendments solve this problem, so that new features can be enabled only when enough validators support those features.</p>
<p>Users and businesses who rely on the XRP Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or <a href="https://ripple.com/build/ripple-ledger-consensus-process/">the consensus process</a> do not need Amendments.</p>
<h2 id="about-amendments">About Amendments</h2>
<p>An amendment is a fully-functional feature or change, waiting to be enabled by the peer-to-peer network as a part of the consensus process. A <code>rippled</code> server that wants to use an amendment has code for two modes: without the amendment (old behavior) and with the amendment (new behavior).</p>
<p>Every amendment has a unique identifying hex value and a short name. The short name is for human use, and is not used in the amendment process. Two servers can support the same amendment ID while using different names to describe it. An amendment's name is not guaranteed to be unique.</p>
<p>By convention, Ripple's developers use the SHA-512Half hash of the amendment name as the amendment ID.</p>
<p>See also: <a href="#known-amendments">Known Amendments</a></p>
<h2 id="amendment-process">Amendment Process</h2>
<p>Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When <code>rippled</code> validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. (<a href="concept-fee-voting.html">Fee Voting</a> also occurs around flag ledgers.)</p>
<p>The flag ledger itself has no special contents. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an <a href="reference-transaction-format.html#enableamendment"><code>EnableAmendment</code> pseudo-transaction</a> into the following ledger. The flags of an EnableAmendment pseudo-transaction show what the server thinks happened:</p>
<ul>
<li>The <code>tfGotMajority</code> flag means that support for the amendment has increased to at least 80% of trusted validators.</li>
<li>The <code>tfLostMajority</code> flag means that support for the amendment has decreased to less than 80% of trusted validators.</li>
<li>An EnableAmendment pseudo-transaction with no flags means that support for the amendment has been enabled. (The change in transaction processing applies to every ledger after this one.)</li>
</ul>
<p>A server only inserts the pseudo-transaction to enable an amendment if all of the following conditions are met:</p>
<ul>
<li>The amendment has not already been enabled.</li>
<li>A previous ledger includes an EnableAmendment pseudo-transaction for this amendment with the <code>tfGotMajority</code> flag enabled.</li>
<li>The previous ledger in question is an ancestor of the current ledger.</li>
<li>The previous ledger in question has a close time that is at least <strong>two weeks</strong> before the close time of the latest flag ledger.</li>
<li>There are no EnableAmendment pseudo-transactions for this amendment with the <code>tfLostMajority</code> flag enabled in the consensus ledgers between the <code>tfGotMajority</code> pseudo-transaction and the current ledger.</li>
</ul>
<p>Theoretically, a <code>tfLostMajority</code> EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the <code>tfLostMajority</code> pseudo-transaction has no effect.</p>
<h2 id="amendment-voting">Amendment Voting</h2>
<p>Each version of <code>rippled</code> is compiled with a list of known amendments and the code to implement those amendments. By default, <code>rippled</code> supports known amendments and opposes unknown amendments. Operators of <code>rippled</code> validators can <a href="#configuring-amendment-voting">configure their servers</a> to explicitly support or oppose certain amendments, even if those amendments are not known to their <code>rippled</code> versions.</p>
<p>To become enabled, an amendment must be supported by at least 80% of trusted validators continuously for two weeks. If support for an amendment goes below 80% of trusted validators, the amendment is temporarily rejected. The two week period starts over if the amendment regains support of at least 80% of trusted validators. (This can occur if validators vote differently, or if there is a change in which validators are trusted.) An amendment can gain and lose a majority an unlimited number of times before it becomes permanently enabled. An amendment cannot be permanently rejected, but it becomes very unlikely for an amendment to become enabled if new versions of <code>rippled</code> do not have the amendment in their known amendments list.</p>
<p>As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. At this time, Ripple (the company) recommends only trusting the 5 default validators that Ripple (the company) operates. For now, trusting only those validators is enough to coordinate with Ripple (the company) on releasing new features.</p>
<h3 id="configuring-amendment-voting">Configuring Amendment Voting</h3>
<p>You can temporarily configure an amendment using the <a href="reference-rippled.html#feature"><code>feature</code> command</a>. To make a persistent change to your server's support for an amendment, change your server's <code>rippled.cfg</code> file.</p>
<p>Use the <code>[veto_amendments]</code> stanza to list amendments you do not want the server to vote for. Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:</p>
<pre><code>[veto_amendments]
C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
</code></pre>
<p>Use the <code>[amendments]</code> stanza to list amendments you want to vote for. (Even if you do not list them here, by default a server votes for all the amendments it knows how to apply.) Each line should contain one amendment's unique ID, optionally followed by the short name for the amendment. For example:</p>
<pre><code>[amendments]
4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign
42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation
</code></pre>
<h3 id="amendment-blocked">Amendment Blocked</h3>
<p>When an amendment gets enabled for the network after the voting process, servers running earlier versions of <code>rippled</code> that do not know about the amendment become "amendment blocked" because they no longer understand the rules of the network. Servers that are amendment blocked:</p>
<ul>
<li>Cannot determine the validity of a ledger</li>
<li>Cannot submit or process transactions</li>
<li>Do not participate in the consensus process</li>
<li>Do not vote on future amendments</li>
</ul>
<p>Becoming amendment blocked is a security feature to protect backend applications. Rather than guessing and maybe misinterpreting a ledger after new rules have applied, <code>rippled</code> reports that it does not know the state of the ledger because it does not know how the amendment works.</p>
<p>The amendments that a <code>rippled</code> server is configured to vote for or against have no impact on whether the server becomes amendment blocked. A <code>rippled</code> server always follows the set of amendments enabled by the rest of the network, to the extent possible. A server only becomes amendment blocked if the enabled amendment is not included in the amendment definitions compiled into the server's source code -- in other words, if the amendment is newer than the server.</p>
<p>If your server is amendment blocked, you must <a href="tutorial-rippled-setup.html#updating-rippled">upgrade to a new version</a> to sync with the network.</p>
<h2 id="testing-amendments">Testing Amendments</h2>
<p>If you want to see how <code>rippled</code> behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use <code>rippled</code>'s configuration file to forcibly enable a feature. This is intended for development purposes only.</p>
<p>Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run <code>rippled</code> in <a href="concept-stand-alone-mode.html">Stand-Alone Mode</a>.</p>
<p>To forcibly enable a feature, add a <code>[features]</code> stanza to your <code>rippled.cfg</code> file. In this stanza, add the short names of the features to enable, one per line. For example:</p>
<pre><code>[features]
MultiSign
TrustSetAuth
</code></pre>
<h1 id="known-amendments">Known Amendments</h1>
<p><a href="https://github.com/ripple/rippled/blob/release/src/ripple/app/main/Amendments.cpp" title="Source">[Source]<br/></a></p>
<p>The following is a comprehensive list of all known amendments and their status on the production XRP Ledger:</p>
<table>
<thead>
<tr>
<th align="left">Name</th>
<th align="left">Introduced</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"><a href="#flowcross">FlowCross</a></td>
<td align="left">v0.70.0</td>
<td align="left"><a title="Planned: TBD"><img alt="Planned: TBD" class="dactyl_badge" src="https://img.shields.io/badge/Planned-TBD-lightgrey.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#shamapv2">SHAMapV2</a></td>
<td align="left">v0.33.0</td>
<td align="left"><a title="Planned: TBD"><img alt="Planned: TBD" class="dactyl_badge" src="https://img.shields.io/badge/Planned-TBD-lightgrey.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#ownerpaysfee">OwnerPaysFee</a></td>
<td align="left">v0.33.0</td>
<td align="left"><a title="Planned: TBD"><img alt="Planned: TBD" class="dactyl_badge" src="https://img.shields.io/badge/Planned-TBD-lightgrey.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#tickets">Tickets</a></td>
<td align="left">N/A</td>
<td align="left"><a title="Planned: TBD"><img alt="Planned: TBD" class="dactyl_badge" src="https://img.shields.io/badge/Planned-TBD-lightgrey.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#enforceinvariants">EnforceInvariants</a></td>
<td align="left">v0.70.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/17593B03F7D3283966F3C0ACAF4984F26E9D884C9A202097DAED0523908E76C6" title="Enabled: 2017-07-07"><img alt="Enabled: 2017-07-07" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--07--07-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#fix1373">fix1373</a></td>
<td align="left">v0.70.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/7EBA3852D111EA19D03469F6870FAAEBF84C64F1B9BAC13B041DDD26E28CA399" title="Enabled: 2017-07-07"><img alt="Enabled: 2017-07-07" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--07--07-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#fix1368">fix1368</a></td>
<td align="left">v0.60.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/3D20DE5CD19D5966865A7D0405FAC7902A6F623659667D6CB872DF7A94B6EF3F" title="Enabled: 2017-03-31"><img alt="Enabled: 2017-03-31" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--03--31-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#paychan">PayChan</a></td>
<td align="left">v0.33.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/16135C0B4AB2419B89D4FB4569B8C37FF76B9EF9CE0DD99CCACB5734445AFD7E" title="Enabled: 2017-03-31"><img alt="Enabled: 2017-03-31" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--03--31-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#escrow">Escrow</a></td>
<td align="left">v0.60.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/C581E0A3F3832FFFEEB13C497658F475566BD7695B0BBA531A774E6739801515" title="Enabled: 2017-03-31"><img alt="Enabled: 2017-03-31" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--03--31-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#ticksize">TickSize</a></td>
<td align="left">v0.50.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/A12430E470BE5C846759EAE3C442FF03374D5D73ECE5815CF4906894B769565E" title="Enabled: 2017-02-21"><img alt="Enabled: 2017-02-21" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--02--21-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#suspay">SusPay</a></td>
<td align="left">v0.31.0</td>
<td align="left"><a href="https://ripple.com/dev-blog/ticksize-amendment-open-voting/#upcoming-features" title="Vetoed: Removed in v0.60.0"><img alt="Vetoed: Removed in v0.60.0" class="dactyl_badge" src="https://img.shields.io/badge/Vetoed-Removed%20in%20v0.60.0-red.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#cryptoconditions">CryptoConditions</a></td>
<td align="left">v0.50.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/8EB00131E1C3DB35EDFF45C155D941E18C3E86BC1934FF987D2DA204F4065F15" title="Enabled: 2017-01-03"><img alt="Enabled: 2017-01-03" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2017--01--03-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#flow">Flow</a></td>
<td align="left">v0.33.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/C06CE3CABA3907389E4DD296C5F31C73B1548CC20BD7B83416C78CD7D4CD38FC" title="Enabled: 2016-10-21"><img alt="Enabled: 2016-10-21" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2016--10--21-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#flowv2">FlowV2</a></td>
<td align="left">v0.32.1</td>
<td align="left"><a href="https://ripple.com/dev-blog/flowv2-amendment-vetoed/" title="Vetoed: Removed in v0.33.0"><img alt="Vetoed: Removed in v0.33.0" class="dactyl_badge" src="https://img.shields.io/badge/Vetoed-Removed%20in%20v0.33.0-red.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#trustsetauth">TrustSetAuth</a></td>
<td align="left">v0.30.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF" title="Enabled: 2016-07-19"><img alt="Enabled: 2016-07-19" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2016--07--19-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#multisign">MultiSign</a></td>
<td align="left">v0.31.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7" title="Enabled: 2016-06-27"><img alt="Enabled: 2016-06-27" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2016--06--27-green.svg"/></a></td>
</tr>
<tr>
<td align="left"><a href="#feeescalation">FeeEscalation</a></td>
<td align="left">v0.31.0</td>
<td align="left"><a href="https://xrpcharts.ripple.com/#/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3" title="Enabled: 2016-05-19"><img alt="Enabled: 2016-05-19" class="dactyl_badge" src="https://img.shields.io/badge/Enabled-2016--05--19-green.svg"/></a></td>
</tr>
</tbody>
</table>
<p class="devportal-callout note"><strong>Note:</strong> 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.</p>
<h2 id="cryptoconditions">CryptoConditions</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Although this amendment is enabled, it has no effect unless the <a href="#suspay">SusPay</a> amendment is also enabled. Ripple does not expect SusPay to become enabled. Instead, Ripple plans to incorporate crypto-conditions in the <a href="#escrow">Escrow</a> amendment.</p>
<h2 id="enforceinvariants">EnforceInvariants</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">DC9CA96AEA1DCF83E527D1AFC916EFAF5D27388ECA4060A88817C1238CAEE0BF</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>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 XRP Ledger. Ripple expects to add more invariant checks in future versions of <code>rippled</code> without additional amendments.</p>
<p>Introduces two new transaction error codes, <code>tecINVARIANT_FAILED</code> and <code>tefINVARIANT_FAILED</code>. Changes transaction processing to add the new checks.</p>
<p>Examples of invariant checks:</p>
<ul>
<li>The total amount of XRP destroyed by a transaction must match the <a href="concept-transaction-cost.html">transaction cost</a> exactly.</li>
<li>XRP cannot be created.</li>
<li><a href="reference-ledger-format.html#accountroot"><code>AccountRoot</code> objects in the ledger</a> cannot be deleted. (See also: <a href="concept-accounts.html#permanence-of-accounts">Permanence of Accounts</a>.)</li>
<li><a href="reference-ledger-format.html#ledger-node-types">An object in the ledger</a> cannot change its type. (The <code>LedgerEntryType</code> field is immutable.)</li>
<li>There cannot be a trust line for XRP.</li>
</ul>
<h2 id="escrow">Escrow</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Replaces the <a href="#suspay">SusPay</a> and <a href="#cryptoconditions">CryptoConditions</a> amendments.</p>
<p>Provides "suspended payments" for XRP for escrow within the XRP Ledger, including support for <a href="https://tools.ietf.org/html/draft-thomas-crypto-conditions-02">Interledger Protocol Crypto-Conditions</a>. Creates a new ledger node type for suspended payments and new transaction types to create, execute, and cancel suspended payments.</p>
<h2 id="feeescalation">FeeEscalation</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Changes the way the <a href="concept-transaction-cost.html">transaction cost</a> applies to proposed transactions. Modifies the consensus process to prioritize transactions that pay a higher transaction cost. <!-- STYLE_OVERRIDE: prioritize --></p>
<p>This amendment introduces a fixed-size transaction queue for transactions that were not able to be included in the previous consensus round. If the <code>rippled</code> 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 (<code>Fee</code> 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.</p>
<p>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.</p>
<p>A transaction remains in the queue until one of the following happens:</p>
<ul>
<li>It gets applied to a validated ledger (regardless of success or failure)</li>
<li>It becomes invalid (for example, the <a href="reference-transaction-format.html#lastledgersequence"><code>LastLedgerSequence</code></a> causes it to expire)</li>
<li>It gets dropped because there are too many transactions in the queue with a higher transaction cost.</li>
</ul>
<h2 id="fix1368">fix1368</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">E2E6F2866106419B88C50045ACE96368558C345566AC8F2BDF5A5B5587F0E6FA</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>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.</p>
<h2 id="fix1373">fix1373</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">42EEA5E28A97824821D4EF97081FE36A54E9593C6E4F20CBAE098C69D2E072DC</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Fixes a minor bug in transaction processing that causes failures when trying to prepare certain <a href="concept-paths.html">payment paths</a> 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.</p>
<p>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 <a href="concept-paths.html#path-specifications">steps</a> include conflicting fields and paths that loop through the same object more than once.</p>
<h2 id="flow">Flow</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">740352F2412A9909880C23A559FCECEDA3BE2126FED62FC7660D628A06927F11</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>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 <a href="https://ripple.com/dev-blog/flowv2-amendment-vetoed/">FlowV2</a> amendment.</p>
<p>The Flow Engine also makes it easier to improve and expand the payment engine with further Amendments.</p>
<h2 id="flowcross">FlowCross</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">3012E8230864E95A58C60FD61430D7E1B4D3353195F2981DC12B0C7C0950FFAC</td>
<td align="left">Released but not enabled</td>
</tr>
</tbody>
</table>
<p>Streamlines the offer crossing logic in the XRP Ledger's decentralized exchange. Uses the updated code from the <a href="#flow">Flow</a> amendment to power offer crossing, so <a href="reference-transaction-format.html#offercreate">OfferCreate transactions</a> and <a href="reference-transaction-format.html#payment">Payment transactions</a> share more code. This has subtle differences in how offers are processed:</p>
<ul>
<li>Rounding is slightly different in some cases.</li>
<li>Due to differences in rounding, some combinations of offers may be ranked higher or lower than by the old logic, and taken preferentially.</li>
<li>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.)</li>
</ul>
<h2 id="flowv2">FlowV2</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26</td>
<td align="left">Withdrawn</td>
</tr>
</tbody>
</table>
<p>This is a previous version of the <a href="#flow">Flow</a> amendment. It was <a href="https://ripple.com/dev-blog/flowv2-amendment-vetoed/">rejected due to a bug</a> and removed in version 0.33.0.</p>
<h2 id="multisign">MultiSign</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Introduces <a href="reference-transaction-format.html#multi-signing">multi-signing</a> as a way to authorize transactions. Creates the <a href="reference-ledger-format.html#signerlist"><code>SignerList</code> ledger node type</a> and the <a href="reference-transaction-format.html#signerlistset"><code>SignerListSet</code> transaction type</a>. Adds the optional <code>Signers</code> field to all transaction types. Modifies some transaction result codes.</p>
<p>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."</p>
<p>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.</p>
<p>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 <code>tecMASTER_DISABLED</code> transaction result code is renamed <code>tecNO_ALTERNATIVE_KEY</code>. The <code>tecNO_REGULAR_KEY</code> transaction result is retired and replaced with <code>tecNO_ALTERNATIVE_KEY</code>. Additionally, this amendment adds the following new <a href="reference-transaction-format.html#result-categories">transaction result codes</a>:</p>
<ul>
<li><code>temBAD_SIGNER</code></li>
<li><code>temBAD_QUORUM</code></li>
<li><code>temBAD_WEIGHT</code></li>
<li><code>tefBAD_SIGNATURE</code></li>
<li><code>tefBAD_QUORUM</code></li>
<li><code>tefNOT_MULTI_SIGNING</code></li>
<li><code>tefBAD_AUTH_MASTER</code></li>
</ul>
<h2 id="ownerpaysfee">OwnerPaysFee</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">9178256A980A86CF3D70D0260A7DA6402AAFE43632FDBCB88037978404188871</td>
<td align="left">Released but not enabled</td>
</tr>
</tbody>
</table>
<p>Fixes an inconsistency in the way <a href="concept-transfer-fees.html">transfer fees</a> are calculated between <a href="reference-transaction-format.html#offercreate">OfferCreate</a> and <a href="reference-transaction-format.html#payment">Payment</a> 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.</p>
<p>This Amendment requires the <a href="#flow">Flow Amendment</a> to be enabled.</p>
<h2 id="paychan">PayChan</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Creates "Payment Channels" for XRP. 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 <a href="https://interledger.org/">Interledger Protocol</a>. One party creates a Payment Channel and sets aside some XRP 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.</p>
<p>Creates three new transaction types:<a href="reference-transaction-format.html#paymentchannelcreate">PaymentChannelCreate</a>, <a href="reference-transaction-format.html#paymentchannelclaim">PaymentChannelClaim</a>, and <a href="reference-transaction-format.html#paymentchannelfund">PaymentChannelFund</a>. Creates a new ledger node type, <a href="reference-ledger-format.html#paychannel">PayChannel</a>. Defines an off-ledger data structure called a <code>Claim</code>, used in the ChannelClaim transaction. Creates new <code>rippled</code> API methods: <a href="reference-rippled.html#channel-authorize"><code>channel_authorize</code></a> (creates a signed Claim), <a href="reference-rippled.html#channel-verify"><code>channel_verify</code></a> (verifies a signed Claim), and <a href="reference-rippled.html#account-channels"><code>account_channels</code></a> (lists Channels associated with an account).</p>
<p>For more information, see the <a href="tutorial-paychan.html">Payment Channels Tutorial</a>.</p>
<h2 id="shamapv2">SHAMapV2</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">C6970A8B603D8778783B61C0D445C23D1633CCFAEF0D43E7DBCD1521D34BD7C3</td>
<td align="left">Released but not enabled</td>
</tr>
</tbody>
</table>
<p>Changes the hash tree structure that <code>rippled</code> 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.</p>
<p>When this amendment is activated, the XRP Ledger will undergo a brief scheduled unavailability while the network calculates the changes to the hash tree structure.</p>
<h2 id="suspay">SusPay</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13</td>
<td align="left">Enabled on TestNet; not intended for production.</td>
</tr>
</tbody>
</table>
<p>This amendment is currently enabled on the <a href="https://ripple.com/build/ripple-test-net/">Ripple Test Net</a>. In production, Ripple expects to enable similar functionality with the <a href="#escrow">Escrow</a> amendment instead.</p>
<h2 id="trustsetauth">TrustSetAuth</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Allows pre-authorization of accounting relationships (zero-balance trust lines) when using <a href="tutorial-gateway-guide.html#authorized-accounts">Authorized Accounts</a>.</p>
<p>With this amendment enabled, a <code>TrustSet</code> transaction with <a href="reference-transaction-format.html#trustset-flags"><code>tfSetfAuth</code> enabled</a> can create a new <a href="reference-ledger-format.html#ripplestate"><code>RippleState</code> ledger node</a> even if it keeps all the other values of the <code>RippleState</code> node in their default state. The new <code>RippleState</code> node has the <a href="reference-ledger-format.html#ripplestate-flags"><code>lsfLowAuth</code> or <code>lsfHighAuth</code> flag</a> 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 <a href="reference-ledger-format.html#accountroot-flags"><code>lsfRequireAuth</code></a> by sending an <a href="reference-transaction-format.html#accountset">AccountSet transaction</a> with the <a href="reference-transaction-format.html#accountset-flags">asfRequireAuth flag enabled</a>.</p>
<h2 id="ticksize">TickSize</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">532651B4FD58DF8922A49BA101AB3E996E5BFBF95A913B3E392504863E63B164</td>
<td align="left">Enabled</td>
</tr>
</tbody>
</table>
<p>Changes the way <a href="reference-transaction-format.html#lifecycle-of-an-offer">Offers</a> 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.</p>
<p>Introduces a <code>TickSize</code> field to accounts, which can be set with the <a href="reference-transaction-format.html#accountset">AccountSet transaction type</a>. If a currency issuer sets the <code>TickSize</code> field, the XRP 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 <code>TickSize</code> set, that number of significant digits applies. When trading two currencies that have different <code>TickSize</code> values, whichever <code>TickSize</code> indicates the fewest significant digits applies. XRP does not have a <code>TickSize</code>.</p>
<h2 id="tickets">Tickets</h2>
<table>
<thead>
<tr>
<th align="left">Amendment ID</th>
<th align="left">Status</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490</td>
<td align="left">In development</td>
</tr>
</tbody>
</table>
<p>Introduces Tickets as a way to reserve a transaction sequence number for later execution. Creates the <code>Ticket</code> ledger node type and the transaction types <code>TicketCreate</code> and <code>TicketCancel</code>.</p>
<p class="devportal-callout caution"><strong>Caution:</strong> This amendment is still in development.</p>
<!-- rippled release notes links -->
</div>
</main>
</div>
<footer class="content-info" role="contentinfo">
<div class="container">
<div class="row">
<section class="col-sm-3 widget nav_menu-3 widget_nav_menu">
<h4>Resources<hr></h4>
<ul id="menu-resources" class="menu">
<li class="menu-insights"><a href="https://ripple.com/insights/">Insights</a></li>
<li class="menu-events"><a href="https://ripple.com/events/">Events</a></li>
<li class="menu-collateral"><a href="https://ripple.com/collateral/">Collateral</a></li>
<li class="menu-press-center"><a href="https://ripple.com/press-center/">Press Center</a></li>
<li class="menu-media-kit"><a href="https://ripple.com/media-kit/">Media Kit</a></li>
<li class="menu-xrp-portal"><a href="https://ripple.com/xrp-portal/">XRP Portal</a></li>
</ul>
</section>
<section class="col-sm-3 widget nav_menu-5 widget_nav_menu">
<h4>Regulators<hr></h4>
<ul id="menu-compliance-regulatory-relations" class="menu">
<li class="menu-compliance"><a href="https://ripple.com/compliance/">Compliance</a></li>
<li class="menu-policy-framework"><a href="https://ripple.com/policy-framework/">Policy Framework</a></li>
</ul>
</section>
<section class="col-sm-3 widget nav_menu-4 widget_nav_menu">
<h4>Support<hr></h4>
<ul id="menu-dev-footer-menu" class="menu">
<li class="menu-contact-us"><a href="https://ripple.com/contact/">Contact Us</a></li>
<li class="active menu-developer-center"><a href="https://ripple.com/build/">Developer Center</a></li>
<li class="menu-knowledge-center"><a href="https://ripple.com/learn/">Knowledge Center</a></li>
<li class="menu-ripple-forum"><a target="_blank" href="https://forum.ripple.com/">Ripple Forum</a></li>
</ul>
</section>
<section class="col-sm-3 widget nav_menu-2 widget_nav_menu">
<h4>About<hr></h4>
<ul id="menu-company-footer" class="menu">
<li class="menu-our-company"><a href="https://ripple.com/company/">Our Company</a></li>
<li class="menu-careers"><a href="https://ripple.com/company/careers/">Careers</a></li>
</ul>
</section>
<div class="col-sm-12 absolute_bottom_footer">
<div class="col-sm-8">
<span>&copy; 2013 - 2016 Ripple Labs, Inc. All Rights Reserved.</span>
<span><a href="/terms-of-use/">Terms</a></span>
<span><a href="/privacy-policy/">Privacy</a></span>
</div>
</div><!-- /.absolute_bottom_footer -->
</div><!-- /.row -->
</div><!-- /.container -->
</footer>
</body>
</html>
Reference in New Issue View Git Blame Copy Permalink