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

Merge branch 'master' of https://github.com/JakeatRipple/xrpl-dev-portal into feat-use-cases

Browse Source 
# Conflicts:
#	assets/css/devportal2022-v13.css
#	styles/light/_light-theme.scss
This commit is contained in:
Jake
2023-01-09 15:33:11 -07:00
parent 7e03cdae2c dec031a6eb
commit 6c8e8c2140
224 changed files with 4272 additions and 1528 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
.github/workflows/link-checker-pr.yml vendored
View File

@@ -12,10 +12,10 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/checkout@v3
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
uses: actions/setup-python@v4
with:
python-version: "3.9"
@@ -43,7 +43,7 @@ jobs:
run: |
sed -i '1,/---------------------------------------/d' linkreport.txt
echo 'LINKREPORT<<EOF' >> $GITHUB_ENV
cat linkreport.txt >> $GITHUB_ENV
head -c 65300 linkreport.txt >> $GITHUB_ENV
echo 'EOF' >> $GITHUB_ENV
cat linkreport.txt

26
CONTRIBUTING.md
View File

@@ -129,6 +129,32 @@ Use the following conventions when creating a page:
- Landing pages should be in subfolders and should have the same filename as the folder. For example, the landing page of the "Accounts" page group should be `accounts/accounts.md` with the HTML filename `accounts.html`. **Don't** use `index.md`.
- Don't use tab characters for indentation in Markdown or code samples. Use **4 spaces per indent**, except in **JavaScript** code samples, which should use 2 spaces per indent.
### Terminology
Use the following words and phrases as described:
| Term | Terms to Avoid | Notes |
|-------------------|----------------|-------|
| API, APIs | API's, RPC | Application Programming Interface, a set of functions and definitions for software to connect to other software. |
| core server, core XRP Ledger server | `rippled` | The `rippled` name is probably going to be retired in the near future, so it's better to refer to it by the more generic name. When necessary, refer to `rippled` in all lowercase and code font. (It's pronounced "ripple dee", and the "d" stands for "daemon" per UNIX tradition.)
| financial institution | bank, FI, PSP (payment services provider) | This term encompasses a wider range of businesses than just _bank_ or other terms and does not rely on an understanding of industry jargon. |
| ledger entry | ledger object, node | A single object inside the state data of the XRP Ledger. The term _ledger object_ could refer to one of these or to the whole ledger. The term _node_ was sometimes used for this case because the ledger's state data can be envisioned as a graph, but this is confusing because _node_ has other uses. |
| liquidity provider | market maker | A business or individual who offers to exchange between two currencies or assets, often deriving income from the price differential between trades. The term _market maker_ has a specific legal definition in some jurisdictions and may not apply in all the same circumstances. |
| malicious actor | hacker | A person, organization, or even an automated tool which might attempt to acquire secrets, break encryption, deny service, or otherwise attack a secure resource. |
| a NFToken | NFT, an NFToken | A NFToken object in the XRP Ledger tracks or represents a non-fungible token. Pronounced "nif-token" and written _a NFToken_ rather than _an NFToken_ |
| PostgreSQL | Postgres | A specific brand of relational database software. Always use the full name, not an informal short version. |
| order book | orderbook, offer book | A collection of trade orders waiting to be matched and executed, typically sorted by exchange rate. Use two words. |
| server | node | A server is software and/or hardware, especially the ones that connect to the XRP Ledger peer-to-peer network. The term _node_ is sometimes used for this purpose but is also overloaded with other meanings including entries in a graph and Node.js, a JavaScript interpreter. |
| stablecoin issuer | gateway | An issuer is the organization that issues a token in the XRP Ledger. A stablecoin is a token where the issuer promises that it is fully backed by some outside asset (such as fiat currency), with the stablecoin issuer providing deposit and withdraw operations to convert between the two (possibly for a fee). Previously the term _gateway_ was used (especially by Ripple, the company) to describe this use case, but the rest of the industry adopted _stablecoin issuer_ instead. |
| transaction cost | transaction fee | The amount of XRP burnt to send a transaction in the XRP Ledger. Even though this is specified in the `Fee` field of transactions, the term _fee_ implies that the money is paid to someone, so _cost_ is preferable. |_
| trust line | trustline | Use two words. A trust line is a relationship between two accounts in the XRP Ledger that tracks a balance of tokens between those accounts. |
| tokens | IOUs, issuances, issues, issued currencies | A token in the XRP ledger may not represent money owed outside of the ledger as the name _IOU_ implies. Specify _fungible tokens_ if necessary to distinguish from non-fungible tokens. |
| wallet | wallet | Depending on the context, _wallet_ could refer to hardware, software, a cryptographic key pair, or an online service. Be sure to provide enough context that the meaning is clear, or use an alternative such as _key pair_ or _client application_. |
| WebSocket | web socket, Websockets | A two way protocol for communication on the web. Always singular and in CamelCase. |
| XRP | XRPs, ripples | The native digital asset, or cryptocurrency, of the XRP Ledger. XRP is not a token. |
| the XRP Ledger | XRP Ledger (no the), Ripple, Ripple Network, RCL | The XRP Ledger was called _the Ripple network_ and the _Ripple Consensus Ledger_ or _RCL_ at various times in the past. These names were confusing and have been retired because of their similarity to the name of the company, Ripple (formerly Ripple Labs) which develops the reference implementation of the core server. |
| XRPL | XRPL | Short for _XRP Ledger_. As much as possible, spell out _XRP Ledger_ instead; _XRPL_ is cryptic and looks like it could be a typo for _XRP_. |
## Translations

4
assets/css/devportal2022-v11b.css → assets/css/devportal2022-v13.css
View File

File diff suppressed because one or more lines are too long

44
assets/js/apitool-methods-ws.js
View File

@@ -1,5 +1,6 @@
DEFAULT_ADDRESS_1 = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
DEFAULT_ADDRESS_2 = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
TST_ISSUER = "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
Request("Account Methods")
@@ -291,20 +292,19 @@ Request('ledger_entry - DepositPreauth', {
}
})
// Waiting for TicketBatch amendment on Mainnet
// Request('ledger_entry - Ticket', {
// description: "Returns a Ticket object in its raw ledger format.",
// link: "ledger_entry.html#get-ticket-object",
// body: {
// "id": "example_get_ticket",
// "command": "ledger_entry",
// "ticket": {
// "owner": DEFAULT_ADDRESS_1,
// "ticket_sequence": 0 // TODO: make a real ticket, fill in the seq
// },
// "ledger_index": "validated"
// }
// })
Request('ledger_entry - Ticket', {
description: "Returns a Ticket object in its raw ledger format.",
link: "ledger_entry.html#get-ticket-object",
body: {
"id": "example_get_ticket",
"command": "ledger_entry",
"ticket": {
"account": DEFAULT_ADDRESS_1,
"ticket_seq": 389 // This is a real ticket on Mainnet.
},
"ledger_index": "validated"
}
})
Request("Transaction Methods")
@@ -475,6 +475,22 @@ Request('ripple_path_find', {
}
})
Request('amm_info', {
description: "Looks up info on an Automated Market Maker instance.",
link: "amm_info.html",
status: "not_enabled",
body: {
"command": "amm_info",
"asset": {
"currency": "XRP"
},
"asset2": {
"currency": "TST",
"issuer": TST_ISSUER
}
}
})
Request("Payment Channel Methods")
Request('channel_authorize', {

33
assets/js/test-net.js → assets/js/faucet.js
View File

@@ -27,7 +27,7 @@ async function wait_for_seq(network_url, address) {
}
function rippleTestNetCredentials(url, altnet_name) {
function TestNetCredentials(url, altnet_name, ws_url) {
const credentials = $('#your-credentials')
const address = $('#address')
@@ -72,13 +72,7 @@ function rippleTestNetCredentials(url, altnet_name) {
balance.hide().html('<h3>Balance</h3> ' +
Number(data.amount).toLocaleString('en') + ' XRP').fadeIn('fast')
sequence.html('<h3>Sequence</h3> <img class="throbber" src="assets/img/xrp-loader-96.png"> Waiting...').fadeIn('fast')
if (altnet_name=="Testnet") {
wait_for_seq("wss://s.altnet.rippletest.net:51233", test_wallet.address)
} else if (altnet_name=="NFT-Devnet") {
wait_for_seq("wss://xls20-sandbox.rippletest.net:51233", test_wallet.address)
} else {
wait_for_seq("wss://s.devnet.rippletest.net:51233", test_wallet.address)
}
wait_for_seq(ws_url, test_wallet.address)
},
error: function() {
@@ -89,20 +83,11 @@ function rippleTestNetCredentials(url, altnet_name) {
}
$(document).ready(function() {
function testnet_click(evt) {
rippleTestNetCredentials("https://faucet.altnet.rippletest.net/accounts",
"Testnet")
}
function devnet_click(evt) {
rippleTestNetCredentials("https://faucet.devnet.rippletest.net/accounts",
"Devnet")
}
function nftnet_click(evt) {
rippleTestNetCredentials("https://faucet-nft.ripple.com/accounts",
"NFT-Devnet")
}
$('#testnet-creds-button').click(testnet_click)
$('#devnet-creds-button').click(devnet_click)
$('#nftnet-creds-button').click(nftnet_click)
$('#generate-creds-button').click( (evt) => {
const checked_network = $("input[name='faucet-selector']:checked")
const url = checked_network.val()
const net_name = checked_network.data("shortname")
const ws_url = checked_network.data("wsurl")
TestNetCredentials(url, net_name, ws_url)
});
})

117
content/_code-samples/airgapped-wallet/py/README.md Normal file
View File

@@ -0,0 +1,117 @@
# Airgapped Wallet
Airgapped describes a state where a device or a system becomes fully disconnected from other devices and systems. It is the maximum protection for a system against unwanted visitors/viruses, this allows any sensitive data like a private key to be stored without worry of it being compromised as long as reasonable security practices are being practiced.
This airgapped XRP wallet allows users to sign a Payment transaction in a secure environment without the private key being exposed to a machine connected to the internet. The private key and seed is encrypted by password and stored securely.
*Note*: You should not use this airgapped wallet in production, it should only be used for educational purposes only.
This code sample consists of 2 parts:
- `airgapped-wallet.py` - This code should be stored in a standalone airgapped machine, it consist of features to generate a wallet, store a keypair securely, sign a transaction and share the signed transaction via QR code.
- `relay-transaction.py` - This code could be stored in any online machine, no credentials is stored on this code other than a signed transaction which would be sent to an XRPL node for it to be validated on the ledger.
Preferably, `airgapped-wallet.py` should be on a Linux machine while `relay-transaction.py` could be on any operating system.
# Security Practices
Strongly note that an airgapped system's security is not determined by its code alone but the security practices that are being followed by an operator.
There are channels that can be maliciously used by outside parties to infiltrate an airgapped system and steal sensitive information.
There are other ways malware could interact across airgapped networks, but they all involve an infected USB drive or a similar device introducing malware onto the airgapped machine. They could also involve a person physically accessing the computer, compromising it and installing malware or modifying its hardware.
This is why it is also recommended to encrypt sensitive information being stored in an airgapped machine.
The airgapped machine should have a few rules enforced to close any possible channels getting abused to leak information outside of the machine:
### Wifi
- Disable any wireless networking hardware on the airgapped machine. For example, if you have a desktop PC with a Wifi card, open the PC and remove the Wifi hardware. If you cannot do that, you could go to the system’s BIOS or UEFI firmware and disable the Wifi hardware.
### BlueTooth
- BlueTooth can be maliciously used by neighboring devices to steal data from an airgapped machine. It is recommended to remove or disable the BlueTooth hardware.
### USB
- The USB port can be used to transfer files in and out of the airgapped machine and this may act as a threat to an airgapped machine if the USB drive is infected with a malware. So after installing & setting up this airgapped wallet, it is highly recommended to block off all USB ports by using a USB blocker and not use them.
Do not reconnect the airgapped machine to a network, even when you need to transfer files! An effective airgapped machine should only serve 1 purpose, which is to store data and never open up a gateway for hackers to abuse and steal data.
# Tutorial
For testing purposes, you would need to have 2 machines and 1 phone in hand to scan the QR code.
1. 1st machine would be airgapped, following the security practices written [here](#security-practices). It stores and manages an XRPL Wallet.
2. 2nd machine would be a normal computer connected to the internet. It relays a signed transaction blob to a rippled node.
3. The phone would be used to scan a QR code, which contains a signed transaction blob. The phone would transmit it to the 2nd machine.
The diagram below shows you the process of submitting a transaction to the XRPL:
<p align="center">
<img src="https://user-images.githubusercontent.com/87929946/197970678-2a1b7f7e-d91e-424e-915e-5ba7d34689cc.png" width=75% height=75%>
</p>
# Setup
- Machine 1 - An airgapped computer (during setup, it must be connected to the internet to download the files)
- Machine 2 - A normal computer connected to the internet
- Phone - A normal phone with a working camera to scan a QR
## Machine 1 Setup
Since this machine will be airgapped, it is best to use Linux as the Operating System.
1. Install Python 3.8:
**Linux Command Line**:
```
sudo apt-get update
sudo apt-get install python3.8 python3-pip
```
**Website**: https://www.python.org/downloads/source/
2. Clone all the files under the [`airgapped-wallet`](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/airgapped-wallet/py) directory
3. Import all the modules required by running:
```
pip install -r requirements.txt
```
4. Airgap the machine by following the security practices written [here](#security-practices).
5. Run `airgapped-wallet.py`
6. Scan the QR code and fund the account using the [testnet faucet](https://test.bithomp.com/faucet/)
7. Re-run the script and input '1' to generate a new transaction by following the instructions.
8. Use your phone to scan the QR code, then to send the signed transaction to Machine 2 for submission
## Machine 2 Setup
This machine will be used to transmit a signed transaction blob from Machine 1, it would require internet access.
1. Install Python 3.8
**Linux Command Line**:
```
sudo apt-get update
sudo apt-get install python3.8 python3-pip
```
**Website**: https://www.python.org/downloads/source/
2. Clone all the files under the [`airgapped-wallet`](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/airgapped-wallet/py) directory
3. Import all the modules required by running:
```
pip install -r requirements.txt
```
4. Edit line 47 @ `relay-transaction.py` and insert the signed transaction blob from scanning the QR code Machine 1 generated.
5. Run `relay-transaction.py`
## Phone Setup
The phone requires a working camera that is able to scan a QR code and an internet connection for it to be able to transmit the signed transaction blob to Machine 2.
Once you have signed a transaction in the airgapped machine, a QR code will be generated which will contain the signed transaction blob. Example:
<img src="https://user-images.githubusercontent.com/87929946/196018292-f210a9f2-c5f8-412e-98c1-361a72286378.png" width=20% height=20%>
Scan the QR code using the phone and transmit it to Machine 2, which will then be sending it to a rippled node.
You can send a message to yourself using Discord, WhatsApp or even e-mail, then open up the message using Machine 2 to receive the signed transaction blob.

224
content/_code-samples/airgapped-wallet/py/airgapped-wallet-TEST.py Normal file
View File

@@ -0,0 +1,224 @@
import os
import base64
import qrcode
import platform
from PIL import Image
from pathlib import Path, PureWindowsPath, PurePath
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from xrpl import wallet
from xrpl.core import keypairs
from xrpl.utils import xrp_to_drops
from xrpl.models.transactions import Payment
from xrpl.transaction import safe_sign_transaction
def create_wallet(silent: False):
"""
Generates a keypair
"""
if not silent:
print("1. Generating seed...")
seed = keypairs.generate_seed()
print("2. Deriving keypair from seed...")
pub, priv = keypairs.derive_keypair(seed)
print("3. Deriving classic addresses from keypair..\n")
address = keypairs.derive_classic_address(pub)
else:
seed = keypairs.generate_seed()
pub, priv = keypairs.derive_keypair(seed)
address = keypairs.derive_classic_address(pub)
return address, seed
def sign_transaction(xrp_amount, destination, ledger_seq, wallet_seq, password):
"""
Signs transaction and returns signed transaction blob in QR code
"""
print("1. Retrieving encrypted private key and salt...")
with open(get_path("/WalletTEST/private.txt"), "r") as f:
seed = f.read()
seed = bytes.fromhex(seed)
with open(get_path("/WalletTEST/salt.txt"), "rb") as f:
salt = f.read()
print("2. Initializing key...")
kdf = PBKDF2HMAC(
algorithm=hashes.SHA256(),
length=32,
iterations=100000,
salt=salt
)
key = base64.urlsafe_b64encode(kdf.derive(bytes(password.encode())))
crypt = Fernet(key)
print("3. Decrypting wallet's private key using password")
seed = crypt.decrypt(seed)
print("4. Initializing wallet using decrypted private key")
_wallet = wallet.Wallet(seed=seed.decode(), sequence=0)
validated_seq = ledger_seq
_wallet.sequence = wallet_seq
print("5. Constructing payment transaction...")
my_tx_payment = Payment(
account=_wallet.classic_address,
amount=xrp_to_drops(xrp=xrp_amount),
destination=destination,
last_ledger_sequence=validated_seq + 100,
# +100 to catch up with the ledger when we transmit the signed tx blob to Machine 2
sequence=_wallet.sequence,
fee="10"
)
print("6. Signing transaction...")
my_tx_payment_signed = safe_sign_transaction(transaction=my_tx_payment, wallet=_wallet)
img = qrcode.make(my_tx_payment_signed.to_dict())
print("7. Displaying signed transaction blob's QR code on the screen...")
img.save(get_path("/WalletTEST/transactionID.png"))
image = Image.open(get_path("/WalletTEST/transactionID.png"))
image.show()
print(f"RESULT: {my_tx_payment_signed.to_dict()}")
print("END RESULT: Successful")
def get_path(file):
"""
Get path (filesystem management)
"""
global File_
# Checks what OS is being used
OS = platform.system()
usr = Path.home()
# Get PATH format based on the OS
if OS == "Windows":
File_ = PureWindowsPath(str(usr) + file)
else: # Assuming Linux-style file format
File_ = PurePath(str(usr) + file)
return str(File_)
def create_wallet_directory():
global File, Path_
OS = platform.system()
usr = Path.home()
if OS == "Windows":
# If it's Windows, use this path:
print("- OS Detected: Windows")
File = PureWindowsPath(str(usr) + '/WalletTEST')
Path_ = str(PureWindowsPath(str(usr)))
if OS == "Linux":
print("- OS Detected: Linux")
# If it's Linux, use this path:
File = PurePath(str(usr) + '/WalletTEST')
Path_ = str(PurePath(str(usr)))
if not os.path.exists(File):
print("1. Generating wallet's keypair...")
pub, seed = create_wallet(silent=True)
print("2. Creating wallet's file directory...")
os.makedirs(File)
print("3. Generating and saving public key's QR code...")
img = qrcode.make(pub)
img.save(get_path("/WalletTEST/public.png"))
print("4. Generating and saving wallet's salt...")
salt = os.urandom(16)
with open(get_path("/WalletTEST/salt.txt"), "wb") as f:
f.write(salt)
print("5. Generating wallet's filesystem password...")
password = "This is a unit test password 123 !@# -+= }{/"
kdf = PBKDF2HMAC(
algorithm=hashes.SHA256(),
length=32,
iterations=100000,
salt=salt
)
key = base64.urlsafe_b64encode(kdf.derive(bytes(password.encode())))
crypt = Fernet(key)
print("6. Encrypting and saving private key by password...")
priv = crypt.encrypt(bytes(seed, encoding='utf-8'))
seed = crypt.encrypt(bytes(seed, encoding='utf-8'))
with open(get_path("/WalletTEST/seed.txt"), "w") as f:
f.write(seed.hex())
with open(get_path("/WalletTEST/private.txt"), "w") as f:
f.write(priv.hex())
with open(get_path("/WalletTEST/public.txt"), "w") as f:
f.write(pub)
if os.path.exists(File):
print(f"0. Wallet's filesystem already exist as the unit test has been performed before. Directory: {File}")
def showcase_wallet_address_qr_code():
with open(get_path("/WalletTEST/public.txt"), "r") as f:
print(f"0. Wallet Address: {f.read()}")
__path = get_path("/WalletTEST/public.png")
print(f"1. Getting address from {__path}...")
print("2. Displaying QR code on the screen...")
image = Image.open(get_path("/WalletTEST/public.png"))
image.show()
if __name__ == '__main__':
print("Airgapped Machine Unit Test (5 functions):\n")
print(f"UNIT TEST 1. create_wallet():")
_address, _seed = create_wallet(silent=False)
print(f"-- RESULTS --\n"
f"Address: {_address}\n"
f"Seed: {_seed}\n"
f"END RESULT: Successful"
)
print(f"\nUNIT TEST 2. create_wallet_directory():")
create_wallet_directory()
print("RESULT: Successful")
print("\nUNIT TEST 3. showcase_wallet_address_qr_code():")
showcase_wallet_address_qr_code()
print("RESULT: Successful")
print("\nUNIT TEST 4. get_path():")
print("1. Getting files' path...\n")
txt_file = get_path("/WalletTEST/FILE123.txt")
png_file = get_path("/WalletTEST/PIC321.png")
print(f"-- RESULTS --\n"
f"txt_file: {txt_file}\n"
f"png_file: {png_file}\n"
f"END RESULT: Successful")
print("\nUNIT TEST 5. sign_transaction():")
print("Parameters: xrp_amount, destination, ledger_seq, wallet_seq, password")
sign_transaction(
xrp_amount=10,
destination="rPEpirdT9UCNbnaZMJ4ENwKAwJqrTpvgMQ",
ledger_seq=32602000,
wallet_seq=32600100,
password="This is a unit test password 123 !@# -+= }{/"
)

227
content/_code-samples/airgapped-wallet/py/airgapped-wallet.py Normal file
View File

@@ -0,0 +1,227 @@
import os
import shutil
import base64
import qrcode
import platform
from PIL import Image
from pathlib import Path, PureWindowsPath, PurePath
from cryptography.fernet import Fernet
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from xrpl import wallet
from xrpl.core import keypairs
from xrpl.utils import xrp_to_drops
from xrpl.models.transactions import Payment
from xrpl.transaction import safe_sign_transaction
def create_wallet():
"""
Generates a keypair
"""
seed = keypairs.generate_seed()
pub, priv = keypairs.derive_keypair(seed)
address = keypairs.derive_classic_address(pub)
print(
f"\n\n XRP WALLET CREDENTIALS"
f"\n Wallet Address: {address}"
f"\n Seed: {seed}"
)
return address, seed
def sign_transaction(_xrp_amount, _destination, _ledger_seq, _wallet_seq, password):
"""
Signs transaction and returns signed transaction blob in QR code
"""
with open(get_path("/Wallet/private.txt"), "r") as f:
_seed = f.read()
_seed = bytes.fromhex(_seed)
with open(get_path("/Wallet/salt.txt"), "rb") as f:
salt = f.read()
# Line 49-58: initialize key
kdf = PBKDF2HMAC(
algorithm=hashes.SHA256(),
length=32,
iterations=100000,
salt=salt
)
key = base64.urlsafe_b64encode(kdf.derive(bytes(password.encode())))
crypt = Fernet(key)
# Decrypts the wallet's private key
_seed = crypt.decrypt(_seed)
_wallet = wallet.Wallet(seed=_seed.decode(), sequence=0)
validated_seq = _ledger_seq
_wallet.sequence = _wallet_seq
# Construct Payment transaction
my_tx_payment = Payment(
account=_wallet.classic_address,
amount=xrp_to_drops(xrp=_xrp_amount),
destination=_destination,
last_ledger_sequence=validated_seq + 100,
# +100 to catch up with the ledger when we transmit the signed tx blob to Machine 2
sequence=_wallet.sequence,
fee="10"
)
# Signs transaction and displays the signed_tx blob in QR code
# Scan the QR code and transmit the signed_tx blob to an online machine (Machine 2) to relay it to the XRPL
my_tx_payment_signed = safe_sign_transaction(transaction=my_tx_payment, wallet=_wallet)
img = qrcode.make(my_tx_payment_signed.to_dict())
img.save(get_path("/Wallet/transactionID.png"))
image = Image.open(get_path("/Wallet/transactionID.png"))
image.show()
def get_path(file):
"""
Get path (filesystem management)
"""
global File_
# Checks what OS is being us
OS = platform.system()
usr = Path.home()
# Get PATH format based on the OS
if OS == "Windows":
File_ = PureWindowsPath(str(usr) + file)
else: # Assuming Linux-style file format, use this path:
File_ = PurePath(str(usr) + file)
return str(File_)
def main():
global File, Path_
# Gets the machine's operating system (OS)
OS = platform.system()
usr = Path.home()
if OS == "Windows":
# If it's Windows, use this path:
File = PureWindowsPath(str(usr) + '/Wallet')
Path_ = str(PureWindowsPath(str(usr)))
else: # Assuming Linux-style file format, use this path:
File = PurePath(str(usr) + '/Wallet')
Path_ = str(PurePath(str(usr)))
# If the Wallet's folder already exists, continue on
if os.path.exists(File) and os.path.exists(get_path("/Wallet/public.txt")):
while True:
ask = int(input("\n 1. Transact XRP"
"\n 2. Generate an XRP wallet (read only)"
"\n 3. Showcase XRP Wallet Address (QR Code)"
"\n 4. Exit"
"\n\n Enter Index: "
))
if ask == 1:
password = str(input(" Enter Password: "))
amount = float(input("\n Enter XRP To Send: "))
destination = input("If you just want to try it out, you can use the faucet account rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe"
"\n Enter Destination: ")
wallet_sequence = int(input("Look up the 'Next Sequence' for the account using test.bithomp.com and enter it below!"
"\n Enter Wallet Sequence: "))
ledger_sequence = int(input("Look up the latest ledger sequence on testnet.xrpl.org and enter it below!"
"\n Enter Ledger Sequence: "))
sign_transaction(_xrp_amount=amount,
_destination=destination,
_ledger_seq=ledger_sequence,
_wallet_seq=wallet_sequence,
password=password
)
del destination, amount, wallet_sequence, ledger_sequence
if ask == 2:
_pub, _seed = create_wallet()
if ask == 3:
with open(get_path("/Wallet/public.txt"), "r") as f:
print(f"\n Wallet Address: {f.read()}")
image = Image.open(get_path("/Wallet/public.png"))
image.show()
if ask == 4:
return 0
else:
# If the Wallet's folder does not exist, create one and store wallet data (encrypted private key, encrypted seed, account address)
# If the Wallet's directory exists but files are missing, delete it and generate a new wallet
if os.path.exists(File):
confirmation = input(f"We've detected missing files on {File}, would you like to delete your wallet's credentials & generate new wallet credentials? (YES/NO):")
if confirmation == "YES":
confirmation_1 = input(f"All wallet credentials will be lost if you continue, are you sure? (YES/NO): ")
if confirmation_1 == "YES":
shutil.rmtree(File)
else:
print("Aborted: Wallet credentials are still intact")
return 0
else:
print("- Wallet credentials are still intact")
return 0
os.makedirs(File)
pub, seed = create_wallet()
img = qrcode.make(pub)
img.save(get_path("/Wallet/public.png"))
print("\nCreating a brand new Wallet, please enter a new password")
password = str(input("\n Enter Password: "))
salt = os.urandom(16)
with open(get_path("/Wallet/salt.txt"), "wb") as f:
f.write(salt)
kdf = PBKDF2HMAC(
algorithm=hashes.SHA256(),
length=32,
iterations=100000,
salt=salt
)
key = base64.urlsafe_b64encode(kdf.derive(bytes(password.encode())))
crypt = Fernet(key)
priv = crypt.encrypt(bytes(seed, encoding='utf-8'))
seed = crypt.encrypt(bytes(seed, encoding='utf-8'))
with open(get_path("/Wallet/seed.txt"), "w") as f:
f.write(seed.hex())
with open(get_path("/Wallet/private.txt"), "w") as f:
f.write(priv.hex())
with open(get_path("/Wallet/public.txt"), "w") as f:
f.write(pub)
openimg = Image.open(get_path("/Wallet/public.png"))
openimg.show()
print("\nFinished generating an account.")
print(f"\nWallet Address: {pub}")
print("\nPlease scan the QR code on your phone and use https://test.bithomp.com/faucet/ to fund the account."
"\nAfter that, you're able to sign transactions and transmit them to Machine 2 (online machine).")
# Loop back to the start after setup
main()
if __name__ == '__main__':
main()

50
content/_code-samples/airgapped-wallet/py/relay-transaction.py Normal file
View File

@@ -0,0 +1,50 @@
from xrpl.clients import JsonRpcClient
from xrpl.models.transactions import Payment
from xrpl.transaction import send_reliable_submission
def connect_node(_node):
"""
Connects to a node
"""
JSON_RPC_URL = _node
_client = JsonRpcClient(url=JSON_RPC_URL)
print("\n --- Connected to Node")
return _client
def send_transaction(transaction_dict):
"""
Connects to a node -> Send Transaction
Main Function to send transaction to the XRPL
"""
client = connect_node("https://s.altnet.rippletest.net:51234/")
# TESTNET: "https://s.altnet.rippletest.net:51234/"
# MAINNET: "https://s2.ripple.com:51234/"
# Since we manually inserted the tx blob, we need to initialize it into a Payment so xrpl-py could process it
my_tx_signed = Payment.from_dict(transaction_dict)
tx = send_reliable_submission(transaction=my_tx_signed, client=client)
tx_hash = tx.result['hash']
tx_destination = tx.result['Destination']
tx_xrp_amount = int(tx.result['Amount']) / 1000000
tx_account = tx.result['Account']
print(f"\n XRPL Explorer: https://testnet.xrpl.org/transactions/{tx_hash}"
f"\n Transaction Hash: {tx_hash}"
f"\n Transaction Destination: {tx_destination}"
f"\n Transacted XRP: {tx_xrp_amount}"
f"\n Wallet Used: {tx_account}"
)
if __name__ == '__main__':
tx_blob = "ENTER TX BLOB HERE"
if tx_blob == "ENTER TX BLOB HERE":
print("Set tx to 'tx_blob' received from scanning the QR code generated by the airgapped wallet")
else:
send_transaction(tx_blob)

26
content/_code-samples/airgapped-wallet/py/requirements.txt Normal file
View File

@@ -0,0 +1,26 @@
anyio==3.2.1
asgiref==3.4.1
base58==2.1.0
certifi==2022.12.7
cffi==1.15.0
colorama==0.4.4
cryptography==35.0.0
Django==3.2.16
ECPy==1.2.5
h11==0.12.0
httpcore==0.13.6
httpx==0.23.0
idna==3.2
image==1.5.33
pifacedigitalio==3.0.5
Pillow==9.3.0
pycparser==2.20
pytz==2021.1
qrcode==7.2
rfc3986==1.5.0
six==1.16.0
sniffio==1.2.0
sqlparse==0.4.2
typing-extensions==3.10.0.0
websockets==9.1
xrpl-py==1.1.1

45
content/_code-samples/freeze/py/check_freeze_status.py Normal file
View File

@@ -0,0 +1,45 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import AccountLines
client = JsonRpcClient("https://xrplcluster.com")
print("connected to mainnet")
# Real accounts that were frozen on mainnet as an example
# Issuer address
issuer_addr = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
# Target address to query for freeze status
target_addr = "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v"
token_name = "USD"
print(f"searching for a trustline for {token_name} issued by {target_addr} for the address {issuer_addr}")
# Build account line query
acc_info = AccountLines(account=issuer_addr, ledger_index="validated")
# Submit query
response = client.request(acc_info)
# Parse response for result
result = response.result
# Parse result for account lines
found_target_line = False
if "lines" in result:
lines = result["lines"]
for line in lines:
# Query result with trustline params
if target_addr == line["account"] and token_name == line["currency"]:
found_target_line = True
if 'freeze' in line:
print(f'freeze status of trustline: {line["freeze"]}')
else:
print(f'freeze status of trustline: False')
if(not(found_target_line)):
print(f"no such trustline exists for {token_name} issued by {target_addr} for the address {issuer_addr}")
else:
print("this account has no trustlines")

39
content/_code-samples/freeze/py/check_global_freeze.py Normal file
View File

@@ -0,0 +1,39 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import AccountInfo
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to testnetwork
ACCOUNT_ROOT_LEDGER_FLAGS: dict[str, int] = {
"lsfNoFreeze": 0x00200000,
"lsfGlobalFreeze": 0x00400000,
}
def parse_account_root_flags(flags: int) -> list[str]:
flags_enabled = []
for flag in ACCOUNT_ROOT_LEDGER_FLAGS:
check_flag = ACCOUNT_ROOT_LEDGER_FLAGS[flag]
if check_flag & flags == check_flag:
flags_enabled.append(flag)
return flags_enabled
# Issuer address to query for global freeze status
issuer_addr = "rfDJ98Z8k7ubr6atbZoCqAPdg9MetyBwcg"
# Build account line query
print(f"Checking if global freeze is enabled for the address {issuer_addr}")
acc_info = AccountInfo(account=issuer_addr, ledger_index="validated")
# Submit query
response = client.request(acc_info)
# Parse response for result
result = response.result
# Query result for global freeze status
if "account_data" in result:
if "Flags" in result["account_data"]:
if "lsfGlobalFreeze" in parse_account_root_flags(result["account_data"]["Flags"]):
print("Global Freeze is enabled")
else:
print("Global Freeze is disabled")

39
content/_code-samples/freeze/py/check_no_freeze.py Normal file
View File

@@ -0,0 +1,39 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import AccountInfo
client = JsonRpcClient("https://xrplcluster.com") # Connect to a network
ACCOUNT_ROOT_LEDGER_FLAGS: dict[str, int] = {
"lsfNoFreeze": 0x00200000,
"lsfGlobalFreeze": 0x00400000,
}
def parse_account_root_flags(flags: int) -> list[str]:
flags_enabled = []
for flag in ACCOUNT_ROOT_LEDGER_FLAGS:
check_flag = ACCOUNT_ROOT_LEDGER_FLAGS[flag]
if check_flag & flags == check_flag:
flags_enabled.append(flag)
return flags_enabled
# Issuer address to query for no freeze status
issuer_addr = "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v"
# Build account line query
print(f"Checking if the 'No Freeze' flag is enabled for the address {issuer_addr}")
acc_info = AccountInfo(account=issuer_addr, ledger_index="validated")
# Submit query
response = client.request(acc_info)
# Parse response for result
result = response.result
# Query result for no freeze status
if "account_data" in result:
if "Flags" in result["account_data"]:
if "lsfNoFreeze" in parse_account_root_flags(result["account_data"]["Flags"]):
print("No Freeze is enabled")
else:
print("No Freeze is disabled")

34
content/_code-samples/freeze/py/enable_no_freeze.py Normal file
View File

@@ -0,0 +1,34 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import AccountSet, AccountSetFlag
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.wallet import Wallet, generate_faucet_wallet
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # connect to testnet
# generate wallet
sender_wallet = generate_faucet_wallet(client=client)
print("Successfully generated test wallet")
# build accountset transaction to disable freezing
accountset = AccountSet(account=sender_wallet.classic_address, set_flag=AccountSetFlag.ASF_NO_FREEZE)
# sign transaction
stxn = safe_sign_and_autofill_transaction(accountset, sender_wallet, client)
print("Now sending an AccountSet transaction to set the ASF_NO_FREEZE flag...")
# submit transaction and wait for result
stxn_response = send_reliable_submission(stxn, client)
# parse response for result
stxn_result = stxn_response.result
# print result and transaction hash
if stxn_result["meta"]["TransactionResult"] == "tesSUCCESS":
print(f'Successfully enabled no freeze for {sender_wallet.classic_address}')
print(stxn_result["hash"])

42
content/_code-samples/freeze/py/freeze_token.py Normal file
View File

@@ -0,0 +1,42 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import IssuedCurrencyAmount, TrustSet
from xrpl.models.transactions import TrustSetFlag
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.wallet import generate_faucet_wallet
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to testnet
token_name = "FOO"
# Amount a trustline can handle, for this transaction it is set to 0
value = "100"
target_addr = generate_faucet_wallet(client=client).classic_address
sender_wallet = generate_faucet_wallet(client=client)
print("Successfully generated test wallets")
# Build trustline freeze transaction
trustset = TrustSet(account=sender_wallet.classic_address, limit_amount=IssuedCurrencyAmount(
currency= token_name,
issuer=target_addr,
value = value),
flags=TrustSetFlag.TF_SET_FREEZE)
# Sign transaction
stxn = safe_sign_and_autofill_transaction(trustset, sender_wallet, client)
print("Now setting a trustline with the TF_SET_FREEZE flag enabled...")
# Submit transaction and wait for result
stxn_response = send_reliable_submission(stxn, client)
# Parse response for result
stxn_result = stxn_response.result
if(stxn_result["meta"]["TransactionResult"] == 'tesSUCCESS'):
print(f"Froze {token_name} issued by {target_addr} for address {sender_wallet.classic_address}")
if(stxn_result["meta"]["TransactionResult"] == 'tesSUCCESS'):
print(f"Froze {token_name} issued by {target_addr} for address {sender_wallet.classic_address}")

1
content/_code-samples/freeze/py/requirements.txt Normal file
View File

@@ -0,0 +1 @@
xrpl-py

30
content/_code-samples/freeze/py/set_global_freeze.py Normal file
View File

@@ -0,0 +1,30 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import AccountSet, AccountSetFlag
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.wallet import generate_faucet_wallet
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to testnet
# Sender wallet object
sender_wallet = generate_faucet_wallet(client)
print("Successfully generated test wallet")
# Build accountset transaction to enable global freeze
accountset = AccountSet(account=sender_wallet.classic_address,
set_flag=AccountSetFlag.ASF_GLOBAL_FREEZE)
print("Preparing and submitting Account set transaction with ASF_GLOBAL_FREEZE ...")
# Sign and submit transaction
stxn = safe_sign_and_autofill_transaction(accountset, sender_wallet, client)
stxn_response = send_reliable_submission(stxn, client)
# Parse response for result
stxn_result = stxn_response.result
# Print result and transaction hash
if stxn_result["meta"]["TransactionResult"] == "tesSUCCESS":
print(f'Successfully enabled global freeze for {sender_wallet.classic_address}')
print(stxn_result["hash"])

50
content/_code-samples/freeze/py/unfreeze_token.py Normal file
View File

@@ -0,0 +1,50 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import IssuedCurrencyAmount, TrustSet, TrustSetFlag
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.wallet import generate_faucet_wallet
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # connect to testnet
token_name = "USD"
# Amount a trustline can handle
value = "0"
print("Generating two test wallets...")
# Address to unfreeze trustline
target_addr = generate_faucet_wallet(client=client).classic_address
print("Successfully generated the target account")
# Sender wallet
sender_wallet = generate_faucet_wallet(client=client)
print("Successfully generated the sender account")
print("Successfully generated test wallets")
# Build trustline freeze transaction
trustset = TrustSet(account=sender_wallet.classic_address, limit_amount=IssuedCurrencyAmount(
currency=token_name,
issuer=target_addr,
value = value
),
flags=TrustSetFlag.TF_CLEAR_FREEZE)
print("prepared and submitting TF_CLEAR_FREEZE transaction")
# Sign and Submit transaction
stxn = safe_sign_and_autofill_transaction(trustset, sender_wallet, client)
stxn_response = send_reliable_submission(stxn, client)
# Parse response for result
stxn_result = stxn_response.result
# Print result and transaction hash
if stxn_result["meta"]["TransactionResult"] == "tesSUCCESS":
print(f'Successfully enabled no freeze for {sender_wallet.classic_address}')
if stxn_result["meta"]["TransactionResult"] == "tecNO_LINE_REDUNDANT":
print("This was used on an account which didn't have a trustline yet. To try this out, modify `target_addr` to point to an account with a frozen trustline, and make sure the currency code matches.")
else:
print(f"Transaction failed with {stxn_result['meta']['TransactionResult']}")
print(stxn_result["hash"])

5
content/_code-samples/markers-and-pagination/README.md Normal file
View File

@@ -0,0 +1,5 @@
# Markers and Pagination
Iterate over a `ledger_data` method request that requires multiple calls.
Examples from the [Markers and Pagination page](https://xrpl.org/markers-and-pagination.html#markers-and-pagination).

43
content/_code-samples/markers-and-pagination/js/pagination-with-markers.js Normal file
View File

@@ -0,0 +1,43 @@
const xrpl = require("xrpl")
async function main() {
// Create a client and connect to the network.
const client = new xrpl.Client("wss://xrplcluster.com/")
await client.connect()
// Query the most recently validated ledger for info.
let ledger = await client.request({
"command": "ledger_data",
"ledger_index": "validated",
})
const ledger_data_index = ledger["result"]["ledger_index"]
// Create a function to run on each API call.
function printLedgerResult(){
console.log(ledger["result"])
}
// Execute function at least once before checking for markers.
do {
printLedgerResult()
if (ledger["result"]["marker"] === undefined) {
break
}
// Specify the same ledger and add the marker to continue querying.
const ledger_marker = await client.request({
"command": "ledger_data",
"ledger_index": ledger_data_index,
"marker": ledger["result"]["marker"]
})
ledger = ledger_marker
} while (true)
// Disconnect when done. If you omit this, Node.js won't end the process.
client.disconnect()
}
main()

24
content/_code-samples/markers-and-pagination/py/pagination-with-markers.py Normal file
View File

@@ -0,0 +1,24 @@
from xrpl.clients import JsonRpcClient
from xrpl.models.requests import LedgerData
# Create a client to connect to the network.
client = JsonRpcClient("https://xrplcluster.com/")
# Query the most recently validated ledger for info.
ledger = LedgerData(ledger_index="validated")
ledger_data = client.request(ledger).result
ledger_data_index = ledger_data["ledger_index"]
# Create a function to run on each API call.
def printLedgerResult():
print(ledger_data)
# Execute function at least once before checking for markers.
while True:
printLedgerResult()
if "marker" not in ledger_data:
break
# Specify the same ledger and add the marker to continue querying.
ledger_marker = LedgerData(ledger_index=ledger_data_index, marker=ledger_data["marker"])
ledger_data = client.request(ledger_marker).result

BIN
content/_code-samples/quickstart/js/quickstart.zip
View File

Binary file not shown.

85
content/_img-sources/amm-concept-deposit.uxf Normal file
View File

@@ -0,0 +1,85 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>UMLClass</id>
<coordinates>
<x>290</x>
<y>70</y>
<w>110</w>
<h>100</h>
</coordinates>
<panel_attributes>AMM</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLUseCase</id>
<coordinates>
<x>30</x>
<y>80</y>
<w>120</w>
<h>80</h>
</coordinates>
<panel_attributes>Liquidity
Provider</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>140</x>
<y>90</y>
<w>190</w>
<h>50</h>
</coordinates>
<panel_attributes>lt=-&gt;&gt;&gt;
r2=Deposit assets</panel_attributes>
<additional_attributes>10.0;30.0;20.0;20.0;170.0;20.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>140</x>
<y>110</y>
<w>190</w>
<h>40</h>
</coordinates>
<panel_attributes>lt=-&gt;&gt;&gt;
</panel_attributes>
<additional_attributes>10.0;10.0;20.0;20.0;170.0;20.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>80</x>
<y>110</y>
<w>370</w>
<h>120</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;.
Receive LP Tokens</panel_attributes>
<additional_attributes>10.0;50.0;10.0;100.0;350.0;100.0;350.0;10.0;320.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>310</x>
<y>100</y>
<w>70</w>
<h>20</h>
</coordinates>
<panel_attributes>USD</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>310</x>
<y>120</y>
<w>70</w>
<h>20</h>
</coordinates>
<panel_attributes>ETH</panel_attributes>
<additional_attributes/>
</element>
</diagram>

74
content/_img-sources/amm-concept-swap.uxf Normal file
View File

@@ -0,0 +1,74 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>UMLClass</id>
<coordinates>
<x>320</x>
<y>170</y>
<w>110</w>
<h>100</h>
</coordinates>
<panel_attributes>AMM</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>230</x>
<y>100</y>
<w>120</w>
<h>130</h>
</coordinates>
<panel_attributes>lt=-&gt;&gt;&gt;
Sell 1.25 USD
</panel_attributes>
<additional_attributes>10.0;10.0;10.0;110.0;90.0;110.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>340</x>
<y>200</y>
<w>70</w>
<h>20</h>
</coordinates>
<panel_attributes>USD: 6.25</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>340</x>
<y>220</y>
<w>70</w>
<h>20</h>
</coordinates>
<panel_attributes>ETH: 4</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLUseCase</id>
<coordinates>
<x>180</x>
<y>30</y>
<w>120</w>
<h>80</h>
</coordinates>
<panel_attributes>Trader</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>290</x>
<y>60</y>
<w>280</w>
<h>190</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;.
Receive 1 ETH</panel_attributes>
<additional_attributes>10.0;10.0;160.0;10.0;160.0;170.0;120.0;170.0</additional_attributes>
</element>
</diagram>

86
content/_img-sources/amm-concept-withdraw.uxf Normal file
View File

@@ -0,0 +1,86 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>UMLClass</id>
<coordinates>
<x>290</x>
<y>70</y>
<w>110</w>
<h>100</h>
</coordinates>
<panel_attributes>AMM</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLUseCase</id>
<coordinates>
<x>30</x>
<y>80</y>
<w>120</w>
<h>80</h>
</coordinates>
<panel_attributes>Liquidity
Provider</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>370</x>
<y>110</y>
<w>80</w>
<h>40</h>
</coordinates>
<panel_attributes>lt=.
</panel_attributes>
<additional_attributes>10.0;20.0;40.0;20.0;60.0;10.0</additional_attributes>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>80</x>
<y>100</y>
<w>500</w>
<h>130</h>
</coordinates>
<panel_attributes>lt=&lt;&lt;.
Receive assets</panel_attributes>
<additional_attributes>10.0;60.0;10.0;110.0;380.0;110.0;380.0;20.0;350.0;20.0;330.0;10.0;300.0;10.0</additional_attributes>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>310</x>
<y>100</y>
<w>70</w>
<h>20</h>
</coordinates>
<panel_attributes>USD</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>UMLClass</id>
<coordinates>
<x>310</x>
<y>120</y>
<w>70</w>
<h>20</h>
</coordinates>
<panel_attributes>ETH</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>140</x>
<y>100</y>
<w>170</w>
<h>50</h>
</coordinates>
<panel_attributes>lt=-&gt;&gt;&gt;
Redeem
LP Tokens</panel_attributes>
<additional_attributes>10.0;20.0;150.0;20.0</additional_attributes>
</element>
</diagram>

129
content/_img-sources/amm-single-asset-deposit-formula.uxf Normal file
View File

@@ -0,0 +1,129 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<diagram program="umlet" version="14.2">
<zoom_level>10</zoom_level>
<element>
<id>Text</id>
<coordinates>
<x>90</x>
<y>150</y>
<w>70</w>
<h>30</h>
</coordinates>
<panel_attributes>L = T ×</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Relation</id>
<coordinates>
<x>190</x>
<y>150</y>
<w>180</w>
<h>30</h>
</coordinates>
<panel_attributes>lt=-</panel_attributes>
<additional_attributes>10.0;10.0;160.0;10.0</additional_attributes>
</element>
<element>
<id>Text</id>
<coordinates>
<x>370</x>
<y>150</y>
<w>30</w>
<h>30</h>
</coordinates>
<panel_attributes>- 1</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>350</x>
<y>130</y>
<w>30</w>
<h>30</h>
</coordinates>
<panel_attributes>W</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>160</x>
<y>130</y>
<w>40</w>
<h>50</h>
</coordinates>
<panel_attributes>fontsize=40
(</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>340</x>
<y>130</y>
<w>40</w>
<h>50</h>
</coordinates>
<panel_attributes>fontsize=40
)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>150</x>
<y>120</y>
<w>40</w>
<h>70</h>
</coordinates>
<panel_attributes>fontsize=60
[</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>390</x>
<y>120</y>
<w>40</w>
<h>80</h>
</coordinates>
<panel_attributes>fontsize=60
]</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>260</x>
<y>160</y>
<w>30</w>
<h>30</h>
</coordinates>
<panel_attributes>P</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>200</x>
<y>140</y>
<w>160</w>
<h>20</h>
</coordinates>
<panel_attributes>B - (F × (1 - W) × B)</panel_attributes>
<additional_attributes/>
</element>
<element>
<id>Text</id>
<coordinates>
<x>170</x>
<y>150</y>
<w>40</w>
<h>30</h>
</coordinates>
<panel_attributes>1 +</panel_attributes>
<additional_attributes/>
</element>
</diagram>

1
content/_snippets/amm-disclaimer.md Normal file
View File

@@ -0,0 +1 @@
_Automated Market Maker (AMM) functionality is part of the proposed [XLS-30d](https://github.com/XRPLF/XRPL-Standards/discussions/78) extension :not_enabled: to the XRP Ledger protocol. You can use these functions on AMM test networks, but there isn't an official amendment and they aren't available on the production Mainnet. Until there is an amendment, the details documented on these pages are subject to change._ <!-- SPELLING_IGNORE: 30d -->

13
content/_snippets/etl-source-object.md Normal file
View File

@@ -0,0 +1,13 @@
### ETL Source Object
<!-- This nested object definition is identical across server_state and server_info -->
On a reporting mode server, each member of the `etl_sources` field is an object with the following fields:
| Field | Type | Description |
|-----------------------------|---------|-------------|
| `connected` | Boolean | If `true`, the reporting mode server is connected to this P2P mode server. If `false`, the server is not connected. This could be due to misconfiguration, a network outage, or it could mean that the P2P mode server is down. |
| `grpc_port` | String | The port number on the P2P mode server where this reporting mode server is configured to connect and retrieve ledger data via gRPC. |
| `ip` | String | The IP address (IPv4 or IPv6) of the P2P mode server. |
| `last_message_arrival_time` | String | An ISO 8601 timestamp indicating the most recent time the reporting mode server received a message from this P2P server. |
| `validated_ledgers_range` | String | The range of validated ledger versions this P2P mode server reports that it has available, in the same format as `complete_ledgers`. |
| `websocket_port` | String | The port number on the P2P server where this reporting mode server is configured to forward WebSocket requests that cannot be served directly from reporting mode. |

2
content/_snippets/post-rippled-install.md
View File

@@ -13,7 +13,7 @@ If the `server_state` in the response is `full` or `proposing`, then your server
After your server has synchronized with the rest of the network, you have a fully functional XRP Ledger peer-to-peer server that you can use to submit transactions or get API access to the XRP Ledger. See [Client Libraries](client-libraries.html) or [HTTP / WebSocket APIs](http-websocket-apis.html) for different ways to communicate with the server.
If you use the XRP Ledger for your business or you just want to contribute to the stability of the network, you should run one server as a validator. For information about validating servers and why you might want to run one, see [Run rippled as a Validator](run-rippled-as-a-validator.html).
If you use the XRP Ledger for your business or you want to contribute to the stability of the network, you should run one server as a validator. For information about validating servers and why you might want to run one, see [Run rippled as a Validator](run-rippled-as-a-validator.html).
Having trouble getting your server started? See [rippled Server Won't Start](server-wont-start.html).

2
content/_snippets/pseudo-tx-fields-intro.md
View File

@@ -1,3 +1,3 @@
## {{currentpage.name}} Fields
In addition to the [common fields](pseudo-transaction-types.html), a {{currentpage.name}} pseudo-transaction uses the following fields:
In addition to the [common fields](pseudo-transaction-types.html), {{currentpage.name}} pseudo-transactions use the following fields:

1
content/_snippets/rippled-api-links.md
View File

@@ -64,6 +64,7 @@
{% set ledger_entries = [
"AccountRoot",
"Amendments",
"AMM",
"Check",
"DepositPreauth",
"DirectoryNode",

2
content/_snippets/tx-fields-intro.md
View File

@@ -1,3 +1,3 @@
## {{currentpage.name}} Fields
In addition to the [common fields][], a {{currentpage.name}} transaction uses the following fields:
In addition to the [common fields][], {{currentpage.name}} transactions use the following fields:

5
content/_snippets/tx-type-links.md
View File

@@ -1,6 +1,11 @@
{% set txtypes = [
"AccountDelete",
"AccountSet",
"AMMBid",
"AMMDeposit",
"AMMCreate",
"AMMVote",
"AMMWithdraw",
"CheckCancel",
"CheckCash",
"CheckCreate",

6
content/concepts/consensus-network/amendments/amendments.md
View File

@@ -227,11 +227,11 @@ TrustSetAuth
## Retiring Legacy Code
After an amendment has become enabled, it can never be disabled. (To reverse protocol changes, it would be necessary to create a new amendment.) However, separate ledger chains, such as [test networks](parallel-networks.html) or [stand-alone mode](rippled-server-modes.html#stand-alone-mode) can have different sets of amendments applied. Therefore, the pre-amendment code may continue to run in those cases, and the software must work with an increasing number of combinations of amendments that may or may not be enabled on any given test network.
After an amendment has become enabled, it can never be disabled. (To reverse protocol changes, it would be necessary to create a new amendment.) However, separate ledger chains, such as [test networks](parallel-networks.html) or [stand-alone mode](rippled-server-modes.html#stand-alone-mode) can have different sets of amendments applied. The pre-amendment code may continue to run in those cases, and the software must work with an increasing number of combinations of amendments that may or may not be enabled on any given test network.
Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](xrpl-servers.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date.
Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](xrpl-servers.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date. <!-- SPELLING_IGNORE: 11d -->
When pre-amendment code has been retired, the server follows the amended logic for all transactions at all times. As a result, the server is no longer guaranteed to produce historically-accurate results if you try to replay ledgers older than the cutoff date. The server prints a warning if you try to [load and replay a ledger](load-a-saved-ledger-in-stand-alone-mode.html) that is older than the cutoff date. To produce historically-accurate results, you must compile or download an old server binary that has the legacy code.
When pre-amendment code has been retired, the server follows the amended logic for all transactions at all times. As a result, the server is no longer guaranteed to produce historically-accurate results if you try to replay ledgers older than the cutoff date. The server prints a warning if you try to [load and replay a ledger](load-a-saved-ledger-in-stand-alone-mode.html) that is older than the cutoff date. To produce historically-accurate results, you must compile or download an old server binary that has the legacy code. <!-- STYLE_OVERRIDE: accurate -->
## See Also

12
content/concepts/consensus-network/amendments/known-amendments.md
View File

@@ -83,7 +83,7 @@ The following is a comprehensive list of all known [amendments](amendments.html)
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Adjusts the [CheckCash transaction][] so that cashing a [Check](checks.html) for an issued token automatically creates a [trust line](trust-lines-and-issuing.html) to hold the token. The new behavior is similar to how the [OfferCreate transaction][] behaves when users purchase tokens in the decentralized exchange: the automatic trust line has a limit value of 0. This removes the setup step of setting up a trust line before receiving a token via a Check. (Checks that send XRP are unaffected.)
Adjusts the [CheckCash transaction][] so that cashing a [Check](checks.html) for an issued token automatically creates a [trust line](trust-lines-and-issuing.html) to hold the token. The new behavior is similar to how the [OfferCreate transaction][] behaves when users buy tokens in the decentralized exchange: the automatic trust line has a limit value of 0. This removes the setup step of setting up a trust line before receiving a token via a Check. (Checks that send XRP are unaffected.)
Without this amendment, users have to separately send a [TrustSet transaction][] before they can cash a Check for an issued token.
@@ -321,7 +321,7 @@ The fix1373 amendment corrects the issue so that the paths are properly prepared
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Fixes a bug in transaction processing that causes some invalid [PaymentChannelClaim][] transactions to fail with the wrong error code. Without this amendment, the transactions have a `tec`-class result code despite not being included in a ledger and therefore not paying the [transaction cost](transaction-cost.html).
Fixes a bug in transaction processing that causes some invalid [PaymentChannelClaim][] transactions to fail with the wrong error code. Without this amendment, the transactions have a `tec`-class result code despite not being included in a ledger.
With this amendment, the transactions fail with a more appropriate result code, `temBAD_AMOUNT`, instead.
@@ -385,7 +385,7 @@ With this amendment, new escrows are added to the [owner directories](directoryn
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | Yes |
Fixes a bug where validators could build consensus ledgers with different timestamps, potentially delaying the process of declaring validated ledgers. The circumstances for this to occur require precise timing, so validators are unlikely to encounter this bug outside of controlled test conditions.
Fixes a bug where validators could build consensus ledgers with different timestamps, potentially delaying the process of declaring validated ledgers. The circumstances for this to occur require precise timing, so this bug is unlikely to happen outside of controlled test conditions.
This amendment changes how validators negotiate the close time of the consensus ledger so that they cannot reach a consensus on ledger contents but build ledger versions with different timestamps.
@@ -593,9 +593,9 @@ This amendment has no known impact on transaction processing.
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Removes the `tfTrustLine` setting on [non-fungible tokens](non-fungible-tokens.html), to protect against a denial of service attack on issuers using this flag. With this amendment enabled, a [NFTokenMint transaction](nftokenmint.html) with the `tfTrustLine` flag enabled is considered invalid and cannot be confirmed by consensus; therefore, `NFToken` objects cannot be minted with the flag.
Removes the `tfTrustLine` setting on [non-fungible tokens](non-fungible-tokens.html), to protect against a denial of service attack on issuers using this flag. With this amendment enabled, a [NFTokenMint transaction](nftokenmint.html) with the `tfTrustLine` flag enabled is considered invalid and cannot be confirmed by consensus; new `NFToken` objects cannot be minted with the flag.
Without this amendment, an attacker could create new, meaningless fungible tokens and sell a `NFToken` back and forth for those tokens, creating numerous useless trust lines tied to the issuer and increasing the issuer's reserve requirement.
Without this amendment, an attacker could create new, meaningless fungible tokens and sell a `NFToken` back and forth for those tokens, creating many useless trust lines tied to the issuer and increasing the issuer's reserve requirement.
This amendment does not change the code for `NFToken` objects that have already been minted. On test networks that enabled NFT support before this amendment, issuers who have already minted NFTokens with the `tfTrustLine` flag enabled are still vulnerable to the exploit even after the fixRemoveNFTokenAutoTrustLine amendment.
@@ -928,7 +928,7 @@ When this amendment is activated, the XRP Ledger will undergo a brief scheduled
Sorts the entries in [DirectoryNode ledger objects](directorynode.html) and fixes a bug that occasionally caused pages of owner directories not to be deleted when they should have been.
**Warning:** Older versions of `rippled` that do not know about this amendment may crash when they encounter a DirectoryNode sorted by the new rules. To avoid this problem, [upgrade](install-rippled.html) to `rippled` version 0.80.0 or later.
**Warning:** Older versions of `rippled` that do not know about this amendment may crash when they find a DirectoryNode sorted by the new rules. To avoid this problem, [upgrade](install-rippled.html) to `rippled` version 0.80.0 or later.
## SusPay

2
content/concepts/consensus-network/consensus-principles-and-rules.md
View File

@@ -7,7 +7,7 @@ labels:
---
# Consensus Principles and Rules
The XRP Ledger is a universal payment system enabling users to transfer funds across national boundaries as seamlessly as sending an email. Like other peer-to-peer payment networks such as Bitcoin, the XRP Ledger enables peer-to-peer transaction settlement across a decentralized network of computers. Unlike other digital currency protocols, the XRP Ledger allows users to denominate their transactions with any currency they prefer, including fiat currencies, digital currencies and other forms of value, in addition to XRP (the native asset of the XRP Ledger).
The XRP Ledger is a universal payment system enabling users to transfer funds across national boundaries as seamlessly as sending an email. Like other peer-to-peer payment networks such as Bitcoin, the XRP Ledger enables peer-to-peer transaction settlement across a decentralized network of computers. Unlike other digital currency protocols, the XRP Ledger allows users to denominate their transactions with any currency they prefer, including fiat currencies, digital currencies and other forms of value, and XRP (the native asset of the XRP Ledger).
The XRP Ledger's technology enables near real-time settlement (three to six seconds) and contains a decentralized exchange, where payments automatically use the cheapest currency trade orders available to bridge currencies.

2
content/concepts/consensus-network/consensus.md
View File

@@ -95,7 +95,7 @@ Validation can be broken up into roughly two parts:
- Calculating the resulting ledger version from an agreed-upon transaction set.
- Comparing results and declaring the ledger version validated if enough trusted validators agree.
Each server in the network performs validation separately and locally; the consensus process can proceed to tentatively confirm transactions even if no ledger is validated from a given round.
Each server in the network performs validation separately and locally.
#### Calculate and Share Validations

2
content/concepts/consensus-network/federated-sidechains.md
View File

@@ -9,7 +9,7 @@ labels:
_Federated Sidechains are available as an Engineering Preview and can be used to develop and test using `rippled` 1.8.0._
A sidechain is an independent ledger with its own consensus algorithm and transaction types and rules. It acts as its own blockchain. Federation enables value in the form of XRP and other tokens to move efficiently between a sidechain and an XRP Ledger _mainchain_ (usually Mainnet, but could be [Testnet or Devnet](parallel-networks.html) for testing). Federated sidechains operate without compromising the speed, efficiency, and throughput of the public Mainnet.
A sidechain is an independent ledger with its own consensus algorithm and transaction types and rules. It acts as its own blockchain. Federation enables value in the form of XRP and other tokens to move efficiently between a sidechain and an XRP Ledger _mainchain_ (usually Mainnet, but could be [Testnet or Devnet](parallel-networks.html) for testing). Federated sidechains run without compromising the speed, efficiency, and throughput of the public Mainnet.
Federated sidechains enable developers to launch new features and innovative applications using the foundation of XRP Ledger technology. Sidechains can customize the XRP Ledger protocol to the needs of a specific use case or project and run it as its own blockchain. Here are a few examples:

3
content/concepts/consensus-network/parallel-networks.md
View File

@@ -16,8 +16,9 @@ To help members of the XRP Ledger community interact with XRP Ledger technology
| Mainnet | Stable releases | _The_ [XRP Ledger](xrp-ledger-overview.html), a decentralized cryptographic ledger powered by a network of peer-to-peer servers and the home of [XRP](xrp.html). |
| Testnet | Stable releases | An "alternate universe" network that acts as a testing ground for software built on the XRP Ledger, without impacting production XRP Ledger users and without risking real money. The [amendment status](known-amendments.html) of the Testnet is intended to closely mirror the Mainnet, although slight variations in timing may occur due to the unpredictable nature of decentralized systems. |
| Devnet | Beta releases | A preview of coming attractions, where unstable changes to the core XRP Ledger software may be tested out. Developers can use this altnet to interact with and learn about planned new XRP Ledger features and amendments that are not yet enabled on the Mainnet. |
| NFT-Devnet | [XLS-20 pre-release](https://github.com/ripple/rippled/tree/xls20) | A preview of the [XLS-20d](https://github.com/XRPLF/XRPL-Standards/discussions/46) standard for non-fungible tokens on the XRP Ledger. |
| NFT-Devnet | [XLS-20 pre-release](https://github.com/ripple/rippled/tree/xls20) | A preview of the [XLS-20d](https://github.com/XRPLF/XRPL-Standards/discussions/46) standard for non-fungible tokens on the XRP Ledger. <!-- SPELLING_IGNORE: 20d --> |
| [Hooks Testnet V2](https://hooks-testnet-v2.xrpl-labs.com/) | [Hooks server](https://github.com/XRPL-Labs/xrpld-hooks) | A preview of on-chain smart contract functionality using [hooks](https://write.as/xumm/xrpl-labs-is-working-on-the-transaction-hooks-amendment-for-the-xrp-ledger). |
| AMM-Devnet | [XLS-30d pre-release](https://github.com/gregtatcam/rippled/tree/amm-core-functionality/) | A preview of the [XLS-30d](https://github.com/XRPLF/XRPL-Standards/discussions/78) standard for Automated Market Makers on the XRP Ledger. <!-- SPELLING_IGNORE: 30d --> [Binary builds for testing](https://github.com/legleux/scheduled/releases) are also available. Library support: [xrpl.js 2.6.0-beta.0](https://www.npmjs.com/package/xrpl/v/2.6.0-beta.0), [xrpl-py 1.8.0b0](https://pypi.org/project/xrpl-py/1.8.0b0/) |
Each altnet has its own separate supply of test XRP, which is [given away for free](xrp-testnet-faucet.html) to parties interested in experimenting with the XRP Ledger and developing applications and integrations. Test XRP does not have real-world value and is lost when the network is reset.

88
content/concepts/decentralized-exchange/automated-market-makers.md Normal file
View File

@@ -0,0 +1,88 @@
---
html: automated-market-makers.html
parent: decentralized-exchange.html
blurb: Automated Market Makers (AMMs) provide liquidity between asset pairs, complemeting the order books in the decentralized exchange while providing passive income for their liquidity providers.
status: not_enabled
labels:
- XRP
- Decentralized Exchange
- AMM
---
# Automated Market Makers
Automated Market Makers (AMMs) are smart contracts that provide liquidity in the XRP Ledger's decentralized exchange. Each AMM holds a pool of two assets and enables users to swap between them at an exchange rate set by a formula.
{% include '_snippets/amm-disclaimer.md' %}
For any given pair of assets, there can be up to one AMM in the ledger. Anyone can create the AMM for an asset pair if it doesn't exist yet, or deposit to an existing AMM. Those who deposit assets into an AMM are called _liquidity providers_ (LPs) and receive "LP Tokens" from the AMM. LP Tokens enable liquidity providers to:
- Redeem their LP Tokens for a share of the assets in the AMM's pool, including fees collected.
- Vote to change the AMM's fee settings. The votes are weighted based on how many LP Tokens the voters hold.
- Bid some of their LP Tokens to receive a temporary discount on the AMM's trading fees.
When the flow of funds between the two assets in a pool is relatively active and balanced, the fees provide a source of passive income for liquidity providers. However, when the relative price between the assets shifts, the liquidity providers can take a loss on the [currency risk](https://www.investopedia.com/terms/c/currencyrisk.asp).
## How the AMM Works
An AMM holds two different assets: at most one of these can be XRP, and one or both of them can be [tokens](tokens.html). Tokens with different issuers are considered different assets for this purpose. This means that there can be an AMM for two tokens with the same currency code but different issuers ("FOO issued by WayGate" is different than "FOO issued by StableFoo"), or the same issuer but different currency codes. The order does not matter; the AMM for FOO.WayGate to XRP is the same as for XRP to FOO.WayGate.
When users want to trade in the decentralized exchange, their [Offers](offers.html) and [Cross-Currency Payments](cross-currency-payments.html) can automatically use AMMs to complete the trade. A single transaction might execute by matching Offers, AMMs, or a mix of both, depending on what's cheaper.
An AMM sets its exchange rate based on the balance of assets in the pool. When you trade against an AMM, the exchange rate adjusts based on how much your trade shifts the balance of assets the AMM holds. As its supply of one asset goes down, the price of that asset goes up; as its supply of an asset goes up, the price of that asset goes down. An AMM gives generally better exchange rates when it has larger overall amounts in its pool. This is because any given trade causes a smaller shift in the balance of the AMM's assets. The more a trade unbalances the AMM's supply of the two assets, the more extreme the exchange rate becomes.
The AMM also charges a percentage trading fee on top of the exchange rate.
The XRP Ledger's implements a _geometric mean_ AMM with a weight parameter of 0.5, so it functions like a _constant product_ market maker. For a detailed explanation of the _constant product_ AMM formula and the economics of AMMs in general, see [Kris Machowski's Introduction to Automated Market Makers](https://www.machow.ski/posts/an_introduction_to_automated_market_makers/).
## LP Tokens
<!-- TODO: add diagrams showcasing flow of funds -->
Whoever creates the AMM becomes the first liquidity provider, and receives LP Tokens that represent 100% ownership of assets in the AMM's pool. They can redeem some or all of those LP Tokens to withdraw assets from the AMM in proportion to the amounts currently there. (The proportions shift over time as people trade against the AMM.) The AMM does not charge a fee when withdrawing both assets.
For example, if you created an AMM with 5 ETH and 5 USD, and then someone exchanged 1.26 USD for 1 ETH, the pool now has 4 ETH and 6.26 USD in it. You can spend half your LP Tokens to withdraw 2 ETH and 3.13 USD.
Anyone can deposit assets to an existing AMM. When they do, they receive new LP Tokens based on how much they deposited. The amount that a liquidity provider can withdraw from an AMM is based on the proportion of the AMM's LP Tokens they hold compared to the total number of LP Tokens outstanding.
LP Tokens are like other tokens in the XRP Ledger, so you can use them in many [types of payments](payment-types.html), trade them in the decentralized exchange, or even deposit them as assets for new AMMs. (To receive LP Tokens as payment, you must set up a [trust line](trust-lines-and-issuing.html) with a nonzero limit with the AMM Account as the issuer.) However, you can _only_ send LP Tokens directly to the AMM (redeeming them) using the [AMMWithdraw][] transaction type, not through other types of payments. Similarly, you can only send assets to the AMM's pool through the [AMMDeposit][] transaction type.
The AMM is designed so that an AMM's asset pool is empty if and only if the AMM has no outstanding LP Tokens. This situation can only occur as the result of an [AMMWithdraw][] transaction; when it does, the AMM is automatically deleted.
### LP Token Currency Codes
LP Tokens use a special type of currency code in the 160-bit hexadecimal ["non-standard" format](currency-formats.html#nonstandard-currency-codes). These codes have the first 8 bits `0x03`. The remainder of the code is a SHA-512 hash, truncated to the first 152 bits, of the two assets' currency codes and their issuers. (The assets are placed in a "canonical order" with the numerically lower currency+issuer pair first.) As a result, the LP Tokens for a given asset pair's AMM have a predictable, consistent currency code.
## Trading Fees
Trading fees are a source of passive income for liquidity providers, and they offset the currency risk of letting others trade against the pool's assets. Trading fees are paid to the AMM, not directly to liquidity providers, but liquidity providers benefit because their LP Tokens can be redeemed for a percentage of the AMM's pool.
Liquidity providers can vote to set the fee from 0% to 1%, in increments of 0.001%. Liquidity providers have an incentive to set trading fees at an appropriate rate: if fees are too high, trades will use order books to get a better rate instead; if fees are too low, liquidity providers don't get any benefit for contributing to the pool. <!-- STYLE_OVERRIDE: will --> Each AMM gives its liquidity providers the power to vote on its fees, in proportion to the amount of LP Tokens those liquidity providers hold.
To vote, a liquidity provider sends an [AMMVote transaction][]. Whenever anyone places a new vote, the AMM recalculates its fee to be an average of the latest votes weighted by how many LP Tokens those voters hold. Up to 8 liquidity providers' votes can be counted this way; if more liquidity providers try to vote then only the top 8 votes (by most LP Tokens held) are counted. Even though liquidity providers' share of LP Tokens can shift rapidly for many reasons (such as trading those tokens using [Offers](offers.html)), the trading fees are only recalculated whenever someone places a new vote (even if that vote is not one of the top 8).
### Auction Slot
Unlike any previous Automated Market Makers, the XRP Ledger's AMM design has an _auction slot_ that a liquidity provider can bid on to get a discount on the trading fee for a 24-hour period. The bid must be paid in LP Tokens, which are returned to the AMM. No more than one account can hold the auction slot at a time, but the bidder can name up to 4 more accounts to also receive the discount. There is no minimum bid, but if the slot is currently occupied then you must outbid the current slot holder to displace them. If someone displaces you, you get part of your bid back depending on how much time remains. As long as you hold an active auction slot, you pay a discounted trading fee of 0% when making trades against that AMM.
With any AMM, when the price of its assets shifts significantly in external markets, traders can use arbitrage to profit off the AMM, which results in a loss for liquidity providers. The auction mechanism is intended to return more of that value to liquidity providers and more quickly bring the AMM's prices back into balance with external markets.
## Representation in the Ledger
In the ledger's state data, an AMM consists of multiple [ledger entries](ledger-object-types.html):
- An [AMM object][] describing the automated market maker itself.
- A special [AccountRoot object][] that issues the AMM's LP Tokens, and holds the AMM's XRP (if it has any).
The address of this AccountRoot is chosen somewhat randomly when the AMM is created, and it is different if the AMM is deleted and re-created. This is to prevent people from funding the AMM account with excess XRP in advance.
- [Trust lines](trust-lines-and-issuing.html) to the special AMM Account for the tokens in the AMM's pool.
These objects are not owned by any account, so the [reserve requirement](reserves.html) does not apply to them. However, to prevent spam, the transaction to create an AMM has a special [transaction cost](transaction-cost.html) that requires the sender to burn a larger than usual amount of XRP.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

4
content/concepts/decentralized-exchange/decentralized-exchange.md
View File

@@ -14,7 +14,7 @@ The XRP Ledger has possibly the world's oldest _decentralized exchange_ (sometim
## Structure
The XRP Ledger's decentralized exchange consists of an unlimited number of currency pairs, tracked on-demand when users make trades. A currency pair can consist of XRP and a token or two different tokens; tokens are always identified by the combination of an issuer and a currency code. Therefore, it is possible to trade between two tokens with the same currency code and different issuers, or the same issuer and different currency codes.
The XRP Ledger's decentralized exchange consists of an unlimited number of currency pairs, tracked on-demand when users make trades. A currency pair can consist of XRP and a token or two different tokens; tokens are always identified by the combination of an issuer and a currency code. It is possible to trade between two tokens with the same currency code and different issuers, or the same issuer and different currency codes. <!-- STYLE_OVERRIDE: limited number -->
As with all changes to the XRP Ledger, you need to send a [transaction](transaction-basics.html) to make a trade. A trade in the XRP Ledger is called an [Offer](offers.html). An Offer is effectively a [_limit order_](https://en.wikipedia.org/wiki/Order_(exchange)#Limit_order) to buy or sell a specific amount of one currency (XRP or a token) for a specific amount of another. When the network executes an Offer, if there are any matching Offers for the same currency pair, they are consumed starting with the best exchange rate first.
@@ -51,7 +51,7 @@ Because trades are only executed each time a new ledger closes (approximately ev
The XRP Ledger does not natively represent concepts such as market orders, stop orders, or trading on leverage. Some of these may be possible with creative use of custom tokens and Offer properties.
As a decentralized system, the XRP Ledger does not have any information on the actual people and organizations behind the [accounts](accounts.html) involved in trading. Therefore, the ledger itself cannot implement restrictions around who can or cannot participate in trading, and users and issuers must take care to follow any relevant laws to regulate trading tokens that represent various types of underlying assets. Features such as [freezes](freezes.html) and [authorized trust lines](authorized-trust-lines.html) are intended to help issuers comply with relevant laws and regulations.
As a decentralized system, the XRP Ledger does not have any information on the actual people and organizations behind the [accounts](accounts.html) involved in trading. The ledger itself cannot implement restrictions around who can or cannot participate in trading, and users and issuers must take care to follow any relevant laws to regulate trading tokens that represent various types of underlying assets. Features such as [freezes](freezes.html) and [authorized trust lines](authorized-trust-lines.html) are intended to help issuers comply with relevant laws and regulations.
## See Also

4
content/concepts/decentralized-exchange/offers.md
View File

@@ -15,7 +15,7 @@ In the XRP Ledger's [decentralized exchange](decentralized-exchange.html), trade
## Lifecycle of an Offer
An [OfferCreate transaction][] is an instruction to conduct a trade, either between two tokens, or a token and XRP. Every such transaction contains a buy amount (`TakerPays`) and a sell amount (`TakerGets`). When the transaction is processed, it automatically consumes matching or crossing Offers to the extent possible. If that does not completely fill the new Offer, then the remainder becomes an Offer object in the ledger.
An [OfferCreate transaction][] is an instruction to conduct a trade, either between two tokens, or a token and XRP. Every such transaction contains a buy amount (`TakerPays`) and a sell amount (`TakerGets`). When the transaction is processed, it automatically consumes matching or crossing Offers to the extent possible. If that does not completely fill the new Offer, then the rest becomes an Offer object in the ledger.
The Offer object waits in the ledger until other Offers or cross-currency payments fully consume it. The account that placed the Offer is called the Offer's _owner_. You can cancel your own Offers at any time, using the dedicated [OfferCancel transaction][], or as an option of the [OfferCreate transaction][].
@@ -42,7 +42,7 @@ However, you don't need to hold the full amount specified in the Offer. Placing
**To sell XRP,** you must hold enough XRP to meet all the [reserve requirements](reserves.html), including the reserve for the Offer object to be placed in the ledger and for the trust line to hold the token you are buying. As long as you have any XRP left over after setting aside the reserve amount, you can place the Offer.
When another Offer matches yours, both Offers execute to the extent that their owners' funds permit at the the time. If there are matching Offers and you run out of funds before yours is fully filled, the remainder of your Offer is canceled. An Offer can't make your balance of a token negative, unless you are the issuer of that token. (If you are the issuer, you can use Offers to issue new tokens up to the total amount specified in your Offers; tokens you issue are represented as negative balances from your perspective.)
When another Offer matches yours, both Offers execute to the extent that their owners' funds allow at the the time. If there are matching Offers and you run out of funds before yours is fully filled, the rest of your Offer is canceled. An Offer can't make your balance of a token negative, unless you are the issuer of that token. (If you are the issuer, you can use Offers to issue new tokens up to the total amount specified in your Offers; tokens you issue are represented as negative balances from your perspective.)
If you place an Offer that crosses any of your own Offers that exist in the ledger, the old, crossed Offers are automatically canceled regardless of the amounts involved.

6
content/concepts/interoperability/intro-to-evm-sidechain.md
View File

@@ -19,11 +19,11 @@ The EVM Sidechain is a powerful latest generation blockchain with the following
- Supports up to 1000 transactions per second, thus handling large loads and throughput.
- Has a low transaction confirmation time, on average, as a block is produced every 5 seconds.
- Once a block is added to the chain and confirmed, it is considered final (1 block finalization time).
- Provides full Ethereum Virtual Machine (EVM) compatibility, enabling you to connect your wallet and interact or deploy smart contracts written in Solidity.
- Provides full Ethereum Virtual Machine (EVM) compatibility, enabling you to connect your wallet and interact or deploy smart contracts written in Solidity. <!-- STYLE_OVERRIDE: wallet -->
## Consensus
The EVM Sidechain runs on a proof-of-stake (PoS) consensus algorithm. Staking is when you pledge your coins to be used for verifying transactions. The proof-of-stake model allows you to stake cryptocurrency (also referred to as "coins") and create your own validator nodes. Your coins are locked up while you stake them, but you can unstake them if you want to trade your coins.
The EVM Sidechain runs on a proof-of-stake (PoS) consensus algorithm. Staking is when you pledge your coins to be used for verifying transactions. The proof-of-stake model allows you to stake cryptocurrency (also referred to as "coins") and create your own validator nodes. Your coins are locked up while you stake them, but you can unstake them if you want to trade your coins.
In a proof-of-stake blockchain, mining power depends on the amount of coins a validator is staking. Participants who stake more coins are more likely to be chosen to add new blocks.
@@ -35,7 +35,7 @@ The blockchain uses the `cosmos-sdk` library on top of Tendermint to create and
## Interoperability Using the EVM Sidechain
The EVM sidechain is directly connected to XRP Ledger through the XRP Ledger bridge ([https://bridge.devnet.xrpl.](https://bridge.devnet.xrpl.org/). Through this bridge component, you can move your XRP to the EVM Sidechain and use its features.
The EVM sidechain is directly connected to XRP Ledger through the XRP Ledger bridge [https://bridge.devnet.xrpl](https://bridge.devnet.xrpl.org/). Through this bridge, you can connect to the EVM Sidechain and use its features.
## See Also

2
content/concepts/interoperability/xrpl-interoperability.md
View File

@@ -9,5 +9,5 @@ status: not_enabled
---
# Interoperability
The XRP Ledger is known for its transaction throughput, speed, and low fees. With the addition of programmabilty and interoperability, developers can access features such as smart contracts and can build apps with cross-chain interoperability.
The XRP Ledger is known for its transaction throughput, speed, and low fees. With the addition of programmability and interoperability, developers can access features such as smart contracts and can build apps with cross-chain interoperability.

4
content/concepts/introduction/intro-to-consensus.md
View File

@@ -42,12 +42,12 @@ The XRP Ledger processes transactions in blocks called "ledger versions", or "le
Each ledger version is numbered with a _ledger index_ and builds on a previous ledger version whose index is one less, going all the way back to a starting point called the _genesis ledger_ with ledger index 1.[¹](#footnote-1) Like Bitcoin and other blockchain technologies, this forms a public history of all transactions and their results. Unlike many blockchain technologies, each new "block" in the XRP Ledger contains the entirety of the current state, so you don't need to collect the entire history to know what's happening now.[²](#footnote-2)
The main job of the XRP Ledger Consensus Protocol is to agree on a set of transactions to apply to the previous ledger, apply them in a well-defined order, then confirm that everyone got the same results. When this happens successfully, a ledger version is considered _validated_, and final. From there, the process continues by building the next ledger version.
The main goal of the XRP Ledger Consensus Protocol is to agree on a set of transactions to add to the next ledger version, apply them in a well-defined order, then confirm that everyone got the same results. When this happens successfully, a ledger version is considered _validated_, and final. From there, the process continues by building the next ledger version.
## Trust-Based Validation
The core principle behind the XRP Ledger's consensus mechanism is that a little trust goes a long way. Each participant in the network chooses a set of _validators_, servers [specifically configured to participate actively in consensus](run-rippled-as-a-validator.html), run by different parties who are expected to behave honestly most of the time. More importantly, the set of chosen validators should not be likely to collude with one another to break the rules in the exact same way. This list is sometimes called a _Unique Node List_, or UNL.
The core principle behind the XRP Ledger's consensus mechanism is that a little trust goes a long way. Each participant in the network chooses a set of _validators_, servers [specifically configured to participate actively in consensus](run-rippled-as-a-validator.html), run by different parties who are expected to behave honestly most of the time according to the protocol. More importantly, the set of chosen validators should not be likely to collude with one another to break the rules in the exact same way. This list is called a _Unique Node List_, or UNL.
As the network progresses, each server listens to its trusted validators[³](#footnote-3); as long as a large enough percentage of them agree that a set of transactions should occur and that a given ledger is the result, the server declares a consensus. If they don't agree, validators modify their proposals to more closely match the other validators they trust, repeating the process in several rounds until they reach a consensus.

6
content/concepts/payment-system-basics/accounts/cryptographic-keys.md
View File

@@ -16,7 +16,7 @@ To make a digital signature, you use a cryptographic key pair associated with th
## Generating Keys
Many [client libraries](client-libraries.html) and applications can generate a key pair suitable for use with the XRP Ledger. However, you should only use keypairs that were generated with devices and software you trust. Compromised applications can expose your secret to malicious users who can then send transactions from your account later.
Many [client libraries](client-libraries.html) and applications can generate a key pair suitable for use with the XRP Ledger. However, you should only use key pairs that were generated with devices and software you trust. Compromised applications can expose your secret to malicious users who can then send transactions from your account later.
## Key Components
@@ -44,13 +44,13 @@ The passphrase is secret information, so you must protect it very carefully. Any
A _seed_ value is a compact value that is used to [derive](#key-derivation) the actual private and public keys for an account. In a [wallet_propose method][] response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to [sign transactions](transaction-basics.html#signing-and-submitting-transactions) in the [`rippled` APIs](http-websocket-apis.html) and some [other XRP Ledger software](software-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
The seed value is secret information, so you must protect it very carefully. Anyone who has knows an address's seed value has effectively full control over that address.
The seed value is secret information, so you must protect it very carefully. Anyone who knows an address's seed value has effectively full control over that address.
### Private Key
The _private key_ is the value that is used to create a digital signature. Most XRP Ledger software does not explicitly show the private key, and [derives the private key](#key-derivation) from the seed value when necessary. It is technically possible to save the private key instead of the seed and use that to sign transactions directly, but this usage is rare.
Like the seed, the private key is secret information, so you must protect it very carefully. Anyone who has knows an address's private key has effectively full control over that address.
Like the seed, the private key is secret information, so you must protect it very carefully. Anyone who knows an address's private key has effectively full control over that address.
### Public Key

27
content/concepts/payment-system-basics/accounts/multi-signing.md
View File

@@ -17,53 +17,54 @@ Benefits of multi-signing include:
* You can delegate the power to send transactions from your address to a group of people, who can control your address if you are unavailable or unable to sign normally.
* ... and more.
## SignerLists
## Signer Lists
Before you can multi-sign, you must create a list of which addresses can sign for you.
The [SignerListSet transaction][] defines which addresses can authorize transactions from your address. You can include 1 to 32 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList.
The [SignerListSet transaction][] defines a _signer list_, a set of addresses that can authorize transactions from your address. You can include 1 to 32 addresses in a signer list. The list cannot include your address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the _Signer Weight_ and _Quorum_ settings in the list.
_(Updated by the [ExpandedSignerList amendment][].)_
### Signer Weight
You can assign a weight to each signer in the SignerList. The weight represents the relative authority of the signer to other signers on the list. The higher the value, the more authorization authority. Individual weight values cannot exceed 2<sup>16</sup>-1.
You assign a weight to each signer in the list. The weight represents the authority of the signer relative to other signers on the list. The higher the value, the more authority. Individual weight values cannot exceed 2<sup>16</sup>-1.
### Signer Quorum
### Quorum
The quorum value is the minimum weight total required to authorize a transaction. The quorum must be greater than 0 but less than or equal to the sum of the weight values in the SignerList: meaning, it must be possible to achieve a quorum with the given signer weights.
The quorum value of a list is the minimum weight total required to authorize a transaction. The quorum must be greater than 0 but less than or equal to the sum of the weight values in the signer list: meaning, it must be possible to achieve a quorum with the given signer weights.
### Wallet Locator
<!-- STYLE_OVERRIDE: wallet -->
You can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers.
_(Added by the [ExpandedSignerList amendment][].)_
### Examples Using Signer Weight and Signer Quorum
### Examples Using Signer Weight and Quorum
The weight and quorum allow you to set an appropriate level of oversight for each transaction, based on the relative trust and authority relegated to responsible participants who manage the account.
The weights and quorum allow you to set an appropriate level of oversight for each transaction, based on the relative trust and authority relegated to responsible participants who manage the account.
For a typical use case, you might have a shared account with a quorum of 1, then give all participants a weight of 1. A single approval from any one of them is all that is required to approve a transaction.
For a shared account use case, you might create a list with a quorum of 1, then give all participants a weight of 1. A single approval from any one of them is all that is required to approve a transaction.
For a very important account, you might set the quorum to 3, with 3 participants that have a weight of 1. All of the participants must agree and approve each transaction.
Another account might also have a quorum of 3. You assign your CEO a weight of 3, 3 Vice Presidents a weight of 2 each, and 3 Directors a weight of 1 each. To approve a transaction for this account requires the approval of all 3 Directors (total weight of 3), 1 Vice President and 1 Director (total weight of 3), 2 Vice Presidents (total weight of 4), or the CEO (total weight of 3).
Another account might also have a quorum of 3. You assign your CEO a weight of 3, 3 Vice Presidents a weight of 2 each, and 3 Directors a weight of 1 each. To approve a transaction for this account requires the approval of all 3 Directors (total weight of 3), 1 Vice President and 1 Director (total weight of 3), 2 Vice Presidents (total weight of 4), or the CEO (total weight of 3). <!-- STYLE_OVERRIDE: vice -->
In each of the previous three use cases, you would disable the master key without configuring a regular key, so that multi-signing is the only way of [authorizing transactions](transaction-basics.html#authorizing-transactions).
There might be a scenario where you create a multi-signing list as a "backup plan." The account owner normally uses a regular key for their transactions (not a multi-signing key). For safety, the owner adds a SignerList containing 3 friends, each with a weight of 1, and a quorum of 3. If the account owner were to lose the private key, they can ask their friends to multi-sign a transaction to replace the regular key.
There might be a scenario where you create a multi-signing list as a "backup plan." The account owner normally uses a regular key for their transactions (not a multi-signing key). For safety, the owner adds a signer list containing 3 friends, each with a weight of 1, and a quorum of 3. If the account owner were to lose the private key, they can ask their friends to multi-sign a transaction to replace the regular key.
## Sending Multi-Signed Transactions
To successfully submit a multi-signed transaction, you must do all of the following:
* The address sending the transaction (specified in the `Account` field) must have a [SignerList in the ledger](signerlist.html). For instructions on how to do this, see [Set Up Multi-Signing](set-up-multi-signing.html).
* The address sending the transaction (specified in the `Account` field) must have a [`SignerList` object in the ledger](signerlist.html). For instructions on how to do this, see [Set Up Multi-Signing](set-up-multi-signing.html).
* The transaction must include the `SigningPubKey` field as an empty string.
* The transaction must include a [`Signers` field](transaction-common-fields.html#signers-field) containing an array of signatures.
* The signatures present in the `Signers` array must match signers defined in the SignerList.
* For the provided signatures, the total weight associated with those signers must be equal or greater than the quorum for the SignerList.
* The signatures present in the `Signers` array must match signers defined in the `SignerList`.
* For the provided signatures, the total weight associated with those signers must be equal or greater than the quorum for the `SignerList`.
* The [transaction cost](transaction-cost.html) (specified in the `Fee` field) must be at least (N+1) times the normal transaction cost, where N is the number of signatures provided.
* All fields of the transaction must be defined before collecting signatures. You cannot [auto-fill](transaction-common-fields.html#auto-fillable-fields) any fields.
* If presented in binary form, the `Signers` array must be sorted based on the numeric value of the signer addresses, with the lowest value first. (If submitted as JSON, the [submit_multisigned method][] handles this automatically.)

53
content/concepts/payment-system-basics/ledgers.ja.md
View File

@@ -31,6 +31,59 @@ XRP Ledgerは完全にオープンな共有グローバルレジャーです。
トランザクションの場合、識別用ハッシュは署名済みトランザクションの指示に基づいていますが、検索時のトランザクションオブジェクトにはトランザクションの結果とメタデータが含まれています。これは、ハッシュの生成時には反映されません。
<!-- TODO: translate these new sections -->
## Open, Closed, and Validated Ledgers
The `rippled` server makes a distinction between ledger versions that are _open_, _closed_, and _validated_. A server has one open ledger, any number of closed but unvalidated ledgers, and an immutable history of validated ledgers. The following table summarizes the difference:
| Ledger Type: | Open | Closed | Validated |
|:---------------------------------|:----------------------------|:-------------------------------------------|:--|
| **Purpose:** | Temporary workspace | Proposed next state | Confirmed previous state |
| **Number used:** | 1 | Any number, but usually 0 or 1 | One per ledger index, growing over time |
| **Can contents change?** | Yes | No, but the whole ledger could be replaced | Never |
| **Transactions are applied in:** | The order they are received | Canonical order | Canonical order |
Unintuitively, the XRP Ledger never "closes" an open ledger to convert it into a closed ledger. Instead, the server throws away the open ledger, creates a new closed ledger by applying transactions on top of a previous closed ledger, then creates a new open ledger using the latest closed ledger as a base. This is a consequence of [how consensus solves the double-spend problem](consensus-principles-and-rules.html#問題の単純化).
For an open ledger, servers apply transactions in the order those transactions appear, but different servers may see transactions in different orders. Since there is no central timekeeper to decide which transaction was actually first, servers may disagree on the exact order of transactions that were sent around the same time. Thus, the process for calculating a closed ledger version that is eligible for [validation](consensus.html#検証) is different than the process of building an open ledger from proposed transactions in the order they arrive. To create a "closed" ledger, each XRP Ledger server starts with a set of transactions and a previous, or "parent", ledger version. The server puts the transactions in a canonical order, then applies them to the previous ledger in that order. The canonical order is designed to be deterministic and efficient, but hard to game, to increase the difficulty of front-running Offers in the [decentralized exchange](decentralized-exchange.html).
Thus, an open ledger is only ever used as a temporary workspace, which is a major reason why transactions' [tentative results may vary from their final results](finality-of-results.html).
## Ledger Close Times
The time that a ledger version closed is recorded at the `close_time` field of the [ledger header](ledger-header.html). To make it easier for the network to reach a consensus on an exact close time, this value is rounded to a number of seconds based on the close time resolution, currently 10 seconds. If rounding would cause a ledger's close time to be the same as (or earlier than) its parent ledger's, the child ledger has its close time set to the parent's close time plus 1. This guarantees that the close times of validated ledgers are strictly increasing. <!-- STYLE_OVERRIDE: a number of -->
Since new ledger versions usually close about every 3 to 5 seconds, these rules result in a loose pattern where ledgers' close times end in :00, :01, :02, :10, :11, :20, :21, and so on. Times ending in 2 are less common and times ending in 3 are very rare, but both occur randomly when more ledgers randomly happen to close within a 10-second window.
Generally speaking, the ledger cannot make any time-based measurements that are more precise than the close time resolution. For example, to check if an object has passed an expiration date, the rule is to compare it to the close time of the parent ledger. (The close time of a ledger is not yet known when executing transactions to go into that ledger.) This means that, for example, an [Escrow](escrow.html) could successfully finish at a real-world time that is up to about 10 seconds later than the time-based expiration specified in the Escrow object.
### Example
The following examples demonstrate the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**:
**Current consensus round**
1. A validator notes that it was **12:00:03** when the ledger closed and entered consensus. The validator includes this close time in its proposals.
2. The validator observes that most other validators (on its UNL) proposed a close time of 12:00:02, and one other proposed a close time of 12:00:03. It changes its proposed close time to match the consensus of **12:00:02**.
3. The validator rounds this value to the nearest close time interval, resulting in **12:00:00**.
4. Since 12:00:00 is not greater than the previous ledger's close time, the validator adjusts the close time to be exactly 1 second after the previous ledger's close time. The result is an adjusted close time of **12:00:01**.
5. The validator builds the ledger with these details, calculates the resulting hash, and confirms in the [validation step](consensus.html#検証) that others did the same.
Non-validating servers do all the same steps, except they don't propose their recorded close times to the rest of the network.
**Next consensus round**
1. The next ledger enters consensus at **12:00:04** according to most validators.
2. This rounds down again, to a close time of **12:00:00**.
3. Since this is not greater than the previous ledger's close time of 12:00:01, the adjusted close time is **12:00:02**.
**Next consensus round after that**
1. The ledger after that enters consensus at **12:00:05** according to most validators.
2. This rounds up, based on the close time resolution, to **12:00:10**.
3. Since this value is larger than the previous ledger's close time, it does not need to be adjusted. **12:00:10** becomes the official close time.
## 関連項目

2
content/concepts/payment-system-basics/ledgers.md
View File

@@ -58,7 +58,7 @@ Generally speaking, the ledger cannot make any time-based measurements that are
### Example
The following examples demonstrate the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**:
The following examples show the rounding behavior of ledger close times, from the perspective of an example validator, following a ledger with the close time **12:00:00**:
**Current consensus round**

16
content/concepts/tokens/authorized-trust-lines.md
View File

@@ -10,13 +10,13 @@ labels:
The Authorized Trust Lines feature enables issuers to create tokens that can only be held by accounts that the issuer specifically authorizes. This feature only applies to tokens, not XRP.
To use the Authorized Trust Lines feature, enable the `RequireAuth` flag on your issuing account. While the setting is enabled, other accounts can only hold tokens you issue if you have authorized those accounts' trust lines to your issuing account.
To use the Authorized Trust Lines feature, enable the **Require Auth** flag on your issuing account. While the setting is enabled, other accounts can only hold tokens you issue if you have authorized those accounts' trust lines to your issuing account.
You can authorize a trust line by sending a [TrustSet transaction][] from your issuing address, configuring the trust line between your account and the account to authorize. After you have authorized a trust line, you can never revoke that authorization. (You can, however, [freeze](freezes.html) that trust line if you need to.)
The transaction to authorize a trust line must be signed by the issuing address, which unfortunately means an increased risk exposure for that address.
**Caution:** You can only enable `RequireAuth` if your account has no trust lines and no Offers in the XRP Ledger, so you must decide whether or not to use it _before_ you start issuing tokens.
**Caution:** You can only enable Require Auth if your account has no trust lines and no Offers in the XRP Ledger, so you must decide whether or not to use it _before_ you start issuing tokens.
## With Stablecoin Issuing
@@ -31,15 +31,15 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process
## As a Precaution
Even if you don't intend to use Authorized Trust Lines, you can enable the `RequireAuth` setting on [operational and standby accounts](issuing-and-operational-addresses.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
Even if you don't intend to use Authorized Trust Lines, you can enable the Require Auth setting on [operational and standby accounts](issuing-and-operational-addresses.html), and then never have those accounts approve any trust lines. This prevents those accounts from issuing tokens by accident (for example, if a user accidentally trusts the wrong address). This is only a precaution, and does not stop the operational and standby accounts from transferring the _issuer's_ tokens, as intended.
## Technical Details
<!--{# TODO: split these off into one or more tutorials on using authorized trust lines, preferably with both JavaScript and Python code samples. #}-->
### Enabling RequireAuth
### Enabling Require Auth
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] to enable the `RequireAuth` flag: (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send an [AccountSet transaction][] that enables Require Auth using the `asfRequireAuth` flag. (This method works the same way regardless of whether the address is an issuing address, operational address, or standby address.)
Request:
@@ -65,11 +65,11 @@ POST http://localhost:5005/
{% include '_snippets/secret-key-warning.md' %}
<!--{#_ #}-->
## Checking Whether an Account Has RequireAuth Enabled
## Checking Whether an Account Has Require Auth Enabled
To see whether an account has the `RequireAuth` setting enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](accountroot.html).
To see whether an account has the Require Auth setting enabled, use the [account_info method][] to look up the account. Compare the value of the `Flags` field (in the `result.account_data` object) with the [bitwise flags defined for an AccountRoot ledger object](accountroot.html).
If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (`0x00040000`) is nonzero, then the account has `RequireAuth` enabled. If the result is zero, then the account has `RequireAuth` disabled.
If the result of the `Flags` value bitwise-AND the `lsfRequireAuth` flag value (`0x00040000`) is nonzero, then the account has Require Auth enabled. If the result is zero, then the account has Require Auth disabled.
## Authorizing Trust Lines

2
content/concepts/tokens/common-misconceptions-about-freezes.md
View File

@@ -10,7 +10,7 @@ It is a common misconception that Ripple or others can freeze XRP, similar to ho
Tokens in the XRP Ledger are [fundamentally different than XRP](currency-formats.html#comparison). Tokens always exist _in trust lines_, which _can_ be frozen. XRP exists in accounts, which _cannot_ be frozen.
## Isn't XRP Just Ripple's Token?
## Isn't XRP Just Ripple's Token? <!-- STYLE_OVERRIDE: just -->
No, XRP is different from tokens. XRP is the only native asset on the XRP Ledger and is required to conduct transactions on the XRP Ledger. XRP has no counterparty, meaning that when someone holds XRP, they are not holding a liability, they are holding the actual currency, XRP. Due to this fact, _**<u>XRP CANNOT be frozen by any entity or individual</u>**_.

4
content/concepts/tokens/demurrage.md
View File

@@ -14,7 +14,7 @@ status: removed
Rather than continuously update all amounts in the XRP Ledger, this approach divides amounts of interest-bearing or demurraging tokens into two types of amount: "ledger values" recorded in the XRP Ledger, and "display values" shown to people. The "ledger values" represent the value of the currency at a fixed point, namely the "Ripple Epoch" of midnight January 1, 2000. The "display values" represent the amount at a later point in time (usually the current time) after calculating continuous interest or demurrage from the Ripple Epoch until that time.
**Tip:** You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not reflect actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate.
**Tip:** You can think of demurrage as similar to inflation, where the value of all assets affected by it decreases over time, but the ledger always holds amounts in year-2000 values. This does not show actual real-world inflation; demurrage is more like hypothetical inflation at a constant rate.
Thus, client software must apply two conversions:
@@ -84,7 +84,7 @@ To support interest-bearing and demurraging tokens, client applications must imp
Demurrage was supported in ripple-lib versions **0.7.37** through **0.12.9**. Demurrage is ***not supported*** in most modern libraries.
The following code samples demonstrate how to use compatible versions of ripple-lib to convert between ledger values and display values. Also see the [Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/).
The following code samples show how to use compatible versions of ripple-lib to convert between ledger values and display values. Also see the [Ripple Demurrage Calculator](https://ripple.github.io/ripple-demurrage-tool/).
To convert from a display value to a ledger value, use `Amount.from_human()`:

2
content/concepts/tokens/issuing-and-operational-addresses.md
View File

@@ -23,7 +23,7 @@ The standby addresses, which are operated by actual humans, send those tokens to
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 with sufficient limits.
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.

60
content/concepts/tokens/nftoken-authorized-minting.md Normal file
View File

@@ -0,0 +1,60 @@
---
html: nftoken-authorized-minting.html
parent: non-fungible-tokens.html
blurb: You can assign another account to mint NFTs in your stead.
labels:
- Non-fungible Tokens, NFTs
---
# Authorizing Another Account to Mint Your NFTs
Each account can have 0 or 1 authorized minter that can mint NFTs on its behalf. By authorizing a minter, a creator can allow a different account to mint NFTs for them, which allows them to focus on making more NFTs.
## Assigning an Authorized Minter
You set the authorized minter with an `AccountSet` transaction.
``` json
tx_json = {
"TransactionType": "AccountSet",
"Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
"NFTokenMinter": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
"SetFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
}
```
`NFTokenMinter` is an account ID of an account on the same XRP Ledger instance. The `asfAuthorizedNFTokenMinter` flag authorizes the `NFTokenMinter` account to mint NFTs on behalf of the `Account`.
*Note*: The `asfAuthorizedNFTokenMinter` flag is used only in the `AccountSet` transaction. It indicates whether the transaction affects the presence or value of the NFTokenMinter field on an account root. Specifically, there is no corresponding flag on the AccountRoot.
## Unassigning an Authorized Minter
To remove an authorized minter, use the `AccountSet` transaction and clear the `asfAuthorizedNFTokenMinter` flag.
``` json
tx_json = {
"TransactionType": "AccountSet",
"Account": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m",
"ClearFlag": xrpl.AccountSetAsfFlags.asfAuthorizedNFTokenMinter
}
```
## Minting an NFT for Another Account
You mint tokens for another account using the standard `NFTokenMint` transaction. The difference is that you must include the `Issuer` field, the account ID of the account for which you are minting the NFT.
```json
const transactionBlob = {
"TransactionType": "NFTokenMint",
"Account": "r3riWB2TDWRmwmT7FRKdRHjqm6efYu4s9C",
"URI": xrpl.convertStringToHex("ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi"),
"Flags": 8,
"TransferFee": 5000,
"NFTokenTaxon": 0
"Issuer": "rrE5EgHN4DfjXhR9USecudHm7UyhTYq6m", // Needed when minting for another
// account.
}
```
When you or a broker sells the NFT, the TransferFee (percentage of sale) is credited to your issuing account.

10
content/concepts/tokens/nftoken-batch-minting.md
View File

@@ -2,8 +2,6 @@
html: nftoken-batch-minting.html
parent: non-fungible-tokens.html
blurb: Minting NFToken objects in batches.
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
---
@@ -14,16 +12,16 @@ There are two common approaches to minting NFToken objects in batches: mint on d
## Mint On Demand (Lazy Minting)
When using a mint on demand model, you and potential customers make buy or sell offers for initial sales of a NFToken object off the XRP Ledger. When you are ready to commence the initial sale, you mint the token, create a sell offer or accept a buy offer, then complete the transaction.
When using a mint on demand model, you and potential customers make buy or sell offers for initial sales of a NFToken object off the XRP Ledger. When you are ready to start the initial sale, you mint the token, create a sell offer or accept a buy offer, then complete the transaction.
### Benefits
* There is no reserve requirement for holding unsold NFToken objects.
* You mint NFToken objects in real time when you know that it will sell.
* You mint NFToken objects in real time when you know that it will sell. <!-- STYLE_OVERRIDE: will -->
### Downside
Any market activity prior to the initial sale of the NFToken object is not recorded on the XRP Ledger. This might not be an issue for some applications.
Any market activity before the initial sale of the NFToken object is not recorded on the XRP Ledger. This might not be an issue for some applications.
## Scripted Minting
@@ -38,4 +36,4 @@ For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutor
### Downside
You need to retain the appropriate XRP reserve for all of the NFToken objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have sufficient XRP in reserve, your mint transactions fail until you add sufficient XRP to your account.
You need to meet the [reserve requirement](reserves.html) for all of the `NFToken` objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have enough XRP in reserve, your mint transactions fail until you get more XRP.

2
content/concepts/tokens/non-fungible-token-transfers.ja.md
View File

@@ -2,8 +2,6 @@
html: non-fungible-token-transfers.html
parent: non-fungible-tokens.html
blurb: NFTokenをダイレクトモードまたはブローカーモードで取引する。
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
status: not_enabled

10
content/concepts/tokens/non-fungible-token-transfers.md
View File

@@ -2,8 +2,6 @@
html: non-fungible-token-transfers.html
parent: non-fungible-tokens.html
blurb: Trading NFTokens in direct or brokered mode.
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
---
@@ -20,12 +18,12 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
### Create a Sell Offer
As the owner of a `NFToken` object, you can create a sell offer using a [NFTokenCreateOffer transaction][] with the `tfSellToken` flag. You provide the `NFTokenID` and the `Amount` you are willing to accept in payment. You can optionally specify an `Expiration` date, after which the offer is no longer valid, and a `Destination` account, which is the only account that is allowed to purchase the `NFToken`.
As the owner of a `NFToken` object, you can create a sell offer using a [NFTokenCreateOffer transaction][] with the `tfSellToken` flag. You provide the `NFTokenID` and the `Amount` you are willing to accept in payment. You can optionally specify an `Expiration` date, after which the offer is no longer valid, and a `Destination` account, which is the only account that is allowed to buy the `NFToken`.
### Accept a Sell Offer
To purchase a `NFToken` that is offered for sale, you use a `NFTokenAcceptOffer` transaction. You provide the owner account and specify the `NFTokenOfferID` of the `NFTokenOffer` object you choose to accept.
To buy a `NFToken` that is offered for sale, you use a `NFTokenAcceptOffer` transaction. You provide the owner account and specify the `NFTokenOfferID` of the `NFTokenOffer` object you choose to accept.
## Buy Offers
@@ -45,9 +43,9 @@ Use the `NFTokenAcceptOffer` transaction to transfer a `NFToken`. Provide the `N
When trading a `NFToken`, you can choose between a _direct_ transaction between a buyer and seller or a _brokered_ transaction, where a third party account matches a sell and buy offer to arrange the trade.
Trading in direct mode gives the seller control over the transfer. The seller can either post a `NFToken` for purchase by anyone, or sell a `NFToken` to a specific destination account. The seller receives the entire purchase price for the `NFToken`.
Trading in direct mode gives the seller control over the transfer. The seller can either post a `NFToken` for sale so that anyone can buy it, or sell a `NFToken` to a specific account. The seller receives the entire price for the `NFToken`.
In brokered mode, the seller allows a third party account to broker the sale of the `NFToken`. The broker account collects a broker fee for the transfer at an agreed upon rate. The purchase is completed in real time, paying the broker and seller from the buyer’s funds without requiring an up front investment by the broker.
In brokered mode, the seller allows a third party account to broker the sale of the `NFToken`. The broker account collects a broker fee for the transfer at an agreed upon rate. This happens as one transaction, paying the broker and seller from the buyer’s funds without requiring an up front investment by the broker.
### When to Use Brokered Mode

2
content/concepts/tokens/non-fungible-tokens.ja.md
View File

@@ -2,8 +2,6 @@
html: non-fungible-tokens.html
parent: tokens.html
blurb: XRPL NFTの紹介。
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
---

16
content/concepts/tokens/non-fungible-tokens.md
View File

@@ -2,8 +2,6 @@
html: non-fungible-tokens.html
parent: tokens.html
blurb: Introduction to XRPL NFTs.
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
---
@@ -17,16 +15,16 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Background
The XRP Ledger offers support for [tokens](tokens.html), also known as _IOUs_. Such assets are, primarily, fungible.
The XRP Ledger offers support for [tokens](tokens.html). Such assets are, primarily, fungible.
> Fun·gi·ble /ˈfənjəbəl/ (adj)
> Fun·gi·ble /´fənjəbəl/ (adj) <!-- SPELLING_IGNORE: fənjəbəl -->
>
> 1. able to replace or be replaced by another identical item; mutually interchangeable.
> 1. able to replace or be replaced by another identical item; mutually interchangeable. <!-- STYLE_OVERRIDE: identical -->
Fungible tokens can be easily traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
Fungible tokens can be traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would purchase a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would buy a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
![Jenny Stamps](img/nft-concepts1.png "Jenny Stamps")
@@ -34,7 +32,7 @@ But since you are standing around in 1919, you might be offered 24-cent airmail
![Jenny Stamps](img/nft-concepts2.png "Jenny Stamps")
Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
Those stamps cannot be replaced by an ordinary 24-cent stamp. They have become _non-fungible_.
To represent digital assets similar to these, use the XRP Ledger's Non-Fungible Tokens feature (sometimes referred to by its standards draft number, [XLS-20](https://github.com/XRPLF/XRPL-Standards/discussions/46)).
@@ -45,7 +43,7 @@ On the XRP Ledger, a non-fungible token is represented as a [NFToken][] object.
The ledger stores up to 32 `NFToken` objects owned by the same account in a single [NFTokenPage object][] to save space. As a result, the owner's [reserve requirement](reserves.html) for `NFToken` objects only increases when the ledger needs to make a new page to store additional tokens.
Accounts can also designate a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
Accounts can also name a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
`NFToken` objects have several settings that are defined when the token is minted and cannot be changed later. These include:

4
content/concepts/tokens/tokens.md
View File

@@ -8,7 +8,7 @@ labels:
All assets other than XRP can be represented in the XRP Ledger as **tokens**. Standard tokens are tracked in relationships called [trust lines](trust-lines-and-issuing.html) between accounts. Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who don't want them. Tokens can represent any type of value, including "stablecoins" backed by assets that exist outside of the ledger, purely digital tokens created specifically on the XRP Ledger, community credit, and more.
**Note:** Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent.
**Note:** Tokens on the XRP Ledger have also been called "IOUs" (as in [I-owe-you](https://en.wikipedia.org/wiki/IOU)) and "issued currencies" in the past. However, these terms are not preferred because they do not cover the full range of digital assets that XRP Ledger tokens can represent. <!-- STYLE_OVERRIDE: ious -->
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) for details of the XRP Ledger's native support.
@@ -23,7 +23,7 @@ A common model for tokens in the XRP Ledger is that an issuer holds assets of eq
A stablecoin issuer should offer _deposits_ and _withdrawals_ to exchange the tokens for the actual currency or asset in the world outside the XRP Ledger.
In practice, the XRP Ledger is a computer system that cannot enforce any rules outside of itself, so stablecoins on the XRP Ledger depend on their issuer's integrity. If you can't count on the stablecoin's issuer to redeem your tokens for the real thing on demand, then you shouldn't expect the stablecoin to retain its value. As a user, you should be mindful of who's issuing the tokens: are they reliable, lawful, and solvent? If not, it's probably best not to hold those tokens.
In practice, the XRP Ledger is a computer system that cannot enforce any rules outside of itself, so stablecoins on the XRP Ledger depend on their issuer's integrity. If you can't count on the stablecoin's issuer to redeem your tokens for the real thing on demand, then you shouldn't expect the stablecoin to hold its value. As a user, you should be mindful of who's issuing the tokens: are they reliable, lawful, and solvent? If not, it's probably best not to hold those tokens.
For more information on how to run a gateway, see the [Becoming an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html).

2
content/concepts/tokens/trust-lines-and-issuing.md
View File

@@ -51,7 +51,7 @@ In addition to the shared balance, each account has its own settings on the trus
Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](reserves.html). Either or both accounts in the trust line may be charged the reserve for the trust line, depending on the status of the trust line: if any of your settings are not the default, or if you hold a positive balance, it counts as one item toward your owner reserve.
Generally, this means that the account that created the trust line is responsible for the reserve and the issuer is not.
Generally, this means that the account that created the trust line is responsible for the reserve and the issuer is not. <!-- STYLE_OVERRIDE: is responsible for -->
Trust lines are automatically deleted if both sides' settings are in the default state and the balance is 0. This means that, to delete a trust line, you need to:

4
content/concepts/xrpl-servers/ledger-history/history-sharding.md
View File

@@ -10,7 +10,7 @@ labels:
[Introduced in: rippled 0.90.0][]
As XRP Ledger servers run, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each server stores that ledger data in its _ledger store_, but [online deletion](online-deletion.html) removes old ledgers' data automatically over time. History sharding provides a separate storage system for older ledger history so that the network can divide up the work of recording the entire (multiple terabyte) history of the XRP Ledger.
As XRP Ledger servers run, they naturally produce a database containing data about the ledgers they built or acquired during network runtime. Each server stores that ledger data in its _ledger store_, but [online deletion](online-deletion.html) removes old ledgers' data automatically over time. History sharding provides a separate storage system for older ledger history so that the network can divide up the work of recording the entire (multiple terabyte) history of the XRP Ledger.
Historical sharding distributes the transaction history of the XRP Ledger into segments, called shards, across servers in the XRP Ledger network. A shard is a range of ledgers. A server uses mostly the same format for ledgers in both the ledger store and the shard store, but the two stores are separate.
@@ -30,7 +30,7 @@ The server selects and downloads additional shards until it reaches the maximum
The history of all ledgers is shared by servers agreeing to keep particular ranges of historical ledgers. This makes it possible for servers to confirm that they have all the data they agreed to maintain, and produce "proof trees" or "ledger deltas" which shows how each ledger in the blockchain's history was the result of applying transactions to the previous state. Since servers that are configured with history sharding randomly select the shards that they store, the entire history of all closed ledgers is stored in a normal distribution curve, increasing the probability that the XRP Ledger Network evenly maintains the history.
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce binary-identical data regardless of what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) [New in: rippled 1.8.1][]
History shards are recorded in a deterministic format, so that any two servers assembling the same shard produce the exact same binary data no matter what order they acquired the data and where they got it from. This makes it possible to compare checksums or cryptographic hashes of the shard data to verify the integrity of the data, and it is possible to share and import history shards through other formats. (For example, you could download shard data using Bittorrent or acquire physical media with the shard data pre-loaded on it, and verify that it matches the data that can be downloaded from the network.) [New in: rippled 1.8.1][]
## See Also

6
content/concepts/xrpl-servers/ledger-history/ledger-history.md
View File

@@ -29,7 +29,7 @@ The [server_info method][] reports how many ledger versions your server has avai
When an XRP Ledger server starts, its first priority is to get a complete copy of the latest validated ledger. From there, it keeps up with advances in the ledger progress. The server fills in any gaps in its ledger history that occur after syncing, and can backfill history from before it became synced. (Gaps in ledger history can occur if a server temporarily becomes too busy to keep up with the network, loses its network connection, or suffers other temporary issues.) When downloading ledger history, the server requests the missing data from its [peer servers](peer-protocol.html), and verifies the data's integrity using cryptographic [hashes][Hash].
Backfilling history is one of the server's lowest priorities, so it may take a long time to fill missing history, especially if the server is busy or has less than sufficient hardware and network specs. For recommendations on hardware specs, see [Capacity Planning](capacity-planning.html). Backfilling history also requires that at least one of the server's direct peers has the history in question. For more information on managing your server's peer-to-peer connections, see [Configure Peering](configure-peering.html).
Backfilling history is one of the server's lowest priorities, so it may take a long time to fill missing history, especially if the server is busy or its hardware and network specs aren't good enough. For recommendations on hardware specs, see [Capacity Planning](capacity-planning.html). Backfilling history also requires that at least one of the server's direct peers has the history in question. For more information on managing your server's peer-to-peer connections, see [Configure Peering](configure-peering.html).
The XRP Ledger identifies data (on several different levels) by a unique hash of its contents. The XRP Ledger's state data contains a short summary of the ledger's history, in the form of the [LedgerHashes object type](ledgerhashes.html). Servers use the LedgerHashes objects to know which ledger versions to fetch, and to confirm that the ledger data they receive is correct and complete.
@@ -49,7 +49,7 @@ The `[ledger_history]` setting defines a minimum number of ledgers to accumulate
Some servers in the XRP Ledger network are configured as "full-history" servers. These servers, which require significantly more disk space than other tracking servers, collect all available XRP Ledger history and **do not use online deletion**.
The XRP Ledger Foundation provides access to a set of full history servers operated by community members (see [xrplcluster.com](https://xrplcluster.com) for more details).
Ripple also provides a set of public full-history servers as a public service at `s2.ripple.com`.
Ripple also provides a set of public full-history servers as a public service at `s2.ripple.com`. <!-- SPELLING_IGNORE: xrplcluster -->
Providers of Full History servers reserve the right to block access that is found to abuse resources, or put inordinate load on the systems.
@@ -59,7 +59,7 @@ For instructions on setting up full history, see [Configure Full History](config
## History Sharding
An alternative to storing the full history of the XRP Ledger on a single expensive machine is to configure many servers to each store a portion of ledger history. The [History Sharding](history-sharding.html) feature makes this possible, storing ranges of ledger history in a separate storage area called the _shard store_. When a peer server asks for specific data (as described in [fetching history](#fetching-history) above), a server can answer using data from either its ledger store or shard store.
An alternative to storing the full history of the XRP Ledger on a single expensive machine is to configure many servers to each store a part of all ledger history. The [History Sharding](history-sharding.html) feature makes this possible, storing ranges of ledger history in a separate storage area called the _shard store_. When a peer server asks for specific data (as described in [fetching history](#fetching-history) above), a server can answer using data from either its ledger store or shard store.
Online deletion **does not** delete from the shard store. However, if you configure online deletion to keep at least 32768 ledger versions in your server's ledger store, your server can copy full shards from the ledger store to the shard store before automatically deleting them from the ledger store.

10
content/concepts/xrpl-servers/ledger-history/online-deletion.md
View File

@@ -22,7 +22,7 @@ The default config file sets the `rippled` server to keep the most recent 2000 l
The `rippled` server stores [ledger history](ledger-history.html) in its _ledger store_. This data accumulates over time.
Inside the ledger store, ledger data is "de-duplicated". In other words, data that doesn't change from version to version is only stored once. The records themselves in the ledger store do not indicate which ledger version(s) contain them; part of the work of online deletion is identifying which records are only used by outdated ledger versions. This process is time consuming and affects the disk I/O and application cache, so it is not feasible to delete old data on every ledger close.
Inside the ledger store, ledger data is "de-duplicated". In other words, data that doesn't change from version to version is only stored once. The records themselves in the ledger store do not indicate which ledger version(s) contain them; part of the work of online deletion is identifying which records are only used by outdated ledger versions. This process is time consuming and affects the disk I/O and application cache, so the server cannot delete old data every time it closes a new ledger.
## Online Deletion Behavior
@@ -38,7 +38,7 @@ The online deletion settings configure how many ledger versions the `rippled` se
The amount of data the server stores depends on how often you call [can_delete][can_delete method] and how big an interval of time your `online_delete` setting represents:
- If you call `can_delete` _more often_ than your `online_delete` interval, the server stores at most a number of ledger versions approximately equal to **twice the `online_delete` value**. (After deletion, this is reduced to approximately the `online_delete` value.) <!-- STYLE_OVERRIDE: a number of -->
- If you call `can_delete` _more often_ than your `online_delete` interval, the server stores **up to twice the `online_delete` number** of ledger versions. (After deletion, this is reduced to approximately the `online_delete` value.)
For example, if you call `can_delete` with a value of `now` once per day and an `online_delete` value of 50,000, the server typically stores up to 100,000 ledger versions before running deletion. After running deletion, the server keeps at least 50,000 ledger versions (about two days' worth). With this configuration, approximately every other `can_delete` call results in no change because the server does not have enough ledger versions to delete.
@@ -66,13 +66,13 @@ To temporarily disable online deletion, you can use the [can_delete method][] wi
The following settings relate to online deletion:
- **`online_delete`** - Specify a number of validated ledger versions to keep. The server periodically deletes any ledger versions that are older than this number. If not specified, no ledgers are deleted.
- **`online_delete`** - Specify how many validated ledger versions to keep. The server periodically deletes any ledger versions that are older than this number. If not specified, no ledgers are deleted.
The default config file specifies 2000 for this value. This cannot be less than 256, because some events like [Fee Voting](fee-voting.html) and the [Amendment Process](amendments.html#amendment-process) update only every 256 ledgers.
**Caution:** If you run `rippled` with `online_delete` disabled, then later enable `online_delete` and restart the server, the server disregards but does not delete existing ledger history that your server already downloaded while `online_delete` was disabled. To save disk space, delete your existing history before re-starting the server after changing the `online_delete` setting.
- **`[ledger_history]`** - Specify a number of validated ledgers, equal to or less than `online_delete`. If the server does not have at least this many validated ledger versions, it attempts to backfill them by fetching the data from peers.
- **`[ledger_history]`** - Specify how many validated ledgers to backfill. Must be equal to or less than `online_delete`. If the server does not have at least this many validated ledger versions, it attempts to fetch the data from peers when it can.
The default for this setting is 256 ledgers.
@@ -84,7 +84,7 @@ The following settings relate to online deletion:
This setting is disabled by default.
- **`[fetch_depth]`** - Specify a number of ledger versions. The server does not accept fetch requests from peers for historical data that is older than the specified number of ledger versions. Specify the value `full` to serve any available data to peers.
- **`[fetch_depth]`** - Specify how many ledger versions to serve to peers. The server does not accept fetch requests from peers for historical data that is older than the specified number of ledger versions. Specify the value `full` to serve any available data to peers.
The default for `fetch_depth` is `full` (serve all available data).

8
content/concepts/xrpl-servers/peer-protocol.md
View File

@@ -17,11 +17,11 @@ The peer protocol is the main mode of communication between servers in the XRP L
- Requesting ledger data from historical ledgers, or providing that data.
- Proposing a set of transactions for consensus, or sharing the calculated outcome of applying a consensus transaction set.
To establish a peer-to-peer connection, one server connects to another via HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). (For more information, see the [Overlay Network](https://github.com/ripple/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
To set up a peer-to-peer connection, one server connects to another using HTTPS and requests an [HTTP upgrade](https://tools.ietf.org/html/rfc7230#section-6.7) to switch to the `XRPL/2.0` protocol (formerly `RTXP/1.2`). (For more information, see the [Overlay Network](https://github.com/ripple/rippled/blob/96bbabbd2ece106779bb544aa0e4ce174e99fdf6/src/ripple/overlay/README.md#handshake) article in the [`rippled` repository](https://github.com/ripple/rippled).)
## Peer Discovery
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server establishes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
The XRP Ledger uses a "gossip" protocol to help find servers find others to connect to in the XRP Ledger network. Whenever a server starts up, it reconnects to any other peers it previously connected to. As a fallback, it uses the [hardcoded public hubs](https://github.com/ripple/rippled/blob/fa57859477441b60914e6239382c6fba286a0c26/src/ripple/overlay/impl/OverlayImpl.cpp#L518-L525). After a server successfully connects to a peer, it asks that peer for the contact information (generally, IP address and port) of other XRP Ledger servers that may also be seeking peers. The server can then connect to those servers, and ask them for the contact information of yet more XRP Ledger servers to peer with. Through this process, the server makes enough peer connections that it can remain reliably connected to the rest of the network even if it loses a connection to any single peer.
Typically, a server needs to connect to a public hub only once, for a short amount of time, to find other peers. After doing so, the server may or may not remain connected to the hub, depending on how stable its network connection is, how busy the hub is, and how many other high-quality peers the server finds. The server saves the addresses of these other peers so it can try reconnecting directly to those peers later, after a network outage or a restart.
@@ -63,7 +63,7 @@ The node key pair also identifies other servers for purposes of [clustering](clu
Normally, a `rippled` server attempts to maintain a healthy number of peers, and automatically connects to untrusted peers up to a maximum number. You can configure a `rippled` server to remain connected to specific peer servers in several ways:
- Use **Fixed Peers** to remain always connected to specific other peers based on their IP addresses. This only works if the peers have fixed IP addresses. Use the `[ips_fixed]` config stanza to configure fixed peers. This is a necessary part of [clustering](clustering.html) or [private peers](#private-peers). Fixed peers are defined in the config file, so changes only apply after restarting the server. Fixed peers are most useful for keeping servers connected if those servers are run by the same person or organization.
- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers run by different people or organizations. [New in: rippled 1.4.0][]
- Use **Peer Reservations** to prioritize specific peers. If your server has a peer reservation for a specific peer, then your server always accepts connection requests from that peer even if your server is already at its maximum number of connected peers. (This can cause your server to go _over_ the maximum number of peers.) You identify a reserved peer by its [node key pair](#node-key-pair), so you can do this even for peers with variable IP addresses. Peer reservations are configured through admin commands and saved in the server databases, so they can be adjusted while the server is online and are saved across restarts. Peer reservations are most useful for connecting servers run by different people or organizations. [New in: rippled 1.4.0][] <!-- STYLE_OVERRIDE: prioritize -->
In the following cases, a `rippled` server does not connect to untrusted peers:
@@ -123,7 +123,7 @@ The pros and cons of each configuration are as follows:
</ul></td>
<td><ul>
<li><p>Higher maintenance burden and cost from running multiple servers.</p></li>
<li><p>Does not completely eliminate the possibility of peer connection outages. No matter how many proxies you run, if they all exist on the same server rack, then one network or power outage can affect all of them.</p></li>
<li><p>Does not completely rule out the possibility of peer connection outages. No matter how many proxies you run, if they all exist on the same server rack, then one network or power outage can affect all of them.</p></li>
</ul></td>
</tr>
<tr><th>Private Server Using Public Hubs</th>

2
content/concepts/xrpl-servers/rippled-server-modes.md
View File

@@ -70,7 +70,7 @@ For more information about running a validator, see [Run `rippled` as a Validato
## Reporting Mode
[New in: rippled 1.7.0][]
Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](https://xrpl.org/configure-grpc.html) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
Reporting mode is specialized mode for serving API requests more efficiently. In this mode, the server gets the latest validated ledger data over [gRPC](configure-grpc.html) from a separate `rippled` server running in P2P Mode, then loads that data into a relational database ([PostgreSQL](https://www.postgresql.org/)). The reporting mode server does not directly participate in the peer-to-peer network, though it can forward requests such as transaction submission to the P2P Mode server it uses.
Multiple reporting mode servers can share access to a PostgreSQL database and [Apache Cassandra](https://cassandra.apache.org/) cluster to serve a large amount of history without each server needing a redundant copy of all the data. Reporting mode servers provide this data through the same [`rippled` APIs](http-websocket-apis.html) with some slight changes to accommodate for the differences in how they store the underlying data.

10
content/concepts/xrpl-servers/transaction-censorship-detection.md
View File

@@ -11,7 +11,7 @@ labels:
The XRP Ledger is designed to be censorship resistant. In support of this design, the XRP Ledger provides an automated transaction censorship detector that is available on all `rippled` servers, enabling all participants to see if censorship is affecting the network.
While a `rippled` server is in sync with the network, the detector tracks all transactions that, in the view of the `rippled` server, should have been accepted in the last round of [consensus](intro-to-consensus.html) and included in the last validated ledger. The detector issues log messages of increasing severity for transactions that have not been included in a validated ledger after several rounds of consensus.
While a `rippled` server is in sync with the network, the detector tracks all transactions that should have been accepted in the last round of [consensus](intro-to-consensus.html) and included in the last validated ledger. The detector issues log messages of increasing severity when it sees transactions that have not been included in a validated ledger after several rounds of consensus.
@@ -19,7 +19,7 @@ While a `rippled` server is in sync with the network, the detector tracks all tr
At a high-level, here’s how the transaction censorship detector works:
1. The detector adds all transactions in a `rippled` server's initial consensus proposal to the tracker.
1. The detector adds all transactions in the server's initial consensus proposal to the tracker.
2. At the close of the consensus round, the detector removes all transactions included in the resulting validated ledger from the tracker.
@@ -55,11 +55,11 @@ The transaction censorship detector may issue false positives in certain scenari
Here are some scenarios that could cause the detector to issue false positive messages:
- Your `rippled` server is running a build with code that is different from the rest of the network. This may cause your `rippled` server to apply transactions differently, resulting in false positives. While this type of false positive is unlikely, in general, it is crucial that you run the correct version of `rippled`.
- Your server is running a build with code that is different from the rest of the network. This may cause your server to apply transactions differently, resulting in false positives. While this type of false positive is unlikely, in general, it is crucial that you run a compatible version of the core XRP Ledger server.
- Your `rippled` server is out of sync with the network and has not yet realized it.
- Your server is out of sync with the network and has not yet realized it.
- `rippled` servers in the network, including possibly your own server, are being impacted by a class of bug that causes `rippled` servers to inconsistently relay transactions to other `rippled` servers in the network.
- Servers in the network, including possibly your own server, have a bug that causes them to inconsistently relay transactions to other servers in the network.
Currently, there are no known bugs that cause this unexpected behavior. However, if you see the impact of what you suspect is a bug, consider reporting it to the [Ripple Bug Bounty](https://ripple.com/bug-bounty/) program.

4
content/faq.md
View File

@@ -104,9 +104,9 @@ For recommendations and best practices, see [Run `rippled` as a Validator](run-r
#### If the dUNL has the most influence on the network, then is the XRPL centralized?
Validators can choose to not use the dUNL, or any widely-used UNL for that matter. Anyone can create a new UNL at any time.
There can be multiple UNLs in use on the same network. Each operator can customize their server's own UNL or choose to follow a different recommended list. All these servers can still operate on the same chain and reach consensus with one another.
There can be multiple UNLs in use on the same network. Each operator can customize their server's own UNL or choose to follow a different recommended list. All these servers can still run the same chain and reach consensus with one another.
However, if your UNL does not have sufficient overlap with the UNLs used by others, there is a risk that your server forks away from the rest of the network. As long as your UNL has > 90% overlap with the one used by people you're transacting with, you are completely safe from forking. If you have less overlap, you may still be able to follow the same chain, but the chances of forking increase with lower overlap, worse network connectivity, and the presence of unreliable or malicious validators on your UNL.
However, if your UNL does not have enough overlap with the UNLs used by others, there is a risk that your server forks away from the rest of the network. As long as your UNL has > 90% overlap with the one used by people you're transacting with, you are completely safe from forking. If you have less overlap, you may still be able to follow the same chain, but the chances of forking increase with lower overlap, worse network connectivity, and the presence of unreliable or malicious validators on your UNL.
## Role of XRP

6
content/references/http-websocket-apis/admin-api-methods/key-generation-methods/wallet_propose.md
View File

@@ -177,9 +177,9 @@ The response follows the [standard format][], with a successful result containin
| `Field` | Type | Description |
|:------------------|:-------|:------------------------------------------------|
| `key_type` | String | Which [signing algorithm](cryptographic-keys.html#signing-algorithms) was used to derive this key pair. Valid values are `ed25519` and `secp256k1` (all lower case). |
| `master_seed` | String | This is the private key of the key pair. The master seed from which all other information about this account is derived, in the XRP Ledger's [base58][] encoded string format. Typically, you use the key in this format to sign transactions. |
| `master_seed_hex` | String | The master seed, in hex format. A simple, widely-supported way to represent the private key. Can be used to sign transactions. |
| `master_key` | String | **DEPRECATED** The master seed, in [RFC-1751][] format. An easier to remember, easier-to-write-down version of the private key. Can be used to sign transactions. **Note:** The `rippled` implementation reverses the byte order of the key after decoding from RFC-1751 and before encoding it to RFC-1751; if you read or write keys for use with the XRP Ledger using a different RFC-1751 implementation, you must do the same to be compatible with `rippled`'s RFC-1751 encoding. |
| `master_seed` | String | The [master seed](cryptographic-keys.html#key-components), in the XRP Ledger's [base58][] encoded string format. Typically, you use the key in this format to sign transactions. |
| `master_seed_hex` | String | The master seed, in hex format. |
| `master_key` | String | **DEPRECATED** The master seed, in [RFC-1751][] format. **Note:** The `rippled` implementation reverses the byte order of the key after decoding from RFC-1751 and before encoding to RFC-1751; if you read or write keys for use with the XRP Ledger using a different RFC-1751 implementation, you must do the same to be compatible with `rippled`'s RFC-1751 encoding. |
| `account_id` | String | The [Address][] of the account in the XRP Ledger's [base58][] format. This is not the public key, but a hash-of-a-hash of it. It also has a checksum so a typo almost certainly results in an invalid address rather than a valid, but different address. This is the primary identifier of an account in the XRP Ledger. You tell people this to get paid, and use it in transactions to indicate who you are and who you're paying, trusting, and so forth. [Multi-signing lists](multi-signing.html) also use these to identify other signers. |
| `public_key` | String | The public key of the key pair, in the XRP Ledger's [base58][] encoded string format. Derived from the `master_seed`. |
| `public_key_hex` | String | This is the public key of the key pair, in hexadecimal. Derived from the `master_seed`. To validate the signature on a transaction, `rippled` needs this public key. That's why the format for a signed transaction includes the public key in the `SigningPubKey` field. |

2
content/references/http-websocket-apis/admin-api-methods/peer-management-methods/connect.md
View File

@@ -101,7 +101,7 @@ The response follows the [standard format][], with a successful result containin
- Any of the [universal error types][].
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
- Cannot connect in standalone mode - Network-related commands are disabled in stand-alone mode.
- Cannot connect in stand-alone mode - Network-related commands are disabled in stand-alone mode.
- `reportingUnsupported` - ([Reporting Mode][] servers only) This method is not available in Reporting Mode.
<!--{# common link defs #}-->

2
content/references/http-websocket-apis/admin-api-methods/status-and-debugging-methods/validators.md
View File

@@ -484,7 +484,7 @@ The response follows the [standard format][], with a successful result containin
| `signing_keys` | Object | Mapping from master public key to current ephemeral public key for all currently-trusted validators. Excludes validators that don't use an ephemeral signing key. |
| `trusted_validator_keys` | Array | Array of master public keys of all currently trusted validators. |
| `validation_quorum` | Number | Minimum number of trusted validations required to validate a ledger version. Some circumstances may cause the server to require more validations. |
| `validator_list_expires` | String | The human readable time when the current validator list will expire. There are two special cases: the string `unknown` if the server has not yet loaded a published validator list, or the string `never` if the server uses a static validator list. |
| `validator_list_expires` | String | The human readable time when the current validator list expires. There are two special cases: the string `unknown` if the server has not yet loaded a published validator list, or the string `never` if the server uses a static validator list. |
Each member of the `publisher_lists` array is a **Publisher List** object with the following fields:

12
content/references/http-websocket-apis/api-conventions/markers-and-pagination.md
View File

@@ -8,3 +8,15 @@ blurb: Convention for paginating large queries into multiple responses.
Some methods return more data than can efficiently fit into one response. When there are more results than contained, the response includes a `marker` field. You can use this to retrieve more pages of data across multiple calls. In each request, pass the `marker` value from the previous response to resume from the point where you left off. If the `marker` is omitted from a response, then you have reached the end of the data set.
The format of the `marker` field is intentionally undefined. Each server can define a `marker` field as desired, so it may take the form of a string, a nested object, or another type. Different servers, and different methods provided by the same server, can have different `marker` definitions. Each `marker` is ephemeral, and may not work as expected after 10 minutes.
<!-- MULTICODE_BLOCK_START -->
_Python_
{{ include_code("_code-samples/markers-and-pagination/py/pagination-with-markers.py", language="py") }}
_JavaScript_
{{ include_code("_code-samples/markers-and-pagination/js/pagination-with-markers.js", language="js") }}
<!-- MULTICODE_BLOCK_END -->

2
content/references/http-websocket-apis/api-conventions/request-formatting.md
View File

@@ -102,7 +102,7 @@ The commandline always uses the latest [API version](#api-versioning).
The `rippled` server uses a single integer to identify the API version to use. The first API version is `1`; currently, this is the only version of the `rippled` API. (There is no API version 0.) [New in: rippled 1.5.0][]
Future versions of `rippled` that introduce breaking changes will introduce a new API version number, such as `2`. The server will support a range of API versions, which it reports in the `version` API method. <!-- TODO: add a link when `version` method is documented. --> <!-- Uncomment when multiple API versions exist: Separate API requests can use different API versions even on the same persistent connection. For example, if you connect WebSocket to a server that supports API versions 1 and 2, you can make a server_info request using API version 2 and then make another server_info request using API version 1 from the same connection. -->
Future versions of `rippled` that introduce breaking changes will introduce a new API version number, such as `2`. The server will support a range of API versions, which it reports in the `version` API method. <!-- STYLE_OVERRIDE: will --> <!-- TODO: add a link when `version` method is documented. --> <!-- Uncomment when multiple API versions exist: Separate API requests can use different API versions even on the same persistent connection. For example, if you connect WebSocket to a server that supports API versions 1 and 2, you can make a server_info request using API version 2 and then make another server_info request using API version 1 from the same connection. -->
### Breaking Changes

6
content/references/http-websocket-apis/commandline-usage.md
View File

@@ -86,7 +86,7 @@ The following options determine which ledger to load first when starting up. The
| `--ledgerfile {FILE}` | Load the ledger version from the specified `{FILE}`, which must contain a complete ledger in JSON format. For an example of such a file, see the provided [`ledger-file.json`]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_api-examples/rippled-cli/ledger-file.json). |
| `--load` | **DEPRECATED** Intended for debugging. Only load the initial ledger from the ledger store on disk. |
| `--replay` | Intended for debugging. Use with `--ledger` to replay a ledger close. Your server must have the ledger in question and its direct ancestor already in the ledger store. Using the previous ledger as a base, the server processes all the transactions in the specified ledger, resulting in a re-creation of the specified ledger. With a debugger, you can add breakpoints to analyze specific transaction processing logic. |
| `--start` | Intended for debugging. Start with a new genesis ledger that has all known amendments (except those the server is configured to vote against) enabled. The functionality of those amendments is therefore available starting from the second ledger, rather than going through the full two-week [Amendment Process](amendments.html). |
| `--start` | Intended for debugging. Start with a new genesis ledger that has all known amendments (except those the server is configured to vote against) enabled. This makes the functionality of those amendments available right away, instead of needing to wait two weeks for the [Amendment Process](amendments.html). |
| `--valid` | **DEPRECATED** Intended for debugging. Consider the initial ledger a valid network ledger even before fully syncing with the network. |
## Client Mode Options
@@ -99,7 +99,7 @@ In client mode, the `rippled` executable acts as a client to another `rippled` s
To run in client mode, provide the [commandline syntax](request-formatting.html#commandline-format) for one of the [`rippled` API](http-websocket-apis.html) methods.
In addition to the individual command syntax, client mode accepts the [Generic Options](#generic-options) and the following options:
Besides the individual commands, client mode accepts the [Generic Options](#generic-options) and the following options:
| Option | Description |
|:------------------------|:---------------------------------------------------|
@@ -131,7 +131,7 @@ If unit testing reports a failure, that generally indicates one of the following
- The source code for `rippled` contains a bug
- A unit test has a bug or has not been updated to account for new behavior
While running unit tests, you can specify the [Generic Options](#generic-options) in addition to any of the following options:
While running unit tests, you can specify the [Generic Options](#generic-options) and any of the following options:
| Option | Short Version | Description |
|:-----------------------------------|:--------------|:------------------------|

5
content/references/http-websocket-apis/public-api-methods/account-methods/account_offers.md
View File

@@ -55,10 +55,9 @@ A request can include the following parameters:
| `Field` | Type | Description |
|:---------------|:----------------------------|:------------------------------|
| `account` | String | A unique identifier for the account, most commonly the account's [Address][]. |
| `ledger` | Unsigned Integer, or String | _(**Deprecated**, Optional)_ A unique identifier for the ledger version to use, such as a ledger index, a hash, or a shortcut such as "validated". |
| `ledger_hash` | String - [Hash][] | _(Optional)_ A 20-byte hex string identifying the ledger version to use. |
| `ledger_index` | Number - [Ledger Index][] | (Optional, defaults to `current`) The [ledger index][] of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See [Specifying Ledgers][]) |
| `limit` | Integer | (Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. Must be within the inclusive range 10 to 400. [New in: rippled 0.26.4][] |
| `ledger_index` | Number - [Ledger Index][] | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
| `limit` | Integer | _(Optional)_ Limit the number of Offers to retrieve. The server may return fewer than this number of results. Must be within the inclusive range 10 to 400. The default is 200. [New in: rippled 0.26.4][] |
| `marker` | [Marker][] | _(Optional)_ Value from a previous paginated response. Resume retrieving data where that response left off. [New in: rippled 0.26.4][] |
| `strict` | Boolean | _(Optional)_ If `true`, then the `account` field only accepts a public key or XRP Ledger address. Otherwise, `account` can be a secret or passphrase (not recommended). The default is `false`. |

2
content/references/http-websocket-apis/public-api-methods/clio-methods/ledger-clio.md
View File

@@ -174,7 +174,7 @@ The response follows the [standard format][], with a successful result containin
| `ledger` | Object | The complete header data of this ledger. |
| `ledger.account_hash` | String | Hash of all account state information in this ledger, as hex |
| `ledger.accountState` | Array | (Omitted unless requested) All the [account-state information](ledger-data-formats.html) in this ledger. |
| `ledger.close_flags` | Integer | A bit-map of flags relating to the closing of this ledger. Currently, the ledger has only one flag defined for `close_flags`: **`sLCF_NoConsensusTime`** (value 1). If this flag is enabled, it means that validators were in conflict regarding the correct close time for the ledger, but build otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger contains a `close_time` that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.) |
| `ledger.close_flags` | Integer | A bit-map of [flags relating to the closing of this ledger](ledger-header.html#close-flags). |
| `ledger.close_time` | Integer | The time this ledger was closed, in [seconds since the Ripple Epoch][] |
| `ledger.close_time_human` | String | The time this ledger was closed, in human-readable format. Always uses the UTC time zone. [Updated in: rippled 1.5.0][] |
| `ledger.close_time_resolution` | Integer | Ledger close times are rounded to within this many seconds. |

8
content/references/http-websocket-apis/public-api-methods/clio-methods/nft_info.md
View File

@@ -48,8 +48,10 @@ The request contains the following parameters:
| `Field` | Type | Description |
|:---------------|:---------------------------|:-------------------------------|
| `nft_id` | String | A unique identifier for the non-fungible token (NFT). |
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. If you do not specify this field, it defaults to `validated`. (See [Specifying Ledgers][]) |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. If you do not specify this field, it defaults to `validated`. Do not specify the `ledger_index` as `closed` or `current`; doing so forwards the request to the P2P `rippled` server and the `nft_info` API is not available on `rippled`. (See [Specifying Ledgers][]) |
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. Do not specify the `ledger_index` as `closed` or `current`; doing so forwards the request to the P2P `rippled` server and the `nft_info` API is not available on `rippled`. (See [Specifying Ledgers][]) |
If you do not specify a ledger version, Clio uses the latest validated ledger.
## Response Format
@@ -135,7 +137,7 @@ The response follows the [standard format][], with a successful result containin
| `issuer` | String | The account ID which denotes the issuer of this NFT. |
| `nft_taxon` | Integer | The NFT’s taxon. |
| `nft_sequence` | Integer | The NFT’s sequence number. |
| `uri` | String or `null` | _(Omitted if the NFT is burned at this ledger.)_. This field is `null` if the NFT is not burned at this ledger but does not have a URI. If the NFT is not burned at this ledger and it does have a URI, this field is a string containing the decoded URI of the NFT. NOTE: If you need to retrieve the URI of a burnt token, re-request `nft_info` for this token, specifying the `ledger_index` as the one previous to the index where this token was burned ({ledger_index-where-token-was-burned} - 1). |
| `uri` | String or `null` | _(Omitted if the NFT is burned at this ledger.)_. This field is `null` if the NFT is not burned at this ledger but does not have a URI. If the NFT is not burned at this ledger and it does have a URI, this field is a string containing the decoded URI of the NFT. NOTE: If you need to retrieve the URI of a burnt token, re-request `nft_info` for this token, specifying the `ledger_index` as the one previous to the index where this token was burned ({_ledger-index-where-token-was-burned_} - 1). |
## Possible Errors

18
content/references/http-websocket-apis/public-api-methods/clio-methods/server_info-clio.md
View File

@@ -46,7 +46,7 @@ The request does not take any parameters.
When a client connects to the `Clio` server over `localhost`, the response includes the `counters` and `etl` objects. These objects are omitted from the response when the client is not located on the same server, and hence does not connect over `localhost`.
An example of a successful response when client connects over localhost:
An example of a successful response when client connects over `localhost`:
<!-- MULTICODE_BLOCK_START -->
@@ -477,7 +477,7 @@ An example of a successful response when client connects over localhost:
<!-- MULTICODE_BLOCK_END -->
An example of a successful response when client does not connect over localhost:
An example of a successful response when client does not connect over `localhost`:
<!-- MULTICODE_BLOCK_START -->
@@ -569,11 +569,11 @@ The `info` object may have some arrangement of the following fields:
| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. This may be a disjoint sequence such as `24900901-24900984,24901116-24901158`. If the server does not have any complete ledgers (for example, it recently started syncing with the network), this is the string `empty`. |
| `counters` | Object | _(May be omitted)_ Stats on API calls handled since server startup. This is present only if the client connects to the `Clio` server over `localhost`.
| `rpc` | Object | _(May be omitted)_ Stats on each API call handled by the Clio server since startup. Since this is nested within the `counters` object, this is also present only if the client connects to the `Clio` server over `localhost`. |
| `rpc.*.started` | Number | Number of RPCs of this type that the Clio server has started processing since startup. |
| `rpc.*.finished` | Number | Number of RPCs of this type that the Clio server has finished processing since startup. |
| `rpc.*.errored` | Number | Number of RPCs of this type that have resulted in some sort of error since startup. |
| `rpc.*.forwarded` | Number | Number of RPCs of this type that the Clio server has forwarded to a `rippled` P2P server since startup. |
| `rpc.*.duration_us` | Number | The total number of microseconds spent processing RPCs of this type since startup. |
| `rpc.*.started` | Number | Number of API calls of this type that the Clio server has started processing since startup. |
| `rpc.*.finished` | Number | Number of API calls of this type that the Clio server has finished processing since startup. |
| `rpc.*.errored` | Number | Number of API calls of this type that have resulted in some sort of error since startup. |
| `rpc.*.forwarded` | Number | Number of API calls of this type that the Clio server has forwarded to a `rippled` P2P server since startup. |
| `rpc.*.duration_us` | Number | The total number of microseconds spent processing API calls of this type since startup. |
| `subscriptions` | Object | _(May be omitted)_ Number of current subscribers for each stream type. Since this is nested within the `counters` object, this is also present only if the client connects to the `Clio` server over `localhost`. |
| `subscriptions.ledger` | | |
| `subscriptions.transactions` | | |
@@ -594,10 +594,10 @@ The `info` object may have some arrangement of the following fields:
| `validated_ledger.reserve_base_xrp` | Number | Minimum amount of XRP (not drops) necessary for every account to keep in reserve. This may be represented in scientific notation such as `1e-05` for 0.00001. |
| `validated_ledger.reserve_inc_xrp` | Number | Amount of XRP (not drops) added to the account reserve for each object an account owns in the ledger. This may be represented in scientific notation such as `1e-05` for 0.00001. |
| `validated_ledger.seq` | Number | The [ledger index][] of the latest validated ledger. |
| `validator_list_expires` | String | _(Admin only)_ Either the human readable time, in UTC, when the current validator list will expire, the string `unknown` if the server has yet to load a published validator list or the string `never` if the server uses a static validator list. [Updated in: rippled 1.5.0][] |
| `validator_list_expires` | String | _(Admin only)_ Either the human readable time, in UTC, when the current validator list expires, the string `unknown` if the server has yet to load a published validator list or the string `never` if the server uses a static validator list. [Updated in: rippled 1.5.0][] |
| `cache` | Object | Information on Clio's state data cache. |
| `cache.size` | Number | Number of state data objects currently in the cache. |
| `cache.is_full` | Boolean | True if cache contains all state data for a specific ledger, false otherwise. Some RPCs, such as book_offers, process much faster when the cache is full. |
| `cache.is_full` | Boolean | True if cache contains all state data for a specific ledger, false otherwise. Some API calls, such as the [book_offers method][], process much faster when the cache is full. |
| `cache.latest_ledger_seq` | Number | The [ledger index][] of the latest validated ledger stored in the cache. |
| `etl` | Object | The `rippled` sources (ETL sources) that the Clio server is connected to. This is present only if the client connects to the `Clio` server over `localhost`. |
| `etl.etl_sources` | Object Array | List the `rippled` sources (ETL sources) that the Clio server is connected to and extracts data from. |

12
content/references/http-websocket-apis/public-api-methods/ledger-methods/ledger.md
View File

@@ -67,11 +67,11 @@ The request can contain the following parameters:
|:---------------|:---------------------------|:-------------------------------|
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]). |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
| `full` | Boolean | _(Optional)_ **Admin required** If `true`, return full information on the entire ledger. Ignored if you did not specify a ledger version. Defaults to `false`. (Equivalent to enabling `transactions`, `accounts`, and `expand`.) **Caution:** This is a very large amount of data -- on the order of several hundred megabytes! |
| `accounts` | Boolean | _(Optional)_ **Admin required.** If `true`, return information on accounts in the ledger. Ignored if you did not specify a ledger version. Defaults to `false`. **Caution:** This returns a very large amount of data! |
| `transactions` | Boolean | _(Optional)_ If `true`, return information on transactions in the specified ledger version. Defaults to `false`. Ignored if you did not specify a ledger version. |
| `expand` | Boolean | _(Optional)_ Provide full JSON-formatted information for transaction/account information instead of only hashes. Defaults to `false`. Ignored unless you request transactions, accounts, or both. |
| `owner_funds` | Boolean | _(Optional)_ If `true`, include `owner_funds` field in the metadata of OfferCreate transactions in the response. Defaults to `false`. Ignored unless transactions are included and `expand` is true. |
| `full` | Boolean | _(Optional)_ **Admin required** If `true`, return full information on the entire ledger. Ignored if you did not specify a ledger version. The default is `false`. (Equivalent to enabling `transactions`, `accounts`, and `expand`.) The [Clio server](the-clio-server.html) does not support this field. **Caution:** On Mainnet, this can be gigabytes worth of data, so the request is likely to time out. |
| `accounts` | Boolean | _(Optional)_ **Admin required.** If `true`, return information on accounts in the ledger. Ignored if you did not specify a ledger version. The default is `false`. **Caution:** On Mainnet, this can be gigabytes worth of data, so the request is likely to time out. |
| `transactions` | Boolean | _(Optional)_ If `true`, return information on transactions in the specified ledger version. The default is `false`. Ignored if you did not specify a ledger version. |
| `expand` | Boolean | _(Optional)_ Provide full JSON-formatted information for transaction/account information instead of only hashes. The default is `false`. Ignored unless you request transactions, accounts, or both. |
| `owner_funds` | Boolean | _(Optional)_ If `true`, include `owner_funds` field in the metadata of OfferCreate transactions in the response. The default is `false`. Ignored unless transactions are included and `expand` is true. |
| `binary` | Boolean | _(Optional)_ If `true`, and `transactions` and `expand` are both also `true`, return transaction information in binary format (hexadecimal string) instead of JSON format. [New in: rippled 0.28.0][] |
| `queue` | Boolean | _(Optional)_ If `true`, and the command is requesting the `current` ledger, includes an array of [queued transactions](transaction-cost.html#queued-transactions) in the results.
@@ -192,7 +192,7 @@ The response follows the [standard format][], with a successful result containin
| `ledger` | Object | The complete header data of this ledger. |
| `ledger.account_hash` | String | Hash of all account state information in this ledger, as hex |
| `ledger.accountState` | Array | (Omitted unless requested) All the [account-state information](ledger-data-formats.html) in this ledger. |
| `ledger.close_flags` | Integer | A bit-map of flags relating to the closing of this ledger. Currently, the ledger has only one flag defined for `close_flags`: **`sLCF_NoConsensusTime`** (value 1). If this flag is enabled, it means that validators were in conflict regarding the correct close time for the ledger, but build otherwise the same ledger, so they declared consensus while "agreeing to disagree" on the close time. In this case, the consensus ledger contains a `close_time` that is 1 second after that of the previous ledger. (In this case, there is no official close time, but the actual real-world close time is probably 3-6 seconds later than the specified `close_time`.) |
| `ledger.close_flags` | Integer | A bit-map of [flags relating to the closing of this ledger](ledger-header.html#close-flags). |
| `ledger.close_time` | Integer | The time this ledger was closed, in [seconds since the Ripple Epoch][] |
| `ledger.close_time_human` | String | The time this ledger was closed, in human-readable format. Always uses the UTC time zone. [Updated in: rippled 1.5.0][] |
| `ledger.close_time_resolution` | Integer | Ledger close times are rounded to within this many seconds. |

15
content/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_data.md
View File

@@ -50,14 +50,13 @@ An example of the request format:
A request can include the following fields:
| `Field` | Type | Description |
|:---------------|:-------------------------------------------|:---------------|
| `id` | (Arbitrary) | (WebSocket only) Any identifier to separate this request from others in case the responses are delayed or out of order. |
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
| `ledger_index` | String or Unsigned Integer | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
| `binary` | Boolean | (Optional, defaults to False) If set to true, return ledger objects as hashed hex strings instead of JSON. |
| `limit` | Integer | (Optional, default varies) Limit the number of ledger objects to retrieve. The server is not required to honor this value. |
| `marker` | [Marker][] | Value from a previous paginated response. Resume retrieving data where that response left off. |
| `Field` | Type | Required? | Description |
|:---------------|:--------------------------|:----------|----------------|
| `ledger_hash` | String - [Hash][] | No | A 20-byte hex string identifying the ledger version to use. |
| `ledger_index` | Number - [Ledger Index][] | No | The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
| `binary` | Boolean | No | If `true`, return ledger entries as hexadecimal strings instead of JSON. The default is `false`. |
| `limit` | Integer | No | Limit the number of ledger entries to retrieve. The server may return fewer than this number of entries. Cannot be more than 2048 (when requesting binary) or 256 (when requesting JSON). The default is the maximum. |
| `marker` | [Marker][] | No | Value from a previous paginated response. Resume retrieving data where that response left off. |
The `ledger` field is deprecated and may be removed without further notice.

26
content/references/http-websocket-apis/public-api-methods/ledger-methods/ledger_entry.md
View File

@@ -392,7 +392,7 @@ Retrieve an [Escrow object](escrow-object.html), which holds XRP until a specifi
"method": "ledger_entry",
"params": [{
"escrow": {
"account": "rL4fPHi2FWGwRGRQSH7gBcxkuo2b9NTjKK",
"owner": "rL4fPHi2FWGwRGRQSH7gBcxkuo2b9NTjKK",
"seq": 126
},
"ledger_index": "validated"
@@ -403,7 +403,7 @@ Retrieve an [Escrow object](escrow-object.html), which holds XRP until a specifi
*Commandline*
```sh
rippled json ledger_entry '{ "escrow": { "account": "rL4fPHi2FWGwRGRQSH7gBcxkuo2b9NTjKK", "seq": 126 }, "ledger_index": "validated" }'
rippled json ledger_entry '{ "escrow": { "owner": "rL4fPHi2FWGwRGRQSH7gBcxkuo2b9NTjKK", "seq": 126 }, "ledger_index": "validated" }'
```
<!-- MULTICODE_BLOCK_END -->
@@ -512,11 +512,11 @@ rippled json ledger_entry '{ "deposit_preauth": { "owner": "rf1BiGeXwwQoi8Z2ueFY
Retrieve a [Ticket object](ticket.html), which represents a [sequence number][] set aside for future use. Can be provided as string (object ID of the Ticket) or as an object. _(Added by the [TicketBatch amendment][])_
| `Field` | Type | Description |
|:------------------------|:---------------------------|:----------------------|
| `ticket` | Object or String | The [Ticket object](ticket.html) to retrieve. If a string, must be the [object ID](ledger-object-ids.html) of the Ticket, as hexadecimal. If an object, the `owner` and `ticket_sequence` sub-fields are required to uniquely specify the Ticket entry. |
| `ticket.owner` | String - [Address][] | _(Required if `ticket` is specified as an object)_ The owner of the Ticket object. |
| `ticket.ticket_sequence` | Unsigned Integer | _(Required if `ticket` is specified as an object)_ The Ticket Sequence number of the Ticket entry to retrieve. |
| `Field` | Type | Description |
|:--------------------|:---------------------|:----------------------|
| `ticket` | Object or String | The [Ticket object](ticket.html) to retrieve. If a string, must be the [object ID](ledger-object-ids.html) of the Ticket, as hexadecimal. If an object, the `account` and `ticket_seq` sub-fields are required to uniquely specify the Ticket entry. |
| `ticket.account` | String - [Address][] | _(Required if `ticket` is specified as an object)_ The owner of the Ticket object. |
| `ticket.ticket_seq` | Number | _(Required if `ticket` is specified as an object)_ The Ticket Sequence number of the Ticket entry to retrieve. |
<!-- MULTICODE_BLOCK_START -->
@@ -527,8 +527,8 @@ Retrieve a [Ticket object](ticket.html), which represents a [sequence number][]
"id": "example_get_ticket",
"command": "ledger_entry",
"ticket": {
"owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"ticket_sequence": 23
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"ticket_seq": 389
},
"ledger_index": "validated"
}
@@ -541,8 +541,8 @@ Retrieve a [Ticket object](ticket.html), which represents a [sequence number][]
"method": "ledger_entry",
"params": [{
"ticket": {
"owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"ticket_sequence": 23
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
"ticket_seq": 389
},
"ledger_index": "validated"
}]
@@ -552,14 +552,12 @@ Retrieve a [Ticket object](ticket.html), which represents a [sequence number][]
*Commandline*
```sh
rippled json ledger_entry '{ "ticket": { "owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "ticket_sequence: 23 }, "ledger_index": "validated" }'
rippled json ledger_entry '{ "ticket": { "account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "ticket_seq: 389 }, "ledger_index": "validated" }'
```
<!-- MULTICODE_BLOCK_END -->
<!-- TODO: enable if/when Tickets are available on Mainnet
[Try it! >](websocket-api-tool.html#ledger_entry-ticket)
-->

223
content/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/amm_info.md Normal file
View File

@@ -0,0 +1,223 @@
---
html: amm_info.html
parent: path-and-order-book-methods.html
blurb: Get info about an Automted Market Maker (AMM) instance.
status: not_enabled
labels:
- Decentralized Exchange
- Cross-Currency
- AMM
---
# amm_info
[[Source]](https://github.com/gregtatcam/rippled/blob/amm-core-functionality/src/ripple/rpc/handlers/AMMInfo.cpp "Source")
<!-- TODO: Update source link to merged version when available -->
The `{{currentpage.name}}` method gets information about an Automated Market Maker (AMM) instance.
{% include '_snippets/amm-disclaimer.md' %}
### Request Format
An example of the request format:
{% include '_snippets/no-cli-syntax.md' %}
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"command": "{{currentpage.name}}",
"asset": {
"currency": "XRP"
},
"asset2": {
"currency": "TST",
"issuer": "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
}
}
```
*JSON-RPC*
```json
{
"method": "{{currentpage.name}}",
"params": [{
"asset": {
"currency": "XRP"
},
"asset2": {
"currency": "TST",
"issuer": "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
}
}]
}
```
<!-- MULTICODE_BLOCK_END -->
[Try it! >](websocket-api-tool.html?server=wss%3A%2F%2Famm.devnet.rippletest.net%3A51233%2F#amm_info)
The request includes the following parameters:
| `Field` | Type | Description |
|:---------|:-----------------|:-----------------------------------|
| `asset` | Object or String | One of the assets of the AMM to look up, as an object with `currency` and `issuer` fields (omit `issuer` for XRP), like [currency amounts][Currency Amount]. For XRP, you can specify as the string `XRP` instead of as an object. |
| `asset2` | Object or String | The other of the assets of the AMM, as an object with `currency` and `issuer` fields (omit `issuer` for XRP), like [currency amounts][Currency Amount]. |
### Response Format
An example of a successful response:
<!-- MULTICODE_BLOCK_START -->
*WebSocket*
```json
{
"result": {
"amm": {
"AMMAccount" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"Asset" : {
"currency" : "XRP"
},
"Asset2" : {
"currency" : "TST",
"issuer" : "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
},
"AuctionSlot" : {
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
"AuthAccounts" : [
{
"AuthAccount" : {
"Account" : "rMKXGCbJ5d8LbrqthdG46q3f969MVK2Qeg"
}
},
{
"AuthAccount" : {
"Account" : "rBepJuTLFJt3WmtLXYAxSjtBWAeQxVbncv"
}
}
],
"DiscountedFee" : 0,
"Expiration" : 721870180,
"Price" : {
"currency" : "039C99CD9AB0B70B32ECDA51EAAE471625608EA2",
"issuer" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"value" : "0.8696263565463045"
}
},
"Flags" : 0,
"LPTokenBalance" : {
"currency" : "039C99CD9AB0B70B32ECDA51EAAE471625608EA2",
"issuer" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"value" : "71150.53584131501"
},
"TradingFee" : 600,
"VoteSlots" : [
{
"VoteEntry" : {
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
"TradingFee" : 600,
"VoteWeight" : 100000
}
}
]
},
"ledger_current_index": 226645,
"validated": false
},
"status": "success",
"type": "response"
}
```
*JSON-RPC*
```json
200 OK
{
"result": {
"amm": {
"AMMAccount" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"Asset" : {
"currency" : "XRP"
},
"Asset2" : {
"currency" : "TST",
"issuer" : "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
},
"AuctionSlot" : {
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
"AuthAccounts" : [
{
"AuthAccount" : {
"Account" : "rMKXGCbJ5d8LbrqthdG46q3f969MVK2Qeg"
}
},
{
"AuthAccount" : {
"Account" : "rBepJuTLFJt3WmtLXYAxSjtBWAeQxVbncv"
}
}
],
"DiscountedFee" : 0,
"Expiration" : 721870180,
"Price" : {
"currency" : "039C99CD9AB0B70B32ECDA51EAAE471625608EA2",
"issuer" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"value" : "0.8696263565463045"
}
},
"Flags" : 0,
"LPTokenBalance" : {
"currency" : "039C99CD9AB0B70B32ECDA51EAAE471625608EA2",
"issuer" : "rE54zDvgnghAoPopCgvtiqWNq3dU5y836S",
"value" : "71150.53584131501"
},
"TradingFee" : 600,
"VoteSlots" : [
{
"VoteEntry" : {
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
"TradingFee" : 600,
"VoteWeight" : 100000
}
}
]
},
"ledger_current_index": 226620,
"status": "success",
"validated": false
}
}
```
<!-- MULTICODE_BLOCK_END -->
The response follows the [standard format][], with a successful result containing the following fields:
| `Field` | Type | Description |
|:-----------------------|:--------|:----------------------------------------------------------|
| `amm` | Object | The [AMM object](amm.html) for the requested asset pair. |
| `ledger_current_index` | Integer | _(Omitted if `ledger_index` is provided instead)_ The [ledger index][] of the current in-progress ledger, which was used when retrieving this information. |
| `ledger_index` | Integer | _(Omitted if `ledger_current_index` is provided instead)_ The [ledger index][] of the ledger version used when retrieving this information. |
| `validated` | Boolean | If `true`, the ledger used for this request is validated and these results are final; if omitted or set to `false`, the data is pending and may change. |
### Possible Errors
- Any of the [universal error types][].
- `actNotFound` - The AMM for this asset pair does not exist, or an issuing account specified in the request does not exist.
- `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

4
content/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/deposit_authorized.md
View File

@@ -9,7 +9,7 @@ labels:
# deposit_authorized
[[Source]](https://github.com/ripple/rippled/blob/817d2339b8632cb2f97d3edd6f7af33aa7631744/src/ripple/rpc/handlers/DepositAuthorized.cpp "Source")
The `deposit_authorized` command indicates whether one account is authorized to send payments directly to another. See [Deposit Authorization](depositauth.html) for information on how to require authorization to deliver money to your account.
The `deposit_authorized` command indicates whether one account is authorized to send payments directly to another. See [Deposit Authorization](depositauth.html) for information on how to require authorization to deliver money to your account. <!-- STYLE_OVERRIDE: is authorized to -->
## Request Format
An example of the request format:
@@ -135,7 +135,7 @@ The response follows the [standard format][], with a successful result containin
| `source_account` | String - [Address][] | The source account specified in the request. |
| `validated` | Boolean | _(May be omitted)_ If `true`, the information comes from a validated ledger version. |
**Note:** A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](trust-lines-and-issuing.html) for the specified currency, or there may not be sufficient liquidity to deliver a payment.
**Note:** A `deposit_authorized` status of `true` does not guarantee that a payment can be sent from the specified source to the specified destination. For example, the destination account may not have a [trust line](trust-lines-and-issuing.html) for the specified currency, or there may not be enough liquidity to deliver a payment.
## Possible Errors

2
content/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/nft_buy_offers.md
View File

@@ -108,7 +108,7 @@ The response follows the [standard format][], with a successful result containin
|:---------|:-----------|:-----------------------------------------------------|
| `nft_id` | String | The NFToken these offers are for, as specified in the request. |
| `offers` | Array | A list of buy offers for the token. Each of these is formatted as a **Buy Offer** (see below). |
| `limit` | Number | _(May be omitted)_The `limit`, as specified in the request. |
| `limit` | Number | _(May be omitted)_ The `limit`, as specified in the request. |
| `marker` | [Marker][] | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. |
### Buy Offers

8
content/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/nft_sell_offers.md
View File

@@ -34,7 +34,11 @@ An example of the request format:
```json
{
"method": "nft_sell_offers",
"tokenid": "00090000D0B007439B080E9B05BF62403911301A7B1F0CFAA048C0A200000007"
"params": [
{
"nft_id": "00090000D0B007439B080E9B05BF62403911301A7B1F0CFAA048C0A200000007"
}
]
}
```
@@ -101,7 +105,7 @@ The response follows the [standard format][], with a successful result containin
|:---------|:-----------|:-----------------------------------------------------|
| `nft_id` | String | The NFToken these offers are for, as specified in the request. |
| `offers` | Array | A list of buy offers for the token. Each of these is formatted as a **Sell Offer** (see below). |
| `limit` | Number | _(May be omitted)_The `limit`, as specified in the request. |
| `limit` | Number | _(May be omitted)_ The `limit`, as specified in the request. |
| `marker` | [Marker][] | _(May be omitted)_ Server-defined value indicating the response is paginated. Pass this to the next call to resume where this call left off. Omitted when there are no pages of information after this one. |
### Sell Offers

26
content/references/http-websocket-apis/public-api-methods/path-and-order-book-methods/path_find.md
View File

@@ -443,21 +443,21 @@ An example of a successful response:
The initial response follows the [standard format](response-formatting.html), with a successful result containing the following fields:
| `Field` | Type | Description |
| Field | Type | Description |
|:----------------------|:-----------------|:----------------------------------|
| `alternatives` | Array | Array of objects with suggested [paths](paths.html) to take, as described below. If empty, then no paths were found connecting the source and destination accounts. |
| `destination_account` | String | Unique address of the account that would receive a transaction |
| `destination_amount` | String or Object | [Currency Amount][] that the destination would receive in a transaction |
| `id` | (Various) | (WebSocket only) The ID provided in the WebSocket request is included again at this level. |
| `source_account` | String | Unique address that would send a transaction |
| `destination_account` | String | Unique address of the account that would receive a transaction. |
| `destination_amount` | String or Object | [Currency Amount][] that the destination would receive in a transaction. |
| `source_account` | String | Unique address that would send a transaction. |
| `full_reply` | Boolean | If `false`, this is the result of an incomplete search. A later reply may have a better path. If `true`, then this is the best path found. (It is still theoretically possible that a better path could exist, but `rippled` won't find it.) Until you close the pathfinding request, `rippled` continues to send updates each time a new ledger closes. [New in: rippled 0.29.0][] |
Each element in the `alternatives` array is an object that represents a path from one possible source currency (held by the initiating account) to the destination account and currency. This object has the following fields:
| `Field` | Type | Description |
|:-----------------|:-----------------|:---------------------------------------|
| `paths_computed` | Array | Array of arrays of objects defining [payment paths](paths.html) |
| `source_amount` | String or Object | [Currency Amount][] that the source would have to send along this path for the destination to receive the desired amount |
| Field | Type | Description |
|:---------------------|:-----------------|:---------------------------------------|
| `paths_computed` | Array | Array of arrays of objects defining [payment paths](paths.html) |
| `source_amount` | String or Object | [Currency Amount][] that the source would have to send along this path for the destination to receive the desired amount. |
| `destination_amount` | String or Object | _(May be omitted)_ [Currency Amount][] that the destination would receive along this path. Only included if the `destination_amount` from the request was the "-1" special case. |
### Possible Errors
@@ -520,7 +520,7 @@ An example of the request format:
The request includes the following parameters:
| `Field` | Type | Description |
| Field | Type | Description |
|:-------------|:-------|:-------------------------------------------|
| `subcommand` | String | Use `"close"` to send the close sub-command |
@@ -528,7 +528,7 @@ The request includes the following parameters:
If a pathfinding request was successfully closed, the response follows the same format as the initial response to [`path_find create`](#path_find-create), plus the following field:
| `Field` | Type | Description |
| Field | Type | Description |
|:---------|:--------|:--------------------------------------------------------|
| `closed` | Boolean | The value `true` indicates this reply is in response to a `path_find close` command. |
@@ -565,7 +565,7 @@ An example of the request format:
The request includes the following parameters:
| `Field` | Type | Description |
| Field | Type | Description |
|:-------------|:-------|:---------------------------------------------|
| `subcommand` | String | Use `"status"` to send the status sub-command |
@@ -573,7 +573,7 @@ The request includes the following parameters:
If a pathfinding request is open, the response follows the same format as the initial response to [`path_find create`](#path_find-create), plus the following field:
| `Field` | Type | Description |
| Field | Type | Description |
|:---------|:--------|:--------------------------------------------------------|
| `status` | Boolean | The value `true` indicates this reply is in response to a `path_find status` command. |

3
content/references/http-websocket-apis/public-api-methods/public-api-methods.ja.md
View File

@@ -55,8 +55,11 @@ XRP Ledgerのアカウントとは、XRPの保有者と取引の送信者を意
パスは、支払いが送信者から受信者に届くまでに中間ステップでたどる道筋を定義します。パスは、送信者と受信者をオーダーブックを介してつなぐことで、複数通貨間の支払いを可能にします。パスと他のオーダーブックに関しては、以下のメソッドを使用します。
* **[`amm_info`](amm_info.html)** :not_enabled: - 自動マーケットメイカー(AMM)についての情報を取得します。
* **[`book_offers`](book_offers.html)** - 2つの通貨を交換するオファーに関する情報を取得します。
* **[`deposit_authorized`](deposit_authorized.html)** - あるアカウントが別のアカウントへの支払いの直接送信について承認されているかどうかを調べます。
* **[`nft_buy_offers`](nft_buy_offers.html)** - Retrieve a list of buy offers for a specified NFToken object.
* **[`nft_sell_offers`](nft_sell_offers.html)** - Retrieve a list of sell offers for a specified NFToken object.
* **[`path_find`](path_find.html)** - 2つのアカウント間の支払いのパスを見つけて、更新を受け取ります。
* **[`ripple_path_find`](ripple_path_find.html)** - 2つのアカウント間の支払いのパスを1回だけ見つけます。

3
content/references/http-websocket-apis/public-api-methods/public-api-methods.md
View File

@@ -59,8 +59,9 @@ By default, the following methods are [admin-only](admin-api-methods.html). They
Paths define a way for payments to flow through intermediary steps on their way from sender to receiver. Paths enable cross-currency payments by connecting sender and receiver through order books. Use these methods to work with paths and other books.
* **[`amm_info`](amm_info.html)** :not_enabled: - Get info about an Automated Market Maker (AMM).
* **[`book_offers`](book_offers.html)** - Get info about offers to exchange two currencies.
* **[`deposit_authorized`](deposit_authorized.html)** - Look up whether one account is authorized to send payments directly to another.
* **[`deposit_authorized`](deposit_authorized.html)** - Look up whether one account is authorized to send payments directly to another. <!-- STYLE_OVERRIDE: is authorized to -->
* **[`nft_buy_offers`](nft_buy_offers.html)** - Retrieve a list of buy offers for a specified NFToken object.
* **[`nft_sell_offers`](nft_sell_offers.html)** - Retrieve a list of sell offers for a specified NFToken object.
* **[`path_find`](path_find.html)** - Find a path for a payment between two accounts and receive updates.

2
content/references/http-websocket-apis/public-api-methods/server-info-methods/manifest.md
View File

@@ -8,7 +8,7 @@ labels:
# manifest
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Manifest.cpp "Source")
The `{{currentpage.name}}` method reports the current "manifest" information for a given validator public key. The "manifest" is the public portion of that validator's configured token. [Updated in: rippled 1.7.0][]
The `{{currentpage.name}}` method reports the current "manifest" information for a given validator public key. The "manifest" is a block of data that authorizes an ephemeral signing key with a signature from the validator's master key pair. [Updated in: rippled 1.7.0][]
### Request Format

191
content/references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md
View File

@@ -61,56 +61,57 @@ An example of a successful response:
"id": 1,
"result": {
"info": {
"build_version": "1.7.2",
"complete_ledgers": "64572720-65887227",
"hostid": "LARD",
"build_version": "1.9.4",
"complete_ledgers": "32570-75801736",
"hostid": "ARMY",
"initial_sync_duration_us": "273518294",
"io_latency_ms": 1,
"jq_trans_overflow": "0",
"jq_trans_overflow": "2282",
"last_close": {
"converge_time_s": 3.004,
"proposers": 41
"converge_time_s": 3.002,
"proposers": 35
},
"load_factor": 512.578125,
"load_factor_server": 1,
"peer_disconnects": "365016",
"peer_disconnects_resources": "336",
"peers": 211,
"pubkey_node": "n9MozjnGB3tpULewtTsVtuudg5JqYFyV3QFdAtVLzJaxHcBaxuXD",
"load_factor": 1,
"network_id": 0,
"peer_disconnects": "3194",
"peer_disconnects_resources": "3",
"peers": 20,
"pubkey_node": "n9KKBZvwPZ95rQi4BP3an1MRctTyavYkZiLpQwasmFYTE6RYdeX3",
"server_state": "full",
"server_state_duration_us": "3589068181859",
"server_state_duration_us": "69205850392",
"state_accounting": {
"connected": {
"duration_us": "301410595",
"transitions": 2
"duration_us": "141058919",
"transitions": "7"
},
"disconnected": {
"duration_us": "1207534",
"transitions": 2
"duration_us": "514136273",
"transitions": "3"
},
"full": {
"duration_us": "3589270527034",
"transitions": 2
"duration_us": "4360230140761",
"transitions": "32"
},
"syncing": {
"duration_us": "6182323",
"transitions": 2
"duration_us": "50606510",
"transitions": "30"
},
"tracking": {
"duration_us": "43",
"transitions": 2
"duration_us": "40245486",
"transitions": "34"
}
},
"time": "2021-Aug-24 20:46:22.194299 UTC",
"uptime": 3589579,
"time": "2022-Nov-16 21:50:22.711679 UTC",
"uptime": 4360976,
"validated_ledger": {
"age": 3,
"age": 1,
"base_fee_xrp": 0.00001,
"hash": "F00F0E590242702B895BE378B6A6D365C094A047CFC8B11DD323D16F81CC67A5",
"reserve_base_xrp": 20,
"reserve_inc_xrp": 5,
"seq": 65887227
"hash": "3147A41F5F013209581FCDCBBB7A87A4F01EF6842963E13B2B14C8565E00A22B",
"reserve_base_xrp": 10,
"reserve_inc_xrp": 2,
"seq": 75801736
},
"validation_quorum": 33
"validation_quorum": 28
}
},
"status": "success",
@@ -126,55 +127,57 @@ An example of a successful response:
{
"result": {
"info": {
"build_version": "1.7.2",
"complete_ledgers": "64735538-65886965",
"hostid": "TOLL",
"build_version": "1.9.4",
"complete_ledgers": "32570-75801747",
"hostid": "ABET",
"initial_sync_duration_us": "566800928",
"io_latency_ms": 1,
"jq_trans_overflow": "3",
"jq_trans_overflow": "47035",
"last_close": {
"converge_time_s": 3,
"proposers": 41
"proposers": 35
},
"load_factor": 1,
"peer_disconnects": "467400",
"peer_disconnects_resources": "16316",
"peers": 85,
"pubkey_node": "n9Mdk7abYaVvded5zic9oDEY3NULv9RmeJ9Z5hgjXX1ycZqAGhTn",
"network_id": 0,
"peer_disconnects": "542",
"peer_disconnects_resources": "1",
"peers": 24,
"pubkey_node": "n9LvjJyaYHBWUvQUat632RrnpS7UHVLW2tLUGXSZ2yXouh4goDHX",
"server_state": "full",
"server_state_duration_us": "627203282776",
"server_state_duration_us": "3612238603",
"state_accounting": {
"connected": {
"duration_us": "600242389",
"transitions": 40
"duration_us": "125498126",
"transitions": "67"
},
"disconnected": {
"duration_us": "112927",
"transitions": 1
"duration_us": "473415516",
"transitions": "2"
},
"full": {
"duration_us": "3591757226163",
"transitions": 46
"duration_us": "4365855930299",
"transitions": "337"
},
"syncing": {
"duration_us": "5304456",
"transitions": 7
"duration_us": "1383837914",
"transitions": "311"
},
"tracking": {
"duration_us": "13989631",
"transitions": 46
"duration_us": "518995710",
"transitions": "374"
}
},
"time": "2021-Aug-24 20:29:53.291350 UTC",
"uptime": 3592376,
"time": "2022-Nov-16 21:51:03.737667 UTC",
"uptime": 4368357,
"validated_ledger": {
"age": 2,
"age": 1,
"base_fee_xrp": 0.00001,
"hash": "B79D223A27F4EC214C9BA85665B12EE76C1EE2CB887BBCBAFB6484355C43FEFA",
"reserve_base_xrp": 20,
"reserve_inc_xrp": 5,
"seq": 65886965
"hash": "D54A94D5EF620DC212EAB5958D592EC641FC94ED92146477A04DCE5B006DFF05",
"reserve_base_xrp": 10,
"reserve_inc_xrp": 2,
"seq": 75801747
},
"validation_quorum": 33
"validation_quorum": 28
},
"status": "success"
}
@@ -190,55 +193,57 @@ Loading: "/etc/opt/ripple/rippled.cfg"
{
"result": {
"info": {
"build_version": "1.7.2",
"complete_ledgers": "64735538-65886965",
"hostid": "TOLL",
"build_version": "1.9.4",
"complete_ledgers": "32570-75801747",
"hostid": "ABET",
"initial_sync_duration_us": "566800928",
"io_latency_ms": 1,
"jq_trans_overflow": "3",
"jq_trans_overflow": "47035",
"last_close": {
"converge_time_s": 3,
"proposers": 41
"proposers": 35
},
"load_factor": 1,
"peer_disconnects": "467400",
"peer_disconnects_resources": "16316",
"peers": 85,
"pubkey_node": "n9Mdk7abYaVvded5zic9oDEY3NULv9RmeJ9Z5hgjXX1ycZqAGhTn",
"network_id": 0,
"peer_disconnects": "542",
"peer_disconnects_resources": "1",
"peers": 24,
"pubkey_node": "n9LvjJyaYHBWUvQUat632RrnpS7UHVLW2tLUGXSZ2yXouh4goDHX",
"server_state": "full",
"server_state_duration_us": "627203282776",
"server_state_duration_us": "3612238603",
"state_accounting": {
"connected": {
"duration_us": "600242389",
"transitions": 40
"duration_us": "125498126",
"transitions": "67"
},
"disconnected": {
"duration_us": "112927",
"transitions": 1
"duration_us": "473415516",
"transitions": "2"
},
"full": {
"duration_us": "3591757226163",
"transitions": 46
"duration_us": "4365855930299",
"transitions": "337"
},
"syncing": {
"duration_us": "5304456",
"transitions": 7
"duration_us": "1383837914",
"transitions": "311"
},
"tracking": {
"duration_us": "13989631",
"transitions": 46
"duration_us": "518995710",
"transitions": "374"
}
},
"time": "2021-Aug-24 20:29:53.291350 UTC",
"uptime": 3592376,
"time": "2022-Nov-16 21:51:03.737667 UTC",
"uptime": 4368357,
"validated_ledger": {
"age": 2,
"age": 1,
"base_fee_xrp": 0.00001,
"hash": "B79D223A27F4EC214C9BA85665B12EE76C1EE2CB887BBCBAFB6484355C43FEFA",
"reserve_base_xrp": 20,
"reserve_inc_xrp": 5,
"seq": 65886965
"hash": "D54A94D5EF620DC212EAB5958D592EC641FC94ED92146477A04DCE5B006DFF05",
"reserve_base_xrp": 10,
"reserve_inc_xrp": 2,
"seq": 75801747
},
"validation_quorum": 33
"validation_quorum": 28
},
"status": "success"
}
@@ -273,14 +278,18 @@ The `info` object may have some arrangement of the following fields:
| `load_factor_fee_escalation` | Number | _(May be omitted)_ The current multiplier to the [transaction cost][] that a transaction must pay to get into the open ledger. [New in: rippled 0.32.0][] |
| `load_factor_fee_queue` | Number | _(May be omitted)_ The current multiplier to the [transaction cost][] that a transaction must pay to get into the queue, if the queue is full. [New in: rippled 0.32.0][] |
| `load_factor_server` | Number | _(May be omitted)_ The load factor the server is enforcing, not including the [open ledger cost](transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] |
| `peers` | Number | How many other `rippled` servers this one is currently connected to. |
| `peers` | Number | _(Omitted by [reporting mode][Reporting mode] servers)_ How many other `rippled` servers this one is currently connected to. |
| `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This [_node key pair_](peer-protocol.html#node-key-pair) is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) You can set a persistent value in the config file using the `[node_seed]` config option, which is useful for [clustering](clustering.html). |
| `pubkey_validator` | String | _(Admin only)_ Public key used by this node to sign ledger validations. This _validation key pair_ is derived from the `[validator_token]` or `[validation_seed]` config field. |
| `reporting` | Object | _([Reporting mode](rippled-server-modes.html) servers only)_ Information about this server's reporting-mode specific configurations. |
| `reporting.etl_sources` | Array | _([Reporting mode](rippled-server-modes.html) servers only)_ A list of P2P-mode servers this reporting mode is retrieving data from. Each entry in this array is an [ETL Source object](#etl-source-object). |
| `reporting.is_writer` | Boolean | _([Reporting mode](rippled-server-modes.html) servers only)_ If `true`, this server is writing to the external database with ledger data. If `false`, it is not currently writing, possibly because another reporting mode server is currently populating a shared database, or because it's configured as read-only.|
| `reporting.last_publish_time` | String | _([Reporting mode](rippled-server-modes.html) servers only)_ An ISO 8601 timestamp indicating when this server last published a validated ledger to its [subscription streams](subscribe.html). |
| `server_state` | String | A string indicating to what extent the server is participating in the network. See [Possible Server States](rippled-server-states.html) for more details. |
| `server_state_duration_us` | Number | The number of consecutive microseconds the server has been in the current state. [New in: rippled 1.2.0][] |
| `state_accounting` | Object | A map of various [server states](rippled-server-states.html) with information about the time the server spends in each. This can be useful for tracking the long-term health of your server's connectivity to the network. [New in: rippled 0.30.1][] |
| `state_accounting.*.duration_us` | String | The number of microseconds the server has spent in this state. (This is updated whenever the server transitions into another state.) [New in: rippled 0.30.1][] |
| `state_accounting.*.transitions` | Number | The number of times the server has changed into this state. [New in: rippled 0.30.1][] |
| `state_accounting.*.transitions` | String | The number of times the server has changed into this state. [New in: rippled 0.30.1][] |
| `time` | String | The current time in UTC, according to the server's clock. [Updated in: rippled 1.5.0][] |
| `uptime` | Number | Number of consecutive seconds that the server has been operational. [New in: rippled 0.30.1][] |
| `validated_ledger` | Object | _(May be omitted)_ Information about the most recent fully-validated ledger. If the most recent validated ledger is not available, the response omits this field and includes `closed_ledger` instead. |
@@ -291,10 +300,12 @@ The `info` object may have some arrangement of the following fields:
| `validated_ledger.reserve_inc_xrp` | Number | Amount of XRP (not drops) added to the account reserve for each object an account owns in the ledger. |
| `validated_ledger.seq` | Number | The [ledger index][] of the latest validated ledger. |
| `validation_quorum` | Number | Minimum number of trusted validations required to validate a ledger version. Some circumstances may cause the server to require more validations. |
| `validator_list_expires` | String | _(Admin only)_ Either the human readable time, in UTC, when the current validator list will expire, the string `unknown` if the server has yet to load a published validator list or the string `never` if the server uses a static validator list. [Updated in: rippled 1.5.0][] |
| `validator_list_expires` | String | _(Admin only)_ Either the human readable time, in UTC, when the current validator list expires, the string `unknown` if the server has yet to load a published validator list or the string `never` if the server uses a static validator list. [Updated in: rippled 1.5.0][] |
**Note:** If the `closed_ledger` field is present and has a small `seq` value (less than 8 digits), that indicates `rippled` does not currently have a copy of the validated ledger from the peer-to-peer network. This could mean your server is still syncing. Typically, it takes about 5 minutes to sync with the network, depending on your connection speed and hardware specs.
{% include '_snippets/etl-source-object.md' %}
## Possible Errors
* Any of the [universal error types][].

14
content/references/http-websocket-apis/public-api-methods/server-info-methods/server_state.md
View File

@@ -286,14 +286,18 @@ The `state` object may have some arrangement of the following fields:
| `load_factor_fee_queue` | Number | _(May be omitted)_ The current multiplier to the [transaction cost][] to get into the queue, if the queue is full, in [fee levels][]. [New in: rippled 0.32.0][] |
| `load_factor_fee_reference` | Number | _(May be omitted)_ The [transaction cost][] with no load scaling, in [fee levels][]. [New in: rippled 0.32.0][] |
| `load_factor_server` | Number | _(May be omitted)_ The load factor the server is enforcing, not including the [open ledger cost](transaction-cost.html#open-ledger-cost). [New in: rippled 0.33.0][] |
| `peers` | Number | How many other `rippled` servers this one is currently connected to. |
| `peers` | Number | _(Omitted by [reporting mode][Reporting mode] servers)_ How many other `rippled` servers this one is currently connected to. |
| `pubkey_node` | String | Public key used to verify this server for peer-to-peer communications. This _node key pair_ is automatically generated by the server the first time it starts up. (If deleted, the server can create a new pair of keys.) You can set a persistent value in the config file using the `[node_seed]` config option, which is useful for [clustering](clustering.html). |
| `pubkey_validator` | String | _(Admin only)_ Public key used by this node to sign ledger validations. This _validation key pair_ is derived from the `[validator_token]` or `[validation_seed]` config field. |
| `reporting` | Object | _([Reporting mode][] servers only)_ Information about this server's reporting-mode specific configurations. |
| `reporting.etl_sources` | Array | _([Reporting mode][] servers only)_ A list of P2P-mode servers this reporting mode is retrieving data from. Each entry in this array is an [ETL Source object](#etl-source-object). |
| `reporting.is_writer` | Boolean | _([Reporting mode][] servers only)_ If `true`, this server is writing to the external database with ledger data. If `false`, it is not currently writing, possibly because another reporting mode server is currently populating a shared database, or because it's configured as read-only. |
| `reporting.last_publish_time` | String | _([Reporting mode][] servers only)_ An ISO 8601 timestamp indicating when this server last saw a new validated ledger from any of its P2P mode sources. |
| `server_state` | String | A string indicating to what extent the server is participating in the network. See [Possible Server States](rippled-server-states.html) for more details. |
| `server_state_duration_us` | Number | The number of consecutive microseconds the server has been in the current state. [New in: rippled 1.2.0][] |
| `state_accounting` | Object | A map of various [server states](rippled-server-states.html) with information about the time the server spends in each. This can be useful for tracking the long-term health of your server's connectivity to the network. [New in: rippled 0.30.1][] |
| `state_accounting.*.duration_us` | String | The number of microseconds the server has spent in this state. (This is updated whenever the server transitions into another state.) [New in: rippled 0.30.1][] |
| `state_accounting.*.transitions` | Number | The number of times the server has changed into this state. [New in: rippled 0.30.1][] |
| `state_accounting.*.transitions` | String | The number of times the server has changed into this state. [New in: rippled 0.30.1][] |
| `time` | String | The current time in UTC, according to the server's clock. [Updated in: rippled 1.5.0][] |
| `uptime` | Number | Number of consecutive seconds that the server has been operational. [New in: rippled 0.30.1][] |
| `validated_ledger` | Object | _(May be omitted)_ Information about the most recent fully-validated ledger. If the most recent validated ledger is not available, the response omits this field and includes `closed_ledger` instead. |
@@ -304,7 +308,11 @@ The `state` object may have some arrangement of the following fields:
| `validated_ledger.reserve_inc` | Number | The [owner reserve](reserves.html) for each item an account owns, as of the most recent validated ledger version. |
| `validated_ledger.seq` | Number | The [ledger index][] of the most recently validated ledger version. |
| `validation_quorum` | Number | Minimum number of trusted validations required to validate a ledger version. Some circumstances may cause the server to require more validations. |
| `validator_list_expires` | Number | _(Admin only)_ When the current validator list will expire, in [seconds since the Ripple Epoch][], or 0 if the server has yet to load a published validator list. [New in: rippled 0.80.1][] |
| `validator_list_expires` | Number | _(Admin only)_ When the current validator list expires, in [seconds since the Ripple Epoch][], or 0 if the server has yet to load a published validator list. [New in: rippled 0.80.1][] |
[Reporting mode]: rippled-server-modes.html
{% include '_snippets/etl-source-object.md' %}
## Possible Errors

10
content/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md
View File

@@ -79,14 +79,14 @@ The following parameters are deprecated and may be removed without further notic
The `streams` parameter provides access to the following default streams of information:
- `consensus` - Sends a message whenever the server changes phase in the consensus cycle (open, establish, accepted, and so forth)
- `ledger` - Sends a message whenever the consensus process declares a new validated ledger
- `consensus` - Sends a message whenever the server changes phase in the consensus cycle.
- `ledger` - Sends a message whenever the consensus process declares a new validated ledger.
- `manifests` - Sends a message whenever the server receives an update to a validator's ephemeral signing key.
- `peer_status` - **(Admin only)** Information about connected peer `rippled` servers, especially with regards to the consensus process.
- `transactions` - Sends a message whenever a transaction is included in a closed ledger
- `transactions` - Sends a message whenever a transaction is included in a closed ledger.
- `transactions_proposed` - Sends a message whenever a transaction is included in a closed ledger, as well as some transactions that have not yet been included in a validated ledger and may never be. Not all proposed transactions appear before validation.
**Note:** [Even some transactions that don't succeed are included](transaction-results.html) in validated ledgers, because they take the anti-spam transaction fee.
- `server` - Sends a message whenever the status of the `rippled` server (for example, network connectivity) changes
- `server` - Sends a message whenever the status of the `rippled` server (for example, network connectivity) changes.
- `validations` - Sends a message whenever the server receives a validation message, regardless of if the server trusts the validator. (An individual `rippled` declares a ledger validated when the server receives validation messages from at least a quorum of trusted validators.)
**Note:** The following streams are not available from servers in [Reporting Mode][]: `server`, `peer_status`, `consensus`. Reporting Mode servers return the error `reportingUnsupported` if you request one of these streams. [Updated in: rippled 1.8.1][]
@@ -569,7 +569,7 @@ The fields from a consensus stream message are as follows:
| `Field` | Type | Description |
|:--------------------|:--------------------------|:---------------------------|
| `type` | String | `consensusPhase` indicates this is from the consensus stream |
| `consensus` | String | The new consensus phase the server is in. Possible values are open, establish, and accepted. |
| `consensus` | String | The new consensus phase the server is in. Possible values are `open`, `establish`, and `accepted`. |
{% include '_snippets/rippled_versions.md' %}

22
content/references/http-websocket-apis/public-api-methods/subscription-methods/unsubscribe.md
View File

@@ -48,22 +48,22 @@ An example of the request format:
The parameters in the request are specified almost exactly like the parameters to the [subscribe method][], except that they are used to define which subscriptions to end instead. The parameters are:
| `Field` | Type | Description |
|:--------------------|:------|:-----------------------------------------------|
| `streams` | Array | _(Optional)_ Array of string names of generic streams to unsubscribe from, including `ledger`, `server`, `transactions`, and `transactions_proposed`. |
| `accounts` | Array | _(Optional)_ Array of unique account addresses to stop receiving updates for, in the XRP Ledger's [base58][] format. (This only stops those messages if you previously subscribed to those accounts specifically. You cannot use this to filter accounts out of the general transactions stream.) |
| `accounts_proposed` | Array | _(Optional)_ Like `accounts`, but for `accounts_proposed` subscriptions that included not-yet-validated transactions. |
| `books` | Array | _(Optional)_ Array of objects defining order books to unsubscribe from, as explained below. |
| `Field` | Type | Required? | Description |
|:--------------------|:------|:----------|:-----------------------------------------------|
| `streams` | Array | No | Array of string names of generic streams to unsubscribe from, including `ledger`, `server`, `transactions`, and `transactions_proposed`. |
| `accounts` | Array | No | Array of unique account addresses to stop receiving updates for, in the XRP Ledger's [base58][] format. (This only stops those messages if you previously subscribed to those accounts specifically. You cannot use this to filter accounts out of the general transactions stream.) |
| `accounts_proposed` | Array | No | Like `accounts`, but for `accounts_proposed` subscriptions that included not-yet-validated transactions. |
| `books` | Array | No | Array of objects defining order books to unsubscribe from, as explained below. |
The `rt_accounts` and `url` parameters, and the `rt_transactions` stream name, are deprecated and may be removed without further notice.
The objects in the `books` array are defined almost like the ones from subscribe, except that they don't have all the fields. The fields they have are as follows:
| `Field` | Type | Description |
|:-------------|:--------|:----------------------------------------------------|
| `taker_gets` | Object | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts][Currency Amount]. |
| `taker_pays` | Object | Specification of which currency the account taking the offer would pay, as an object with `currency` and `issuer` fields (omit issuer for XRP), like [currency amounts][Currency Amount]. |
| `both` | Boolean | (Optional, defaults to false) If true, remove a subscription for both sides of the order book. |
| `Field` | Type | Required? | Description |
|:-------------|:--------|:----------|:----------------------------------------------------|
| `taker_gets` | Object | No | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields. Omit `issuer` for XRP. |
| `taker_pays` | Object | No | Specification of which currency the account taking the offer would receive, as an object with `currency` and `issuer` fields. Omit `issuer` for XRP. |
| `both` | Boolean | No | If `true`, remove a subscription for both sides of the order book. |
## Response Format

10
content/references/http-websocket-apis/public-api-methods/transaction-methods/submit.md
View File

@@ -22,10 +22,10 @@ To send a transaction as robustly as possible, you should construct and [sign][s
A submit-only request includes the following parameters:
| `Field` | Type | Description |
|:------------|:--------|:-----------------------------------------------------|
| `tx_blob` | String | Hex representation of the signed transaction to submit. This can be a [multi-signed transaction](multi-signing.html). |
| `fail_hard` | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
| `Field` | Type | Required? | Description |
|:------------|:--------|:----------|:-----------------------------------------------------|
| `tx_blob` | String | Yes | Hex representation of the signed transaction to submit. This can be a [multi-signed transaction](multi-signing.html). |
| `fail_hard` | Boolean | No | If `true`, and the transaction fails locally, do not retry or relay the transaction to other servers. The default is `false`. |
### Request Format
@@ -88,7 +88,7 @@ The request includes the following parameters:
| `passphrase` | String | _(Optional)_ Secret key of the account supplying the transaction, used to sign it, as a string passphrase. If provided, you must also specify the `key_type`. Cannot be used with `secret`, `seed`, or `seed_hex`. |
| `key_type` | String | _(Optional)_ Type of cryptographic key provided in this request. Valid types are `secp256k1` or `ed25519`. Defaults to `secp256k1`. Cannot be used with `secret`. **Caution:** Ed25519 support is experimental. |
| `fail_hard` | Boolean | _(Optional)_ If `true`, and the transaction fails locally, do not retry or relay the transaction to other servers. The default is `false`. [Updated in: rippled 1.5.0][] |
| `offline` | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not try to automatically fill in or validate values. |
| `offline` | Boolean | _(Optional)_ If `true`, when constructing the transaction, do not try to automatically fill in or validate values. The default is `false`. |
| `build_path` | Boolean | _(Optional)_ If this field is provided, the server [auto-fills](transaction-common-fields.html#auto-fillable-fields) the `Paths` field of a [Payment transaction][] before signing. You must omit this field if the transaction is a [direct XRP payment](direct-xrp-payments.html) or if it is not a Payment-type transaction. **Caution:** The server looks for the presence or absence of this field, not its value. This behavior may change. ([Issue #3272](https://github.com/ripple/rippled/issues/3272)) |
| `fee_mult_max` | Integer | _(Optional)_ Sign-and-submit fails with the error `rpcHIGH_FEE` if the [auto-filled `Fee` value](transaction-common-fields.html#auto-fillable-fields) would be greater than the [reference transaction cost](transaction-cost.html#special-transaction-costs) × `fee_mult_max` ÷ `fee_div_max`. This field has no effect if you explicitly specify the `Fee` field of the transaction. The default is `10`. |
| `fee_div_max` | Integer | _(Optional)_ Sign-and-submit fails with the error `rpcHIGH_FEE` if the [auto-filled `Fee` value](transaction-common-fields.html#auto-fillable-fields) would be greater than the [reference transaction cost](transaction-cost.html#special-transaction-costs) × `fee_mult_max` ÷ `fee_div_max`. This field has no effect if you explicitly specify the `Fee` field of the transaction. The default is `1`. [New in: rippled 0.30.1][] |

55
content/references/http-websocket-apis/public-api-methods/transaction-methods/submit_multisigned.md
View File

@@ -135,10 +135,10 @@ rippled submit_multisigned '{
The request includes the following parameters:
| `Field` | Type | Description |
|:------------|:--------|:-----------------------------------------------------|
| `tx_json` | Object | [Transaction in JSON format](transaction-formats.html) with an array of `Signers`. To be successful, the weights of the signatures must be equal or higher than the quorum of the [SignerList](signerlist.html). |
| `fail_hard` | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers. |
| `Field` | Type | Required? | Description |
|:------------|:--------|:----------|:-----------------------------------------------------|
| `tx_json` | Object | Yes | [Transaction in JSON format](transaction-formats.html) with an array of `Signers`. To be successful, the weights of the signatures must be equal or higher than the quorum of the [SignerList](signerlist.html). |
| `fail_hard` | Boolean | No | If `true`, and the transaction fails locally, do not retry or relay the transaction to other servers. The default is `false`. |
## Response Format
@@ -238,6 +238,53 @@ An example of a successful response:
}
```
*Commandline*
```
Loading: "/etc/rippled.cfg"
Connecting to 127.0.0.1:5005
{
"result": {
"engine_result": "tesSUCCESS",
"engine_result_code": 0,
"engine_result_message": "The transaction was applied. Only final in a validated ledger.",
"status": "success",
"tx_blob": "120014220004000024000000046380000000000000000000000000000000000000005553440000000000B5F762798A53D543A014CAF8B297CFF8F2F937E868400000000000753073008114A3780F5CB5A44D366520FC44055E8ED44D9A2270F3E010732102B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF74473045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B78114204288D2E47F8EF6C99BCC457966320D12409711E1E010732103398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C174473045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D0881143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
"tx_json": {
"Account": "rEuLyBCvcw4CFmzv8RepSiAoNgF8tTGJQC",
"Fee": "30000",
"Flags": 262144,
"LimitAmount": {
"currency": "USD",
"issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
"value": "0"
},
"Sequence": 4,
"Signers": [
{
"Signer": {
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
"SigningPubKey": "02B3EC4E5DD96029A647CFA20DA07FE1F85296505552CCAC114087E66B46BD77DF",
"TxnSignature": "3045022100CC9C56DF51251CB04BB047E5F3B5EF01A0F4A8A549D7A20A7402BF54BA744064022061EF8EF1BCCBF144F480B32508B1D10FD4271831D5303F920DE41C64671CB5B7"
}
},
{
"Signer": {
"Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
"SigningPubKey": "03398A4EDAE8EE009A5879113EAA5BA15C7BB0F612A87F4103E793AC919BD1E3C1",
"TxnSignature": "3045022100FEE8D8FA2D06CE49E9124567DCA265A21A9F5465F4A9279F075E4CE27E4430DE022042D5305777DA1A7801446780308897699412E4EDF0E1AEFDF3C8A0532BDE4D08"
}
}
],
"SigningPubKey": "",
"TransactionType": "TrustSet",
"hash": "81A477E2A362D171BB16BE17B4120D9F809A327FA00242ABCA867283BEA2F4F8"
}
}
}
```
<!-- MULTICODE_BLOCK_END -->
The response follows the [standard format][], with a successful result containing the following fields:

2
content/references/http-websocket-apis/public-api-methods/transaction-methods/tx.md
View File

@@ -459,7 +459,7 @@ If the server does not find the transaction, it returns a `txnNotFound` error, w
- The transaction has not been included in any ledger version, and has not been executed.
- The transaction was included in a ledger version that the server does not have available.
This means that a `txnNotFound` on its own is not sufficient to know the [final outcome of a transaction](finality-of-results.html).
This means that a `txnNotFound` on its own is not enough to know the [final outcome of a transaction](finality-of-results.html).
To further narrow down the possibilities, you can provide a range of ledgers to search using the `min_ledger` and `max_ledger` fields in the request. If you provide **both** of those fields, the `txnNotFound` response includes the following field:

2
content/references/protocol-reference/data-types/currency-formats.md
View File

@@ -117,4 +117,4 @@ At the protocol level, this format is [serialized](serialization.html#currency-c
You can also use a 160-bit (40-character) hexadecimal string such as `015841551A748AD2C1F76FF6ECB0CCCD00000000` as the currency code. To prevent this from being treated as a "standard" currency code, the first 8 bits MUST NOT be `0x00`.
**Deprecated:** Some previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) supported an "interest-bearing" or "demurraging" currency code type. These codes have the first 8 bits `0x01`. Demurraging / interest-bearing currencies are no longer supported, but you may encounter them in ledger data. For more information, see [Demurrage](demurrage.html).
**Deprecated:** Some previous versions of [ripple-lib](https://github.com/XRPLF/xrpl.js) supported an "interest-bearing" or "demurraging" currency code type. These codes have the first 8 bits `0x01`. Demurraging / interest-bearing currencies are no longer supported, but you may find them in ledger data. For more information, see [Demurrage](demurrage.html).

25
content/references/protocol-reference/data-types/nftoken.md
View File

@@ -21,10 +21,11 @@ Example {{currentpage.name}} JSON
```
Unlike other objects, `NFToken` has no field to identify the object type or current owner of the object. `NFToken `objects are grouped into `NFTokenPages` that implicitly define the object type and identify the owner.
Unlike full-fledged [ledger entries](ledger-object-types.html), `NFToken` has no field to identify the object type or current owner of the object. `NFToken` objects are grouped into pages that implicitly define the object type and identify the owner.
## NFTokenID
<!-- SPELLING_IGNORE: nftokenid -->
`NFTokenID`, optional, string, Hash256
@@ -33,7 +34,7 @@ This composite field uniquely identifies a token, and consists of the following
1. 16 bits that identify flags or settings specific to the NFToken
2. 16 bits that encode the transfer fee associated with this NFToken, if any
3. A 160-bit account identifier of the issuer
4. A 32-bit issuer-specified [NFTokenTaxon](https://www.merriam-webster.com/dictionary/taxon)
4. A 32-bit issuer-specified [`NFTokenTaxon`](https://www.merriam-webster.com/dictionary/taxon)
5. An (automatically generated) monotonically increasing 32-bit sequence number.
@@ -61,12 +62,13 @@ Flags are properties or other options associated with the `NFToken` object.
### Example
The example sets three flags: `lsfBurnable` (`0x0001`), `lsfOnlyXRP` (`0x0002`), `lsfTransferable` (`0x0008`). 1+2+8 = 11, or 0x000B in big endian format.
The example sets three flags: `lsfBurnable` (`0x0001`), `lsfOnlyXRP` (`0x0002`), `lsfTransferable` (`0x0008`). 1+2+8 = 11, or `0x000B` in big endian format.
![Flags](img/nftokena.png "Flags")
### TransferFee
<!-- SPELLING_IGNORE: transferfee -->
The `TransferFee` value specifies the percentage fee, in units of 1/100,000, charged by the issuer for secondary sales of the token. Valid values for this field are between 0 and 50,000, inclusive. A value of 1 is equivalent to 0.001% or 1/10 of a basis point (bps), allowing transfer rates between 0% and 50%.
@@ -88,12 +90,13 @@ The third section of the `NFTokenID` is a big endian representation of the issue
### NFTokenTaxon
<!-- SPELLING_IGNORE: nftokentaxon -->
The fourth section is a `NFTokenTaxon` created by the issuer.
![NFTokenTaxon](img/nftokend.png "NFTokenTaxon")
![Diagram of `NFTokenTaxon` bits](img/nftokend.png)
An issuer might issue several `NFToken` objects with the same `NFTokenTaxon`; to ensure that `NFToken` objects are spread across multiple pages, the `NFTokenTaxon` is scrambled using the fifth section, a sequential number, as the seed for a random number generator. The scrambled value is stored with the `NFToken`, but the unscrambled value is the actual NFTokenTaxon.
An issuer might issue several `NFToken` objects with the same `NFTokenTaxon`; to ensure that `NFToken` objects are spread across multiple pages, the `NFTokenTaxon` is scrambled using the fifth section, a sequential number, as the seed for a random number generator. The scrambled value is stored with the `NFToken`, but the unscrambled value is the actual `NFTokenTaxon`.
![Dumb Sequential](img/nftokene.png "Dumb Sequential")
@@ -106,20 +109,20 @@ The fifth section is a sequence number that increases with each `NFToken` the is
## URI
The URI field points to the data and/or metadata associated with the `NFToken`. This field need not be an HTTP or HTTPS URL; it could be an IPFS URI, a magnet link, immediate data encoded as an RFC2379 ["data" URL](https://datatracker.ietf.org/doc/html/rfc2397), or even an opaque issuer-specific encoding. The URI is not checked for validity, but the field is limited to a maximum length of 256 bytes.
The URI field points to the data or metadata associated with the `NFToken`. This field does not need to be an HTTP or HTTPS URL; it could be an IPFS URI, a magnet link, an [RFC 2379 "data" URL](https://datatracker.ietf.org/doc/html/rfc2397), or even a totally custom encoding. The URI is not checked for validity, but the field is limited to a maximum length of 256 bytes.
One drawback of using this method is that the value is immutable, so it commits the issuer to hosting the data in perpetuity.
**Caution:** The URI is immutable, so no one can update it if, for example, it links to a website that no longer exists.
# Retrieving `NFToken` Data and Metadata
# Retrieving NFToken Data and Metadata
To minimize the footprint of `NFTokens` without sacrificing functionality or imposing unnecessary restrictions, XRPL NFTs do not have arbitrary data fields. Instead, data is maintained separately and referenced by the `NFToken`. The URI provides a reference to immutable content for the `Hash` and any mutable data for the `NFToken` object.
The `URI` field is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, a `minter` that stores `NFToken` data or metadata using the Inter Planetary File System (IPFS) can use the `URI` field to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see [Best Practices for Storing NFT Data using IPFS](https://docs.ipfs.io/how-to/best-practices-for-nft-data/#types-of-ipfs-links-and-when-to-use-them),
The `URI` field is especially useful for referring to non-traditional Peer-to-Peer (P2P) URLs. For example, a minter that stores `NFToken` data or metadata using the Inter Planetary File System (IPFS) can use the `URI` field to refer to data on IPFS in different ways, each of which is suited to different use-cases. For more context on types of IPFS links that can be used to store NFT data, see [Best Practices for Storing NFT Data using IPFS](https://docs.ipfs.io/how-to/best-practices-for-nft-data/#types-of-ipfs-links-and-when-to-use-them),
An alternative to the URI approach is for issuers of `NFToken` objects to set the `Domain` field of their issuing account to the correct domain, and offer an API for clients that want to lookup the data or metadata associated with a particular `NFToken`. Note that using this mechanism _requires_ the `minter` to acquire a domain name and set the domain name for their minting account, but does not require the `minter` to necessarily operate a server nor other service to provide the ability to query this data; instead, a `minter` can "redirect" queries to a data provider (for example, to a marketplace, registry or other service).
An alternative to the URI approach is for issuers of `NFToken` objects to set the `Domain` field of their issuing account to the correct domain, and offer an API for clients that want to lookup the data or metadata associated with a particular `NFToken`. Note that using this mechanism _requires_ the minter to acquire a domain name and set the domain name for their minting account, but does not require the minter to necessarily run a server nor other service to provide the ability to query this data; instead, a minter can "redirect" queries to a data provider (for example, to a marketplace, registry or other service).
Your implementation should first attempt to check for the presence of the `URI` field to retrieve the associated data and/or metadata. If the `URI` field does not exist, the implementation should check for the presence of `Domain` field. If neither field exists, nothing happens. Implementations must be prepared to handle HTTP redirections (for example, using HTTP responses 301, 302, 307 and 308) from the URI.
Your implementation should first attempt to check for the presence of the `URI` field to retrieve the associated data or metadata. If the `URI` field does not exist, the implementation should check for the presence of `Domain` field. If neither field exists, nothing happens. Implementations must be prepared to handle HTTP redirections (for example, using HTTP responses 301, 302, 307 and 308) from the URI.
## TXT Record Format

16
content/references/protocol-reference/ledger-data/ledger-object-types/accountroot.ja.md
View File

@@ -56,6 +56,22 @@ labels:
| `WalletLocator` | 文字列 | Hash256 | _（省略可）_ **廃止予定**。使用しないでください。 |
| `WalletSize` | 数値 | UInt32 | _（省略可）_ **廃止予定**。使用しないでください。 |
## Special AMM AccountRoot Objects
<!-- TODO: translate this section -->
{% include '_snippets/amm-disclaimer.md' %}
[Automated Market Makers](automated-market-makers.html) (AMMs) use an AccountRoot object to issue their LP Tokens and hold the assets in the AMM pool, in addition to the [AMM object][] for tracking some of the details of the AMM. The address of an AMM's associated AccountRoot is randomized so that users cannot identify and fund the address in advance of the AMM being created. Unlike normal accounts, AMM AccountRoots are created with the following settings:
- `lsfAMM` **enabled**. This indicates that the AccountRoot is part of an AMM and is not a regular account.
- `lsfDisableMaster` **enabled** and no other means of authorizing transactions. This ensures no one can control the account directly, and it cannot send transactions.
- `lsfRequireAuth` **enabled** and no accounts preauthorized. This ensures that the only way to add money to the AMM Account is using the [AMMDeposit transaction][].
- `lsfDefaultRipple` **enabled**. This ensures that users can send and trade the AMM's LP Tokens among themselves.
These special accounts are not subject to the [reserve requirement](reserves.html) but they can hold XRP if it is one of the two assets in the AMM's pool.
In most other ways, these accounts function like ordinary accounts; the LP Tokens they issue behave like other [tokens](tokens.html) except that those tokens can also be used in AMM-related transactions. You can check an AMM's balances and the history of transactions that affected it the same way you would with a regular account.
## AccountRootのフラグ
このアカウントに対して有効化または無効化できる各種オプションがあります。これらのオプションを変更するには、[AccountSetトランザクション][]を使用します。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 _lsf_ で始まる名前が付いています。

25
content/references/protocol-reference/ledger-data/ledger-object-types/accountroot.md
View File

@@ -48,7 +48,7 @@ The `AccountRoot` object has the following fields:
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0061`, mapped to the string `AccountRoot`, indicates that this is an AccountRoot object. |
| `MessageKey` | String | Blob | No | A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. Must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. |
| `MintedNFTokens` | Number | UInt32 | No | How many total [non-fungible tokens](non-fungible-tokens.html) have been minted by and on behalf of this account. |
| `NFTokenMinter` | String | AccountID | No | Another account that is authorized to mint [non-fungible tokens](non-fungible-tokens.html) on behalf of this account. |
| `NFTokenMinter` | String | AccountID | No | Another account that can mint [non-fungible tokens](non-fungible-tokens.html) on behalf of this account. |
| `OwnerCount` | Number | UInt32 | Yes | The number of objects this account owns in the ledger, which contributes to its owner reserve. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes |The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
@@ -57,8 +57,9 @@ The `AccountRoot` object has the following fields:
| `TicketCount` | Number | UInt32 | No | How many [Tickets](tickets.html) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. _(Added by the [TicketBatch amendment][].)_ |
| `TickSize` | Number | UInt8 | No | How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Added by the [TickSize amendment][].)_ |
| `TransferRate` | Number | UInt32 | No | A [transfer fee](transfer-fees.html) to charge other users for sending currency issued by this account to each other. |
| `WalletLocator` | String | Hash256 | No | **DEPRECATED**. Do not use. |
| `WalletSize` | Number | UInt32 | No | **DEPRECATED**. Do not use. |
| `WalletLocator` | String | Hash256 | No | An arbitrary 256-bit value that users can set. |
| `WalletSize` | Number | UInt32 | No | Unused. (The code supports this field but there is no way to set it.) |
## AccountRoot Flags
@@ -68,6 +69,7 @@ AccountRoot objects can have the following flag values:
| Flag Name | Hex Value | Decimal Value | Corresponding [AccountSet Flag](accountset.html#accountset-flags) | Description |
|---------------------|--------------|---------------|--------------------|----|
| `lsfAMM` :not_enabled: | `0x02000000` | 33554432 | (None) | This account is an Automated Market Maker instance. :not_enabled: |
| `lsfDefaultRipple` | `0x00800000` | 8388608 | `asfDefaultRipple` | Enable [rippling](rippling.html) on this addresses's trust lines by default. Required for issuing addresses; discouraged for others. |
| `lsfDepositAuth` | `0x01000000` | 16777216 | `asfDepositAuth` | This account can only receive funds from transactions it sends, and from [preauthorized](depositauth.html#preauthorization) accounts. (It has [DepositAuth](depositauth.html) enabled.) |
| `lsfDisableMaster` | `0x00100000` | 1048576 | `asfDisableMaster` | Disallows use of the master key to sign transactions for this account. |
@@ -78,6 +80,23 @@ AccountRoot objects can have the following flag values:
| `lsfRequireAuth` | `0x00040000` | 262144 | `asfRequireAuth` | This account must individually approve other users for those users to hold this account's tokens. |
| `lsfRequireDestTag` | `0x00020000` | 131072 | `asfRequireDest` | Requires incoming payments to specify a Destination Tag. |
## Special AMM AccountRoot Objects
{% include '_snippets/amm-disclaimer.md' %}
[Automated Market Makers](automated-market-makers.html) (AMMs) use an AccountRoot object to issue their LP Tokens and hold the assets in the AMM pool, and an [AMM object][] for tracking some of the details of the AMM. The address of an AMM's AccountRoot is randomized so that users cannot identify and fund the address in advance of the AMM being created. Unlike normal accounts, AMM AccountRoot objects are created with the following settings:
- `lsfAMM` **enabled**. This indicates that the AccountRoot is part of an AMM and is not a regular account.
- `lsfDisableMaster` **enabled** and no other means of authorizing transactions. This ensures no one can control the account directly, and it cannot send transactions.
- `lsfRequireAuth` **enabled** and no accounts preauthorized. This ensures that the only way to add money to the AMM Account is using the [AMMDeposit transaction][].
- `lsfDefaultRipple` **enabled**. This ensures that users can send and trade the AMM's LP Tokens among themselves.
These special accounts are not subject to the [reserve requirement](reserves.html) but they can hold XRP if it is one of the two assets in the AMM's pool.
In most other ways, these accounts function like ordinary accounts; the LP Tokens they issue behave like other [tokens](tokens.html) except that those tokens can also be used in AMM-related transactions. You can check an AMM's balances and the history of transactions that affected it the same way you would with a regular account.
## AccountRoot ID Format
The ID of an AccountRoot object is the [SHA-512Half][] of the following values, concatenated in order:

Some files were not shown because too many files have changed in this diff Show More