mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-13 08:15:49 +00:00
Compare commits
35 Commits
tutorial_f
...
blog-ai-on
| Author | SHA1 | Date | |
|---|---|---|---|
|
64ed9cf3c2 | ||
|
|
3be171ba8d | ||
|
|
0dc8ff7a77 | ||
|
|
9a2ae0f4b0 | ||
|
|
eb6dba60a6 | ||
|
|
c78e0f8727 | ||
|
|
77b44d4e7a | ||
|
|
9ea2b13c4c | ||
|
|
c95613261f | ||
|
|
468c8d3a47 | ||
|
|
94686086ee | ||
|
|
207e50caa2 | ||
|
|
985a47a4bb | ||
|
|
30e6767f58 | ||
|
|
6947fccf57 | ||
|
|
bab45a105d | ||
|
|
31e9682f81 | ||
|
|
d903bf9c2a | ||
|
|
8617ed2642 | ||
|
|
e12e40a926 | ||
|
|
0eadc32085 | ||
|
|
3b7d66ee7e | ||
|
|
8fc4d8fa6d | ||
|
|
a2cfcb2dbc | ||
|
|
2b8673c355 | ||
|
|
ba4750d2cc | ||
|
|
a638266581 | ||
|
|
1e7ab3ea5c | ||
|
|
aec8b0f007 | ||
|
|
d58ddaf13a | ||
|
|
98684cc3a1 | ||
|
|
e3ec322c8f | ||
|
|
c68bc530b2 | ||
|
|
72325730c3 | ||
|
|
97c692c767 |
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: deleting-accounts.html
|
||||
parent: accounts.html
|
||||
blurb: Acerca de eliminar una cuenta XRP Ledger.
|
||||
seo:
|
||||
description: Acerca de eliminar una cuenta XRP Ledger.
|
||||
labels:
|
||||
- Cuentas
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: consensus-protections.html
|
||||
parent: consensus.html
|
||||
blurb: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
|
||||
seo:
|
||||
description: Aprende cómo el Protocolo de Consenso del XRP Ledger se protege contra varios problemas y ataques que pueden ocurrir en un sistema financiero descentralizado.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
|
||||
@@ -14,8 +14,8 @@
|
||||
[AMMVoteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammvote.md
|
||||
[AMMWithdraw]: /@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
|
||||
[AMMWithdrawトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/ammwithdraw.md
|
||||
[API v1]: /@l10n/ja/docs/references/http-websocket-apis/api-conventions/request-formatting.md#api-versioning
|
||||
[API v2]: /@l10n/ja/docs/references/http-websocket-apis/api-conventions/request-formatting.md#api-versioning
|
||||
[API v1]: /@l10n/ja/docs/references/http-websocket-apis/index.md
|
||||
[API v2]: /@l10n/ja/docs/references/http-websocket-apis/index.md
|
||||
[AccountDelete]: /@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
|
||||
[AccountDeleteトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/accountdelete.md
|
||||
[AccountRootエントリ]: /@l10n/ja/docs/references/protocol/ledger-data/ledger-entry-types/accountroot.md
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: ディープフリーズは、トラストラインのフリーズが解除されるまで、フリーズされたトークン保有者がその資金を送受信できないようにします。
|
||||
seo:
|
||||
description: ディープフリーズは、トラストラインのフリーズが解除されるまで、フリーズされたトークン保有者がその資金を送受信できないようにします。
|
||||
labels:
|
||||
- トークン
|
||||
- フリーズ
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: Multi-Purpose Tokenは、トラストラインよりもコンパクトで柔軟なトークンタイプです。
|
||||
seo:
|
||||
description: Multi-Purpose Tokenは、トラストラインよりもコンパクトで柔軟なトークンタイプです。
|
||||
labels:
|
||||
- トークン
|
||||
- MPT
|
||||
|
||||
@@ -81,7 +81,7 @@ rippled -- account_tx rLNaPoKeeBjZe2qs6x52yVPZpZ8td4dc6w -1 -1 2 0 binary descen
|
||||
| `marker` | [マーカー][] | 以前にページネーションされたレスポンスの値。そのレスポンスを停止した箇所からデータの取得を再開します。サーバが使用できるレジャーの範囲に変更があっても、この値は変わりません。 |
|
||||
|
||||
- リクエスト内で次の各フィールドのうち1つ以上を使用する必要があります: `ledger_index`、`ledger_hash`、`ledger_index_min`、または`ledger_index_max`。
|
||||
- [API v2]： `ledger_index`と`ledger_hash`のどちらかを指定した場合、`ledger_index_min`と`ledger_index_max`を含めると`invalidParams`エラーが返ります。
|
||||
- [API v2][]： `ledger_index`と`ledger_hash`のどちらかを指定した場合、`ledger_index_min`と`ledger_index_max`を含めると`invalidParams`エラーが返ります。
|
||||
|
||||
|
||||
### 照会されたデータの繰り返し
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: get_aggregate_price.html
|
||||
parent: ledger-methods.html
|
||||
blurb: 指定されたOracleインスタンスの集計価格を計算します。
|
||||
seo:
|
||||
description: 指定されたOracleインスタンスの集計価格を計算します。
|
||||
labels:
|
||||
- オラクル
|
||||
---
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: 指定された`MPTokenIssuanceID`とledgerシーケンスに対する所有者の情報を取得します。
|
||||
seo:
|
||||
description: 指定された`MPTokenIssuanceID`とledgerシーケンスに対する所有者の情報を取得します。
|
||||
labels:
|
||||
- アカウント
|
||||
- XRP
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: XRPLのMulti-Purpose Tokenのオブジェクトについて説明します。
|
||||
seo:
|
||||
description: XRPLのMulti-Purpose Tokenのオブジェクトについて説明します。
|
||||
labels:
|
||||
- Multi-Purpose Token, MPT, トークン
|
||||
---
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: Introduction to XRPL MPTs.
|
||||
seo:
|
||||
description: 単一のMPT Issuanceを表し、Issuance自体に関連するデータを保持します。
|
||||
labels:
|
||||
- Multi-Purpose Token, MPT, トークン
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: mptokenauthorize.html
|
||||
parent: transaction-types.html
|
||||
blurb: アカウントが特定のMPTの残高を保持することを許可します。
|
||||
seo:
|
||||
description: アカウントが特定のMPTの残高を保持することを許可します。
|
||||
labels:
|
||||
- Multi-Purpose Token, MPT
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: mptokenissuancecreate.html
|
||||
parent: transaction-types.html
|
||||
blurb: 新しいMulti-Purpose Tokenを発行します。
|
||||
seo:
|
||||
description: 新しいMulti-Purpose Tokenを発行します。
|
||||
labels:
|
||||
- Multi-Purpose Token, MPT
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: mptokenissuancedestroy.html
|
||||
parent: transaction-types.html
|
||||
blurb: レジャーからMulti-Purpose Tokenを削除します。
|
||||
seo:
|
||||
description: Multi-Purpose Tokenを削除します。
|
||||
labels:
|
||||
- Multi-Purpose Token, MPT
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: mptokenissuanceset.html
|
||||
parent: transaction-types.html
|
||||
blurb: MPTの変更可能なプロパティを設定します。
|
||||
seo:
|
||||
description: MPTの変更可能なプロパティを設定します。
|
||||
labels:
|
||||
- Multi-Purpose Token, MPT
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: oracledelete.html
|
||||
parent: transaction-types.html
|
||||
blurb: 既存の価格オラクルを削除します。
|
||||
seo:
|
||||
description: 既存の価格オラクルを削除します。
|
||||
labels:
|
||||
- オラクル
|
||||
---
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: OracleSet.html
|
||||
parent: transaction-types.html
|
||||
blurb: 価格オラクルを作成または更新します。
|
||||
seo:
|
||||
description: 価格オラクルを作成または更新します。
|
||||
labels:
|
||||
- オラクル
|
||||
---
|
||||
|
||||
@@ -139,6 +139,10 @@ footer.community.report-a-scam: 詐欺の報告
|
||||
|
||||
component.tryit: 試してみる
|
||||
component.queryexampletx: トランザクションの例を確認
|
||||
component.amendment-status.requires.1: " "
|
||||
component.amendment-status.requires.2: が必要です。
|
||||
component.amendment-status.added.1: " "
|
||||
component.amendment-status.added.2: により追加されました。
|
||||
|
||||
# Amendment tracker translations
|
||||
amendment.loading: ロード中Amendments...
|
||||
|
||||
@@ -20,7 +20,10 @@ export function IndexPageItems() {
|
||||
{data?.map((item: any) => (
|
||||
<li className="level-1" key={item.slug}>
|
||||
<Link to={item.slug}>{item.title}</Link>
|
||||
<p className='class="blurb child-blurb'>{item.blurb}</p>
|
||||
{
|
||||
item.status === "not_enabled" ? (<NotEnabled />) : ""
|
||||
}
|
||||
<p className='class="blurb child-blurb'>{item.seo?.description}</p>
|
||||
</li>
|
||||
))}
|
||||
</ul>
|
||||
@@ -380,3 +383,103 @@ function AmendmentBadge(props: { amendment: Amendment }) {
|
||||
|
||||
return <img src={badgeUrl} alt={status} className="shield" />;
|
||||
}
|
||||
|
||||
export function AmendmentDisclaimer(props: {
|
||||
name: string,
|
||||
compact: boolean
|
||||
}) {
|
||||
const [amendmentStatus, setStatus] = React.useState<Amendment | null>(null);
|
||||
const [loading, setLoading] = React.useState(true);
|
||||
const [error, setError] = React.useState<string | null>(null);
|
||||
const { useTranslate } = useThemeHooks();
|
||||
const { translate } = useTranslate();
|
||||
|
||||
const link = () => <Link to={`/resources/known-amendments#${props.name.toLowerCase()}`}>{props.name}{ props.compact ? "" : " amendment"}</Link>
|
||||
|
||||
React.useEffect(() => {
|
||||
const fetchAmendments = async () => {
|
||||
try {
|
||||
setLoading(true);
|
||||
const response = await fetch(`https://vhs.prod.ripplex.io/v1/network/amendments/vote/main/`);
|
||||
if (!response.ok) {
|
||||
throw new Error(`HTTP error! status: ${response.status}`);
|
||||
}
|
||||
const data: AmendmentsResponse = await response.json()
|
||||
console.log("data.amendments is:", data.amendments)
|
||||
|
||||
let found_amendment = false
|
||||
for (const amendment of data.amendments) {
|
||||
if (amendment.name == props.name) {
|
||||
setStatus(amendment)
|
||||
found_amendment = true
|
||||
break
|
||||
}
|
||||
}
|
||||
if (!found_amendment) {
|
||||
throw new Error(`Couldn't find ${props.name} amendment in status table.`)
|
||||
}
|
||||
} catch (err) {
|
||||
setError(err instanceof Error ? err.message : 'Failed to fetch amendments');
|
||||
} finally {
|
||||
setLoading(false)
|
||||
}
|
||||
}
|
||||
fetchAmendments()
|
||||
}, [])
|
||||
|
||||
if (loading) {
|
||||
return (
|
||||
<p><em>
|
||||
{translate("component.amendment-status.requires.1", "Requires the ")}{link()}{translate("component.amendment-status.requires.2", ".")}
|
||||
{" "}
|
||||
<span className="spinner-border text-primary" role="status">
|
||||
<span className="sr-only">{translate("amendment.loading_status", "Loading...")}</span>
|
||||
</span>
|
||||
</em></p>
|
||||
)
|
||||
}
|
||||
|
||||
if (error) {
|
||||
return (
|
||||
<p><em>
|
||||
{translate("component.amendment-status.requires.1", "Requires the ")}{link()}{translate("component.amendment-status.requires.2", ".")}
|
||||
{" "}
|
||||
<span className="alert alert-danger" style={{display: "block"}}>
|
||||
<strong>{translate("amendment.error_status", "Error loading amendment status")}:</strong> {error}
|
||||
</span>
|
||||
</em></p>
|
||||
)
|
||||
}
|
||||
|
||||
if (props.compact) {
|
||||
return (
|
||||
<>
|
||||
{link()}
|
||||
{" "}
|
||||
<AmendmentBadge amendment={amendmentStatus} />
|
||||
</>
|
||||
)
|
||||
}
|
||||
|
||||
return (
|
||||
<p><em>(
|
||||
{
|
||||
amendmentStatus.date ? (
|
||||
<>
|
||||
{translate("component.amendment-status.added.1", "Added by the ")}{link()}
|
||||
{translate("component.amendment-status.added.2", ".")}
|
||||
{" "}
|
||||
<AmendmentBadge amendment={amendmentStatus} />
|
||||
</>
|
||||
) : (
|
||||
<>
|
||||
{translate("component.amendment-status.requires.1", "Requires the ")}{link()}
|
||||
{translate("component.amendment-status.requires.2", ".")}
|
||||
{" "}
|
||||
<AmendmentBadge amendment={amendmentStatus} />
|
||||
</>
|
||||
)
|
||||
}
|
||||
)</em></p>
|
||||
)
|
||||
}
|
||||
|
||||
@@ -221,3 +221,20 @@ export const amendmentsTable: Schema & { tagName: string } = {
|
||||
render: 'AmendmentsTable',
|
||||
selfClosing: true
|
||||
}
|
||||
|
||||
export const amendmentDisclaimer: Schema & { tagName: string } = {
|
||||
tagName: 'amendment-disclaimer',
|
||||
attributes: {
|
||||
name: {
|
||||
type: 'String',
|
||||
required: true
|
||||
},
|
||||
compact: {
|
||||
type: 'Boolean',
|
||||
required: false,
|
||||
default: false
|
||||
}
|
||||
},
|
||||
render: 'AmendmentDisclaimer',
|
||||
selfClosing: true
|
||||
}
|
||||
|
||||
253
_api-examples/account_objects/jsonrpc-response.json
Normal file
253
_api-examples/account_objects/jsonrpc-response.json
Normal file
@@ -0,0 +1,253 @@
|
||||
{
|
||||
"result": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"account_objects": [
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "ASP",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 65536,
|
||||
"HighLimit": {
|
||||
"currency": "ASP",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "ASP",
|
||||
"issuer": "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
|
||||
"value": "10"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "BF7555B0F018E3C5E2A3FF9437A1A5092F32903BE246202F988181B9CED0D862",
|
||||
"PreviousTxnLgrSeq": 1438879,
|
||||
"index": "2243B0B630EA6F7330B654EFA53E27A7609D9484E535AB11B7F946DF3D247CE9"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "JOE",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "JOE",
|
||||
"issuer": "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
|
||||
"value": "100"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "JOE",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "8E488B0E939D4DACD62102A5BFA2FDC63679EFCC56F2FDA2FDF45283674BB711",
|
||||
"PreviousTxnLgrSeq": 5989200,
|
||||
"index": "273BD42DD72E7D84416ED759CEC92DACCD12A4502287E50BECF816233C021ED1"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rEhDDUUNxpXgEHVJtC2cjXAgyx5VCFxdMF",
|
||||
"value": "1"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"index": "2CC2B211F6D1159B5CFD07AF8717A9C51C985E2497B2875C192EE87266AB0F81"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "5"
|
||||
},
|
||||
"Flags": 1114112,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "5"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "2A5C5D95880A254A2C57BB5332558205BC33B9F2B38D359A170283CB4CBD080A",
|
||||
"PreviousTxnLgrSeq": 39498567,
|
||||
"index": "2DECFAC23B77D5AEA6116C15F5C6D4669EBAEE9E7EE050A40FE2B1E47B6A9419"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "EUR",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0.793598266778297"
|
||||
},
|
||||
"Flags": 1114112,
|
||||
"HighLimit": {
|
||||
"currency": "EUR",
|
||||
"issuer": "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "EUR",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "1"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "E9345D44433EA368CFE1E00D84809C8E695C87FED18859248E13662D46A0EC46",
|
||||
"PreviousTxnLgrSeq": 5447146,
|
||||
"index": "4513749B30F4AF8DA11F077C448128D6486BF12854B760E4E5808714588AA915"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "CNY",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "CNY",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "3"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "CNY",
|
||||
"issuer": "rnuF96W4SZoCJmbHYBFoJZpR8eCaxNvekK",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "8",
|
||||
"PreviousTxnID": "2FDDC81F4394695B01A47913BEC4281AC9A283CC8F903C14ADEA970F60E57FCF",
|
||||
"PreviousTxnLgrSeq": 5949673,
|
||||
"index": "578C327DA8944BDE2E10C9BA36AFA2F43E06C8D1E8819FB225D266CBBCFDE5CE"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "DYM",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "1.336889190631542"
|
||||
},
|
||||
"Flags": 65536,
|
||||
"HighLimit": {
|
||||
"currency": "DYM",
|
||||
"issuer": "rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "DYM",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "3"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "6DA2BD02DFB83FA4DAFC2651860B60071156171E9C021D9E0372A61A477FFBB1",
|
||||
"PreviousTxnLgrSeq": 8818732,
|
||||
"index": "5A2A5FF12E71AEE57564E624117BBA68DEF78CD564EF6259F92A011693E027C7"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "BTC",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "BTC",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "3"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "BTC",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "43",
|
||||
"PreviousTxnID": "03EDF724397D2DEE70E49D512AECD619E9EA536BE6CFD48ED167AE2596055C9A",
|
||||
"PreviousTxnLgrSeq": 8317037,
|
||||
"index": "767C12AF647CDF5FEB9019B37018748A79C50EDAF87E8D4C7F39F78AA7CA9765"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-11.68225001668339"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "5000"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "4a",
|
||||
"PreviousTxnID": "8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B",
|
||||
"PreviousTxnLgrSeq": 43251698,
|
||||
"index": "826CF5BFD28F3934B518D0BDF3231259CBD3FD0946E3C3CA0C97D2C75D2D1A09"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
|
||||
"value": "100"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "B1A7405C4A698E6A371E5B02836E779A942936AB754865FE82141E5280F09D1B",
|
||||
"PreviousTxnLgrSeq": 5718137,
|
||||
"index": "8DF1456AAB7470A760F6A095C156B457FF1038D43E6B11FD8011C2DF714E4FA1"
|
||||
}
|
||||
],
|
||||
"ledger_hash": "E471A081996BB5CBB666AC99085CB8E3CA4D59DFCEDC0060B8701DC45A0EE423",
|
||||
"ledger_index": 98162290,
|
||||
"limit": 10,
|
||||
"marker": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93,94A9F05FEF9A153229E2E997E64919FD75AAE2028C8153E8EBDB4440BD3ECBB5",
|
||||
"status": "success",
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
256
_api-examples/account_objects/ws-response.json
Normal file
256
_api-examples/account_objects/ws-response.json
Normal file
@@ -0,0 +1,256 @@
|
||||
{
|
||||
"id": "example_account_objects",
|
||||
"result": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"account_objects": [
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "ASP",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 65536,
|
||||
"HighLimit": {
|
||||
"currency": "ASP",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "ASP",
|
||||
"issuer": "r3vi7mWxru9rJCxETCyA1CHvzL96eZWx5z",
|
||||
"value": "10"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "BF7555B0F018E3C5E2A3FF9437A1A5092F32903BE246202F988181B9CED0D862",
|
||||
"PreviousTxnLgrSeq": 1438879,
|
||||
"index": "2243B0B630EA6F7330B654EFA53E27A7609D9484E535AB11B7F946DF3D247CE9"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "JOE",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "JOE",
|
||||
"issuer": "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
|
||||
"value": "100"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "JOE",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "8E488B0E939D4DACD62102A5BFA2FDC63679EFCC56F2FDA2FDF45283674BB711",
|
||||
"PreviousTxnLgrSeq": 5989200,
|
||||
"index": "273BD42DD72E7D84416ED759CEC92DACCD12A4502287E50BECF816233C021ED1"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rEhDDUUNxpXgEHVJtC2cjXAgyx5VCFxdMF",
|
||||
"value": "1"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"index": "2CC2B211F6D1159B5CFD07AF8717A9C51C985E2497B2875C192EE87266AB0F81"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "5"
|
||||
},
|
||||
"Flags": 1114112,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "5"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "2A5C5D95880A254A2C57BB5332558205BC33B9F2B38D359A170283CB4CBD080A",
|
||||
"PreviousTxnLgrSeq": 39498567,
|
||||
"index": "2DECFAC23B77D5AEA6116C15F5C6D4669EBAEE9E7EE050A40FE2B1E47B6A9419"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "EUR",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0.793598266778297"
|
||||
},
|
||||
"Flags": 1114112,
|
||||
"HighLimit": {
|
||||
"currency": "EUR",
|
||||
"issuer": "rLEsXccBGNR3UPuPu2hUXPjziKC3qKSBun",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "EUR",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "1"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "E9345D44433EA368CFE1E00D84809C8E695C87FED18859248E13662D46A0EC46",
|
||||
"PreviousTxnLgrSeq": 5447146,
|
||||
"index": "4513749B30F4AF8DA11F077C448128D6486BF12854B760E4E5808714588AA915"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "CNY",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "CNY",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "3"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "CNY",
|
||||
"issuer": "rnuF96W4SZoCJmbHYBFoJZpR8eCaxNvekK",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "8",
|
||||
"PreviousTxnID": "2FDDC81F4394695B01A47913BEC4281AC9A283CC8F903C14ADEA970F60E57FCF",
|
||||
"PreviousTxnLgrSeq": 5949673,
|
||||
"index": "578C327DA8944BDE2E10C9BA36AFA2F43E06C8D1E8819FB225D266CBBCFDE5CE"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "DYM",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "1.336889190631542"
|
||||
},
|
||||
"Flags": 65536,
|
||||
"HighLimit": {
|
||||
"currency": "DYM",
|
||||
"issuer": "rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "DYM",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "3"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "6DA2BD02DFB83FA4DAFC2651860B60071156171E9C021D9E0372A61A477FFBB1",
|
||||
"PreviousTxnLgrSeq": 8818732,
|
||||
"index": "5A2A5FF12E71AEE57564E624117BBA68DEF78CD564EF6259F92A011693E027C7"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "BTC",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "BTC",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "3"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "BTC",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "43",
|
||||
"PreviousTxnID": "03EDF724397D2DEE70E49D512AECD619E9EA536BE6CFD48ED167AE2596055C9A",
|
||||
"PreviousTxnLgrSeq": 8317037,
|
||||
"index": "767C12AF647CDF5FEB9019B37018748A79C50EDAF87E8D4C7F39F78AA7CA9765"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-11.68225001668339"
|
||||
},
|
||||
"Flags": 131072,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "5000"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "4a",
|
||||
"PreviousTxnID": "8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B",
|
||||
"PreviousTxnLgrSeq": 43251698,
|
||||
"index": "826CF5BFD28F3934B518D0BDF3231259CBD3FD0946E3C3CA0C97D2C75D2D1A09"
|
||||
},
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "0"
|
||||
},
|
||||
"Flags": 2228224,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rE6R3DWF9fBD7CyiQciePF9SqK58Ubp8o2",
|
||||
"value": "100"
|
||||
},
|
||||
"HighNode": "0",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0",
|
||||
"PreviousTxnID": "B1A7405C4A698E6A371E5B02836E779A942936AB754865FE82141E5280F09D1B",
|
||||
"PreviousTxnLgrSeq": 5718137,
|
||||
"index": "8DF1456AAB7470A760F6A095C156B457FF1038D43E6B11FD8011C2DF714E4FA1"
|
||||
}
|
||||
],
|
||||
"ledger_hash": "59D7E38286AD80C402EC1533BFE002285E792698EEFA06BD3D5AEAC618B56B0A",
|
||||
"ledger_index": 98162008,
|
||||
"limit": 10,
|
||||
"marker": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93,94A9F05FEF9A153229E2E997E64919FD75AAE2028C8153E8EBDB4440BD3ECBB5|NONFH",
|
||||
"validated": true,
|
||||
"_nodepref": "nonfh"
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
@@ -830,12 +830,13 @@ set-function-length@^1.2.2:
|
||||
has-property-descriptors "^1.0.2"
|
||||
|
||||
sha.js@^2.4.0, sha.js@^2.4.11, sha.js@^2.4.8:
|
||||
version "2.4.11"
|
||||
resolved "https://registry.yarnpkg.com/sha.js/-/sha.js-2.4.11.tgz#37a5cf0b81ecbc6943de109ba2960d1b26584ae7"
|
||||
integrity sha512-QMEp5B7cftE7APOjk5Y6xgrbWu+WkLVQwk8JNjZ8nKRciZaByEW6MubieAiToS7+dwvrjGhH8jRXz3MVd0AYqQ==
|
||||
version "2.4.12"
|
||||
resolved "https://registry.yarnpkg.com/sha.js/-/sha.js-2.4.12.tgz#eb8b568bf383dfd1867a32c3f2b74eb52bdbf23f"
|
||||
integrity sha512-8LzC5+bvI45BjpfXU8V5fdU2mfeKiQe1D1gIMn7XUlF3OTUrpdJpPPH4EMAnF0DsHHdSZqCdSss5qCmJKuiO3w==
|
||||
dependencies:
|
||||
inherits "^2.0.1"
|
||||
safe-buffer "^5.0.1"
|
||||
inherits "^2.0.4"
|
||||
safe-buffer "^5.2.1"
|
||||
to-buffer "^1.2.0"
|
||||
|
||||
source-map-js@^1.2.1:
|
||||
version "1.2.1"
|
||||
|
||||
@@ -6,34 +6,27 @@ Quick install & usage:
|
||||
|
||||
```sh
|
||||
npm install
|
||||
node ./verify_credential.js
|
||||
```
|
||||
|
||||
The output should look something like this:
|
||||
`verify_credential.js` can also be used as a commandline utility. Full usage statement:
|
||||
|
||||
```text
|
||||
Looking up credential...
|
||||
{
|
||||
"command": "ledger_entry",
|
||||
"credential": {
|
||||
"subject": "rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA",
|
||||
"issuer": "rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS",
|
||||
"credential_type": "6D795F63726564656E7469616C"
|
||||
},
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
Found credential:
|
||||
{
|
||||
"CredentialType": "6D795F63726564656E7469616C",
|
||||
"Flags": 65536,
|
||||
"Issuer": "rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS",
|
||||
"IssuerNode": "0",
|
||||
"LedgerEntryType": "Credential",
|
||||
"PreviousTxnID": "7D1257779E2D298C07C7E0C73CD446534B143FBD1F13DB268A878E40FD153B9A",
|
||||
"PreviousTxnLgrSeq": 803275,
|
||||
"Subject": "rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA",
|
||||
"SubjectNode": "0",
|
||||
"index": "9603F0E204A8B1C61823625682EB0ECE98A4ECF22FF46CD4845FA9BFA3606B24"
|
||||
}
|
||||
Credential is valid.
|
||||
```sh
|
||||
$ ./verify_credential.js -h
|
||||
|
||||
Usage: verify-credential [options] [issuer] [subject] [credential_type]
|
||||
|
||||
Verify an XRPL credential
|
||||
|
||||
Arguments:
|
||||
issuer Credential issuer address as base58 (default:
|
||||
"rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS")
|
||||
subject Credential subject (holder) address as base58 (default:
|
||||
"rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA")
|
||||
credential_type Credential type as string. (default: "my_credential")
|
||||
|
||||
Options:
|
||||
-b, --binary Use binary (hexadecimal) for credential_type
|
||||
-n, --network <network> {devnet,testnet,mainnet} Use the specified network for lookup (default: "devnet")
|
||||
-q, --quiet Don't print log messages
|
||||
-h, --help display help for command
|
||||
```
|
||||
|
||||
@@ -1,9 +1,18 @@
|
||||
{
|
||||
"name": "verify_credentials",
|
||||
"version": "2.0.0",
|
||||
"description": "Sample code showing how to check if a credential on the XRPL exists and is valid.",
|
||||
"name": "issuer_service",
|
||||
"version": "1.0.0",
|
||||
"description": "",
|
||||
"main": "verify_credential.js",
|
||||
"scripts": {
|
||||
"test": "echo \"Error: no test specified\" && exit 1"
|
||||
},
|
||||
"keywords": [],
|
||||
"author": "",
|
||||
"license": "ISC",
|
||||
"type": "module",
|
||||
"dependencies": {
|
||||
"commander": "^13.1.0",
|
||||
"winston": "^3.17.0",
|
||||
"xrpl": "^4.2.5"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,68 +1,184 @@
|
||||
import { Client, rippleTimeToISOTime, convertStringToHex } from "xrpl"
|
||||
#!/usr/bin/env node
|
||||
|
||||
const client = new Client("wss://s.devnet.rippletest.net:51233")
|
||||
await client.connect()
|
||||
import { Command } from "commander";
|
||||
import { Client, rippleTimeToISOTime, convertStringToHex } from "xrpl";
|
||||
import winston from "winston";
|
||||
|
||||
const subject_address = "rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA"
|
||||
const issuer_address = "rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS"
|
||||
const credential_type = convertStringToHex("my_credential").toUpperCase()
|
||||
// Set up logging --------------------------------------------------------------
|
||||
// Use WARNING by default in case verify_credential is called from elsewhere.
|
||||
const logger = winston.createLogger({
|
||||
level: "warn",
|
||||
transports: [new winston.transports.Console()],
|
||||
format: winston.format.simple(),
|
||||
});
|
||||
|
||||
// Look up Credential ledger entry --------------------------------------------
|
||||
const ledgerEntryRequest = {
|
||||
command: "ledger_entry",
|
||||
credential: {
|
||||
subject: subject_address,
|
||||
issuer: issuer_address,
|
||||
credential_type: credential_type,
|
||||
},
|
||||
ledger_index: "validated",
|
||||
// Define an error to throw when XRPL lookup fails unexpectedly
|
||||
class XRPLLookupError extends Error {
|
||||
constructor(error) {
|
||||
super("XRPL look up error");
|
||||
this.name = "XRPLLookupError";
|
||||
this.body = error;
|
||||
}
|
||||
}
|
||||
console.log("Looking up credential...")
|
||||
console.log(JSON.stringify(ledgerEntryRequest, null, 2))
|
||||
|
||||
let xrplResponse
|
||||
try {
|
||||
xrplResponse = await client.request(ledgerEntryRequest)
|
||||
} catch (err) {
|
||||
if (err.data?.error === "entryNotFound") {
|
||||
console.error("Credential was not found")
|
||||
const CREDENTIAL_REGEX = /^[0-9A-F]{2,128}$/;
|
||||
// See https://xrpl.org/docs/references/protocol/ledger-data/ledger-entry-types/credential#credential-flags
|
||||
// to learn more about the lsfAccepted flag.
|
||||
const LSF_ACCEPTED = 0x00010000;
|
||||
|
||||
async function verifyCredential(client, issuer, subject, credentialType, binary=false) {
|
||||
/**
|
||||
* Check whether an XRPL account holds a specified credential,
|
||||
* as of the most recently validated ledger.
|
||||
* Parameters:
|
||||
* client - Client for interacting with rippled servers.
|
||||
* issuer - Address of the credential issuer, in base58.
|
||||
* subject - Address of the credential holder/subject, in base58.
|
||||
* credentialType - Credential type to check for as a string,
|
||||
* which will be encoded as UTF-8 (1-128 characters long).
|
||||
* binary - Specifies that the credential type is provided in hexadecimal format.
|
||||
* You must provide the credential_type as input.
|
||||
* Returns True if the account holds the specified, valid credential.
|
||||
* Returns False if the credential is missing, expired, or not accepted.
|
||||
*/
|
||||
|
||||
// Encode credentialType as uppercase hex, if needed
|
||||
let credentialTypeHex = "";
|
||||
if (binary) {
|
||||
credentialTypeHex = credentialType.toUpperCase();
|
||||
} else {
|
||||
console.error(err)
|
||||
credentialTypeHex = convertStringToHex(credentialType).toUpperCase();
|
||||
logger.info(`Encoded credential_type as hex: ${credentialTypeHex}`);
|
||||
}
|
||||
process.exit(1)
|
||||
}
|
||||
|
||||
const credential = xrplResponse.result.node
|
||||
console.log("Found credential:")
|
||||
console.log(JSON.stringify(credential, null, 2))
|
||||
if (credentialTypeHex.length % 2 !== 0 || !CREDENTIAL_REGEX.test(credentialTypeHex)) {
|
||||
// Hexadecimal is always 2 chars per byte, so an odd length is invalid.
|
||||
throw new Error("Credential type must be 128 characters as hexadecimal.");
|
||||
}
|
||||
|
||||
// Check if the credential has been accepted ----------------------------------
|
||||
const lsfAccepted = 0x00010000
|
||||
if (!(credential.Flags & lsfAccepted)) {
|
||||
console.log("Credential is not accepted.")
|
||||
process.exit(2)
|
||||
}
|
||||
|
||||
// Confirm that the credential is not expired ---------------------------------
|
||||
if (credential.Expiration) {
|
||||
const expirationTime = rippleTimeToISOTime(credential.Expiration)
|
||||
console.log(`Credential has expiration: ${expirationTime}`)
|
||||
console.log("Looking up validated ledger to check for expiration.")
|
||||
|
||||
const ledgerResponse = await client.request({
|
||||
command: "ledger",
|
||||
// Perform XRPL lookup of Credential ledger entry --------------------------
|
||||
const ledgerEntryRequest = {
|
||||
command: "ledger_entry",
|
||||
credential: {
|
||||
subject: subject,
|
||||
issuer: issuer,
|
||||
credential_type: credentialTypeHex,
|
||||
},
|
||||
ledger_index: "validated",
|
||||
})
|
||||
};
|
||||
logger.info("Looking up credential...");
|
||||
logger.info(JSON.stringify(ledgerEntryRequest, null, 2));
|
||||
|
||||
const closeTime = rippleTimeToISOTime(ledgerResponse.result.ledger.close_time)
|
||||
console.log(`Most recent validated ledger was at: ${closeTime}`)
|
||||
let xrplResponse;
|
||||
try {
|
||||
xrplResponse = await client.request(ledgerEntryRequest);
|
||||
} catch (err) {
|
||||
if (err.data?.error === "entryNotFound") {
|
||||
logger.info("Credential was not found");
|
||||
return false;
|
||||
} else {
|
||||
// Other errors, for example invalidly specified addresses.
|
||||
throw new XRPLLookupError(err?.data || err);
|
||||
}
|
||||
}
|
||||
|
||||
if (new Date(closeTime) > new Date(expirationTime)) {
|
||||
console.log("Credential is expired.")
|
||||
process.exit(3)
|
||||
const credential = xrplResponse.result.node;
|
||||
logger.info("Found credential:");
|
||||
logger.info(JSON.stringify(credential, null, 2));
|
||||
|
||||
// Check if the credential has been accepted ---------------------------
|
||||
if (!(credential.Flags & LSF_ACCEPTED)) {
|
||||
logger.info("Credential is not accepted.");
|
||||
return false
|
||||
}
|
||||
|
||||
// Confirm that the credential is not expired ------------------------------
|
||||
if (credential.Expiration) {
|
||||
const expirationTime = rippleTimeToISOTime(credential.Expiration);
|
||||
logger.info(`Credential has expiration: ${expirationTime}`);
|
||||
logger.info("Looking up validated ledger to check for expiration.");
|
||||
|
||||
let ledgerResponse;
|
||||
try {
|
||||
ledgerResponse = await client.request({
|
||||
command: "ledger",
|
||||
ledger_index: "validated",
|
||||
});
|
||||
} catch (err) {
|
||||
throw new XRPLLookupError(err?.data || err);
|
||||
}
|
||||
|
||||
const closeTime = rippleTimeToISOTime(ledgerResponse.result.ledger.close_time);
|
||||
logger.info(`Most recent validated ledger is: ${closeTime}`);
|
||||
|
||||
if (new Date(closeTime) > new Date(expirationTime)) {
|
||||
logger.info("Credential is expired.");
|
||||
return false;
|
||||
}
|
||||
}
|
||||
|
||||
// Credential has passed all checks ---------------------------------------
|
||||
logger.info("Credential is valid.");
|
||||
return true;
|
||||
}
|
||||
|
||||
|
||||
// Commandline usage -----------------------------------------------------------
|
||||
async function main() {
|
||||
// Websocket URLs of public servers
|
||||
const NETWORKS = {
|
||||
devnet: "wss://s.devnet.rippletest.net:51233",
|
||||
testnet: "wss://s.altnet.rippletest.net:51233",
|
||||
mainnet: "wss://xrplcluster.com/",
|
||||
};
|
||||
|
||||
|
||||
// Parse arguments ---------------------------------------------------------
|
||||
let result = false
|
||||
const program = new Command();
|
||||
program
|
||||
.name("verify-credential")
|
||||
.description("Verify an XRPL credential")
|
||||
.argument("[issuer]", "Credential issuer address as base58", "rEzikzbnH6FQJ2cCr4Bqmf6c3jyWLzkonS")
|
||||
.argument("[subject]", "Credential subject (holder) address as base58", "rsYhHbanGpnYe3M6bsaMeJT5jnLTfDEzoA")
|
||||
.argument("[credential_type]", "Credential type as string.", "my_credential")
|
||||
.option("-b, --binary", "Use binary (hexadecimal) for credential_type")
|
||||
.option(
|
||||
`-n, --network <network> {${Object.keys(NETWORKS)}}`,
|
||||
"Use the specified network for lookup",
|
||||
(value) => {
|
||||
if (!Object.keys(NETWORKS).includes(value)) {
|
||||
throw new Error(`Must be one of: ${Object.keys(NETWORKS)}`);
|
||||
}
|
||||
return value;
|
||||
},
|
||||
"devnet"
|
||||
)
|
||||
.option("-q, --quiet", "Don't print log messages")
|
||||
// Call verify_credential with appropriate args ----------------------------
|
||||
.action(async (issuer, subject, credentialType, options) => {
|
||||
const client = new Client(NETWORKS[options.network]);
|
||||
await client.connect();
|
||||
|
||||
// Use INFO level by default when called from the commandline.
|
||||
if (!options.quiet) { logger.level = "info" }
|
||||
|
||||
// Commander.js automatically sets options.binary to a boolean:
|
||||
// - If you provide -b or --binary on the command line then options.binary = true
|
||||
// - If you do not provide it then options.binary = false
|
||||
result = await verifyCredential(client, issuer, subject, credentialType, options.binary);
|
||||
|
||||
await client.disconnect();
|
||||
});
|
||||
await program.parseAsync(process.argv);
|
||||
|
||||
// Return a nonzero exit code if credential verification failed -----------
|
||||
if (!result) {
|
||||
process.exit(1);
|
||||
}
|
||||
}
|
||||
|
||||
// Credential has passed all checks -------------------------------------------
|
||||
console.log("Credential is valid.")
|
||||
client.disconnect()
|
||||
main().catch((err) => {
|
||||
console.error("Fatal startup error:", err);
|
||||
process.exit(1);
|
||||
});
|
||||
|
||||
@@ -11,13 +11,12 @@ export const frontmatter = {
|
||||
},
|
||||
};
|
||||
|
||||
const target = { prefix: "" }; // TODO: fixme
|
||||
|
||||
const categories = {
|
||||
general: "General",
|
||||
release_notes: "Release Notes",
|
||||
advisories: "Advisories",
|
||||
amendments: "Amendments",
|
||||
case_study: "Case Study",
|
||||
development: "Development",
|
||||
developer_reflections: "Developer Reflections",
|
||||
features: "Features",
|
||||
@@ -89,7 +88,7 @@ export default function Index() {
|
||||
<div className="col">
|
||||
<div className="text-bg">
|
||||
<h4 className="mb-3 eyebrow text-uppercase font-weight-light">
|
||||
<span className="post-date pb-2">
|
||||
<span className="hero-post-date pb-2">
|
||||
{moment(heroPost.date).format(translate("blog.banner.date.part1","MMM"))}
|
||||
</span>
|
||||
{translate("blog.banner.date.part2", " ")}
|
||||
@@ -135,14 +134,14 @@ export default function Index() {
|
||||
className={`blog-filter input_${item}`}
|
||||
type="checkbox"
|
||||
name="categories"
|
||||
id={`input_${item}`}
|
||||
id={`input_desktop_${item}`}
|
||||
defaultValue={`${item}`}
|
||||
onChange={() => toggleCategory(item)}
|
||||
defaultChecked
|
||||
/>
|
||||
<label
|
||||
className="font-weight-bold"
|
||||
htmlFor={`input_${item}`}
|
||||
htmlFor={`input_desktop_${item}`}
|
||||
>
|
||||
{translate(categories[item])}
|
||||
</label>
|
||||
@@ -173,14 +172,14 @@ export default function Index() {
|
||||
className={`blog-filter input_${item}`}
|
||||
type="checkbox"
|
||||
name="categories"
|
||||
id={`input_${item}`}
|
||||
id={`input_mobile_${item}`}
|
||||
defaultValue={`${item}`}
|
||||
onChange={() => toggleCategory(item)}
|
||||
defaultChecked
|
||||
/>
|
||||
<label
|
||||
className="font-weight-bold"
|
||||
htmlFor={`input_${item}`}
|
||||
htmlFor={`input_mobile_${item}`}
|
||||
>
|
||||
{translate(categories[item])}
|
||||
</label>
|
||||
@@ -200,10 +199,9 @@ export default function Index() {
|
||||
className={`${card.category_id} pb-5 px-lg-4`}
|
||||
id={card.title + i}
|
||||
>
|
||||
<div className="mb-4" id="category-list">
|
||||
<div className="mb-4 category-list">
|
||||
<img
|
||||
alt="card block"
|
||||
id={`${card.category_id}`}
|
||||
alt=""
|
||||
className="mb-4"
|
||||
/>
|
||||
<div
|
||||
@@ -213,7 +211,7 @@ export default function Index() {
|
||||
</div>
|
||||
</div>
|
||||
<div>
|
||||
<p id="card-date" className="mb-0">
|
||||
<p className="mb-0 card-date">
|
||||
{moment(card.date).format(translate("blog.card.date","MMM DD, YYYY"))}
|
||||
{ card.author ? ` by ${card.author}` : ""}
|
||||
</p>
|
||||
|
||||
@@ -1,3 +1,7 @@
|
||||
## Blog sidebar file. Reminder: blogs must use one of the hard-coded categories
|
||||
## in their labels frontmatter, or they won't show up in the list below the
|
||||
## latest post, and they won't have an image.
|
||||
|
||||
- group: Blog
|
||||
groupTranslationKey: sidebar.blog
|
||||
page: index.page.tsx
|
||||
|
||||
@@ -21,8 +21,8 @@
|
||||
[AMMWithdraw transaction]: /docs/references/protocol/transactions/types/ammwithdraw.md
|
||||
[AMMWithdraw transactions]: /docs/references/protocol/transactions/types/ammwithdraw.md
|
||||
[AMMWithdraw]: /docs/references/protocol/transactions/types/ammwithdraw.md
|
||||
[API v1]: /docs/references/http-websocket-apis/api-conventions/request-formatting.md#api-versioning
|
||||
[API v2]: /docs/references/http-websocket-apis/api-conventions/request-formatting.md#api-versioning
|
||||
[API v1]: /docs/references/http-websocket-apis/index.md#api-versioning
|
||||
[API v2]: /docs/references/http-websocket-apis/index.md#api-versioning
|
||||
[AccountDelete transaction]: /docs/references/protocol/transactions/types/accountdelete.md
|
||||
[AccountDelete transactions]: /docs/references/protocol/transactions/types/accountdelete.md
|
||||
[AccountDelete]: /docs/references/protocol/transactions/types/accountdelete.md
|
||||
@@ -38,6 +38,7 @@
|
||||
[Batch]: /docs/references/protocol/transactions/types/batch.md
|
||||
[Batch transaction]: /docs/references/protocol/transactions/types/batch.md
|
||||
[Batch transactions]: /docs/references/protocol/transactions/types/batch.md
|
||||
[Bridge entry]: /docs/references/protocol/ledger-data/ledger-entry-types/bridge.md
|
||||
[Check entry]: /docs/references/protocol/ledger-data/ledger-entry-types/check.md
|
||||
[Check object]: /docs/references/protocol/ledger-data/ledger-entry-types/check.md
|
||||
[CheckCancel transaction]: /docs/references/protocol/transactions/types/checkcancel.md
|
||||
@@ -81,14 +82,15 @@
|
||||
[DelegateSet transactions]: /docs/references/protocol/transactions/types/delegateset.md
|
||||
[DepositAuth amendment]: /resources/known-amendments.md#depositauth
|
||||
[DepositPreauth amendment]: /resources/known-amendments.md#depositpreauth
|
||||
[DepositPreauth entry]: /docs/references/protocol/transactions/types/depositpreauth.md
|
||||
[DepositPreauth object]: /docs/references/protocol/transactions/types/depositpreauth.md
|
||||
[DepositPreauth entry]: /docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth.md
|
||||
[DepositPreauth object]: /docs/references/protocol/ledger-data/ledger-entry-types/depositpreauth.md
|
||||
[DepositPreauth transaction]: /docs/references/protocol/transactions/types/depositpreauth.md
|
||||
[DepositPreauth transactions]: /docs/references/protocol/transactions/types/depositpreauth.md
|
||||
[DepositPreauth]: /docs/references/protocol/transactions/types/depositpreauth.md
|
||||
[DIDSet transaction]: /docs/references/protocol/transactions/types/didset.md
|
||||
[DIDSet transactions]: /docs/references/protocol/transactions/types/didset.md
|
||||
[DIDSet]: /docs/references/protocol/transactions/types/didset.md
|
||||
[DIDDelete transaction]: /docs/references/protocol/transactions/types/diddelete.md
|
||||
[DirectoryNode entry]: /docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
|
||||
[DirectoryNode object]: /docs/references/protocol/ledger-data/ledger-entry-types/directorynode.md
|
||||
[DisallowIncoming amendment]: /resources/known-amendments.md#disallowincoming
|
||||
@@ -98,8 +100,8 @@
|
||||
[EnableAmendment]: /docs/references/protocol/transactions/pseudo-transaction-types/enableamendment.md
|
||||
[EnforceInvariants amendment]: /resources/known-amendments.md#enforceinvariants
|
||||
[Escrow amendment]: /resources/known-amendments.md#escrow
|
||||
[Escrow entry]: /docs/concepts/payment-types/escrow.md
|
||||
[Escrow object]: /docs/concepts/payment-types/escrow.md
|
||||
[Escrow entry]: /docs/references/protocol/ledger-data/ledger-entry-types/escrow.md
|
||||
[Escrow object]: /docs/references/protocol/ledger-data/ledger-entry-types/escrow.md
|
||||
[EscrowCancel transaction]: /docs/references/protocol/transactions/types/escrowcancel.md
|
||||
[EscrowCancel transactions]: /docs/references/protocol/transactions/types/escrowcancel.md
|
||||
[EscrowCancel]: /docs/references/protocol/transactions/types/escrowcancel.md
|
||||
@@ -192,6 +194,9 @@
|
||||
[Payment]: /docs/references/protocol/transactions/types/payment.md
|
||||
[PermissionDelegation amendment]: /resources/known-amendments.md#permissiondelegation
|
||||
[PermissionedDEX amendment]: /resources/known-amendments.md#permissioneddex
|
||||
[Permissioned DEXes]: /docs/concepts/tokens/decentralized-exchange/permissioned-dexes.md
|
||||
[PermissionedDomain entry]: /docs/references/protocol/ledger-data/ledger-entry-types/permissioneddomain.md
|
||||
[PermissionedDomainDelete transaction]: /docs/references/protocol/transactions/types/permissioneddomaindelete.md
|
||||
[PermissionedDomainSet transaction]: /docs/references/protocol/transactions/types/permissioneddomainset.md
|
||||
[PermissionedDomainSetトランザクション]: /@l10n/ja/docs/references/protocol/transactions/types/permissioneddomainset.md
|
||||
[PermissionedDomains amendment]: /resources/known-amendments.md#permissioneddomains
|
||||
@@ -256,9 +261,12 @@
|
||||
[XChainCreateBridge transaction]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
|
||||
[XChainCreateBridge transactions]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
|
||||
[XChainCreateBridge]: /docs/references/protocol/transactions/types/xchaincreatebridge.md
|
||||
[XChainModifyBridge transaction]: /docs/references/protocol/transactions/types/xchainmodifybridge.md
|
||||
[XChainModifyBridge transactions]: /docs/references/protocol/transactions/types/xchainmodifybridge.md
|
||||
[XChainCreateClaimID transaction]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
|
||||
[XChainCreateClaimID transactions]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
|
||||
[XChainCreateClaimID]: /docs/references/protocol/transactions/types/xchaincreateclaimid.md
|
||||
[XChainOwnedCreateAccountClaimID entry]: /docs/references/protocol/ledger-data/ledger-entry-types/xchainownedcreateaccountclaimid.md
|
||||
[XChainOwnedClaimID entry]: /docs/references/protocol/ledger-data/ledger-entry-types/xchainownedclaimid
|
||||
[XRP, in drops]: /docs/references/protocol/data-types/basic-data-types.md#specifying-currency-amounts
|
||||
[XRPFees amendment]: /resources/known-amendments.md#xrpfees
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: XRPL accounts can delegate both transaction permissions and granular permissions to other accounts.
|
||||
description: Learn how XRPL Account Permission Delegation enables secure, granular control over your account transactions. Explore DelegateSet transactions for comprehensive permission and access management on the XRP Ledger.
|
||||
labels:
|
||||
- Accounts
|
||||
- Permissions
|
||||
@@ -13,14 +13,14 @@ Permission delegation is the function of granting various permissions to another
|
||||
_(Requires the [PermissionDelegation amendment][] {% not-enabled /%}.)_
|
||||
|
||||
|
||||
## Background
|
||||
## Background: The Need for Permission Delegation
|
||||
|
||||
Managing your [cryptographic keys](./cryptographic-keys.md) is one of the more challenging parts of using a blockchain. As part of a defense-in-depth strategy, a secure configuration should limit the damage that can occur if a secret key is compromised. One way to do this is to rotate keys regularly and to keep master keys off of computers that are always connected to the internet and serving user traffic. However, many use cases involve frequently and automatically signing transactions, which typically requires having secret keys on an internet-connected server.
|
||||
|
||||
Permission Delegation can reduce this problem by granting very limited permissions to separate accounts that have their keys available online for day-to-day tasks. Meanwhile, the keys with full control over the account can be kept offline, so that you only use them for special tasks, like issuing tokens. This is especially helpful when using compliance features like [Authorized Trust Lines](../tokens/fungible-tokens/authorized-trust-lines.md) that require a stablecoin issuer to individually approve each user after meeting regulatory requirements like Know Your Customer rules. With a proper configuration, you can minimize the consequences of a delegate's keys being compromized.
|
||||
|
||||
|
||||
## How It Works
|
||||
## How Permission Delegation Works
|
||||
|
||||
The account on whose behalf transactions are being sent is called the _delegator_. The account sending the transactions is called the _delegate_.
|
||||
|
||||
@@ -39,7 +39,7 @@ The delegate can only send transactions that match the permissions it has. Permi
|
||||
|
||||
For a complete list of transaction types that can or cannot be delegated as well as a list of granular permissions, see [Permission Values](/docs/references/protocol/data-types/permission-values.md).
|
||||
|
||||
### Limitations
|
||||
### Limitations of Permission Delegation
|
||||
|
||||
The main limiting factor on how many delegates you can have is that you must hold enough XRP to meet the [reserve requirement](./reserves.md). Each delegate's permissions are tracked with a [Delegate ledger entry][], which counts as one item towards the delegator's owner reserve.
|
||||
|
||||
|
||||
@@ -12,9 +12,11 @@ Permissioned DEXes are controlled environments for trading within the XRP Ledger
|
||||
There can be multiple permissioned DEXes within the XRP Ledger blockchain. Each one is uniquely associated with a permissioned domain, which acts as an allow-list for accessing that DEX. Trades placed within a permissioned DEX can only execute against other trades in the same permissioned DEX. Each permissioned DEX can have order books for any number of currency pairs, as needed.
|
||||
|
||||
|
||||
## Background
|
||||
## Background: The Need for Permissioned DEXes
|
||||
|
||||
The XRP Ledger has had a single, _open DEX_ since it launched. Anyone with an XRPL account can trade in this DEX, and the system automatically executes matching orders, also called offers, with no regard for who placed them. Orders also provide liquidity to cross-currency payments, which can potentially execute several trades as part of one atomic transaction. Since the system inherently knows nothing about the people and organizations behind the accounts, there is no certainty who the counterparties are for any given trade. However, economic sanctions and financial regulations often place strict rules against transacting with criminals, terrorists, or specific countries. Given these limitations, regulated financial institutions may not be willing to take the risk of trading in the open DEX.
|
||||
The XRP Ledger has had a single, _open DEX_ since it launched. Anyone with an XRPL account can trade in this DEX, and the system automatically executes matching orders, also called offers, with no regard for who placed them. Orders also provide liquidity to cross-currency payments, which can potentially execute several trades as part of one atomic transaction.
|
||||
|
||||
Since the system inherently knows nothing about the people and organizations behind the accounts, there is no certainty who the counterparties are for any given trade. However, economic sanctions and financial regulations often place strict rules against transacting with criminals, terrorists, or specific countries. Given these limitations, regulated financial institutions may not be willing to take the risk of trading in the open DEX.
|
||||
|
||||
More background reading:
|
||||
|
||||
@@ -23,7 +25,7 @@ More background reading:
|
||||
- [Permissioned Domains](./permissioned-domains.md)
|
||||
|
||||
|
||||
## Roles
|
||||
## Key Roles in a Permissioned DEX
|
||||
|
||||
To use a permissioned DEX, parties with the following roles and responsibilities need to exist:
|
||||
|
||||
@@ -38,13 +40,28 @@ It is possible for a single account to play more than one of these roles. For ex
|
||||
_Figure: A permissioned order book, linked to a permissioned domain. Owen is both the domain owner and the issuer of one of the domain's accepted credentials. Tracy is able to trade in the permissioned order book because she holds an appropriate credential issued by Owen._
|
||||
|
||||
|
||||
## Structure
|
||||
## Understanding the Permissioned DEX Structure: Offer Types and Interaction
|
||||
|
||||
With the permissioned DEXes feature, a trade offer can be _open_, _permissioned_, or _hybrid_. An open offer uses the open DEX and can be matched by anyone else's open offer, hybrid offer, an [Automated Market Maker (AMM)](./automated-market-makers.md), or a combination of offers and an AMM. _Open offers_ are unchanged from how the XRPL's DEX works without permissioned DEXes.
|
||||
With the permissioned DEXes feature, a trade offer can be _open_, _permissioned_, or _hybrid_.
|
||||
|
||||
A permissioned offer specifies a domain ID, and is only valid if a permissioned domain with the matching ID exists and the account placing the offer has access to that domain because they hold the correct credentials. Permissioned offers are placed into an order book for the given domain and currency pair, separate from the open DEX's order book for that currency pair. Permissioned offers can only execute by matching other permissioned offers that specify the same domain ID. [Cross-currency payments](../../payment-types/cross-currency-payments.md) can also specify a domain ID, in which case they are restricted to only consuming offers from the corresponding permissioned DEX. Trades in a permissioned DEX can still use [auto-bridging](./autobridging.md) as long as the necessary orders all exist in the same permissioned DEX.
|
||||
### Open Offers
|
||||
|
||||
A hybrid offer specifies a domain ID and a flag marking it as hybrid. Like a permissioned offer, it is only valid if the specified permissioned domain exists and the account placing the offer has access to that domain. However, a hybrid offer can match offers in both the specified DEX and the open DEX. Hybrid offers are tracked in both the open DEX order book and the domain-specific order book for their currency pair, and can be consumed by matching offers from either. When placed, they preferentially match offers from the permissioned DEX.
|
||||
An open offer uses the open DEX and can be matched by anyone else's open offer, hybrid offer, an [Automated Market Maker (AMM)](./automated-market-makers.md), or a combination of offers and an AMM. _Open offers_ are unchanged from how the XRPL's DEX works without permissioned DEXes.
|
||||
|
||||
### Permissioned Offers
|
||||
|
||||
A permissioned offer specifies a domain ID and is only valid if a permissioned domain with the matching ID exists and the account placing the offer has access to that domain because they hold the correct credentials. Permissioned offers are placed into an order book for the given domain and currency pair, separate from the open DEX's order book for that currency pair.
|
||||
|
||||
Permissioned offers can only execute by matching other permissioned offers that specify the same domain ID. [Cross-currency payments](../../payment-types/cross-currency-payments.md) can also specify a domain ID, in which case they are restricted to only consuming offers from the corresponding permissioned DEX. Trades in a permissioned DEX can still use [auto-bridging](./autobridging.md) as long as the necessary orders all exist in the same permissioned DEX.
|
||||
|
||||
### Hybrid Offers
|
||||
|
||||
A hybrid offer specifies a domain ID and a flag marking it as hybrid. Like a permissioned offer, it is only valid if the specified permissioned domain exists and the account placing the offer has access to that domain. However, a hybrid offer can match offers in both the specified DEX and the open DEX.
|
||||
|
||||
Hybrid offers are tracked in both the open DEX order book and the domain-specific order book for their currency pair, and can be consumed by matching offers from either. When placed, they preferentially match offers from the permissioned DEX.
|
||||
|
||||
|
||||
### How Open, Hybrid, and Permissioned Offers Match
|
||||
|
||||
In summary, see the following table summarizing what offers can match:
|
||||
|
||||
@@ -54,7 +71,9 @@ In summary, see the following table summarizing what offers can match:
|
||||
| Hybrid | ✅ | ✅ | ✅ (same domain) | ✅ |
|
||||
| Permissioned | ❌ | ❌ | ✅ (same domain) | ❌ |
|
||||
|
||||
There is no single ledger entry to represent a given permissioned DEX: it implicitly exists as all the order books with the same domain ID. Order books with a given domain ID are implicitly created when valid offers are placed using that domain ID, and those order books are automatically deleted when they are empty. A single transaction can use multiple order books with the same domain ID—in other words, different currency pairs in the same permissioned DEX—either as part of a longer cross-currency payment or through auto-bridging. A hybrid offer can match a mix of permissioned and open offers, but a transaction cannot use multiple different domains.
|
||||
There is no single ledger entry to represent a given permissioned DEX: it implicitly exists as all the order books with the same domain ID. Order books with a given domain ID are created when valid offers are placed using that domain ID, and those order books are automatically deleted when they are empty.
|
||||
|
||||
A single transaction can use multiple order books with the same domain ID—in other words, different currency pairs in the same permissioned DEX—either as part of a longer [cross-currency payment](../../payment-types/cross-currency-payments.md) or through auto-bridging. A hybrid offer can match a mix of permissioned and open offers, but a transaction cannot use multiple different domains.
|
||||
|
||||
The amount of liquidity and the best exchange rate available in any given DEX may vary depending on the offers placed in that DEX. Some traders may choose to trade in multiple permissioned DEXes and the open DEX to arbitrage price differences, while other traders may trade strictly in one domain, depending on their compliance requirements.
|
||||
|
||||
@@ -65,20 +84,30 @@ _Figure: The open DEX, and two different permissioned DEXes, each containing ord
|
||||
|
||||
### Invalid Permissioned Offers
|
||||
|
||||
In addition to the ways offers can be unfunded in the open DEX, offers in a permissioned DEX can become _invalid_. Invalid offers are treated the same way as unfunded offers, and are automatically removed whenever a transaction modifies the order book containing them. They can remain in the ledger data indefinitely until a transaction removes them, but they cannot be executed if they are invalid. Reasons that a permissioned offer can become invalid include:
|
||||
In addition to the ways offers can be unfunded in the open DEX, offers in a permissioned DEX can become _invalid_. Invalid offers are treated the same way as unfunded offers and are automatically removed whenever a transaction modifies the order book containing them. They can remain in the ledger data indefinitely until a transaction removes them, but they cannot be executed if they are invalid.
|
||||
|
||||
Reasons a permissioned offer can become invalid include:
|
||||
|
||||
- A credential, held by the account placing the offer, has expired or has been deleted.
|
||||
- The permissioned domain has been updated to change the set of credentials that grant access, and the account placing the offer does not hold any of the new credentials.
|
||||
- The permissioned domain has been deleted.
|
||||
|
||||
Like with unfunded offers, it is possible for an offer to become temporarily invalid, then become valid again. For example, if a trader's credential that grants access to a permissioned domain expires, their offers in the corresponding permissioned DEX would be invalid; but if they get the credential renewed, any offers that hadn't already been removed automatically become valid again.
|
||||
Like with unfunded offers, it is possible for an offer to become temporarily invalid and then become valid again. For example, if a trader's credential that grants access to a permissioned domain expires, their offers in the corresponding permissioned DEX would be invalid; but if they get the credential renewed, any offers that hadn't already been removed automatically become valid again.
|
||||
|
||||
### Limitations
|
||||
### Limitations of Permissioned DEXes
|
||||
|
||||
The permissioned DEXes feature is enabled by the **PermissionedDEX** amendment, and relies on the [Credentials](../../decentralized-storage/credentials.md) and [Permissioned Domains](./permissioned-domains.md) amendments, so it cannot be used until _all_ of those amendments have been enabled.
|
||||
|
||||
Permissioned DEXes are incompatible with Automated Market Makers (AMMs). Permissioned offers and permissioned payments cannot be filled by AMMs, and access to AMMs cannot be restricted by a permissioned domain. Trades that use the open DEX can sometimes consume a hybrid offer and use an AMM in the same transaction, but transactions that specify a domain cannot use any AMMs.
|
||||
#### Not Compatible with AMMs
|
||||
|
||||
Permissioned DEXes are incompatible with [Automated Market Makers (AMMs)](../../tokens/decentralized-exchange/automated-market-makers.md). Permissioned offers and permissioned payments cannot be filled by AMMs, and access to AMMs cannot be restricted by a permissioned domain. Trades that use the open DEX can sometimes consume a hybrid offer and use an AMM in the same transaction, but transactions that specify a domain cannot use any AMMs.
|
||||
|
||||
**Permissioned DEXes are independent**
|
||||
|
||||
Each permissioned DEX is separate, with its own order books and offers. A single transaction cannot trade in multiple permissioned DEXes or aggregate liquidity from multiple permissioned DEXes. Hybrid offers can use a mix of one permissioned DEX and the open DEX, but they cannot use multiple different permissioned DEXes.
|
||||
|
||||
The security and fairness of a permissioned DEX depend on the owner of the permissioned domain and the issuers of credentials that grant access to it. At a baseline, the definition of each credential and the requirements for getting that credential are defined and enforced by the credential issuer, so the existence of a permissioned domain does not inherently mean anything about who is able to use it in practice. A credential issuer can issue or revoke credentials at their discretion. If they are unreliable or compromised, so is any permissioned domain that accepts their credentials. Similarly, the domain owner can modify the domain's list of accepted credentials to grant or deny access to the domain arbitrarily, so if they are untrustworthy or compromised, the domain is as well.
|
||||
#### Security Considerations for Permissioned DEXes
|
||||
|
||||
The security and fairness of a permissioned DEX depend on the owner of the permissioned domain and the issuers of credentials that grant access to it. At a baseline, the definition of each credential and the requirements for getting that credential are defined and enforced by the credential issuer, so the existence of a permissioned domain does not inherently mean anything about who is able to use it in practice.
|
||||
|
||||
A credential issuer can issue or revoke credentials at their discretion. If they are unreliable or compromised, so is any permissioned domain that accepts their credentials. Similarly, the domain owner can modify the domain's list of accepted credentials to grant or deny access to the domain arbitrarily, so if they are untrustworthy or compromised, the domain is as well.
|
||||
|
||||
@@ -1,13 +1,13 @@
|
||||
---
|
||||
seo:
|
||||
description: The definition and details of a Permissioned Domain instance.
|
||||
description: Learn how Permissioned Domains on the XRP Ledger enable controlled, secure blockchain environments. Explore their role in decentralized exchanges (DEXes) and lending protocols.
|
||||
labels:
|
||||
- Compliance
|
||||
- Permissioned Domains
|
||||
---
|
||||
# Permissioned Domains
|
||||
|
||||
Permissioned domains are controlled environments within the broader ecosystem of the XRP Ledger blockchain. Domains do nothing on their own, but features such as Permissioned DEXes and Lending Protocols can use domains to restrict access, so that traditional financial institutions can offer services on chain while complying with various compliance rules.
|
||||
Permissioned domains are controlled environments within the broader ecosystem of the XRP Ledger blockchain. Domains do nothing on their own, but features such as [Permissioned DEXes][] and Lending Protocols can use domains to restrict and manage access, so traditional financial institutions can offer services on chain while complying with various compliance rules.
|
||||
|
||||
The only configurable rule for a domain is the set of accepted [credentials][]. Future amendments may add new and different types of rules to encompass any limits that a financial institution may need to follow to maintain compliance with the laws of the jurisdictions where they do business.
|
||||
|
||||
@@ -29,7 +29,7 @@ A domain serves as an abstraction layer between credentials and a resource being
|
||||
|
||||
Users do not need to apply to join or leave a domain. When a transaction requires access to a resource that is restricted by a domain, the transaction automatically checks if the account holds a credential matching that domain's accepted credentials, and fails if they have none. The user's credential must be accepted and not expired.
|
||||
|
||||
## Uses for Domains
|
||||
## Uses for Permissioned Domains
|
||||
|
||||
Currently, there are no available XRP Ledger features that use permissioned domains. However, amendments that are in development and use domains include:
|
||||
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: Deep Freeze ensures that frozen token holders can neither send nor receive frozen funds until their trust line is unfrozen.
|
||||
seo:
|
||||
description: Deep Freeze ensures that frozen token holders can neither send nor receive frozen funds until their trust line is unfrozen.
|
||||
labels:
|
||||
- Tokens
|
||||
- Freeze
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
---
|
||||
blurb: Multi-purpose tokens offer a more compact, flexible token type than trust lines.
|
||||
seo:
|
||||
description: Learn about multi-purpose tokens (MPTs) on XRP Ledger. MPTs are a flexible way to issue fungible tokens with built-in metadata, compliance, and transfer controls.
|
||||
labels:
|
||||
- Tokens
|
||||
- MPTs
|
||||
@@ -10,48 +11,78 @@ status: not_enabled
|
||||
|
||||
_(Requires the [MPTokensV1 amendment][] {% not-enabled /%})_
|
||||
|
||||
Multi-purpose tokens (MPTs) are a more compact and flexible type of fungible token.
|
||||
Multi-purpose tokens (MPTs) are a more compact and flexible type of [fungible token](./index.md) on the XRP Ledger.
|
||||
|
||||
MPTs let you take advantage of ready-to-use tokenization features with a few lines of code. You can create many token experiences from one token program itself. Notable features include:
|
||||
MPTs let you take advantage of ready-to-use tokenization features with a few lines of code. You can create many token experiences from one token program itself.
|
||||
|
||||
## Key Features of MPTs on XRPL
|
||||
|
||||
The following are notable features of MPTs on XRPL.
|
||||
|
||||
**On-Chain Metadata Storage**
|
||||
|
||||
- MPTs store their metadata directly on the XRPL blockchain. Once set, the metadata is immutable.
|
||||
- A 1024-byte URI field provides a metadata pointer that allows you to use an off-chain source for metadata in addition to the on-chain source. This lets your application access necessary information directly from the chain, prompting higher interoperability for tokens, without losing the ability to attach additional information.
|
||||
|
||||
**Transferability and Supply Controls**
|
||||
|
||||
- MPTs can have a fixed token supply where you set a cap on the maximum number of tokens that can be minted.
|
||||
- You can define MPTs as non-transferable, tokens that can only be transferred back to the issuer, but not among tokenholders. Useful for cases such as issuing airline credits or loyalty rewards.
|
||||
- Issuers can set transfer fees to collect on-chain revenue each time the token is traded among tokenholders.
|
||||
- MPTs also have advanced compliance features:
|
||||
- The ability to lock tokens held by a tokenholder to support compliance requirements.
|
||||
- The ability to set a global lock for all MPT balances across all tokenholders.
|
||||
- The issuer can configure MPTs that can be clawed back from tokenholder wallets, either to revoke them, or to reassign them in the case of lost wallet keys.
|
||||
- An opt-in feature can allow only wallets authorized by the issuer to hold issued tokens.
|
||||
|
||||
**Built-In Compliance Features**
|
||||
|
||||
MPTs also have advanced compliance features, including:
|
||||
- The ability to lock tokens held by a tokenholder to support compliance requirements.
|
||||
- The ability to set a global lock for all MPT balances across all tokenholders.
|
||||
- The issuer can configure MPTs that can be clawed back from tokenholder wallets, either to revoke them, or to reassign them in the case of lost wallet keys.
|
||||
- An opt-in feature can allow only wallets authorized by the issuer to hold issued tokens.
|
||||
|
||||
## MPTs versus Trust Lines
|
||||
|
||||
Unlike trust lines, MPTs do not represent bidirectional debt relationships. Instead, MPTs function more like a unidirectional trust line with only one balance. This reduces the overhead to support common tokenization requirements, including non-monetary use cases such as tracking reputation points in an online game.
|
||||
These are the primary differences between MPTs and [trust lines](/docs/concepts/tokens/fungible-tokens#trust-lines).
|
||||
|
||||
MPTs offer a less complicated conceptual model than trust lines.
|
||||
**Conceptual Differences**
|
||||
|
||||
MPTs require significantly less space than trust lines. They require roughly 52 bytes for each MPT held by a token holder, compared to at least 234 bytes for every new trust line.
|
||||
- Unlike trust lines, MPTs do not represent bidirectional debt relationships. Instead, MPTs function more like a unidirectional trust line with only one balance. This reduces the overhead to support common tokenization requirements, including non-monetary use cases such as tracking reputation points in an online game.
|
||||
|
||||
They reduce the long-term infrastructure and storage burdens for node operators, increasing network resiliency.
|
||||
- MPTs offer a less complicated conceptual model than trust lines.
|
||||
|
||||
MPTs also improve node perfomance when processing large volumes of transactions.
|
||||
**Ledger Storage and Performance**
|
||||
|
||||
MPTs are unidirectional. While trust lines use "balance netting," MPTs have only a single balance.
|
||||
- MPTs require significantly less space than trust lines. They require roughly 52 bytes for each MPT held by a token holder, compared to at least 234 bytes for every new trust line.
|
||||
|
||||
An account can issue a maximum of 32 unique MPT issuances. If an issuer wants to support more than this number of MPTs, they can open additional accounts.
|
||||
- They reduce the long-term infrastructure and storage burdens for node operators, increasing network resiliency.
|
||||
|
||||
Since token holders will not acquire an MPT without first making an off-ledger trust decision, MPTs have no trust limits. For example, a common use case for an MPT is a fiat-backed stablecoin, where a token holder wouldn't purchase more stablecoins than they would feel comfortable holding.
|
||||
- MPTs also improve node perfomance when processing large volumes of transactions.
|
||||
|
||||
Unlike some existing capabilities of the ledger, MPTs are not subject to rippling, and do not require configurability settings related to that functionality.
|
||||
**Transfer Logic and Directionality**
|
||||
|
||||
- MPTs are unidirectional. While trust lines use "balance netting," MPTs have only a single balance.
|
||||
- An account can issue a maximum of 32 unique MPT issuances. If an issuer wants to support more than this number of MPTs, they can open additional accounts.
|
||||
- Since token holders will not acquire an MPT without first making an off-ledger trust decision, MPTs have no trust limits. For example, a common use case for an MPT is a [fiat-backed stablecoin](/docs/concepts/tokens/fungible-tokens/stablecoins#fiat-backed), where a token holder wouldn't purchase more stablecoins than they would feel comfortable holding.
|
||||
- Unlike some existing capabilities of the ledger, MPTs are not subject to [rippling](/docs/concepts/tokens/fungible-tokens/rippling) and do not require configurability settings related to that functionality.
|
||||
|
||||
## MPTs versus IOUs
|
||||
|
||||
On a technical level, MPTs provide a fundamentally different way to represent fungible tokens on the ledger. While IOUs are represented by trustlines and have bilateral debt relationships, MPTs use a simpler, unilateral relationship captured by an MPToken object. This results in substantial space savings on the ledger. The representation of a fungible token as a token object instead of a trustline makes it easier to enable functionality for real-world financial assets on-chain, such as token-level metadata, fixed supply, and fixed-point balance.
|
||||
MPTs are different from IOUs in the following ways.
|
||||
|
||||
On a usage level, MPTs provide a straightforward conceptual model compared to trustlines and rippling. Developers can more easily build web3 applications around `MPToken` and `MPTokenIssuance` objects, with some similarities to the conceptual model of XLS-20 NFTs. It is also simpler for ordinary users to understand what tokens are available, what tokens they have issued, and what they hold in their wallet. For both issuers and holders of MPTs, there will typically be a smaller XRP reserve compared to the equivalent representations with IOU trustlines.
|
||||
**Technical Representation on the Ledger**
|
||||
|
||||
MPTs are intended to be complementary to IOUs. While there might be use cases where either MPTs or IOUs might be suitable, there will likely be a need for both over the long term. There will be use cases such as credit lines for lending and borrowing that might be better represented by IOUs long term. The MPT feature set should evolve in an incremental manner to unlock more common use cases first and deliver additional feature support at a later time. During the MPT development period, some cases might still be better represented by an IOU, then later be better supported with MPTs.
|
||||
On a technical level, MPTs provide a fundamentally different way to represent fungible tokens on the ledger. While IOUs are represented by trustlines and have bilateral debt relationships, MPTs use a simpler, unilateral relationship captured by an MPToken object. This results in substantial space savings on the ledger.
|
||||
|
||||
The representation of a fungible token as a token object instead of a trustline makes it easier to enable functionality for real-world financial assets on-chain, such as token-level metadata, fixed supply, and fixed-point balance.
|
||||
|
||||
**Developer Experience and App Design**
|
||||
On a usage level, MPTs provide a straightforward conceptual model compared to [trustlines](/docs/concepts/tokens/fungible-tokens#trust-lines) and [rippling](/docs/concepts/tokens/fungible-tokens/rippling). Developers can more easily build web3 applications around `[MPToken](/docs/references/protocol/ledger-data/ledger-entry-types/mptoken)` and `[MPTokenIssuance](/docs/references/protocol/ledger-data/ledger-entry-types/mptokenissuance)` objects, with some similarities to the conceptual model of XLS-20 NFTs.
|
||||
|
||||
It is also simpler for ordinary users to understand what tokens are available, what tokens they have issued, and what they hold in their wallet.
|
||||
|
||||
For both issuers and holders of MPTs, there will typically be a smaller XRP reserve compared to the equivalent representations with IOU trustlines.
|
||||
|
||||
## Use Case and Long-Term Considerations
|
||||
|
||||
MPTs are intended to be complementary to IOUs. While there might be use cases where either MPTs or IOUs might be suitable, there will likely be a need for both over the long term. There will be use cases such as credit lines for lending and borrowing that might be better represented by IOUs long term. The MPT feature set should evolve in an incremental manner to unlock more common use cases first and deliver additional feature support at a later time. During the MPT development period, some cases might still be better represented by an IOU, and then later be better supported with MPTs.
|
||||
|
||||
## See Also
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Batch allows up to 8 transactions to be submitted as a single unit.
|
||||
description: Discover how XRPL Batch Transactions streamline multiple blockchain operations into a single secure transaction. Learn about batch modes, execution details, and security considerations.
|
||||
labels:
|
||||
- Batch
|
||||
- Transactions
|
||||
@@ -8,7 +8,9 @@ status: not_enabled
|
||||
---
|
||||
# Batch Transactions
|
||||
|
||||
`Batch` lets you package multiple transactions together and execute them as a single unit. It eliminates the risk of partial completion and unexpected outcomes, giving you a more reliable and predictable experience for complex operations. Up to eight transactions can be submitted in a single batch.
|
||||
XRPL Batch Transactions let you package multiple [transactions](/docs/concepts/transactions) together and execute them as a single unit. It eliminates the risk of partial completion and unexpected outcomes, giving you a more reliable and predictable experience for complex operations. Up to eight transactions can be submitted in a single batch.
|
||||
|
||||
## XRPL Batch Use Cases
|
||||
|
||||
Some potential uses for `Batch` include the following.
|
||||
- All or nothing: You can mint an NFT and create an offer for it in one transaction. If the offer creation fails, the NFT mint is reverted as well.
|
||||
@@ -19,7 +21,11 @@ Some potential uses for `Batch` include the following.
|
||||
|
||||
`Batch` transactions are comprised of the _outer transaction_, the wrapper `Batch` transaction itself, and the _inner transactions_, each of which is executed atomically. The precise way that the inner transactions are processed is determined by the batch _mode_.
|
||||
|
||||
## Batch Mode
|
||||
<div align="center">
|
||||
<iframe width="560" height="315" src="https://www.youtube.com/embed/LsMMXm7jm1k" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
|
||||
</div>
|
||||
|
||||
## XRPL Batch Transaction Modes
|
||||
|
||||
There are four possible batch modes: `ALLORNOTHING`, `ONLYONE`, `UNTILFAILURE`, and `INDEPENDENT`.
|
||||
|
||||
@@ -39,9 +45,9 @@ In `ALLORNOTHING` mode, all inner transactions must succeed for any one of them
|
||||
|
||||
All transactions are applied, even if one or more of the inner transactions fail.
|
||||
|
||||
## Raw Transactions
|
||||
## XRPL Raw Transactions Object
|
||||
|
||||
The `RawTransactions` object is a container for the list of transactions to be applied. You can include up to eight transactions in a sincle batch. The transactions can come from one account or multiple accounts.
|
||||
The `RawTransactions` object is a container for the list of transactions to be applied. You can include up to eight transactions in a single batch. The transactions can come from one account or multiple accounts.
|
||||
|
||||
Each inner transaction:
|
||||
|
||||
@@ -67,6 +73,8 @@ This field is included if the account is signing with multi-sign (as opposed to
|
||||
|
||||
This field must be provided if more than one account has inner transactions included in the Batch. In that case, this field must contain signatures from all accounts whose inner transactions are included, excluding the account signing the outer transaction (if applicable).
|
||||
|
||||
#### Fields Used for XRPL Batch Transactions
|
||||
|
||||
Each object in this array contains the following fields:
|
||||
|
||||
| Field Name | Required? | JSON Type | Internal Type |
|
||||
@@ -90,7 +98,7 @@ These fields are included if the account is signing with a single signature (as
|
||||
|
||||
This field is included if the account is signing with multi-sign (as opposed to a single signature). It operates equivalently to the `Signers` field used in standard transaction multi-sign. This field holds the signatures for the `Flags` field and the hashes of the transactions in `RawTransactions`.
|
||||
|
||||
## Transaction Fee
|
||||
## XRPL Batch Transaction Fees
|
||||
|
||||
The fee for the outer transaction is twice the base fee (a total of 20 drops when there is no fee escalation), plus the sum of the transaction fees of all the inner transactions (which incorporates factors like higher fees for `multisign` or `AMMCreate`), plus an additional base fee amount for each additional signature in the transaction (for example, from `BatchSigners`). Expressed as an equation:
|
||||
|
||||
@@ -124,7 +132,7 @@ There is also a pointer back to the parent outer transaction (`ParentBatchID`).
|
||||
|
||||
## Transaction Common Fields
|
||||
|
||||
This standard doesn't add any new fields to the transaction common fields, but it does add another global transaction flag:
|
||||
This standard doesn't add any new fields to the [transaction common fields](/docs/references/protocol/transactions/common-fields.md), but it does add another global transaction flag:
|
||||
|
||||
| Flag Name | Value |
|
||||
|-----------------|------------|
|
||||
@@ -132,7 +140,7 @@ This standard doesn't add any new fields to the transaction common fields, but i
|
||||
|
||||
This flag should be used only if a transaction is an inner transaction in a `Batch` transaction. This signifies that the transaction shouldn't be signed. Any normal transaction that includes this flag should be rejected.
|
||||
|
||||
## Security
|
||||
## Security for XRPL Batch Transactions
|
||||
|
||||
Batch transactions come with additional security considerations.
|
||||
|
||||
|
||||
168
docs/img/_sources/api-functionality-venn-diagram.uxf
Normal file
168
docs/img/_sources/api-functionality-venn-diagram.uxf
Normal file
@@ -0,0 +1,168 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<diagram program="umlet" version="14.2">
|
||||
<zoom_level>10</zoom_level>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>230</x>
|
||||
<y>90</y>
|
||||
<w>400</w>
|
||||
<h>360</h>
|
||||
</coordinates>
|
||||
<panel_attributes/>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>UMLUseCase</id>
|
||||
<coordinates>
|
||||
<x>30</x>
|
||||
<y>90</y>
|
||||
<w>400</w>
|
||||
<h>360</h>
|
||||
</coordinates>
|
||||
<panel_attributes/>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>140</x>
|
||||
<y>50</y>
|
||||
<w>110</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>*rippled Server*</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>400</x>
|
||||
<y>50</y>
|
||||
<w>110</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>*Clio Server*</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>310</x>
|
||||
<y>70</y>
|
||||
<w>50</w>
|
||||
<h>30</h>
|
||||
</coordinates>
|
||||
<panel_attributes>*Both*</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>290</x>
|
||||
<y>250</y>
|
||||
<w>100</w>
|
||||
<h>50</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Serve most API methods</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>430</x>
|
||||
<y>150</y>
|
||||
<w>140</w>
|
||||
<h>50</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Scales efficiently to many requests</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>30</x>
|
||||
<y>0</y>
|
||||
<w>490</w>
|
||||
<h>40</h>
|
||||
</coordinates>
|
||||
<panel_attributes>fontsize=20
|
||||
*API functionality provided by servers*</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>90</x>
|
||||
<y>160</y>
|
||||
<w>150</w>
|
||||
<h>50</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Provides Admin API methods</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>70</x>
|
||||
<y>220</y>
|
||||
<w>150</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Provides pending / unvalidated data including transaction queue
|
||||
</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>80</x>
|
||||
<y>300</y>
|
||||
<w>160</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Has a live view of consensus and peer-to-peer network</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>440</x>
|
||||
<y>200</y>
|
||||
<w>180</w>
|
||||
<h>70</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Provides NFT methods: nft_history, nft_info, nfts_by_issuer</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>450</x>
|
||||
<y>270</y>
|
||||
<w>180</w>
|
||||
<h>50</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Provides mpt_holders method</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
<element>
|
||||
<id>Text</id>
|
||||
<coordinates>
|
||||
<x>430</x>
|
||||
<y>320</y>
|
||||
<w>140</w>
|
||||
<h>80</h>
|
||||
</coordinates>
|
||||
<panel_attributes>style=wordwrap
|
||||
• Serves rippled-exclusive API requests by forwarding</panel_attributes>
|
||||
<additional_attributes/>
|
||||
</element>
|
||||
</diagram>
|
||||
138
docs/img/api-functionality-venn-diagram.svg
Normal file
138
docs/img/api-functionality-venn-diagram.svg
Normal file
@@ -0,0 +1,138 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.0//EN'
|
||||
'http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd'>
|
||||
<svg fill-opacity="1" xmlns:xlink="http://www.w3.org/1999/xlink" color-rendering="auto" color-interpolation="auto" text-rendering="auto" stroke="black" stroke-linecap="square" width="640" stroke-miterlimit="10" shape-rendering="auto" stroke-opacity="1" fill="black" stroke-dasharray="none" font-weight="normal" stroke-width="1" viewBox="10 -20 640 490" height="490" xmlns="http://www.w3.org/2000/svg" font-family="'Dialog'" font-style="normal" stroke-linejoin="miter" font-size="12px" stroke-dashoffset="0" image-rendering="auto"
|
||||
><!--Generated by the Batik Graphics2D SVG Generator--><defs id="genericDefs"
|
||||
/><g
|
||||
><defs id="defs1"
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath1"
|
||||
><path d="M0 0 L2147483647 0 L2147483647 2147483647 L0 2147483647 L0 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath2"
|
||||
><path d="M0 0 L0 80 L140 80 L140 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath3"
|
||||
><path d="M0 0 L0 50 L180 50 L180 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath4"
|
||||
><path d="M0 0 L0 70 L180 70 L180 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath5"
|
||||
><path d="M0 0 L0 70 L160 70 L160 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath6"
|
||||
><path d="M0 0 L0 80 L150 80 L150 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath7"
|
||||
><path d="M0 0 L0 50 L150 50 L150 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath8"
|
||||
><path d="M0 0 L0 40 L490 40 L490 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath9"
|
||||
><path d="M0 0 L0 50 L140 50 L140 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath10"
|
||||
><path d="M0 0 L0 50 L100 50 L100 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath11"
|
||||
><path d="M0 0 L0 30 L50 30 L50 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath12"
|
||||
><path d="M0 0 L0 30 L110 30 L110 0 Z"
|
||||
/></clipPath
|
||||
><clipPath clipPathUnits="userSpaceOnUse" id="clipPath13"
|
||||
><path d="M0 0 L0 360 L400 360 L400 0 Z"
|
||||
/></clipPath
|
||||
></defs
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(430,320)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath2)" stroke="none"
|
||||
>• Serves</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath2)" stroke="none"
|
||||
>rippled-exclusive</text
|
||||
><text x="5" xml:space="preserve" y="51.0781" clip-path="url(#clipPath2)" stroke="none"
|
||||
>API requests by</text
|
||||
><text x="5" xml:space="preserve" y="67.4375" clip-path="url(#clipPath2)" stroke="none"
|
||||
>forwarding</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(450,270)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath3)" stroke="none"
|
||||
>• Provides mpt_holders</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath3)" stroke="none"
|
||||
>method</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(440,200)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath4)" stroke="none"
|
||||
>• Provides NFT methods:</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath4)" stroke="none"
|
||||
>nft_history, nft_info,</text
|
||||
><text x="5" xml:space="preserve" y="51.0781" clip-path="url(#clipPath4)" stroke="none"
|
||||
>nfts_by_issuer</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(80,300)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath5)" stroke="none"
|
||||
>• Has a live view of</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath5)" stroke="none"
|
||||
>consensus and</text
|
||||
><text x="5" xml:space="preserve" y="51.0781" clip-path="url(#clipPath5)" stroke="none"
|
||||
>peer-to-peer network</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(70,220)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath6)" stroke="none"
|
||||
>• Provides pending /</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath6)" stroke="none"
|
||||
>unvalidated data</text
|
||||
><text x="5" xml:space="preserve" y="51.0781" clip-path="url(#clipPath6)" stroke="none"
|
||||
>including</text
|
||||
><text x="5" xml:space="preserve" y="67.4375" clip-path="url(#clipPath6)" stroke="none"
|
||||
>transaction queue</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(90,160)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath7)" stroke="none"
|
||||
>• Provides Admin</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath7)" stroke="none"
|
||||
>API methods</text
|
||||
></g
|
||||
><g font-size="20px" font-weight="bold" font-family="sans-serif" transform="translate(30,0)"
|
||||
><text x="5" xml:space="preserve" y="24.0781" clip-path="url(#clipPath8)" stroke="none"
|
||||
>API functionality provided by servers</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(430,150)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath9)" stroke="none"
|
||||
>• Scales efficiently</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath9)" stroke="none"
|
||||
>to many requests</text
|
||||
></g
|
||||
><g font-family="sans-serif" font-size="14px" transform="translate(290,250)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath10)" stroke="none"
|
||||
>• Serve most</text
|
||||
><text x="5" xml:space="preserve" y="34.7188" clip-path="url(#clipPath10)" stroke="none"
|
||||
>API methods</text
|
||||
></g
|
||||
><g font-size="14px" font-weight="bold" font-family="sans-serif" transform="translate(310,70)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath11)" stroke="none"
|
||||
>Both</text
|
||||
></g
|
||||
><g font-size="14px" font-weight="bold" font-family="sans-serif" transform="translate(400,50)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath12)" stroke="none"
|
||||
>Clio Server</text
|
||||
></g
|
||||
><g font-size="14px" font-weight="bold" font-family="sans-serif" transform="translate(140,50)"
|
||||
><text x="5" xml:space="preserve" y="18.3594" clip-path="url(#clipPath12)" stroke="none"
|
||||
>rippled Server</text
|
||||
></g
|
||||
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(30,90)" stroke-opacity="0" stroke="rgb(255,255,255)"
|
||||
><ellipse rx="199.25" ry="179.25" clip-path="url(#clipPath13)" cx="199.75" cy="179.75" stroke="none"
|
||||
/></g
|
||||
><g transform="translate(30,90)"
|
||||
><ellipse rx="199.25" fill="none" ry="179.25" clip-path="url(#clipPath13)" cx="199.75" cy="179.75"
|
||||
/></g
|
||||
><g fill="rgb(255,255,255)" fill-opacity="0" transform="translate(230,90)" stroke-opacity="0" stroke="rgb(255,255,255)"
|
||||
><ellipse rx="199.25" ry="179.25" clip-path="url(#clipPath13)" cx="199.75" cy="179.75" stroke="none"
|
||||
/></g
|
||||
><g transform="translate(230,90)"
|
||||
><ellipse rx="199.25" fill="none" ry="179.25" clip-path="url(#clipPath13)" cx="199.75" cy="179.75"
|
||||
/></g
|
||||
></g
|
||||
></svg
|
||||
>
|
||||
|
After Width: | Height: | Size: 7.5 KiB |
@@ -0,0 +1,39 @@
|
||||
# Short Names of Ledger Entries
|
||||
|
||||
Some API methods, specifically the [account_objects method][] and [ledger_data method][], allow filtering the ledger entries they return based on the type of ledger entry. The type field you specify can use either the canonical name of the [ledger entry](../../protocol/ledger-data/ledger-entry-types/index.md) or a short name, as in the following table.
|
||||
|
||||
The "Ownable" column indicates whether the ledger entry type can appear in owner directories. Ledger entries that are not ownable cannot appear in `account_objects` responses and cannot be used as a `type` filter in that method.
|
||||
|
||||
| Canonical Name | Short Name | Ownable | Related Amendment |
|
||||
| -------------------- | --------------------- | ------- |---|
|
||||
| `AccountRoot` | `account` | No | |
|
||||
| `Amendments` | `amendments` | No | |
|
||||
| `AMM` | `amm` | No | {% amendment-disclaimer name="AMM" compact=true /%} |
|
||||
| `Bridge` | `bridge` | Yes | {% amendment-disclaimer name="XChainBridge" compact=true /%} |
|
||||
| `Check` | `check` | Yes | {% amendment-disclaimer name="Checks" compact=true /%} |
|
||||
| `Credential` | `credential` | Yes | {% amendment-disclaimer name="Credentials" compact=true /%} |
|
||||
| `Delegate` | `delegate` | Yes | {% amendment-disclaimer name="PermissionDelegation" compact=true /%} |
|
||||
| `DepositPreauth` | `deposit_preauth` | Yes | {% amendment-disclaimer name="DepositPreauth" compact=true /%} |
|
||||
| `DID` | `did` | Yes | {% amendment-disclaimer name="DID" compact=true /%} |
|
||||
| `DirectoryNode` | `directory` | No | |
|
||||
| `Escrow` | `escrow` | Yes | |
|
||||
| `FeeSettings` | `fee` | No | |
|
||||
| `LedgerHashes` | `hashes` | No | |
|
||||
| `MPToken` | `mptoken` | Yes | {% amendment-disclaimer name="MPTokensV1" compact=true /%} |
|
||||
| `MPTokenIssuance` | `mpt_issuance` | Yes | {% amendment-disclaimer name="MPTokensV1" compact=true /%} |
|
||||
| `NegativeUNL` | `nunl` | No | {% amendment-disclaimer name="NegativeUNL" compact=true /%} |
|
||||
| `NFTokenOffer` | `nft_offer` | Yes | {% amendment-disclaimer name="NonFungibleTokensV1_1" compact=true /%} |
|
||||
| `NFTokenPage` | `nft_page` | Yes | {% amendment-disclaimer name="NonFungibleTokensV1_1" compact=true /%} |
|
||||
| `Offer` | `offer` | Yes | |
|
||||
| `Oracle` | `oracle` | Yes | {% amendment-disclaimer name="PriceOracle" compact=true /%} |
|
||||
| `PayChannel` | `payment_channel` | Yes | |
|
||||
| `PermissionedDomain` | `permissioned_domain` | Yes | {% amendment-disclaimer name="PermissionedDomains" compact=true /%} |
|
||||
| `RippleState` | `state` | Yes | |
|
||||
| `SignerList` | `signer_list` | Yes | |
|
||||
| `Ticket` | `ticket` | Yes | {% amendment-disclaimer name="TicketBatch" compact=true /%} |
|
||||
| `XChainOwnedClaimID` | `xchain_owned_claim_id` | Yes | {% amendment-disclaimer name="XChainBridge" compact=true /%} |
|
||||
| `XChainOwnedCreate`<wbr>`AccountClaimID` | `xchain_owned_`<wbr>`create_account_claim_id` | Yes | {% amendment-disclaimer name="XChainBridge" compact=true /%} |
|
||||
|
||||
<!-- Author's note: used <wbr> (word break opportunity) so that the long xchain names don't cause the table to scroll horizontally. -->
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: request-formatting.html
|
||||
parent: api-conventions.html
|
||||
seo:
|
||||
description: Standard request format, with examples, for the WebSocket, JSON-RPC, and Commandline interfaces.
|
||||
---
|
||||
@@ -13,12 +11,11 @@ seo:
|
||||
{% tab label="WebSocket" %}
|
||||
```json
|
||||
{
|
||||
"id": 2,
|
||||
"id": "example_ws_request_1",
|
||||
"command": "account_info",
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated",
|
||||
"api_version": 1
|
||||
"api_version": 2
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
@@ -33,9 +30,8 @@ Content-Type: application/json
|
||||
"params": [
|
||||
{
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated",
|
||||
"api_version": 1
|
||||
"api_version": 2
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -44,7 +40,7 @@ Content-Type: application/json
|
||||
|
||||
{% tab label="Commandline" %}
|
||||
```sh
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated strict
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
@@ -59,7 +55,7 @@ After you open a WebSocket to the `rippled` server, you can send commands as a [
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `command` | String | The name of the [API method](../public-api-methods/index.md). |
|
||||
| `id` | (Various) | _(Optional)_ A unique value to identify this request. The response to this request uses the same `id` field. This way, even if responses arrive out of order, you know which request prompted which response. |
|
||||
| `api_version` | Number | _(Optional)_ The API version to use. If omitted, uses version 1. For details, see [API Versioning](#api-versioning). |
|
||||
| `api_version` | Number | _(Optional)_ The API version to use. For details, see [API Versioning](../index.md#api-versioning). |
|
||||
| (Method Parameters) | (Various) | Provide any parameters to the method at the top level. |
|
||||
|
||||
See [Response Formatting](response-formatting.md) for the response from the server.
|
||||
@@ -84,7 +80,7 @@ The object inside the `params` array can contain the following fields:
|
||||
|
||||
| Field | Type | Description |
|
||||
|:--------------------|:----------|:-------------------------------------------|
|
||||
| `api_version` | Number | _(Optional)_ The API version to use. If omitted, uses version `1`. For details, see [API Versioning](#api-versioning). |
|
||||
| `api_version` | Number | _(Optional)_ The API version to use. For details, see [API Versioning](#api-versioning). |
|
||||
| (Method Parameters) | (Various) | Provide any parameters to the method here. |
|
||||
|
||||
See [Response Formatting](response-formatting.md) for the response from the server.
|
||||
@@ -95,7 +91,7 @@ Put the API method name after any normal (dash-prefaced) commandline options, fo
|
||||
|
||||
The commandline calls JSON-RPC, so its responses always match the JSON-RPC [response format](response-formatting.md).
|
||||
|
||||
The commandline always uses the latest [API version](#api-versioning).
|
||||
The commandline always uses the latest [API version](./index.md#api-versioning).
|
||||
|
||||
{% admonition type="warning" name="Caution" %}The commandline interface is intended for administrative purposes only and is _not a supported API_. New versions of `rippled` may introduce breaking changes to the commandline API without warning!{% /admonition %}
|
||||
|
||||
|
||||
@@ -6,37 +6,38 @@ metadata:
|
||||
---
|
||||
# HTTP / WebSocket APIs
|
||||
|
||||
You can communicate with the XRP Ledger through the `rippled` servers' publicly available APIs.
|
||||
You can communicate directly with the XRP Ledger through HTTP-based APIs provided by the core `rippled` server as well as the Clio server. Both types of server provide JSON-RPC and WebSocket APIs with mostly the same functionality. JSON-RPC uses a strict request-response paradigm similar to a REST API, but WebSocket uses a single persistent connection where the server can push messages to the client asynchronously. For more information, see [Get Started Using HTTP / WebSocket APIs](../../tutorials/http-websocket-apis/build-apps/get-started.md).
|
||||
|
||||
[{% inline-svg file="/docs/img/api-functionality-venn-diagram.svg" /%}](/docs/img/api-functionality-venn-diagram.svg "Diagram: Most API methods are provided by both rippled and Clio servers. The rippled server provides admin methods, provides pending/unvalidated data including transaction queue, and has a live view of consensus and peer-to-peer network. The Clio server scales efficiently, provides additional methods nft_history, nft_info, nfts_by_issuer, and mpt_holders, and serves rippled-exclusive API requests by forwarding.")
|
||||
|
||||
## API Versioning
|
||||
|
||||
Currently, there are two API versions: `1` and `2` {% badge href="https://github.com/XRPLF/rippled/releases/tag/2.0.0" %}New in: rippled 2.0.0{% /badge %}. The server reports the range of supported API versions in the [`version` API method](public-api-methods/server-info-methods/version.md); you can specify which version to use in your API requests.
|
||||
|
||||
Separate API requests can use different API versions even on the same persistent connection. For example, if you connect through WebSocket to a server that supports API versions 1 and 2, you can make an `account_tx` request using API version 2 and then make another `account_tx` request using API version 1 from the same connection.
|
||||
|
||||
- For a full list of the differences between API versions, see [API-CHANGELOG on GitHub](https://github.com/xrplf/rippled/blob/develop/API-CHANGELOG.md).
|
||||
- For a full list of the differences between API versions, see [API-CHANGELOG on GitHub](https://github.com/XRPLF/rippled/blob/develop/API-CHANGELOG.md).
|
||||
- To stay up-to-date with API changes, join the [ripple server mailing list](https://groups.google.com/g/ripple-server).
|
||||
|
||||
### Specifying a Version
|
||||
|
||||
## Default API Versions
|
||||
Use the `api_version` field of the request to specify which API version to use. See [Request Formatting](./api-conventions/request-formatting.md) for example requests.
|
||||
|
||||
The table below shows which version of the `rippled` API is used if you don't specify it in the request:
|
||||
Separate API requests can use different API versions even on the same persistent connection. For example, if you connect through WebSocket to a server that supports API versions 1 and 2, you can make an `account_tx` request using API version 2 and then make another `account_tx` request using API version 1 from the same connection.
|
||||
|
||||
| Request Method | API Version | Additional Notes |
|
||||
|----------------|-------------|------------------|
|
||||
| Websocket | 1 | |
|
||||
| JSON-RPC | 1 | |
|
||||
| Commandline | 2 | The commandline only uses the latest API version. |
|
||||
| [xrpl.js](https://github.com/XRPLF/xrpl.js) | 2 | Defaults to [API v2][] starting in v4.0.0. |
|
||||
| [xrpl-py](https://github.com/XRPLF/xrpl-py) | 2 | Defaults to [API v2][] starting in v3.0.0. |
|
||||
### Default API Versions
|
||||
|
||||
{% admonition type="info" name="Note" %}
|
||||
Clio behaves the same as `rippled`.
|
||||
{% /admonition %}
|
||||
If you do not specify an API version when making a request directly to the server, the server uses API v1. However, some [client libraries](../client-libraries.md) automatically use a different API version if you do not specify one. The following table shows which API version each library uses when you don't specify which API version to use:
|
||||
|
||||
| Client Library | API Version | Additional Notes |
|
||||
|-----------------------------------------------|-------------|------------------|
|
||||
| None - direct WebSocket / JSON-RPC connection | 1 | |
|
||||
| None - `rippled` Commandline | 2 | The commandline only uses the latest API version. |
|
||||
| [xrpl.js](https://github.com/XRPLF/xrpl.js) | 2 | Versions 3.x and older use API v1 by default. |
|
||||
| [xrpl-py](https://github.com/XRPLF/xrpl-py) | 2 | Versions 2.x and older use API v1 by default. |
|
||||
|
||||
Future versions of `rippled` that introduce breaking changes will introduce a new API version 3.
|
||||
|
||||
### Breaking Changes
|
||||
|
||||
The following types of changes are **breaking changes**:
|
||||
New API versions can introduce breaking changes. The following types of changes are **breaking changes**:
|
||||
|
||||
- Removing or renaming a field of a request or response.
|
||||
- Changing the type of a field of a request or response.
|
||||
@@ -44,16 +45,10 @@ The following types of changes are **breaking changes**:
|
||||
- Changing the order of positional parameters, or adding a new field before other positional parameters.
|
||||
- Removing or renaming an API method.
|
||||
- Changing the behavior of an API function visible to existing clients.
|
||||
- The following types of breaking changes only apply to the gRPC API:
|
||||
- Changing a `proto` field number.
|
||||
- Removing or renaming an enum or enum value.
|
||||
- Adding or removing fields from a `oneof`.
|
||||
- Splitting or merging a `oneof`.
|
||||
- Changing whether a message field is `optional`, `repeated`, or `required`.
|
||||
- Changing the stream value of a request or response.
|
||||
- Deleting or renaming a package or service.
|
||||
|
||||
Any time a full release introduces a breaking change, it introduces a new API version number. Pre-release, beta, and development versions may introduce breaking changes to the same API version number.
|
||||
Any time a full release introduces a breaking change, it introduces a new API version number.
|
||||
|
||||
API versions are subject to change until they are included in a stable release of the server. New API versions are expected to experience multiple breaking changes across development, beta, and pre-release software.
|
||||
|
||||
### Non-Breaking Changes
|
||||
|
||||
@@ -61,7 +56,11 @@ The following types of changes are **non-breaking changes** and may occur withou
|
||||
|
||||
- Adding a new field to a request or response, not including positional parameters.
|
||||
- Adding a new API method.
|
||||
- Fixing a bug so that the API matches prior documentation and behavior.
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
## API Method References
|
||||
|
||||
{% child-pages /%}
|
||||
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,9 +1,11 @@
|
||||
---
|
||||
blurb: Get the holders for a given `MPTokenIssuanceID` and ledger sequence.
|
||||
seo:
|
||||
description: Get the holders of a given MPT issuance as of a given ledger.
|
||||
labels:
|
||||
- Accounts
|
||||
- XRP
|
||||
- Multi Purpose Tokens, MPTs
|
||||
stautus: not_enabled
|
||||
---
|
||||
|
||||
# mpt_holders
|
||||
|
||||
@@ -59,29 +59,7 @@ A request can include the following fields:
|
||||
| `binary` | Boolean | No | If `true`, return ledger entries as hexadecimal strings instead of JSON. The default is `false`. |
|
||||
| `limit` | Number | No | Limit the number of ledger entries to retrieve. The server may return fewer than this number of entries. Cannot be more than 2048 (when requesting binary) or 256 (when requesting JSON). Positive values outside this range are replaced with the closest valid option. The default is the maximum. |
|
||||
| `marker` | [Marker][] | No | Value from a previous paginated response. Resume retrieving data where that response left off. |
|
||||
| `type` | String | No | Filter results to a specific type of ledger entry. This field accepts canonical ledger entry names (case insensitive) or short names. |
|
||||
|
||||
Valid `type` field values are:
|
||||
|
||||
| Canonical Name | Short Name |
|
||||
| ----------------- | ----------------- |
|
||||
| `AccountRoot` | `account` |
|
||||
| `Amendments` | `amendments` |
|
||||
| `AMM` | `amm` |
|
||||
| `Check` | `check` |
|
||||
| `DepositPreauth` | `deposit_preauth` |
|
||||
| `DirectoryNode` | `directory` |
|
||||
| `Escrow` | `escrow` |
|
||||
| `FeeSettings` | `fee` |
|
||||
| `LedgerHashes` | `hashes` |
|
||||
| `MPToken` | `mptoken` |
|
||||
| `MPTokenIssuance` | `mpt_issuance` |
|
||||
| `NFTokenOffer ` | `nft_offer` |
|
||||
| `Offer` | `offer` |
|
||||
| `PayChannel` | `payment_channel` |
|
||||
| `RippleState` | `state` |
|
||||
| `SignerList` | `signer_list` |
|
||||
| `Ticket` | `ticket` |
|
||||
| `type` | String | No | Filter results to a specific type of ledger entry. This field accepts canonical names of [ledger entry types](../../../protocol/ledger-data/ledger-entry-types/index.md) (case insensitive) or [short names](../../api-conventions/ledger-entry-short-names.md). If omitted, return ledger entries of all types. |
|
||||
|
||||
The `ledger` field is deprecated and may be removed without further notice.
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
html: get_aggregate_price.html
|
||||
parent: ledger-methods.html
|
||||
blurb: Calculates the aggregate price of specified Oracle instances.
|
||||
seo:
|
||||
description: Calculate the aggregate price of specified Oracle instances.
|
||||
labels:
|
||||
- Oracle
|
||||
---
|
||||
|
||||
@@ -115,4 +115,10 @@ The ID of an AccountRoot entry is the [SHA-512Half][] of the following values, c
|
||||
* The Account space key (`0x0061`)
|
||||
* The AccountID of the account
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [AccountSet transaction][]
|
||||
- [AccountDelete transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Singleton ledger entry with status of enabled and pending amendments.
|
||||
description: The status of enabled and pending amendments.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
|
||||
@@ -119,4 +119,15 @@ The ID of an `AMM` entry is the [SHA-512Half][] of the following values, concate
|
||||
|
||||
For XRP, use all 0's for both the token and the issuer.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [AMMBid transaction][]
|
||||
- [AMMClawback transaction][]
|
||||
- [AMMCreate transaction][]
|
||||
- [AMMDelete transaction][]
|
||||
- [AMMDeposit transaction][]
|
||||
- [AMMVote transaction][]
|
||||
- [AMMWithdraw transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: A `bridge` object represents a single cross-chain bridge that connects and enables value to move efficiently between two blockchains.
|
||||
description: A single cross-chain bridge that connects and enables value to move efficiently between two blockchains.
|
||||
labels:
|
||||
- Interoperability
|
||||
status: not_enabled
|
||||
@@ -66,4 +66,10 @@ In addition to the [common fields](../common-fields.md), {% code-page-name /%} e
|
||||
| `LockingChainDoor` | String | Account | Yes | The door account on the locking chain. |
|
||||
| `LockingChainIssue` | Issue | Issue | Yes | The asset that is locked and unlocked on the locking chain. |
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [XChainCreateBridge transaction][]
|
||||
- [XChainModifyBridge transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -75,4 +75,11 @@ The ID of a `Check` entry is the [SHA-512Half][] of the following values, concat
|
||||
|
||||
See the tutorial showing how to [Send a Check](../../../../tutorials/how-tos/use-specialized-payment-types/use-checks/send-a-check.md).
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [CheckCancel transaction][]
|
||||
- [CheckCash transaction][]
|
||||
- [CheckCreate transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: An attestation about a subject account from a credential issuer account, which can be used to preauthorize payments.
|
||||
description: A credential, which can be used to preauthorize payments or gain access to specific permissioned domains.
|
||||
status: not_enabled
|
||||
---
|
||||
# Credential
|
||||
@@ -65,4 +65,11 @@ The unique ID of a Credential entry is the SHA-512Half hash of the following val
|
||||
* The `Issuer` field's value; and
|
||||
* The `CredentialType` field's value.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [CredentialAccept transaction][]
|
||||
- [CredentialCreate transaction][]
|
||||
- [CredentialDelete transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -4,6 +4,7 @@ seo:
|
||||
labels:
|
||||
- Accounts
|
||||
- Permissions
|
||||
status: not_enabled
|
||||
---
|
||||
# Delegate
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/1e01cd34f7a216092ed779f291b43324c167167a/include/xrpl/protocol/detail/ledger_entries.macro#L475-L482 "Source")
|
||||
@@ -65,4 +66,9 @@ There are no flags defined for {% code-page-name /%} entries.
|
||||
|
||||
{% code-page-name /%} entries are not deletion blockers. If the owner (delegating) account is deleted, all such ledger entries are deleted along with them. However, the `Authorize`
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [DelegateSet transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -109,4 +109,9 @@ In this case, the ID is the [SHA-512Half][] of the following values, concatenate
|
||||
* The AccountID of the owner of this object (the sender of the [DepositPreauth transaction][] that created this object; in other words, the one that granted the preauthorization)
|
||||
* The contents of the `AuthorizeCredentials` field.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions**
|
||||
- [DepositPreauth transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: The definition and details of a Decentralized Identifier (DID).
|
||||
description: A Decentralized Identifier (DID).
|
||||
labels:
|
||||
- DID
|
||||
---
|
||||
@@ -61,4 +61,10 @@ The ID of a `DID` entry is the [SHA-512Half][] of the following values, concaten
|
||||
1. The `DID` space key (`0x0049`).
|
||||
2. The AccountID that controls the DID.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [DIDDelete transaction][]
|
||||
- [DIDSet transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Contains links to other objects.
|
||||
description: A set of links to other ledger entries, either objects owned by an account or trades in the decentralized exchange.
|
||||
labels:
|
||||
- Data Retention
|
||||
- Decentralized Exchange
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Contains XRP held for a conditional payment.
|
||||
description: An escrow, which holds funds to be released when certain conditions are met.
|
||||
labels:
|
||||
- Escrow
|
||||
---
|
||||
@@ -74,4 +74,11 @@ The ID of an `Escrow` entry is the [SHA-512Half][] of the following values, conc
|
||||
* The Sequence number of the [EscrowCreate transaction][] that created the `Escrow` entry
|
||||
If the EscrowCreate transaction used a [Ticket](../../../../concepts/accounts/tickets.md), use the `TicketSequence` value instead.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [EscrowCancel transaction][]
|
||||
- [EscrowCreate transaction][]
|
||||
- [EscrowFinish transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Singleton object with consensus-approved base transaction cost and reserve requirements.
|
||||
description: The current base transaction cost and reserve requirements.
|
||||
labels:
|
||||
- Fees
|
||||
---
|
||||
@@ -11,6 +11,25 @@ The `FeeSettings` entry contains the current base [transaction cost](../../../..
|
||||
|
||||
## Example {% $frontmatter.seo.title %} JSON
|
||||
|
||||
This ledger entry has two formats, depending on whether the [XRPFees amendment][] was enabled at the time:
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Current Format" %}
|
||||
```json
|
||||
{
|
||||
"BaseFeeDrops": "10",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "FeeSettings",
|
||||
"PreviousTxnID": "4EEDB01BB943CE32E97BB468AC179ABF933B272D6FF990E76B6721FB48E069FC",
|
||||
"PreviousTxnLgrSeq": 92508417,
|
||||
"ReserveBaseDrops": "1000000",
|
||||
"ReserveIncrementDrops": "200000",
|
||||
"index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Legacy Format" %}
|
||||
```json
|
||||
{
|
||||
"BaseFee": "000000000000000A",
|
||||
@@ -22,16 +41,28 @@ The `FeeSettings` entry contains the current base [transaction cost](../../../..
|
||||
"index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651"
|
||||
}
|
||||
```
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
## {% $frontmatter.seo.title %} Fields
|
||||
|
||||
In addition to the [common fields](../common-fields.md), the {% code-page-name /%} ledger entry has the following fields:
|
||||
The fields of the `FeeSettings` ledger entry depend on whether the [XRPFees amendment][] was enabled the last time it was modified. If the last update was before the amendment became enabled, the entry uses the **legacy format**. If it has been updated after the amendment, it uses the **current format**. The fields it can have, in addition to the [common fields](../common-fields.md), are as follows:
|
||||
|
||||
{% tabs %}
|
||||
{% tab label="Current Format" %}
|
||||
| Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|:------------------------|:----------|:------------------|:----------|:-----------------------|
|
||||
| `BaseFeeDrops` | String | Amount | Yes | The [transaction cost](../../../../concepts/transactions/transaction-cost.md) of the "reference transaction" in drops of XRP. |
|
||||
| `ReserveBaseDrops` | String | Amount | Yes | The [base reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. |
|
||||
| `ReserveIncrementDrops` | String | Amount | Yes | The incremental [owner reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
|
||||
| `PreviousTxnID` | String | UInt256 | No | The identifying hash of the transaction that most recently modified this entry. _(Added by the [fixPreviousTxnID amendment][].)_ |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | No | The [index of the ledger][Ledger Index] that contains the transaction that most recently modified this entry. _(Added by the [fixPreviousTxnID amendment][].)_ |
|
||||
{% /tab %}
|
||||
|
||||
{% tab label="Legacy Format" %}
|
||||
| Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|:--------------------|:----------|:------------------|:----------|:-----------------------|
|
||||
| `BaseFee` | String | UInt64 | Yes | The [transaction cost](../../../../concepts/transactions/transaction-cost.md) of the "reference transaction" in drops of XRP as hexadecimal. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `FeeSettings` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. |
|
||||
| `ReferenceFeeUnits` | Number | UInt32 | Yes | The `BaseFee` translated into "fee units". |
|
||||
| `ReserveBase` | Number | UInt32 | Yes | The [base reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. |
|
||||
| `ReserveIncrement` | Number | UInt32 | Yes | The incremental [owner reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
|
||||
@@ -40,16 +71,8 @@ In addition to the [common fields](../common-fields.md), the {% code-page-name /
|
||||
|
||||
{% admonition type="danger" name="Warning" %}The JSON format for this ledger entry type is unusual. The `BaseFee`, `ReserveBase`, and `ReserveIncrement` indicate drops of XRP but ***not*** in the usual format for [specifying XRP][Currency Amount].{% /admonition %}
|
||||
|
||||
|
||||
If the _[XRPFees amendment][]_ is enabled, the `FeeSettings` object has these fields instead:
|
||||
|
||||
| Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|:------------------------|:----------|:------------------|:----------|:-----------------------|
|
||||
| `BaseFeeDrops` | String | Amount | Yes | The [transaction cost](../../../../concepts/transactions/transaction-cost.md) of the "reference transaction" in drops of XRP. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bitmap of boolean flags enabled for this object. Currently, the protocol defines no flags for `FeeSettings` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. |
|
||||
| `ReserveBaseDrops` | String | Amount | Yes | The [base reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for an account in the XRP Ledger, as drops of XRP. |
|
||||
| `ReserveIncrementDrops` | String | Amount | Yes | The incremental [owner reserve](../../../../concepts/accounts/reserves.md#base-reserve-and-owner-reserve) for owning objects, as drops of XRP. |
|
||||
{% /tab %}
|
||||
{% /tabs %}
|
||||
|
||||
|
||||
## {% $frontmatter.seo.title %} Flags
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
html: ledger-entry-types.html
|
||||
parent: ledger-data-formats.html
|
||||
seo:
|
||||
description: A list of all entry types that can exist in the ledger's state data.
|
||||
metadata:
|
||||
indexPage: true
|
||||
---
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
blurb: Describes the XRPL multi-purpose token object.
|
||||
seo:
|
||||
description: Multi-Purpose Tokens (MPT) of one issuance held by a specific account.
|
||||
labels:
|
||||
- Multi-purpose Tokens, MPTs, Tokens
|
||||
status: not_enabled
|
||||
---
|
||||
# MPToken
|
||||
|
||||
@@ -54,4 +56,8 @@ The ID of an `MPToken` entry is the [SHA-512Half][] of the following values, con
|
||||
- The `MPTokenIssuanceID` for the issuance being held.
|
||||
- The `AccountID` of the token holder.
|
||||
|
||||
## See Also
|
||||
|
||||
- [MPTokenAuthorize transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
blurb: The `MPTokenIssuance` object represents a single MPT issuance and holds data associated with the issuance itself.
|
||||
seo:
|
||||
description: Definition of a Multi-Purpose Token (MPT) issuance.
|
||||
labels:
|
||||
- Multi-purpose Tokens, MPTs, Tokens
|
||||
status: not_enabled
|
||||
---
|
||||
# MPTokenIssuance
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Create offers to buy or sell NFTs.
|
||||
description: An offer to buy or sell an NFT.
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Ledger structure for recording NFTokens.
|
||||
description: A group of up to 32 NFTs, stored together for efficiency.
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: An order to make a currency trade.
|
||||
description: An offer (order) to trade currencies in the decentralized exchange.
|
||||
labels:
|
||||
- Decentralized Exchange
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: A ledger entry to publish price information about currency pairs.
|
||||
description: A record of price information about currency pairs from an outside source.
|
||||
labels:
|
||||
- Decentralized Exchange
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: A channel for asynchronous XRP payments.
|
||||
description: A payment channel, which allows for rapid, asynchronous payments.
|
||||
labels:
|
||||
- Payment Channels
|
||||
---
|
||||
|
||||
@@ -1,9 +1,10 @@
|
||||
---
|
||||
seo:
|
||||
description: A PermissionedDomain ledger entry represents a Permissioned Domain, which is used to limit access to other features.
|
||||
description: A permissioned domain, which is used to limit access to other features.
|
||||
labels:
|
||||
- Compliance
|
||||
- Permissioned Domains
|
||||
status: not_enabled
|
||||
---
|
||||
# PermissionedDomain
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/detail/ledger_entries.macro#L451-L461 "Source")
|
||||
@@ -77,5 +78,10 @@ The ID of a {% code-page-name /%} entry is the [SHA-512Half][] of the following
|
||||
0. The AccountID of the {% code-page-name /%}'s owner.
|
||||
0. The Sequence number of the transaction that created the {% code-page-name /%}.
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [PermissionedDomainDelete transaction][]
|
||||
- [PermissionedDomainSet transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: This entry represents a trust line, tracking the net balance of tokens between them.
|
||||
description: A trust line, which tracks the net balance of fungible tokens between two accounts.
|
||||
labels:
|
||||
- Tokens
|
||||
---
|
||||
@@ -124,4 +124,9 @@ The ID of a RippleState entry is the [SHA-512Half][] of the following values, co
|
||||
* The AccountID of the high account
|
||||
* The 160-bit currency code of the trust line(s)
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [TrustSet transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -102,4 +102,9 @@ The ID of a `SignerList` entry is the SHA-512Half of the following values, conca
|
||||
* The AccountID of the owner of the signer list
|
||||
* The `SignerListID` (currently always `0`)
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [SignerListSet transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: ticket.html
|
||||
parent: ledger-entry-types.html
|
||||
seo:
|
||||
description: A Ticket tracks an account sequence number that has been set aside for future use.
|
||||
description: A ticket, which sets aside a sequence number for use in a future transaction.
|
||||
labels:
|
||||
- Transaction Sending
|
||||
---
|
||||
@@ -60,4 +58,9 @@ The ID of a Ticket object is the SHA-512Half of the following values, concatenat
|
||||
* The AccountID of the owner of the Ticket
|
||||
* The `TicketSequence` number of the Ticket
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [TicketCreate transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: An `XChainOwnedClaimID` object represents *one* cross-chain transfer of value.
|
||||
description: A cross-chain transfer of value.
|
||||
labels:
|
||||
- Interoperability
|
||||
status: not_enabled
|
||||
@@ -102,4 +102,9 @@ _(Requires the [XChainBridge amendment][] {% not-enabled /%})_
|
||||
| `LockingChainDoor` | String | AccountID | Yes | The door account on the locking chain. |
|
||||
| `LockingChainIssue` | Issue | Issue | Yes | The asset that is locked and unlocked on the locking chain. |
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [XChainCreateClaimID transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: The `XChainOwnedCreateAccountClaimID` ledger object is used to collect attestations for creating an account via a cross-chain transfer.
|
||||
description: A record of attestations for creating an account via a cross-chain transfer.
|
||||
labels:
|
||||
- Interoperability
|
||||
status: not_enabled
|
||||
@@ -85,4 +85,9 @@ _(Requires the [XChainBridge amendment][] {% not-enabled /%})_
|
||||
| `LockingChainDoor` | String | AccountID | Yes | The door account on the locking chain. |
|
||||
| `LockingChainIssue` | Issue | Issue | Yes | The asset that is locked and unlocked on the locking chain. |
|
||||
|
||||
## See Also
|
||||
|
||||
- **Transactions:**
|
||||
- [XChainAddAccountCreateAttestation transaction][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: transaction-common-fields.html
|
||||
parent: transaction-formats.html
|
||||
seo:
|
||||
description: These common fields can be provided on any XRP Ledger transaction.
|
||||
labels:
|
||||
|
||||
@@ -60,4 +60,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `tecHAS_OBLIGATIONS` | Occurs if the account to be deleted is connected to objects that cannot be deleted in the ledger. (This includes objects created by other accounts, such as [escrows](../../../../concepts/payment-types/escrow.md) and for example [NFT's minted](nftokenmint.md), [even if owned by another account](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/DeleteAccount.cpp#L197).) |
|
||||
| `tefTOO_BIG` | Occurs if the sending account is linked to more than 1000 objects in the ledger. The transaction could succeed on retry if some of those objects were deleted separately first. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AccountRoot entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -158,6 +158,10 @@ See [Transfer Fees](../../../../concepts/tokens/transfer-fees.md) for more infor
|
||||
|
||||
To remove an authorized minter, set `ClearFlag` to 10 (`asfAuthorizedNFTokenMinter`) and omit the `NFTokenMinter` field.
|
||||
|
||||
## See Also
|
||||
|
||||
- [AccountRoot entry][]
|
||||
|
||||
<!-- SPELLING_IGNORE: TransferRate -->
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: ammbid.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Bid on an Automated Market Maker's auction slot, which grants a discounted fee.
|
||||
labels:
|
||||
@@ -142,4 +140,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `terNO_ACCOUNT` | One of the accounts specified in this request do not exist. |
|
||||
| `terNO_AMM` | The Automated Market Maker instance for the asset pair in this transaction does not exist. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
seo:
|
||||
description: Claw back tokens from a holder who has deposited your issued tokens into an Automated Market Maker pool.
|
||||
labels:
|
||||
- AMM
|
||||
- Tokens
|
||||
---
|
||||
# AMMClawback
|
||||
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/AMMClawback.cpp "Source")
|
||||
@@ -66,4 +73,8 @@ Besides errors that can occur for all transactions, `AMMClawback` transactions c
|
||||
| `temMALFORMED` | Occurs if the `issuer` subfield doesn't match between `Asset` and `Account`, `Account` is the same as the `Holder`, or `Asset` is XRP. |
|
||||
| `terNO_AMM` | Occurs if the AMM pool specified by `Asset` and `Asset2` doesn't exist. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: ammcreate.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Create a new Automated Market Maker for trading a given pair of assets.
|
||||
labels:
|
||||
@@ -69,4 +67,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `temBAD_FEE` | The `TradingFee` value is invalid. It must be zero or a positive integer and cannot be over 1000. |
|
||||
| `temDISABLED` | The AMM feature is not enabled on this network. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: ammdelete.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Delete an Automated Market Maker instance with an empty asset pool.
|
||||
description: Delete an Automated Market Maker with an empty asset pool.
|
||||
labels:
|
||||
- AMM
|
||||
---
|
||||
@@ -53,4 +51,8 @@ Besides errors that can occur for all transactions, AMMCreate transactions can r
|
||||
| `tecINCOMPLETE` | There were too many associated ledger entries to fully delete, so the transaction removed as many as it could, but the AMM has not been fully deleted. You can send another AMMDelete transaction to continue and possibly finish the job. |
|
||||
| `terNO_AMM` | The specified AMM does not exist. (It may have been deleted already, or you may have specified a wrong asset for the AMM you intended.) |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: ammdeposit.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Deposit funds into an Automated Market Maker in exchange for LPTokens.
|
||||
labels:
|
||||
@@ -147,4 +145,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `terNO_ACCOUNT` | An account specified in the request does not exist. |
|
||||
| `terNO_AMM` | The Automated Market Maker instance for the asset pair in this transaction does not exist. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: ammvote.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Vote on the trading fee for an Automated Market Maker instance.
|
||||
description: Vote on the trading fee for an Automated Market Maker.
|
||||
labels:
|
||||
- AMM
|
||||
---
|
||||
@@ -55,4 +53,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `temBAD_FEE` | The `TradingFee` from this transaction is not valid. |
|
||||
| `terNO_AMM` | The Automated Market Maker instance for the asset pair in this transaction does not exist. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: ammwithdraw.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Return LPTokens into an Automated Market Maker in exchange for a share of the assets the pool holds.
|
||||
description: Return LPTokens to an Automated Market Maker in exchange for a share of the assets the pool holds.
|
||||
labels:
|
||||
- AMM
|
||||
---
|
||||
@@ -123,4 +121,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `temBAD_AMM_TOKENS` | The transaction specified the LP Tokens incorrectly; for example, the `issuer` is not the AMM's associated AccountRoot address or the `currency` is not the currency code for this AMM's LP Tokens, or the transaction specified this AMM's LP Tokens in one of the asset fields. |
|
||||
| `terNO_AMM` | The Automated Market Maker instance for the asset pair in this transaction does not exist. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [AMM entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: checkcancel.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Cancel a check.
|
||||
labels:
|
||||
@@ -38,4 +36,8 @@ _(Added by the [Checks amendment][].)_
|
||||
- If the object identified by the `CheckID` does not exist or is not a Check, the transaction fails with the result `tecNO_ENTRY`.
|
||||
- If the Check is not expired and the sender of the CheckCancel transaction is not the source or destination of the Check, the transaction fails with the result `tecNO_PERMISSION`.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Check entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: checkcash.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Redeem a check.
|
||||
labels:
|
||||
@@ -49,4 +47,8 @@ The transaction ***must*** include either `Amount` or `DeliverMin`, but not both
|
||||
- If the transaction specifies both `Amount` and `DeliverMin`, or omits both, the transaction fails with the result `temMALFORMED`.
|
||||
- If the `Amount` or `DeliverMin` does not match the currency (and issuer, if not XRP) of the Check, the transaction fails with the result `temBAD_CURRENCY`.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Check entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,4 @@
|
||||
---
|
||||
html: checkcreate.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Create a check.
|
||||
labels:
|
||||
@@ -51,4 +49,8 @@ _(Added by the [Checks amendment][].)_
|
||||
- If the sender does not have enough XRP to meet the [owner reserve](../../../../concepts/accounts/reserves.md#owner-reserves) after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`.
|
||||
- If either the sender or the destination of the Check cannot own more objects in the ledger, the transaction fails with the result `tecDIR_FULL`.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Check entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -48,5 +48,8 @@ The combination of `Account`, `Issuer`, and `CredentialType` must match a `Crede
|
||||
| `temINVALID_ACCOUNT_ID` | The provided `Issuer` field is invalid. For example, it contains [ACCOUNT_ZERO](../../../../concepts/accounts/addresses.md#special-addresses). |
|
||||
| `temINVALID_FLAG` | The transaction includes a [Flag](../common-fields.md#flags-field) that does not exist, or includes a contradictory combination of flags. _(Requires the [fixInvalidTxFlags amendment][] {% not-enabled /%})_ |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Credential entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -50,5 +50,8 @@ Besides errors that can occur for all transactions, CredentialCreate transaction
|
||||
| `temINVALID_ACCOUNT_ID` | The provided `Subject` field is invalid. For example, it contains [ACCOUNT_ZERO](../../../../concepts/accounts/addresses.md#special-addresses). |
|
||||
| `temINVALID_FLAG` | The transaction includes a [Flag](../common-fields.md#flags-field) that does not exist, or includes a contradictory combination of flags. _(Requires the [fixInvalidTxFlags amendment][] {% not-enabled /%})_ |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Credential entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -49,5 +49,8 @@ This transaction looks for a [Credential ledger entry](../../ledger-data/ledger-
|
||||
| `tecNO_ENTRY` | The specified credential does not exist in the ledger. |
|
||||
| `temINVALID_FLAG` | The transaction includes a [Flag](../common-fields.md#flags-field) that does not exist, or includes a contradictory combination of flags. _(Requires the [fixInvalidTxFlags amendment][] {% not-enabled /%})_ |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Credential entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: An transaction that delegates a set of permissions to another account.
|
||||
description: Grant another account permission to send some transactions for you, or revoke that permission.
|
||||
labels:
|
||||
- Accounts
|
||||
- Permissions
|
||||
@@ -73,5 +73,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `temDISABLED` | The [Permission Delegation amendment][] is not enabled. |
|
||||
| `temMALFORMED` | The transaction was invalid. For example, the `Authorize` account is the same as the sender of the transaction, the `Permissions` list contains duplicate entries, or one of the permissions in the list is not a valid permission. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [Delegate ledger entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Preauthorizes an account to send payments to this one.
|
||||
description: Preauthorize an account to send payments to you.
|
||||
labels:
|
||||
- Security
|
||||
---
|
||||
@@ -89,5 +89,8 @@ In addition to error types that can occur for all transactions, DepositPreauth t
|
||||
| `temCANNOT_PREAUTH_SELF` | The address in the `Authorize` field is the sender of the transaction. You cannot preauthorize yourself. |
|
||||
| `temDISABLED` | A required amendment is not enabled. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [DepositPreauth object][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: diddelete.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Delete a DID.
|
||||
description: Delete a Decentralized Identifier.
|
||||
labels:
|
||||
- DID
|
||||
---
|
||||
@@ -39,4 +37,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
|:--------------------|:---------------------------------------------|
|
||||
| `tecNO_ENTRY` | The account doesn't have a DID. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [DID entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Create or update a DID.
|
||||
description: Create or update a Decentralized Identifier.
|
||||
labels:
|
||||
- DID
|
||||
---
|
||||
@@ -48,4 +48,8 @@ Besides errors that can occur for all transactions, {% $frontmatter.seo.title %}
|
||||
| `tecEMPTY_DID` | The transaction will create an empty DID ledger entry. Check that your updates don't remove the `Data`, `DIDDocument`, and `URI` fields. |
|
||||
| `temEMPTY_DID` | The transaction is malformed and missing any DID information. Include either the `Data`, `DIDDocument`, or `URI` fields. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [DID entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Reclaim escrowed XRP.
|
||||
description: Cancel an expired escrow, returning the funds to the sender.
|
||||
labels:
|
||||
- Escrow
|
||||
---
|
||||
@@ -38,4 +38,8 @@ Any account may submit an EscrowCancel transaction.
|
||||
* If the corresponding [EscrowCreate transaction][] did not specify a `CancelAfter` time, the EscrowCancel transaction fails.
|
||||
* Otherwise the EscrowCancel transaction fails if the `CancelAfter` time is after the close time of the most recently-closed ledger.
|
||||
|
||||
## See Also
|
||||
|
||||
- [Escrow entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Create an escrowed XRP payment.
|
||||
description: Escrow funds, which can be released to the destination after a specific time or condition.
|
||||
labels:
|
||||
- Escrow
|
||||
---
|
||||
@@ -58,4 +58,8 @@ It is not possible to create a conditional escrow with no expiration, but you ca
|
||||
Before the [fix1571 amendment][] became enabled on 2018-06-19, it was possible to create an escrow with `CancelAfter` only. These escrows could be finished by anyone at any time before the specified expiration.
|
||||
{% /admonition %}
|
||||
|
||||
## See Also
|
||||
|
||||
- [Escrow entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Deliver escrowed XRP to recipient.
|
||||
description: Deliver escrowed funds to the intended recipient.
|
||||
labels:
|
||||
- Escrow
|
||||
---
|
||||
@@ -49,4 +49,8 @@ Any account may submit an EscrowFinish transaction.
|
||||
|
||||
In [non-production networks](../../../../concepts/networks-and-servers/parallel-networks.md), it may be possible [to delete](../../../../concepts/accounts/deleting-accounts.md) the destination account of a pending escrow. In this case, an attempt to finish the escrow fails with the result `tecNO_TARGET`, but the escrow object remains unless it has expired normally. If another payment re-creates the destination account, the escrow can be finished successfully. The destination account of an escrow can only be deleted if the escrow was created before the [fix1523 amendment](/resources/known-amendments.md#fix1523) became enabled. No such escrows exist in the production XRP Ledger, so this edge case is not possible on the production XRP Ledger. This edge case is also not possible in test networks that enable both fix1523 and Escrow amendments at the same time, which is the default when you [start a new genesis ledger](../../../../infrastructure/testing-and-auditing/start-a-new-genesis-ledger-in-stand-alone-mode.md).
|
||||
|
||||
## See Also
|
||||
|
||||
- [Escrow entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
seo:
|
||||
description: Repair corruptions to the XRP ledger.
|
||||
description: Repair corruptions to the XRP ledger's state data.
|
||||
labels:
|
||||
- Utilities
|
||||
- Troubleshooting
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
blurb: Allow an account to hold an amount of a particular MPT.
|
||||
seo:
|
||||
description: Set up your account to receive a specific MPT as a holder; or authorize a holder as an MPT issuer.
|
||||
labels:
|
||||
- Multi-purpose Tokens, MPTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# MPTokenAuthorize
|
||||
@@ -30,4 +32,8 @@ Transactions of the MPTokenAuthorize type support additional values in the `Flag
|
||||
|:-------------------|:-------------|:--------------|:------------------------------|
|
||||
| `tfMPTUnauthorize` | `0x00000001` | 1 | When the holder enables this flag, if their balance of the given MPT is zero, it revokes their willingness to hold this MPT and deletes their `MPToken` entry. If their balance is non-zero, the transaction fails. When an issuer enables this flag, it revokes permission for the specified holder to hold this MPT; the transaction fails if the MPT does not use allow-listing. |
|
||||
|
||||
## See Also
|
||||
|
||||
- [MPToken entry][]
|
||||
|
||||
{% raw-partial file="/docs/_snippets/common-links.md" /%}
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
blurb: Issue a new Multi-purpose Token.
|
||||
seo:
|
||||
description: Define the properties of a new Multi-Purpose Token (MPT).
|
||||
labels:
|
||||
- Multi-purpose Tokens, MPTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# MPTokenIssuanceCreate
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
blurb: Remove a Multi-purpose Token from the ledger.
|
||||
seo:
|
||||
description: Delete a Multi-Purpose Token definition.
|
||||
labels:
|
||||
- Multi-purpose Tokens, MPTs
|
||||
status: not_enabled
|
||||
---
|
||||
# MPTokenIssuanceDestroy
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/MPTokenIssuanceDestroy.cpp "Source")
|
||||
|
||||
@@ -1,7 +1,9 @@
|
||||
---
|
||||
blurb: Set mutable properties for an MPT.
|
||||
seo:
|
||||
description: Set mutable properties of a Multi-Purpose Token definition.
|
||||
labels:
|
||||
- Multi-purpose Tokens, MPTs
|
||||
- Multi-purpose Tokens, MPTs
|
||||
status: not_enabled
|
||||
---
|
||||
# MPTokenIssuanceSet
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/MPTokenIssuanceSet.cpp "Source")
|
||||
@@ -14,15 +16,13 @@ _(Requires the [MPTokensV1 amendment][] {% not-enabled /%}.)_
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "MPTokenIssuanceSet",
|
||||
"Fee": "10",
|
||||
"MPTokenIssuanceID": "00070C4495F14B0E44F78A264E41713C64B5F89242540EE255534400000000000000",
|
||||
"Flags": 1
|
||||
"TransactionType": "MPTokenIssuanceSet",
|
||||
"Fee": "10",
|
||||
"MPTokenIssuanceID": "00070C4495F14B0E44F78A264E41713C64B5F89242540EE255534400000000000000",
|
||||
"Flags": 1
|
||||
}
|
||||
```
|
||||
|
||||
<!-- ## MPTokenIssuanceSet Fields -->
|
||||
|
||||
{% raw-partial file="/docs/_snippets/tx-fields-intro.md" /%}
|
||||
|
||||
| Field | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: nftokenburn.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Use TokenBurn to permanently destroy NFTs.
|
||||
description: Permanently destroy an NFT.
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
---
|
||||
html: nftokencanceloffer.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Cancel existing token offers to buy or sell an NFToken.
|
||||
description: Cancel offers to buy or sell an NFT.
|
||||
labels:
|
||||
- NFTs, Non-fungible Tokens
|
||||
---
|
||||
|
||||
@@ -1,10 +1,8 @@
|
||||
---
|
||||
html: nftokencreateoffer.html
|
||||
parent: transaction-types.html
|
||||
seo:
|
||||
description: Create an offer to buy or sell NFTs.
|
||||
description: Create an offer to buy or sell an NFT.
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
# NFTokenCreateOffer
|
||||
[[Source]](https://github.com/XRPLF/rippled/blob/master/src/xrpld/app/tx/detail/NFTokenCreateOffer.cpp "Source")
|
||||
@@ -19,11 +17,11 @@ _(Added by the [NonFungibleTokensV1_1 amendment][].)_
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "NFTokenCreateOffer",
|
||||
"Account": "rs8jBmmfpwgmrSPgwMsh7CvKRmRt1JTVSX",
|
||||
"NFTokenID": "000100001E962F495F07A990F4ED55ACCFEEF365DBAA76B6A048C0A200000007",
|
||||
"Amount": "1000000",
|
||||
"Flags": 1
|
||||
"TransactionType": "NFTokenCreateOffer",
|
||||
"Account": "rs8jBmmfpwgmrSPgwMsh7CvKRmRt1JTVSX",
|
||||
"NFTokenID": "000100001E962F495F07A990F4ED55ACCFEEF365DBAA76B6A048C0A200000007",
|
||||
"Amount": "1000000",
|
||||
"Flags": 1
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user