tokens and accounts

content/concepts/accounts/account-creating.md

@@ -1,3 +1,10 @@
+---
+html: account-creating.html
+parent: accounts.html
+blurb: Create an account by sending a minimum reserve amount to a valid address.
+labels:
+  - Accounts
+---
 # Creating Accounts
 
 There is not a dedicated "create account" transaction. The `Payment` transaction automatically creates a new account if a payment sends XRP equal to or greater than the account reserve to a mathematically valid address that does not already have an account. This is called _funding_ an account, and creates an AccountRoot object in the ledger. No other transaction can create an account.

content/concepts/accounts/account-deleting.md

@@ -1,3 +1,10 @@
+---
+html: account-deleting.html
+parent: accounts.html
+blurb: Delete an account by fulfilling several requirements.
+labels:
+  - Accounts
+---
 # Deleting Accounts
 
 The DeletableAccounts amendment (enabled 2020-05-08) made it possible to delete accounts.

content/concepts/accounts/account-structure.md

@@ -1,3 +1,10 @@
+---
+html: account-structure.html
+parent: accounts.html
+blurb: The core elements of an account.
+labels:
+  - Accounts
+---
 # Account Structure
 
 The core elements of an account are:

content/concepts/accounts/account-types.md

@@ -1,3 +1,10 @@
+---
+html: account-types.html
+parent: accounts.html
+blurb: Common account types include issuing accounts, standby accounts, and operational accounts.
+labels:
+  - Accounts
+---
 # Account Types
 
 In the XRP Ledger, financial institutions typically use multiple XRP Ledger accounts to minimize the risk associated with a compromised secret key. The industry standard is to separate roles as follows:
@@ -48,9 +55,8 @@ If a standby account is compromised, the consequences are like an operational ac
 
 When a token issuer follows this separation of roles, funds tend to flow in specific directions, as in the following diagram:
 
-<!--
-{{ include_svg("../../../img/issued-currency-funds-flow.svg", "Diagram: Funds flow from the issuing account to standby accounts, to operational accounts, to customer and partner accounts, and finally back to the issuing account.")}}
--->
+
+{{ include_svg("img/issued-currency-funds-flow.svg", "Diagram: Funds flow from the issuing account to standby accounts, to operational accounts, to customer and partner accounts, and finally back to the issuing account.")}}
 
 The issuing account creates tokens by sending payments to standby accounts. These tokens have negative value from the perspective of the issuing account, since they (often) represent obligations. The same tokens have positive value from other perspectives, including from the perspective of a standby account.
 

content/concepts/accounts/accounts.md

@@ -8,21 +8,3 @@ labels:
 # Accounts
 
 An "Account" in the XRP Ledger represents a holder of XRP and a sender of transactions.
-
-## Account Structure
-
-The core elements of an account are:
-
-- An identifying **address**, such as `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`.
-- An **XRP balance**. Some of this XRP is set aside for the account reserve.
-- A **sequence number**, which helps make sure any transactions this account sends are applied in the correct order and only once. To execute a transaction, the transaction's sequence number and its sender's sequence number must match. Then, as part of applying the transaction, the account's sequence number increases by 1.
-- A **history of transactions** that affected this account and its balances.
-- One or more ways to authorize transactions, possibly including:
-    - A master key pair intrinsic to the account. (This can be disabled, but not changed.)
-    - A "regular" key pair that can be rotated.
-    - A signer list for multi-signing. (Stored separately from the account's core data.)
-
-In the ledger's data tree, an account's core data is stored in the AccountRoot ledger object type. An account can also be the owner (or partial owner) of several other types of data.
-
-**Tip:** An "Account" in the XRP Ledger is somewhere between the financial usage (like "bank account") and the computing usage (like "UNIX account"). Non-XRP currencies and assets are not stored in an XRP Ledger Account itself; each such asset is stored in an accounting relationship called a "Trust Line" that connects two parties.
-

content/concepts/accounts/addresses.md

@@ -1,4 +1,11 @@
-## Addresses
+---
+html: addresses.html
+parent: accounts.html
+blurb: Accounts in the XRP Ledger are identified by an address in the XRP Ledger's base58 format.
+labels:
+  - Accounts
+---
+# Addresses
 
 Accounts in the XRP Ledger are identified by an address in the XRP Ledger's base58 format. The address is derived from the account's master [public key](https://en.wikipedia.org/wiki/Public-key_cryptography), which is in turn derived from a secret key. An address is represented as a string in JSON and has the following characteristics:
 
@@ -13,7 +20,7 @@ Accounts in the XRP Ledger are identified by an address in the XRP Ledger's base
 > The XRP Ledger protocol only supports "classic" addresses natively, but many client libraries support X-addresses too.
 
 
-For more information, see [Accounts](accounts.md).
+For more information, see [Accounts](accounts.html).
 
 
 Any valid address can become an account in the XRP Ledger by being funded. You can also use an address that has not been funded to represent a regular key or a member of a signer list. Only a funded account can be the sender of a transaction.

content/concepts/accounts/balances.md

@@ -1,3 +0,0 @@
-# Balances
-
-Placeholder for details of the account balances.

content/concepts/accounts/cryptographic-keys.md

@@ -1,3 +1,10 @@
+---
+html: cryptographic-keys.html
+parent: accounts.html
+blurb: To make a digital signature, you use a cryptographic key pair associated with the transaction's sending account.
+labels:
+  - Accounts
+---
 # Cryptographic Keys
 
 In the XRP Ledger, a digital signature _authorizes_ a [transaction](../transactions/transactions.md) to do a specific set of actions. Only signed transactions can be submitted to the network and included in a validated ledger.
@@ -8,7 +15,7 @@ To make a digital signature, you use a cryptographic key pair associated with th
 
 ## Generating Keys
 
-Many [client libraries](../../../references/client-libraries.md) and applications can generate a key pair suitable for use with the XRP Ledger. However, you should only use keypairs that were generated with devices and software you trust. Compromised applications can expose your secret to malicious users who can then send transactions from your account later.
+Many [client libraries](client-libraries.html) and applications can generate a key pair suitable for use with the XRP Ledger. However, you should only use keypairs that were generated with devices and software you trust. Compromised applications can expose your secret to malicious users who can then send transactions from your account later.
 
 
 ## Key Components
@@ -17,7 +24,7 @@ A cryptographic key pair is a **private key** and a **public key** that are conn
 
 When dealing with the XRP Ledger, you may also use some related values such as a passphrase, seed, account ID, or address.
 
-{{ include_svg("../../../img/cryptographic-keys.svg", "Diagram: Passphrase → Seed → Private Key → Public Key → Account ID ←→ Address") }}
+{{ include_svg("img/cryptographic-keys.svg", "Diagram: Passphrase → Seed → Private Key → Public Key → Account ID ←→ Address") }}
 _Figure: A simplified view of the relationship between cryptographic key values._
 
 
@@ -37,7 +44,7 @@ The passphrase is secret information, so you must protect it very carefully. Any
 
 ### Seed
 
-A _seed_ value is a compact value that is used to derive the actual private and public keys for an account. In a `wallet_propose` method response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to sign transactions in the rippled APIs and some [other XRP Ledger software](../xrpl/xrpl-ecosystem.md). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
+A _seed_ value is a compact value that is used to derive the actual private and public keys for an account. In a `wallet_propose` method response, the `master_key`, `master_seed`, and `master_seed_hex` all represent the same seed value, in various formats. Any of these formats can be used to sign transactions in the rippled APIs and some [other XRP Ledger software](xrpl-ecosystem.html). Despite being prefixed with `master_`, the keys this seed represents are not necessarily the master keys for an account; you can use a key pair as a regular key or a member of a multi-signing list as well.
 
 The seed value is secret information, so you must protect it very carefully. Anyone who has knows an address's seed value has effectively full control over that address.
 
@@ -98,11 +105,11 @@ Keeping your master key pair offline means not putting the secret information (p
 
 - Disable the master key pair.
 
-- Permanently give up the ability to [freeze](../tokens/freezing-tokens.md#no-freeze).
+- Permanently give up the ability to [freeze](freezing-tokens.html#no-freeze).
 
 - Send a special key reset transaction with a transaction cost of 0 XRP.
 
-A regular key or multi-signature can do anything else the same as the master key pair. Notably, after you have disabled the master key pair, you can re-enable it using a regular key pair or multi-signature. You can also [delete an account](account-deleting.md) if it meets the requirements for deletion.
+A regular key or multi-signature can do anything else the same as the master key pair. Notably, after you have disabled the master key pair, you can re-enable it using a regular key pair or multi-signature. You can also [delete an account](account-deleting.html) if it meets the requirements for deletion.
 
 
 ## Regular Key Pair
@@ -181,7 +188,7 @@ The key derivation processes described here are implemented in multiple places a
 ### secp256k1 Key Derivation
 [[Source]](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/SecretKey.cpp "Source")
 
-{{ include_svg("../../../img/key-derivation-secp256k1.svg", "Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair") }}
+{{ include_svg("img/key-derivation-secp256k1.svg", "Passphrase → Seed → Root Key Pair → Intermediate Key Pair → Master Key Pair") }}
 
 Key derivation for secp256k1 XRP Ledger account keys involves more steps than Ed25519 key derivation for a couple reasons:
 
@@ -237,7 +244,7 @@ The steps to derive the XRP Ledger's secp256k1 account key pair from a seed valu
 
 6. When serializing an account's public key to its base58 format, use the account public key prefix, `0x23`.
 
-    See [Address Encoding](addresses.md#address-encoding) for information and sample code to convert from an account's public key to its address.
+    See [Address Encoding](addresses.html#address-encoding) for information and sample code to convert from an account's public key to its address.
 
 <!--
 

content/concepts/accounts/deposit-authorization.md

@@ -1,8 +1,15 @@
+---
+html: deposit-authorization.html
+parent: accounts.html
+blurb: Deposit Authorization can block all transfers from strangers, including transfers of XRP and tokens.
+labels:
+  - Accounts
+---
 # Deposit Authorization
 
 _(Added by the DepositAuth amendment.)_
 
-Deposit Authorization is an optional [account](accounts.md) setting in the XRP Ledger. If enabled, Deposit Authorization blocks all transfers from strangers, including transfers of XRP and [tokens](../tokens/tokens.md). An account with Deposit Authorization can only receive value in two ways:
+Deposit Authorization is an optional account setting in the XRP Ledger. If enabled, Deposit Authorization blocks all transfers from strangers, including transfers of XRP and [tokens](tokens.html). An account with Deposit Authorization can only receive value in two ways:
 
 - From accounts it has [preauthorized](#preauthorization).
 - By sending a transaction to receive the funds. For example, an account with Deposit Authorization could finish an escrow that was initiated by a stranger.

content/concepts/accounts/history.md

@@ -1,3 +0,0 @@
-# History
-
-Placeholder for details of account history.

content/concepts/accounts/reserves.md

@@ -1,3 +1,10 @@
+---
+html: reserves.html
+parent: accounts.html
+blurb: Reserves are the minimum balance of XRP that an account must maintain.
+labels:
+  - Accounts
+---
 # Reserves
 
 The XRP Ledger applies _reserve requirements_, in XRP, to protect the shared global ledger from growing excessively large as the result of spam or malicious usage. The goal is to constrain the growth of the ledger to match improvements in technology so that a current commodity-level machine can always fit the current ledger in RAM.

content/concepts/accounts/sequence.md

@@ -1,3 +0,0 @@
-# Sequence
-
-Placeholder for details of sequence with regard to account transactions.

content/concepts/tokens/authorized-trust-lines.md

@@ -1,3 +1,10 @@
+---
+html: authorized-trust-lines.html
+parent: tokens.html
+blurb: The Authorized Trust Lines feature enables issuers to create tokens that can only be held by accounts that the issuer specifically authorizes.
+labels:
+  - Tokens
+---
 # Authorized Trust Lines
 
 The Authorized Trust Lines feature enables issuers to create tokens that can only be held by accounts that the issuer specifically authorizes. This feature only applies to tokens, not XRP.

content/concepts/tokens/common-misunderstandings-about-freezes.md

@@ -1,3 +1,10 @@
+---
+html: common-misunderstandings-about-freezes.html
+parent: freezing-tokens.html
+blurb: Clarifications on some common areas of confusion around freezing tokens.
+labels:
+  - Tokens
+---
 # Common Misunderstandings about Freezes
 
 It is a common misconception that Ripple or others can freeze XRP, similar to how centralized services like PayPal can suspend your account and prevent you from accessing your funds. In reality, while the XRP Ledger does have a [freeze feature](freezing-tokens.md), it can only be used on issued tokens, not on XRP. _No one can freeze XRP.__

content/concepts/tokens/freezing-tokens.md

@@ -1,3 +1,10 @@
+---
+html: freezing-tokens.html
+parent: tokens.html
+blurb: Issuers can freeze the tokens they issue in the XRP Ledger.
+labels:
+  - Tokens
+---
 # Freezing Tokens
 
 Issuers can freeze the tokens they issue in the XRP Ledger. _This does not apply to XRP,__ which is the native asset of the XRP Ledger, not an issued token.

content/concepts/tokens/fungible.md

@@ -1,3 +0,0 @@
-# Fungible Tokens
-
-Fungible tokens topic placeholder.

content/concepts/tokens/nftoken-batch-minting.md

@@ -1,3 +1,10 @@
+---
+html: nftoken-batch-minting.html
+parent: non-fungible.html
+blurb: You can mint non-fungible tokens in batches.
+labels:
+  - Tokens
+---
 # Batch minting
 
 There are two common approaches to minting NFToken objects in batches: mint on demand and scripted minting.
@@ -19,7 +26,7 @@ Any market activity prior to the initial sale of the NFToken object is not recor
 
 Use a program or script to mint many tokens at once. You might find the XRP Ledger ticket functionality helps you submit transactions in parallel, up to a current limit of 200 transactions in one group.
 
-For a practical example, see the [Batch Mint NFTokens](../../../tutorials/quickstart/batch-minting.md) tutorial.
+For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutorial.
 
 ### Benefits
 

content/concepts/tokens/non-fungible-token-transfers.md

@@ -1,5 +1,11 @@
+---
+html: non-fungible-token-transfers.html
+parent: non-fungible.html
+blurb: The XRPL Labs team has created a framework that supports non-fungible tokens.
+labels:
+  - Tokens
+---
 # Trading NFTokens on the XRP Ledger
-{% include '_snippets/nfts-disclaimer.md' %}
 
 You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0.  All offers are created using `NFTokenCreateOffer` transaction.
 

content/concepts/tokens/non-fungible.md

@@ -1,5 +1,11 @@
+---
+html: non-fungible.html
+parent: token-types.html
+blurb: The XRPL Labs team has created a framework that supports non-fungible tokens.
+labels:
+  - Tokens
+---
 # Non-fungible Tokens
-{% include '_snippets/nfts-disclaimer.md' %}
 
 The XRP Ledger tokens are, primarily, fungible.
 
@@ -12,11 +18,11 @@ Fungible tokens can be easily traded between users for XRP or other issued asset
 
 A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would purchase a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
 
-![Jenny Stamps](../../../img/nft-concepts1.png "Jenny Stamps")
+![Jenny Stamps](img/nft-concepts1.png "Jenny Stamps")
 
 But since you are standing around in 1919, you might be offered 24-cent airmail stamps where the aeroplane on the stamp is accidentally printed upside down. These are the world famous “Inverted Jenny” stamps. Only 100 were circulated on a single sheet of stamps, making them extremely rare and sought after. The current value of each mint condition stamp is appraised at over $1.5 million dollars.
 
-![Jenny Stamps](../../../img/nft-concepts2.png "Jenny Stamps")
+![Jenny Stamps](img/nft-concepts2.png "Jenny Stamps")
 
 Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
 
@@ -42,7 +48,7 @@ You destroy an `NFToken` using the `NFTokenBurn` transaction.
 
 You create a NFT using the `NFTokenMint` transaction. The `NFToken` lives on the `NFTokenPage` of the issuing account. You can create an `NFTokenOffer` to sell the `NFToken`, creating an entry to the XRP Ledger. Another account can accept the `NFTokenOffer`, transferring the `NFToken` to the accepting account’s `NFTokenPage`. If the `lsfTransferable `flag is set to _true_ (0x000008) when the `NFToken` is minted, the `NFToken` can be traded multiple times between accounts. The `NFToken` can be permanently destroyed by its owner using the `NFTokenBurn` transaction.
 
-![The NFT Lifecycle](../../../img/nft-lifecycle.png "NFT Lifecycle Image")
+![The NFT Lifecycle](img/nft-lifecycle.png "NFT Lifecycle Image")
 
 
 <!--

content/concepts/tokens/paths.md

@@ -1,6 +1,13 @@
+---
+html: paths.html
+parent: tokens.html
+blurb: In the XRP Ledger, paths define a way for tokens to flow through intermediary steps as part of a payment.
+labels:
+  - Tokens
+---
 # Paths
 
-In the XRP Ledger, paths define a way for [tokens](tokens.md) to flow through intermediary steps as part of a payment. Paths enable [cross-currency payments](../transactions/payments/cross-currency-payments.md) by connecting sender and receiver through orders in the XRP Ledger's decentralized exchange. Paths also enable complex settlement of offsetting debts.
+In the XRP Ledger, paths define a way for [tokens](tokens.html) to flow through intermediary steps as part of a payment. Paths enable [cross-currency payments](cross-currency-payments.html) by connecting sender and receiver through orders in the XRP Ledger's decentralized exchange. Paths also enable complex settlement of offsetting debts.
 
 A single Payment transaction in the XRP Ledger can use multiple paths, combining liquidity from different sources to deliver the desired amount. Thus, a transaction includes a _path set_, which is a collection of possible paths to take. All paths in a path set must start with the same currency, and must also end with the same currency as each other.
 
@@ -17,7 +24,7 @@ A path is made of steps that connect the sender to the receiver of the payment.
 
 Trading tokens and possibly XRP involves going to an order book and finding the best exchange rate between the assets involved for the amount being sent. The path step specifies which currency to change to, but does not record the state of the Offers in the order book. The canonical order of transactions is not final until a ledger is validated, so you cannot know for certain which Offers a transaction will take, until after the transaction has been validated. (You can make an educated guess, since each transaction takes the best available Offers at the time it executes in the final ledger.) <!-- STYLE_OVERRIDE: will -->
 
-In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.md), trust line quality settings, or rounding.
+In both types of steps, each intermediate address gains and loses approximately equal value: either a balance ripples from a trust line to another trust line in the same currency, or they exchange currencies according to a previously-placed order. In some cases, the amounts gained and lost may not be exactly equivalent, due to [transfer fees](transfer-fees.html), trust line quality settings, or rounding.
 
 {{ include_svg("img/paths-examples.svg", "Diagram of three example paths") }}
 
@@ -38,11 +45,11 @@ Finding paths is a very challenging problem that changes slightly every few seco
 
 ## Implied Steps
 
-By convention, several steps of a path are implied by the [fields of the Payment transaction](../transactions/payments/payment-types.md): specifically, the `Account` (sender), `Destination` (receiver), `Amount` (currency and amount to be delivered) and `SendMax` (currency and amount to be sent, if specified). The implied steps are as follows:
+By convention, several steps of a path are implied by the [fields of the Payment transaction](payment-types.html): specifically, the `Account` (sender), `Destination` (receiver), `Amount` (currency and amount to be delivered) and `SendMax` (currency and amount to be sent, if specified). The implied steps are as follows:
 
 * The first step of a path is always implied to be the sender of the transaction, as defined by the transaction's `Account` field.
 * If the transaction includes a `SendMax` field with an `issuer` that is not the sender of the transaction, that issuer is implied to be the second step of the path.
-    * If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines for the given currency code. See [special values for `SendMax` and `Amount`](../transactions/payments/payment-types.md) for details.
+    * If `issuer` of the `SendMax` _is_ the sending address, then the path starts at the sending address, and may use any of that address's trust lines for the given currency code. See [special values for `SendMax` and `Amount`](payment-types.html) for details.
 * If the `Amount` field of the transaction includes an `issuer` that is not the same as the `Destination` of the transaction, that issuer is implied to be the second-to-last step of the path.
 * Finally, last step of a path is always implied to be the receiver of a transaction, as defined by the transaction's `Destination` field.
 

content/concepts/tokens/rippling.md

@@ -1,10 +1,17 @@
+---
+html: rippling.html
+parent: tokens.html
+blurb: _Rippling__ occurs when more than one trust line is adjusted to make a payment. 
+labels:
+  - Tokens
+---
 # Rippling
 
-In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](../transactions/trust-lines-and-issuing.md) for the same token. Rippling is essential, because it allows users who hold tokens to send those to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way exchange order with no limit and a 1:1 exchange rate for two tokens with the same currency code but different issuers.
+In the XRP Ledger, "rippling" describes a process of atomic net settlement between multiple connected parties who have [trust lines](trust-lines-and-issuing.html) for the same token. Rippling is essential, because it allows users who hold tokens to send those to each other with the issuer as a passive intermediary. In a sense, rippling is like a passive, two-way exchange order with no limit and a 1:1 exchange rate for two tokens with the same currency code but different issuers.
 
 <!-- [exchange order](../server/offers.md) -->
 
-Rippling only occurs along the [paths](paths.md) of a payment. [Direct XRP-to-XRP payments](../transactions/payments/direct-xrp-payments.md) do not involve rippling.
+Rippling only occurs along the [paths](paths.html) of a payment. [Direct XRP-to-XRP payments](direct-xrp-payments.html) do not involve rippling.
 
 For non-issuing accounts, rippling can be undesirable because it lets other users shift obligations between tokens with the same currency code but different issuers. The [No Ripple Flag](#the-no-ripple-flag) disables rippling by default when others open trust lines to your account, unless you enable rippling by default using the [Default Ripple flag](#the-default-ripple-flag).
 
@@ -76,7 +83,7 @@ To enable the No Ripple flag, send a `TrustSet` transaction with the `tfSetNoRip
 
 In the case of two accounts that mutually trust each other, the No Ripple flag is tracked separately for each account.
 
-Using the HTTP/WebSocket APIs or your preferred [client library](../../../references/client-libraries.md), look up trust lines with the `account_lines method`. For each trust line, the `no_ripple` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the No Ripple flag.
+Using the HTTP/WebSocket APIs or your preferred [client library](client-libraries.html), look up trust lines with the `account_lines method`. For each trust line, the `no_ripple` field shows whether the current address has enabled the No Ripple flag on that trust line, and the `no_ripple_peer` field shows whether the counterparty has enabled the No Ripple flag.
 
 <!-- 
 

content/concepts/tokens/token-types.md

@@ -1,3 +1,10 @@
+---
+html: token-types.html
+parent: tokens.html
+blurb: You can use tokens for a variety of purposes on the XRP Ledger.
+labels:
+  - Tokens
+---
 # Token Types
 
 You can use tokens for a variety of purposes on the XRP Ledger.

dactyl-config.yml

@@ -760,12 +760,6 @@ pages:
       targets:
          - en
          - ja
-
-
-         
- ############
- ## Do Payments next.
- ############
          
     - md: concepts/tokens/tokens.md
       parent: concepts.html
@@ -773,11 +767,120 @@ pages:
          - en
          - ja
          
+    - md: concepts/tokens/token-types.md
+      parent: tokens.html
+      targets:
+         - en
+         - ja
+  
+    - md: concepts/tokens/authorized-trust-lines.md
+      parent: tokens.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/paths.md
+      parent: tokens.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/rippling.md
+      parent: tokens.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/transfer-fees.md
+      parent: tokens.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/freezing-tokens.md
+      parent: tokens.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/common-misunderstandings-about-freezes.md
+      parent: freezing-tokens.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/non-fungible.md
+      parent: token-types.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/non-fungible-token-transfers.md
+      parent: non-fungible.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/tokens/nftoken-batch-minting.md
+      parent: non-fungible.html
+      targets:
+         - en
+         - ja
+         
     - md: concepts/accounts/accounts.md
       parent: concepts.html
       targets:
          - en
          - ja
+         
+    - md: concepts/accounts/account-structure.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/account-types.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/account-creating.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/account-deleting.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/reserves.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/addresses.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/deposit-authorization.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
+    - md: concepts/accounts/cryptographic-keys.md
+      parent: accounts.html
+      targets:
+         - en
+         - ja
+         
 
 
 # Tutorials --------------------------------------------------------------------