mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 20:05:50 +00:00
Compare commits
23 Commits
mainnet-mp
...
kennyzlei/
| Author | SHA1 | Date | |
|---|---|---|---|
|
b71200a7dd | ||
|
|
31ff09c093 | ||
|
|
4319594cf1 | ||
|
|
7d9b9f7c17 | ||
|
|
0d73d6d851 | ||
|
|
e7cb03a88d | ||
|
|
18985ad7e5 | ||
|
|
09708e58de | ||
|
|
6e6247952f | ||
|
|
d7ca624269 | ||
|
|
d07d6dae6d | ||
|
|
bc0c698692 | ||
|
|
878f1ba77c | ||
|
|
c83fc47941 | ||
|
|
588da44a2e | ||
|
|
f511a23ea2 | ||
|
|
20225b5f62 | ||
|
|
10c974249f | ||
|
|
5d45562fc6 | ||
|
|
4481320636 | ||
|
|
b1c8a33de9 | ||
|
|
755b15383b | ||
|
|
b2aa96e283 |
@@ -17,8 +17,6 @@ Para ayudar a miembros de la comunidad del XRP Ledger a interactuar con la tecno
|
||||
| Mainnet | Lanzamientos estables | _El_ [XRP Ledger](/about/), un libro contable criptográfico descentralizado impulsado por una red de servidores peer-to-peer y el hogar de [XRP](../../introduction/what-is-xrp.md). |
|
||||
| Testnet | Lanzamientos estables | Una red de "universo alternativo" que actua como un campo de pruebas para el software construido en el XRP Ledger, sin impactar a los usuarios del XRP Ledger de producción y sin arriesgar dinero real. El [estado de enmienda](/resources/known-amendments.md) de Testnet está destinado a reflejar de cerca el de la Mainnet, aunque pueden ocurrir ligeras variaciones en el tiempo debido a la naturaleza impredecible de los sistemas descentralizados. |
|
||||
| Devnet | Lanzamientos Beta | Una vista previa de las próximas atracciones, donde cambios inestables en el software principal de XRP Ledger se pueden probar. Los desarrolladores pueden utilizar esta altnet para interactuar y aprender sobre funcionalidades nuevas planficiadas para el XRP Ledger y enmiendas que no están habilitadas en la Mainnet. |
|
||||
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Servidor Hooks](https://github.com/XRPL-Labs/xrpld-hooks) | Una vista previa de la funcionalidad de smart contract en la cadena utilizando [hooks](https://xrpl-hooks.readme.io/). |
|
||||
| Sidechain-Devnet | Lanzamientos Beta | Una sidechain para probar funcionalidades en puentes cross-chain. Devnet se trata como la cadena de bloqueo y esta sidechain es la cadena de emisión.<br>Soporte a la librería:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**Nota**: También puedes usar la herramienta de línea de comandos [`xbridge-cli`](https://github.com/XRPLF/xbridge-cli) para configurar un puente entre cadenas en tu máquina local. |
|
||||
|
||||
Cada altnet tiene su propia distribución separada de XRP de prueba, que se [regala gratis](/resources/dev-tools/xrp-faucets) a partes interesadas en experimentar con el XRP Ledger y desarrollar aplicaciones e integraciones. El XRP test no tiene valor en el mundo real y se pierde cuando la red se reinicia.
|
||||
|
||||
|
||||
@@ -17,8 +17,6 @@ XRP Ledgerコミュニティのメンバーが、メインネットに影響を
|
||||
| Mainnet | 安定版リリース | ピアツーピアサーバのネットワーク機能を備えた分散型の暗号台帳であり、[XRP](../../introduction/what-is-xrp.md)の土台となる[XRP Ledger](/about/)です。 |
|
||||
| Testnet | 安定版リリース | XRP Ledger上に構築したソフトウェアのテスト環境として動作する「代替環境」のネットワークです。本番環境のXRP Ledgerユーザに影響を及ぼすことも、本物の通貨をリスクにさらすこともありません。Testnetの[Amendmentのステータス](/resources/known-amendments.md)は、Mainnetを厳密に反映するようになっていますが、分散型システムが持つ予測不可能な性質により、タイミングにわずかな違いが生じることがあります。 |
|
||||
| Devnet | ベータ版リリース | 次期リリースのプレビューネットワークです。XRP Ledgerのコアソフトウェアへの不安定な変更がテストされます。このAltNetを使用すると、開発者はまだMainnetで有効になっていないXRPLの計画段階の新機能やAmendmentを操作したり学習したりすることができます。 |
|
||||
| [Hooks V3 Testnet](https://hooks-testnet-v3.xrpl-labs.com/) | [Hooksサーバ](https://github.com/XRPL-Labs/xrpld-hooks) | [Hooks](https://xrpl-hooks.readme.io/)を使用したオンチェーン・スマートコントラクト機能のプレビューネットワークです。 |
|
||||
| Sidechain-Devnet | ベータ版リリース | クロスチェーンブリッジ機能をテストするためのサイドチェーンです。<br>ライブラリのサポート:<br>- [xrpl.js 2.12.0](https://www.npmjs.com/package/xrpl/v/2.12.0)<br>- [xrpl-py 2.4.0](https://pypi.org/project/xrpl-py/2.4.0/)<br>**注記**: また、[`xbridge-cli`](https://github.com/XRPLF/xbridge-cli)コマンドラインツールを使用して、ローカルマシンにクロスチェーンブリッジをセットアップすることもできます。 |
|
||||
|
||||
テスト用XRPは、XRP Ledgerの実験やアプリケーションの開発、統合に興味のある人々に[無償で提供](/resources/dev-tools/xrp-faucets)されています。テスト用のXRPは実際には価値を持たず、ネットワークがリセットされると失われます。
|
||||
|
||||
|
||||
@@ -43,11 +43,6 @@ labels:
|
||||
# No [ips] stanza. Use the default hubs to connect to Mainnet.
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[ips]
|
||||
sidechain-net2.devnet.rippletest.net 51235
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
2. 以前の `[ips]`があれば、コメントアウトしてください。
|
||||
@@ -78,11 +73,6 @@ labels:
|
||||
main
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[network_id]
|
||||
262
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
カスタムネットワークの場合、そのネットワークに接続する全員が、そのネットワークに固有の値を使用する必要があります。新しいネットワークを作成するときは、ネットワークIDを11から4,294,967,295までの整数からランダムに選択します。
|
||||
@@ -121,14 +111,6 @@ labels:
|
||||
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[validator_list_sites]
|
||||
https://vlsidechain-net2.devnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
{% admonition type="success" name="ヒント" %}プレビュー版パッケージには必要な項目があらかじめ設定されている場合がありますが、念のため確認してください。{% /admonition %}
|
||||
@@ -182,13 +164,6 @@ labels:
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Sidechain-Devnet" %}
|
||||
```
|
||||
[features]
|
||||
XChainBridge
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
{% admonition type="danger" name="警告" %}メインネットまたはテストネットに接続するときは、`[features]`を使用しないでください。他のネットワークと異なる機能を強制的に有効にすると、サーバがネットワークから分断される可能性があります。{% /admonition %}
|
||||
|
||||
@@ -26,7 +26,6 @@ labels:
|
||||
| Ripple[¹][] | Testnet (Clio) | `https://clio.altnet.rippletest.net:51234/` | `wss://clio.altnet.rippletest.net:51233/` | Clioを使用したTestnet公開サーバ |
|
||||
| Ripple[¹][] | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net:51233/` | Devnet 公開サーバ |
|
||||
| Ripple[¹][] | Devnet (Clio) | `https://clio.devnet.rippletest.net:51234/` | `wss://clio.devnet.rippletest.net:51233/` | Clioを使用したDevnet公開サーバ |
|
||||
| Ripple[¹][] | Sidechain-Devnet | `https://sidechain-net2.devnet.rippletest.net:51234/` | `wss://sidechain-net2.devnet.rippletest.net:51233/` | クロスチェーンブリッジ機能をテストするためのサイドチェーンDevnet。Devnetはロックチェーンとして機能し、このサイドチェーンは発行チェーンとして機能します。 |
|
||||
| XRPL Labs | Xahau Testnet | `https://xahau-test.net/` | `wss://xahau-test.net/` | [Hooksが有効](https://hooks.xrpl.org/)なXahau Testnet |
|
||||
|
||||
[ネットワーク]: ../concepts/networks-and-servers/parallel-networks.md
|
||||
|
||||
@@ -10,26 +10,26 @@ const { wallet } = await client.fundWallet()
|
||||
|
||||
// Define metadata as JSON
|
||||
const mpt_metadata = {
|
||||
ticker: 'TBILL',
|
||||
name: 'T-Bill Yield Token',
|
||||
desc: 'A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.',
|
||||
icon: 'https://example.org/tbill-icon.png',
|
||||
asset_class: 'rwa',
|
||||
asset_subclass: 'treasury',
|
||||
issuer_name: 'Example Yield Co.',
|
||||
urls: [
|
||||
t: 'TBILL',
|
||||
n: 'T-Bill Yield Token',
|
||||
d: 'A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.',
|
||||
i: 'https://example.org/tbill-icon.png',
|
||||
ac: 'rwa',
|
||||
as: 'treasury',
|
||||
in: 'Example Yield Co.',
|
||||
us: [
|
||||
{
|
||||
url: 'https://exampleyield.co/tbill',
|
||||
type: 'website',
|
||||
title: 'Product Page'
|
||||
u: 'https://exampleyield.co/tbill',
|
||||
c: 'website',
|
||||
t: 'Product Page'
|
||||
},
|
||||
{
|
||||
url: 'https://exampleyield.co/docs',
|
||||
type: 'docs',
|
||||
title: 'Yield Token Docs'
|
||||
u: 'https://exampleyield.co/docs',
|
||||
c: 'docs',
|
||||
t: 'Yield Token Docs'
|
||||
}
|
||||
],
|
||||
additional_info: {
|
||||
ai: {
|
||||
interest_rate: '5.00%',
|
||||
interest_type: 'variable',
|
||||
yield_source: 'U.S. Treasury Bills',
|
||||
|
||||
@@ -12,26 +12,26 @@ wallet = generate_faucet_wallet(client, debug=True)
|
||||
|
||||
# Define metadata as JSON
|
||||
mpt_metadata = {
|
||||
"ticker": "TBILL",
|
||||
"name": "T-Bill Yield Token",
|
||||
"desc": "A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.",
|
||||
"icon": "https://example.org/tbill-icon.png",
|
||||
"asset_class": "rwa",
|
||||
"asset_subclass": "treasury",
|
||||
"issuer_name": "Example Yield Co.",
|
||||
"urls": [
|
||||
"t": "TBILL",
|
||||
"n": "T-Bill Yield Token",
|
||||
"d": "A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.",
|
||||
"i": "example.org/tbill-icon.png",
|
||||
"ac": "rwa",
|
||||
"as": "treasury",
|
||||
"in": "Example Yield Co.",
|
||||
"us": [
|
||||
{
|
||||
"url": "https://exampleyield.co/tbill",
|
||||
"type": "website",
|
||||
"title": "Product Page"
|
||||
"u": "exampleyield.co/tbill",
|
||||
"c": "website",
|
||||
"t": "Product Page"
|
||||
},
|
||||
{
|
||||
"url": "https://exampleyield.co/docs",
|
||||
"type": "docs",
|
||||
"title": "Yield Token Docs"
|
||||
"u": "exampleyield.co/docs",
|
||||
"c": "docs",
|
||||
"t": "Yield Token Docs"
|
||||
}
|
||||
],
|
||||
"additional_info": {
|
||||
"ai": {
|
||||
"interest_rate": "5.00%",
|
||||
"interest_type": "variable",
|
||||
"yield_source": "U.S. Treasury Bills",
|
||||
|
||||
@@ -1270,7 +1270,7 @@ const events = [
|
||||
link: "https://luma.com/llwjrmcx",
|
||||
location: "Rome, Italy",
|
||||
date: "November 07, 2025",
|
||||
image: hackathon,
|
||||
image: italyHackathon,
|
||||
end_date: "November 08, 2025",
|
||||
},
|
||||
{
|
||||
@@ -1306,6 +1306,17 @@ const events = [
|
||||
date: "December 10, 2025",
|
||||
end_date: "December 10, 2025",
|
||||
},
|
||||
{
|
||||
name: "XRPL Hackathon @ Blockchain Kaigi 2025",
|
||||
description:
|
||||
"This is a 3-week online hackathon culminating in demos and an awards ceremony to be held in conjunction with Blockchain Kaigi 2025 in Mumbai, India.",
|
||||
type: "hackathon",
|
||||
link: "https://luma.com/ypj8ecj0",
|
||||
location: "Online (with demos at IIT Bombay)",
|
||||
date: "Nov 14 - Dec 06, 2025",
|
||||
image: require("../static/img/events/hackathon-kaigi.png"),
|
||||
end_date: "December 06, 2025",
|
||||
},
|
||||
];
|
||||
|
||||
|
||||
|
||||
@@ -390,10 +390,22 @@ const events = [
|
||||
link: "https://xrpl.vegahacks.xyz/",
|
||||
location: "Virtual",
|
||||
date: "October 01 - November 14, 2025",
|
||||
image: hackathon,
|
||||
image: italyHackathon,
|
||||
end_date: "November 14, 2025",
|
||||
start_date: "October 01, 2025",
|
||||
},
|
||||
{
|
||||
name: "XRPL Hackathon @ Blockchain Kaigi 2025",
|
||||
description:
|
||||
"This is a 3-week online hackathon culminating in demos and an awards ceremony to be held in conjunction with Blockchain Kaigi 2025 in Mumbai, India.",
|
||||
type: "hackathon",
|
||||
link: "https://luma.com/ypj8ecj0",
|
||||
location: "Online (with demos at IIT Bombay)",
|
||||
date: "November 14 - December 06, 2025",
|
||||
image: require("../static/img/events/hackathon-kaigi.png"),
|
||||
start_date: "November 14, 2025",
|
||||
end_date: "December 06, 2025",
|
||||
},
|
||||
|
||||
];
|
||||
|
||||
|
||||
@@ -31,16 +31,10 @@ LP tokens enable liquidity providers to:
|
||||
An AMM holds two different assets: at most one of these can be XRP, and one or both of them can be [tokens](../index.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, or deposit to an AMM if it already exists.
|
||||
|
||||
When you want to trade in the decentralized exchange, your [Offers](offers.md) and [Cross-Currency Payments](../../payment-types/cross-currency-payments.md) 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.
|
||||
When you want to trade in the decentralized exchange, your [offers](offers.md) and [cross-currency payments](../../payment-types/cross-currency-payments.md) 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. You can [read a transaction's metadata](../../transactions/finality-of-results/look-up-transaction-results.md) to see what liquidity it consumed.
|
||||
|
||||
|
||||
|
||||
{% admonition type="info" name="Note" %}
|
||||
|
||||
You can determine if a `Payment` or `OfferCreate` transaction interacted with an AMM by checking for a [`RippleState`](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) ledger entry in the transaction metadata. A `Flags` value of `16777216` indicates AMM liquidity was consumed.
|
||||
|
||||
{% /admonition %}
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
@@ -45,6 +45,94 @@ Every MPT issuance has a set of key properties defined in the ledger as an [MPTo
|
||||
|
||||
After the MPT is issued, the on-chain data cannot be changed. However, the proposed [XLS-94: Dynamic MPT standard](https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0094-dynamic-MPT) {% not-enabled /%} would allow fields to be marked as mutable during creation, so that those fields can be changed later.
|
||||
|
||||
#### Metadata Schema
|
||||
|
||||
To fit within the 1024-byte limit, MPT metadata must use compressed JSON keys. The following table describes these keys and their corresponding fields:
|
||||
|
||||
| Field Name | Key | Type | Required? | Description |
|
||||
|:--------------- |:---- |:---------------- |---------- |-------------|
|
||||
| ticker | `t` | String | Yes | The ticker symbol used to represent the token. Must be uppercase letters (A-Z) and digits (0-9) only. A maximum of 6 characters is recommended. |
|
||||
| name | `n` | String | Yes | The display name of the token. Any UTF-8 string is permitted. |
|
||||
| desc | `d` | String | No | A short description of the token. Any UTF-8 string is permitted. |
|
||||
| icon | `i` | String | Yes | The URI to the token icon. Can be `hostname/path` (HTTPS is assumed), or full URI for other protocols. |
|
||||
| asset_class | `ac` | String | Yes️ | Categorizes tokens by their primary purpose and backing. See [Asset Class](#asset-class) for more details. |
|
||||
| asset_subclass | `as` | String | No | An optional subcategory that is only required if the `asset_class` is `rwa`. See [Asset Subclass](#asset-subclass) for more details. |
|
||||
| issuer_name | `in` | String | Yes | Name of the entity issuing the token. Any UTF-8 string is permitted. |
|
||||
| uris | `us` | Array | No | The list of related URIs such as website, documentation, and social media. See [URIs](#uris) for more details.|
|
||||
| additional_info | `ai` | Object or String | No | Freeform field for key token details like interest rate, maturity date, term, or other relevant info. Any valid JSON object or UTF-8 string is permitted. |
|
||||
|
||||
##### Asset Class
|
||||
|
||||
The `asset_class` field categorizes tokens by their primary purpose and backing. These categories help applications understand the nature of the token and its intended use case.
|
||||
|
||||
| Category | Definition |
|
||||
|----------|------------|
|
||||
| `rwa` | Tokens representing real-world assets (RWAs), which derive value from legally enforceable claims on physical or off-chain financial assets. |
|
||||
| `memes` | Community-driven tokens without intrinsic backing or utility claims, primarily driven by internet culture or speculation. |
|
||||
| `wrapped` | Tokens representing assets from other blockchains, typically backed 1:1 by bridges or custodians. |
|
||||
| `gaming` | Tokens used in games or virtual worlds, often representing in-game currency, assets, or rewards. |
|
||||
| `defi` | Tokens native to or used within DeFi protocols, including governance tokens, DEX tokens, and lending assets. |
|
||||
| `other` | Tokens that do not clearly fit into the defined categories. This may include experimental, test, or tokens with unique use cases not covered elsewhere. |
|
||||
|
||||
##### Asset Subclass
|
||||
|
||||
When `asset_class` is set to `rwa`, an `asset_subclass` can be specified to provide more granular categorization. This describes what type of real-world asset backs the token and what legal or regulatory framework might apply.
|
||||
|
||||
| Subclass | Definition |
|
||||
|----------|------------|
|
||||
| `stablecoin` | Tokens pegged to a stable value, typically fiat currencies like USD, which are backed by reserves like cash, treasuries, or crypto collateral. |
|
||||
| `commodity` | Tokens that represent physical commodities like gold, silver, or oil, often redeemable or legally linked to off-chain reserves. |
|
||||
| `real_estate` | Tokens representing ownership or claims on real estate, including fractionalized property shares or REIT-like instruments. |
|
||||
| `private_credit` | Tokens representing debt obligations from private entities, such as loans, invoices, or receivables. |
|
||||
| `equity` | Tokens representing ownership shares in companies, similar to traditional stock or equity instruments. |
|
||||
| `treasury` | Tokens backed by government debt instruments, such as U.S. Treasury bills or bonds. |
|
||||
| `other` | Tokens that do not fit into the predefined categories, including experimental, hybrid, or emerging real-world asset types. |
|
||||
|
||||
##### URIs
|
||||
|
||||
The `us` array contains a list of URI objects, each with a URI link, category, and human-readable title.
|
||||
|
||||
| Field Name | Key | Type | Required? | Description |
|
||||
|:---------- |:--- |:------ |:--------- |:-------------|
|
||||
| uri | `u` | String | Yes️ |`hostname/path` or full URI link to the related resource. |
|
||||
| category | `c` | String | Yes | The category of the link provided. Allowed values are: `website`, `social`, `docs`, `other`. |
|
||||
| title | `t` | String | Yes | Human-readable label for the link. |
|
||||
|
||||
#### Example JSON Metadata
|
||||
|
||||
The following example shows metadata for a treasury-backed token.
|
||||
|
||||
```json
|
||||
{
|
||||
"t": "TBILL",
|
||||
"n": "T-Bill Yield Token",
|
||||
"d": "A yield-bearing stablecoin backed by short-term U.S. Treasuries and money market instruments.",
|
||||
"i": "example.org/tbill-icon.png",
|
||||
"ac": "rwa",
|
||||
"as": "treasury",
|
||||
"in": "Example Yield Co.",
|
||||
"us": [
|
||||
{
|
||||
"u": "exampleyield.co/tbill",
|
||||
"c": "website",
|
||||
"t": "Product Page"
|
||||
},
|
||||
{
|
||||
"u": "exampleyield.co/docs",
|
||||
"c": "docs",
|
||||
"t": "Yield Token Docs"
|
||||
}
|
||||
],
|
||||
"ai": {
|
||||
"interest_rate": "5.00%",
|
||||
"interest_type": "variable",
|
||||
"yield_source": "U.S. Treasury Bills",
|
||||
"maturity_date": "2045-06-30",
|
||||
"cusip": "912796RX0"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Transferability Controls
|
||||
|
||||
MPTs can be configured with different levels of transferability controls by adjusting the following flags:
|
||||
|
||||
@@ -227,15 +227,15 @@ If the payment contains a `CreatedNode` with `"LedgerEntryType": "AccountRoot"`,
|
||||
|
||||
#### Token Payments
|
||||
|
||||
Payments involving tokens are a bit more complicated.
|
||||
Payments involving [trust line tokens](../../tokens/fungible-tokens/trust-line-tokens.md) are a bit more complicated.
|
||||
|
||||
All changes in token balances are reflected in [RippleState objects](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md), which represent [trust lines](../../tokens/fungible-tokens/index.md). An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; in the metadata, this is only recorded as a single change to the shared `Balance` for the RippleState object. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.
|
||||
All changes to trust line token balances are reflected in [RippleState entries](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md), which represent [trust lines](../../tokens/fungible-tokens/index.md). An increase to one party's balance on a trust line is considered to decrease the counterparty's balance by equal amount; transaction metadata records only a single net change to the shared `Balance` of a `RippleState` entry. Whether this change is recorded as an "increase" or "decrease" depends on which account has the numerically higher address.
|
||||
|
||||
A single payment may go across a long [path](../../tokens/fungible-tokens/paths.md) consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called [rippling](../../tokens/fungible-tokens/rippling.md). Depending on the `issuer` specified in the transaction's `Amount` field, it is also possible that the amount delivered may be split between several trust lines (`RippleState` accounts) connected to the destination account.
|
||||
A single payment may go across a long [path](../../tokens/fungible-tokens/paths.md) consisting of several trust lines and order books. The process of changing the balances on several trust lines to connect parties indirectly is called [rippling](../../tokens/fungible-tokens/rippling.md). Depending on the `issuer` specified in the transaction's `Amount` field, it is also possible that the amount delivered may be split between several trust lines (separate RippleState entries) connected to the destination account.
|
||||
|
||||
{% admonition type="success" name="Tip" %}The order that modified objects are presented in the metadata does not necessarily match the order those objects were visited while processing a payment. To better understand payment execution, it may help to reorder `AffectedNodes` members to reconstruct the paths the funds took through the ledger.{% /admonition %}
|
||||
|
||||
Cross-currency payments consume [Offers](../../../references/protocol/ledger-data/ledger-entry-types/offer.md) in part or entirely to change between different currency codes and issuers. If a transaction shows `DeletedNode` objects for `Offer` types, that can indicate an Offer that was fully consumed, or an Offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing. If a transaction shows a `ModifiedNode` of type `Offer`, that indicates an Offer that was partially consumed.
|
||||
Cross-currency payments use [offers](../../tokens/decentralized-exchange/offers.md) and [AMMs](../../tokens/decentralized-exchange/automated-market-makers.md) to convert between different currency codes and issuers. Offers can be partially or fully consumed. If a transaction shows `DeletedNode` objects for `Offer` types, that can indicate an offer that was fully consumed, or an offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing. If a transaction shows a `ModifiedNode` of type `Offer`, that indicates an offer that was partially consumed.
|
||||
|
||||
The [`QualityIn` and `QualityOut` settings of trust lines](../../../references/protocol/transactions/types/trustset.md) can affect how one side of a trust line values the token, so that the numeric change in balances is different from how the sender values that token. The `delivered_amount` shows how much was delivered as valued by the recipient.
|
||||
|
||||
@@ -243,9 +243,17 @@ If the amount to be sent or received is outside of the [token precision](../../.
|
||||
|
||||
Depending on the length of the [paths](../../tokens/fungible-tokens/paths.md), the metadata for cross-currency payments can be _long_. For example, [transaction 8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B) delivered 2.788 GCB issued by `rHaaans...`, spending XRP but passing through USD from 2 issuers, paying XRP to 2 accounts, removing an unfunded offer from `r9ZoLsJ...` to trade EUR for ETH, plus bookkeeping for a total of 17 different ledger objects modified. <!-- SPELLING_IGNORE: gcb -->
|
||||
|
||||
#### Using AMM Liquidity
|
||||
|
||||
You can tell if an AMM was involved in a transaction by looking for [RippleState entries](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md) that belong to an AMM. Check the `Flags` value of each `RippleState` entry in the `AffectedNodes` array; if the [`lsfAMMNode` flag](../../../references/protocol/ledger-data/ledger-entry-types/ripplestate.md#ripplestate-flags) is enabled, then that trust line is connected to an AMM. Flags are combined using bitwise operations. To check if `lsfAMMNode` is enabled, use a bitwise-AND operator, like the following pseudo-code:
|
||||
|
||||
```
|
||||
isEnabled = RippleState.Flags & lsfAMMNode
|
||||
```
|
||||
|
||||
### Offers
|
||||
|
||||
An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer to the ledger's order books. For example:
|
||||
An [OfferCreate transaction][] may or may not create an object in the ledger, depending on how much was matched and whether the transaction used flags such as `tfImmediateOrCancel`. Look for a `CreatedNode` entry with `"LedgerEntryType": "Offer"` to see if the transaction added a new Offer entry to the ledger's order books. For example:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -268,11 +276,11 @@ An [OfferCreate transaction][] may or may not create an object in the ledger, de
|
||||
}
|
||||
```
|
||||
|
||||
A `ModifiedNode` of type `Offer` indicates an Offer that was matched and partially consumed. A single transaction can consume a large number of Offers. An Offer to trade two tokens might also consume Offers to trade XRP because of [auto-bridging](../../tokens/decentralized-exchange/autobridging.md). All or part of an exchange can be auto-bridged.
|
||||
A `ModifiedNode` of type `Offer` indicates an offer that was matched and partially consumed. A single transaction can consume a large number of offers. An offer to trade two tokens might also consume offers to trade XRP because of [auto-bridging](../../tokens/decentralized-exchange/autobridging.md). All or part of an exchange can be auto-bridged. Offers can also use AMMs to convert currency; you can recognize when this happens by [checking for a `RippleState` entry with the `lsfAMMNode` flag](#using-amm-liquidity) in the `AffectedNodes` array.
|
||||
|
||||
A `DeletedNode` of type `Offer` can indicate a matching Offer that was fully consumed, an Offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing, or an Offer that was canceled as part of placing a new Offer. You can recognize a canceled Offer because the `Account` that placed it is the sender of the transaction that deleted it.
|
||||
A `DeletedNode` of type `Offer` can indicate a matching offer that was fully consumed, an offer that was found to be [expired or unfunded](../../tokens/decentralized-exchange/offers.md#lifecycle-of-an-offer) at the time of processing, or an offer that was canceled as part of placing a new offer. You can recognize a canceled offer because the `Account` that placed it is the sender of the transaction that deleted it.
|
||||
|
||||
Example of a deleted Offer:
|
||||
Example of a deleted offer:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -300,11 +308,11 @@ Example of a deleted Offer:
|
||||
}
|
||||
```
|
||||
|
||||
Offers can create, delete, and modify both types of [DirectoryNode objects](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md), to keep track of who placed which Offers and which Offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
|
||||
Offers can create, delete, and modify [DirectoryNode entries](../../../references/protocol/ledger-data/ledger-entry-types/directorynode.md), both to keep track of who placed which offers and which offers are available at which exchange rates. Generally, users don't need to pay close attention to this bookkeeping.
|
||||
|
||||
An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no Offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an Offer. If not, the Offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
|
||||
An [OfferCancel transaction][] may have the code `tesSUCCESS` even if there was no offer to delete. Look for a `DeletedNode` of type `Offer` to confirm that the transaction actually deleted an offer. If not, the offer may already have been removed by a previous transaction, or the OfferCancel transaction may have used the wrong sequence number in the `OfferSequence` field.
|
||||
|
||||
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the Offer created a trust line](../../tokens/decentralized-exchange/offers.md#offers-and-trust) to hold a token received in the trade.
|
||||
If an OfferCreate transaction shows a `CreatedNode` of type `RippleState`, that indicates that [the offer created a trust line](../../tokens/decentralized-exchange/offers.md#offers-and-trust) to hold a token received in the trade.
|
||||
|
||||
### Escrows
|
||||
|
||||
|
||||
@@ -43,11 +43,6 @@ Edit your `rippled.cfg` file.
|
||||
# No [ips] stanza. Use the default hubs to connect to Mainnet.
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[ips]
|
||||
sidechain-net2.devnet.rippletest.net 51235
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
2. Comment out the previous `[ips]` stanza, if there is one:
|
||||
@@ -77,11 +72,6 @@ Edit your `rippled.cfg` file.
|
||||
main
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[network_id]
|
||||
262
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
For custom networks, everyone who connects to the network should use a value unique to that network. When creating a new network, choose a network ID at random from the integers 11 to 4,294,967,295.
|
||||
@@ -120,14 +110,6 @@ Edit your `validators.txt` file. This file is located in the same folder as your
|
||||
ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
|
||||
```
|
||||
|
||||
```{% label="Sidechain-Devnet" %}
|
||||
[validator_list_sites]
|
||||
https://vlsidechain-net2.devnet.rippletest.net
|
||||
|
||||
[validator_list_keys]
|
||||
EDA5504C7133743FADA46342229B4E9CBBE1CF9BCA19D16633574F7CBB72F79569
|
||||
```
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
{% admonition type="success" name="Tip" %}Preview packages might come with the necessary stanzas pre-configured, but check them just in case.{% /admonition %}
|
||||
@@ -181,13 +163,6 @@ For some test networks using experimental features, you must also forcefully ena
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Sidechain-Devnet" %}
|
||||
```
|
||||
[features]
|
||||
XChainBridge
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% /tabs %}
|
||||
|
||||
{% admonition type="danger" name="Warning" %}Do not use the `[features]` stanza when connecting to Mainnet or Testnet. Forcefully enabling different features than the rest of the network could cause your server to diverge from the network.{% /admonition %}
|
||||
|
||||
@@ -70,8 +70,7 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
`RippleState` entries can have the following flags combined into the `Flags` field:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Corresponding [TrustSet Flag](../../transactions/types/trustset.md#trustset-flags) | Description |
|
||||
|-------------------|--------------|---------------|-----------------|---------|
|
||||
| `lsfAMMNode` | `0x01000000` | 16777216 | (None) | This entry consumed AMM liquidity to complete a [`Payment`](../../transactions/types/payment.md) transaction. |
|
||||
|---------------------|--------------|---------------|-----------------------|---------|
|
||||
| `lsfLowReserve` | `0x00010000` | 65536 | (None) | This entry [contributes to the low account's owner reserve](#ripplestate-reserve). |
|
||||
| `lsfHighReserve` | `0x00020000` | 131072 | (None) | This entry [contributes to the high account's owner reserve](#ripplestate-reserve). |
|
||||
| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | The low account has authorized the high account to hold tokens issued by the low account. |
|
||||
@@ -80,8 +79,9 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | The high account [has disabled rippling](../../../../concepts/tokens/fungible-tokens/rippling.md) from this trust line. |
|
||||
| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | The low account has frozen the trust line, preventing the high account from transferring the asset. |
|
||||
| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | The high account has frozen the trust line, preventing the low account from transferring the asset. |
|
||||
| `lsfLowDeepFreeze` | `0x02000000` | 33554432 |`tfSetLowDeepFreeze` | The low account has deep-frozen the trust line, preventing the high account from sending and receiving the asset. |
|
||||
| `lsfHighDeepFreeze` | `0x04000000` | 67108864 | `tfSetHighDeepFreeze` | The high account has deep-frozen the trust line, preventing the low account from sending and receiving the asset. |
|
||||
| `lsfAMMNode` | `0x01000000` | 16777216 | (None) | This trust line holds one of the assets in an [Automated Market Maker](../../../../concepts/tokens/decentralized-exchange/automated-market-makers.md)'s pool; one of this trust line's accounts is the AMM, and the other is the issuer of the token. {% amendment-disclaimer name="AMM" /%} |
|
||||
| `lsfLowDeepFreeze` | `0x02000000` | 33554432 |`tfSetLowDeepFreeze` | The low account has deep-frozen the trust line, preventing the high account from sending and receiving the asset. {% amendment-disclaimer name="DeepFreeze" /%} |
|
||||
| `lsfHighDeepFreeze` | `0x04000000` | 67108864 | `tfSetHighDeepFreeze` | The high account has deep-frozen the trust line, preventing the low account from sending and receiving the asset. {% amendment-disclaimer name="DeepFreeze" /%} |
|
||||
|
||||
The two accounts connected by the trust line can each change their own settings with a [TrustSet transaction][].
|
||||
|
||||
|
||||
@@ -19,21 +19,32 @@ Creates both an [AMM entry][] and a [special AccountRoot entry](../../ledger-dat
|
||||
|
||||
```json
|
||||
{
|
||||
"Account" : "rJVUeRqDFNs2xqA7ncVE6ZoAhPUoaJJSQm",
|
||||
"Amount" : {
|
||||
"currency" : "TST",
|
||||
"issuer" : "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd",
|
||||
"value" : "25"
|
||||
"Account": "r3qNwezAqKp2FRFteiFjhC4V1at4KePFx7",
|
||||
"Amount": {
|
||||
"currency": "SKY",
|
||||
"issuer": "rSKYachd4cqUgztsTr83mEKTAcNZG4Ez2",
|
||||
"value": "80"
|
||||
},
|
||||
"Amount2" : "250000000",
|
||||
"Fee" : "2000000",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 6,
|
||||
"TradingFee" : 500,
|
||||
"TransactionType" : "AMMCreate"
|
||||
"Amount2": "20000000",
|
||||
"Fee": "200000",
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 99502897,
|
||||
"Memos": [
|
||||
{
|
||||
"Memo": {
|
||||
"MemoData": "414D4D2063726561746520696E69746961746564207669612058506D61726B65742E636F6D"
|
||||
}
|
||||
}
|
||||
],
|
||||
"Sequence": 94041760,
|
||||
"SourceTag": 20221212,
|
||||
"TradingFee": 1000,
|
||||
"TransactionType": "AMMCreate",
|
||||
}
|
||||
```
|
||||
|
||||
{% tx-example txid="E4CC45E28421618FFEB1920B8FE152EAAB70489BD9AD52FEF24D58389C011C5E" /%}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|
||||
@@ -15,6 +15,23 @@ Control whether an account can hold a given [Multi-purpose Token (MPT)](../../..
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
## Example MPTokenAuthorize JSON
|
||||
|
||||
This example assumes that the transaction is submitted by the holder of the token.
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "MPTokenAuthorize",
|
||||
"Account": "rsNw23ygZatXv7h8QVSgAE4jktY2uW1iZP",
|
||||
"MPTokenIssuanceID": "05EECEBE97A7D635DE2393068691A015FED5A89AD203F5AA",
|
||||
"Fee": "10",
|
||||
"Flags": 0,
|
||||
"Sequence": 99537811
|
||||
}
|
||||
```
|
||||
|
||||
{% tx-example txid="9C19FBB8C0C92C17B11DF626A94303776D44AC36D7A760863FF3585532C38230" /%}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|
||||
@@ -20,16 +20,20 @@ This example assumes that the issuer of the token is the signer of the transacti
|
||||
```json
|
||||
{
|
||||
"TransactionType": "MPTokenIssuanceCreate",
|
||||
"Account": "rajgkBmMxmz161r8bWYH7CQAFZP5bA9oSG",
|
||||
"AssetScale": 2,
|
||||
"TransferFee": 314,
|
||||
"Account": "rNFta7UKwcoiCpxEYbhH2v92numE3cceB6",
|
||||
"AssetScale": 4,
|
||||
"TransferFee": 0,
|
||||
"MaximumAmount": "50000000",
|
||||
"Flags": 83659,
|
||||
"MPTokenMetadata": "7B227469636B6572223A20225442494C4C222C20226E616D65223A2022542D42696C6C205969656C6420546F6B656E222C202264657363223A202241207969656C642D62656172696E6720737461626C65636F696E206261636B65642062792073686F72742D7465726D20552E532E205472656173757269657320616E64206D6F6E6579206D61726B657420696E737472756D656E74732E222C202269636F6E223A202268747470733A2F2F6578616D706C652E6F72672F7462696C6C2D69636F6E2E706E67222C202261737365745F636C617373223A2022727761222C202261737365745F737562636C617373223A20227472656173757279222C20226973737565725F6E616D65223A20224578616D706C65205969656C6420436F2E222C202275726C73223A205B7B2275726C223A202268747470733A2F2F6578616D706C657969656C642E636F2F7462696C6C222C202274797065223A202277656273697465222C20227469746C65223A202250726F647563742050616765227D2C207B2275726C223A202268747470733A2F2F6578616D706C657969656C642E636F2F646F6373222C202274797065223A2022646F6373222C20227469746C65223A20225969656C6420546F6B656E20446F6373227D5D2C20226164646974696F6E616C5F696E666F223A207B22696E7465726573745F72617465223A2022352E303025222C2022696E7465726573745F74797065223A20227661726961626C65222C20227969656C645F736F75726365223A2022552E532E2054726561737572792042696C6C73222C20226D617475726974795F64617465223A2022323034352D30362D3330222C20226375736970223A2022393132373936525830227D7D",
|
||||
"Fee": "10"
|
||||
"MPTokenMetadata": "7B2274223A225442494C4C222C226E223A22542D42696C6C205969656C6420546F6B656E222C2264223A2241207969656C642D62656172696E6720737461626C65636F696E206261636B65642062792073686F72742D7465726D20552E532E205472656173757269657320616E64206D6F6E6579206D61726B657420696E737472756D656E74732E222C2269223A226578616D706C652E6F72672F7462696C6C2D69636F6E2E706E67222C226163223A22727761222C226173223A227472656173757279222C22696E223A224578616D706C65205969656C6420436F2E222C227573223A5B7B2275223A226578616D706C657969656C642E636F2F7462696C6C222C2263223A2277656273697465222C2274223A2250726F647563742050616765227D2C7B2275223A226578616D706C657969656C642E636F2F646F6373222C2263223A22646F6373222C2274223A225969656C6420546F6B656E20446F6373227D5D2C226169223A7B22696E7465726573745F72617465223A22352E303025222C22696E7465726573745F74797065223A227661726961626C65222C227969656C645F736F75726365223A22552E532E2054726561737572792042696C6C73222C226D617475726974795F64617465223A22323034352D30362D3330222C226375736970223A22393132373936525830227D7D",
|
||||
"Fee": "12",
|
||||
"Flags": 122,
|
||||
"Sequence": 99536574
|
||||
}
|
||||
```
|
||||
|
||||
{% tx-example txid="F4491A84EE3BC27A2F5B63FEBF0CB310368E27E9EF07E00A46F1DC2764852133" /%}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|
||||
@@ -16,11 +16,15 @@ Delete a [Multi-purpose Token (MPT)](../../../../concepts/tokens/fungible-tokens
|
||||
```json
|
||||
{
|
||||
"TransactionType": "MPTokenIssuanceDestroy",
|
||||
"Account": "rNFta7UKwcoiCpxEYbhH2v92numE3cceB6",
|
||||
"MPTokenIssuanceID": "05EECEBC97A7D635DE2393068691A015FED5A89AD203F5AA",
|
||||
"Fee": "10",
|
||||
"MPTokenIssuanceID": "00070C4495F14B0E44F78A264E41713C64B5F89242540EE255534400000000000000"
|
||||
"Flags": 0,
|
||||
"Sequence": 99536573
|
||||
}
|
||||
```
|
||||
|
||||
{% tx-example txid="B270DEE7D229D626699935B7B3CC37A1BAD3E832044CE5129722C2965D3EB228" /%}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
|
||||
@@ -11,17 +11,23 @@ Update a mutable property of a [Multi-purpose Token (MPT)](../../../../concepts/
|
||||
|
||||
{% amendment-disclaimer name="MPTokensV1" /%}
|
||||
|
||||
## Example
|
||||
## Example MPTokenIssuanceSet JSON
|
||||
|
||||
This example locks the balances of all holders of the specified MPT issuance.
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "MPTokenIssuanceSet",
|
||||
"Account": "rNFta7UKwcoiCpxEYbhH2v92numE3cceB6",
|
||||
"MPTokenIssuanceID": "05EECEBE97A7D635DE2393068691A015FED5A89AD203F5AA",
|
||||
"Fee": "10",
|
||||
"MPTokenIssuanceID": "00070C4495F14B0E44F78A264E41713C64B5F89242540EE255534400000000000000",
|
||||
"Flags": 1
|
||||
"Flags": 1,
|
||||
"Sequence": 99536577
|
||||
}
|
||||
```
|
||||
|
||||
{% tx-example txid="5DB41F975E3AC04DD4AE9E93764AFBBABB0E4C7322B2D6F2E84B253FAA170BF3" /%}
|
||||
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|
||||
@@ -16,27 +16,79 @@ Create or update a [price oracle](../../../../concepts/decentralized-storage/pri
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "OracleSet",
|
||||
"Account": "rNZ9m6AP9K7z3EVg6GhPMx36V4QmZKeWds",
|
||||
"OracleDocumentID": 34,
|
||||
"Provider": "70726F7669646572",
|
||||
"LastUpdateTime": 1724871860,
|
||||
"Account": "roosteri9aGNFRXZrJNYQKVBfxHiE5abg",
|
||||
"AssetClass": "63757272656E6379",
|
||||
"Fee": "12",
|
||||
"LastUpdateTime": 1760397040,
|
||||
"OracleDocumentID": 3,
|
||||
"PriceDataSeries": [
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "267e",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "USD",
|
||||
"AssetPrice": 740,
|
||||
"QuoteAsset": "SAR",
|
||||
"Scale": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "214a",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "THB",
|
||||
"Scale": 2
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "1abc8",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "TRY",
|
||||
"Scale": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "13b19",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "TWD",
|
||||
"Scale": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "686e090",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "UAH",
|
||||
"Scale": 6
|
||||
}
|
||||
},
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "a34",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "USD",
|
||||
"Scale": 3
|
||||
}
|
||||
},
|
||||
{
|
||||
"PriceData": {
|
||||
"AssetPrice": "11d9",
|
||||
"BaseAsset": "XRP",
|
||||
"QuoteAsset": "ZAR",
|
||||
"Scale": 2
|
||||
}
|
||||
}
|
||||
],
|
||||
"Provider": "7468726565787270",
|
||||
"Sequence": 95076881,
|
||||
"TransactionType": "OracleSet",
|
||||
"URI": "68747470733A2F2F6174746573746174696F6E2E74687265657872702E6465762F63757272656E63793A39393530323934303A39353037363838313A33"
|
||||
}
|
||||
```
|
||||
|
||||
{% tx-example txid="11449FDBDF40345F08B2E1537EA9590369B5A662CDEB3DB71F9A2CC04E1012C1" /%}
|
||||
|
||||
## OracleSet Fields
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
| Field | JSON Type | Internal Type | Required? | Description |
|
||||
|--------------------|-----------|---------------|-----------|-------------|
|
||||
|
||||
@@ -26,7 +26,7 @@ Setting up an IOU-IOU bridge enables you to move tokens between chains.
|
||||
const xrpl = require('xrpl')
|
||||
|
||||
const WS_URL_lockingchain = 'wss://s.devnet.rippletest.net:51233/' // Locking chain
|
||||
const WS_URL_issuingchain = 'wss://sidechain-net2.devnet.rippletest.net:51233/' // Issuing chain
|
||||
const WS_URL_issuingchain = 'wss://example-sidechain.net:12345/' // Issuing chain
|
||||
|
||||
// Define the XChainBridge, using the "TST" token.
|
||||
const xchainbridge = {
|
||||
|
||||
@@ -27,7 +27,7 @@ Setting up an XRP-XRP bridge enables you to move XRP between chains. The set up
|
||||
const xrpl = require('xrpl')
|
||||
|
||||
const WS_URL_lockingchain = 'wss://s.devnet.rippletest.net:51233/' // Locking chain
|
||||
const WS_URL_issuingchain = 'wss://sidechain-net2.devnet.rippletest.net:51233/' // Issuing chain
|
||||
const WS_URL_issuingchain = 'wss://example-sidechain.net:12345/' // Issuing chain
|
||||
|
||||
// Define the XChainBridge
|
||||
const xchainbridge = {
|
||||
|
||||
@@ -25,7 +25,7 @@ This tutorial explains how to create a test account on a locking chain (_Devent_
|
||||
const xrpl = require('xrpl')
|
||||
|
||||
const WS_URL_lockingchain = 'wss://s.devnet.rippletest.net:51233/' // Locking chain
|
||||
const WS_URL_issuingchain = 'wss://sidechain-net2.devnet.rippletest.net:51233/' // Issuing chain
|
||||
const WS_URL_issuingchain = 'wss://example-sidechain.net:12345/' // Issuing chain
|
||||
|
||||
// Define the XChainBridge
|
||||
const xchainbridge = {
|
||||
|
||||
@@ -32,7 +32,6 @@ If you don't [run your own `rippled` server](../infrastructure/installation/inde
|
||||
| Ripple[¹][] | Testnet (Clio) | `https://clio.altnet.rippletest.net:51234/` | `wss://clio.altnet.rippletest.net:51233/` | Testnet public server with Clio |
|
||||
| Ripple[¹][] | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net:51233/` | Devnet public server |
|
||||
| Ripple[¹][] | Devnet (Clio) | `https://clio.devnet.rippletest.net:51234/` | `wss://clio.devnet.rippletest.net:51233/` | Devnet public server with Clio |
|
||||
| Ripple[¹][] | Sidechain-Devnet | `https://sidechain-net2.devnet.rippletest.net:51234/` | `wss://sidechain-net2.devnet.rippletest.net:51233/` | Sidechain Devnet to test cross-chain bridge features. Devnet serves as the locking chain while this sidechain serves as the issuing chain. |
|
||||
| XRPL Labs | Xahau Testnet | `https://xahau-test.net/` | `wss://xahau-test.net/` | [Hooks-enabled](https://hooks.xrpl.org/) Xahau Testnet |
|
||||
|
||||
|
||||
|
||||
@@ -1,81 +1,62 @@
|
||||
---
|
||||
html: documentation-translations.html
|
||||
parent: contribute-documentation.html
|
||||
seo:
|
||||
description: Learn how to contribute and maintain translations of the documentation on this website.
|
||||
---
|
||||
# Translations
|
||||
|
||||
The XRP Ledger Dev Portal is mostly written in English, so the English version is generally the most up-to-date and accurate version. However, to broaden the reach of the XRP Ledger software and community, this repository also contains translated versions of the documentation. We strongly encourage members of the community who understand other languages to contribute translations of the dev portal contents in their native languages.
|
||||
The XRP Ledger Dev Portal (XRPL.org) is mostly written in English, so the English version is generally the most up-to-date and accurate version. However, to broaden the reach of the XRP Ledger software and community, this repository also contains translated versions of the documentation. We strongly encourage members of the community who understand other languages to contribute translations of the dev portal contents in their native languages.
|
||||
|
||||
The `dactyl-config.yml` contains a "target" entry for each available language. (Currently, the available languages are English and Japanese.) This entry includes a dictionary of strings used in the template files. For example:
|
||||
The languages currently provided are:
|
||||
|
||||
```yaml
|
||||
- name: en
|
||||
lang: en
|
||||
display_name: XRP Ledger Dev Portal
|
||||
# These github_ fields are used by the template's "Edit on GitHub" link.
|
||||
# Override them with --vars to change which fork/branch to edit.
|
||||
github_forkurl: https://github.com/XRPLF/xrpl-dev-portal
|
||||
github_branch: master
|
||||
strings:
|
||||
blog: "Blog"
|
||||
search: "Search site with Google..."
|
||||
bc_home: "Home"
|
||||
# ...
|
||||
```
|
||||
|
||||
There is also a top-level `languages` listing that defines some properties for each supported language. The short code for each language should be short code according to [IETF BCP47](https://tools.ietf.org/html/bcp47). For example, "en" for English, "es" for Spanish, "ja" for Japanese, "zh-CN" for Simplified Chinese, "zh-TW" for Traditional Chinese (as used in Taiwan), and so on. The `display_name` field defines the language's name as written natively in that language. The `prefix` field defines a prefix to be used in hyperlinks to that language's version of the site. Example `languages` definition:
|
||||
|
||||
```yaml
|
||||
languages:
|
||||
- code: en
|
||||
display_name: English
|
||||
prefix: "/"
|
||||
- code: ja
|
||||
display_name: 日本語
|
||||
prefix: "/ja/"
|
||||
```
|
||||
|
||||
The same `dactyl-config.yml` file contains an entry for each content page in the XRP Ledger Dev Portal. If a page has been translated, there is a separate entry for each translation, linked to the "target" for that translation. If a page has not yet been translated, the English version is used across all targets. (If a new page is added only to English and not other languages, the link checker reports that as a broken link.)
|
||||
|
||||
Translating a page means separating out the entry for that page in the other language. Here are some tips for translating the page's metadata, which can be in either the `dactyl-config.yml` file or the frontmatter at the top of the page's Markdown file:
|
||||
|
||||
| Field | Notes |
|
||||
|-------|-------|
|
||||
| `html` | The HTML file name of the page. By convention, this should be the same across all language versions. |
|
||||
| `md` | The Markdown source file for the page. Translated Markdown source files should use the same filename as the English-language version except that the file extension should be `.{language code}.md` instead of only `.md` for English. For example, Japanese translated files end in `.ja.md`. |
|
||||
| `blurb` | A short summary of the page. This should be translated. This text is used in metadata for search engine optimization and also on automatically-generated landing pages. |
|
||||
| Language | Code | Status |
|
||||
|-------------------|------|--------|
|
||||
| English | (N/A) | Primary language, with most work and updates being done in English first. |
|
||||
| Japanese (日本語) | `ja` | Available on the site. Maintained on a best-effort basis, but sometimes not as up-to-date as the English version. |
|
||||
| Spanish (Español) | `es-ES` | Incomplete, not actively maintained. Not currently served on the production site. |
|
||||
|
||||
|
||||
Example of English and Japanese entries for the `server_info` method page:
|
||||
## Translations Folder
|
||||
|
||||
```yaml
|
||||
- md: references/http-websocket-apis/public-api-methods/server-info-methods/server_info.md
|
||||
targets:
|
||||
- en
|
||||
The `@l10n` folder of the repository contains the translated docs for the site, including documentation pages (written in Markdown) and non-documentation pages such as dev tools that use the translations file to replace smaller strings of text where possible. Each translation exists in a separate folder identified by an [IETF BCP47](https://tools.ietf.org/html/bcp47) language code. Within the folder for a given language, the folder structure mirrors the top of the repository, such that content files whose path matches exactly are used instead of the English language versions. For example, `@l10n/ja/docs/concepts/accounts/index.md` is a Japanese-translated version of `docs/concepts/accounts/index.md`.
|
||||
|
||||
- md: references/http-websocket-apis/public-api-methods/server-info-methods/server_info.ja.md
|
||||
targets:
|
||||
- ja
|
||||
```
|
||||
If there is not a parallel version of a file in the translation folder, the English version displays when you navigate to that page on the translated version of the site.
|
||||
|
||||
Example entry for a page that isn't translated:
|
||||
|
||||
```yaml
|
||||
- md: concepts/payment-system-basics/transaction-basics/source-and-destination-tags.md
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
```
|
||||
## Strings File
|
||||
|
||||
The `translations.yaml` file contains strings of text that are used in specially-stylized pages (with the `.page.tsx` extension) including dev tools and the "marketing" pages in the `about/` and `community/` sections of the site, and in some cases the `sidebars.yaml` file too.
|
||||
|
||||
Preferably, strings should use a key such as `topnav.docs.tutorials` to uniquely indicate the text being translated. Strings can also be matched by exactly the English text being translated, but matching by the English text is not ideal because the same text may need to be translated differently based on context, or different segments of text may need to be translated non-exactly to display correctly. The original files should be updated to use translation keys as needed.
|
||||
|
||||
|
||||
## Moving or Renaming Files
|
||||
|
||||
When files are moved or renamed, the translated files also need to be moved or renamed the same way.
|
||||
|
||||
When you add redirects to the `redirects.yaml` file at the repository top, also add redirects for each translation (these are grouped later in the file).
|
||||
|
||||
|
||||
## Where to Start
|
||||
|
||||
If you want to translate the XRP Ledger Dev Portal into your native language of choice, start with the {% repo-link path="docs/concepts/introduction/what-is-the-xrp-ledger.md" %}"What is the XRP Ledger?" page{% /repo-link %}, which introduces the core concepts behind the XRP Ledger.
|
||||
If you want to translate the XRP Ledger Dev Portal into your native language of choice, start with the {% repo-link path="docs/introduction/what-is-the-xrp-ledger.md" %}"What is the XRP Ledger?" page{% /repo-link %}, which introduces the core concepts behind the XRP Ledger.
|
||||
|
||||
Save the file as `what-is-the-xrp-ledger.{language code}.md`, where `{language code}` is the [IETF BCP47](https://tools.ietf.org/html/bcp47) language code. (For example, "es" for Spanish, "ja" for Japanese, "zh-CN" for Simplified Chinese, "zh-TW" for Traditional Chinese as used in Taiwan, and so on.) Then open a [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) adding your file to this repository. One of the repository's maintainers can help with the other necessary setup to add the language to the site.
|
||||
Save the file as `@l10n/{language code}/docs/introduction/what-is-the-xrp-ledger.md`, where `{language code}` is the [IETF BCP47](https://tools.ietf.org/html/bcp47) language code. (For example, "es-ES" for Spanish (Spain), "ja" for Japanese, "zh-CN" for Simplified Chinese, "zh-TW" for Traditional Chinese as used in Taiwan, and so on.) Then open a [pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests) adding your file to this repository. One of the repository's maintainers can help with the other necessary setup to add the language to the site.
|
||||
|
||||
For the Markdown content files, please use the following conventions:
|
||||
|
||||
- Line-feed newline characters (`\n`) only (Unix style). Do not use carriage return (`\r`) characters (Windows style).
|
||||
- Use UTF-8 encoding. Avoid the use of Byte-order marks.
|
||||
|
||||
To test changes with the translated version of the site, modify the `redocly.yaml` file at the repository top and add the language in question to the `l10n.locales` list:
|
||||
|
||||
```yaml
|
||||
l10n:
|
||||
defaultLocale: en-US
|
||||
locales:
|
||||
- code: en-US
|
||||
name: English
|
||||
- code: ja
|
||||
name: 日本語
|
||||
```
|
||||
|
||||
Then start the local dev server with `npm run start` from the repository top, use your web browser to view the local site, and choose the language from the dropdown in the main menu.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: contribute-documentation.html
|
||||
parent: resources.html
|
||||
metadata:
|
||||
indexPage: true
|
||||
seo:
|
||||
description: Contribution guides for XRP Ledger documentation.
|
||||
---
|
||||
@@ -23,18 +23,17 @@ The official source repository for the site is at <https://github.com/XRPLF/xrpl
|
||||
|
||||
- `_api-examples/` - Sample API requests and responses, especially ones used in the documentation.
|
||||
- `_code-samples/` - Code samples used or referenced by the documentation. Where possible, these are fully functional / executable scripts.
|
||||
- `@l10n` - Translations into languages other than English. Currently, only Japanese.
|
||||
- `@l10n` - Translations into languages other than English. See [Documentation Translations](./documentation-translations.md) for details.
|
||||
- `@theme` - Overrides and custom components used in Markdoc contents as well as custom React pages.
|
||||
- `about/` - Source files for the About section's pages.
|
||||
- `blog/` - Source files for the XRPL Dev Blog.
|
||||
- `community/` - Source files for the Community section's pages.
|
||||
- `docs/` - Source files used to build the documentation. Mostly in Markdown.
|
||||
- `docs/_snippets/` - Reusable pieces of text used in the documentation.
|
||||
- `docs/img/` - Diagrams and other images used in the documentation.
|
||||
- `docs/img/` - Diagrams and other images used in the documentation. Diagrams can also be placed in the folder with the files that reference them.
|
||||
- `docs/img/_sources/` - Source files for images used in the documentation, where available.
|
||||
- `locale/` - **DEPRECATED** Old localization files.
|
||||
- `resources/` - Source files for the Resources section's pages.
|
||||
- `shared/` - Configuration files for some dependencies like CodeMirror.
|
||||
- `shared/` - Configuration files for some dependencies like CodeMirror, and React components for some specially styled pages.
|
||||
- `static/` - Static files used by the site's templates and theme.
|
||||
- `styles/` - SCSS source files for custom CSS.
|
||||
- `redirects.yaml` - Definitions of redirects from old site URLs to current paths.
|
||||
@@ -45,11 +44,13 @@ The official source repository for the site is at <https://github.com/XRPLF/xrpl
|
||||
|
||||
## Requirements for a Successful Pull Request
|
||||
|
||||
Before being considered for review or merging, each pull request must:
|
||||
Before being considered for merging, each pull request must:
|
||||
|
||||
- Pass continuous integration tests.
|
||||
- Be [marked as drafts](https://github.blog/2019-02-14-introducing-draft-pull-requests/) until they are ready for review.
|
||||
- Adhere to the [code of conduct](https://github.com/XRPLF/xrpl-dev-portal/blob/master/CODE-OF-CONDUCT.md) for this repository.
|
||||
1. Pass continuous integration tests.
|
||||
2. Adhere to the [code of conduct](https://github.com/XRPLF/xrpl-dev-portal/blob/master/CODE-OF-CONDUCT.md) for this repository.
|
||||
3. Pass review from at least one maintainer, who will consider the quality, relevance, and maintainability of the contents in their review.
|
||||
|
||||
If your PR is not yet ready to be merged, [mark it as a draft](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
|
||||
|
||||
## Redocly Setup
|
||||
|
||||
@@ -84,6 +85,36 @@ If you add a new page, you should add it to the appropriate `sidebars.yaml` file
|
||||
|
||||
The Markdown file for a page should start with a [frontmatter stanza](#frontmatter-fields).
|
||||
|
||||
## Writing Style
|
||||
|
||||
In general, follow the [Microsoft Style Guide](https://learn.microsoft.com/en-us/style-guide/)'s recommendations for tone, phrasing, and structure. You are allowed to deviate from the Microsoft guide.
|
||||
|
||||
Try to split documentation pages into the following categories, based on their contents:
|
||||
|
||||
- **Concepts:** Explain the _how_ and _why_ of a topic, feature, or practice. Don't go overboard with specific names, values, or code. Use [diagrams](./creating-diagrams.md) to help with understanding.
|
||||
- **References:** Describe all the possible properties, modes, or features of a piece of technology. Provide only small amounts of context, while linking to concepts for the bigger picture. Use tables or bulleted lists, sorted, to help users find what they need.
|
||||
- **Tutorials:** Demonstrate how to accomplish a task or use a feature. Provide step-by-step instructions with working code samples if possible. Link to references for more details of the functions used and alternative options. For more recommendations on how to build tutorials, see the [Tutorial Guidelines](./tutorial-guidelines.md).
|
||||
|
||||
These types of documents serve people with different roles, or sometimes the same people at different points in their process. For example, software architects or CTOs making technical decisions might read a concept page to decide how to structure their integration or to determine which technology meets their needs; engineers might copy code from tutorials while building, then use the reference to adapt it for their use case.
|
||||
|
||||
Some pages, like **Use Cases**, don't fit cleanly into these categories. It is OK to have exceptions where justified.
|
||||
|
||||
### Interlinking
|
||||
|
||||
Linking is useful for readers, who may arrive at any page in any order, without full context. Links in the body text help humans navigate through the site, since it's common to end up on a page that does not actually have the information you are looking for, but is related in some way to the page that does; links can send people to the right place while also building an understanding of the relationship between pieces of the whole. Frequent usage of links also helps machines point people at the right place, both in terms of search engine optimization and generative engine (AI) optimization.
|
||||
|
||||
Links commonly fall into these categories:
|
||||
|
||||
- _external links_ go to other sites. These should be used sparingly and clearly indicated; otherwise, suddenly ending up on a different site can be jarring. External links may open in a new tab or window; non-external links should always stay within the same tab.
|
||||
- _deep links_ go into greater detail than the current page, explaining a topic or option with more specifics. They are called "deep" links because the pages they link to typically exist at a level that is deeper into the site's hierarchical navigation and information architecture. Deep links are commonly introduced with a phrase such as, "For more information about {topic}," or placed in a "See Also" section at the bottom of a page, but that is not always necessary.
|
||||
- _backlinks_ provide background information or context for understanding the current page. They are called "back" links because they typically send readers "back" to shallower levels of the information architecture instead of following the typical progression of knowledge.
|
||||
|
||||
Links can and should be used regularly, but without going overboard. Some additional guidelines:
|
||||
|
||||
- In the first paragraph or even first sentence of any reference page, include a backlink to a concept page that provides more context about when and why that reference may be used.
|
||||
- When using a keyword that may need some explanation, to link the first instance of that keyword back to a concept page that explains it. Don't make every instance of the keyword into a link, which is overkill and distracting, but you may want to link it again if it comes up again in a separate section of the same page, especially if readers are likely to jump ahead to a specific section rather than reading straight through from the first mention to the later one.
|
||||
- On concept pages that are in the shallower parts of the information architecture, use caution when putting deep links into the text body. Readers may interpret these as backlinks, implying that they need additional background reading to understand the current section, interrupting the flow of information from simpler to more advanced. It is OK to use deep links in concepts when introduced with a warning phrase such as "For more information," or when context makes it clear that it is a deep link—for example, when saying that users can use a particular transaction type to accomplish a certain goal, it is appropriate to use a deep link to the transaction type reference documentation.
|
||||
|
||||
## Conventions
|
||||
|
||||
Use the following conventions when creating a page:
|
||||
@@ -101,29 +132,7 @@ Use the following conventions when creating a page:
|
||||
|
||||
### New Features
|
||||
|
||||
When documenting a new feature, include a badge indicating the version of the program when the feature was introduced. The badge tag takes the structure:
|
||||
|
||||
<pre><code>
|
||||
{% badge href="url" date="date of release" %}New in: program version{% /badge%}
|
||||
</code></pre>
|
||||
|
||||
For example, the following badge definition:
|
||||
|
||||
<pre><code>
|
||||
{% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" date="February 18, 2024" %}New in: Clio v2.0.0{% /badge %}
|
||||
</code></pre>
|
||||
|
||||
renders as {% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" date="February 18, 2024" %}New in: Clio v2.0.0{% /badge %}.
|
||||
|
||||
When updating a feature, replace _New in:_ with _Updated in:_. For example, the following badge definition:
|
||||
|
||||
`{% badge href="https://github.com/XRPLF/clio/releases/tag/2.1.0" date="May 4, 2024" %} Updated in: Clio v2.1.0{% /badge %}`
|
||||
|
||||
renders as {% badge href="https://github.com/XRPLF/clio/releases/tag/2.1.0" date="May 4, 2024" %}Updated in: Clio v2.1.0{% /badge %}.
|
||||
|
||||
Some phrases automatically set the color of the badge, or you can add a color parameter such as `color="purple"` to the tag to set the color explicitly.
|
||||
|
||||
It is a best practice to remove any new/updated badges more than 2 years old.
|
||||
When documenting a new feature, include a [badge](./markdoc-tags.md#badge) indicating the version of the program when the feature was introduced. It is a best practice to remove any new/updated badges more than 2 years old.
|
||||
|
||||
### Terminology
|
||||
|
||||
@@ -153,20 +162,60 @@ Use the following words and phrases as described:
|
||||
|
||||
## Frontmatter Fields
|
||||
|
||||
***Note: The details of Realm's frontmatter specification are not fully documented. Update this with a link when Realm exits closed beta.***
|
||||
|
||||
Frontmatter for Markdown files can include details such as the following:
|
||||
|
||||
```yaml
|
||||
---
|
||||
metadata:
|
||||
indexPage: true # Add this if you want the page to contain an auto-generated list of its child pages.
|
||||
indexPage: true # Use if you want to use the {% child-pages /%} macro to display a list of page children
|
||||
seo:
|
||||
description: rippled is the core peer-to-peer server that manages the XRP Ledger. This section covers concepts that help you learn the "what" and "why" behind fundamental aspects of the rippled server.
|
||||
description: Transact with confidence using the XRP Ledger's suite of compliance features for following government regulations and security practices.
|
||||
---
|
||||
```
|
||||
|
||||
Some pages in the site have leftover metadata from the previous (Dactyl) toolchain, such as `html`, `parent`, or `targets` fields. These fields have no effect and can be omitted from new pages.
|
||||
Some pages in the site have leftover metadata from the previous (Dactyl) toolchain, such as `html`, `parent`, or `targets` fields. These fields have no effect and can be removed. For a reference of frontmatter fields that are supported by the current (Redocly) toolchain, see [Front matter configuration options (Realm docs)](https://redocly.com/docs/realm/config/front-matter-config).
|
||||
|
||||
Usually, you should not specify a title in the frontmatter, but you might use the `seo` field's `title` sub-field (see below) for non-Markdown pages or when recommended for search engine optimization.
|
||||
|
||||
### seo.title, default title, and sidebar label
|
||||
|
||||
Every markdown page should have an h1 on the first line of the markdown contents, such as this:
|
||||
|
||||
```
|
||||
# What is XRP?
|
||||
```
|
||||
|
||||
By default, the text of this title is used as the title of the page. You don't need to specify a title separately in the frontmatter, especially since someone might change it in one place and forget to update the other. Sometimes pages have a longer title in the frontmatter's `seo.title` field, for purposes of search engine optimization (SEO). These titles are usually longer and optimized to include phrases or search terms that are likely to match queries people might type while looking for the page. **Titles in the frontmatter should only be used when recommended for SEO.** For example:
|
||||
|
||||
```
|
||||
---
|
||||
seo:
|
||||
title: What is XRP and Why is it Valuable?
|
||||
---
|
||||
```
|
||||
|
||||
A third place a page might have a title is in a `label` field in the `sidebars.yaml` file. This should always come with a translation key in the `labelTranslationKey` field. Labels in the `sidebars.yaml` file should only be used in these cases:
|
||||
|
||||
- To provide a translatable title for a `.page.tsx` file.
|
||||
- To shorten an SEO title so that it fits better in the sidebar. In this case, the label contents should match the original h1 title.
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
- page: docs/introduction/what-is-xrp.md
|
||||
label: What is XRP?
|
||||
labelTranslationKey: sidebar.docs.introduction.what-is-xrp
|
||||
```
|
||||
|
||||
For reference, here's the hierarchy that determines which title gets used where:
|
||||
|
||||
| Location | Which title it uses |
|
||||
|----------|---------------------|
|
||||
| `<title>` element (the text that displays in the tab name and the title bar of your browser, if it has one) | `seo.title`, falling back to md h1 |
|
||||
| `<meta name="title" ...>`, `<meta name="og:title" ...>`, `<meta name="twitter:title" ...>` and so on in the `<head>` of the page, which are used when "unfurling" a link (showing a preview) in various chat and social media apps like Discord, Slack, or X (Twitter) | `seo.title`, falling back to md h1 |
|
||||
| Sidebar navigation | `label` from `sidebars.yaml`, then `seo.title`, and finally md h1 |
|
||||
| In-page header, that is, the big text in the center column | md h1 only |
|
||||
|
||||
|
||||
### Next and Previous Buttons
|
||||
|
||||
@@ -188,9 +237,9 @@ Store your graphics in the `/docs/img` directory. Embed graphics using the synta
|
||||
|
||||
``
|
||||
|
||||
For example, `` renders as follows.
|
||||
For example, `` renders as follows.
|
||||
|
||||
|
||||
|
||||
|
||||
## Videos
|
||||
|
||||
@@ -220,71 +269,44 @@ referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
|
||||
|
||||
## Tables
|
||||
|
||||
Markdoc provides three different syntax styles for generating tables.
|
||||
Use Markdown tables liberally. Tables are a good way to convey possible options, especially in reference documentation.
|
||||
|
||||
In most cases, create tables using the pipe character (|) to separate columns and three or more hyphens (---) to create the column headers.
|
||||
|
||||
```
|
||||
| | Head 1 |
|
||||
| ------- | ------ |
|
||||
| Label 1 | Val 1 |
|
||||
```
|
||||
|
||||
This code renders as follows.
|
||||
|
||||
| | Head 1 |
|
||||
| ------- | ------ |
|
||||
| Label 1 | Val 1 |
|
||||
|
||||
The cells do not have to be the same width. The renderer aligns the columns and wraps text as needed, as shown.
|
||||
The GitHub Flavored Markdown syntax uses the pipe character (|) to separate columns and three or more hyphens (---) to create the column headers. For example:
|
||||
|
||||
```
|
||||
| Key | Value |
|
||||
| --- | ----- |
|
||||
|-----|-------|
|
||||
| Name | H. G. Wells |
|
||||
| Genre | Science Fiction |
|
||||
| Hyperbole | The greatest story ever told! No one has ever written anything more important than this Victorian era classic. Oh, how swells the heart to ponder the heady philosophies introduced therein! |
|
||||
```
|
||||
|
||||
This table displays as follows:
|
||||
|
||||
| Key | Value |
|
||||
| --- | ----- |
|
||||
|-----|-------|
|
||||
| Name | H. G. Wells |
|
||||
| Genre | Science Fiction |
|
||||
| Hyperbole | The greatest story ever told! No one has ever written anything more important than this Victorian era classic. Oh, how swells the heart to ponder the heady philosophies introduced therein! |
|
||||
|
||||
Use colons in the heading lines to align columns left (:--), middle (:-:), or right (--:).
|
||||
The cells do not have to be the same width. The renderer aligns the columns and wraps text as needed. However, it is often helpful for editors if you align the columns of the table in the markdown source file.
|
||||
|
||||
Optionally, use colons in the heading lines to align columns left (:--), middle (:-:), or right (--:). For example:
|
||||
|
||||
```
|
||||
| Model | Color | Price |
|
||||
| :-: | :-- | --: |
|
||||
|:--------:|:------|------:|
|
||||
| Protexra | Electric Blue | 50,000 XRP |
|
||||
| Joatic | Hot Pink | 165,000 XRP |
|
||||
| Zhanu | Neon Green | 234,000 XRP |
|
||||
```
|
||||
|
||||
| Model | Color | Price |
|
||||
| :-: | :-- | --: |
|
||||
|:--------:|:------|------:|
|
||||
| Protexra | Electric Blue | 50,000 XRP |
|
||||
| Joatic | Hot Pink | 165,000 XRP |
|
||||
| Zhanu | Impetuous Green | 1,728,000 XRP |
|
||||
| Zhanu | Neon Green | 234,000 XRP |
|
||||
|
||||
The left column is bold by default. If you don't want a bold label in the left column, you can use an empty left column and start your table one column over.
|
||||
|
||||
```
|
||||
| | French | English | German |
|
||||
| --- | --- | --- | --- |
|
||||
| | Fromage | Cheese | Käse |
|
||||
| | Maux d'estomac | Stomach ache | Magenschmerzen |
|
||||
| | Cornichon | Pickle | Essiggurke |
|
||||
```
|
||||
|
||||
| | French | English | German |
|
||||
| --- | --- | --- | --- |
|
||||
| | Fromage | Cheese | Käse |
|
||||
| | Maux d'estomac | Stomach ache | Magenschmerzen |
|
||||
| | Cornichon | Pickle | Essiggurke |
|
||||
|
||||
Use these basic tables whenever possible. If you genuinely require special formatting not provided by the examples above, you can create a table using HTML syntax.
|
||||
|
||||
## Links
|
||||
|
||||
@@ -306,11 +328,11 @@ To make it easier to link to pages that are commonly cited, you can add a `{% ra
|
||||
|
||||
Format method names and other code structures inline enclosing the code in backtick (`) characters. For example:
|
||||
|
||||
My favorite method ever is `nft_info`.
|
||||
> My favorite method ever is `nft_info`.
|
||||
|
||||
renders as
|
||||
|
||||
My favorite method ever is `nft_info`.
|
||||
> My favorite method ever is `nft_info`.
|
||||
|
||||
For longer code blocks, use three backtics (```) followed by the language name. Type a return, and enter the sample code. At the end of your code sample, type a return and close the block again with three backticks (```).
|
||||
|
||||
@@ -338,123 +360,10 @@ renders as
|
||||
})
|
||||
```
|
||||
|
||||
## Markdoc Components
|
||||
## Markdoc Tags
|
||||
|
||||
The files are processed with [Markdoc](https://markdoc.dev/), which means they can contain special tags in `{% ... %}` syntax. In addition to Redocly's built-in tags, this repository has some custom tags defined in `/@theme/markdoc/`.
|
||||
|
||||
### Badges
|
||||
|
||||
See [New Features](#new-features).
|
||||
|
||||
### Partials
|
||||
|
||||
If you have text that you use frequently, or text that requires periodic update in a number of places in the documentation, you can create a _snippet file for reuse.
|
||||
|
||||
Store your file in the `_snippet` directory. To insert the partial file, use the syntax `{% partial file="<file url>" /%}`.
|
||||
|
||||
For example, here is the snippet `/docs/_snippets/secret-key-warning.md`.
|
||||
|
||||
<blockquote>
|
||||
{% admonition type="warning" name="Caution" %}<br/>
|
||||
Never submit a secret key to a server you do not control. Do not send a secret key unencrypted over the network.<br/>
|
||||
{% /admonition %}
|
||||
</blockquote>
|
||||
|
||||
To embed the text, use the tag `{% partial file="/docs/_snippets/secret-key-warning.md" /%}`.
|
||||
|
||||
For example:
|
||||
|
||||
<blockquote>
|
||||
There I was, happy as a lark, skipping through the daisies, when I shyly handed my secret
|
||||
key to my one true love.
|
||||
|
||||
{% partial file="/docs/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
Alas, if only I had heeded that sage advice, I would not rue the day as I do today.
|
||||
</blockquote>
|
||||
|
||||
renders as:
|
||||
|
||||
<blockquote>
|
||||
There I was, happy as a lark, skipping through the daisies, when I shyly handed my secret key to my one true love.
|
||||
|
||||
{% partial file="/docs/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
Alas, if only I had heeded that sage advice, I would not rue the day as I do today.
|
||||
</blockquote>
|
||||
|
||||
### Not-Enabled Badge
|
||||
|
||||
The `{% not-enabled /%}` Markdoc component displays a yellow flask icon with a tooltip about how the feature is not available on the production XRP Ledger. Use this when discussing amendments that are open for voting but not currently enabled. Example: {% not-enabled /%}
|
||||
|
||||
This tag is self-closing, and it takes no parameters.
|
||||
|
||||
### Repo Link
|
||||
|
||||
This tag links to a particular file in the source code repository for this site, usually a code sample. For example:
|
||||
|
||||
<pre><code>
|
||||
{% repo-link path="_code-samples/build-a-desktop-wallet/js/1_ledger-index.js" %}`1-ledger-index/index.js`{% /repo-link %}
|
||||
</code></pre>
|
||||
|
||||
becomes: {% repo-link path="_code-samples/build-a-desktop-wallet/js/1_ledger-index.js" %}`1-ledger-index/index.js`{% /repo-link %}
|
||||
|
||||
If you are working from a fork or branch of the site, all such links can be updated at once with a site configuration change.
|
||||
|
||||
|
||||
### Try It
|
||||
|
||||
The `{% try-it ... /%}` Markdoc tag provides a convenient shortcut for linking to the WebSocket tool as a button. This tag is self-closing.
|
||||
Example:
|
||||
|
||||
{% try-it method="account_currencies" server="testnet" /%}
|
||||
|
||||
Example syntax:
|
||||
|
||||
<pre><code>
|
||||
{% try-it method="account_currencies" server="testnet" /%}
|
||||
</code></pre>
|
||||
|
||||
The text of the button is normally "Try it!" in English, and can be translated by setting the `component.tryit` key in the localization's `translations.yaml` file.
|
||||
|
||||
This tag takes the following parameters:
|
||||
|
||||
| Parameter | Required? | Description |
|
||||
|---|---|---|
|
||||
| `method` | Yes | The ID of the anchor to use on the WebSocket Tool page. For most WebSocket API methods, this is the API method exactly, but it could contain more. For example, different `ledger_entry` variations use a suffix like `ledger_entry-nft-page`. If you are documenting a new method, you must also add that method to the WebSocket tool by editing `/resources/dev-tools/components/websocket-api/data/command-list.json`. |
|
||||
| `server` | No | A specific server to use for the request. You may want to specify the server if a method is specific to Clio or `rippled` servers, or if the example uses data or amendments that are only on a specific test network. |
|
||||
|
||||
The values you can provide to the `server` parameter are as follows:
|
||||
|
||||
| `server` value | Server to use |
|
||||
|---|---|
|
||||
| (Omitted) | The WebSocket tool's default server (currently `s1.ripple.com`) |
|
||||
| `s1` | Ripple's `s1.ripple.com` Mainnet public cluster, typically served by Clio servers. |
|
||||
| `s2` | Ripple's `s2.ripple.com` Mainnet full-history public cluster, typically served by Clio servers. |
|
||||
| `xrplcluster` | The `xrplcluster.com` cluster of public servers, typically served by `rippled` servers with a lightweight proxy in front. |
|
||||
| `devnet` | The `s.altnet.rippletest.net` cluster of Testnet servers. |
|
||||
| `testnet` | The `s.devnet.rippletest.net` cluster of Devnet servers. |
|
||||
|
||||
### Tx Example
|
||||
|
||||
The `{% tx-example ... /%}` Markdoc tag provides a convenient shortcut for linking to the WebSocket tool as a button with a body pre-filled to look up a specific example transaction. This tag is self-closing. Example:
|
||||
|
||||
{% tx-example txid="1AF19BF9717DA0B05A3BFC5007873E7743BA54C0311CCCCC60776AAEAC5C4635" /%}
|
||||
|
||||
Example syntax:
|
||||
|
||||
<pre><code>
|
||||
{% tx-example txid="1AF19BF9717DA0B05A3BFC5007873E7743BA54C0311CCCCC60776AAEAC5C4635" /%}
|
||||
</code></pre>
|
||||
|
||||
The text of the button is normally "Query example transaction" in English, and can be translated by setting the `component.queryexampletx` key in the localization's `translations.yaml` file.
|
||||
|
||||
This tag takes the following parameters:
|
||||
|
||||
| Parameter | Required? | Description |
|
||||
|---|---|---|
|
||||
| `txid` | Yes | The unique hash of the transaction to look up. |
|
||||
| `server` | No | A specific server to use for the request. Possible values are the same as `{% try-it %}` as defined above. For example, you may need to specify `devnet` to show a transaction added by an amendment that isn't enabled on Mainnet. |
|
||||
The files are processed with [Markdoc](https://markdoc.dev/), which means they can contain special tags in `{% ... %}` syntax. In addition to Redocly's built-in tags, this repository has some custom tags. For details on markdoc tags and their usage, see [Markdoc Tags](./markdoc-tags.md).
|
||||
|
||||
## More Contributor Documentation
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
265
resources/contribute-documentation/markdoc-tags.md
Normal file
265
resources/contribute-documentation/markdoc-tags.md
Normal file
@@ -0,0 +1,265 @@
|
||||
---
|
||||
seo:
|
||||
description: Read about all the Markdoc tags commonly used in XRPL documentation, including custom tags.
|
||||
---
|
||||
# Markdoc Tags
|
||||
|
||||
This page serves as a reference of the [Markdoc tags](https://redocly.com/docs/realm/content/markdoc-tags/tag-library) used in XRPL documentation. These extensions of Markdown syntax allow for stylized and dynamic contents.
|
||||
|
||||
When using self-closing tags, be sure to include the closing slash in the tag definition. Otherwise, content after the unclosed tag will not be displayed.
|
||||
|
||||
## Redocly Built-In Tags
|
||||
|
||||
This section describes the Redocly built-in tags that XRPL documentation uses most often and the conventions for using them in the site.
|
||||
|
||||
|
||||
### Admonition
|
||||
|
||||
Show text in a colored box that stands out from regular paragraphs, sometimes referred to as a _callout_. There are four levels of admonition with escalating levels of severity. You can put any text in the `name` attribute, but there are recommended names for each category that can be automatically translated. For historical reasons, the recommended names do not align cleanly with the `type` options. The recommended names are:
|
||||
|
||||
| `type` | Color | Recommended `name` | Usage |
|
||||
|-----------|---------------|--------------------|-------|
|
||||
| `success` | Green | `Tip` | Optional, additional information, shortcuts, and cases where people might think there's a problem but there actually isn't. |
|
||||
| `info` | Blue | `Note` | Quirks, background information, or other details that are not critical but may be good to know. |
|
||||
| `warning` | Yellow/Orange | `Caution` | Common mistakes, misunderstandings, or limitations that may cause confusion and inconvenience. |
|
||||
| `danger` | Red/Magenta | `Warning` | Mistakes or risks that may cause financial loss, security incidents, or other substantial problems. |
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% admonition type="success" name="Tip" %}
|
||||
Admonitions create colored boxes that stand out from regular paragraphs.
|
||||
{% /admonition %}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% admonition type="success" name="Tip" %}
|
||||
Admonitions create colored boxes that stand out from regular paragraphs.
|
||||
{% /admonition %}
|
||||
|
||||
It is valid to put an admonition's opening and closing tags all on the same line as its contents. To avoid a Redocly bug, make sure multi-line admonitions have their opening and closing tags on separate lines.
|
||||
|
||||
### Inline SVG
|
||||
|
||||
Include an image in SVG format inline in the page's markup. This allows the diagram's color scheme to adapt to the user's current (light/dark) theme. Typically, you should use the tag inside a link that opens the SVG file as a stand-alone image so the user can view it and zoom in or out as needed. For tips on making diagrams compatible with this feature, see [Creating Diagrams](./creating-diagrams.md). This tag is self-closing.
|
||||
|
||||
Example usage:
|
||||
<pre><code>
|
||||
[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Figure 1: Anatomy of a ledger version, which includes transactions, state, and metadata")
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
[{% inline-svg file="/docs/img/anatomy-of-a-ledger-simplified.svg" /%}](/docs/img/anatomy-of-a-ledger-simplified.svg "Figure 1: Anatomy of a ledger version, which includes transactions, state, and metadata")
|
||||
|
||||
|
||||
### Partial and Raw Partial
|
||||
|
||||
Include text from another, reusable file, called a _snippet_. Unlike environment variables, partials are typically an entire paragraph or more. If text needs to be updated in multiple places, you can use this component to reuse a single file's contents in multiple places. Store the source file in the `docs/_snippets/` directory. This tag is self-closing.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% partial file="/docs/_snippets/secret-key-warning.md" /%}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% partial file="/docs/_snippets/secret-key-warning.md" /%}
|
||||
|
||||
Links and markup inside snippets are parsed separately before being added to the including file. Relative links are resolved based on the location of the snippet, not on the file including it. To include a snippet that resolves its contents in the context of the including page instead, include the file as a raw partial instead. This is useful when you want the partial to refer to the name of the page that included it, or if it defines common links used throughout the site.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
</code></pre>
|
||||
|
||||
|
||||
### Variables
|
||||
|
||||
Include the contents of a predefined variable, inline in the document. Unlike partials, these are typically only a few words at most. Common use cases include `{% $frontmatter.seo.title %}` for referring to the title of the current page (used in some templates and snippets), and environment variables for the current reserve amounts on the XRP Ledger Mainnet.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
Each NFToken page requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}.
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
Each NFToken page requires a reserve of {% $env.PUBLIC_OWNER_RESERVE %}.
|
||||
|
||||
{% admonition type="warning" name="Caution" %}Variable references are like self-closing tags, but they don't use a slash like self-closing tags should (`/%}`).{%/admonition%}
|
||||
|
||||
|
||||
|
||||
|
||||
## Custom Tags
|
||||
|
||||
Markdown supports creating custom tags with user-defined functionality. This repository defines several such tags for convenience in editing, as follows.
|
||||
|
||||
|
||||
### Amendment Disclaimer
|
||||
|
||||
Show a disclaimer that functionality is based on an amendment to the XRP Ledger protocol, which updates live with the status of the amendment on Mainnet. The `name` parameter is required and is case-sensitive. This tag is self-closing.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% amendment-disclaimer name="Credentials" /%}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% amendment-disclaimer name="Credentials" /%}
|
||||
|
||||
When the amendment is not enabled on Mainnet, the component adds a paragraph that says, "Requires the (name) amendment," with a badge showing the amendment's voting percentage. After the amendment is enabled, the paragraph changes to say, "Added by the (name) amendment," with a badge showing the date the amendment became enabled.
|
||||
|
||||
The `compact=true` parameter (note, it is an error to put true in quotation marks here) displays only the name of the amendment and the status badge.
|
||||
|
||||
The `mode="updated"` parameter (case-sensitive) changes the paragraph so that it says, "The (name) amendment updates this," before the amendment is enabled, and "Updated by the (name) amendment," afterward, with the same badges.
|
||||
|
||||
|
||||
### Badge
|
||||
|
||||
Show a colored inline badge. Use these to point out new or updated features, especially in the API, that are not tied to an amendment. The contents are the text of the badge; the left and right halves are split by the `:` character in the text.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" date="February 18, 2024" %}New in: Clio 2.0.0{% /badge %}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% badge href="https://github.com/XRPLF/clio/releases/tag/2.0.0" date="February 18, 2024" %}New in: Clio 2.0.0{% /badge %}
|
||||
|
||||
The `date` parameter is optional, and is not displayed. It is helpful to remind editors when a change is old enough to remove the badge.
|
||||
|
||||
When updating a feature, replace _New in:_ with _Updated in:_. These and certain other phrases automatically set the color of the badge and can be automatically translated. If necessary, you can add a color parameter such as `color="purple"` to the tag to set the color explicitly.
|
||||
|
||||
### Card Grid and XRPL Card
|
||||
|
||||
Create a grid of cards with specific links and icons. By default, the grid is 3 cards wide on desktop and 1 card wide on mobile. The contents of the card grid should only be `xrpl-card` tags. The `xrpl-card` tag is self-closing.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% card-grid %}
|
||||
{% xrpl-card title="Javascript" body="Using the xrpl.js client library." href="/docs/tutorials/javascript/" image="/img/logos/javascript.svg" imageAlt="Javascript logo" /%}
|
||||
{% xrpl-card title="Python" body="Using xrpl.py, a pure Python library." href="/docs/tutorials/python/" image="/img/logos/python.svg" imageAlt="Python logo" /%}
|
||||
{% /card-grid %}
|
||||
</pre></code>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% card-grid %}
|
||||
{% xrpl-card title="Javascript" body="Using the xrpl.js client library." href="/docs/tutorials/javascript/" image="/img/logos/javascript.svg" imageAlt="Javascript logo" /%}
|
||||
{% xrpl-card title="Python" body="Using xrpl.py, a pure Python library." href="/docs/tutorials/python/" image="/img/logos/python.svg" imageAlt="Python logo" /%}
|
||||
{% /card-grid %}
|
||||
|
||||
|
||||
### Child Pages
|
||||
|
||||
Show a bulleted list of pages that are children of the page using this tag. The descriptions of the pages use the frontmatter's `seo.description` field. This tag is self-closing and takes no parameters.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% child-pages /%}
|
||||
</code></pre>
|
||||
|
||||
This tag only works if you include the following data in the page's frontmatter:
|
||||
|
||||
```
|
||||
metadata:
|
||||
indexPage: true
|
||||
```
|
||||
|
||||
|
||||
### Not Enabled
|
||||
|
||||
Display a yellow flask icon with a tooltip about how the feature is not available on the production XRP Ledger. Usually, you should use an [amendment-disclaimer](#amendment-disclaimer) instead, but there may be edge cases where you want to include this icon. This tag is self-closing and takes no parameters.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% not-enabled /%}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% not-enabled /%}
|
||||
|
||||
|
||||
### Repo Link
|
||||
|
||||
Link to a particular file in the source code repository for this site, usually a code sample. If you are working from a fork or branch of the site, all such links can be updated at once with a site configuration change. The contents are the text of the link.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% repo-link path="_code-samples/build-a-desktop-wallet/js/1_ledger-index.js" %}`1-ledger-index/index.js`{% /repo-link %}
|
||||
</code></pre>
|
||||
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% repo-link path="_code-samples/build-a-desktop-wallet/js/1_ledger-index.js" %}`1-ledger-index/index.js`{% /repo-link %}
|
||||
|
||||
|
||||
### Try It
|
||||
|
||||
Link to the WebSocket tool as a button. The text of the button is normally "Try it!" in English, and can be translated by setting the `component.tryit` key in the localization's `translations.yaml` file. This tag is self-closing.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% try-it method="account_currencies" server="testnet" /%}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% try-it method="account_currencies" server="testnet" /%}
|
||||
|
||||
This tag takes the following parameters:
|
||||
|
||||
| Parameter | Required? | Description |
|
||||
|---|---|---|
|
||||
| `method` | Yes | The ID of the anchor to use on the WebSocket Tool page. For most WebSocket API methods, this is the API method exactly, but it could contain more. For example, different `ledger_entry` variations use a suffix like `ledger_entry-nft-page`. If you are documenting a new method, you must also add that method to the WebSocket tool by editing `/resources/dev-tools/components/websocket-api/data/command-list.json`. |
|
||||
| `server` | No | A specific server to use for the request. You may want to specify the server if a method is specific to Clio or `rippled` servers, or if the example uses data or amendments that are only on a specific test network. |
|
||||
|
||||
The values you can provide to the `server` parameter are as follows:
|
||||
|
||||
| `server` value | Server to use |
|
||||
|---|---|
|
||||
| (Omitted) | The WebSocket tool's default server (currently `s1.ripple.com`) |
|
||||
| `s1` | Ripple's `s1.ripple.com` Mainnet public cluster, typically served by Clio servers. |
|
||||
| `s2` | Ripple's `s2.ripple.com` Mainnet full-history public cluster, typically served by Clio servers. |
|
||||
| `xrplcluster` | The `xrplcluster.com` cluster of public servers, typically served by `rippled` servers with a lightweight proxy in front. |
|
||||
| `devnet` | The `s.altnet.rippletest.net` cluster of Testnet servers. |
|
||||
| `testnet` | The `s.devnet.rippletest.net` cluster of Devnet servers. |
|
||||
|
||||
|
||||
### Tx Example
|
||||
|
||||
Link to the WebSocket tool, as a button, with a body pre-filled to look up a specific example transaction. The text of the button is normally "Query example transaction" in English, and can be translated by setting the `component.queryexampletx` key in the localization's `translations.yaml` file. This tag is self-closing.
|
||||
|
||||
Example usage:
|
||||
|
||||
<pre><code>
|
||||
{% tx-example txid="1AF19BF9717DA0B05A3BFC5007873E7743BA54C0311CCCCC60776AAEAC5C4635" /%}
|
||||
</code></pre>
|
||||
|
||||
Demonstration:
|
||||
|
||||
{% tx-example txid="1AF19BF9717DA0B05A3BFC5007873E7743BA54C0311CCCCC60776AAEAC5C4635" /%}
|
||||
|
||||
This tag takes the following parameters:
|
||||
|
||||
| Parameter | Required? | Description |
|
||||
|---|---|---|
|
||||
| `txid` | Yes | The unique hash of the transaction to look up. |
|
||||
| `server` | No | A specific server to use for the request. Possible values are the same as `{% try-it %}` as defined above. For example, you may need to specify `devnet` to show a transaction added by an amendment that isn't enabled on Mainnet. |
|
||||
@@ -31,6 +31,14 @@
|
||||
"faucetHost": "batch.faucet.nerdnest.xyz",
|
||||
"shortName": "Batch-Devnet",
|
||||
"desc": "Preview of XLS-56d Batch transactions."
|
||||
},
|
||||
{
|
||||
"id": "faucet-select-lending-devnet",
|
||||
"wsUrl": "wss://lend.devnet.rippletest.net:51233/",
|
||||
"jsonRpcUrl": "https://lend.devnet.rippletest.net:51234/",
|
||||
"faucetHost": "lend-faucet.devnet.rippletest.net",
|
||||
"shortName": "Lending-Devnet",
|
||||
"desc": "Preview of XLS-66d Lending Protocol"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
@@ -757,6 +757,7 @@
|
||||
external: true
|
||||
- page: resources/contribute-documentation/documentation-translations.md
|
||||
- page: resources/contribute-documentation/creating-diagrams.md
|
||||
- page: resources/contribute-documentation/markdoc-tags.md
|
||||
- page: resources/contribute-documentation/tutorial-guidelines.md
|
||||
- page: resources/contribute-documentation/tutorial-structure.md
|
||||
- page: resources/contribute-blog/index.md
|
||||
|
||||
BIN
static/img/events/hackathon-kaigi.png
Normal file
BIN
static/img/events/hackathon-kaigi.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 233 KiB |
Reference in New Issue
Block a user