New Crowdin updates

account-types.md

@@ -0,0 +1,84 @@
+---
+html: account-types.html
+parent: accounts.html
+seo:
+    description: Businesses sending transactions on the XRP Ledger automatically should set up separate addresses for different purposes to minimize risk.
+labels:
+  - Tokens
+  - Security
+---
+# Account Types
+
+{% partial file="/docs/_snippets/issuing-and-operational-addresses-intro.md" /%}
+
+
+## Funds Lifecycle
+
+When a token issuer follows this separation of roles, funds tend to flow in specific directions, as in the following diagram:
+
+[{% inline-svg file="/docs/img/issued-currency-funds-flow.svg" /%}](/docs/img/issued-currency-funds-flow.svg "Diagram: Funds flow from the issuing address to standby addresses, to operational addresses, to customer and partner addresses, and finally back to the issuing address.")
+
+The issuing address creates tokens by sending payments to standby addresses. These tokens have negative value from the perspective of the issuing address, since they (often) represent obligations. The same tokens have positive value from other perspectives, including from the perspective of a standby address.
+
+The standby addresses, which are operated by actual humans, send those tokens to operational addresses. This step allows the issuing address to be used as little as possible after this point, while having at least some tokens available on standby.
+
+Operational addresses, which are operated by automated systems, send payments to other counterparties, such as liquidity providers, partners, and other customers. Those counterparties may send funds freely among themselves multiple times.
+
+As always, token payments must "ripple through" the issuer across trust lines.
+
+Eventually, someone sends tokens back to the issuer. This destroys those tokens, reducing the issuer's obligations in the XRP Ledger. If the token is a stablecoin, this is the first step of redeeming the tokens for the corresponding off-ledger assets.
+
+
+## Issuing Address
+
+The issuing address is like a vault. Partners, customers, and operational addresses create 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 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.
+
+Unlike a vault, the issuing address can receive payments directly from customers and partners. Since all transactions in the XRP Ledger are public, automated systems can watch for payments to the issuing address without needing a secret key.
+
+### Issuing Address Compromise
+
+If a malicious actor learns the secret key behind a institution's issuing address, that actor can create new tokens and send them to users or trade them in the decentralized exchange. This can make a stablecoin issuer insolvent. It can become difficult for the financial institution to distinguish legitimately-obtained tokens 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 trust lines to the old issuing address must create new trust lines with the new address.
+
+### Multiple Issuing Addresses
+
+A financial institution can issue more than one type of token in the XRP Ledger from a single issuing address. However, there are some settings that apply equally to all (fungible) tokens issued from an address, including the percentage for [transfer fees](../tokens/transfer-fees.md) and the [global freeze](../tokens/fungible-tokens/freezes.md) status. If the financial institution wants the flexibility to manage settings differently for each type of token, the institution must multiple issuing addresses.
+
+
+## Operational Addresses
+
+An operational address is like a cash register. It makes payments on behalf of the institution by transferring tokens to customers and partners. To sign transactions automatically, the secret key for an operational address must be stored on a server that is connected to the internet. (The secret key can be stored encrypted, but the server must decrypt it to sign transactions.) Customers and partners do not, and should not, create trust lines to an operational address.
+
+Each operational address has a limited balance of tokens and XRP. 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 actor learns the secret key behind an operational address, the financial institution can only lose as much 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 XRP Ledger addresses as standby addresses, whose keys are not available to always-online servers, but are entrusted to different trusted users.
+
+When an operational address is running low on funds (either tokens or XRP), 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 funds to a standby address in a single transaction, and the standby addresses can distribute those funds 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, a standby address must have an accounting relationship with the issuing address, and not with customers or partners. All precautions that apply to operational addresses also apply to standby addresses.
+
+### Standby Address Compromise
+
+If a standby address is compromised, the consequences are like an operational address being compromised. A malicious actor can steal any balances possessed by the standby address, and the financial institution can change to a new standby address with no action from customers and partners.
+
+
+## See Also
+
+- **Concepts:**
+    - [Accounts](index.md)
+    - [Cryptographic Keys](cryptographic-keys.md)
+- **Tutorials:**
+    - [Assign a Regular Key Pair](../../tutorials/how-tos/manage-account-settings/assign-a-regular-key-pair.md)
+    - [Change or Remove a Regular Key Pair](../../tutorials/how-tos/manage-account-settings/change-or-remove-a-regular-key-pair.md)
+- **References:**
+    - [account_info method][]
+    - [SetRegularKey transaction][]
+    - [AccountRoot object](../../references/protocol/ledger-data/ledger-entry-types/accountroot.md)
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}

addresses.md

@@ -0,0 +1,96 @@
+---
+html: addresses.html
+parent: accounts.html
+seo:
+    description: Addresses uniquely identify XRP Ledger accounts, using base58 format.
+labels:
+  - Accounts
+---
+# Addresses
+
+{% partial file="/docs/_snippets/data_types/address.md" /%}
+
+Any valid address can [become an account in the XRP Ledger](index.md#creating-accounts) by being funded. You can also use an address that has not been funded to represent a [regular key](cryptographic-keys.md) or a member of a [signer list](multi-signing.md). Only a funded account can be the sender of a transaction.
+
+Creating a valid address is a strictly mathematical task starting with a key pair. You can generate a key pair and calculate its address entirely offline without communicating to the XRP Ledger or any other party. The conversion from a public key to an address involves a one-way hash function, so it is possible to confirm that a public key matches an address but it is impossible to derive the public key from the address alone. (This is part of the reason why signed transactions include the public key _and_ the address of the sender.)
+
+
+## Special Addresses
+
+Some addresses have special meaning, or historical uses, in the XRP Ledger. In many cases, these are "black hole" addresses, meaning the address is not derived from a known secret key. Since it is effectively impossible to guess a secret key from only an address, any XRP possessed by black hole addresses is lost forever.
+
+
+| Address                       | Name | Meaning | Black Hole? |
+|-------------------------------|------|---------|-------------|
+| `rrrrrrrrrrrrrrrrrrrrrhoLvTp` | ACCOUNT\_ZERO | An address that is the XRP Ledger's [base58][] encoding of the value `0`. In peer-to-peer communications, `rippled` uses this address as the issuer for XRP. | Yes |
+| `rrrrrrrrrrrrrrrrrrrrBZbvji`  | ACCOUNT\_ONE | An address that is the XRP Ledger's [base58][] encoding of the value `1`. In the ledger, [RippleState entries](../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) use this address as a placeholder for the issuer of a trust line balance. | Yes |
+| `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` | The genesis account | When `rippled` starts a new genesis ledger from scratch (for example, in stand-alone mode), this account holds all the XRP. This address is generated from the seed value `masterpassphrase` which is [hard-coded](https://github.com/XRPLF/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184). | No |
+| `rrrrrrrrrrrrrrrrrNAMEtxvNvQ` | Ripple Name reservation black-hole | In the past, Ripple asked users to send XRP to this account to reserve Ripple Names.| Yes |
+| `rrrrrrrrrrrrrrrrrrrn5RM1rHd` | NaN Address | Previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) generated this address when encoding the value [NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN) using the XRP Ledger's [base58][] string encoding format. | Yes |
+
+
+## Address Encoding
+
+**Tip:** These technical details are only relevant for people building low-level library software for XRP Ledger compatibility!
+
+[[Source]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
+
+XRP Ledger addresses are encoded using [base58][] with the _dictionary_ `rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`. Since the XRP Ledger encodes several types of keys with base58, it prefixes the encoded data with a one-byte "type prefix" (also called a "version prefix") to distinguish them. The type prefix causes addresses to usually start with different letters in base58 format.
+
+The following diagram shows the relationship between keys and addresses:
+
+[{% inline-svg file="/docs/img/address-encoding.svg" /%}](/docs/img/address-encoding.svg "Master Public Key + Type Prefix → Account ID + Checksum → Address")
+
+The formula for calculating an XRP Ledger address from a public key is as follows. For the complete example code, see [`encode_address.js`](https://github.com/XRPLF/xrpl-dev-portal/blob/master/_code-samples/address_encoding/js/encode_address.js). For the process of deriving a public key from a passphrase or seed value, see [Key Derivation](cryptographic-keys.md#key-derivation).
+
+1. Import required algorithms: SHA-256, RIPEMD160, and base58. Set the dictionary for base58.
+
+    ```
+    'use strict';
+    const assert = require('assert');
+    const crypto = require('crypto');
+    const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
+    const base58 = require('base-x')(R_B58_DICT);
+
+    assert(crypto.getHashes().includes('sha256'));
+    assert(crypto.getHashes().includes('ripemd160'));
+    ```
+
+2. Start with a 33-byte ECDSA secp256k1 public key, or a 32-byte Ed25519 public key. For Ed25519 keys, prefix the key with the byte `0xED`.
+
+    ```
+    const pubkey_hex =
+      'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
+    const pubkey = Buffer.from(pubkey_hex, 'hex');
+    assert(pubkey.length == 33);
+    ```
+
+3. Calculate the [RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD) hash of the SHA-256 hash of the public key. This value is the "Account ID".
+
+    ```
+    const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
+    const pubkey_outer_hash = crypto.createHash('ripemd160');
+    pubkey_outer_hash.update(pubkey_inner_hash.digest());
+    const account_id = pubkey_outer_hash.digest();
+    ```
+
+4. Calculate the SHA-256 hash of the SHA-256 hash of the Account ID; take the first 4 bytes. This value is the "checksum".
+
+    ```
+    const address_type_prefix = Buffer.from([0x00]);
+    const payload = Buffer.concat([address_type_prefix, account_id]);
+    const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
+    const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
+    const checksum =  chksum_hash2.slice(0,4);
+    ```
+
+5. Concatenate the payload and the checksum. Calculate the base58 value of the concatenated buffer. The result is the address.
+
+    ```
+    const dataToEncode = Buffer.concat([payload, checksum]);
+    const address = base58.encode(dataToEncode);
+    console.log(address);
+    // rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
+    ```
+
+{% raw-partial file="/docs/_snippets/common-links.md" /%}