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

Merge branch 'master' into dd-NFT-Jira-Fixes20200322

Browse Source
This commit is contained in:
Dennis Dawson
2022-04-07 11:11:50 -07:00
committed by GitHub
parent 953f0ba387 40e50a3d81
commit 8ef1fefcfd
20 changed files with 167 additions and 94 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
assets/css/devportal2022-v3.css Normal file
View File

File diff suppressed because one or more lines are too long

BIN
assets/img/events/event-meetup-abu-dhabi@2x.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 210 KiB

BIN
assets/img/events/event-meetup-irvine@2x.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 310 KiB

BIN
assets/img/events/event-meetup-new-york@2x.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 260 KiB

BIN
assets/img/events/event-meetup-sao-paulo@2x.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 298 KiB

BIN
assets/img/events/event-meetup-toronto@2x.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 189 KiB

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

@@ -35,20 +35,19 @@ Transactions within the sidechain are not visible to the servers on the mainchai
## Terminology
_Sidechain_: An XRP Ledger sidechain is another blockchain based on XRP Ledger technology. A _federated_ sidechain provides a way to transfer assets from a mainchain to the sidechain and back. A sidechain can use an exact copy of the XRP Ledger's protocol or it can make changes, including to the [consensus algorithm](consensus.html), [transaction types](transaction-types.html), and other rules.
_Federator_: A server on the sidechain that listens for triggering transactions on both the main chain and the side chain. Each federator has a signing key associated with it that is used to sign transactions. A transaction must be signed by a quorum of federators before it can be submitted. Federators are responsible for creating and signing valid response transactions, collecting signatures from other federators, and submitting transactions to the main chain and side chain.
_Mainchain_: The blockchain where assets originate and where assets are held while being used on the side chain. For most sidechains, the mainchain is the XRP Ledger Mainnet, Testnet, or Devnet.
_Sidechain_: A custom blockchain where some assets are backed by a mainchain. Proxy assets are issued in the sidechain, with the equivalent assets held by a door account on the mainchain. Sidechains have separate history, rules, and validators than the mainchain. Proxy assets on the sidechain can be sent back to the mainchain and unlocked from the control of the federators.
Below is an alphabetical list of terms and their definitions.
_Door account_: An account controlled by the federators. There are two door accounts: one on the mainchain and one on the sidechain. Cross chain transactions are started by users sending assets to a door account. Mainchain to sidechain transactions cause the balance to increase on the mainchain door account and the balance to decrease on the sidechain door account. It is called a "door" because it is the mechanism to move assets from one chain to another—much like going between rooms in a house requires stepping through a door.
_Triggering transaction_: A transaction that causes the federators to start the process of signing and submitting a new response transaction. For example, sending XRP to the mainchain's door account is a triggering transaction that causes the federators to submit a new transaction on the sidechain.
_Federator_: A server on the sidechain that listens for triggering transactions on both the mainchain and the sidechain. Each federator has a signing key associated with it that is used to sign transactions. A transaction must be signed by a quorum of federators before it can be submitted. Federators are responsible for creating and signing valid response transactions, collecting signatures from other federators, and submitting transactions to the mainchain and sidechain.
_Mainchain_: The blockchain where assets originate and where assets are held while being used on the sidechain. For most sidechains, the mainchain is the XRP Ledger Mainnet, Testnet, or Devnet.
_Response transaction_: A transaction submitted by the federators in reaction to a triggering transaction. In most cases, the response transaction occurs on the opposite chain as the triggering transaction. However, there are some exceptions for handling failed transactions.
_Sidechain_: An XRP Ledger sidechain is another blockchain based on XRP Ledger technology. A _federated_ sidechain provides a way to transfer assets from a mainchain to the sidechain and back. A sidechain can use an exact copy of the XRP Ledger's protocol or it can make changes, including to the [consensus algorithm](consensus.html), [transaction types](transaction-types.html), and other rules. Sidechains have separate history, rules, and validators than the mainchain. Proxy assets are issued in the sidechain, with the equivalent assets held by a door account on the mainchain. Proxy assets on the sidechain can be sent back to the mainchain and unlocked from the control of the federators.
_Triggering transaction_: A transaction that causes the federators to start the process of signing and submitting a new response transaction. For example, sending XRP to the mainchain's door account is a triggering transaction that causes the federators to submit a new transaction on the sidechain.
## How to Set Up a Federated Sidechain

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

@@ -10,7 +10,7 @@ targets:
The XRP Ledger has possibly the world's oldest _decentralized exchange_ (sometimes abbreviated "DEX"), operating continuously since the XRP Ledger's launch in 2012. The exchange allows users to buy and sell [tokens](tokens.html) for XRP or other tokens, with minimal [fees](fees.html) charged to the network itself (not paid out to any party).
**Caution:** Any can [issue a token](issue-a-fungible-token.html) with any currency code or ticker symbol they want and sell it in the decentralized exchange. Always perform due diligence before buying a token, and pay attention to the issuer. Otherwise, you might give up something of value and receive worthless tokens in exchange.
**Caution:** Anyone can [issue a token](issue-a-fungible-token.html) with any currency code or ticker symbol they want and sell it in the decentralized exchange. Always perform due diligence before buying a token, and pay attention to the issuer. Otherwise, you might give up something of value and receive worthless tokens in exchange.
## Structure

16
content/references/protocol-reference/transactions/transaction-types/nftokenacceptoffer.md
View File

@@ -17,9 +17,9 @@ The `NFTokenAcceptOffer` transaction is used to accept offers to `buy` or `sell`
## Brokered vs. Direct Mode
The mode in which the transaction operates depends on the presence of the `SellOffer` and `BuyOffer` fields of the transaction:
The mode in which the transaction operates depends on the presence of the `NFTokenSellOffer` and `NFTokenBuyOffer` fields of the transaction:
| `SellOffer` | `BuyOffer` | Mode |
| `NFTokenSellOffer` | `NFTokenBuyOffer` | Mode |
|:------------|:-----------|:---------|
| ✔️ | ✔️ | Brokered |
| ✔️ | X | Direct |
@@ -68,17 +68,17 @@ In brokered mode, the `NFTokenAcceptOffer` transaction fails if:
| Field | JSON Type | [Internal Type][] | Description |
|:----------------|:-----------------|:------------------|:--------------------|
| `TransactionType` | String | UInt16 | Transaction type `NFTokenAcceptOffer`. The integer identifier is 29. |
| `SellOffer` | String | Hash256 | _(Optional)_ Identifies the `NFTokenOffer` that offers to sell the `NFToken`. |
| `BuyOffer` | String | Hash256 | _(Optional)_ Identifies the `NFTokenOffer` that offers to buy the `NFToken`. |
| `BrokerFee` | [Currency Amount][] | Amount | _(Optional)_ This field is only valid in brokered mode, and specifies the amount that the broker keeps as part of their fee for bringing the two offers together; the remaining amount is sent to the seller of the NFToken being bought. If specified, the fee must be such that, prior to accounting for the transfer fee charged by the issuer, the amount that the seller would receive is at least as much as the amount indicated in the sell offer. |
| `NFTokenSellOffer` | String | Hash256 | _(Optional)_ Identifies the `NFTokenOffer` that offers to sell the `NFToken`. |
| `NFTokenBuyOffer` | String | Hash256 | _(Optional)_ Identifies the `NFTokenOffer` that offers to buy the `NFToken`. |
| `NFTokenBrokerFee` | [Currency Amount][] | Amount | _(Optional)_ This field is only valid in brokered mode, and specifies the amount that the broker keeps as part of their fee for bringing the two offers together; the remaining amount is sent to the seller of the NFToken being bought. If specified, the fee must be such that, prior to accounting for the transfer fee charged by the issuer, the amount that the seller would receive is at least as much as the amount indicated in the sell offer. |
In direct mode, you must specify **either** the `SellOffer` or the `BuyOffer`. In brokered mode, you must specify **both** the `SellOffer` and the `BuyOffer`.
In direct mode, you must specify **either** the `NFTokenSellOffer` or the `NFTokenBuyOffer`. In brokered mode, you must specify **both** the `NFTokenSellOffer` and the `NFTokenBuyOffer`.
This functionality is intended to allow the `owner` of an `NFToken` to offer their token for sale to a third party broker, who may then attempt to sell the `NFToken` on for a larger amount, without the broker having to own the `NFToken` or custody funds.
This functionality is intended to allow the `owner` of a `NFToken` to offer their token for sale to a third party broker, who may then attempt to sell the `NFToken` on for a larger amount, without the broker having to own the `NFToken` or custody funds.
If both offers are for the same asset, it is possible that the order in which funds are transferred might cause a transaction that would succeed to fail due to an apparent lack of funds. To ensure deterministic transaction execution and maximize the chances of successful execution, the account attempting to buy the `NFToken` is debited first. Funds due to the broker are credited _before_ crediting the seller.
In brokered mode, The offers referenced by `BuyOffer` and `SellOffer` must both specify the same `TokenID`; that is, both must be for the same `NFToken`.
In brokered mode, The offers referenced by `NFTokenBuyOffer` and `NFTokenSellOffer` must both specify the same `NFTokenID`; that is, both must be for the same `NFToken`.

36
content/references/protocol-reference/transactions/transaction-types/nftokenburn.md
View File

@@ -23,7 +23,7 @@ If this operation succeeds, the corresponding `NFToken` is removed. If this oper
"Account": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
"Owner": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"Fee": 10,
"TokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65"
"NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65"
}
```
@@ -63,7 +63,7 @@ If this operation succeeds, the corresponding `NFToken` is removed. If this oper
</td>
<td>AccountID
</td>
<td>The <code>AccountID</code> that submitted this transaction. The account must be either the present <code>owner</code> of the token or, if the <code>lsfBurnable</code> flag is set in the <code>NFToken</code>, the <code>issuer</code> account or an account authorized by the issuer, (that is, the <code>MintAccount</code>).
<td>The <code>AccountID</code> that submitted this transaction. The account must be either the present <code>owner</code> of the token or, if the <code>lsfBurnable</code> flag is set in the <code>NFToken</code>, the <code>issuer</code> account or an account authorized by the issuer, (that is, the <code>NFTokenMinter</code>).
</td>
</tr>
<tr>
@@ -79,7 +79,7 @@ If this operation succeeds, the corresponding `NFToken` is removed. If this oper
</td>
</tr>
<tr>
<td><code>TokenID</code>
<td><code>NFTokenID</code>
</td>
<td>Yes
</td>
@@ -90,6 +90,18 @@ If this operation succeeds, the corresponding `NFToken` is removed. If this oper
<td>Identifies the <code>NFToken</code> object to be removed by the transaction.
</td>
</tr>
<tr>
<td><code>Owner</code>
</td>
<td>No
</td>
<td>string
</td>
<td>AccountID
</td>
<td>Identifies the owner of the NFToken with the given TokenID. Only used if that owner is different than the account signing this transaction. This is used to burn tokens with the lsfBurnable flag that have been traded.
</td>
</tr>
</table>
@@ -97,7 +109,7 @@ If this operation succeeds, the corresponding `NFToken` is removed. If this oper
## Account Root Enhancements
### MintAccount
### NFTokenMinter
Issuers might want to issue NFTs from their well known account, while at the same time wanting to delegate the issuance of such NFTs to a mint or other third party.
@@ -117,7 +129,7 @@ Issuers might want to issue NFTs from their well known account, while at the sam
</td>
</tr>
<tr>
<td><code>MintAccount</code>
<td><code>NFTokenMinter</code>
</td>
<td>
</td>
@@ -125,26 +137,26 @@ Issuers might want to issue NFTs from their well known account, while at the sam
</td>
<td>AccountID
</td>
<td>The <code>MintAccount</code> field, if set, specifies an alternate account which is allowed to execute the <code>NFTokenMint</code> and <code>NFTokenBurn</code> operations on behalf of the account.
<td>The <code>NFTokenMinter</code> field, if set, specifies an alternate account that is allowed to execute the <code>NFTokenMint</code> and <code>NFTokenBurn</code> operations on behalf of the account.
</td>
</tr>
</table>
The `SetAccount` transaction allows the `MintAccount` field to be set or cleared.
The `SetAccount` transaction allows the `NFTokenMinter` field to be set or cleared.
### MintedTokens
### MintedNFTokens
The `MintedTokens` field is used to form the `TokenID` of a new object, to ensure the uniqueness of `NFToken` objects. If this field is not present, the value is 0.
The `MintedNFTokens` field is used to form the `NFTokenID` of a new object, to ensure the uniqueness of `NFToken` objects. If this field is not present, the value is 0.
### BurnedTokens
### BurnedNFTokens
The `BurnedTokens` field provides a convenient way to determine how many `NFToken` objects issued by an account are still active (that is, not burned). If this field is not present the value 0 is assumed. The field is decremented whenever a token issued by this account is burned.
The `BurnedNFTokens` field provides a convenient way to determine how many `NFToken` objects issued by an account are still active (that is, not burned). If this field is not present the value 0 is assumed. The field is decremented whenever a token issued by this account is burned.
An account for which the difference the number of minted and burned tokens, as stored in the `MintedTokens` and `BurnedTokens` fields respectively, is non-zero cannot be deleted.
An account for which the difference in the number of minted and burned tokens, as stored in the `MintedNFTokens` and `BurnedNFTokens` fields respectively, is non-zero cannot be deleted.
<!--{# common link defs #}-->

6
content/references/protocol-reference/transactions/transaction-types/nftokencanceloffer.md
View File

@@ -17,7 +17,7 @@ The `NFTokenCancelOffer` transaction can be used to cancel existing token offers
{
"TransactionType": "NFTokenCancelOffer",
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
"TokenOffers": [
"NFTokenOffers": [
"9C92E061381C1EF37A8CDE0E8FC35188BFC30B1883825042A64309AC09F4C36D"
]
}
@@ -38,9 +38,9 @@ This transaction removes the listed `NFTokenOffer` object from the ledger, if pr
| Field | JSON Type | [Internal Type][] | Description |
|:------------------|:----------|:------------------|:-------------------------|
| `TransactionType` | String | UInt16 | NFTokenCancelOffer transaction type. The integer identifier is 28. |
| `TokenOffers` | Array | VECTOR256 | An array of IDs of the `NFTokenOffer` objects to cancel (not the `nft_id` values of `NFToken` objects, but the `nft_offer_index` values of `NFTokenOffer` objects). Each entry must be a different [object ID](ledger-object-ids.html) of an [NFTokenOffer](nftokenoffer.html) object; the transaction is invalid if the array contains duplicate entries. |
| `NFTokenOffers` | Array | VECTOR256 | An array of IDs of the `NFTokenOffer` objects to cancel (not the IDs of `NFToken` objects, but the IDs of the `NFTokenOffer` objects). Each entry must be a different [object ID](ledger-object-ids.html) of an [NFTokenOffer](nftokenoffer.html) object; the transaction is invalid if the array contains duplicate entries. |
The transaction can succeed even if one or more of the IDs in the `TokenOffers` field do not refer to objects that currently exist in the ledger. (For example, those token offers might already have been deleted.)
The transaction can succeed even if one or more of the IDs in the `NFTokenOffers` field do not refer to objects that currently exist in the ledger. (For example, those token offers might already have been deleted.) The transaction fails with an error if one of the IDs points to an object that does exist, but is not a [NFTokenOffer](nftokenoffer.html) object.
It is important to note that if you inadvertently provide a `nft_id` rather than a `nft_offer_index`, you might receive a `tesSuccess` response. The reason is that when passed a properly formatted ID value that is not found, the system assumes that the `NFTokenOffer` has already been deleted.

4
content/references/protocol-reference/transactions/transaction-types/nftokencreateoffer.md
View File

@@ -19,7 +19,7 @@ If successful, the transaction creates a [NFTokenOffer object][]. Each offer cou
{
"TransactionType": "NFTokenCreateOffer",
"Account": "rs8jBmmfpwgmrSPgwMsh7CvKRmRt1JTVSX",
"TokenID": "000100001E962F495F07A990F4ED55ACCFEEF365DBAA76B6A048C0A200000007",
"NFTokenID": "000100001E962F495F07A990F4ED55ACCFEEF365DBAA76B6A048C0A200000007",
"Amount": "1000000",
"Flags": 1
}
@@ -31,7 +31,7 @@ If successful, the transaction creates a [NFTokenOffer object][]. Each offer cou
| Field | JSON Type | [Internal Type][] | Description |
|:--------------|:--------------------|:------------------|:-------------------|
| `Owner` | String | AccountID | _(Optional)_ Who owns the corresponding `NFToken`. If the offer is to buy a token, this field must be present and it must be different than the `Account` field (since an offer to buy a token one already holds is meaningless). If the offer is to sell a token, this field must not be present, as the owner is, implicitly, the same as the `Account` (since an offer to sell a token one doesn't already hold is meaningless). |
| `TokenID` | String | Hash256 | Identifies the `NFToken` object that the offer references. |
| `NFTokenID` | String | Hash256 | Identifies the `NFToken` object that the offer references. |
| `Amount` | [Currency Amount][] | Amount | Indicates the amount expected or offered for the corresponding `NFToken`. The amount must be non-zero, except where this is an offer to sell and the asset is XRP; then, it is legal to specify an amount of zero, which means that the current owner of the token is giving it away, gratis, either to anyone at all, or to the account identified by the `Destination` field. |
| `Expiration` | Number | UInt32 | _(Optional)_ Indicates the time after which the offer will no longer be valid. The value is the number of [seconds since the Ripple Epoch][]. |
| `Destination` | String | AccountID | _(Optional)_ If present, indicates that this offer may only be accepted by the specified account. Attempts by other accounts to accept this offer MUST fail. |

26
content/references/protocol-reference/transactions/transaction-types/nftokenmint.md
View File

@@ -10,9 +10,9 @@ status: not_enabled
[[Source]](https://github.com/ripple/rippled/blob/xls20/src/ripple/app/tx/impl/NFTokenMint.cpp)
{% include '_snippets/nfts-disclaimer.md' %}
The `NFTokenMint` transaction creates an non-fungible token and adds it to the relevant [NFTokenPage object][] of the `Minter` as an [NFToken][] object. A required parameter to this transaction is the `Token` field specifying the actual token. This transaction is the only opportunity the `Minter` has to specify any token fields that are defined as immutable (for example, the `TokenFlags`).
The `NFTokenMint` transaction creates a NFToken and adds it to the relevant [NFTokenPage object][] of the `NFTokenMinter` as a [NFToken][] object. A required parameter to this transaction is the `Token` field specifying the actual token. This transaction is the only opportunity the `NFTokenMinter` has to specify any token fields that are defined as immutable (for example, the `Flags`).
If the transaction is successful, the newly minted token is owned by the account (the `minter` account) that executed the transaction. If needed, the server creates a new `NFTokenPage` for the account and applies a reserve charge.
If the transaction is successful, the newly minted token is owned by the account (the `minter` account) that executed the transaction. If needed, the server creates a new `NFTokenPage` for the account and applies a reserve charge.
## Example {{currentpage.name}} JSON
@@ -24,7 +24,7 @@ If the transaction is successful, the newly minted token is owned by the account
"Account": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"Issuer": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
"TransferFee": 314,
"TokenTaxon": 0,
"NFTokenTaxon": 0,
"Flags": 2147483659,
"Fee": 10,
"URI": "697066733a2f2f62616679626569676479727a74357366703775646d37687537367568377932366e6634646675796c71616266336f636c67747179353566627a6469",
@@ -41,7 +41,7 @@ If the transaction is successful, the newly minted token is owned by the account
```
This transaction assumes that the issuer, `rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2`, has set the `Minter` field in its `AccountRoot` to `rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B`, thereby authorizing that account to mint tokens on its behalf.
This transaction assumes that the issuer, `rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2`, has set the `NFTokenMinter` field in its `AccountRoot` to `rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B`, thereby authorizing that account to mint tokens on its behalf.
@@ -49,10 +49,10 @@ This transaction assumes that the issuer, `rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2`,
| Field | JSON Type | [Internal Type][] | Description |
|:--------------|:--------------------|:------------------|:-------------------|
| `TokenTaxon` | Number | UInt32 | The taxon associated with the token. The taxon is generally a value chosen by the minter of the token. A given taxon can be used for multiple tokens. Taxon identifiers greater than `0xFFFF'FFFF` are disallowed. |
| `Issuer` | String | AccountID | _(Optional)_ The issuer of the token, if the sender of the account is issuing it on behalf of another account. This field must be omitted if the account sending the transaction is the issuer of the `NFToken`. If provided, the issuer's [AccountRoot object][] must have the `Minter` field set to sender of this transaction (this transaction's `Account` field). |
| `TransferFee` | Number | UInt16 | _(Optional)_ The value specifies the fee charged by the issuer for secondary sales of the Token, if such sales are allowed. Valid values for this field are between 0 and 50,000 inclusive and a value of 1 is equivalent to 1/10 of a basis point or 0.001%, allowing transfer rates between 0% and 50%. A TransferFee of 50,000 corresponds to 50%. If this field is provided, the transaction MUST have the [`tfTransferable` flag](#nftokenmint-flags) enabled. |
| `URI` | String | Blob | _(Optional)_ Up to 256 bytes of arbitrary data. In JSON, this should be encoded as a string of hexadecimal. You can use the [`xrpl.convertStringToHex`](https://js.xrpl.org/modules.html#convertStringToHex) utility to convert a URI to its hexadecimal equivalent. This is intended to be a URI that points to the data or metadata associated with the NFT. The contents could decode to an HTTP or HTTPS URL, an IPFS URI, a magnet link, immediate data encoded as an [RFC2379 "data" URL](https://datatracker.ietf.org/doc/html/rfc2397), or even an issuer-specific encoding. The URI is NOT checked for validity.
| `NFTokenTaxon` | Number | UInt32 | The taxon associated with the token. The taxon is generally a value chosen by the minter of the token. A given taxon can be used for multiple tokens. Taxon identifiers greater than `0xFFFF'FFFF` are disallowed. |
| `Issuer` | String | AccountID | _(Optional)_ The issuer of the token, if the sender of the account is issuing it on behalf of another account. This field must be omitted if the account sending the transaction is the issuer of the `NFToken`. If provided, the issuer's [AccountRoot object][] must have the `NFTokenMinter` field set to the sender of this transaction (this transaction's `Account` field). |
| `TransferFee` | Number | UInt16 | _(Optional)_ The value specifies the fee charged by the issuer for secondary sales of the NFToken, if such sales are allowed. Valid values for this field are between 0 and 9999 inclusive, allowing transfer rates of between 0.00% and 99.99% in increments of 0.01. If this field is provided, the transaction MUST have the [`tfTransferable` flag](#nftokenmint-flags) enabled. |
| `URI` | String | Blob | _(Optional)_ Up to 256 bytes of arbitrary data. In JSON, this should be encoded as a string of hexadecimal. You can use the [`xrpl.convertStringToHex`](https://js.xrpl.org/modules.html#convertStringToHex) utility to convert a URI to its hexadecimal equivalent. This is intended to be a URI that points to the data or metadata associated with the NFToken. The contents could decode to an HTTP or HTTPS URL, an IPFS URI, a magnet link, immediate data encoded as an [RFC2379 "data" URL](https://datatracker.ietf.org/doc/html/rfc2397), or even an issuer-specific encoding. The URI is NOT checked for validity.|
## NFTokenMint Flags
@@ -62,7 +62,7 @@ Transactions of the NFTokenMint type support additional values in the [`Flags` f
| Flag Name | Hex Value | Decimal Value | Description |
|:--------------|:-------------|:--------------|:------------------------------|
| `tfBurnable` | `0x00000001` | 1 | Allow the issuer (or an entity authorized by the issuer) to destroy the minted `NFToken`. (The `NFToken`'s owner can _always_ do so.) |
| `tfOnlyXRP` | `0x00000002` | 2 | The minted `NFToken` can only be bought or sold for XRP. This may be desirable if the token has a transfer fee and the issuer does not want to receive fees in non-XRP currencies. |
| `tfOnlyXRP` | `0x00000002` | 2 | The minted `NFToken` can only be bought or sold for XRP. This can be desirable if the token has a transfer fee and the issuer does not want to receive fees in non-XRP currencies. |
| `tfTrustLine` | `0x00000004` | 4 | Automatically create [trust lines](trust-lines-and-issuing.html) from the issuer to hold transfer fees received from transferring the minted `NFToken`. |
| `tfTransferable` | `0x00000008` | 8 | The minted `NFToken` can be transferred to others. If this flag is _not_ enabled, the token can still be transferred _from_ or _to_ the issuer. |
@@ -73,12 +73,12 @@ If you need to specify additional information during minting (for example, detai
## Error Cases
- If the `TransferFee` field is not within the acceptable range (0 to 50,000 inclusive) the transaction fails with `temBAD_TRANSFER_RATE`.
- If the `TransferFee` field is not within the acceptable range (0 to 9999 inclusive) the transaction fails with `temBAD_NFTOKEN_TRANSFER_FEE`.
- If the `URI` field is longer than 256 bytes, the transaction fails with `temMALFORMED`.
- If the `Issuer` field refers to an account that does not exist, the transaction fails with `tecNO_ISSUER`.
- If account referenced by the `Issuer` field has not authorized this transaction's sender (using the `Minter` setting) to mint `NFToken`s on their behalf, the transaction fails with `tecNO_PERMISSION`.
- If the owner would not meet the updated [reserve requirement](reserves.html) after minting the token, the transaction fails with `tecINSUFFICIENT_RESERVE`. Note that new `NFToken`s only increase the owner's reserve if it requires a new [NFTokenPage object][], which can each hold up to 32 NFTs.
- If the `Issuer`'s `MintedTokens` field maxes out, the transaction fails with `tecMAX_SEQUENCE_REACHED`. This is only possible if 2<sup>32</sup>-1 `NFToken`s have been minted in total by the issuer or on their behalf.
- If account referenced by the `Issuer` field has not authorized this transaction's sender (using the `NFTokenMinter` setting) to mint `NFToken`s on their behalf, the transaction fails with `tecNO_PERMISSION`.
- If the owner would not meet the updated [reserve requirement](reserves.html) after minting the token, the transaction fails with `tecINSUFFICIENT_RESERVE`. Note that new `NFToken`s only increase the owner's reserve if it requires a new [NFTokenPage object][], which can each hold up to 32 NFTokens.
- If the `Issuer`'s `MintedNFTokens` field maxes out, the transaction fails with `tecMAX_SEQUENCE_REACHED`. This is only possible if 2<sup>32</sup>-1 `NFToken`s have been minted in total by the issuer or on their behalf.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/tutorials/use-tokens/issue-a-fungible-token.md
View File

@@ -65,7 +65,7 @@ When you're [building production-ready software](production-readiness.html), you
### {{n.next()}}. Connect to the Network
You must be connected to the network to submit transactions to it. The following code shows how to connect to a public XRP Ledger Testnet server a supported [client library](client-libraries.html):
You must be connected to the network to submit transactions to it. The following code shows how to connect to a public XRP Ledger Testnet server with a supported [client library](client-libraries.html):
<!-- MULTICODE_BLOCK_START -->

76
content/tutorials/use-tokens/nftoken-tester-tutorial.md
View File

@@ -19,7 +19,7 @@ This example builds a JavaScript test harness where you can create NFTokens and
To mint a `NFToken`, you need to generate Account and Secret credentials on the NFT-Devnet (`wss://xls20-sandbox.rippletest.net:51233`). Go to the [Test XRP Faucet](xrp-testnet-faucet.html) and click **Generate NFT-Devnet credentials**. You can also obtain a second set of account credentials to try creating and accepting buy and sell offers.
You will need a URL to the token data you want to turn into a `NFToken`. You can use your own object or this example IPFS address for testing.
You need a URL to the token data you want to turn into a `NFToken`. You can use your own object or this example IPFS address for testing.
```
@@ -84,7 +84,7 @@ async function mintToken() {
2. Create a `NFTokenMint` transaction using your account address and the `URI` to your token data. Note that you must convert the token `URI` to a hexadecimal value for this transaction. The `TokenTaxon` is a required field, but if you are not using the value as a custom indexing field, you can set it to 0.
2. Create a `NFTokenMint` transaction using your account address and the `URI` to your token data. Note that you must convert the token `URI` to a hexadecimal value for this transaction. The `NFTokenTaxon` is a required field, but if you are not using the value as a custom indexing field, you can set it to 0.
```js
@@ -93,7 +93,7 @@ async function mintToken() {
Account: wallet.classicAddress,
URI: xrpl.convertStringToHex(tokenUrl.value),
Flags: parseInt(flags.value),
TokenTaxon: 0
NFTokenTaxon: 0
}
```
@@ -283,7 +283,7 @@ async function burnToken() {
const transactionBlob = {
"TransactionType": "NFTokenBurn",
"Account": wallet.classicAddress,
"TokenID": tokenId.value
"NFTokenID": nftokenId.value
}
```
@@ -348,7 +348,7 @@ To create an offer to sell a `NFToken`:
1. Enter your **Account** and **Secret** in the appropriate fields.
2. Enter the **Token ID** of the NFToken you want to sell.
2. Enter the **NFToken ID** of the NFToken you want to sell.
3. Set the **Flags** value to 1.
4. Enter the **Amount**, the sale price in drops (millionths of an xrp). For example, if you enter 1000000, the sale price is 1 xrp.
5. Click **Create Sell Offer**.
@@ -395,7 +395,7 @@ async function createSellOffer() {
const transactionBlob = {
"TransactionType": "NFTokenCreateOffer",
"Account": wallet.classicAddress,
"TokenID": tokenId.value,
"NFTokenID": nftokenId.value,
"Amount": amount.value,
"Flags": parseInt(flags.value)
}
@@ -422,7 +422,7 @@ async function createSellOffer() {
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
tokenid: tokenId.value
nft_id: nftokenId.value
})
} catch (err) {
console.log("No sell offers.")
@@ -433,7 +433,7 @@ async function createSellOffer() {
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
tokenid: tokenId.value })
nft_id: nftokenId.value })
} catch (err) {
console.log("No buy offers.")
}
@@ -477,7 +477,7 @@ To create an offer to buy a `NFToken`:
1. Enter your **Account** and **Secret** in the appropriate fields.
2. Set the **Flags** value to `0`.
3. Enter the **Token ID** of the `NFToken` you want to purchase.
3. Enter the **NFToken ID** of the `NFToken` you want to purchase.
4. Enter your proposed purchase **Amount** in drops (millionths of an xrp).
5. Enter the **Owner** account address.
6. Click **Create Buy Offer**.
@@ -487,7 +487,7 @@ The `createBuyOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
2. Prepare a transaction blob.
3. Submit the transaction and wait for the results.
4. Request lists of current Sell Offers and Buy Offers.
@@ -504,7 +504,7 @@ The `createBuyOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
```js
@@ -527,7 +527,7 @@ async function createBuyOffer() {
"TransactionType": "NFTokenCreateOffer",
"Account": wallet.classicAddress,
"Owner": owner.value,
"TokenID": tokenId.value,
"NFTokenID": nftokenId.value,
"Amount": amount.value,
"Flags": parseInt(flags.value)
}
@@ -554,7 +554,7 @@ async function createBuyOffer() {
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
tokenid: tokenId.value
tokenid: nftokenId.value
})
} catch (err) {
console.log("No sell offers.")
@@ -565,7 +565,7 @@ async function createBuyOffer() {
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
tokenid: tokenId.value })
tokenid: nftokenId.value })
} catch (err) {
console.log("No buy offers.")
}
@@ -608,14 +608,14 @@ To create an offer to buy a `NFToken`:
1. Enter your **Account** and **Secret** in the appropriate fields.
2. Enter the **Token ID** of the `NFToken` you want to list.
2. Enter the **NFToken ID** of the `NFToken` you want to list.
3. Click **Get Offers**.
The `getOffers()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
2. Request `nft_sell_offers` and `nft_buy_offers` for your wallet account and send the results to your console log.
3. Disconnect from the server.
@@ -653,7 +653,7 @@ async function getOffers() {
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
tokenid: tokenId.value
tokenid: nftokenId.value
})
} catch (err) {
console.log("No sell offers.")
@@ -664,7 +664,7 @@ async function getOffers() {
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
tokenid: tokenId.value
tokenid: nftokenId.value
})
} catch (err) {
console.log("No buy offers.")
@@ -695,7 +695,7 @@ To cancel an offer to sell or buy a `NFToken`:
1. Enter your **Account** and **Secret** in the appropriate fields.
2. Enter the **Token Offer Index** of the offer you want to cancel. (Labeled as **Index** in the responses to `nft_buy_offers `and` nft_sell_offers` requests.)
2. Enter the **NFToken Offer Index** of the offer you want to cancel. (Labeled as nft_offer_index in the responses to `nft_buy_offers `and` nft_sell_offers` requests.)
3. Click **Cancel Offer**.
@@ -705,7 +705,7 @@ The `cancelOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
2. Prepare a transaction blob.
3. Submit the transaction and wait for the results.
4. Request lists of current Sell Offers and Buy Offers.
@@ -722,7 +722,7 @@ The `cancelOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
```js
@@ -740,13 +740,13 @@ async function cancelOffer() {
```js
const tokenOfferID = tokenOfferIndex.value
const tokenOfferID = nftokenOfferIndex.value
const tokenOffers = [tokenOfferID]
const transactionBlob = {
"TransactionType": "NFTokenCancelOffer",
"Account": wallet.classicAddress,
"TokenOffers": tokenOffers
"NFTokenOffers": tokenOffers
}
```
@@ -772,7 +772,7 @@ async function cancelOffer() {
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
tokenid: tokenId.value
tokenid: nftokenId.value
})
} catch (err) {
console.log("No sell offers.")
@@ -783,7 +783,7 @@ async function cancelOffer() {
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
tokenid: tokenId.value })
tokenid: nftokenId.value })
} catch (err) {
console.log("No buy offers.")
}
@@ -831,14 +831,14 @@ To accept a sell offer:
1. Enter your **Account** and **Secret** in the appropriate fields.
2. Enter the **Token Offer Index** of the offer you want to accept. (Labeled as **Index** in the responses to `nft_sell_offers` requests.)
2. Enter the **Token Offer Index** of the offer you want to accept. (Labeled as `nft_offer_index` in the responses to `nft_sell_offers` requests.)
3. Click **Accept Sell Offer**.
The `acceptSellOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
2. Prepare a transaction blob.
3. Submit the transaction and wait for the results.
4. Display the results in your console log.
@@ -854,7 +854,7 @@ The `acceptSellOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
```js
@@ -875,7 +875,7 @@ async function acceptSellOffer() {
const transactionBlob = {
"TransactionType": "NFTokenAcceptOffer",
"Account": wallet.classicAddress,
"SellOffer": tokenOfferIndex.value,
"SellOffer": nftokenOfferIndex.value,
}
```
@@ -927,14 +927,14 @@ To accept a buy offer:
1. Enter your **Account** and **Secret** in the appropriate fields.
2. Enter the **Token Offer Index** of the offer you want to accept. (Labeled as **Index** in the responses to `nft_sell_offers` requests.)
2. Enter the **NFToken Offer Index** of the offer you want to accept. (Labeled as `nft_offer_index` in the responses to `nft_sell_offers` requests.)
3. Click **Accept Buy Offer**.
The `acceptBuyOffer()` function steps are:
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
2. Prepare a transaction blob.
3. Submit the transaction and wait for the results.
4. Display the results in your console log.
@@ -952,7 +952,7 @@ async function acceptBuyOffer() {
1. Connect to the devnet server.
1. Connect to the nft-devnet server.
```js
@@ -971,7 +971,7 @@ async function acceptBuyOffer() {
const transactionBlob = {
"TransactionType": "NFTokenAcceptOffer",
"Account": wallet.classicAddress,
"BuyOffer": tokenOfferIndex.value
"BuyOffer": nftokenOfferIndex.value
}
```
@@ -1051,7 +1051,7 @@ The remainder of the test harness file creates a standard HTML form with 9 butto
<td><input type="text" id="secret" value="" size="40" /></td>
</tr>
<tr>
<td align="right">Token URL</td>
<td align="right">NFToken URL</td>
<td><input type="text" id="tokenUrl"
value = "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi" size="80"/>
</td>
@@ -1061,16 +1061,16 @@ value = "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi" siz
<td><input type="text" id="flags" value="1" size="10"/></td>
</tr>
<tr>
<td align="right">Token ID</td>
<td><input type="text" id="tokenId" value="" size="80"/></td>
<td align="right">NFToken ID</td>
<td><input type="text" id="nftokenId" value="" size="80"/></td>
</tr>
<tr>
<td align="right">Amount</td>
<td><input type="text" id="amount" value="1000000" size="20"/></td>
</tr>
<tr>
<td align="right">Token Offer Index</td>
<td><input type="text" id="tokenOfferIndex" value="" size="80"/></td>
<td align="right">NFToken Offer Index</td>
<td><input type="text" id="nftokenOfferIndex" value="" size="80"/></td>
</tr>
<tr>
<td align="right">Owner</td>

6
styles/package.json
View File

@@ -4,9 +4,9 @@
"node-sass": "^7.0.0"
},
"scripts": {
"build-css": "node-sass --include-path scss xrpl.scss ../assets/css/devportal2022-v2.css --output-style compressed",
"build-css-out": "node-sass --include-path scss xrpl.scss ../out/assets/css/devportal2022-v2.css --output-style compressed --source-map true",
"build-css-watch-out": "node-sass --recursive --watch --include-path scss xrpl.scss ../out/assets/css/devportal2022-v2.css --output-style compressed --source-map true"
"build-css": "node-sass --include-path scss xrpl.scss ../assets/css/devportal2022-v3.css --output-style compressed",
"build-css-out": "node-sass --include-path scss xrpl.scss ../out/assets/css/devportal2022-v3.css --output-style compressed --source-map true",
"build-css-watch-out": "node-sass --recursive --watch --include-path scss xrpl.scss ../out/assets/css/devportal2022-v3.css --output-style compressed --source-map true"
},
"dependencies": {
"sass": "^1.26.10"

2
styles/xrpl.scss
View File

@@ -67,7 +67,7 @@ $line-height-base: 1.5;
@import "_blog.scss";
@import "_feedback.scss";
@import "_video.scss";
@import "_top-banner.scss";
// @import "_top-banner.scss";
// Light/Dark theme settings ---------------------------------------------------
// Option to only change theme on user system settings. No toggle.

2
template/base.html.jinja
View File

@@ -53,7 +53,7 @@
{% if target.lang=="ja" %}
<link href="{{currentpage.prefix}}assets/css/fonts-ja.css" rel="stylesheet" />
{% endif %}
<link href="{{currentpage.prefix}}assets/css/devportal2022-v2.css" rel="stylesheet" />
<link href="{{currentpage.prefix}}assets/css/devportal2022-v3.css" rel="stylesheet" />
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/docsearch.js@2/dist/cdn/docsearch.min.css" />

4
template/component-top-nav.html.jinja
View File

@@ -1,9 +1,9 @@
<div class="top-banner fixed-top">
<!--{# <div class="top-banner fixed-top">
<div class="d-flex justify-content-center ">
<span><p class="mb-0">{% trans %}Wave 3 of the XRPL Grants program is open!{% endtrans %}</p></span>
<span><a href="https://xrplgrants.org/?utm_medium=referral&utm_source=xrpl&utm_campaign=banner" class=" btn btn-outline-secondary" target="_blank">Apply</a></span>
</div>
</div>
</div> #}-->
<nav class="top-nav navbar navbar-expand-lg navbar-dark fixed-top">
<a href="{% if currentpage.prefix %}{{currentpage.prefix}}{% else %}/{% endif %}" class="navbar-brand"><img class="logo" height="40" alt="{{target.display_name}}" /></a>
<button class="navbar-toggler collapsed" type="button" data-toggle="collapse" data-target="#top-main-nav" aria-controls="navbarHolder" aria-expanded="false" aria-label="Toggle navigation">

58
template/page-events.html.jinja
View File

@@ -101,6 +101,15 @@
</div>
{% set upcoming = [
{ "name": "NYC Meetup/Hackathon XRPL Celebration",
"id": "upcoming-xrpl-new-york",
"description": "The NYC/XRP community and Dev Null Productions cordially invites you to attend our 10th meetup, being held in celebration of the on-going XRPL Hackathon, at the unique and artistic TALS studio in Midtown Manhattan.",
"type": "meetup-upcoming",
"link": "https://www.meetup.com/NYC-XRP/events/284485901/",
"location": "NYC, NY",
"date": "March 30, 2022",
"image": "event-meetup-new-york@2x.jpg"},
{ "name": "XRPL Community Meetup: London",
"id": "upcoming-xrpl-london",
"description": "Join for an evening of programming and networking with members of the XRPL Community in London, co-organised by Peerkat - the NFT platform for creators on the XRPL.",
@@ -109,6 +118,53 @@
"location": "IDEALondon",
"date": "March 31, 2022",
"image": "event-meetup-london.png"},
{ "name": "XRPL Community Meetup: Toronto",
"id": "upcoming-xrpl-toronto",
"description": "Join us for our first Toronto meetup with an evening of programming and networking with other members of the XRP Ledger Community with special guests from the XUMM Wallet and ARK PLATES teams!",
"type": "meetup-upcoming",
"link": "https://www.meetup.com/xrpl-toronto-community-meetup/events/284177188/",
"location": "Toronto",
"date": "March 31, 2022",
"image": "event-meetup-toronto@2x.jpg"},
{ "name": "XRPL Community Meetup: San Diego",
"id": "upcoming-xrpl-san-diego",
"description": "Get together with other San Diego-based members of the XRP Ledger Community to network and discuss all things XRPL! Join us for our second San Diego XRPL Meetup.",
"type": "meetup-upcoming",
"link": "https://www.meetup.com/xrp-ledger-san-diego-community/events/284663355/",
"location": "San Diego, CA",
"date": "April 1st 2022",
"image": "event-meetup-san-diego@2x.jpg"},
{ "name": "XRPL Community Meetup: Irvine LA",
"id": "upcoming-xrpl-irvine",
"description": "Get together with other LA-based members of the XRP Ledger Community to network and discuss all things XRPL.",
"type": "meetup-upcoming",
"link": "https://www.meetup.com/xrp-ledger-la-community-meetup/events/284824635/",
"location": "UC Irvine, CA",
"date": "April 3rd 2022",
"image": "event-meetup-irvine@2x.jpg"},
{ "name": "XRPL Community Meetup: Miami #2",
"id": "upcoming-xrpl-miami-2",
"description": "We're excited to host our second Miami meetup for XRP Ledger community members on April 6th from 6-8pm, featuring Marco Neri, Developer Advocate at Ripple, who will join us to give a presentation on the XRP Ledger.",
"type": "meetup-upcoming",
"link": "https://www.meetup.com/xrp-ledger-miami-community/events/284463736/",
"location": "The LAB Miami, FL",
"date": "April 6th 2022",
"image": "event-meetup-miami@2x.jpg"},
{ "name": "XRPL Community Meetup: Abu Dhabi",
"id": "upcoming-xrpl-abu-dhabi",
"description": "Get together with other Abu Dhabi-based members of the XRP Ledger Community to network and discuss all things XRPL!",
"type": "meetup-upcoming",
"link": "https://www.meetup.com/xrp-ledger-dubai-community/events/284776939/",
"location": "NYU Abu Dhabi, Building A6",
"date": "April 14th 2022",
"image": "event-meetup-abu-dhabi@2x.jpg"},
] %}
<div class="row row-cols-1 row-cols-lg-3 card-deck mt-2">
{% for event in upcoming %}
@@ -203,7 +259,7 @@
"image": "event-hack-new-year.svg"},
] %}
<div class="row row-cols-1 row-cols-lg-3 card-deck mb-0 mt-2 ">
{% for event in past %}
{% for event in past|reverse %}
<a class="event-card {{event.type}}" href="{{event.link}}" target="_blank">
<div class="event-card-header" style="background: no-repeat url(assets/img/events/{{event.image}}); ">
<div class="event-card-title">{{event.name}}</div>