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

issuing/op address doc - peer review revisions

Browse Source
This commit is contained in:
mDuo13
2016-03-18 17:52:44 -07:00
parent c310d255b5
commit dddaad56b1
2 changed files with 46 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
content/concept-issuing-and-operational-addresses.md
View File

@@ -1,37 +1,44 @@
# 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:
All non-XRP currency balances (issuances) in the Ripple Consensus Ledger (RCL) are tied to accounting relationships between two Ripple addresses. To control an address in the RCL, you only need the secret key mathematically connected to that address. Since no party can unilaterally prevent transactions or correct the ledger, financial institutions typically use multiple Ripple ledger addresses to minimize the risk associated with a compromised secret key. Ripple strongly recommends the following separation of roles:
* 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.
* One **issuing address**, also known as a "cold wallet." This address is the hub of the financial institution's accounting relationships in the ledger, but sends as few transactions as possible.
* One or more **operational addresses**, also known as "hot wallets." Automated, internet-connected systems use the secret keys to these addresses to conduct day-to-day business like transfers to customers.
* Optional **standby addresses**, also known as "warm wallets." Trusted human operators use these addresses to transfer money to the operational addresses.
## Separation of Roles ##
## Issuing Address ##
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.
The issuing address is like a vault. Customer addresses and operational addresses create accounting relationships (trust lines) to the issuing address, but this address sends as few transactions as possible. Periodically, a human operator creates and signs a transaction from the issuing address in order to refill the balances of a standby or operational address. Ideally, the secret key used to sign these transactions should never be accessible from any internet-connected computer.
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.
Balances sent by the issuing address are positive from the perspective of the customers, operational addresses, and standby addresses. The same balances are negative from the perspective of the issuing address, since they represent obligations. When the issuing address receives a payment, this reduces its obligations, effectively "destroying" the issuances that were sent.
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.)
Unlike a vault, the issuing address can receive payments directly from customers. Since all transactions in the Ripple Consensus Ledger are public, automated systems can monitor for payments to the issuing address without needing a secret key.
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.
### Issuing Address Compromise ###
(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.)
If a malicious person learns the secret key behind a institution's issuing address, that person can create new issuances without limit and trade them in the decentralized exchange. This would make it difficult for the financial institution to distinguish legitimately-obtained issuances and redeem them fairly. If a financial institution loses control of its issuing address, the institution must create a new issuing address, and all users who have accounting relationships with the old issuing address must create new accounting relationships with the new address.
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.
### Multiple Issuing Addresses ###
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.
If a financial institution issues more than one currency in the Ripple Consensus Ledger, the institution may choose to use a different issuing address for each currency. This provides the flexibility to separately [enable a global freeze](concept-freeze.html) and set [transfer fees](concept-transfer-fees.html) for each currency.
### Standby Addresses ###
## Operational Addresses ##
An operational address is like a cash register. It makes payments on behalf of the institution by transferring issuances to customers. 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 with an operational address.
Each operational address has a limited balance of issuances. When the balance of an operational address gets low, the financial institution refills it by sending a payment from the issuing address or a standby address.
### Operational Address Compromise ###
If a malicious user learns the secret key behind an operational address, the financial institution can only lose as much currency as that operational address holds. The institution can switch to a new operational address with no action from customers and partners.
## 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.
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 a 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.
As with operational addresses, a standby address must have an accounting relationship with the issuing address, and not with customers. All precautions that apply to operational addresses also apply to standby addresses.