You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blog/2022/get-ready-for-nfts.md
+6-6Lines changed: 6 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -28,15 +28,15 @@ If you operate an XRP Ledger server but don’t upgrade to version 1.9.2 (or hig
28
28
29
29
If the NonFungibleTokensV1_1 amendment does not become enabled, then your server will not become amendment blocked and should continue to operate.
30
30
31
-
For instructions on upgrading on supported platforms, see [Install `rippled`](https://xrpl.org/install-rippled.html).
31
+
For instructions on upgrading on supported platforms, see [Install `rippled`](/docs/infrastructure/installation).
32
32
33
33
## Amendment Voting Summary
34
34
35
35
For an amendment to the XRP Ledger protocol to become enabled, it must hold **over 80% support** from trusted validators continuously for two weeks.
36
36
37
37
The exact amendment voting calculations depend on the quorum of validators that are currently online and participating in consensus, which means that the exact number of votes in favor of an amendment can fluctuate when validators go temporarily offline. If at any point its support drops below 80%, the timer resets and the amendment must wait a full two weeks again starting when it regains 80%+ support.
38
38
39
-
Previously, the threshold for amendment voting was "at least 80%" but in some cases rounding in the reference server's calculations could cause this condition to be met with slightly below 80%. The [fixAmendmentMajorityCalc amendment](https://xrpl.org/known-amendments.html#fixamendmentmajoritycalc), which activated on 2021-04-08, changed the calculation to be **strictly greater than 80%**. Since there are currently 35 validators in all three [recommended UNLs](https://xrpl.org/about/faq#validators-and-unique-node-lists), and 28/35 is _exactly_ 80%, the threshold for voting to enable an amendment when all validators are online is at least 29 votes in favor.
39
+
Previously, the threshold for amendment voting was "at least 80%" but in some cases rounding in the reference server's calculations could cause this condition to be met with slightly below 80%. The [fixAmendmentMajorityCalc amendment](/resources/known-amendments#fixamendmentmajoritycalc), which activated on 2021-04-08, changed the calculation to be **strictly greater than 80%**. Since there are currently 35 validators in all three [recommended UNLs](/about/faq#validators-and-unique-node-lists), and 28/35 is _exactly_ 80%, the threshold for voting to enable an amendment when all validators are online is at least 29 votes in favor.
40
40
41
41
For a live view of amendment voting, you can use the [XRPScan Amendments Dashboard](https://xrpscan.com/amendments). For more discussion of the voting process, see [this blog by Ripple developer Nik B.](https://dev.to/ripplexdev/xrpl-amendments-to-vote-or-not-to-vote-5l3) as well as the [Amendments documentation](https://xrpl.org/docs/concepts/networks-and-servers/amendments).
42
42
@@ -46,22 +46,22 @@ Non-fungible tokens, or `NFToken` objects, are a new type of object on the XRP L
46
46
47
47
Tokens can have transfer fees that provide their creator with a share of the revenue when the NFT is bought and sold, and they can be part of a set of related NFTs that share a "taxon". Creators can also designate a broker who mints and sells the tokens on their behalf.
48
48
49
-
The [**NonFungibleTokensV1_1** amendment](https://xrpl.org/known-amendments.html#nonfungibletokensv1_1) incorporates the original [NonFungibleTokensV1 amendment](https://xrpl.org/known-amendments.html#nonfungibletokensv1) as well as two bug fixes that were added in later releases, [fixNFTokenDirV1](https://xrpl.org/known-amendments.html#fixnftokendirv1) and [fixNFTokenNegOffer](https://xrpl.org/known-amendments.html#fixnftokennegoffer).
49
+
The [**NonFungibleTokensV1_1** amendment](/resources/known-amendments#nonfungibletokensv1_1) incorporates the original [NonFungibleTokensV1 amendment](/resources/known-amendments#nonfungibletokensv1) as well as two bug fixes that were added in later releases, [fixNFTokenDirV1](/resources/known-amendments#fixnftokendirv1) and [fixNFTokenNegOffer](/resources/known-amendments#fixnftokennegoffer).
50
50
51
-
For more information on NFTs, see the [NFT Conceptual Overview](https://xrpl.org/non-fungible-tokens.html) and related documentation.
51
+
For more information on NFTs, see the [NFT Conceptual Overview](/docs/concepts/tokens/nfts) and related documentation.
52
52
53
53
54
54
## A Word of Caution
55
55
56
56
Since the road to enabling native NFT support has been long, some members of the community have voiced concern regarding pent-up demand for minting NFTs and converting NFTs from the deprecated XLS-14d specification. When the NFT amendment becomes enabled, the onset of NFT minting may cause a temporary increase in traffic on the XRP Ledger network. Possible effects could include:
57
57
58
58
- Outages of individual XRP Ledger servers, especially ones with older or weaker hardware
59
-
- Increased [transaction costs](https://xrpl.org/transaction-cost.html) as a result of network load
59
+
- Increased [transaction costs](/docs/concepts/transactions/transaction-cost) as a result of network load
60
60
- Slower results from popular public API servers, or a higher rate of errors
61
61
62
62
While performance testing has shown that the network is capable of handling the long-term effects of NFTs, the short-term impact on the actual, decentralized Mainnet and all the infrastructure built on top of it is more complex. Alloy Networks, a founding member of the XRP Ledger Foundation, [advises minters](https://twitter.com/alloynetworks/status/1561672954299269120) to be cautious and not mint or convert large collections of NFTs all at once.
63
63
64
-
Users should also be careful not to burn more XRP than they intended on temporarily-elevated transaction costs. If you have an automated system for submitting transactions, now is a good time to review your code to make sure you [properly handle](https://xrpl.org/reliable-transaction-submission.html)`terQUEUED` and other non-final transaction results.
64
+
Users should also be careful not to burn more XRP than they intended on temporarily-elevated transaction costs. If you have an automated system for submitting transactions, now is a good time to review your code to make sure you [properly handle](/docs/concepts/transactions/reliable-transaction-submission)`terQUEUED` and other non-final transaction results.
0 commit comments