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

Known Amendments & NFT fixes

Browse Source 
- Add new amendments to the Known Amendments page.
    (The URL for the 1.9.4 release notes is speculative; this release is
    expected to happen "soon")
- Link the relevant API methods from the NFT concept page
- Rewrite some parts of the NFT concept page to be more concept-like and
  less a list of reference details
- Update the status of the CryptoConditionsSuite amendment
This commit is contained in:
mDuo13
2022-09-20 15:25:05 -07:00
parent 9aaa8a4e66
commit a556b817c1
7 changed files with 123 additions and 84 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -113,6 +113,7 @@
"account_currencies",
"account_info",
"account_lines",
"account_nfts",
"account_objects",
"account_offers",
"account_tx",
@@ -142,6 +143,9 @@
"log_level",
"logrotate",
"manifest",
"nft_buy_offers",
"nft_info",
"nft_sell_offers",
"noripple_check",
"path_find",
"peer_reservations_add",
@@ -210,8 +214,10 @@
"fixMasterKeyAsRegularKey",
"fixNFTokenDirV1",
"fixPayChanRecipientOwnerDir",
"fixRemoveNFTokenAutoTrustLine",
"fixQualityUpperBound",
"fixTakerDryOfferRemoval",
"fixTrustLinesToSelf",
"Flow",
"FlowCross",
"FlowV2",

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

@@ -14,10 +14,11 @@ labels:
| 名前 | 導入済み | ステータス |
|:--------------------------------|:-----------|:------------------------------------|
| [CryptoConditionsSuite][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [fixTrustLinesToSelf][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.4.html "BADGE_80d0e0") |
| [fixNFTokenNegOffer][] | v1.9.2 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.2.html "BADGE_80d0e0") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [予定: 2022/09/13](ttps://xrpl.org/blog/2022/get-ready-for-nfts.html "BADGE_BLUE") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.2.html "BADGE_80d0e0") |
| [ExpandedSignerList][] | v1.9.1 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.1.html "BADGE_80d0e0") |
| [fixNFTokenDirV1][] | v1.9.1 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.1.html "BADGE_80d0e0") |
| [NonFungibleTokensV1][] | v1.9.0 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.0.html "BADGE_80d0e0") |
@@ -64,10 +65,11 @@ labels:
| [TrustSetAuth][] | v0.30.0 | [有効: 2016/07/19](https://livenet.xrpl.org/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") |
| [MultiSign][] | v0.31.0 | [有効: 2016/06/27](https://livenet.xrpl.org/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") |
| [FeeEscalation][] | v0.31.0 | [有効: 2016/05/19](https://livenet.xrpl.org/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") |
| [Tickets][] | v0.30.1 | [禁止: v0.90.0で削除]( "BADGE_RED") |
| [CryptoConditionsSuite][] | v0.60.0 | [廃止: 削除未定]( "BADGE_RED") |
| [SHAMapV2][] | v0.32.1 | [禁止: v1.4.0で削除](https://xrpl.org/blog/2019/rippled-1.4.0.html "BADGE_RED") |
| [FlowV2][] | v0.32.1 | [禁止: v0.33.0で削除](https://xrpl.org/blog/2016/flowv2-vetoed.html "BADGE_RED") |
| [SusPay][] | v0.31.0 | [禁止: v0.60.0で削除](https://xrpl.org/blog/2017/ticksize-voting.html#upcoming-features "BADGE_RED") |
| [Tickets][] | v0.30.1 | [禁止: v0.90.0で削除](https://xrpl.org/blog/2018/rippled-0.90.0.html "BADGE_RED") |
**注記:** 多くの場合、旧バージョンのソフトウェアには不完全バージョンの修正用コードが存在します。上の表内の「導入済み」バージョンは最初の安定バージョンです。「未定」は、修正がまだ安定していないと見なされていることを示します。
@@ -473,6 +475,26 @@ Fixes a bug in unused code for estimating the ratio of input to output of indivi
This amendment has no known impact on transaction processing.
## fixRemoveNFTokenAutoTrustLine
[fixRemoveNFTokenAutoTrustLine]: #fixremovenftokenautotrustline
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| DF8B4536989BDACE3F934F29423848B9F1D76D09BE6A1FCFE7E7F06AA26ABEAD | 投票中 |
<!-- TODO: translate amendment description -->
Removes the `tfTrustLine` setting on [non-fungible tokens](non-fungible-tokens.html), to protect against a denial of service attack on issuers using this flag. With this amendment enabled, an [NFTokenMint transaction](nftokenmint.html) with the `tfTrustLine` flag enabled is considered invalid and cannot be confirmed by consensus; therefore, `NFToken` objects cannot be minted with the flag.
Without this amendment, an attacker could create new, meaningless fungible tokens and sell an NFT back and forth for those tokens, creating numerous useless trust lines tied to the issuer and increasing the issuer's reserve requirement.
This amendment does not change the code for `NFToken` objects that have already been minted. On test networks that already have NonFungibleTokensV1_1 enabled, this means that issuers who have already minted NFTokens with the `tfTrustLine` flag enabled are still vulnerable to the exploit even after the fixRemoveNFTokenAutoTrustLine amendment.
This amendment has no effect unless [NonFungibleTokensV1][] or [NonFungibleTokensV1_1][] is also enabled.
To protect issuers, this amendment should be enabled _before_ [NonFungibleTokensV1][] or [NonFungibleTokensV1_1][].
## fixRmSmallIncreasedQOffers
[fixRmSmallIncreasedQOffers]: #fixrmsmallincreasedqoffers
@@ -514,6 +536,19 @@ XRP Ledger内にドライオファーを残す可能性がある[オートブリ
この修正により、これらのドライオファーがオートブリッジで一致した場合に、XRP Ledgerによって除去されます。
## fixTrustLinesToSelf
[fixTrustLinesToSelf]: #fixtrustlinestoself
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| F1ED6B4A411D8B872E65B9DCB4C8B100375B0DD3D62D07192E011D6D7F339013 | 開発中 |
<!-- TODO: translate amendment description -->
This amendment removes up two trust lines from an account to itself that were created due to an old bug (both on 2013-05-07). When the amendment is activated, it deletes the trust lines with the IDs `2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1` and `326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A` if they exist. After doing so, the amendment does nothing else.
On test networks that do not have these trust lines, the amendment has no effect.
## Flow
[Flow]: #flow

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

@@ -14,10 +14,11 @@ The following is a comprehensive list of all known [amendments](amendments.html)
| Name | Introduced | Status |
|:--------------------------------|:-----------|:------------------------------|
| [CryptoConditionsSuite][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixTrustLinesToSelf][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.4.html "BADGE_80d0e0") |
| [fixNFTokenNegOffer][] | v1.9.2 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.2.html "BADGE_80d0e0") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [Expected: 2022-09-13](https://xrpl.org/blog/2022/get-ready-for-nfts.html "BADGE_BLUE") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.2.html "BADGE_80d0e0") |
| [ExpandedSignerList][] | v1.9.1 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.1.html "BADGE_80d0e0") |
| [fixNFTokenDirV1][] | v1.9.1 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.1.html "BADGE_80d0e0") |
| [NonFungibleTokensV1][] | v1.9.0 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.0.html "BADGE_80d0e0") |
@@ -64,10 +65,11 @@ The following is a comprehensive list of all known [amendments](amendments.html)
| [TrustSetAuth][] | v0.30.0 | [Enabled: 2016-07-19](https://livenet.xrpl.org/transactions/0E589DE43C38AED63B64FF3DA87D349A038F1821212D370E403EB304C76D70DF "BADGE_GREEN") |
| [MultiSign][] | v0.31.0 | [Enabled: 2016-06-27](https://livenet.xrpl.org/transactions/168F8B15F643395E59B9977FC99D6310E8708111C85659A9BAF8B9222EEAC5A7 "BADGE_GREEN") |
| [FeeEscalation][] | v0.31.0 | [Enabled: 2016-05-19](https://livenet.xrpl.org/transactions/5B1F1E8E791A9C243DD728680F108FEF1F28F21BA3B202B8F66E7833CA71D3C3 "BADGE_GREEN") |
| [CryptoConditionsSuite][] | v0.60.0 | [Obsolete: To Be Removed]( "BADGE_RED") |
| [SHAMapV2][] | v0.32.1 | [Vetoed: Removed in v1.4.0](https://xrpl.org/blog/2019/rippled-1.4.0.html "BADGE_RED") |
| [FlowV2][] | v0.32.1 | [Vetoed: Removed in v0.33.0](https://xrpl.org/blog/2016/flowv2-vetoed.html "BADGE_RED") |
| [SusPay][] | v0.31.0 | [Vetoed: Removed in v0.60.0](https://xrpl.org/blog/2017/ticksize-voting.html#upcoming-features "BADGE_RED") |
| [Tickets][] | v0.30.1 | [Vetoed: Removed in v0.90.0]( "BADGE_RED") |
| [Tickets][] | v0.30.1 | [Vetoed: Removed in v0.90.0](https://xrpl.org/blog/2018/rippled-0.90.0.html "BADGE_RED") |
**Note:** In many cases, an incomplete version of the code for an amendment is present in previous versions of the software. The "Introduced" version in the table above is the first stable version. The value "TBD" indicates that the amendment is not yet considered stable.
@@ -124,13 +126,13 @@ Although this amendment is enabled, it has no effect unless the [SusPay](#suspay
| Amendment | CryptoConditionsSuite |
|:----------|:-----------|
| Amendment ID | 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 |
| Status | In Development |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Implements several types of crypto-conditions from the official [crypto-conditions specification](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03) for use in [EscrowCreate][] and [EscrowFinish][] transactions. Without this amendment, only the PREIMAGE-SHA-256 type is supported.
This amendment was intended to add support for several types of crypto-conditions from the official [crypto-conditions specification](https://tools.ietf.org/html/draft-thomas-crypto-conditions-03) for use in [EscrowCreate][] and [EscrowFinish][] transactions.
**Caution:** This amendment is still [in development](https://github.com/ripple/rippled/pull/2170). The version from `rippled` v0.60.0 to present does not implement the full functionality.
However, the amendment was added to `rippled` v0.60.0 before implementation was complete. As a result, this amendment ID refers to incomplete code which does almost nothing. To safely add support for additional crypto-conditions without causing a conflict with versions that have the incomplete code, a different amendment ID would be needed.
## DeletableAccounts
@@ -580,6 +582,26 @@ Fixes a bug in unused code for estimating the ratio of input to output of indivi
This amendment has no known impact on transaction processing.
## fixRemoveNFTokenAutoTrustLine
[fixRemoveNFTokenAutoTrustLine]: #fixremovenftokenautotrustline
| Amendment | fixRemoveNFTokenAutoTrustLine |
|:----------|:-----------|
| Amendment ID | DF8B4536989BDACE3F934F29423848B9F1D76D09BE6A1FCFE7E7F06AA26ABEAD |
| Status | In Development |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
Removes the `tfTrustLine` setting on [non-fungible tokens](non-fungible-tokens.html), to protect against a denial of service attack on issuers using this flag. With this amendment enabled, an [NFTokenMint transaction](nftokenmint.html) with the `tfTrustLine` flag enabled is considered invalid and cannot be confirmed by consensus; therefore, `NFToken` objects cannot be minted with the flag.
Without this amendment, an attacker could create new, meaningless fungible tokens and sell an NFT back and forth for those tokens, creating numerous useless trust lines tied to the issuer and increasing the issuer's reserve requirement.
This amendment does not change the code for `NFToken` objects that have already been minted. On test networks that already have NonFungibleTokensV1_1 enabled, this means that issuers who have already minted NFTokens with the `tfTrustLine` flag enabled are still vulnerable to the exploit even after the fixRemoveNFTokenAutoTrustLine amendment.
This amendment has no effect unless [NonFungibleTokensV1][] or [NonFungibleTokensV1_1][] is also enabled.
To protect issuers, this amendment should be enabled _before_ [NonFungibleTokensV1][] or [NonFungibleTokensV1_1][].
## fixRmSmallIncreasedQOffers
[fixRmSmallIncreasedQOffers]: #fixrmsmallincreasedqoffers
@@ -628,6 +650,21 @@ Without this fix, the dry offer remains on the ledger and counts toward its owne
With this amendment enabled, the XRP Ledger removes these dry offers when they're matched in auto-bridging.
## fixTrustLinesToSelf
[fixTrustLinesToSelf]: #fixtrustlinestoself
| Amendment | fixTrustLinesToSelf |
|:----------|:-----------|
| Amendment ID | F1ED6B4A411D8B872E65B9DCB4C8B100375B0DD3D62D07192E011D6D7F339013 |
| Status | In Development |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
This amendment removes up two trust lines from an account to itself that were created due to an old bug (both on 2013-05-07). When the amendment is activated, it deletes the trust lines with the IDs `2F8F21EFCAFD7ACFB07D5BB04F0D2E18587820C7611305BB674A64EAB0FA71E1` and `326035D5C0560A9DA8636545DD5A1B0DFCFF63E68D491B5522B767BB00564B1A` if they exist. After doing so, the amendment does nothing else.
On test networks that do not have these trust lines, the amendment has no effect.
## Flow
[Flow]: #flow
@@ -796,7 +833,7 @@ It also modifies the [AccountSet transaction][] type to allow you to set the `NF
| Amendment | NonFungibleTokensV1_1 |
|:----------|:-----------|
| Amendment ID | 32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 |
| Status | Expected |
| Status | Open for Voting |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |

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

@@ -31,30 +31,35 @@ But since you are standing around in 1919, you might be offered 24-cent airmail
Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
The XRPL Labs team has created a framework that supports non-fungible tokens (NFTs, or “nifties” in the vernacular). Non-fungible tokens serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
The [NonFungibleTokensV1 amendment][] :not_enabled: adds support for non-fungible tokens (NFTs, or “nifties” in the vernacular) natively on the XRP Ledger. Non-fungible tokens serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
## NFT Extensions
## NFTs on the XRP Ledger
Extensions to the XRP Ledger support two new objects and a new ledger structure.
On the XRP Ledger, a non-fungible token is represented as an [NFToken][] object. An `NFToken` is a unique, indivisible unit that is not used for payments. Users can mint (create), hold, buy, sell, and burn (destroy) such tokens.
The [NFToken][] is a native NFT type. It has operations to enumerate, purchase, sell, and hold such tokens. An `NFToken` is a unique, indivisible unit that is not used for payments.
The ledger stores up to 32 `NFToken` objects owned by the same account in a single [NFTokenPage object][] to save space. As a result, the owner's [reserve requirement](reserves.html) for `NFToken` objects only increases when the ledger needs to make a new page to store additional tokens.
The [NFTokenPage object][] contains a set of `NFToken` objects owned by the same account.
Accounts can also designate a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
You create a new `NFToken` using the [NFTokenMint transaction][].
`NFToken` objects have several settings that are defined when the token is minted and cannot be changed later. These include:
[NFTokenOffer object][] is a new object that describes an offer to buy or sell a single `NFToken`.
You destroy an `NFToken` using the [NFTokenBurn transaction][]. Token owners can always burn a token they own. If you mint a token with the `tfBurnable` flag set, you have the option of burning the token at any time, regardless of the owner.
- Various identifying data that uniquely defines the token.
- Whether the issuer can burn the token regardless of who currently holds it.
- Whether the holder of the token can transfer it to others. (The `NFToken` can always be sent to or from the issuer directly.)
- If transfers are allowed, the issuer can charge a transfer fee as a percentage of the sale price.
- Whether the holder can sell the `NFToken` for [fungible token](tokens.html) amounts, or only for XRP.
## `NFToken` Lifecycle
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.
Anyone can create a new `NFToken` using the [NFTokenMint transaction][] type. The `NFToken` lives on the [NFTokenPage object][] of the issuing account. Either the owner or an interested party can send a [NFTokenCreateOffer transaction][] to propose buying or selling the `NFToken`; the ledger tracks the proposed transfer as an [NFTokenOffer object][], and deletes the `NFTokenOffer` when either side accepts or cancels the offer. If the `NFToken` is transferable, it can be traded multiple times between accounts.
You can destroy an `NFToken` you own using the [NFTokenBurn transaction][]. If the issuer minted the token with `tfBurnable` flag enabled, the issuer can also burn the token regardless of the current owner. (This could be useful, for example, for a token that represents a ticket to an event which is used up at some point.)
![The NFT Lifecycle](img/nft-lifecycle.png "NFT Lifecycle Image")
For more info about transferring NFTs, see [Trading NFTokens on the XRP Ledger](non-fungible-token-transfers.html).
## Reference
@@ -69,13 +74,11 @@ You create a NFT using the `NFTokenMint` transaction. The `NFToken` lives on the
- [NFTokenCancelOffer transaction][]
- [NFTokenAcceptOffer transaction][]
- [NFTokenBurn transaction][]
### API Methods
* `account_nfts`
* `nft_sell_offers`
* `nft_buy_offers`
- API Methods
- [account_nfts method][]
- [nft_sell_offers method][]
- [nft_buy_offers method][]
- [nft_info method][] (Clio server only)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

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

@@ -48,64 +48,20 @@ The 16-bit flags, transfer fee fields, the 32-bit `NFTokenTaxon`, and the sequen
Flags are properties or other options associated with the `NFToken` object.
<table>
<tr>
<td><strong>Flag Name</strong>
</td>
<td><strong>Flag Value</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td><code>lsfBurnable</code>
</td>
<td><code>0x0001</code>
</td>
<td>If set, indicates that the issuer (or an entity authorized by the issuer) can destroy the object. The object's owner can <em>always</em> do so.
</td>
</tr>
<tr>
<td><code>lsfOnlyXRP</code>
</td>
<td><code>0x0002</code>
</td>
<td>If set, indicates that the tokens can only be offered or sold for XRP.
</td>
</tr>
<tr>
<td><code>lsfTrustLine</code>
</td>
<td><code>0x0004</code>
</td>
<td>If set, indicates that the issuer wants a trustline to be automatically created. The <code>lsfTrustLine</code> field is useful when the token can be offered for sale for assets other than XRP and the issuer charges a <code>TransferFee</code>. If this flag is set, a trust line is automatically created as needed to allow the issuer to receive the appropriate transfer fee. If this flag is not set, an attempt to transfer the NFToken for an asset for which the issuer does not have a trustline fails.
</td>
</tr>
<tr>
<td><code>lsfTransferable</code>
</td>
<td><code>0x0008</code>
</td>
<td>If set, indicates that this <code>NFToken</code> can be transferred. This flag has no effect if the token is being transferred <em>from</em> the issuer or <em>to</em> the issuer.
</td>
</tr>
<tr>
<td><code>lsfReservedFlag</code>
</td>
<td><code>0x8000</code>
</td>
<td>This proposal reserves this flag for future use. Attempts to set this flag fail.
</td>
</tr>
</table>
| Flag Name | Flag Value | Description |
|:----------------|:-----------|:----------------------------------------------|
| `lsfBurnable` | `0x0001` | If set, indicates that the issuer (or an entity authorized by the issuer) can destroy the object. The object's owner can always do so. |
| `lsfOnlyXRP` | `0x0002` | If set, indicates that the tokens can only be offered or sold for XRP. |
| `lsfTrustLine` | `0x0004` | **DEPRECATED** If enabled, automatically create [trust lines](trust-lines-and-issuing.html) to hold transfer fees. Otherwise, buying or selling this `NFToken` for a fungible token amount fails if the issuer does not have a trust line for that token. The [fixRemoveNFTokenAutoTrustLine amendment][] makes it invalid to set this flag. |
| `lsfTransferable` | `0x0008` | If set, indicates that this `NFToken` can be transferred. This flag has no effect if the token is being transferred from the issuer or to the issuer. |
| `lsfReservedFlag` | `0x8000` | This proposal reserves this flag for future use. Attempts to set this flag fail. |
`NFToken` flags are immutable: they can only be set during the `NFTokenMint` transaction and cannot be changed later.
`NFToken` flags are immutable: they can only be set during the [NFTokenMint transaction][] and cannot be changed later.
### Example
The example sets three flags: lsfBurnable (0x0001), lsfOnlyXRP (0x0002), lsfTransferable (0x0008). 1+2+8 = 11, or 0x000B in big endian format.
The example sets three flags: `lsfBurnable` (`0x0001`), `lsfOnlyXRP` (`0x0002`), `lsfTransferable` (`0x0008`). 1+2+8 = 11, or 0x000B in big endian format.
![Flags](img/nftokena.png "Flags")

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

@@ -47,8 +47,6 @@ The `NFTokenMint` transaction creates a non-fungible token and adds it to the re
| `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 50000 inclusive, allowing transfer rates of between 0.00% and 50.00% in increments of 0.001. 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. |
**Note:** The xrpl.js client library throws an error if you try to sign a transaction with the `URI` field in lowercase hexadecimal. This is a [bug](https://github.com/XRPLF/xrpl.js/issues/2004).
## NFTokenMint Flags
@@ -59,7 +57,7 @@ Transactions of the NFTokenMint type support additional values in the [`Flags` f
|:--------------|:-------------|:--------------|:------------------------------|
| `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 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`. |
| `tfTrustLine` | `0x00000004` | 4 | **DEPRECATED** Automatically create [trust lines](trust-lines-and-issuing.html) from the issuer to hold transfer fees received from transferring the minted `NFToken`. The [fixRemoveNFTokenAutoTrustLine amendment][] makes it invalid to set this flag. |
| `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. |
@@ -75,6 +73,7 @@ If you want to issue an NFT for another account there are two things you must do
2. When you mint the NFToken, set the `Issuer` field to Account B.
### Example of NFTokenMint with an issuer
```json
{
"TransactionType": "NFTokenMint",
@@ -108,6 +107,7 @@ In addition to errors that can occur for all transactions, {{currentpage.name}}
|:------------------------------|:---------------------------------------------|
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
| `temBAD_NFTOKEN_TRANSFER_FEE` | The `TransferFee` is not within the acceptable range. |
| `temINVALID_FLAG` | The `Flags` value has bits enabled that are not allowed or valid flags. If the [fixRemoveNFTokenAutoTrustLine amendment][] is enabled, the `tfTrustLine` flag causes this error. |
| `temMALFORMED` | The transaction was not validly specified. For example, the `URI` field is longer than 256 bytes. |
| `tecNO_ISSUER` | The `Issuer` refers to an account that does not exist in the ledger. |
| `tecNO_PERMISSION` | The account referenced by the `Issuer` field has not authorized this transaction's sender (using the `NFTokenMinter` setting) to mint on their behalf. |