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

NFT error codes

Browse Source 
- Also removed some stuff from the NFTokenBurn page which was describing
  changes to the AccountRoot object caused by the NFTs amendment
This commit is contained in:
mDuo13
2022-05-17 16:01:37 -07:00
parent e8446fec54
commit 451c3a1d83
10 changed files with 103 additions and 154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -47,9 +47,12 @@ The `AccountRoot` object has the following fields:
| `PreviousTxnLgrSeq` | Number | UInt32 | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |
| `Sequence` | Number | UInt32 | The [sequence number](basic-data-types.html#account-sequence) of the next valid transaction for this account. |
| `AccountTxnID` | String | Hash256 | _(Optional)_ The identifying hash of the transaction most recently sent by this account. This field must be enabled to use the [`AccountTxnID` transaction field](transaction-common-fields.html#accounttxnid). To enable it, send an [AccountSet transaction with the `asfAccountTxnID` flag enabled](accountset.html#accountset-flags). |
| `BurnedNFTokens` | Number | UInt32 | _(Optional)_ How many total of this account's issued [non-fungible tokens](non-fungible-tokens.html) :not_enabled: have been burned. This number is always equal or less than `MintedNFTokens`. |
| `Domain` | String | Blob | _(Optional)_ A domain associated with this account. In JSON, this is the hexadecimal for the ASCII representation of the domain. [Cannot be more than 256 bytes in length.](https://github.com/ripple/rippled/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
| `EmailHash` | String | Hash128 | _(Optional)_ The md5 hash of an email address. Clients can use this to look up an avatar through services such as [Gravatar](https://en.gravatar.com/). |
| `MessageKey` | String | Blob | _(Optional)_ A public key that may be used to send encrypted messages to this account. In JSON, uses hexadecimal. Must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. |
| `MintedNFTokens` | Number | UInt32 | _(Optional)_ How many total [non-fungible tokens](non-fungible-tokens.html) :not_enabled: have been minted by and on behalf of this account. |
| `NFTokenMinter` | String | AccountID | _(Optional)_ Another account that is authorized to mint [non-fungible tokens](non-fungible-tokens.html) :not_enabled: on behalf of this account. |
| `RegularKey` | String | AccountID | _(Optional)_ The address of a [key pair](cryptographic-keys.html) that can be used to sign transactions for this account instead of the master key. Use a [SetRegularKey transaction][] to change this value. |
| `TicketCount` | Number | UInt32 | _(Optional)_ How many [Tickets](tickets.html) this account owns in the ledger. This is updated automatically to ensure that the account stays within the hard limit of 250 Tickets at a time. This field is omitted if the account has zero Tickets. _(Added by the [TicketBatch amendment][].)_ |
| `TickSize` | Number | UInt8 | _(Optional)_ How many significant digits to use for exchange rates of Offers involving currencies issued by this address. Valid values are `3` to `15`, inclusive. _(Added by the [TickSize amendment][].)_ |

8
content/references/protocol-reference/transactions/transaction-results/tec-codes.md
View File

@@ -15,6 +15,7 @@ For the most part, transactions with `tec` codes take no action other than to de
| Code | Value | Explanation |
|:---------------------------|:------|:----------------------------------------|
| `tecCANT_ACCEPT_OWN_NFTOKEN_OFFER` | 157 | The transaction tried to accept an offer that was placed by the same account to buy or sell a [non-fungible token](non-fungible-tokens.html). _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecCLAIM` | 100 | Unspecified failure, with transaction cost destroyed. |
| `tecCRYPTOCONDITION_ERROR` | 146 | This [EscrowCreate][] or [EscrowFinish][] transaction contained a malformed or mismatched crypto-condition. |
| `tecDIR_FULL` | 121 | The transaction tried to add an object (such as a trust line, Check, Escrow, or Payment Channel) to an account's owner directory, but that account cannot own any more objects in the ledger. |
@@ -27,11 +28,16 @@ For the most part, transactions with `tec` codes take no action other than to de
| `tecINSUF_RESERVE_LINE` | 122 | The transaction failed because the sending account does not have enough XRP to create a new trust line. (See: [Reserves](reserves.html)) This error occurs when the counterparty already has a trust line in a non-default state to the sending account for the same currency. (See `tecNO_LINE_INSUF_RESERVE` for the other case.) |
| `tecINSUF_RESERVE_OFFER` | 123 | The transaction failed because the sending account does not have enough XRP to create a new Offer. (See: [Reserves](reserves.html)) |
| `tecINSUFF_FEE` | 136 | The transaction failed because the sending account does not have enough XRP to pay the [transaction cost](transaction-cost.html) that it specified. (In this case, the transaction processing destroys all of the sender's XRP even though that amount is lower than the specified transaction cost.) This result only occurs if the account's balance decreases _after_ this transaction has been distributed to enough of the network to be included in a consensus set. Otherwise, the transaction fails with [`terINSUF_FEE_B`](ter-codes.html) before being distributed. |
| `tecINSUFFICIENT_FUNDS` | 158 | One of the accounts involved does not hold enough of a necessary asset. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecINSUFFICIENT_PAYMENT` | 161 | The amount specified is not enough to pay all fees involved in the transaction. For example, when trading a non-fungible token, the buy amount may not be enough to pay both the broker fee and the sell amount. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecINSUFFICIENT_RESERVE` | 141 | The transaction would increase the [reserve requirement](reserves.html) higher than the sending account's balance. [SignerListSet][], [PaymentChannelCreate][], [PaymentChannelFund][], and [EscrowCreate][] can return this error code. See [Signer Lists and Reserves](signerlist.html#signer-lists-and-reserves) for more information. |
| `tecINTERNAL` | 144 | Unspecified internal error, with transaction cost applied. This error code should not normally be returned. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tecINVARIANT_FAILED` | 147 | An invariant check failed when trying to execute this transaction. Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tecKILLED` | 150 | The [OfferCreate transaction][] specified the `tfFillOrKill` flag and could not be filled, so it was killed. _(Added by the [fix1578 amendment][].)_ |
| `tecMAX_SEQUENCE_REACHED` | 153 | A sequence number field is already at its maximum. This includes the `MintedNFTokens` field. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecNEED_MASTER_KEY` | 142 | This transaction tried to cause changes that require the master key, such as [disabling the master key or giving up the ability to freeze balances](accountset.html#accountset-flags). [New in: rippled 0.28.0][] |
| `tecNFTOKEN_BUY_SELL_MISMATCH` | 155 | The [NFTokenAcceptOffer transaction][] :not_enabled: attempted to match incompatible offers to buy and sell a non-fungible token. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecNFTOKEN_OFFER_TYPE_MISMATCH` | 156 | One or more of the offers specified in the transaction was not the right type of offer. (For example, a buy offer was specified in the `NFTokenSellOffer` field.) _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecNO_ALTERNATIVE_KEY` | 130 | The transaction tried to remove the only available method of [authorizing transactions](transaction-basics.html#authorizing-transactions). This could be a [SetRegularKey transaction][] to remove the regular key, a [SignerListSet transaction][] to delete a SignerList, or an [AccountSet transaction][] to disable the master key. (Prior to `rippled` 0.30.0, this was called `tecMASTER_DISABLED`.) |
| `tecNO_AUTH` | 134 | The transaction failed because it needs to add a balance on a trust line to an account with the `lsfRequireAuth` flag enabled, and that trust line has not been authorized. If the trust line does not exist at all, `tecNO_LINE` occurs instead. |
| `tecNO_DST` | 124 | The account on the receiving end of the transaction does not exist. This includes Payment and TrustSet transaction types. (It could be created if it received enough XRP.) |
@@ -43,7 +49,9 @@ For the most part, transactions with `tec` codes take no action other than to de
| `tecNO_LINE_REDUNDANT` | 127 | The transaction failed because it tried to set a trust line to its default state, but the trust line did not exist. |
| `tecNO_PERMISSION` | 139 | The sender does not have permission to do this operation. For example, the [EscrowFinish transaction][] tried to release a held payment before its `FinishAfter` time, someone tried to use [PaymentChannelFund][] on a channel the sender does not own, or a [Payment][] tried to deliver funds to an account with the "DepositAuth" flag enabled. |
| `tecNO_REGULAR_KEY` | 131 | The [AccountSet transaction][] tried to disable the master key, but the account does not have another way to [authorize transactions](transaction-basics.html#authorizing-transactions). If [multi-signing](multi-signing.html) is enabled, this code is deprecated and `tecNO_ALTERNATIVE_KEY` is used instead. |
| `tecNO_SUITABLE_NFTOKEN_PAGE` | 154 | ***TODO*** |
| `tecNO_TARGET` | 138 | The transaction referenced an Escrow or PayChannel ledger object that doesn't exist, either because it never existed or it has already been deleted. (For example, another [EscrowFinish transaction][] has already executed the held payment.) Alternatively, the destination account has `asfDisallowXRP` set so it cannot be the destination of this [PaymentChannelCreate][] or [EscrowCreate][] transaction. |
| `tecOBJECT_NOT_FOUND` | 160 | One of the objects specified by this transaction did not exist in the ledger. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecOVERSIZE` | 145 | This transaction could not be processed, because the server created an excessively large amount of [metadata](transaction-metadata.html) when it tried to apply the transaction. [New in: rippled 0.29.0-hf1][] |
| `tecOWNERS` | 132 | The transaction requires that account sending it has a nonzero "owners count", so the transaction cannot succeed. For example, an account cannot enable the [`lsfRequireAuth`](accountset.html#accountset-flags) flag if it has any trust lines or available offers. |
| `tecPATH_DRY` | 128 | The transaction failed because the provided [paths](paths.html) did not have enough liquidity to send anything at all. This could mean that the source and destination accounts are not linked by [trust lines](trust-lines-and-issuing.html). |

1
content/references/protocol-reference/transactions/transaction-results/tef-codes.md
View File

@@ -28,6 +28,7 @@ These codes indicate that the transaction failed and was not included in a ledge
| `tefINVARIANT_FAILED` | An invariant check failed when trying to claim the [transaction cost](transaction-cost.html). Added by the [EnforceInvariants amendment][]. If you can reproduce this error, please [report an issue](https://github.com/ripple/rippled/issues). |
| `tefMASTER_DISABLED` | The transaction was signed with the account's master key, but the account has the `lsfDisableMaster` field set. |
| `tefMAX_LEDGER` | The transaction included a [`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence) parameter, but the current ledger's sequence number is already higher than the specified value. |
| `tefNFTOKEN_IS_NOT_TRANSFERABLE` | The transaction attempted to send a [non-fungible token](non-fungible-tokens.html) to another account, but the `NFToken` has the `lsfTransferable` flag disabled and the transfer would not be to or from the issuer. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tefNO_AUTH_REQUIRED` | The [TrustSet transaction][] tried to mark a trust line as authorized, but the `lsfRequireAuth` flag is not enabled for the corresponding account, so authorization is not necessary. |
| `tefNO_TICKET` | The transaction attempted to use a [Ticket](tickets.html), but the specified `TicketSequence` number does not exist in the ledger, and cannot be created in the future because it is earlier than the sender's current sequence number. |
| `tefNOT_MULTI_SIGNING` | The transaction was [multi-signed](multi-signing.html), but the sending account has no SignerList defined. |

1
content/references/protocol-reference/transactions/transaction-results/tem-codes.md
View File

@@ -20,6 +20,7 @@ These codes indicate that the transaction was malformed, and cannot succeed acco
| `temBAD_FEE` | The transaction improperly specified its `Fee` value, for example by listing a non-XRP currency or some negative amount of XRP. |
| `temBAD_ISSUER` | The transaction improperly specified the `issuer` field of some currency included in the request. |
| `temBAD_LIMIT` | The [TrustSet transaction][] improperly specified the `LimitAmount` value of a trust line. |
| `temBAD_NFTOKEN_TRANSFER_FEE` | The [NFTokenMint transaction][] improperly specified the `TransferFee` field of the transaction. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `temBAD_OFFER` | The [OfferCreate transaction][] specifies an invalid offer, such as offering to trade XRP for itself, or offering a negative amount. |
| `temBAD_PATH` | The [Payment transaction][] specifies one or more [Paths](paths.html) improperly, for example including an issuer for XRP, or specifying an account differently. |
| `temBAD_PATH_LOOP` | One of the [Paths](paths.html) in the [Payment transaction][] was flagged as a loop, so it cannot be processed in a bounded amount of time. |

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

@@ -20,10 +20,10 @@ The `NFTokenAcceptOffer` transaction is used to accept offers to `buy` or `sell`
The mode in which the transaction operates depends on the presence of the `NFTokenSellOffer` and `NFTokenBuyOffer` fields of the transaction:
| `NFTokenSellOffer` | `NFTokenBuyOffer` | Mode |
|:------------|:-----------|:---------|
| ✔️ | ✔️ | Brokered |
| ✔️ | X | Direct |
| X | ✔️ | Direct |
|:-------------------|:------------------|:---------|
| ✔️ | ✔️ | Brokered |
| ✔️ | X | Direct |
| X | ✔️ | Direct |
If neither of those fields is specified, the transaction is malformed and produces a `tem` class error.
@@ -64,25 +64,39 @@ In brokered mode, the `NFTokenAcceptOffer` transaction fails if:
## Fields
{% include '_snippets/tx-fields-intro.md' %}
| Field | JSON Type | [Internal Type][] | Description |
|:----------------|:-----------------|:------------------|:--------------------|
| `TransactionType` | String | UInt16 | Transaction type `NFTokenAcceptOffer`. The integer identifier is 29. |
| `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. |
| Field | JSON Type | [Internal Type][] | Description |
|:-------------------|:--------------------|:------------------|:--------------|
| `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 `NFTokenSellOffer` or the `NFTokenBuyOffer`. In brokered mode, you must specify **both** the `NFTokenSellOffer` and the `NFTokenBuyOffer`.
In direct mode, you must specify **either** the `NFTokenSellOffer` or the `NFTokenBuyOffer` field. In brokered mode, you must specify **both** fields.
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.
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.
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 `NFTokenBuyOffer` and `NFTokenSellOffer` must both specify the same `NFTokenID`; 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`.
## Error Cases
* If there is no entry with the given `SellOffer` or `BuyOffer` index on the ledger, the transaction fails with the result `tecOBJECT_NOT_FOUND`.
In addition to errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following [transaction result codes](transaction-results.html):
| Error Code | Description |
|:-----------------------------------|:----------------------------------------|
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
| `temMALFORMED` | The transaction was not validly formatted. For example, it specified neither `NFTokenSellOffer` nor `NFTokenBuyOffer`, or it specified a negative `NFTokenBrokerFee`. |
| `tecCANT_ACCEPT_OWN_NFTOKEN_OFFER` | The buyer and seller are the same account. |
| `tecEXPIRED` | An offer specified in the transaction has already expired. |
| `tecINSUFFICIENT_FUNDS` | The buyer does not have the full amount they are offering. If the buy amount is specified in XRP, this could be because of the [reserve requirement](reserves.html). If the buy amount is a token, it could be because the token is [frozen](freezes.html). |
| `tecINSUFFICIENT_PAYMENT` | In brokered mode, the buy amount offered is not high enough to pay the `BrokerFee` _and_ the sell cost of the `NFToken`. |
| `tecOBJECT_NOT_FOUND` | One of the offers specified in the transaction does not exist in the ledger. |
| `tecNFTOKEN_BUY_SELL_MISMATCH` | In brokered mode, the two offers are not a valid match. For example, the seller is asking more than the buyer is offering, the buy and sell offer are denominated in different assets, or the seller specified a destination that is not the buyer or the broker. |
| `tecNFTOKEN_OFFER_TYPE_MISMATCH` | The object identified by the `NFTokenBuyOffer` is not actually a buy offer, or the object identified by the `NFTokenSellOffer` is not actually a sell offer. |
| `tecNO_PERMISSION` | The seller does not own the `NFToken` being sold; or the matching offer specifies a different `Destination` account than the account accepting the offer. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

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

@@ -11,153 +11,40 @@ status: not_enabled
The `NFTokenBurn` transaction is used to remove a `NFToken` object from the `NFTokenPage` in which it is being held, effectively removing the token from the ledger (_burning_ it).
The sender of this transaction must be the owner of the `NFToken` to burn; or, if the `NFToken` has the `lsfBurnable` flag enabled, can be the issuer or the issuer's authorized `NFTokenMinter` account instead.
If this operation succeeds, the corresponding `NFToken` is removed. If this operation empties the `NFTokenPage` holding the `NFToken` or results in consolidation, thus removing a `NFTokenPage`, the owner’s reserve requirement is reduced by one.
## Example {{currentpage.name}} JSON
```
```json
{
"TransactionType": "NFTokenBurn",
"Account": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
"Owner": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"Fee": 10,
"NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65"
"TransactionType": "NFTokenBurn",
"Account": "rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2",
"Owner": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
"Fee": 10,
"NFTokenID": "000B013A95F14B0044F78A264E41713C64B5F89242540EE208C3098E00000D65"
}
```
{% include '_snippets/tx-fields-intro.md' %}
<table>
<tr>
<td><strong>Field Name</strong>
</td>
<td><strong>Required?</strong>
</td>
<td><strong>JSON Type</strong>
</td>
<td><strong>Internal Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td><code>TransactionType</code>
</td>
<td>Yes
</td>
<td>string
</td>
<td>UInt16
</td>
<td>The <code>NFTokenBurn</code> transaction type. The integer value is <code>26</code>.
</td>
</tr>
<tr>
<td><code>Account</code>
</td>
<td>Yes
</td>
<td>string
</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>NFTokenMinter</code>).
</td>
</tr>
<tr>
<td><code>Owner</code>
</td>
<td>No
</td>
<td>string
</td>
<td>AccountID
</td>
<td>The account that owns the NFToken to be destroyed. This field is required when an issuer burns a NFToken minted using the `tfBurnable` flag that is owned by another account.
</td>
</tr>
<tr>
<td><code>NFTokenID</code>
</td>
<td>Yes
</td>
<td>string
</td>
<td>Hash256
</td>
<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>
| Field | JSON Type | [Internal Type][] | Description |
|:------------------|:----------|:------------------|:-------------------------|
| `NFTokenID` | String | Hash256 | The `NFToken` to be removed by this transaction. |
| `Owner` | String | AccountID | The owner of the `NFToken` to burn. Only used if that owner is different than the account sending this transaction. The issuer or authorized minter can use this field to burn NFTs that have the `lsfBurnable` flag enabled. |
## Error Cases
## Account Root Enhancements
### 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.
<table>
<tr>
<td><strong>Field Name</strong>
</td>
<td><strong>Required?</strong>
</td>
<td><strong>JSON Type</strong>
</td>
<td><strong>Internal Type</strong>
</td>
<td><strong>Description</strong>
</td>
</tr>
<tr>
<td><code>NFTokenMinter</code>
</td>
<td>
</td>
<td>string
</td>
<td>AccountID
</td>
<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 `NFTokenMinter` field to be set or cleared.
### MintedNFTokens
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.
### BurnedNFTokens
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 in the number of minted and burned tokens, as stored in the `MintedNFTokens` and `BurnedNFTokens` fields respectively, is non-zero cannot be deleted.
In addition to errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following [transaction result codes](transaction-results.html):
| Error Code | Description |
|:-------------------|:--------------------------------------------------------|
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
| `tecNO_ENTRY` | The specified `TokenID` was not found. |
| `tecNO_PERMISSION` | The account does not have permission to burn the token. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

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

@@ -37,8 +37,7 @@ 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. |
| `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. |
| `TokenOffers` | 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 `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.
@@ -46,6 +45,16 @@ It is important to note that if you inadvertently provide a `nft_id` rather than
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.
## Error Cases
In addition to errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following [transaction result codes](transaction-results.html):
| Error Code | Description |
|:-------------------|:--------------------------------------------------------|
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
| `temMALFORMED` | The transaction was not validly formatted. For example, the `TokenOffers` array was empty or contained more than the maximum number of offers that can be canceled at one time. |
| `tecNO_PERMISSION` | At least one of the IDs in the `TokenOffers` field refers to an object that cannot be canceled. For example, the sender of this transaction is not the owner or `Destination` of the offer, or the object was not an `NFTokenOffer` type object. |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

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

@@ -46,6 +46,25 @@ Transactions of the NFTokenCreateOffer type support additional values in the [`F
| `tfSellToken` | `0x00000001` | `1` | If enabled, indicates that the offer is a sell offer. Otherwise, it is a buy offer. |
## Error Cases
In addition to errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following [transaction result codes](transaction-results.html):
| Error Code | Description |
|:---------------------------------|:------------------------------------------|
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
| `temBAD_AMOUNT` | The `Amount` field is not valid. For example, the amount was zero for a buy offer, or the amount is denominated in fungible tokens but the `NFToken` has the [`lsfOnlyXRP` flag](nftoken.html#nftoken-flags) enabled. |
| `temBAD_EXPIRATION` | The specified `Expiration` time is invalid (for example, `0`). |
| `tecDIR_FULL` | The sender already owns too many objects in the ledger, or there are already too many offers to buy or sell this token. |
| `tecEXPIRED` | The specified `Expiration` time has already passed. |
| `tecFROZEN` | The `Amount` is denominated in fungible tokens, but one of the trust lines that would receive tokens from this offer is [frozen](freezes.html). This could be the seller's trust line or the `NFToken`'s issuer's trust line (if the `NFToken` has a transfer fee). |
| `tecINSUFFICIENT_RESERVE` | The sender does not have enough XRP to meet the [reserve requirement](reserves.html) after placing this offer. |
| `tecNO_DST` | The account specified in the `Destination` field does not exist in the ledger. |
| `tecNO_ENTRY` | The `NFToken` is not owned by the expected account. |
| `tecNO_ISSUER` | The issuer specified in the `Amount` field does not exist. |
| `tecNO_LINE` | The `Amount` field is denominated in fungible tokens, but the `NFToken`'s issuer does not have a trust line for those tokens and the `NFToken` does not have the [`lsfTrustLine` flag](nftoken.html#nftoken-flags) enabled. |
| `tecUNFUNDED_OFFER` | For a buy offer, the sender does have the funds specified in the `Amount` field available. If the `Amount` is XRP, this could be due to the reserve requirement; if the `Amount` is denominated in fungible tokens, this could be because they are [frozen](freezes.html). |
| `tefNFTOKEN_IS_NOT_TRANSFERABLE` | The `NFToken` has the [`lsfTransferable` flag](nftoken.html#nftoken-flags) disabled and this transaction would not transfer the `NFToken` to or from the issuer. |

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

@@ -106,12 +106,18 @@ This transaction assumes that the issuer, `rNCFjv8Ek5oDrNiMJ3pw6eLLFtMjZLJnf2`,
## Error Cases
- 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 `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.
In addition to errors that can occur for all transactions, {{currentpage.name}} transactions can result in the following [transaction result codes](transaction-results.html):
| Error Code | Description |
|:------------------------------|:---------------------------------------------|
| `temDISABLED` | The [NonFungibleTokensV1 amendment][] is not enabled. |
| `temBAD_NFTOKEN_TRANSFER_FEE` | The `TransferFee` is not within the acceptable range. |
| `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. |
| `tecINSUFFICIENT_RESERVE` | The owner would not meet the updated [reserve requirement](reserves.html) after minting the token. 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. |
| `tecMAX_SEQUENCE_REACHED` | The `Issuer`'s `MintedNFTokens` field is already at its maximum. 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' %}