ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-11-30 08:35:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

[DOC] e2g - restructure and content

Browse Source
This commit is contained in:
mDuo13
2014-12-18 13:24:50 -08:00
parent 8c35fa9f32
commit 7cbd38c5a3
1 changed files with 121 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

135
content/exchange_to_gateway.md
View File

@@ -27,15 +27,6 @@ The cold wallet should remain offline, and serves as the asset issuer. This mean
A hot wallet makes payments to the gateway's users in Ripple by sending them issuances created by the cold wallet. It also needs a trust line to the cold wallet. A gateway can use one or more "hot wallet" accounts, but each hot wallet has a limited balance of the gateway's issuances. If it is compromised, the gateway can only lose as much currency as the hot wallet holds. However, this means that the gateway must monitor the hot wallet's balance, so that it doesn't run out during ordinary operation.
### Trading on Ripple ###
After the issuances have been created in Ripple, they can be freely transferred and traded by Ripple users.
- Anyone can buy/sell EUR@ACME on Ripple
- including users who don't have ACME accounts (caveat: requireauth flag)
- Ripple users trading and sending EUR@ACME to one another requires no intervention by ACME
## Prior to Ripple Integration ##
Our example exchange, ACME, already accepts withdrawals and deposits from users using some existing system, and uses an internal accounting system to track how much balance each user has with the exchange. Such a system can be modeled simply like this:
@@ -122,27 +113,143 @@ In addition to the [requirements for making deposits possible](#deposit-requirem
- ACME must monitor its Ripple accounts for incoming payments.
- ACME must recognize the identities of users from the incoming payments.
- We recommend that ACME should bounce any unrecognized incoming payments back to their sender.
- Typically, the preferred method of recognizing incoming payments is through destination tags.
- Typically, the preferred method of recognizing incoming payments is through [destination tags](#destination-tags).
### Precautions ###
Processing withdrawals and bouncing incoming payments are both potentially risky processes, so a gateway should be sure to take care in implementing them. Additionally, gateways should avoid any potentially ambiguous situations when receiving customer funds. We recommend the following precautions:
Processing withdrawals and bouncing incoming payments are both potentially risky processes, so a gateway should be sure to take care in implementing them. We recommend the following precautions:
- Before processing a withdrawal, make sure you know the customer's identity. This is especially important because the users withdrawing from Ripple could be different than the ones depositing.
- Understand how [Partial Payments](#partial-payments) work, and correctly read the delivered amount.
- [Robustly monitor for incoming payments](#robustly-monitor-for-payments), and read the correct amount. Don't be deceived by Partial Payments.
- Proactively avoid ambiguous situations. We recommend the following:
- Enable the [`DisallowXRP` flag](#disallowxrp) for the cold wallet account and all hot wallet accounts, so users do not accidentally send you XRP.
- Enable the [`RequireDest` flag](#requiredest) for the cold wallet account and all hot wallet accounts, so users do not accidentally forget the destination tag on payments to make withdrawals.
- Enable the [`RequireAuth` flag](#requireauth) on all hot wallet accounts so they cannot create their own issuances.
# Trading on Ripple #
After the issuances have been created in Ripple, they can be freely transferred and traded by Ripple users.
- Anyone can buy/sell EUR@ACME on Ripple
- including users who don't have ACME accounts (caveat: requireauth flag)
- Ripple users trading and sending EUR@ACME to one another requires no intervention by ACME
<span class='draft-comment'>TODO: Elaborate on this section</span>
## Fees and Revenue Sources ##
There are several ways in which a gateway can seek to benefit financially from Ripple integration. These can include:
* Indirect revenue from value added. Ripple integration can provide valuable functionality for your customers that distinguishes your business from your competitors.
* Withdrawal and Deposit fees. It is typical for a gateway to charge a small fee (such as 1%) for the service of adding or removing money from Ripple. You have the power to determine the rate you credit people when they move money onto and off of Ripple through your gateway.
* Transfer fees. You can set a percentage fee to charge when Ripple users send each other issuances created by your account. This amount disappears from the Ripple ledger, decreasing your obligation each time your issuances change hands. See [TransferRate](#transferrate) for details.
# Technical Details #
## DisallowXRP ##
The DisallowXRP flag (`disallow_xrp` in Ripple-REST) is designed to discourage users from sending XRP to your account by accident. For accounts that are intended to process withdrawals, receiving XRP is undesirable because there is no way to "withdraw" XRP from the network.
However, the DisallowXRP flag is not strictly enforced, because doing so could allow accounts to become permanently unusable. Client applications should honor it, but it is intentionally possible to work around. We recommend enabling the DisallowXRP flag on all gateway hot and cold wallets.
The following is an example of a Ripple-REST request to enable the DisallowXRP flag:
Request:
```
POST https://api.ripple.com/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/settings?validated=true
{
"secret": "ssssssssssssssssssssssssssss",
"settings": {
"disallow_xrp": true
}
}
```
Response:
```
200 OK
{
"success": true,
"settings": {
"hash": "AC0F7D7735CDDC6D859D0EC4E96A571F71F7481750F4C6C975FC8075801A6FB5",
"ledger": "10560577",
"state": "validated",
"require_destination_tag": false,
"require_authorization": false,
"disallow_xrp": true
}
}
```
## RequireDest ##
The `RequireDest` flag (`require_destination_tag` in Ripple-REST) is designed to prevent users from sending payments to your account while accidentally forgetting the [destination tag](#destination-tags) that identifies who should be credited for the payment. When enabled, the Ripple Network rejects any payment to your account that does not specify a destination tag.
We recommend enabling the RequireDest flag on all gateway hot and cold wallets.
The following is an example of a Ripple-REST request to enable the RequireDest flag.
Request:
```
POST https://api.ripple.com/v1/accounts/rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn/settings?validated=true
{
"secret": "ssssssssssssssssssssssssssss",
"settings": {
"require_destination_tag": true
}
}
```
Response:
```
200 OK
{
"success": true,
"settings": {
"hash": "F3D2EE87D597BA50EA3A94027583110925E8BAAFE41511F937D65423B18BC2A3",
"ledger": "10560755",
"state": "validated",
"require_destination_tag": true,
"require_authorization": false,
"disallow_xrp": false
}
}
```
# Appendix #
## RequireAuth ##
TODO
## Robustly Monitoring for Payments ##
TODO
## Destination Tags ##
TODO
## Partial Payments ##
## TransferRate ##
TODO
## Bouncing Payments ##
TODO
## Setting Trust Lines in Ripple Trade ##
TODO
## Robust Transaction Submission ##
TODO