cli conflict resolution

This commit is contained in:
ddawson
2022-11-22 13:59:42 -08:00
128 changed files with 1665 additions and 2167 deletions

File diff suppressed because one or more lines are too long

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 256 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 619 KiB

View File

@@ -53,7 +53,6 @@ Request('account_lines', {
Request('account_nfts', {
description: "Retrieves NFTs owned by an account.",
link: "account_nfts.html",
status: "not_enabled",
body: {
"command": "account_nfts",
"account": "rsuHaTvJh1bDmDoxX9QcKP7HEBSBt4XsHx",
@@ -417,7 +416,6 @@ Request('deposit_authorized', {
Request('nft_buy_offers', {
description: "Retrieves offers to buy a given NFT.",
link: "nft_buy_offers.html",
status: "not_enabled",
body: {
"command": "nft_buy_offers",
"nft_id": "00090000D0B007439B080E9B05BF62403911301A7B1F0CFAA048C0A200000007",
@@ -428,7 +426,6 @@ Request('nft_buy_offers', {
Request('nft_sell_offers', {
description: "Retrieves offers to sell a given NFT.",
link: "nft_sell_offers.html",
status: "not_enabled",
body: {
"command": "nft_sell_offers",
"nft_id": "00090000D0B007439B080E9B05BF62403911301A7B1F0CFAA048C0A200000007",

View File

@@ -56,9 +56,7 @@ function rippleTestNetCredentials(url, altnet_name) {
destination: test_wallet.address,
memos: [
{
Memo: {
MemoData: xrpl.convertStringToHex("xrpl.org-faucet"),
},
data: xrpl.convertStringToHex("xrpl.org-faucet"),
},
],
}),

View File

@@ -0,0 +1,49 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import AccountObjects
from xrpl.utils import drops_to_xrp, ripple_time_to_datetime
# Retreive all escrows created or received by an account, formatted
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to the testnetwork
account_address = "r9CEVt4Cmcjt68ME6GKyhf2DyEGo2rG8AW"
all_escrows_dict = {}
sent_escrows = []
received_escrows = []
# Build and make request
req = AccountObjects(account=account_address, ledger_index="validated", type="escrow")
response = client.request(req)
# Return account escrows
escrows = response.result["account_objects"]
# Loop through result and parse account escrows
for escrow in escrows:
escrow_data = {}
if isinstance(escrow["Amount"], str):
escrow_data["escrow_id"] = escrow["index"]
escrow_data["sender"] = escrow["Account"]
escrow_data["receiver"] = escrow["Destination"]
escrow_data["amount"] = str(drops_to_xrp(escrow["Amount"]))
if "PreviousTxnID" in escrow:
escrow_data["prex_txn_id"] = escrow["PreviousTxnID"]
if "FinishAfter" in escrow:
escrow_data["redeem_date"] = str(ripple_time_to_datetime(escrow["FinishAfter"]))
if "CancelAfter" in escrow:
escrow_data["expiry_date"] = str(ripple_time_to_datetime(escrow["CancelAfter"]))
if "Condition" in escrow:
escrow_data["condition"] = escrow["Condition"]
# Sort escrows
if escrow_data["sender"] == account_address:
sent_escrows.append(escrow_data)
else:
received_escrows.append(escrow_data)
# Add lists to escrow dict
all_escrows_dict["sent"] = sent_escrows
all_escrows_dict["received"] = received_escrows
print(all_escrows_dict)

View File

@@ -0,0 +1,29 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import EscrowCancel
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.wallet import generate_faucet_wallet
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to the testnetwork
# Cancel an escrow
# An Escrow can only be canceled if it was created with a CancelAfter time
escrow_sequence = 30215126
# Sender wallet object
sender_wallet = generate_faucet_wallet(client=client)
# Build escrow cancel transaction
cancel_txn = EscrowCancel(account=sender_wallet.classic_address, owner=sender_wallet.classic_address, offer_sequence=escrow_sequence)
# Sign and submit transaction
stxn = safe_sign_and_autofill_transaction(cancel_txn, sender_wallet, client)
stxn_response = send_reliable_submission(stxn, client)
# Parse response and return result
stxn_result = stxn_response.result
# Parse result and print out the transaction result and transaction hash
print(stxn_result["meta"]["TransactionResult"])
print(stxn_result["hash"])

View File

@@ -0,0 +1,54 @@
import json
from datetime import datetime, timedelta
from xrpl.clients import JsonRpcClient
from xrpl.models import EscrowCreate
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.utils import datetime_to_ripple_time, xrp_to_drops
from xrpl.wallet import generate_faucet_wallet
# Create Escrow
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to client
amount_to_escrow = 10.000
receiver_addr = "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe" # Example: send back to Testnet Faucet
# Escrow will be available to claim after 3 days
claim_date = datetime_to_ripple_time(datetime.now() + timedelta(days=3))
# Escrow will expire after 5 days
expiry_date = datetime_to_ripple_time(datetime.now() + timedelta(days=5))
# Optional field
# You can optionally use a Crypto Condition to allow for dynamic release of funds. For example:
condition = "A02580205A0E9E4018BE1A6E0F51D39B483122EFDF1DDEF3A4BE83BE71522F9E8CDAB179810120" # do not use in production
# sender wallet object
sender_wallet = generate_faucet_wallet(client=client)
# Build escrow create transaction
create_txn = EscrowCreate(
account=sender_wallet.classic_address,
amount=xrp_to_drops(amount_to_escrow),
destination=receiver_addr,
finish_after=claim_date,
cancel_after=expiry_date,
condition=condition)
# Sign and send transaction
stxn = safe_sign_and_autofill_transaction(create_txn, sender_wallet, client)
stxn_response = send_reliable_submission(stxn, client)
# Return result of transaction
stxn_result = stxn_response.result
# Parse result and print out the neccesary info
print(stxn_result["Account"])
print(stxn_result["Sequence"])
print(stxn_result["meta"]["TransactionResult"])
print(stxn_result["hash"])

View File

@@ -0,0 +1,42 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import EscrowFinish
from xrpl.transaction import (safe_sign_and_autofill_transaction,
send_reliable_submission)
from xrpl.wallet import Wallet, generate_faucet_wallet
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to the testnetwork
# Complete an escrow
# Cannot be called until the finish time is reached
# Required fields (modify to match an escrow you create)
escrow_creator = generate_faucet_wallet(client=client).classic_address
escrow_sequence = 27641268
# Optional fields
# Crypto condition that must be met before escrow can be completed, passed on escrow creation
condition = "A02580203882E2EB9B44130530541C4CC360D079F265792C4A7ED3840968897CB7DF2DA1810120"
# Crypto fulfillment of the condtion
fulfillment = "A0228020AED2C5FE4D147D310D3CFEBD9BFA81AD0F63CE1ADD92E00379DDDAF8E090E24C"
# Sender wallet object
sender_wallet = generate_faucet_wallet(client=client)
# Build escrow finish transaction
finish_txn = EscrowFinish(account=sender_wallet.classic_address, owner=escrow_creator, offer_sequence=escrow_sequence, condition=condition, fulfillment=fulfillment)
# Sign transaction with wallet
stxn = safe_sign_and_autofill_transaction(finish_txn, sender_wallet, client)
# Send transaction and wait for response
stxn_response = send_reliable_submission(stxn, client)
# Parse response and return result
stxn_result = stxn_response.result
# Parse result and print out the transaction result and transaction hash
print(stxn_result["meta"]["TransactionResult"])
print(stxn_result["hash"])

View File

@@ -0,0 +1,19 @@
import random
from os import urandom
from cryptoconditions import PreimageSha256
# """Generate a condition and fulfillment for escrows"""
# Generate a random preimage with at least 32 bytes of cryptographically-secure randomness.
secret = urandom(32)
# Generate cryptic image from secret
fufill = PreimageSha256(preimage=secret)
# Parse image and return the condition and fulfillment
condition = str.upper(fufill.condition_binary.hex()) # conditon
fulfillment = str.upper(fufill.serialize_binary().hex()) # fulfillment
# Print condition and fulfillment
print(f"condition: {condition} \n fulfillment {fulfillment}")

View File

@@ -0,0 +1,2 @@
xrpl-py
cryptoconditions

View File

@@ -0,0 +1,24 @@
from xrpl.clients import JsonRpcClient
from xrpl.models import Tx
client = JsonRpcClient("https://s.altnet.rippletest.net:51234") # Connect to the testnetwork
prev_txn_id = "" # should look like this '84503EA84ADC4A65530C6CC91C904FCEE64CFE2BB973C023476184288698991F'
# Return escrow seq from `PreviousTxnID` for finishing or cancelling escrows
if prev_txn_id == "":
print("No transaction id provided. Use create_escrow.py to generate an escrow transaction, then you can look it up by modifying prev_txn_id to use that transaction's id.")
# Build and send query for PreviousTxnID
req = Tx(transaction=prev_txn_id)
response = client.request(req)
# Return the result
result = response.result
# Print escrow sequence if available
if "Sequence" in result:
print(f'escrow sequence: {result["Sequence"]}')
# Use escrow ticket sequence if escrow sequence is not available
if "TicketSequence" in result:
print(f'escrow ticket sequence: {result["TicketSequence"]}')

View File

@@ -1,3 +0,0 @@
# NFToken Test Harness
Build an interface that can mint and trade non-fungible tokens (NFTs) on the NFT-Devnet.

View File

@@ -1,420 +0,0 @@
<html>
<head>
<script src='https://unpkg.com/xrpl@2.2.1/build/xrpl-latest-min.js'></script>
<script>
if (typeof module !== "undefined") var xrpl = require('xrpl')
//***************************
//** Mint Token *************
//***************************
async function mintToken() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
// Note that you must convert the token URL to a hexadecimal
// value for this transaction.
// ----------------------------------------------------------
const transactionBlob = {
TransactionType: "NFTokenMint",
Account: wallet.classicAddress,
URI: xrpl.convertStringToHex(tokenUrl.value),
Flags: parseInt(flags.value),
NFTokenTaxon: 0 //Required, but if you have no use for it, set to zero.
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})
const nfts = await client.request({
method: "account_nfts",
account: wallet.classicAddress
})
console.log(nfts)
// Check transaction results -------------------------------------------------
console.log("Transaction result:", tx.result.meta.TransactionResult)
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
} //End of mintToken
//***************************
//** Get Tokens *************
//***************************
async function getTokens() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
const nfts = await client.request({
method: "account_nfts",
account: wallet.classicAddress
})
console.log(nfts)
client.disconnect()
} //End of getTokens
//***************************
//** Burn Token *************
//***************************
async function burnToken() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
// Prepare transaction -------------------------------------------------------
const transactionBlob = {
"TransactionType": "NFTokenBurn",
"Account": wallet.classicAddress,
"NFTokenID": tokenId.value
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})
const nfts = await client.request({
method: "account_nfts",
account: wallet.classicAddress
})
console.log(nfts)
// Check transaction results -------------------------------------------------
console.log("Transaction result:", tx.result.meta.TransactionResult)
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
}
// End of burnToken()
//********************************
//** Create Sell Offer ***********
//********************************
async function createSellOffer() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
// Prepare transaction -------------------------------------------------------
const transactionBlob = {
"TransactionType": "NFTokenCreateOffer",
"Account": wallet.classicAddress,
"NFTokenID": tokenId.value,
"Amount": amount.value,
"Flags": parseInt(flags.value)
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})//AndWait
console.log("***Sell Offers***")
let nftSellOffers
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
nft_id:tokenId.value
})
} catch (err) {
console.log("No sell offers.")
}
console.log(JSON.stringify(nftSellOffers,null,2))
console.log("***Buy Offers***")
let nftBuyOffers
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
nft_id:tokenId.value })
} catch (err) {
console.log("No buy offers.")
}
console.log(JSON.stringify(nftBuyOffers,null,2))
// Check transaction results -------------------------------------------------
console.log("Transaction result:",
JSON.stringify(tx.result.meta.TransactionResult, null, 2))
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
// End of createSellOffer()
}
//********************************
//** Create Buy Offer ***********
//********************************
async function createBuyOffer() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
// Prepare transaction -------------------------------------------------------
const transactionBlob = {
"TransactionType": "NFTokenCreateOffer",
"Account": wallet.classicAddress,
"Owner": owner.value,
"NFTokenID": tokenId.value,
"Amount": amount.value,
"Flags": parseInt(flags.value)
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})
console.log("***Sell Offers***")
let nftSellOffers
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
nft_id: tokenId.value
})
} catch (err) {
console.log("No sell offers.")
}
console.log(JSON.stringify(nftSellOffers,null,2))
console.log("***Buy Offers***")
let nftBuyOffers
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
nft_id: tokenId.value })
} catch (err) {
console.log("No buy offers.")
}
console.log(JSON.stringify(nftBuyOffers,null,2))
// Check transaction results -------------------------------------------------
console.log("Transaction result:",
JSON.stringify(tx.result.meta.TransactionResult, null, 2))
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
// End of createBuyOffer()
}
//***************************
//** Cancel Offer ***********
//***************************
async function cancelOffer() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
const tokenOfferID = tokenOfferIndex.value
const tokenOffers = [tokenOfferID]
// Prepare transaction -------------------------------------------------------
const transactionBlob = {
"TransactionType": "NFTokenCancelOffer",
"Account": wallet.classicAddress,
"NFTokenOffers": tokenOffers
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})
console.log("***Sell Offers***")
let nftSellOffers
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
nft_id:tokenId.value
})
} catch (err) {
console.log("No sell offers.")
}
console.log(JSON.stringify(nftSellOffers,null,2))
console.log("***Buy Offers***")
let nftBuyOffers
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
nft_id:tokenId.value })
} catch (err) {
console.log("No buy offers.")
}
console.log(JSON.stringify(nftBuyOffers,null,2))
// Check transaction results -------------------------------------------------
console.log("Transaction result:",
JSON.stringify(tx.result.meta.TransactionResult, null, 2))
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
// End of cancelOffer()
}
//***************************
//** Get Offers *************
//***************************
async function getOffers() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
console.log("***Sell Offers***")
let nftSellOffers
try {
nftSellOffers = await client.request({
method: "nft_sell_offers",
nft_id: tokenId.value
})
} catch (err) {
console.log("No sell offers.")
}
console.log(JSON.stringify(nftSellOffers,null,2))
console.log("***Buy Offers***")
let nftBuyOffers
try {
nftBuyOffers = await client.request({
method: "nft_buy_offers",
nft_id:tokenId.value })
} catch (err) {
console.log("No buy offers.")
}
console.log(JSON.stringify(nftBuyOffers,null,2))
client.disconnect()
// End of getOffers()
}
//***************************
//** Accept Sell Offer ******
//***************************
async function acceptSellOffer() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
// Prepare transaction -------------------------------------------------------
const transactionBlob = {
"TransactionType": "NFTokenAcceptOffer",
"Account": wallet.classicAddress,
"NFTokenSellOffer": tokenOfferIndex.value,
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})
const nfts = await client.request({
method: "account_nfts",
account: wallet.classicAddress
})
console.log(JSON.stringify(nfts,null,2))
// Check transaction results -------------------------------------------------
console.log("Transaction result:",
JSON.stringify(tx.result.meta.TransactionResult, null, 2))
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
// End of acceptSellOffer()
}
//***************************
//** Accept Buy Offer ******
//***************************
async function acceptBuyOffer() {
const wallet = xrpl.Wallet.fromSeed(secret.value)
const client = new xrpl.Client("wss://xls20-sandbox.rippletest.net:51233")
await client.connect()
console.log("Connected to Sandbox")
// Prepare transaction -------------------------------------------------------
const transactionBlob = {
"TransactionType": "NFTokenAcceptOffer",
"Account": wallet.classicAddress,
"NFTokenBuyOffer": tokenOfferIndex.value
}
// Submit signed blob --------------------------------------------------------
const tx = await client.submitAndWait(transactionBlob,{wallet})
const nfts = await client.request({
method: "account_nfts",
account: wallet.classicAddress
})
console.log(JSON.stringify(nfts,null,2))
// Check transaction results -------------------------------------------------
console.log("Transaction result:",
JSON.stringify(tx.result.meta.TransactionResult, null, 2))
console.log("Balance changes:",
JSON.stringify(xrpl.getBalanceChanges(tx.result.meta), null, 2))
client.disconnect()
// End of submitTransaction()
}
</script>
<title>NFToken Tester</title>
</head>
<body>
<h1>NFToken Tester</h1>
<form id="theForm">
<p>
<button type="button" onClick="mintToken()">Mint Token</button>&nbsp;&nbsp;
<button type="button" onClick="getTokens()">Get Tokens</button>&nbsp;&nbsp;
<button type="button" onClick="burnToken()">Burn Token</button>&nbsp;&nbsp;
</p>
<p>
<button type="button" onClick="createSellOffer()">Create Sell Offer</button>&nbsp;&nbsp;
<button type="button" onClick="createBuyOffer()">Create Buy Offer</button>&nbsp;&nbsp;
<button type="button" onClick="getOffers()">Get Offers</button>
</p>
<p>
<button type="button" onClick="acceptSellOffer()">Accept Sell Offer</button>&nbsp;&nbsp;
<button type="button" onClick="acceptBuyOffer()">Accept Buy Offer</button>&nbsp;&nbsp;
<button type="button" onClick="cancelOffer()">Cancel Offer</button>&nbsp;&nbsp;
</p>
<table>
<tr>
<td align="right">Account</td>
<td><input type="text" id="account" value="" size="40" /></td>
</tr>
<tr>
<td align="right">Secret</td>
<td><input type="text" id="secret" value="" size="40" /></td>
</tr>
<tr>
<td align="right">Token URL</td>
<td><input type="text" id="tokenUrl"
value = "ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf4dfuylqabf3oclgtqy55fbzdi" size="80"/>
</td>
</tr>
<tr>
<td align="right">Flags</td>
<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>
</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>
</tr>
<tr>
<td align="right">Owner</td>
<td><input type="text" id="owner" value="" size="80"/></td>
</tr>
</table>
</form>
</body>
</html>

View File

@@ -1 +0,0 @@
_NFTのXLS-20規格 (現在は有効ではありません) は、テストネットワークで使用できる予備的な実装がありますが、XRP Ledgerプロトコルの[Amendment(修正案)](amendments.html)としてまだ利用可能ではありません。将来のXRP Ledgerのリリースに修正案が含まれる可能性があります。_

View File

@@ -1 +0,0 @@
_Non-fungible token functionality is part of the [NonFungibleTokensV1 amendment][] :not_enabled: to the XRP Ledger protocol. You can use these functions on the [NFT-Devnet](parallel-networks.html) now, but they are not yet available on the production Mainnet._

View File

@@ -225,6 +225,7 @@
"MultiSignReserve",
"NegativeUNL",
"NonFungibleTokensV1",
"NonFungibleTokensV1_1",
"OwnerPaysFee",
"PayChan",
"RequireFullyCanonicalSig",

View File

@@ -16,12 +16,9 @@ labels:
|:----------------------------------|:-----------|:------------------------------------|
| [fixTrustLinesToSelf][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | 未定 | [開発中: 未定]( "BADGE_LIGHTGREY") |
| [fixNFTokenNegOffer][] | v1.9.2 | [投票中: 未定](https://xrpl.org/blog/2022/rippled-1.9.2.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") |
| [CheckCashMakesTrustLine][] | v1.8.0 | [投票中: 未定](https://xrpl.org/blog/2021/rippled-1.8.1.html "BADGE_80d0e0") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [予定: 2022/10/31](https://xrpl.org/blog/2022/expandedsignerlist-enabled-and-nfts-approaching.html "BADGE_BLUE") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [予定: 2022/10/27](https://xrpl.org/blog/2022/expandedsignerlist-enabled-and-nfts-approaching.html "BADGE_BLUE") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [有効: 2022/10/31](https://livenet.xrpl.org/transactions/251242639A640CD9287A14A476E7F7C20BA009FDE410570926BAAF29AA05CEDE "BADGE_GREEN") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [有効: 2022/10/27](https://livenet.xrpl.org/transactions/2A67DB4AC65D688281B76334C4B52038FD56931694A6DD873B5CCD9B970AD57C "BADGE_GREEN") |
| [ExpandedSignerList][] | v1.9.1 | [有効: 2022/10/13](https://livenet.xrpl.org/transactions/802E2446547BB86397217E32A78CB9857F21B048B91C81BCC6EF837BE9C72C87 "BADGE_GREEN") |
| [NegativeUNL][] | v1.7.3 | [有効: 2021/11/21](https://livenet.xrpl.org/transactions/1500FADB73E7148191216C53040990E829C7110788B26E7F3246CB3660769EBA "BADGE_GREEN") |
| [fixRmSmallIncreasedQOffers][] | v1.7.2 | [有効: 2021/11/18](https://livenet.xrpl.org/transactions/1F37BA0502576DD7B5464F47641FA95DEB55735EC2663269DFD47810505478E7 "BADGE_GREEN") |
@@ -65,6 +62,9 @@ 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") |
| [fixNFTokenNegOffer][] | v1.9.2 | [廃止: 削除未定]( "BADGE_RED") |
| [fixNFTokenDirV1][] | v1.9.1 | [廃止: 削除未定]( "BADGE_RED") |
| [NonFungibleTokensV1][] | v1.9.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") |
@@ -432,12 +432,12 @@ Checksトランザクションがアカウントのメタデータに影響を
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| 0285B7E5E08E1A8E4C15636F0591D87F73CB6A7B6452A932AD72BBC8E5D1CBE3 | 投票中 |
| 0285B7E5E08E1A8E4C15636F0591D87F73CB6A7B6452A932AD72BBC8E5D1CBE3 | 廃止 |
<!-- TODO: translate description -->
This amendment fixes an off-by-one error that occurred in some corner cases when determining which `NFTokenPage` a `NFToken` object belongs on. It also adjusts the constraints of `NFTokenPage` invariant checks, so that certain error cases fail with a suitable error code such as `tecNO_SUITABLE_TOKEN_PAGE` instead of failing with a `tecINVARIANT_FAILED` error code.
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. To avoid bugs, the fixNFTokenDirV1 amendment should be enabled before the NonFungibleTokensV1 amendment.
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. This amendment is obsolete because its effects are included as part of [NonFungibleTokensV1_1][].
## fixNFTokenNegOffer
@@ -445,12 +445,12 @@ This amendment has no effect unless the [NonFungibleTokensV1][] amendment is ena
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| 36799EA497B1369B170805C078AEFE6188345F9B3E324C21E9CA3FF574E3C3D6 | 投票中 |
| 36799EA497B1369B170805C078AEFE6188345F9B3E324C21E9CA3FF574E3C3D6 | 廃止 |
<!-- TODO: translate description -->
This amendment fixes a bug in the [NonFungibleTokensV1][] amendment code where NFTs could be traded for negative amounts of money. Without this fix, users could place and accept an offer to buy or sell an NFT for a negative amount of money, which resulted in the person "buying" the NFT also receiving money from the "seller". With this amendment, NFT offers for negative amounts are considered invalid.
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. To avoid bugs, all the NFT-related amendments should be enabled together using [NonFungibleTokensV1_1][].
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. This amendment is obsolete because its effects are included as part of [NonFungibleTokensV1_1][].
## fixPayChanRecipientOwnerDir
@@ -483,7 +483,7 @@ This amendment has no known impact on transaction processing.
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| DF8B4536989BDACE3F934F29423848B9F1D76D09BE6A1FCFE7E7F06AA26ABEAD | 予定 |
| DF8B4536989BDACE3F934F29423848B9F1D76D09BE6A1FCFE7E7F06AA26ABEAD | 有効 |
<!-- TODO: translate amendment description -->
@@ -664,12 +664,12 @@ Implements a "Negative UNL" system, where the network can track which validators
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| 3C43D9A973AA4443EF3FC38E42DD306160FBFFDAB901CD8BAA15D09F2597EB87 | 開発中 |
| 3C43D9A973AA4443EF3FC38E42DD306160FBFFDAB901CD8BAA15D09F2597EB87 | 廃止 |
<!-- TODO: translate description -->
Adds native support for non-fungible tokens. Standards Draft: [XLS-20d](https://github.com/XRPLF/XRPL-Standards/discussions/46). <!-- SPELLING_IGNORE: xls, 20d -->
**Warning:** There is a known issue with this amendment that can cause `tecINVARIANT_FAILED` errors to appear in the ledger. The [fixNFTokenDirV1][] amendment fixes these issues and should be enabled before the NonFungibleTokensV1 amendment to avoid problems.
**Warning:** There are several known issues with this amendment including one that can cause `tecINVARIANT_FAILED` errors to appear in the ledger. It has been replaced by the [NonFungibleTokensV1_1 amendment][].
This amendment adds 5 new transaction types:
@@ -694,18 +694,20 @@ It also modifies the [AccountSet transaction][] type to allow you to set the `NF
| Amendment ID | ステータス |
|:-----------------------------------------------------------------|:---------|
| 32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 | 予定 |
| 32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 | 有効 |
<!-- TODO: translate description -->
This amendment's only effect is to enable three other amendments at the same time:
Adds native support for [non-fungible tokens](non-fungible-tokens.html), including fixes to several issues that were discovered after [NonFungibleTokensV1][].
This amendment combines the effects of the following amendments, rendering the individual amendments obsolete:
- [NonFungibleTokensV1][]
- [fixNFTokenNegOffer][]
- [fixNFTokenDirV1][]
This ensures that the base NFT functionality and the related fixes all become enabled together, with no chance for the buggy functionality to become enabled without the fixes and no delay needed in between.
It has no other effects.
Validators who wish to enable Non-Fungible Tokens (NFTs) on the XRP Ledger should vote in favor of this amendment and not the others.
**Caution:** The [fixRemoveNFTokenAutoTrustLine][] fixes an known issue with this amendment. When creating a new test network, you should make sure that these amendments should be enabled together or the fix amendment is enabled first.
## OwnerPaysFee

View File

@@ -16,12 +16,9 @@ The following is a comprehensive list of all known [amendments](amendments.html)
|:----------------------------------|:-----------|:------------------------------|
| [fixTrustLinesToSelf][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [OwnerPaysFee][] | TBD | [In Development: TBD]( "BADGE_LIGHTGREY") |
| [fixNFTokenNegOffer][] | v1.9.2 | [Open for Voting: TBD](https://xrpl.org/blog/2022/rippled-1.9.2.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") |
| [CheckCashMakesTrustLine][] | v1.8.0 | [Open for Voting: TBD](https://xrpl.org/blog/2021/rippled-1.8.1.html "BADGE_80d0e0") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [Expected: 2022-10-31](https://xrpl.org/blog/2022/expandedsignerlist-enabled-and-nfts-approaching.html "BADGE_BLUE") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [Expected: 2022-10-27](https://xrpl.org/blog/2022/expandedsignerlist-enabled-and-nfts-approaching.html "BADGE_BLUE") |
| [NonFungibleTokensV1_1][] | v1.9.2 | [Enabled: 2022-10-31](https://livenet.xrpl.org/transactions/251242639A640CD9287A14A476E7F7C20BA009FDE410570926BAAF29AA05CEDE "BADGE_GREEN") |
| [fixRemoveNFTokenAutoTrustLine][] | v1.9.4 | [Enabled: 2022-10-27](https://livenet.xrpl.org/transactions/2A67DB4AC65D688281B76334C4B52038FD56931694A6DD873B5CCD9B970AD57C "BADGE_GREEN") |
| [ExpandedSignerList][] | v1.9.1 | [Enabled: 2022-10-13](https://livenet.xrpl.org/transactions/802E2446547BB86397217E32A78CB9857F21B048B91C81BCC6EF837BE9C72C87 "BADGE_GREEN") |
| [NegativeUNL][] | v1.7.3 | [Enabled: 2021-11-21](https://livenet.xrpl.org/transactions/1500FADB73E7148191216C53040990E829C7110788B26E7F3246CB3660769EBA "BADGE_GREEN") |
| [fixRmSmallIncreasedQOffers][] | v1.7.2 | [Enabled: 2021-11-18](https://livenet.xrpl.org/transactions/1F37BA0502576DD7B5464F47641FA95DEB55735EC2663269DFD47810505478E7 "BADGE_GREEN") |
@@ -65,6 +62,9 @@ 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") |
| [fixNFTokenNegOffer][] | v1.9.2 | [Obsolete: To Be Removed]( "BADGE_RED") |
| [fixNFTokenDirV1][] | v1.9.1 | [Obsolete: To Be Removed]( "BADGE_RED") |
| [NonFungibleTokensV1][] | v1.9.0 | [Obsolete: To Be Removed]( "BADGE_RED") |
| [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") |
@@ -126,7 +126,7 @@ Although this amendment is enabled, it has no effect unless the [SusPay](#suspay
| Amendment | CryptoConditionsSuite |
|:----------|:-----------|
| Amendment ID | 86E83A7D2ECE3AD5FA87AB2195AE015C950469ABF0B72EAACED318F74886AE90 |
| Status | Obsolete |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
@@ -529,13 +529,13 @@ With this amendment enabled, a SetRegularKey transaction cannot set the regular
| Amendment | fixNFTokenDirV1 |
|:----------|:-----------|
| Amendment ID | 0285B7E5E08E1A8E4C15636F0591D87F73CB6A7B6452A932AD72BBC8E5D1CBE3 |
| Status | Open for Voting |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
This amendment fixes an off-by-one error that occurred in some corner cases when determining which `NFTokenPage` a `NFToken` object belongs on. It also adjusts the constraints of `NFTokenPage` invariant checks, so that certain error cases fail with a suitable error code such as `tecNO_SUITABLE_TOKEN_PAGE` instead of failing with a `tecINVARIANT_FAILED` error code.
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. To avoid bugs, all the NFT-related amendments should be enabled together using [NonFungibleTokensV1_1][].
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. This amendment is obsolete because its effects are included as part of [NonFungibleTokensV1_1][].
## fixNFTokenNegOffer
@@ -550,7 +550,7 @@ This amendment has no effect unless the [NonFungibleTokensV1][] amendment is ena
This amendment fixes a bug in the [NonFungibleTokensV1][] amendment code where NFTs could be traded for negative amounts of money. Without this fix, users could place and accept an offer to buy or sell a `NFToken` for a negative amount of money, which resulted in the person "buying" the NFT also receiving money from the "seller". With this amendment, NFT offers for negative amounts are considered invalid.
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. To avoid bugs, all the NFT-related amendments should be enabled together using [NonFungibleTokensV1_1][].
This amendment has no effect unless the [NonFungibleTokensV1][] amendment is enabled. This amendment is obsolete because its effects are included as part of [NonFungibleTokensV1_1][].
## fixPayChanRecipientOwnerDir
@@ -589,7 +589,7 @@ This amendment has no known impact on transaction processing.
| Amendment | fixRemoveNFTokenAutoTrustLine |
|:----------|:-----------|
| Amendment ID | DF8B4536989BDACE3F934F29423848B9F1D76D09BE6A1FCFE7E7F06AA26ABEAD |
| Status | Expected |
| Status | Enabled |
| Default Vote (Latest stable release) | Yes |
| Pre-amendment functionality retired? | No |
@@ -597,11 +597,9 @@ Removes the `tfTrustLine` setting on [non-fungible tokens](non-fungible-tokens.h
Without this amendment, an attacker could create new, meaningless fungible tokens and sell a `NFToken` 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 does not change the code for `NFToken` objects that have already been minted. On test networks that enabled NFT support before this amendment, 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][].
This amendment has no effect unless either [NonFungibleTokensV1][] or [NonFungibleTokensV1_1][] is enabled. To protect issuers, this amendment should be enabled _before_ [NonFungibleTokensV1][] or [NonFungibleTokensV1_1][].
## fixRmSmallIncreasedQOffers
@@ -802,13 +800,13 @@ Implements a "Negative UNL" system, where the network can track which validators
| Amendment | NonFungibleTokensV1 |
|:----------|:-----------|
| Amendment ID | 3C43D9A973AA4443EF3FC38E42DD306160FBFFDAB901CD8BAA15D09F2597EB87 |
| Status | Open for Voting |
| Status | Obsolete |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
Adds native support for non-fungible tokens. Standards Draft: [XLS-20d](https://github.com/XRPLF/XRPL-Standards/discussions/46). <!-- SPELLING_IGNORE: xls, 20d -->
Adds native support for [non-fungible tokens](non-fungible-tokens.html). Standards Draft: [XLS-20d](https://github.com/XRPLF/XRPL-Standards/discussions/46). <!-- SPELLING_IGNORE: xls, 20d -->
**Warning:** There is a known issue with this amendment that can cause `tecINVARIANT_FAILED` errors to appear in the ledger. The [fixNFTokenDirV1][] amendment fixes these issues and should be enabled before the NonFungibleTokensV1 amendment to avoid problems.
**Warning:** There are several known issues with this amendment including one that can cause `tecINVARIANT_FAILED` errors to appear in the ledger. It has been replaced by the [NonFungibleTokensV1_1 amendment][].
This amendment adds 5 new transaction types:
@@ -834,19 +832,21 @@ It also modifies the [AccountSet transaction][] type to allow you to set the `NF
| Amendment | NonFungibleTokensV1_1 |
|:----------|:-----------|
| Amendment ID | 32A122F1352A4C7B3A6D790362CC34749C5E57FCE896377BFDC6CCD14F6CD627 |
| Status | Expected |
| Status | Enabled |
| Default Vote (Latest stable release) | No |
| Pre-amendment functionality retired? | No |
This amendment's only effect is to enable three other amendments at the same time:
Adds native support for [non-fungible tokens](non-fungible-tokens.html), including fixes to several issues that were discovered after [NonFungibleTokensV1][].
This amendment combines the effects of the following amendments, rendering the individual amendments obsolete:
- [NonFungibleTokensV1][]
- [fixNFTokenNegOffer][]
- [fixNFTokenDirV1][]
This ensures that the base NFT functionality and the related fixes all become enabled together, with no chance for the buggy functionality to become enabled without the fixes and no delay needed in between.
It has no other effects.
Validators who wish to enable Non-Fungible Tokens (NFTs) on the XRP Ledger should vote in favor of this amendment and not the others.
**Caution:** The [fixRemoveNFTokenAutoTrustLine][] fixes an known issue with this amendment. When creating a new test network, you should make sure that these amendments should be enabled together or the fix amendment is enabled first.
## OwnerPaysFee

View File

@@ -0,0 +1,42 @@
---
html: intro-to-evm-sidechain.html
parent: xrpl-interoperability.html
blurb: Introduction to the EVM compatible XRP Ledger Sidechain
labels:
- Interoperability
status: not_enabled
---
# Introduction to EVM Compatible XRP Ledger Sidechain
The Ethereum Virtual Machine (EVM) compatible XRP Ledger sidechain is a secure and fast public blockchain that brings all kinds of web3 applications to the XRP Ledger community.
- Explorer: [https://evm-sidechain.xrpl.org](https://evm-sidechain.xrpl.org/)
- Public RPC: [https://rpc-evm-sidechain.xrpl.org](https://rpc-evm-sidechain.xrpl.org/)
The EVM Sidechain is a powerful latest generation blockchain with the following features:
- Supports up to 1000 transactions per second, thus handling large loads and throughput.
- Has a low transaction confirmation time, on average, as a block is produced every 5 seconds.
- Once a block is added to the chain and confirmed, it is considered final (1 block finalization time).
- Provides full Ethereum Virtual Machine (EVM) compatibility, enabling you to connect your wallet and interact or deploy smart contracts written in Solidity.
## Consensus
The EVM Sidechain runs on a proof-of-stake (PoS) consensus algorithm. Staking is when you pledge your coins to be used for verifying transactions. The proof-of-stake model allows you to stake cryptocurrency (also referred to as "coins") and create your own validator nodes. Your coins are locked up while you stake them, but you can unstake them if you want to trade your coins.
In a proof-of-stake blockchain, mining power depends on the amount of coins a validator is staking. Participants who stake more coins are more likely to be chosen to add new blocks.
If you are interested in staking cryptocurrency and running your own validator, see [Join EVM Sidechain Devnet](join-evm-sidechain-devnet.html) for more information.
The underlying technology for the XRP Ledger EVM Sidechain consensus is [Tendermint](https://tendermint.com/), a Byzantine-Fault Tolerant engine for building blockchains.
The blockchain uses the `cosmos-sdk` library on top of Tendermint to create and customize the blockchain using its built-in modules. The EVM sidechain uses the [Ethermint](https://github.com/evmos/ethermint) `cosmos-sdk` module, which provides EVM compatibility
## Interoperability Using the EVM Sidechain
The EVM sidechain is directly connected to XRP Ledger through the XRP Ledger bridge ([https://bridge.devnet.xrpl.](https://bridge.devnet.xrpl.org/). Through this bridge component, you can move your XRP to the EVM Sidechain and use its features.
## See Also
[Get Started with EVM Sidechain](get-started-evm-sidechain.html)

View File

@@ -26,7 +26,7 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process
3. The customer sends a `TrustSet` transaction to create a trust line to the issuer's address, with a positive limit.
4. The issuer sends a `TrustSet` transaction to authorize the customer's trust line.
**Tip:** The issuer can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the TrustSetAuth amendment.)_
**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_
## As a Precaution

View File

@@ -0,0 +1,96 @@
---
html: freezes.html
parent: tokens.html
blurb: 凍結では、コンプライアンス目的で発行済み通貨の取引を停止できます。
labels:
- トークン
---
# 発行済み通貨の凍結
XRPは発行済み通貨ではありません。XRPはXRP Ledgerのネイティブ資産であり、XRP Ledgerでのトランザクションの実行に必要となります。XRPは取引相手を必要としません。つまり、XRPを保有しているということは負債ではなく実際の通貨であるXRPを保有していることになります。このため、_**<u>いかなる組織または個人もXRPを凍結できません</u>**_。
XRP Ledgerでは、XRP以外の通貨はすべて発行済み通貨として表すことができます。このような発行済み通貨「イシュアンス」または「IOU」とも呼ばれますは、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスもXRP以外の通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外の発行済み通貨の残高を急きょ凍結することがあります。
**ヒント:** 誰もXRPを凍結することはできません。
凍結については、3種類の設定があります。
* [**Individual Freeze**](#individual-freeze) - 1件の取引相手を凍結します。
* [**Global Freeze**](#global-freeze) - 取引相手全員を凍結します。
* [**No Freeze**](#no-freeze) - 個々の取引相手の凍結機能と、Global Freezeを終了できる機能を永久に放棄します。
凍結機能は発行済み通貨にのみ適用されます。XRP Ledgerには特権的な立場の当事者は存在しないため、凍結機能では、取引相手が、XRPまたはその他の取引相手が発行した資金で取引を実行することを阻止できません。Rippleを含め誰もXRPを凍結することはできません。
凍結対象の残高がプラス、マイナスにかかわらず、すべての凍結設定を行うことができます。通貨イシュアーまたは通貨保持者のいずれかがトラストラインを凍結できますが、通貨保持者がイシュアーを凍結しても、その影響はわずかです。
## Individual Freeze
**Individual Freeze**機能は、[トラストライン](trust-lines-and-issuing.html)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
* 取引相手が凍結されたトラストライン上の発行済み通貨の売りオファーを出した場合、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
確認事項: トラストラインではXRPは保持されません。XRPは凍結できません。
金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス([運用アドレス](issuing-and-operational-addresses.html)を含むからその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
## Global Freeze
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべての発行済み通貨に対して以下のルールが適用されます:
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。(これはすべての[運用アドレス](issuing-and-operational-addresses.html)にも影響します。)
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
* 凍結アドレスによる発行済み通貨の売りオファーはすべて、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
確認事項: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](issuing-and-operational-addresses.html)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
また、金融機関が新しい[発行アドレス](issuing-and-operational-addresses.html)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザーは他の通貨で取引することができなくなります。
Global Freezeは、当該アドレスによって発行および保有されている _すべての_ 通貨に適用されます。1つの通貨のみに対してGlobal Freezeを有効にすることはできません。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
アドレスのGlobal Freeze設定はいつでも有効にできます。ただし、アドレスの[No Freeze](#no-freeze)設定を有効にすると、Global Freezeを _無効にする_ ことはできません。
## No Freeze
**No Freeze**機能をアドレスに設定すると、取引相手が発行した通貨を凍結する機能を永久に放棄します。この機能を使用すれば、企業は自社が発行した資金を「物理的なお金のように」扱うことができます。これにより、企業は顧客どうしがその資金を取引することに介入できなくなります。
確認事項: XRPはすでに凍結できません。No Freeze機能は、XRP Ledgerで発行された他の通貨にのみ適用されます。
No Freeze設定には次の2つの効果があります。
* 発行アドレスは、すべての取引相手とのトラストラインに対してIndividual Freezeを有効にできなくなります。
* 発行アドレスは、Global Freezeを有効にしてグローバル凍結を施行できますが、Global Freezeを _無効にする_ ことはできません。
XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行することを強制できません。このため、Global Freezeを有効にする機能を放棄しても顧客を保護できません。ただし、Global Freezeを _無効にする_ 機能を放棄することで、Global Freeze機能が一部の顧客に対して不当に適用されないようにすることができます。
No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチ署名済みトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
<!--{# TODO: update "See Also" with new tutorials' technical details #}-->
# 関連項目
* [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -82,7 +82,6 @@ You can only enable the No Freeze setting with a transaction signed by your addr
<!--
# See Also
- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
- [Freeze Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
- **Concepts:**
- [Trust Lines and Issuing](trust-lines-and-issuing.html)

View File

@@ -4,6 +4,7 @@ parent: non-fungible.html
blurb: You can mint non-fungible tokens in batches.
labels:
- Tokens
---
# Batch minting
@@ -24,7 +25,7 @@ Any market activity prior to the initial sale of the NFToken object is not recor
## Scripted Minting
Use a program or script to mint many tokens at once. You might find the XRP Ledger ticket functionality helps you submit transactions in parallel, up to a current limit of 200 transactions in one group.
Use a program or script to mint many tokens at once. You might find that [Tickets](tickets.html) help you submit transactions in parallel, up to a current limit of 200 transactions in one group.
For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutorial.
@@ -35,4 +36,4 @@ For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutor
### Downside
You need to retain the appropriate XRP reserve for all of the NFToken objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have sufficient XRP in reserve, your mint transactions fail until you add sufficient XRP to your account.
You need to retain the appropriate XRP reserve for all of the NFToken objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have sufficient XRP in reserve, your mint transactions fail until you add sufficient XRP to your account.

View File

@@ -0,0 +1,86 @@
---
html: non-fungible-token-transfers.html
parent: non-fungible-tokens.html
blurb: NFTokenをダイレクトモードまたはブローカーモードで取引する。
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# XRP Ledger上でNFTokenを売買する
XRP Ledger上のアカウント間で`NFToken`オブジェクトを転送することができます。`NFToken` の売買をオファーしたり、他のアカウントから自分が保有する NFToken への売買オファーを受け入れることができます。`NFToken` を 無料(価格が0)で売却することで、`NFToken` を配布することもできます。すべてのオファーは [NFTokenCreateOfferトランザクション][] を使って作成されます。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## 売却オファー
### 売却オファーの作成
`NFToken` オブジェクトの所有者であれば、`tfSellToken` フラグを指定して [NFTokenCreateOffer トランザクション][] を使用して売却オファーを作成することができます。`NFTokenID` と、対価として受け取る金額 `Amount` を指定します。オプションで、そのオファーが無効になる `Expiration` と、その `NFToken` を購入することができる唯一のアカウントである `Destination` を指定することができます。
### 売却オファーを受け入れる
販売されている `NFToken` を購入するには、`NFTokenAcceptOffer` トランザクションを使用します。`NFTokenOffer` オブジェクトの所有者アカウントと `NFTokenOfferID` を指定し、受け入れることを決定します。
## 購入オファー
### 購入オファーの作成
どのアカウントでも `NFToken` の購入オファーを作成することができます。`tfSellToken` のフラグを指定せずに、[NFTokenCreateOffer][] を使用することで、購入オファーを作成することが可能です。`Owner`アカウント、`NFTokenID`、オファーの `Amount` を指定します。
### 購入オファーを受け入れる
`NFTokenAcceptOffer` トランザクションを使用して `NFToken` を転送します。`NFTokenOfferID` と所有者アカウントを指定して、トランザクションを完了させてください。
## 取引モード
`NFToken`を取引する場合、購入者と販売者の間で直接取引を行う、 _ダイレクト_ 取引と、第三者の口座が売りと買いのオファーをマッチングして取引を仲介する、 _ブローカー_ 取引を選択することができます。
ダイレクトモードでの取引では、販売者が転送をコントロールすることができます。販売者は誰でも購入できるように `NFToken` を出品するか、特定の取引先アカウントに `NFToken` を販売することができます。販売者はNFTokenの販売価格全額を受け取ります。
ブローカーモードでは、販売者は第三者のアカウントに`NFToken`の販売を仲介させます。ブローカーアカウントは、合意したレートで仲介手数料を徴収し、転送を行います。購入はリアルタイムで完了し、ブローカーと販売者には購入資金から支払われ、ブローカーによる前払いは必要ありません。
### ブローカーモードを使用する場合
`NFToken`の作成者が適切な購入者を探す時間と忍耐力がある場合、作成者は販売から得たすべての収益を得ることができます。これは、少数の`NFToken`オブジェクトを様々な価格で販売するクリエイターにとって、非常に有効な方法です。
一方、クリエイターは、創作に時間を割くことができるのに、販売に時間を割くのは抵抗があるのではないでしょうか。そのような場合、個別に対応するのではなく、第三者であるブローカーのアカウントに販売業務を委託することが可能です。
ブローカーを利用すると、いくつかの利点があります。例えば
* ブローカーは仲介者として、`NFToken`の販売価格を最大化するために活動することができます。ブローカーが販売価格の何割かを受け取る場合、価格が高ければ高いほど、ブローカーの収入も増えます。
* ブローカーは、ニッチな市場や 価格帯などの基準に基づいて`NFToken`オブジェクトの管理を行う管理者として活動することができます。これによって、クリエイターの作品を発見できないような購入者のグループを呼び込むことができるでしょう。
* ブローカーは、Opensea.ioのようなマーケットプレイスとして機能し、アプリケーション層でオークション機能を提供することもできます。
### ブローカー販売のワークフロー
最も単純なワークフローでは、クリエイターが新しい`NFToken`を発行します。クリエイターは売却オファーを作成する際、最低売却価格を入力し、売却先にブローカーを設定します。購入希望者はブローカーを経由して`NFToken`に入札を行います。ブローカーは落札者を選び、取引を完了させ、ブローカー手数料を受け取ります。ベストプラクティスとして、ブローカーは`NFToken`に対して残っている購入オファーをすべてキャンセルします。
![Brokered Mode with Reserve](img/nft-brokered-mode-with-reserve.png)
もう1つのワークフローは、クリエイターが販売をよりコントロールできるようにするものです。このワークフローでは、クリエイターが新しい`NFToken`を発行します。入札者はオファーを作成し、ブローカーを宛先として設定します。ブローカーは落札者を選び、仲介手数料を差し引き、`NFTokenCreateOffer`を使用してクリエイターに署名の依頼をします。クリエーターは要求されたオファーに署名し、ブローカーを宛先として設定します。ブローカーは `NFTokenAcceptOffer` を使って売却を完了し、仲介手数料を保持します。ブローカーは `NFTokenCancelOffer` を使用して `NFToken` に対する残りの入札をキャンセルします。
![Brokered Mode without Reserve](img/nft-brokered-mode-without-reserve.png)
所有者が他のアカウントで作成した `NFToken` をリセールする場合にも、同じワークフローを使用することができます。
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -9,6 +9,8 @@ labels:
You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0. All offers are created using `NFTokenCreateOffer` transaction.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Sell Offers

View File

@@ -0,0 +1,84 @@
---
html: non-fungible-tokens.html
parent: tokens.html
blurb: XRPL NFTの紹介。
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
---
# NFTのコンセプトの概要
XRP Ledgerは、_IOUs_ としても知られる[発行済み通貨](tokens.html)のサポートを提供しています。このような資産は、主に、代替可能(Fungible)です。
> 代替可能性
>
> 1. 個々の単位が本質的に交換可能であり、各部分が別の部分と区別できない商品または商品の特性である
代替可能トークンは、XRP Ledgerの分散型取引所において、ユーザー間でXRPや他の発行済み通貨と手軽に交換することができます。そのため、決済に適しています。
例えば、切手などがそうです。1919年当時、あなたが航空便で手紙を送る必要がある場合、24セントの切手を購入し、封筒に張ったでしょう。もしその切手をなくしてしまったら、別の24セント切手を使うか、10セント切手2枚と2セント切手2枚を使うことができます。非常に使い勝手がいいのです。
![Jenny Stamps](img/nft-concepts1.png "Jenny Stamps")
しかし、1919年という時代のことですから、切手の飛行機が偶然にも逆さまに印刷されている24セントの航空郵便切手が出回るかもしれません。これが世界的に有名な「インバート・ジェニー」切手です。1枚の切手シートで100枚しか流通しなかったため、非常に希少で人気の高い切手です。現在、鑑定では一枚150万円以上の価値があるとされています。
![Jenny Stamps](img/nft-concepts2.png "Jenny Stamps")
これらの切手は、他の24セント切手と交換することはできません。非代替(Non-fungible)になってしまったのです。
[NonFungibleTokensV1の修正][] :現在有効ではありません: は、XRP Ledgerに非代替性トークンNFTのサポートをネイティブで追加するものです。 非代替性トークンは、芸術品やゲーム内アイテムなど、ユニークな物理的、非物理的、あるいは純粋なデジタル商品の所有権をコード化する役割を果たします。
## XRP Ledger上のNFT
XRP Ledger上では、non-fungible tokenは[NFToken][]オブジェクトとして表されます。NFTokenはユニークで分割できない単位で、決済には使用できません。ユーザーはこのようなトークンを発行作成、保有、購入、売却、焼却破棄することができます。
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の `NFToken` オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の `NFToken` オブジェクトに対する [準備金] (reserves.html) は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
また、アカウントは、自分に代わってNFTokenオブジェクトを発行・販売するブローカー代理発行者を指定することができます。
`NFToken` オブジェクトは、トークンが発行された時点で確定し、後で変更することが出来ない設定項目を持ちます。これらは以下の通りです。
- トークンを一意に定義する各種識別データ。
- 発行者が、現在の保有者に関係なく、トークンを焼却できるかどうか。
- トークンの保持者がトークンを他者に転送できるかどうか。( `NFToken` は常に発行者に直接送信したり、発行者から送信することが可能です)。
- 転送が許可されている場合、発行者は販売価格に対する一定の割合で手数料を徴収することができます。
- NFTokenを[発行済み通貨](tokens.html)で売却できるか、XRPのみでしか売却できないか。
## `NFToken`のライフサイクル
誰もが [NFTokenMint トランザクション][] を使って新しい `NFToken` を作成することができます。`NFToken` は発行者アカウントの [NFTokenPage オブジェクト][] に格納されます。所有者または利害関係者は [NFTokenCreateOffer トランザクション][]を送信して `NFToken` の売買を提案できます。レジャーは提案された転送を [NFTokenOffer オブジェクト][]として追跡し、一方が承諾またはキャンセルすると `NFTokenOffer` を削除します。`NFToken` が転送可能であれば、アカウント間で複数回取引することができます。
[NFTokenBurn トランザクション][] を使用して、自分が所有する `NFToken` を破棄することができます。発行者が `tfBurnable` フラグを有効にしてトークンを発行した場合、発行者は現在の所有者に関係なくトークンを破棄することが可能です。( 例えば、あるイベントのチケットを表すトークンである場合、そのチケットをある時点で消費するといった場合に便利です)。
![The NFT Lifecycle](img/nft-lifecycle.png "NFT Lifecycle Image")
`NFToken` オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](non-fungible-token-transfers.html) を参照してください。
## 関連項目
- [NFToken][] データ型
- レジャーオブジェクト
- [NFTokenOffer オブジェクト][]
- [NFTokenPage オブジェクト][]
- トランザクション
- [NFTokenMint トランザクション][]
- [NFTokenCreateOffer トランザクション][]
- [NFTokenCancelOffer トランザクション][]
- [NFTokenAcceptOffer トランザクション][]
- [NFTokenBurn トランザクション][]
- API メソッド
- [account_nfts メソッド][]
- [nft_sell_offers メソッド][]
- [nft_buy_offers メソッド][]
- [nft_info メソッド][] (Clioサーバのみ)
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -0,0 +1,91 @@
---
html: non-fungible-tokens.html
parent: tokens.html
blurb: Introduction to XRPL NFTs.
filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
---
# Non-Fungible Tokens Overview
The XRP Ledger supports non-fungible tokens (NFTs, or “nifties” in the vernacular) natively. 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.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Background
The XRP Ledger offers support for [tokens](tokens.html), also known as _IOUs_. Such assets are, primarily, fungible.
> Fun·gi·ble /ˈfənjəbəl/ (adj)
>
> 1. able to replace or be replaced by another identical item; mutually interchangeable.
Fungible tokens can be easily traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would purchase a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
![Jenny Stamps](img/nft-concepts1.png "Jenny Stamps")
But since you are standing around in 1919, you might be offered 24-cent airmail stamps where the aeroplane on the stamp is accidentally printed upside down. These are the world famous “Inverted Jenny” stamps. Only 100 were circulated on a single sheet of stamps, making them extremely rare and sought after. The current value of each mint condition stamp is appraised at over $1.5 million dollars.
![Jenny Stamps](img/nft-concepts2.png "Jenny Stamps")
Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
To represent digital assets similar to these, use the XRP Ledger's Non-Fungible Tokens feature (sometimes referred to by its standards draft number, [XLS-20](https://github.com/XRPLF/XRPL-Standards/discussions/46)).
## NFTs on the XRP Ledger
On the XRP Ledger, a non-fungible token is represented as a [NFToken][] object. A `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 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.
Accounts can also designate a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
`NFToken` objects have several settings that are defined when the token is minted and cannot be changed later. These include:
- 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
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 a [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 a `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 `NFToken` objects, see [Trading NFTokens on the XRP Ledger](non-fungible-token-transfers.html).
## Reference
- [NFToken][] data type
- Ledger Objects
- [NFTokenOffer object][]
- [NFTokenPage object][]
- Transactions
- [NFTokenMint transaction][]
- [NFTokenCreateOffer transaction][]
- [NFTokenCancelOffer transaction][]
- [NFTokenAcceptOffer transaction][]
- [NFTokenBurn transaction][]
- 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' %}
{% include '_snippets/tx-type-links.md' %}
{% include '_snippets/rippled_versions.md' %}

View File

@@ -13,13 +13,14 @@ All assets other than XRP can be represented in the XRP Ledger as **tokens**. St
Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who do not want them.
Standard tokens are fungible, meaning all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible.md) for details of the XRP Ledger's native support.
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) for details of the XRP Ledger's native support.
Tokens can used for [cross-currency payments](../transactions/payments/cross-currency-payments.md) and can be traded in the <!-- * -->decentralized exchange.
Tokens can used for [cross-currency payments](cross-currency-payments.html) and can be traded in the <!-- * -->decentralized exchange.
<!-- * [decentralized exchange](../server/decentralized-exchange.md) -->
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.md#the-no-ripple-flag) on trust lines to prevent those trust lines from rippling.
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html#the-no-ripple-flag) on trust lines to prevent those trust lines from rippling.
## Token Properties
@@ -30,9 +31,9 @@ Tokens in the XRP Ledger are <!--*-->fundamentally different than XRP. Tokens al
Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
Anyone can issue tokens by sending a `Payment` transaction if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](../transactions/payments/cross-currency-payments.md) or trades can also create more tokens according to an issuer's settings.
Anyone can issue tokens by sending a `Payment` transaction if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](cross-currency-payments.html) or trades can also create more tokens according to an issuer's settings.
Issuers can charge a [transfer fee](transfer-fees.md) that is automatically deducted when users transfer their tokens. Issuers can also define a <!-- * -->tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.md) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a <!-- * -->tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
<!-- * [tick size](ticksize.md) -->

View File

@@ -4,7 +4,7 @@
For standard tokens, the tokens paid in the transfer fee are burned, and no longer tracked in the XRP Ledger. If the token is backed by off-ledger assets, this reduces the amount of those assets the issuer has to hold in reserve to meet its obligations in the XRP Ledger. Transfer fees are usually not appropriate for tokens that aren't backed with outside assets.
Non-fungible tokens :not_enabled: can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
Non-fungible tokens can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.

View File

@@ -20,9 +20,9 @@ Benefits of multi-signing include:
Before you can multi-sign, you must create a list of which addresses can sign for you.
The `SignerListSet` transaction defines which addresses can authorize transactions from your address. You can include 1 to 8 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList.
The [SignerListSet transaction][] defines which addresses can authorize transactions from your address. You can include 1 to 32 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList.
If the `ExpandedSignerList` amendment :not_enabled: is enabled, you can include 1 to 32 addresses in a SignerList.
_(Updated by the [ExpandedSignerList amendment][].)_
### Signer Weight
@@ -34,7 +34,9 @@ The quorum value is the minimum weight total required to authorize a transaction
### Wallet Locator
If the `ExpandedSignerList` amendment :not_enabled: is enabled, you can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers.
You can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers.
_(Added by the [ExpandedSignerList amendment][].)_
### Examples Using Signer Weight and Signer Quorum

View File

@@ -37,12 +37,6 @@ If more than 20% of validators suddenly go offline all at once, the remaining se
Negative UNL has no effect on [stand-alone mode](rippled-server-modes.html) since the server does not use consensus in stand-alone mode.
## Enabling the Negative UNL for Testing
Negative UNL functionality is currently available for testing on [Devnet](parallel-networks.html). You can test the Negative UNL feature by adding or modifying a `[features]` stanza in your `rippled.cfg` file, as described in [Connect Your rippled to a Parallel Network](connect-your-rippled-to-the-xrp-test-net.html).
## How It Works
The Negative UNL is closely tied to the [consensus process](consensus.html) and is designed with safeguards to maintain the continuity and reliability of the network in adverse situations. When all trusted validators are operating normally, the Negative UNL is unused and has no effect. When some validators appear to be offline or out of sync, the Negative UNL rules take effect.

View File

@@ -4,14 +4,13 @@ parent: account-methods.html
blurb: Get a list of all NFTs for an account.
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# account_nfts
[[Source]](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/AccountObjects.cpp "Source")
The `account_nfts` method returns a list of `NFToken` objects for the specified account.
{% include '_snippets/nfts-disclaimer.md' %}
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Request Format
An example of the request format:

View File

@@ -4,14 +4,13 @@ parent: path-and-order-book-methods.html
blurb: Get a list of all buy offers for a NFToken.
labels:
- Non-fungible Tokens, NFTs, NFTokens
status: not_enabled
---
# nft_buy_offers
[[Source]](https://github.com/ripple/rippled/blob/xls20/src/ripple/rpc/handlers/NFTOffers.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/NFTOffers.cpp "Source")
The `nft_buy_offers` method returns a list of buy offers for a given [NFToken][] object.
{% include '_snippets/nfts-disclaimer.md' %}
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Request Format
An example of the request format:

View File

@@ -4,14 +4,14 @@ parent: path-and-order-book-methods.html
blurb: Get a list of all sell offers for a NFToken.
labels:
- Non-fungible Tokens, NFTs, NFTokens
status: not_enabled
---
# nft_sell_offers
[[Source]](https://github.com/ripple/rippled/blob/xls20/src/ripple/rpc/handlers/NFTOffers.cpp "Source")
{% include '_snippets/nfts-disclaimer.md' %}
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/rpc/handlers/NFTOffers.cpp "Source")
The `nft_sell_offers` method returns a list of sell offers for a given [NFToken][] object.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Request Format
An example of the request format:

View File

@@ -20,7 +20,7 @@ An account in the XRP Ledger represents a holder of XRP and a sender of transact
* **[`account_currencies`](account_currencies.html)** - Get a list of currencies an account can send or receive.
* **[`account_info`](account_info.html)** - Get basic data about an account.
* **[`account_lines`](account_lines.html)** - Get info about an account's trust lines.
* **[`account_nfts`](account_nfts.html)** :not_enabled: - Get a list of non-fungible tokens owned by an account.
* **[`account_nfts`](account_nfts.html)** - Get a list of non-fungible tokens owned by an account.
* **[`account_objects`](account_objects.html)** - Get all ledger objects owned by an account.
* **[`account_offers`](account_offers.html)** - Get info about an account's currency exchange offers.
* **[`account_tx`](account_tx.html)** - Get info about an account's transactions.
@@ -61,8 +61,8 @@ Paths define a way for payments to flow through intermediary steps on their way
* **[`book_offers`](book_offers.html)** - Get info about offers to exchange two currencies.
* **[`deposit_authorized`](deposit_authorized.html)** - Look up whether one account is authorized to send payments directly to another.
* **[`nft_buy_offers`](nft_buy_offers.html)** :not_enabled: - Retrieve a list of buy offers for a specified NFToken object.
* **[`nft_sell_offers`](nft_sell_offers.html)** :not_enabled: - Retrieve a list of sell offers for a specified NFToken object.
* **[`nft_buy_offers`](nft_buy_offers.html)** - Retrieve a list of buy offers for a specified NFToken object.
* **[`nft_sell_offers`](nft_sell_offers.html)** - Retrieve a list of sell offers for a specified NFToken object.
* **[`path_find`](path_find.html)** - Find a path for a payment between two accounts and receive updates.
* **[`ripple_path_find`](ripple_path_find.html)** - Find a path for payment between two accounts, once.

View File

@@ -94,7 +94,7 @@ Tokens can represent a wide variety of assets, including those typically measure
When sending token amounts in the XRP Ledger's peer-to-peer network, servers [serialize](serialization.html) the amount to a 64-bit binary value.
**Note:** Native support for [Non-Fungible Tokens (NFTs) :not_enabled:](non-fungible-tokens.html) is currently in an experimental state. There are also deprecated, alternative standards for implementing NFTs without changes to the XRP Ledger protocol, including [XLS-14d](https://github.com/XRPLF/XRPL-Standards/discussions/30) and [XLS-19d](https://github.com/XRPLF/XRPL-Standards/discussions/40). <!-- SPELLING_IGNORE: xls, 14d, 19d -->
**Tip:** For tokens that should not be divisible at all, see [Non-Fungible Tokens (NFTs)](non-fungible-tokens.html).
## Currency Codes
[Currency Code]: #currency-codes

View File

@@ -4,10 +4,8 @@ parent: basic-data-types.html
blurb: XRPL NFTの紹介
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFToken
{% include '_snippets/nfts-disclaimer.ja.md' %}
`NFToken` オブジェクトは、1つの非代替性トークン (NFT) を表します。単体では保存されず、他の NFT と共に [NFTokenPage オブジェクト][] に格納されます。
@@ -23,6 +21,8 @@ status: not_enabled
他のオブジェクトとは異なり、`NFToken` にはオブジェクトの種類や現在の所有者を特定するためのフィールドはありません。NFToken オブジェクトは、オブジェクトの種類と所有者を暗黙的に定義する `NFTokenPages` にグループ化されています。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## トークンID

View File

@@ -4,13 +4,13 @@ parent: basic-data-types.html
blurb: Introduction to XRPL NFTs.
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFToken
{% include '_snippets/nfts-disclaimer.md' %}
The `NFToken` object represents a single non-fungible token (NFT). It is not stored on its own, but is contained in a [NFTokenPage object][] alongside other `NFToken` objects.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
Example {{currentpage.name}} JSON
```json

View File

@@ -41,14 +41,14 @@ The `AccountRoot` object has the following fields:
| `Account` | String | AccountID | Yes | The identifying (classic) address of this [account](accounts.html). |
| `AccountTxnID` | String | Hash256 | No | 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). |
| `Balance` | String | Amount | No | The account's current [XRP balance in drops][XRP, in drops], represented as a string. |
| `BurnedNFTokens` | Number | UInt32 | No | 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`. |
| `BurnedNFTokens` | Number | UInt32 | No | How many total of this account's issued [non-fungible tokens](non-fungible-tokens.html) have been burned. This number is always equal or less than `MintedNFTokens`. |
| `Domain` | String | Blob | No | 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 | No | 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/). |
| [`Flags`](#accountroot-flags) | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this account. |
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0061`, mapped to the string `AccountRoot`, indicates that this is an AccountRoot object. |
| `MessageKey` | String | Blob | No | 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 | No | 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 | No | Another account that is authorized to mint [non-fungible tokens](non-fungible-tokens.html) :not_enabled: on behalf of this account. |
| `MintedNFTokens` | Number | UInt32 | No | How many total [non-fungible tokens](non-fungible-tokens.html) have been minted by and on behalf of this account. |
| `NFTokenMinter` | String | AccountID | No | Another account that is authorized to mint [non-fungible tokens](non-fungible-tokens.html) on behalf of this account. |
| `OwnerCount` | Number | UInt32 | Yes | The number of objects this account owns in the ledger, which contributes to its owner reserve. |
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes |The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this object. |

View File

@@ -6,13 +6,13 @@ filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenOffer
{% include '_snippets/nfts-disclaimer.md' %}
`lsfTransferable` フラグが設定されているトークンは、オファーを使って 参加者間で転送することができます。`NFTokenOffer` オブジェクトは `NFToken` オブジェクトの購入、売却、または譲渡のオファーを表します。`NFToken` の所有者は `NFTokenCreateOffer` を使用して売買を行うことができます。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
### `NFTokenOfferID`のフォーマット

View File

@@ -6,23 +6,29 @@ filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenOffer
{% include '_snippets/nfts-disclaimer.md' %}
Tokens that have the `lsfTransferable` flag set can be transferred among participants using offers. The `NFTokenOffer` object represents an offer to buy, sell or transfer an `NFToken` object. The owner of a `NFToken` can use `NFTokenCreateOffer` to start a transaction.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
### `NFTokenOfferID` Format
## Example {{currentpage.name}} JSON
The unique ID (`NFTokenOfferID`) of the `NFTokenOffer` object is the result of the following values concatenated in order:
* The `NFTokenOffer` space key, `0x0074`;
* The `AccountID` of the account placing the offer; and
* The `Sequence` (or `Ticket`) of the `NFTokenCreateOffer` transaction that will create the `NFTokenOffer`.
```json
{
"Amount": "1000000",
"Flags": 1,
"LedgerEntryType": "NFTokenOffer",
"NFTokenID": "00081B5825A08C22787716FA031B432EBBC1B101BB54875F0002D2A400000000",
"NFTokenOfferNode": "0",
"Owner": "rhRxL3MNvuKEjWjL7TBbZSDacb8PmzAd7m",
"OwnerNode": "17",
"PreviousTxnID": "BFA9BE27383FA315651E26FDE1FA30815C5A5D0544EE10EC33D3E92532993769",
"PreviousTxnLgrSeq": 75443565,
"index": "AEBABA4FAC212BF28E0F9A9C3788A47B085557EC5D1429E7A8266FB859C863B3"
}
```
### `NFTokenOffer` Fields
@@ -79,6 +85,15 @@ Each token has two directories. One contains offers to buy the token and the oth
Each `NFTokenOffer` object costs the account placing the offer one incremental reserve. As of this writing the incremental reserve is 2 XRP. The reserve can be recovered by cancelling the offer.
### `NFTokenOfferID` Format
The unique ID (`NFTokenOfferID`) of the `NFTokenOffer` object is the result of the following values concatenated in order:
* The `NFTokenOffer` space key, `0x0074`;
* The `AccountID` of the account placing the offer; and
* The `Sequence` (or `Ticket`) of the `NFTokenCreateOffer` transaction that will create the `NFTokenOffer`.
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}
{% include '_snippets/tx-type-links.md' %}

View File

@@ -6,13 +6,14 @@ filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenPage
{% include '_snippets/nfts-disclaimer.md' %}
`NFTokenPage` オブジェクトは、同じアカウントが所有する `NFToken` オブジェクトのコレクションを表します。一つのアカウントは複数の `NFTokenPage` 型のレジャーオブジェクトを持つことができ、それらは双方向リストを形成します。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## {{currentpage.name}} JSONの例
```json

View File

@@ -6,13 +6,14 @@ filters:
- include_code
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenPage
{% include '_snippets/nfts-disclaimer.md' %}
The `NFTokenPage` object represents a collection of `NFToken` objects owned by the same account. An account can have multiple `NFTokenPage` ledger objects, which form a doubly linked list.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {{currentpage.name}} JSON
```json

View File

@@ -73,7 +73,7 @@ _[MultiSign Amendment][]が必要です。_
|:---------------|:----------|:--------------|:--------------------------------|
| `Account` | 文字列 | AccountID | 署名がマルチ署名に提供されるXRP Ledgerアドレス。レジャーの資金供給のあるアドレスである必要はありません。 |
| `SignerWeight` | 数値 | UInt16 | この署名者による署名の重み。マルチ署名は、付与された署名の重みの合計がSignerListの`SignerQuorum`値を超えている場合にのみ有効となります。 |
| `WalletLocator` | 文字列 | Hash256 | 省略可Arbitrary hexadecimal data. This can be used to identify the signer or for other, related purposes. Requires the [ExpandedSignerList amendment][] :not_enabled:. <!-- TODO: translate --> |
| `WalletLocator` | 文字列 | Hash256 | 省略可Arbitrary hexadecimal data. This can be used to identify the signer or for other, related purposes. Added by the [ExpandedSignerList amendment][]. <!-- TODO: translate --> |
マルチ署名済みトランザクションを処理する際に、サーバーはトランザクション実行時にレジャーに関する`Account`値を間接参照します。アドレスが資金供給のある[AccountRootオブジェクト](accountroot.html)に対応して _いない_ 場合、そのアドレスに関連付けられているマスターシークレットによってのみ有効な署名を生成できます。アカウントがレジャーに _確かに_ 存在している場合は、アカウントの状態により異なります。アカウントにレギュラーキーが設定されている場合はレギュラーキーを使用できます。アカウントのマスターキーが無効化されていない場合に限り、アカウントのマスターキーを使用できます。マルチ署名を別のマルチ署名の一部として使用することはできません。

View File

@@ -73,7 +73,7 @@ Each member of the `SignerEntries` field is an object that describes that signer
|:----------------|:----------|:--------------|:-------------------------------|
| `Account` | String | AccountID | An XRP Ledger address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. |
| `SignerWeight` | Number | UInt16 | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the signer list's `SignerQuorum` value. |
| `WalletLocator` | String | Hash256 | _(Optional)_ Arbitrary hexadecimal data. This can be used to identify the signer or for other, related purposes. Requires the [ExpandedSignerList amendment][] :not_enabled:. |
| `WalletLocator` | String | Hash256 | _(Optional)_ Arbitrary hexadecimal data. This can be used to identify the signer or for other, related purposes. _(Added by the [ExpandedSignerList amendment][].)_ |
When processing a multi-signed transaction, the server looks up the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded [AccountRoot object](accountroot.html), then only the [master private key](cryptographic-keys.html) associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.

View File

@@ -28,8 +28,6 @@ A `UNLModify` [pseudo-transaction](pseudo-transaction-types.html) marks a change
}
```
## {{currentpage.name}} Fields
{% include '_snippets/pseudo-tx-fields-intro.md' %}
<!--{# fix md highlighting_ #}-->

View File

@@ -15,7 +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:)_ |
| `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_1 amendment][].)_ |
| `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. |
@@ -28,16 +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_FUNDS` | 158 | One of the accounts involved does not hold enough of a necessary asset. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `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_1 amendment][].)_ |
| `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:)_ |
| `tecMAX_SEQUENCE_REACHED` | 153 | A sequence number field is already at its maximum. This includes the `MintedNFTokens` field. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `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:)_ |
| `tecNFTOKEN_BUY_SELL_MISMATCH` | 155 | The [NFTokenAcceptOffer transaction][] attempted to match incompatible offers to buy and sell a non-fungible token. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `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_1 amendment][].)_ |
| `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.) |
@@ -49,9 +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 | The transaction tried to mint or acquire a non-fungible token but the account receiving the `NFToken` does not have a directory page that can hold it. This situation is rare. _(Added by the [NonFungibleTokensV1 amendment][]. :not_enabled:)_ |
| `tecNO_SUITABLE_NFTOKEN_PAGE` | 154 | The transaction tried to mint or acquire a non-fungible token but the account receiving the `NFToken` does not have a directory page that can hold it. This situation is rare. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `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:)_ |
| `tecOBJECT_NOT_FOUND` | 160 | One of the objects specified by this transaction did not exist in the ledger. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `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). |

View File

@@ -28,7 +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:)_ |
| `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_1 amendment][].)_ |
| `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. |

View File

@@ -20,7 +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_NFTOKEN_TRANSFER_FEE` | The [NFTokenMint transaction][] improperly specified the `TransferFee` field of the transaction. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `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. |

View File

@@ -35,7 +35,7 @@ An AccountSet transaction modifies the properties of an [account in the XRP Ledg
| [Domain](#domain) | String | Blob | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. [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)_ Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
| `MessageKey` | String | Blob | _(Optional)_ Public key for sending encrypted messages to this account. To set the key, it must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. To remove the key, use an empty value. |
| `NFTokenMinter` :not_enabled: | String | Blob | _(Optional)_ Sets an alternate account that is allowed to mint NFTokens on this account's behalf using NFTokenMint's `Issuer` field. This field is part of the experimental XLS-20 standard for non-fungible tokens. |
| `NFTokenMinter` | String | Blob | _(Optional)_ Sets an alternate account that is allowed to mint NFTokens on this account's behalf using NFTokenMint's `Issuer` field. This field is part of the experimental XLS-20 standard for non-fungible tokens. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| [`SetFlag`](#accountset-flags) | Number | UInt32 | _(Optional)_ Integer flag to enable for this account. |
| [`TransferRate`](#transferrate) | Number | UInt32 | _(Optional)_ The fee to charge when users transfer this account's tokens, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
| [`TickSize`](ticksize.html) | Number | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Added by the [TickSize amendment][].)_ |
@@ -72,7 +72,7 @@ The available AccountSet flags are:
| Flag Name | Decimal Value | Corresponding Ledger Flag | Description |
|:-------------------|:--------------|:--------------------------|:--------------|
| `asfAccountTxnID` | 5 | (None) | Track the ID of this account's most recent transaction. Required for [`AccountTxnID`](transaction-common-fields.html#accounttxnid) |
| `asfAuthorizedNFTokenMinter` :not_enabled:| 10 | (None) | Enable to allow another account to mint non-fungible tokens (NFTokens) on this account's behalf. Specify the authorized account in the `NFTokenMinter` field of the [AccountRoot](accountroot.html) object. This is an experimental field to enable behavior for NFToken support. |
| `asfAuthorizedNFTokenMinter`| 10 | (None) | Enable to allow another account to mint non-fungible tokens (NFTokens) on this account's behalf. Specify the authorized account in the `NFTokenMinter` field of the [AccountRoot](accountroot.html) object. This is an experimental field to enable behavior for NFToken support. _(Added by the [NonFungibleTokensV1_1 amendment][].)_ |
| `asfDefaultRipple` | 8 | `lsfDefaultRipple` | Enable [rippling](rippling.html) on this account's trust lines by default. [New in: rippled 0.27.3][] |
| `asfDepositAuth` | 9 | `lsfDepositAuth` | Enable [Deposit Authorization](depositauth.html) on this account. _(Added by the [DepositAuth amendment][].)_ |
| `asfDisableMaster` | 4 | `lsfDisableMaster` | Disallow use of the master key pair. Can only be enabled if the account has configured another way to sign transactions, such as a [Regular Key](cryptographic-keys.html) or a [Signer List](multi-signing.html). |

View File

@@ -4,16 +4,16 @@ parent: transaction-types.html
blurb: NFTokenの購入または売却のオファーを受け入れる。
labels:
- NFTs, Non-fungible Tokens
status: not_enabled
---
# NFTokenAcceptOffer
{% include '_snippets/nfts-disclaimer.md' %}
`NFTokenAcceptOffer` トランザクションは `NFToken` の購入または売却のオファーを受け入れるために使用されます。トランザクションは次のいずれかになります。
* 1つのオファーを受け入れることを許可する。これは _ダイレクト_ モードと呼ばれます。
* 2つの異なるオファー、1つは与えられた `NFToken` の購入を提案し、もう1つは同じ `NFToken` の売却を提案し、アトミックに受け入れられることを許可します。これは _ブローカー_ モードと呼ばれます。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## ブローカー vs. ダイレクト モード

View File

@@ -4,16 +4,37 @@ parent: transaction-types.html
blurb: Accept an offer to buy or sell an NFToken.
labels:
- NFTs, Non-fungible Tokens
status: not_enabled
---
# NFTokenAcceptOffer
{% include '_snippets/nfts-disclaimer.md' %}
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenAcceptOffer.cpp "Source")
The `NFTokenAcceptOffer` transaction is used to accept offers to `buy` or `sell` an `NFToken`. It can either:
* Allow one offer to be accepted. This is called _direct_ mode.
* Allow two distinct offers, one offering to buy a given `NFToken` and the other offering to sell the same `NFToken`, to be accepted in an atomic fashion. This is called _brokered_ mode.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example NFTokenAcceptOffer JSON
```json
{
"Account": "r9spUPhPBfB6kQeF6vPhwmtFwRhBh2JUCG",
"Fee": "12",
"LastLedgerSequence": 75447550,
"Memos": [
{
"Memo": {
"MemoData": "61356534373538372D633134322D346663382D616466362D393666383562356435386437"
}
}
],
"NFTokenSellOffer": "68CD1F6F906494EA08C9CB5CAFA64DFA90D4E834B7151899B73231DE5A0C3B77",
"Sequence": 68549302,
"TransactionType": "NFTokenAcceptOffer"
}
```
## Brokered vs. Direct Mode

View File

@@ -4,10 +4,8 @@ parent: transaction-types.html
blurb: TokenBurnを使用して、NFTを永久に破棄します。
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenBurn
{% include '_snippets/nfts-disclaimer.md' %}
NFTokenBurn トランザクションは、`NFToken` オブジェクトを保持している `NFTokenPage` 内から削除し、トークンをレジャーから削除( _バーン_ )することになります。
@@ -15,6 +13,8 @@ NFTokenBurn トランザクションは、`NFToken` オブジェクトを保持
この操作に成功すると、対応する `NFToken` が削除されます。この操作によって `NFToken` を保持している `NFTokenPage` が空になるか、統合されて `NFTokenPage` が削除されると、所有者準備金が1つ減ります。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## {{currentpage.name}} JSONの例

View File

@@ -4,10 +4,9 @@ parent: transaction-types.html
blurb: Use TokenBurn to permanently destroy NFTs.
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenBurn
{% include '_snippets/nfts-disclaimer.md' %}
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenBurn.cpp "Source")
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).
@@ -15,6 +14,8 @@ The sender of this transaction must be the owner of the `NFToken` to burn; or, i
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 owners reserve requirement is reduced by one.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {{currentpage.name}} JSON

View File

@@ -4,10 +4,8 @@ parent: transaction-types.html
blurb: NFTokenの売買のための既存のトークンへのオファーをキャンセルする。
labels:
- NFTs, Non-fungible Tokens
status: not_enabled
---
# NFTokenCancelOffer
{% include '_snippets/nfts-disclaimer.md' %}
`NFTokenCancelOffer` トランザクションは、`NFTokenCreateOffer` を使用して作成した既存のトークンへのオファーをキャンセルするために使用できます。
@@ -23,6 +21,9 @@ status: not_enabled
}
```
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## アクセス権
`NFTokenOffer` オブジェクトで表される既存のオファーは、以下の方法でキャンセルすることができます。

View File

@@ -4,13 +4,14 @@ parent: transaction-types.html
blurb: Cancel existing token offers to buy or sell an NFToken.
labels:
- NFTs, Non-fungible Tokens
status: not_enabled
---
# NFTokenCancelOffer
{% include '_snippets/nfts-disclaimer.md' %}
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenCancelOffer.cpp "Source")
The `NFTokenCancelOffer` transaction can be used to cancel existing token offers created using `NFTokenCreateOffer`.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {{currentpage.name}} JSON
```json

View File

@@ -4,15 +4,15 @@ parent: transaction-types.html
blurb: NFTの売買のオファーを作成する。
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenCreateOffer
{% include '_snippets/nfts-disclaimer.md' %}
トランザクションを送信するアカウントが所有する `NFToken` に対する新しい _売却_ オファー、または別のアカウントが所有する `NFToken` に対する新しい _購入_ オファー を作成します。
成功した場合、トランザクションは[NFTokenOfferオブジェクト][]を作成します。各オファーは、オファーを提示したアカウントの [所有者準備金](reserves.html) に関連づけて1つのオブジェクトとしてカウントされます。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## {{currentpage.name}} JSONの例
```json

View File

@@ -4,15 +4,16 @@ parent: transaction-types.html
blurb: Create an offer to buy or sell NFTs.
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenCreateOffer
{% include '_snippets/nfts-disclaimer.md' %}
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenCreateOffer.cpp "Source")
Creates either a new _Sell_ offer for an `NFToken` owned by the account executing the transaction, or a new _Buy_ offer for an `NFToken` owned by another account.
If successful, the transaction creates a [NFTokenOffer object][]. Each offer counts as one object towards the [owner reserve](reserves.html) of the account that placed the offer.
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {{currentpage.name}} JSON
```json

View File

@@ -4,14 +4,14 @@ parent: transaction-types.html
blurb: TokenMintを使用して新規NFTを発行する。.
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenMint
[[ソース]](https://github.com/ripple/rippled/blob/xls20/src/ripple/app/tx/impl/NFTokenMint.cpp)
{% include '_snippets/nfts-disclaimer.md' %}
[[ソース]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/NFTokenMint.cpp "Source")
`NFTokenMint` トランザクションは非代替性トークンを作成し、`NFTokenMinter` の関連する [NFTokenPage object][] に [NFToken][] オブジェクトとして追加します。このトランザクションの必須パラメーターは `Token` フィールドで、実際のトークンを指定します。このトランザクションは `NFTokenMinter` にとって、不変と定義されているトークン フィールド (例えば `Flags`) を設定することができる唯一の方法です。
_([NonFungibleTokensV1_1 amendment][]が必要です)_
## {currentpage.name}} JSONの例

View File

@@ -4,14 +4,14 @@ parent: transaction-types.html
blurb: Use TokenMint to issue new NFTs.
labels:
- Non-fungible Tokens, NFTs
status: not_enabled
---
# NFTokenMint
[[Source]](https://github.com/ripple/rippled/blob/xls20/src/ripple/app/tx/impl/NFTokenMint.cpp)
{% include '_snippets/nfts-disclaimer.md' %}
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/NFTokenMint.cpp "Source")
The `NFTokenMint` transaction creates a non-fungible token and adds it to the relevant [NFTokenPage object][] of the `NFTokenMinter` 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 `NFTokenMinter` has to specify any token fields that are defined as immutable (for example, the `TokenFlags`).
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
## Example {{currentpage.name}} JSON

View File

@@ -48,7 +48,7 @@ SignerListSetトランザクションは、トランザクションの[マルチ
| フィールド | JSONの型 | [内部の型][] | 説明 |
|:--------------|:----------|:------------------|:-----------------------------|
| SignerQuorum | 数値 | UInt32 | 署名者の重みのターゲット数。このリストの署名者によるマルチ署名は、付与された署名の重みの合計がこの値以上である場合に限り有効となります。SignerListを削除するには、`0`の値を使用します。 |
| SignerEntries | 配列 | 配列 | (削除する場合は省略)このリストの署名者のアドレスと重みを示す[SignerEntryオブジェクト](signerlist.html#signerentryオブジェクト)の配列。SignerListには18人のメンバーが含まれている必要があります。リストに1つのアドレスが複数回表示されることはありません。また、トランザクションを送信する`Account`も表示されません。 |
| SignerEntries | 配列 | 配列 | (削除する場合は省略)このリストの署名者のアドレスと重みを示す[SignerEntryオブジェクト](signerlist.html#signerentryオブジェクト)の配列。SignerListには132人のメンバーが含まれている必要があります。リストに1つのアドレスが複数回表示されることはありません。また、トランザクションを送信する`Account`も表示されません。 |
アカウントは複数のSignerListを所有できません。既存のSignerListが存在する場合は、SignerListSetトランザクションが成功するとその既存のSignerListが置き換えられます。SignerListを削除するには、`SignerQuorum``0`に設定し、_かつ_`SignerEntries`フィールドを省略します。このようにしないと、トランザクションは[temMALFORMED](tem-codes.html)エラーで失敗します。SignerListを削除するトランザクションは、削除するSignerListがない場合でも成功したとみなされます。

View File

@@ -6,7 +6,7 @@ labels:
- Security
---
# SignerListSet
[[Source]](https://github.com/ripple/rippled/blob/ef511282709a6a0721b504c6b7703f9de3eecf38/src/ripple/app/tx/impl/SetSignerList.cpp "Source")
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/ripple/app/tx/impl/SetSignerList.cpp "Source")
The SignerListSet transaction creates, replaces, or removes a list of signers that can be used to [multi-sign](multi-signing.html) a transaction. This transaction type was introduced by the [MultiSign amendment][]. [New in: rippled 0.31.0][]
@@ -48,7 +48,7 @@ The SignerListSet transaction creates, replaces, or removes a list of signers th
| Field | JSON Type | [Internal Type][] | Description |
|:--------------|:----------|:------------------|:-----------------------------|
| `SignerQuorum` | Number | UInt32 | A target number for the signer weights. A multi-signature from this list is valid only if the sum weights of the signatures provided is greater than or equal to this value. To delete a signer list, use the value `0`. |
| `SignerEntries` | Array | Array | (Omitted when deleting) Array of [`SignerEntry` objects](signerlist.html#signer-entry-object), indicating the addresses and weights of signers in this list. This signer list must have at least 1 member and no more than 8 members. If the [ExpandedSignerList amendment][] :not_enabled: is enabled, the list can have up to 32 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. |
| `SignerEntries` | Array | Array | _(Omitted when deleting)_ Array of [`SignerEntry` objects](signerlist.html#signer-entry-object), indicating the addresses and weights of signers in this list. This signer list must have at least 1 member and no more than 32 members. No address may appear more than once in the list, nor may the `Account` submitting the transaction appear in the list. _(Updated by the [ExpandedSignerList amendment][].)_ |
A successful SignerListSet transaction replaces the account's [`SignerList` object](signerlist.html) in the ledger, or adds one if it did not exist before. An account may not have more than one signer list. To delete a signer list, you must set `SignerQuorum` to `0` _and_ omit the `SignerEntries` field. Otherwise, the transaction fails with the error [`temMALFORMED`](tem-codes.html). A transaction to delete a signer list is considered successful even if there was no signer list to delete.
@@ -58,7 +58,7 @@ You can create, update, or remove a signer list using the master key, regular ke
You cannot remove the last method of signing transactions from an account. If an account's master key is disabled (the account has the [`lsfDisableMaster` flag](accountroot.html#accountroot-flags) enabled) and the account does not have a [Regular Key](cryptographic-keys.html) configured, then you cannot delete the signer list from the account. Instead, the transaction fails with the error [`tecNO_ALTERNATIVE_KEY`](tec-codes.html).
With the [MultiSignReserve amendment][] enabled, creating or replacing a signer list enables the `lsfOneOwnerCount` flag on the [SignerList object](signerlist.html). When this flag is enabled, the XRP Ledger is able to lower the [`OwnerCount`](accountroot.html#accountroot-fields) and [owner reserve](reserves.html#owner-reserves) for the signer list. For more information, see [SignerList Flags](signerlist.html#signerlist-flags).
Creating or replacing a signer list enables the `lsfOneOwnerCount` flag on the [SignerList object](signerlist.html). Lists that were created before the [MultiSignReserve amendment][] became enabled do not have this flag and have a higher [owner reserve](reserves.html#owner-reserves). You can decrease the owner reserve for these lists by replacing the list with an identical one. For more information, see [SignerList Flags](signerlist.html#signerlist-flags).
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

View File

@@ -82,7 +82,9 @@ Edit your `rippled.cfg` file.
<!-- MULTICODE_BLOCK_END -->
**Note:** This setting is optional, and does not strictly define which network your server follows, but it helps servers find peers who are following the same network.
For sidechains and custom networks, everyone who connects to the network should use a value unique to that network. When creating a new network, choose a network ID at random from the integers 11 to 4,294,967,295.
**Note:** This setting helps your server find peers who are on the same network, but it is not a hard control on what network your server follows. The UNL / trusted validator settings (in the next step) are what actually define what network the server follows.
## 2. Set your trusted validator list.

View File

@@ -1,5 +1,5 @@
---
html: run-rippled-as-a-wallet-server.html
html: run-rippled-as-a-stock-server.html
parent: configure-rippled.html
blurb: XRPを統合する人のための汎用的な構成。
labels:

View File

@@ -13,7 +13,7 @@ That said, macOS is suitable for many development and testing tasks. `rippled` h
For development purposes, run `rippled` as a non-admin user, not using `sudo`.
1. Install [Xcode](https://developer.apple.com/download/). <!-- SPELLING_IGNORE: xcode -->
1. Install [Xcode](https://developer.apple.com/xcode/). <!-- SPELLING_IGNORE: xcode -->
0. Install Xcode command line tools.
@@ -31,7 +31,7 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
brew install git cmake pkg-config protobuf openssl ninja
0. Install a compatible version of Boost. `rippled` 1.7.2 is compatible with Boost 1.75.0. To compile Boost yourself, complete the following steps:
0. Install a compatible version of Boost. `rippled` 1.9.4 is compatible with Boost 1.75.0. To compile Boost yourself, complete the following steps:
1. [Download version 1.75.0 of Boost](https://www.boost.org/users/history/version_1_75_0.html).
@@ -63,7 +63,7 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
0. Clone the `rippled` source code into your desired location and access the `rippled` directory. To do this, you'll need to set up Git (installed earlier using Homebrew) and GitHub. For example, you'll need to create a GitHub account and set up your SSH key. For more information, see [Set up git](https://docs.github.com/en/get-started/quickstart/set-up-git/).
git clone https://github.com/ripple/rippled.git
git clone https://github.com/XRPLF/rippled.git
cd rippled
0. Switch to the appropriate branch for the software version you want:
@@ -80,9 +80,9 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
git checkout develop
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/XRPLF/rippled/releases).
0. Check the commit log to be sure you're compiling the right code. The most recent commit should be signed by a well-known Ripple developer and should set the version number to the latest released version. The [release announcements for `rippled`](https://xrpl.org/blog/label/rippled-release-notes.html) generally show the exact commit to expect for that release.
0. Check the commit log to be sure you're compiling the right code. The most recent commit should be signed by a well-known community developer and should set the version number to the latest released version. The [release announcements for `rippled`](https://xrpl.org/blog/label/rippled-release-notes.html) generally show the exact commit to expect for that release.
git log -1

View File

@@ -26,7 +26,6 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
- `stable` for the latest production release (`master` branch)
- `unstable` for pre-release builds (`release` branch)
- `nightly` for experimental/development builds (`develop` branch)
- `xls20` for the preview of the [XLS-20d NFT standard](https://github.com/XRPLF/XRPL-Standards/discussions/46) :not_enabled:.
<!-- MULTICODE_BLOCK_START -->

View File

@@ -64,7 +64,6 @@ Before you install `rippled`, you must meet the [System Requirements](system-req
- `unstable` - Pre-release builds ([`release` branch](https://github.com/ripple/rippled/tree/release))
- `nightly` - Experimental/development builds ([`develop` branch](https://github.com/ripple/rippled/tree/develop))
- `xls20` - Preview of the [XLS-20d NFT standard](https://github.com/XRPLF/XRPL-Standards/discussions/46) :not_enabled:.
**Warning:** Unstable and nightly builds may be broken at any time. Do not use these builds for production servers.

View File

@@ -27,11 +27,11 @@ You can download the [Quickstart Samples](https://github.com/XRPLF/xrpl-dev-port
## Get Accounts
1. Open `6.authorized-minter.html` in a browser.
2. Get test accounts.
1. If you have existing NFT-Devnet account seeds:
2. Choose your ledger instance (_Testnet_ or _Devnet_).
1. If you have existing test account seeds:
1. Paste the account seeds in the **Seeds** field.
2. Click **Get Accounts from Seeds**.
2. If you do not have existing NFT-Devnet accounts:
2. If you do not have existing test accounts:
1. Click **Get New Standby Account**.
2. Click **Get New Operational Account**.
@@ -398,9 +398,6 @@ Update the form with fields and buttons to support the new functions.
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">

View File

@@ -23,10 +23,10 @@ You can download the [Quickstart Samples](https://github.com/XRPLF/xrpl-dev-port
1. Open `7.batch-minting.html` in a browser.
2. Get a test account.
1. If you want to use an existing NFT-Devnet account seed:
1. If you want to use an existing account seed:
1. Paste the account seed in the **Seed** field.
2. Click **Get Account from Seed**.
2. If you do not want to use an existing NFT-Devnet account seed, click **Get New Standby Account**.
2. If you do not want to use an existing account seed, click **Get New Standby Account**.
**Note:** Running this command throws an error in the JavaScript console because the `getAccountsFromSeeds` function in `ripplex1-send-xrp.js` looks for the operational seed field, which is not included in this form. You can ignore the error (or fix it in your own implementation).
@@ -360,9 +360,6 @@ For this form:
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">

View File

@@ -28,12 +28,12 @@ You can download the [Quickstart Samples](https://github.com/XRPLF/xrpl-dev-port
## Get Accounts
1. Open `5.broker-nfts.html` in a browser.
2. Choose **XLS20-NFT** as your ledger instance.
2. Choose your ledger instance.
3. Get test accounts.
1. If you have existing NFT-Devnet account seeds:
1. If you have existing account seeds:
1. Paste 3 account seeds in the **Seeds** field.
2. Click **Get Accounts from Seeds**.
2. If you do not have NFT-Devnet account seeds:
2. If you do not have account seeds:
1. Click **Get New Standby Account**.
2. Click **Get New Operational Account**.
3. Click **Get New Broker Account**
@@ -625,9 +625,6 @@ Revise the HTML form to add a new Broker section at the top.
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">

View File

@@ -10,24 +10,18 @@ labels:
---
# 1. Create Accounts and Send XRP
This example shows how to:
1. Create accounts on the Testnet, funded with 10000 test XRP with no actual value.
2. Retrieve the accounts from seed values.
3. Transfer XRP between accounts.
When you create an account, you receive a public/private key pair offline. It does not appear on the ledger until it is funded with XRP. This example shows how to create accounts for Testnet, but not how to create an account that you can use on Mainnet.
![Token Test Harness](img/quickstart2.png)
## Prerequisites
To get started, create a new folder on your local disk and install the JavaScript library using `npm`.
@@ -47,7 +41,7 @@ To get test accounts:
1. Open `1.get-accounts-send-xrp.html` in a browser
2. Choose **NFT-Devnet**, **Testnet**, or **Devnet**.
2. Choose **Testnet** or **Devnet**.
3. Click **Get New Standby Account**.
4. Click **Get New Operational Account.**
5. Copy and paste the **Seeds** field in a persistent location, such as a Notepad, so that you can reuse the accounts after reloading the form.
@@ -80,7 +74,7 @@ You can download the [Quickstart Samples](https://github.com/XRPLF/xrpl-dev-port
## ripplex-1-send-xrp.js
This example can be used with any XRP Ledger network. Currently, there are _Testnet_ and _Devnet,_ with the experimental _NFT-Devnet_ server with support for NFTokens. You can update the code to choose different or additional XRP Ledger networks.
This example can be used with any XRP Ledger network, _Testnet_, or _Devnet_. You can update the code to choose different or additional XRP Ledger networks.
### getNet()
@@ -100,7 +94,6 @@ This function uses brute force `if` statements to discover the selected network
```
let net
if (document.getElementById("xls").checked) net = "wss://xls20-sandbox.rippletest.net:51233"
if (document.getElementById("tn").checked) net = "wss://s.altnet.rippletest.net:51233"
if (document.getElementById("dn").checked) net = "wss://s.devnet.rippletest.net:51233"
return net
@@ -380,7 +373,6 @@ Connect to your selected ledger.
```
Prepare the transaction. This is a Payment transaction from the standby wallet to the operational wallet.
The _Payment_ transaction expects the XRP to be expressed in drops, or 1/millionth of an XRP. You can use the xrpToDrops utility to convert the send amount for you (which beats having to type an extra 6 zeroes to send 1 XRP).
@@ -542,9 +534,6 @@ Create a standard HTML form to send transactions and requests, then display the
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">

View File

@@ -648,9 +648,6 @@ Update the form to support the new functions.
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">

View File

@@ -10,8 +10,6 @@ labels:
# 3. Mint and Burn NFTokens
{% include '_snippets/nfts-disclaimer.md' %}
This example shows how to:
@@ -34,10 +32,10 @@ You can download the [Quickstart Samples](https://github.com/XRPLF/xrpl-dev-port
1. Open `3.mint-nfts.html` in a browser.
2. Get test accounts.
1. If you have existing NFT-Devnet account seeds:
1. If you have existing Testnet account seeds:
1. Paste the account seeds in the **Seeds** field.
2. Click **Get Accounts from Seeds**.
2. If you do not have existing NFT-Devnet accounts:
2. If you do not have existing Testnet accounts:
1. Click **Get New Standby Account**.
2. Click **Get New Operational Account**.
@@ -484,11 +482,7 @@ Bold text in the following indicates changes to the form that support the new fu
<body>
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
Choose your ledger instance:
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">
<label for="testnet">Testnet</label>

View File

@@ -10,8 +10,6 @@ labels:
# 4. Transfer NFTokens
{% include '_snippets/nfts-disclaimer.md' %}
This example shows how to:
@@ -38,12 +36,12 @@ You can download the [Quickstart Samples](https://github.com/XRPLF/xrpl-dev-port
1. Open `4.transfer-nftokens.html` in a browser.
2. Choose **XLS20-NFT** as your ledger instance.
2. Choose your ledger instance (**Testnet** or **Devnet**).
3. Get test accounts.
1. If you have existing NFT-Devnet account seeds
1. If you have existing test account seeds
1. Paste account seeds in the **Seeds** field.
2. Click **Get Accounts from Seeds**.
2. If you do not have NFT-Devnet account seeds:
2. If you do not have test account seeds:
1. Click **Get New Standby Account**.
2. Click **Get New Operational Account**.
@@ -1192,9 +1190,6 @@ Update the form with fields and buttons to support the new functions.
<h1>Token Test Harness</h1>
<form id="theForm">
Choose your ledger instance:
<input type="radio" id="xls" name="server"
value="wss://xls20-sandbox.rippletest.net:51233" checked>
<label for="xls20">XLS20-NFT</label>
&nbsp;&nbsp;
<input type="radio" id="tn" name="server"
value="wss://s.altnet.rippletest.net:51233">

File diff suppressed because it is too large Load Diff

View File

@@ -355,26 +355,6 @@ You can generate a destination tag on-demand when a customer intends to send mon
For more information, see [Source and Destination Tags](source-and-destination-tags.html).
## Gateway Bulletins
Historically, Ripple (the company) published gateway bulletins to introduce new XRP Ledger features or discuss topics related to compliance and risk for issuers. Gateway Bulletins are listed here in reverse chronological order.
- May 13, 2015 - [GB-2015-06 Gateway Bulletin: Corrections to Autobridging (PDF)](assets/pdf/GB-2015-06.pdf) <!-- SPELLING_IGNORE: autobridging -->
- April 17, 2015 - [GB-2015-05 Historical Ledger Query Migration](assets/pdf/GB-2015-05.pdf)
- March 13, 2015 - [GB-2015-04 Action Required: Default Ripple Flag (PDF)](https://ripple.com/files/GB-2015-04.pdf)
- March 3, 2015 - [GB-2015-03 Gateway Advisory: FinCEN Ruling on MoneyGram Compliance Program (PDF)](https://ripple.com/files/GB-2015-03.pdf) <!-- SPELLING_IGNORE: moneygram -->
- March 2, 2015 (Updated) - [GB-2015-02 New Standards: How to be Featured on Ripple Trade and Ripple Charts (PDF)](https://ripple.com/files/GB-2015-02.pdf)
- January 5, 2015 - [GB-2015-01 Gateway Advisory: Reliable Transaction Submission (PDF)](https://ripple.com/files/GB-2015-01.pdf)
- December 18, 2014 - [GB-2014-08 Gateway Advisory: Recent FinCEN Rulings (PDF)](https://ripple.com/files/GB-2014-08.pdf)
- November 4, 2014 -[GB-2014-07 Gateway Advisory: FATF Standards (PDF)](https://ripple.com/files/GB-2014-07.pdf)
- October 17, 2014 -[GB-2014-06 Gateway Advisory: Partial Payment Flag (PDF)](https://ripple.com/files/GB-2014-06.pdf)
- September 24, 2014 - [GB-2014-05 Gateway Advisory: EBA Opinion On Virtual Currency (PDF)](https://ripple.com/files/GB-2014-05.pdf) <!-- SPELLING_IGNORE: eba -->
- September 11, 2014 - [GB-2014-04 Gateway Advisory: CFPB Opinion on Virtual Currency (PDF)](https://ripple.com/files/GB-2014-04.pdf) <!-- SPELLING_IGNORE: cfpb -->
- August 19, 2014 - [GB-2014-03 Updated Feature: Trust Lines UI (PDF)](https://ripple.com/files/GB-2014-03.pdf)
- August 1, 2014 - [GB-2014-02 New Feature: Balance Freeze (PDF)](https://ripple.com/files/GB-2014-02.pdf)
- April 23, 2014, Updated August 14, 2014 -[GB-2014-01 New Feature: Ripple Names (PDF)](https://ripple.com/files/GB-2014-01.pdf)
# Technical Details
## Infrastructure
@@ -472,7 +452,7 @@ For example: If ACME sets a transfer fee of 1%, an XRP Ledger payment to deliver
When you build an automated system to send payments into the XRP Ledger for your customers, you must make sure that it constructs payments carefully. Malicious actors are constantly trying to find ways to trick a system into paying them more money than it should.
One common pitfall is performing pathfinding before sending sending a payment to customers in the XRP Ledger. If you specify the issuers correctly, the [default paths](paths.html#default-paths) can deliver the currency as intended.
One common pitfall is performing pathfinding before sending a payment to customers in the XRP Ledger. If you specify the issuers correctly, the [default paths](paths.html#default-paths) can deliver the currency as intended.
The following is an example of using a locally-hosted `rippled`'s [submit method][] to send a payment from the operational address `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn` to the customer address `raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n`, sending and delivering funds issued by the issuing address `rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW`.

View File

@@ -239,6 +239,7 @@ pages:
# # renaming the original file in that target and translating the changes
# # - ja
#
- name: Use Cases & Featured Projects
template: page-uses.html.jinja
html: uses.html
@@ -402,6 +403,7 @@ pages:
# #- intro-to-consensus.html
# - public-api-methods.html
top_nav_hero_image: top-nav-hero-docs
# popular_pages: #TODO: find a way so this isn't a partial duplicate of top_nav_shortcuts?
# - send-xrp.html
# - reserves.html
@@ -410,6 +412,7 @@ pages:
# - build-run-rippled-in-reporting-mode.html
# #- intro-to-consensus.html
# - public-api-methods.html
blurb: Explore XRP Ledger documentation and everything you need to know to start building and integrating with the ledger.
top_nav_blurb: Dive into XRP Ledger technology and start integrating.
filters:
@@ -439,14 +442,16 @@ pages:
# - intro-to-consensus.html
- public-api-methods.html
top_nav_hero_image: top-nav-hero-docs
popular_pages: #TODO: find a way so this isn't a partial duplicate of top_nav_shortcuts?
popular_pages: # TODO: find a way so this isn't a partial duplicate of top_nav_shortcuts?
- send-xrp.html
- reserves.html
- xrp-testnet-faucet.html
- run-rippled-as-a-validator.html
- build-run-rippled-in-reporting-mode.html
# - intro-to-consensus.html
blurb: Dive into XRP Ledger technology and start integrating. #TODO: translate
# blurb: Dive into XRP Ledger technology and start integrating. #TODO: translate
filters:
- labels
targets:
@@ -898,41 +903,49 @@ pages:
targets:
- ja
# TODO: translate
- md: tutorials/quickstart/xrpl-quickstart.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/create-accounts-send-xrp.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/create-trustline-send-currency.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/mint-and-burn-nftokens.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/transfer-nftokens.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/broker-sale.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/authorize-minter.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/quickstart/batch-minting.md
targets:
- en
@@ -954,11 +967,13 @@ pages:
targets:
- ja
# TODO: translate
- md: tutorials/get-started/get-started-using-python.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/get-started/get-started-using-java.md
targets:
- en
@@ -1266,7 +1281,7 @@ pages:
- en
- ja
#TODO: split concept info off of the paychan tutorial
# TODO: split concept info off of the paychan tutorial
- md: tutorials/use-specialized-payment-types/use-payment-channels.md
targets:
- en
@@ -1358,12 +1373,6 @@ pages:
- en
- ja
# TODO: translate
- md: tutorials/use-tokens/nftoken-tester-tutorial.md
targets:
- en
- ja
# TODO: translate this page & blurb
- md: tutorials/use-tokens/enable-no-freeze.md
targets:
@@ -1821,7 +1830,7 @@ pages:
targets:
- en
#TODO: translate the blurb in this page's frontmatter
# TODO: translate the blurb in this page's frontmatter
- md: tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.ja.md
targets:
- ja
@@ -1842,6 +1851,7 @@ pages:
targets:
- ja
# TODO: translate title & blurb
- name: Manage the Clio Server
html: manage-the-clio-server.html
parent: tutorials.html
@@ -1851,41 +1861,70 @@ pages:
- en
- ja
# TODO: translate
- md: tutorials/manage-the-clio-server/install-clio-on-ubuntu.md
targets:
- en
- ja
- name: Amendments
longer_name: Amendments
template: page-references.html.jinja
html: amendments-top.html
parent: docs.html
top_nav_grouping: Article Types
sidebar: disabled
blurb: The amendment process and known amendments to XRPL protocols.
# TODO: translate title & blurb
- name: Interoperability - EVM Sidechain
html: evm-sidechains.html
parent: tutorials.html
blurb: Learn how to interact with the EVM Sidechain Devnet.
template: pagetype-category.html.jinja
targets:
- en
- ja
# TODO: translate
- md: tutorials/interoperability/get-started-evm-sidechain.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/interoperability/connect-metamask-to-xrpl-evm-sidechain.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/interoperability/join-evm-sidechain-devnet.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/interoperability/evm-sidechain-validator-security.md
targets:
- en
- ja
# TODO: translate
- md: tutorials/interoperability/evm-sidechain-run-a-validator-node.md
targets:
- en
- ja
- md: amendments/amendments.md
parent: amendments-top.html
targets:
- en
# - md: amendments/amendments.ja.md
# parent: amendments-top.html
# targets:
# - ja
- md: amendments/known-amendments.md
parent: amendments-top.html
parent: amendments.html
targets:
- en
# - md: concepts/consensus-network/amendments/known-amendments.ja.md
# parent: amendments-top.html
# targets:
# - ja
- md: amendments/amendments.ja.md
targets:
- ja
- md: amendments/known-amendments.ja.md
parent: known-amendments.ja.html
targets:
- ja
# References -------------------------------------------------------------------
@@ -1912,6 +1951,7 @@ pages:
- ja
# TODO: translate title & blurb
- name: XRP Ledger Protocol Reference
html: protocol-reference.html
parent: references.html
@@ -2131,8 +2171,6 @@ pages:
targets:
- ja
# TODO: translate _snippets/tx-fields-intro.md
- md: references/protocol-reference/transactions/transaction-types/accountset.md
targets:
- en
@@ -2744,7 +2782,7 @@ pages:
html: transaction-methods.html # watch for clashes w/ this filename
parent: public-api-methods.html
template: pagetype-category.html.jinja
blurb: Transactions are the only thing that can modify the shared state of the XRP Ledger. All business on the XRP Ledger takes the form of transactions. Use these methods to work with transactions. #TODO:translate
blurb: Transactions are the only thing that can modify the shared state of the XRP Ledger. All business on the XRP Ledger takes the form of transactions. Use these methods to work with transactions. # TODO: translate
targets:
- en
@@ -2856,10 +2894,11 @@ pages:
targets:
- ja
# TODO: translate title & blurb
- name: Payment Channel Methods
html: payment-channel-methods.html
parent: public-api-methods.html
blurb: Payment channels are a tool for facilitating repeated, unidirectional payments, or temporary credit between two parties. Use these methods to work with payment channels. #TODO:translate
blurb: Payment channels are a tool for facilitating repeated, unidirectional payments, or temporary credit between two parties. Use these methods to work with payment channels.
template: pagetype-category.html.jinja
targets:
- en
@@ -2881,10 +2920,11 @@ pages:
targets:
- ja
# TODO: translate title & blurb
- name: Subscription Methods
html: subscription-methods.html
parent: public-api-methods.html
blurb: Use these methods to enable the server to push updates to your client when various events happen, so that you can know and react right away. WebSocket API only. #TODO:translate
blurb: Use these methods to enable the server to push updates to your client when various events happen, so that you can know and react right away. WebSocket API only.
template: pagetype-category.html.jinja
targets:
- en
@@ -2959,7 +2999,7 @@ pages:
targets:
- ja
# TODO: translate
# TODO: translate title & blurb
- name: Clio Server Methods
html: clio-methods.html
parent: public-api-methods.html
@@ -2987,6 +3027,7 @@ pages:
- en
- ja
# TODO: translate title & blurb
- name: Utility Methods
html: utility-methods.html
parent: public-api-methods.html
@@ -3079,10 +3120,11 @@ pages:
targets:
- en
# TODO: translate blurb
- name: ログとデータ管理のメソッド
html: logging-and-data-management-methods.html
parent: admin-api-methods.html
blurb: Use these methods to manage log levels and other data, such as ledgers. #TODO: translate
blurb: Use these methods to manage log levels and other data, such as ledgers.
template: pagetype-category.html.jinja
targets:
- ja
@@ -3151,7 +3193,7 @@ pages:
targets:
- ja
#TODO: translate title and blurb
# TODO: translate title and blurb
- name: Server Control Methods
html: server-control-methods.html
parent: admin-api-methods.html
@@ -3185,10 +3227,11 @@ pages:
targets:
- ja
# TODO: translate title & blurb
- name: Signing Methods
html: signing-methods.html
parent: admin-api-methods.html
blurb: Use these methods to work with transactions. #TODO:translate
blurb: Use these methods to work with transactions.
template: pagetype-category.html.jinja
targets:
- en
@@ -3926,6 +3969,7 @@ pages:
html: dev-tools.html
template: page-dev-tools.html.jinja
parent: docs.html
top_nav_grouping: Online Tools
sidebar: left_only
targets:
- en
@@ -3939,6 +3983,14 @@ pages:
targets:
- en
- ja
- name: XRPL Education Portal
html: https://learn.xrpl.org/
parent: docs.html
top_nav_grouping: Online Tools
targets:
- en
- ja
- name: RPC Tool
html: xrp-ledger-rpc-tool.html
@@ -4258,6 +4310,7 @@ known_broken_links:
- https://xrpl-hackathon-2021.devpost.com/project-gallery
- https://xrplimpact.devpost.com/
- https://www.postgresqltutorial.com/install-postgresql-linux/
- http://www.investopedia.com/terms/o/order-book.asp
# This site often times out, but it does work and is the original.
- https://theworld.com/~reinhold/diceware.html

Binary file not shown.

Before

Width:  |  Height:  |  Size: 86 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 185 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 136 KiB

After

Width:  |  Height:  |  Size: 144 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 209 KiB

After

Width:  |  Height:  |  Size: 224 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 209 KiB

After

Width:  |  Height:  |  Size: 199 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 200 KiB

After

Width:  |  Height:  |  Size: 192 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 120 KiB

After

Width:  |  Height:  |  Size: 106 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 160 KiB

After

Width:  |  Height:  |  Size: 152 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 196 KiB

After

Width:  |  Height:  |  Size: 190 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 185 KiB

After

Width:  |  Height:  |  Size: 178 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 198 KiB

After

Width:  |  Height:  |  Size: 193 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 223 KiB

After

Width:  |  Height:  |  Size: 219 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 212 KiB

After

Width:  |  Height:  |  Size: 206 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 64 KiB

After

Width:  |  Height:  |  Size: 53 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 189 KiB

After

Width:  |  Height:  |  Size: 182 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 107 KiB

After

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 153 KiB

After

Width:  |  Height:  |  Size: 162 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 178 KiB

After

Width:  |  Height:  |  Size: 191 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 160 KiB

After

Width:  |  Height:  |  Size: 171 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 148 KiB

After

Width:  |  Height:  |  Size: 157 KiB

Some files were not shown because too many files have changed in this diff Show More