ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-04 20:05:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

"issuing account"->"issuing address" etc.

Browse Source
This commit is contained in:
mDuo13
2016-03-08 17:51:55 -08:00
parent 47407e82c8
commit d0fc1c5b84
28 changed files with 110 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
concept-fee-voting.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
concept-fees.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

10
concept-freeze.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>
@@ -144,18 +144,18 @@
<li>The counterparty's offers to sell the currency issued on the frozen trust line are <a href="reference-transaction-format.html#lifecycle-of-an-offer">considered unfunded</a>.</li>
</ul>
<p>A gateway can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the gateway's terms of use. The gateway should also freeze the counterparty in any other systems the gateway operates that are connected to the Ripple Consensus Ledger. (Otherwise, an account might still be able to engage in undesired activity by sending payments through the gateway.)</p>
<p>An individual account can freeze its trust line to a gateway. This has no effect on transactions between the gateway and other users. It does, however, prevent other accounts, including <a href="concept-issuing-and-operational-accounts.html">operational accounts</a>, from sending that gateway's issued currency to the individual account. This type of individual freeze has no effect on offers.</p>
<p>An individual account can freeze its trust line to a gateway. This has no effect on transactions between the gateway and other users. It does, however, prevent other accounts, including <a href="concept-issuing-and-operational-addresses.html">operational addresses</a>, from sending that gateway's issued currency to the individual account. This type of individual freeze has no effect on offers.</p>
<p>The Individual Freeze applies to a single currency only. In order to freeze multiple currencies with a particular counterparty, the account must enable Individual Freeze on the trust lines for each currency individually.</p>
<p>An account cannot enable the Individual Freeze setting if it has previously enabled the <a href="#no-freeze">No Freeze</a> setting.</p>
<h2 id="global-freeze">Global Freeze</h2>
<p>The <strong>Global Freeze</strong> feature is a setting on an account. When an issuing account enables the Global Freeze feature, the following rules apply:</p>
<ul>
<li>All counterparties of the frozen issuing account can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects any <a href="concept-issuing-and-operational-accounts.html">operational accounts</a>.)</li>
<li>All counterparties of the frozen issuing account can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects any <a href="concept-issuing-and-operational-addresses.html">operational addresses</a>.)</li>
<li>Counterparties of the frozen issuing account can still send and receive payments directly to and from the issuing account.</li>
<li>All offers to sell currencies issued by the frozen account are <a href="reference-transaction-format.html#lifecycle-of-an-offer">considered unfunded</a>.</li>
</ul>
<p>It can be useful to enable Global Freeze on a gateway's <a href="concept-issuing-and-operational-accounts.html">issuing account</a> if an operational account is compromised, or immediately after regaining control of a compromised issuing account. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. In addition to enacting a Global Freeze in the Ripple Consensus Ledger, a financial institution should also suspend activities in its connectors to outside systems.</p>
<p>It can also be useful to enable Global Freeze if a gateway intends to migrate to a new <a href="concept-issuing-and-operational-accounts.html">issuing account</a>, or if the gateway intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.</p>
<p>It can be useful to enable Global Freeze on a gateway's <a href="concept-issuing-and-operational-addresses.html">issuing account</a> if the secret key to an operational address is compromised, or immediately after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. In addition to enacting a Global Freeze in the Ripple Consensus Ledger, a financial institution should also suspend activities in its connectors to outside systems.</p>
<p>It can also be useful to enable Global Freeze if a gateway intends to migrate to a new <a href="concept-issuing-and-operational-addresses.html">issuing account</a>, or if the gateway intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.</p>
<p>Global Freeze applies to <em>all</em> currencies issued and held by the account. You cannot enable Global Freeze for only one currency. If you want to have the ability to freeze some currencies and not others, you should use different accounts for each currency.</p>
<p>An account can always enable the Global Freeze setting. However, if the account has previously enabled the <a href="#no-freeze">No Freeze</a> setting, it can never <em>disable</em> Global Freeze.</p>
<h2 id="no-freeze">No Freeze</h2>

37
concept-issuing-and-operational-accounts.html → concept-issuing-and-operational-addresses.html
View File

@@ -5,7 +5,7 @@
<meta charset="utf-8">
<meta content="IE=edge,chrome=1" http-equiv="X-UA-Compatible">
<meta content="width=device-width" name="viewport">
<title>Issuing and Operational Acounts - Ripple Developer Portal</title>
<title>Issuing and Operational Addresses - Ripple Developer Portal</title>
<!-- favicon -->
<link href="favicon.ico" rel="icon" type="image/x-icon">
<link href="favicon.ico" rel="shortcut icon" type="image/x-icon">
@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>
@@ -110,7 +110,7 @@
<div id="cont">
<ul class="dev_nav_sidebar">
<li class="level-1"><a href="index.html">Category: Best Practices</a></li>
<li class="level-2"><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li class="level-2"><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li class="level-2"><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
<hr/>
@@ -121,24 +121,27 @@
</aside>
<main class="main" role="main">
<div class="content">
<h1 id="issuing-and-operational-accounts">Issuing and Operational Accounts</h1>
<p>For any financial institution doing business using the Ripple Consensus Ledger, we strongly recommend that the institution use multiple Ripple ledger accounts with a separation of roles. This promotes strong security and minimizes risk. We recommend the following setup:</p>
<h1 id="issuing-and-operational-addresses">Issuing and Operational Addresses</h1>
<p>For any financial institution doing business using the Ripple Consensus Ledger, we strongly recommend that the institution use multiple Ripple ledger addresses with a separation of roles. This promotes strong security and minimizes risk. We recommend the following setup:</p>
<ul>
<li>An <strong>issuing account</strong> (also known as a "cold wallet") with high value, used as rarely as possible.</li>
<li>One or more <strong>operational accounts</strong> (also known as a "hot wallets") with low value, used frequently by automated processes.</li>
<li>Optional <strong>standby accounts</strong> (also known as "warm wallets"), used infrequently by human operators.</li>
<li>An <strong>issuing address</strong> (also known as a "cold wallet") with high value, used as rarely as possible.</li>
<li>One or more <strong>operational addresses</strong> (also known as a "hot wallets") with low value, used frequently by automated processes.</li>
<li>Optional <strong>standby addresses</strong> (also known as "warm wallets"), used infrequently by human operators.</li>
</ul>
<h2 id="the-risk">The Risk</h2>
<p>If a malicious person compromises a institution's issuing account (cold wallet), that person could create an unlimited amount of new issuances and trade them in the decentralized exchange. This would make it difficult to distinguish legitimately-obtained issuances and redeem them fairly. In this case, the institution must create a new issuing account, and all users with trust lines to the old issuing account must create new trust lines to the new account. Thus, it's best to keep your issuing account as secure as possible.</p>
<p>If a malicious person learns the secret key behind a institution's issuing address (cold wallet), that person could create an unlimited amount of new issuances and trade them in the decentralized exchange. This would make it difficult to distinguish legitimately-obtained issuances and redeem them fairly. In this case, the institution must create a new issuing address, and all users with trust lines to the old issuing address must create new trust lines to the new address. Thus, it's best to keep the secret key to your issuing address as secure as possible.</p>
<h2 id="separation-of-roles">Separation of Roles</h2>
<p>The issuing account is like a vault. It serves as the asset issuer, and should remain offline. The secret key that is used for this account is kept offline, accessible to only a few trusted operators. Periodically, a human operator creates and signs a transaction (preferably from an entirely offline machine) in order to refill the operational account's balance. Because the issuing account is creating the issuances, customer accounts holding those issuances must create trust lines to the issuing account.</p>
<p>An operational account is like a cash register. It makes payments on behalf of the institution by sending issuances created by the issuing account. The secret key for an operational account is, by necessity, stored on a server that is connected to the outside internet, usually in a configuration file on a public-facing server. Because it holds issuances created by the issuing account, each operational account must create a trust line to the issuing account. Customers do not, and should not, trust operational accounts. An institution can use one or more operational accounts, but it's easiest to configure the financial institution's software to use just a single operational account.</p>
<p>(Unlike a cash register, an operational account does not have to handle incoming payments from users, because the issuing account can receive and monitor payments without using its secret key. To make things simple for your users, we recommend treating incoming payments to the operational and issuing accounts as the same.)</p>
<p>Each operational account has a limited balance of the issuances. If an operational account is compromised, the financial institution only loses as much currency as that operational account holds. Customers do not need to change any configuration in order to receive funds from a new operational account. However, the institution must monitor operational accounts balances so that those accounts don't run out of funds during ordinary operation.</p>
<h3 id="standby-accounts">Standby Accounts</h3>
<p>Another optional step that an institution can take to balance risk and convenience is to use "standby accounts" as an intermediate step between the issuing account and operational accounts. The institution can operate additional accounts as standby accounts, whose keys not stored online, but are entrusted to different trusted users.</p>
<p>When an operational account is running low on funds, a trusted user can use a standby accountto refill the operational account's balance. When the standby accounts run low on funds, the institution can use the issuing account to send more currency to a standby account in a single transaction, and the standby accounts can distribute that currency among themselves if necessary. This improves security of the issuing account, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.</p>
<p>As with operational accounts, standby accounts must trust the issuing account, and should not be trusted by users. All precautions that apply to operational accounts also apply to standby accounts.</p>
<p>The issuing address is like a vault. The secret keys used for this address should be kept offline, accessible to only a few trusted operators. The issuing address is responsible for creating issuances (any non-XRP currencies) in the Ripple Consensus Ledger. Customer addresses and operational addresses must create accounting relationships to the issuing address in order to hold those issuances.</p>
<p>Periodically, a human operator creates and signs a transaction from the issuing address in order to refill the balance of the operational address(es). Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.</p>
<p>An operational address is like a cash register. It makes payments on behalf of the institution by sending issuances created by the issuing address. The secret key for an operational address is, by necessity, stored on a server that is connected to the outside internet, usually in a configuration file. (The secret key can be stored encrypted, but the server must decrypt it in order to sign transactions.)</p>
<p>Customers do not, and should not, create accounting relationships (trust lines) to an operational address. An institution can use one or more operational addresses, but it's easiest to configure the financial institution's software to use just a single operational address.</p>
<p>(Unlike a cash register, an operational address does not have to handle incoming payments from users, because the issuing address can receive and monitor payments without using its secret key. To make things simple for customers, we recommend treating incoming payments to the operational and issuing addresses as the same.)</p>
<p>Each operational address has a limited balance of issuances. If an operational address's secret key is compromised, the financial institution only loses as much currency as that operational address holds. Customers do not need to change any configuration in order to receive funds from a new operational address.</p>
<p>The drawback to this separation of roles, aside from the initial setup, is that the institution must monitor operational the balances of operational addresses so that those addresses don't run out of funds during ordinary operation.</p>
<h3 id="standby-addresses">Standby Addresses</h3>
<p>Another optional step that an institution can take to balance risk and convenience is to use "standby addresses" as an intermediate step between the issuing address and operational addresses. The institution can fund additional Ripple addresses as standby addresses, whose keys are not stored online, but are entrusted to different trusted users.</p>
<p>When an operational address is running low on funds, a trusted user can use a standby address to refill the operational address's balance. When the standby addresses run low on funds, the institution can use the issuing address to send more currency to a standby address in a single transaction, and the standby addresses can distribute that currency among themselves if necessary. This improves security of the issuing address, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.</p>
<p>As with operational addresses, standby addresses must trust the issuing address, and should not be trusted by users. All precautions that apply to operational addresses also apply to standby addresses.</p>
</div>
</main>
</div>

2
concept-paths.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
concept-reserves.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
concept-transaction-cost.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
concept-transfer-fees.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

8
content/concept-freeze.md
View File

@@ -24,7 +24,7 @@ The **Individual Freeze** feature is a setting on a trust line. When an issuing
A gateway can freeze the trust line linking it to a counterparty if that counterparty shows suspicious activity or violates the gateway's terms of use. The gateway should also freeze the counterparty in any other systems the gateway operates that are connected to the Ripple Consensus Ledger. (Otherwise, an account might still be able to engage in undesired activity by sending payments through the gateway.)
An individual account can freeze its trust line to a gateway. This has no effect on transactions between the gateway and other users. It does, however, prevent other accounts, including [operational accounts](concept-issuing-and-operational-accounts.html), from sending that gateway's issued currency to the individual account. This type of individual freeze has no effect on offers.
An individual account can freeze its trust line to a gateway. This has no effect on transactions between the gateway and other users. It does, however, prevent other accounts, including [operational addresses](concept-issuing-and-operational-addresses.html), from sending that gateway's issued currency to the individual account. This type of individual freeze has no effect on offers.
The Individual Freeze applies to a single currency only. In order to freeze multiple currencies with a particular counterparty, the account must enable Individual Freeze on the trust lines for each currency individually.
@@ -36,13 +36,13 @@ Global Freeze
The **Global Freeze** feature is a setting on an account. When an issuing account enables the Global Freeze feature, the following rules apply:
* All counterparties of the frozen issuing account can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects any [operational accounts](concept-issuing-and-operational-accounts.html).)
* All counterparties of the frozen issuing account can no longer decrease the balances in their trust lines to the frozen account, except in direct payments to the issuer. (This also affects any [operational addresses](concept-issuing-and-operational-addresses.html).)
* Counterparties of the frozen issuing account can still send and receive payments directly to and from the issuing account.
* All offers to sell currencies issued by the frozen account are [considered unfunded](reference-transaction-format.html#lifecycle-of-an-offer).
It can be useful to enable Global Freeze on a gateway's [issuing account](concept-issuing-and-operational-accounts.html) if an operational account is compromised, or immediately after regaining control of a compromised issuing account. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. In addition to enacting a Global Freeze in the Ripple Consensus Ledger, a financial institution should also suspend activities in its connectors to outside systems.
It can be useful to enable Global Freeze on a gateway's [issuing account](concept-issuing-and-operational-addresses.html) if the secret key to an operational address is compromised, or immediately after regaining control of a such an address. This stops the flow of funds, preventing attackers from getting away with any more money or at least making it easier to track what happened. In addition to enacting a Global Freeze in the Ripple Consensus Ledger, a financial institution should also suspend activities in its connectors to outside systems.
It can also be useful to enable Global Freeze if a gateway intends to migrate to a new [issuing account](concept-issuing-and-operational-accounts.html), or if the gateway intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
It can also be useful to enable Global Freeze if a gateway intends to migrate to a new [issuing account](concept-issuing-and-operational-addresses.html), or if the gateway intends to cease doing business. This locks the funds at a specific point in time, so users cannot trade them away for other currencies.
Global Freeze applies to _all_ currencies issued and held by the account. You cannot enable Global Freeze for only one currency. If you want to have the ability to freeze some currencies and not others, you should use different accounts for each currency.

32
content/concept-issuing-and-operational-accounts.md
View File

@@ -1,32 +0,0 @@
# Issuing and Operational Accounts #
For any financial institution doing business using the Ripple Consensus Ledger, we strongly recommend that the institution use multiple Ripple ledger accounts with a separation of roles. This promotes strong security and minimizes risk. We recommend the following setup:
* An **issuing account** (also known as a "cold wallet") with high value, used as rarely as possible.
* One or more **operational accounts** (also known as a "hot wallets") with low value, used frequently by automated processes.
* Optional **standby accounts** (also known as "warm wallets"), used infrequently by human operators.
## The Risk ##
If a malicious person compromises a institution's issuing account (cold wallet), that person could create an unlimited amount of new issuances and trade them in the decentralized exchange. This would make it difficult to distinguish legitimately-obtained issuances and redeem them fairly. In this case, the institution must create a new issuing account, and all users with trust lines to the old issuing account must create new trust lines to the new account. Thus, it's best to keep your issuing account as secure as possible.
## Separation of Roles ##
The issuing account is like a vault. It serves as the asset issuer, and should remain offline. The secret key that is used for this account is kept offline, accessible to only a few trusted operators. Periodically, a human operator creates and signs a transaction (preferably from an entirely offline machine) in order to refill the operational account's balance. Because the issuing account is creating the issuances, customer accounts holding those issuances must create trust lines to the issuing account.
An operational account is like a cash register. It makes payments on behalf of the institution by sending issuances created by the issuing account. The secret key for an operational account is, by necessity, stored on a server that is connected to the outside internet, usually in a configuration file on a public-facing server. Because it holds issuances created by the issuing account, each operational account must create a trust line to the issuing account. Customers do not, and should not, trust operational accounts. An institution can use one or more operational accounts, but it's easiest to configure the financial institution's software to use just a single operational account.
(Unlike a cash register, an operational account does not have to handle incoming payments from users, because the issuing account can receive and monitor payments without using its secret key. To make things simple for your users, we recommend treating incoming payments to the operational and issuing accounts as the same.)
Each operational account has a limited balance of the issuances. If an operational account is compromised, the financial institution only loses as much currency as that operational account holds. Customers do not need to change any configuration in order to receive funds from a new operational account. However, the institution must monitor operational accounts balances so that those accounts don't run out of funds during ordinary operation.
### Standby Accounts ###
Another optional step that an institution can take to balance risk and convenience is to use "standby accounts" as an intermediate step between the issuing account and operational accounts. The institution can operate additional accounts as standby accounts, whose keys not stored online, but are entrusted to different trusted users.
When an operational account is running low on funds, a trusted user can use a standby accountto refill the operational account's balance. When the standby accounts run low on funds, the institution can use the issuing account to send more currency to a standby account in a single transaction, and the standby accounts can distribute that currency among themselves if necessary. This improves security of the issuing account, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.
As with operational accounts, standby accounts must trust the issuing account, and should not be trusted by users. All precautions that apply to operational accounts also apply to standby accounts.

37
content/concept-issuing-and-operational-addresses.md Normal file
View File

@@ -0,0 +1,37 @@
# Issuing and Operational Addresses #
For any financial institution doing business using the Ripple Consensus Ledger, we strongly recommend that the institution use multiple Ripple ledger addresses with a separation of roles. This promotes strong security and minimizes risk. We recommend the following setup:
* An **issuing address** (also known as a "cold wallet") with high value, used as rarely as possible.
* One or more **operational addresses** (also known as a "hot wallets") with low value, used frequently by automated processes.
* Optional **standby addresses** (also known as "warm wallets"), used infrequently by human operators.
## The Risk ##
If a malicious person learns the secret key behind a institution's issuing address (cold wallet), that person could create an unlimited amount of new issuances and trade them in the decentralized exchange. This would make it difficult to distinguish legitimately-obtained issuances and redeem them fairly. In this case, the institution must create a new issuing address, and all users with trust lines to the old issuing address must create new trust lines to the new address. Thus, it's best to keep the secret key to your issuing address as secure as possible.
## Separation of Roles ##
The issuing address is like a vault. The secret keys used for this address should be kept offline, accessible to only a few trusted operators. The issuing address is responsible for creating issuances (any non-XRP currencies) in the Ripple Consensus Ledger. Customer addresses and operational addresses must create accounting relationships to the issuing address in order to hold those issuances.
Periodically, a human operator creates and signs a transaction from the issuing address in order to refill the balance of the operational address(es). Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.
An operational address is like a cash register. It makes payments on behalf of the institution by sending issuances created by the issuing address. The secret key for an operational address is, by necessity, stored on a server that is connected to the outside internet, usually in a configuration file. (The secret key can be stored encrypted, but the server must decrypt it in order to sign transactions.)
Customers do not, and should not, create accounting relationships (trust lines) to an operational address. An institution can use one or more operational addresses, but it's easiest to configure the financial institution's software to use just a single operational address.
(Unlike a cash register, an operational address does not have to handle incoming payments from users, because the issuing address can receive and monitor payments without using its secret key. To make things simple for customers, we recommend treating incoming payments to the operational and issuing addresses as the same.)
Each operational address has a limited balance of issuances. If an operational address's secret key is compromised, the financial institution only loses as much currency as that operational address holds. Customers do not need to change any configuration in order to receive funds from a new operational address.
The drawback to this separation of roles, aside from the initial setup, is that the institution must monitor operational the balances of operational addresses so that those addresses don't run out of funds during ordinary operation.
### Standby Addresses ###
Another optional step that an institution can take to balance risk and convenience is to use "standby addresses" as an intermediate step between the issuing address and operational addresses. The institution can fund additional Ripple addresses as standby addresses, whose keys are not stored online, but are entrusted to different trusted users.
When an operational address is running low on funds, a trusted user can use a standby address to refill the operational address's balance. When the standby addresses run low on funds, the institution can use the issuing address to send more currency to a standby address in a single transaction, and the standby addresses can distribute that currency among themselves if necessary. This improves security of the issuing address, allowing it to make fewer total transactions, without leaving too much money in the control of a single automated system.
As with operational addresses, standby addresses must trust the issuing address, and should not be trusted by users. All precautions that apply to operational addresses also apply to standby addresses.

3
content/data_types/ledger_index.md
View File

@@ -1,6 +1,7 @@
A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is also known as the ledger's sequence number. The very first ledger was ledger index 1, and each subsequent ledger has a ledger index 1 higher than that of the ledger immediately before it.
The ledger index indicates the order of the ledgers; the [Hash][] value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For closed ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:
The ledger index indicates the order of the ledgers; the [Hash][] value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:
* Two different `rippled` servers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network.
* There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same sequence number but different contents (and different hashes). Only one of these closed ledgers can become validated.
* A current ledger's contents change over time, which would cause its hash to change, even though its ledger index number stays the same. Therefore, the hash of a ledger is not calculated until the ledger is closed.

6
content/reference-data-api.md
View File

@@ -1883,8 +1883,8 @@ A successful response uses the HTTP code **200 OK** and has a JSON body with the
|-------------|--------|-------------|
| name | String | Human-readable name of the gateway
| start\_date | String - [Timestamp][] | The approximate date of the first time exchanges for this gateway's currencies appeared in the ledger. |
| accounts | Array | A list of [issuing accounts](concept-issuing-and-operational-accounts.html) (cold wallets) used by this gateway. (Gateways may use different issuing accounts for different currencies.) |
| hotwallets | Array of [Address][]es | The addresses of the Ripple accounts this gateway uses as [operational accounts](concept-issuing-and-operational-accounts.html). |
| accounts | Array | A list of [issuing addresses](concept-issuing-and-operational-addresses.html) (cold wallets) used by this gateway. (Gateways may use different issuing accounts for different currencies.) |
| hotwallets | Array of [Address][]es | The addresses of the Ripple accounts this gateway uses as [operational addresses](concept-issuing-and-operational-addresses.html) (hot wallets). |
| domain | String | The domain name where this gateway does business. Typically the gateway hosts a [`ripple.txt`](https://wiki.ripple.com/Ripple.txt) there. |
| normalized | String | A normalized version of the `name` field suitable for including in URLs. |
| assets | Array of Strings | Graphics filenames available for this gateway, if any. (Mostly, these are logos used by Ripple Charts.) |
@@ -1893,7 +1893,7 @@ Each object in the `accounts` field array has the following fields:
| Field | Value | Description |
|------------|--------|-------------|
| address | String | The [Address][] of an [issuing account](concept-issuing-and-operational-accounts.html) (cold wallet) used by this gateway. |
| address | String | The [Address][] of an [issuing address](concept-issuing-and-operational-addresses.html) (cold wallet) used by this gateway. |
| currencies | Object | Each field in this object is a [Currency Code][] corresponding to a currency issued from this address. Each value is an object with a `featured` boolean indicating whether that currency is featured. Ripple, Inc. decides which currencies and gateways to feature based on responsible business practices, volume, and other measures. |
#### Example ####

8
content/tutorial-gateway-guide.md
View File

@@ -67,11 +67,11 @@ The value of a gateway's issuances in Ripple comes directly from users' trust th
We strongly recommend that gateways use multiple Ripple ledger accounts with a separation of roles. This promotes strong security and minimizes risk. We recommend the following setup:
* An **issuing account** (also known as a "cold wallet") with high value, used as rarely as possible.
* One or more **operational accounts** (also known as a "hot wallets") with low value, used frequently by automated processes.
* Optional **standby accounts** (also known as "warm wallets"), used infrequently by human operators.
* An **issuing address** (also known as a "cold wallet") with high value, used as rarely as possible.
* One or more **operational addresses** (also known as a "hot wallets") with low value, used frequently by automated processes.
* Optional **standby addresses** (also known as "warm wallets"), used infrequently by human operators.
For more information, see [Issuing and Operational Accounts](concept-issuing-and-operational-accounts.html)
For more information, see [Issuing and Operational Addresses](concept-issuing-and-operational-addresses.html)
### Funds Lifecycle ###

2
data-api-v2-tool.html
View File

@@ -63,7 +63,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

4
index.html
View File

@@ -70,7 +70,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>
@@ -154,7 +154,7 @@ Ripple’s distributed settlement network is built on open-source technology tha
<div class="col-md-3">
<ul>
<li class="top"><h5 class="dev_heading">Best Practices</h5></li>
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</div>

11
reference-data-api.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>
@@ -2803,12 +2803,12 @@
<tr>
<td>accounts</td>
<td>Array</td>
<td>A list of <a href="concept-issuing-and-operational-accounts.html">issuing accounts</a> (cold wallets) used by this gateway. (Gateways may use different issuing accounts for different currencies.)</td>
<td>A list of <a href="concept-issuing-and-operational-addresses.html">issuing addresses</a> (cold wallets) used by this gateway. (Gateways may use different issuing accounts for different currencies.)</td>
</tr>
<tr>
<td>hotwallets</td>
<td>Array of <a href="#addresses">Address</a>es</td>
<td>The addresses of the Ripple accounts this gateway uses as <a href="concept-issuing-and-operational-accounts.html">operational accounts</a>.</td>
<td>The addresses of the Ripple accounts this gateway uses as <a href="concept-issuing-and-operational-addresses.html">operational addresses</a> (hot wallets).</td>
</tr>
<tr>
<td>domain</td>
@@ -2840,7 +2840,7 @@
<tr>
<td>address</td>
<td>String</td>
<td>The <a href="#addresses">Address</a> of an <a href="concept-issuing-and-operational-accounts.html">issuing account</a> (cold wallet) used by this gateway.</td>
<td>The <a href="#addresses">Address</a> of an <a href="concept-issuing-and-operational-addresses.html">issuing address</a> (cold wallet) used by this gateway.</td>
</tr>
<tr>
<td>currencies</td>
@@ -4760,9 +4760,10 @@ Content-Type: image/svg+xml
<p>(As of <a href="https://github.com/ripple/rippled-historical-database/releases/tag/v2.0.4">v2.0.4</a>, the offset <code>+00:00</code> is no longer used.)</p>
<h3 id="ledger-index">Ledger Index</h3>
<p>A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is also known as the ledger's sequence number. The very first ledger was ledger index 1, and each subsequent ledger has a ledger index 1 higher than that of the ledger immediately before it.</p>
<p>The ledger index indicates the order of the ledgers; the <a href="#hashes">Hash</a> value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For closed ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:</p>
<p>The ledger index indicates the order of the ledgers; the <a href="#hashes">Hash</a> value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:</p>
<ul>
<li>Two different <code>rippled</code> servers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network.</li>
<li>There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same sequence number but different contents (and different hashes). Only one of these closed ledgers can become validated.</li>
<li>A current ledger's contents change over time, which would cause its hash to change, even though its ledger index number stays the same. Therefore, the hash of a ledger is not calculated until the ledger is closed.</li>
</ul>
<h3 id="account-sequence">Account Sequence</h3>

2
reference-ledger-format.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
reference-rippleapi.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

5
reference-rippled.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>
@@ -568,9 +568,10 @@ Null method
<p>Every <a href="reference-ledger-format.html#offer">Offer node in the Ripple Consensus Ledger</a> is marked with the sending <code>Account</code> <a href="#addresses">Address</a> and the <code>Sequence</code> value of the <a href="reference-transaction-format.html#offercreate">OfferCreate transaction</a> that created it. These two fields, together, uniquely identify the Offer.</p>
<h3 id="ledger-index">Ledger Index</h3>
<p>A ledger index is a 32-bit unsigned integer used to identify a ledger. The ledger index is also known as the ledger's sequence number. The very first ledger was ledger index 1, and each subsequent ledger has a ledger index 1 higher than that of the ledger immediately before it.</p>
<p>The ledger index indicates the order of the ledgers; the <a href="#hashes">Hash</a> value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For closed ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:</p>
<p>The ledger index indicates the order of the ledgers; the <a href="#hashes">Hash</a> value identifies the exact contents of the ledger. Two ledgers with the same hash are always identical. For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1. However, this is not true for in-progress ledgers:</p>
<ul>
<li>Two different <code>rippled</code> servers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network.</li>
<li>There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same sequence number but different contents (and different hashes). Only one of these closed ledgers can become validated.</li>
<li>A current ledger's contents change over time, which would cause its hash to change, even though its ledger index number stays the same. Therefore, the hash of a ledger is not calculated until the ledger is closed.</li>
</ul>
<h3 id="specifying-ledgers">Specifying Ledgers</h3>

2
reference-transaction-format.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
ripple-api-tool.html
View File

@@ -63,7 +63,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
tool-jsonrpc.html
View File

@@ -63,7 +63,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

6
tool/devportal-config.yml
View File

@@ -147,10 +147,10 @@ pages:
sidebar: true
# "Best Practices" documents are mostly in the same category as tutorials
- name: Issuing and Operational Acounts
- name: Issuing and Operational Addresses
category: Best Practices
html: concept-issuing-and-operational-accounts.html
md: concept-issuing-and-operational-accounts.md
html: concept-issuing-and-operational-addresses.html
md: concept-issuing-and-operational-addresses.md
# TODO publish this article separately on the website
ripple.com: https://ripple.com/build/gateway-guide/#hot-and-cold-wallets
sidebar: true

12
tutorial-gateway-guide.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>
@@ -110,7 +110,7 @@
<div id="cont">
<ul class="dev_nav_sidebar">
<li class="level-1"><a href="index.html">Category: Best Practices</a></li>
<li class="level-2"><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li class="level-2"><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li class="level-2"><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
<hr/>
@@ -166,11 +166,11 @@
<h3 id="hot-and-cold-wallets">Hot and Cold Wallets</h3>
<p>We strongly recommend that gateways use multiple Ripple ledger accounts with a separation of roles. This promotes strong security and minimizes risk. We recommend the following setup:</p>
<ul>
<li>An <strong>issuing account</strong> (also known as a "cold wallet") with high value, used as rarely as possible.</li>
<li>One or more <strong>operational accounts</strong> (also known as a "hot wallets") with low value, used frequently by automated processes.</li>
<li>Optional <strong>standby accounts</strong> (also known as "warm wallets"), used infrequently by human operators.</li>
<li>An <strong>issuing address</strong> (also known as a "cold wallet") with high value, used as rarely as possible.</li>
<li>One or more <strong>operational addresses</strong> (also known as a "hot wallets") with low value, used frequently by automated processes.</li>
<li>Optional <strong>standby addresses</strong> (also known as "warm wallets"), used infrequently by human operators.</li>
</ul>
<p>For more information, see <a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Accounts</a></p>
<p>For more information, see <a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></p>
<h3 id="funds-lifecycle">Funds Lifecycle</h3>
<p>Funds in Ripple tend to flow in a cycle, from the cold wallet to the warm wallets, then the warm wallets, to customers, and eventually from customers back to the cold wallet. Issuances (any non-XRP balance in Ripple) are always tied to a trust line, so each payment "ripples" through ACME's issuing account on the trust lines connected to it. Ultimately, the lifecycle of issuances in Ripple looks something like this:</p>
<p><img alt="Funds flow diagram" src="img/e2g-funds_flow.png"/></p>

2
tutorial-reliable-transaction-submission.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
tutorial-rippleapi-beginners-guide.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>

2
tutorial-rippled-setup.html
View File

@@ -77,7 +77,7 @@
<li class="dropdown">
<a class="dropdown-toggle" data-toggle="dropdown" href="#">Best Practices <span class="caret"></span></a>
<ul class="dropdown-menu" role="menu">
<li><a href="concept-issuing-and-operational-accounts.html">Issuing and Operational Acounts</a></li>
<li><a href="concept-issuing-and-operational-addresses.html">Issuing and Operational Addresses</a></li>
<li><a href="tutorial-gateway-guide.html">Gateway Guide</a></li>
</ul>
</li>