mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-23 05:05:50 +00:00
Information Architecture v3 (#1934)
* Update look up escrows to remove redundant info about lookups via sender/destination. Modify cancel expired escrow for brevity. * Cancel escrow: fix notes * Add draft of updated cancel-escrow.js. * Update intro to escrows. * Add Escrow Tutorial * Minor corrections * Fix headings, add HTML * Update escrow docs This commit re-createsf205a92db2with some adjustments: - Omit the accidentally-created dir full of junk - Fix some typos and one mistake in the Escrow limitations section - Add a table to the EscrowCreate ref to clarify valid combos of fields. * Concept info from send-a-time-held-escrow added to escrow.md * IA: Move "Consensus Network" files This re-creates some work from the original commit56fffe0b9f* Rewrite escrows article (re-created) This commit re-creates relevant work from the following commits:9a4a588f2bUpdate escrow.md context infoe1b017dc83Remove references to using escrow for interledger payments. * IA: Move "XRPL servers" files This re-creates some work from original commit7611979abf* IA: move "production readiness" files. Re-creates work from the following commit:692438693aMove tutorials to concepts * New intro articles Original commit:56fffe0b9f* IA: Reorg account concepts Re-creates some work from original commit56fffe0b9f* IA: reorg transaction concepts Original commits:9d4eff9940WIP - reorg accounts7611979abfWIP dir. reorg * IA: reorg consensus concepts Original commit:56fffe0b9f* IA: Reorg ledger docs Original commit:56fffe0b9f- Rephrased some details of the section * IA: rename issuing/operational addresses page Original commit:56fffe0b9f* Moving use cases * Fleshing out Use Cases Note, the dactyl-config.yml file has not been fully updated. * Clean up checks conceptual info. * Remove redundant checks use case section Original commit:3c29e9c05e* IA: move Dex under tokens Original commit:d08b3ba7d7* Touch up stablecoin issuer use case (#1856) * Consolidate stablecoin use case * Stablecoin issuer: cleanup progress through sending * Stablecoin issuer: reorg second half (Note: the dactyl-config.yml is not fully reconciled yet) * Move rippled and clio tutorials into infrastructure * Remove link to checks amendement. * Add note to account_objects.md about commandline interface type field. * Merge expiration case with lifecycle section. * Interoperability Use Cases * Add graphics to intro * Move escrow use cases to dedicated page. * Update use case page intros and corresponding concept info. * Clarify meaning of direct XRP payments. * Intro link updates * Payment use cases * Remove some unnecessary links in transactions section Original commit:e6fcf4a4dc* Link cleanup in Tokens section Original commit:9588dd5e70* Touch up 'Configure Peering' section Original commit:fc8f0990b8* Clean up links in accounts section Original commit:3da5fde7a8* Add NFT mkt use case * p2p payments: edits to Wallets * Clean up payments use cases * Refine history description * IA: use case cleanup * IA: reconcile servers, ledgers sections * IA: reconcile payment types, tx, tokens * IA: reconcile accounts section * IA: reconcile infra * IA: Fix most broken links * Full Docs Index: omit from sidebar * IA: fix up most broken links * fix Absolute path link to internal content * Quick updates to Software Ecosystem * Remove some absolute links to internal resources * Fix remaining broken links in JA target * Contributing: tweak formatting * Tutorials: fix some minor issues * remove interop use cases * remove intro image and personal references to dennis * alphabetize-transaction-nav * Remove unused files * Add QS escrow tutorials * IA: move ledgers, consensus protocol files around * IA: update nav for new page hierarchy * reordering of topics under new networks and servers top-nav * Move "Naming" to "What is XRP?" * Update dactyl-config.yml Remove xrp.md from the TOC. * Update list-xrp-as-an-exchange.md Update link to what-is-xrp * Update list-xrp-as-an-exchange.ja.md Change link to what-is-xrp * Update currency-formats.md Change link to what-is-xrp * Update currency-formats.ja.md Change link to what-is-xrp * Update cancel-an-expired-escrow.md Change link to what-is-xrp * Update paymentchannelfund.md Change link to what-is-xml * Update look-up-escrows.md Change link to what-is-xrp * Update tokens.md change link to what-is-xrp * Update use-payment-channels.md * Update send-a-time-held-escrow.md Update link to what-is-xml * fix broken links * Update parallel-networks.md Change link to what-is-xml * Update parallel-networks.ja.md * Update invariant-checking.md Remove link to xrp.html * Update invariant-checking.ja.md Remove link to xrp.html * Update transaction-cost.md Change link to what-is-xrp * Update transaction-cost.ja.md Change link to what-is-xrp * Update send-a-conditionally-held-escrow.md Change link to what-is-xrp * Update stablecoin-issuer.md Change link to what-is-xrp * Update tokens.ja.md Change link to what-is-xml * Update autobridging.ja.md Change link to what-is-xrp * Update currency-formats.md update text * reorganize infrastructure nav section * Update currency-formats.md Try removing link altogether. * Update currency-formats.ja.md Remove link to what-is-xrp.html * move commandline usage topic to infrastructure * initial intro rewrite * minor update to language * IA.v3: rm Production Readiness * Delete xrp.md * Update xrp link in snippet * Add redirect for old xrp.html URL * Small edits to 'What is XRP?' article * Add missing imgs * XRP - copy edit per @DennisDawson * restructure tutorials nav and pages * fix broken links * more broken link fixes * Algo trading: 1st draft * Algo trading: notes on taxes * Algo trading: edits per review * algo trading: fix broken link * Ledger structure: rewrite for accuracy and clarity * Update links to removed 'tree format' header * Ledger Structure: Update diagrams * Re-gen CSS for ledger structure changes * Ledger structure: edits per review * IA.v3: fix broken NFT links introduced by rebase * Desktop Wallet (py): update little stuff * Update some capacity/storage details * contribute doc nav update * fix image link in create diagram page * IAv3: Fix 'Ledgers' blurb * Update full history requirements with details from community members * add reviewer suggestions * Edits per @trippled review * Apply suggestions from peer review Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> * FH: reword file size limit note per review * Update software ecosystem * updates per review * Minor tweaks to graphics * fixTypos * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Update content/concepts/introduction/software-ecosystem.md Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * [JA] update AccountDelete cost * custom transactors doc * add doc to dactyl config * [JA] fix NonFungibleTokensV1_1 amendment status * [JA] update NFTokenOffer page * Remove old, unused XRP article (#2039) * add reviewer suggestions * Add tooling to check for file/nav consistency - From the repo top, run tool/check_file_consistency.py to look for Markdown files that exist in the "content/" directory but aren't used in the documentation. - New "enforce_filenames" filter prints a warning to console when building, if a file's path and filename don't match expectations based on its place in the nav and top heading. * File consistency checker: correctly handle filenames starting in _ * Remove unused old 'get started' and associated code * Create Resources section & reorg some files - Rename some files/folders based on their place in the nav - Move a bunch of non-documentation stuff, and docs on contributing code and/or docs to the new "Resources" section. - Known issue: nav spills into a second row on page widths between 993px-1110px. To be fixed in a later CSS update, maybe along with making the Resources dropdown multi-column. * Fix #2078 code tab bug CSS not built yet, to reduce merge conflicts. Won't have any effect until that happens. * fix Transaction JSON * [JA] translate contributing contents * fix contributing-to-documentation parent * fix contribute-code blurb * Top nav: add cols for Resources, fix broken links * CSS: fix top nav overflows * Fix broken link from redirect not in JA target * Top nav: add Infra to article types * Update contrib info & rename intro file * [ja] Update link to suggested first page to translate * [ja] fix contribute docs organization * Run private network with docker tutorial (#2065) * [NO-ISSUE] Run private network with docker tutorial Adds a tutorial page in the Infrastructure section on how to run a private XRPL network with Docker. Please let me know if you think this is a useful page to include for developers, whether the steps are clear or not, and if you have suggestions on what can be added to it. * Add minor link fixes and Japanese target * Apply suggestions from code review Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * Add link to ripple-docker-testnet setup scripts in See Also section * Update repo URL --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> * add intro gfx (#2036) * add intro gfx * Move graphic up * Update some graphics with their revised versions * Add updated version of the custodial vs non-custodial graphic --------- Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com> * Update to reflect current UNL publishers * [ja] update contributing Co-authored-by: tequ <git@tequ.dev> * Incorporate feedback on "What is XRP" page. (#2099) * Add trademark info for XRP * Revert section to previous state * Fix broken link (#2101) --------- Co-authored-by: Oliver Eggert <oeggert@ripple.com> Co-authored-by: ddawson <dennis.s.dawson@gmail.com> Co-authored-by: Maria Shodunke <mshodunke@ripple.com> Co-authored-by: tequ <git@tequ.dev> Co-authored-by: oeggert <117319296+oeggert@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <amarantha-k@users.noreply.github.com> Co-authored-by: develoQ <develoQ.jp@gmail.com> Co-authored-by: Maria Shodunke <maria-robobug@users.noreply.github.com> Co-authored-by: Amarantha Kulkarni <akulkarni@ripple.com>
This commit is contained in:
Rome Reginelli
53
content/use-cases/payments/peer-to-peer-payments-uc.md
Normal file
53
content/use-cases/payments/peer-to-peer-payments-uc.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
html: peer-to-peer-payments-uc.html
|
||||
parent: payments-uc.html
|
||||
blurb: Use the XRP Ledger to handle your day-to-day payments without a third party.
|
||||
labels:
|
||||
- Transactions
|
||||
---
|
||||
# Peer-to-Peer Payments
|
||||
|
||||
The XRP Ledger provides an efficient and borderless solution to handling payments. Unlike traditional payment methods, you don't need a financial institution to hold your assets and transfer value. If you have access to the internet, you can make direct payments on the XRP Ledger as easily as handing someone cash. Whether between friends, or a buyer and merchant, the XRP Ledger enables you to handle direct (peer-to-peer) payments quickly and with low network fees.
|
||||
|
||||
|
||||
## Wallets
|
||||
|
||||
Before jumping into using the XRP Ledger to handle direct payments, you should settle on a crypto wallet to use. Crypto wallets make it easier to interact with the ledger and manage your funds; there are many to choose from, depending on your needs, and you can even create your own. See: [Crypto Wallets](crypto-wallets.html).
|
||||
|
||||
|
||||
## Account Creation
|
||||
|
||||
Before creating an account, you must decide which XRP Ledger network to use. There are multiple networks for different use cases, but native XRP transactions only happen on `Mainnet`. See: [Parallel Networks](parallel-networks.html)
|
||||
|
||||
Most publicly available wallets offer the ability to create an account for you and can generate a public and private key. If they don't, you can create an account yourself, so long as it's mathematically valid. See: [Creating Accounts](accounts.html#creating-accounts).
|
||||
|
||||
|
||||
## Fund Your Account
|
||||
|
||||
An account isn't active on the XRP Ledger until it's been funded and meets the minimum reserve requiremen. See: [Reserves](reserves.html).
|
||||
|
||||
If the wallet you're using doesn't offer the option to purchase XRP, you'll need to find a third party exchange to do so and send it to your account. Alternatively, someone you know can also send XRP to your account. See: [Payment](payment.html).
|
||||
|
||||
After funding your account, you should verify on the XRP Ledger itself that your account exists and is funded. You can do this with the:
|
||||
|
||||
- [XRPL Explorer](https://livenet.xrpl.org/).
|
||||
- [`account_info` command](account_info.html).
|
||||
|
||||
|
||||
## Handling Payments
|
||||
|
||||
|
||||
### Direct XRP Payments
|
||||
|
||||
XRP payments are the simplest way to pay someone on the XRP Ledger. You can use checks or escrows, but these require multiple transactions to complete. A direct XRP payment require only one transaction, making this option great for day-to-day activity. If you're a merchant handling large volumes of transactions, this may be the right choice for you due to it being quick, simple, and having the lowest fees. See: [Direct XRP Payments](direct-xrp-payments.html).
|
||||
|
||||
To make a direct XRP payment work, you only need to know the address of the receiver.
|
||||
|
||||
|
||||
### Cross-Currency Payments
|
||||
|
||||
The XRP Ledger enables you to make cross-currency payments of XRP and tokens. Cross-currency payments within the XRP Ledger are fully atomic, meaning the payment fully executes or no part of the payment executes at all.
|
||||
|
||||
Cross-currency payments deliver a fixed amount to their destination, but the sender can have a variable fee cost, depending on the paths taken to make the transaction work on the network. See: [Cross-currency Payments](cross-currency-payments.html).
|
||||
|
||||
This is a great payment option if you or the receiver prefer a specific token instead of the native XRP currency.
|
||||
70
content/use-cases/payments/restricting-deposits-uc.md
Normal file
70
content/use-cases/payments/restricting-deposits-uc.md
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
html: restricting-deposits-uc.html
|
||||
parent: payments-uc.html
|
||||
blurb: Checks enable users to create deferred payments similar to personal paper checks.
|
||||
labels:
|
||||
- Transactions
|
||||
---
|
||||
# Restricting Deposits
|
||||
|
||||
To comply with banking regulations, financial institutions must provide documentation about the sources of funds they receive. These regulations seek to prevent illicit activity by requiring institutions to track the source and destination of all payments they process. On the XRP Ledger, payments can be sent and received without any interaction from the receiver. This default behavior can be problematic, but you can enable deposit authorization so you only receive funds you explicitly approve.
|
||||
|
||||
Accounts with deposit authorization enabled can only receive funds through:
|
||||
|
||||
- Preauthorized Accounts
|
||||
- Checks
|
||||
- Escrow
|
||||
<!-- - Payment Channels -->
|
||||
|
||||
|
||||
## Set Up Deposit Authorization
|
||||
|
||||
To enable deposit authorization, use the `AccountSet` transaction to set the `asfDepositAuth` flag. See: [Deposit Authorization](depositauth.html).
|
||||
|
||||
## Preauthorized Accounts
|
||||
|
||||
When you enable deposit authorization, your account blocks all incoming transactions unless you specifically _okay_ them. This may be what you're looking for, but it can be cumbersome if you're working with high volumes of transactions. If you have trusted vendors or accounts, you can preauthorize them so that you don't have to approve transactions from them.
|
||||
|
||||
Preauthorized accounts are currency-agnostic, meaning you can't specify which currencies to authorize. It's all or nothing.
|
||||
|
||||
See: [DepositPreauth](depositpreauth.html).
|
||||
|
||||
|
||||
## Accepting Deposits from Unauthorized Accounts
|
||||
|
||||
You can still work with unauthorized accounts, even after enabling deposit authorization. There are several payment methods that enable you to do so.
|
||||
|
||||
|
||||
### Checks
|
||||
|
||||
Checks are a straightforward, familiar, and flexible way to transfer funds when deposit authorization is enabled. Checks are a two-part payment method. The sender creates the check, and then the receiver has to cash the check. Cashing the check is your explicit approval of the deposit.
|
||||
|
||||
While this method is the simplest, it doesn't guarantee the funds. Checks are deferred payments, meaning funds aren't moved until the moment you try to cash the check. It's possible for the sending account to not have the necessary funds at the time the check is cashed, which can cause delays or other headaches, depending on your business.
|
||||
|
||||
See: [Use Checks](use-checks.html).
|
||||
|
||||
|
||||
### Escrow
|
||||
|
||||
If you require a guarantee of funds at the time of deposit, another option is to have deposits made with an escrow. Like regular escrows, a sender sets aside funds on the ledger, effectively locking them up until certain conditions are met. This guarantees the funds will be available when you close the escrow to release the funds.
|
||||
|
||||
See: [Use Escrows](use-escrows.html).
|
||||
|
||||
|
||||
<!-- Need a better understanding of Payment Channels use cases.
|
||||
|
||||
### Payment Channels
|
||||
|
||||
Payment Channels are an advanced feature for sending asynchronous XRP payments that can be divided into very small increments and settled later.
|
||||
|
||||
The XRP for a payment channel is set aside temporarily. The sender creates _Claims_ against the channel, which the recipient verifies without sending an XRP Ledger transaction or waiting for a new ledger version to be approved by consensus. (This is an _asynchronous_ process because it happens separate from the usual pattern of getting transactions approved by consensus.) At any time, the recipient can _redeem_ a Claim to receive an amount of XRP authorized by that Claim. Settling a Claim like this uses a standard XRP Ledger transaction, as part of the usual consensus process. This single transaction can encompass any number of transactions guaranteed by smaller Claims.
|
||||
|
||||
Because Claims can be verified individually but settled in bulk later, payment channels make it possible to conduct transactions at a rate only limited by the participants' ability to create and verify the digital signatures of those Claims. This limit is primarily based on the speed of the participants' hardware and the complexity of the signature algorithms. For maximum speed, use Ed25519 signatures, which are faster than the XRP Ledger's default secp256k1 ECDSA signatures. Research has demonstrated the ability to create over Ed25519 100,000 signatures per second and to verify over [70,000 per second](https://ed25519.cr.yp.to/ed25519-20110926.pdf) on commodity hardware in 2011.
|
||||
|
||||
Learn about [Payment Channels](payment-channels.html) on the XRP Ledger.
|
||||
|
||||
you may have circumstances where you want to go into contract with a contractor, but don't know the exact amount. This is common in situations such as home improvement projects where an estimate can be provided, but unforeseen circumstances can increase the final amount due. In these situations you can create a payment channel, which allocates (currently only XRP) to a payment channel. This amount would be the estimate the contractor gives you and can serve as their budget for the project. Each item they require payment for, you would submit a claim to the payment channel.
|
||||
|
||||
Repeating this process, you would eventually settle on the final amount due, where the contractor (payee) claims the final amount from the payment channel. This method of payment serves as a great way to track invdividual items payed for in large projects.
|
||||
|
||||
-->
|
||||
48
content/use-cases/payments/smart-contracts-uc.md
Normal file
48
content/use-cases/payments/smart-contracts-uc.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
html: escrow-uc.html
|
||||
parent: payments-uc.html
|
||||
blurb: Transactions allow accounts to modify the XRP Ledger.
|
||||
labels:
|
||||
- Ledgers
|
||||
---
|
||||
# Smart Contracts
|
||||
|
||||
A smart contract is a blockchain-based program that handles the conditions and executes the fulfillment of an agreement between two parties. Broken into its simplest components, a smart contract _does_ something if _something else_ happens.
|
||||
|
||||
The benefit of encoding a smart contract into a blockchain is that it enables contracts to be securely carried out without traditional third-parties, like financial or legal institutions. Instead, the contract is supervised by the distributed, decentralized network of computers that run the blockchain.
|
||||
|
||||
This enables you to transact with anybody without having to trust they'll uphold their end of a deal; the conditions of the smart contract will force them to.
|
||||
|
||||
|
||||
## Conditionally Held Escrow
|
||||
|
||||
Smart contracts on the XRP Ledger work through conditionally held escrows.
|
||||
|
||||
|
||||
### Create the Escrow
|
||||
|
||||
A conditionally held escrow is similar to a normal escrow: you set aside funds with an escrow to guarantee funds are available to a recipient. The difference is that a conditionally held escrow on the ledger has a `Condition` attached to it, which serves as a lock on the funds. The ledger won't release those funds until an `EscrowFinish` transaction is submitted with the corresponding `Fulfillment` field. The `Condition` and `Fulfillment` fields can be viewed as a lock and key on an escrow.
|
||||
|
||||
See: [`EscrowCreate`](escrowcreate.html).
|
||||
|
||||
|
||||
### Establish the Oracle
|
||||
|
||||
An oracle is a neutral third-party agent that can verify real-world events to either fulfill or invalidate a smart contract. Oracles are vital to making conditional escrows work by generating the condition and fulfillment, and keeping the fulfillment secret until the terms of the contract are met.
|
||||
|
||||
In the context of smart contracts, an oracle will most likely be software that can read real-world data. The oracle would be programmed with the terms of the contract between parties and generate the condition and fulfillment hex values.
|
||||
|
||||
The oracle gives the condition hex value to the escrow creator, enabling them to set up the escrow initially.
|
||||
|
||||
After the oracle's programming detects the conditions are met, it gives the fulfillment hex value to the escrow recipient. It does nothing else after this point, such as finishing the escrow. The recipient of the escrow would most likely finish the escrow.
|
||||
|
||||
See: [Generate a condition and fulfillment](send-a-conditionally-held-escrow.html#1-generate-condition-and-fulfillment).
|
||||
|
||||
## Examples
|
||||
|
||||
Smart contracts have a wide range of uses, but some uses include:
|
||||
|
||||
1. Handling payments on large-value items you would otherwise need lawyers for, such as mortgages.
|
||||
2. Supply-chain management to ensure funds are delivered upon receipt of goods.
|
||||
3. Automating certain kinds of insurance claims that can be verified by software.
|
||||
4. Ensuring payments are given for services rendered.
|
||||
Reference in New Issue
Block a user