mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-04 11:55:50 +00:00
Compare commits
95 Commits
v2014-09-1
...
v2014-10-0
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
9c64b787ff | ||
|
|
07fd5ce872 | ||
|
|
af8f2ed50e | ||
|
|
092d715bfa | ||
|
|
63246c37c2 | ||
|
|
e1fc112df1 | ||
|
|
eb33c7e446 | ||
|
|
5bca4a1319 | ||
|
|
07a92022b3 | ||
|
|
ec74ec90cb | ||
|
|
2aa95a4023 | ||
|
|
fd0354f957 | ||
|
|
5e229a1138 | ||
|
|
723e70a5ea | ||
|
|
44c9340902 | ||
|
|
e4374c3214 | ||
|
|
844640f141 | ||
|
|
8fe388de6f | ||
|
|
7228faf419 | ||
|
|
dff1e04c18 | ||
|
|
c43c2f0915 | ||
|
|
d99b264cff | ||
|
|
e6f753aa72 | ||
|
|
b909e200fa | ||
|
|
10fa680688 | ||
|
|
b689061d89 | ||
|
|
8303508670 | ||
|
|
c7c7f30845 | ||
|
|
96164d68e2 | ||
|
|
3abd182ea8 | ||
|
|
a4a9b734f8 | ||
|
|
39f4a1cb08 | ||
|
|
7582184ea5 | ||
|
|
4e6adb1f34 | ||
|
|
71932be386 | ||
|
|
d79b84ed43 | ||
|
|
1aebd976ea | ||
|
|
2430809517 | ||
|
|
daf5bca353 | ||
|
|
bd99c824c7 | ||
|
|
e0f404ecd7 | ||
|
|
202e42b08d | ||
|
|
f01f9f529e | ||
|
|
c834cd8c16 | ||
|
|
2f040e0c28 | ||
|
|
937cb2e2bf | ||
|
|
37a23d499b | ||
|
|
0388898396 | ||
|
|
060c5ad755 | ||
|
|
8be084b979 | ||
|
|
8ae50b6597 | ||
|
|
c7986b3e45 | ||
|
|
a2a660fa32 | ||
|
|
05a5440f4f | ||
|
|
f3e518b25b | ||
|
|
746b072803 | ||
|
|
c67a310fc0 | ||
|
|
affd896fe3 | ||
|
|
3786fa21e0 | ||
|
|
fb47986f3b | ||
|
|
50af081193 | ||
|
|
2f27bab67b | ||
|
|
73a551702f | ||
|
|
feb3074e8f | ||
|
|
f48045856a | ||
|
|
64fdde5d4b | ||
|
|
a6f06c399e | ||
|
|
fcabac30da | ||
|
|
aab362a00a | ||
|
|
9588aa68aa | ||
|
|
f4c222b006 | ||
|
|
eea601176c | ||
|
|
d6b6405543 | ||
|
|
b2fa86afc5 | ||
|
|
fd4be275ab | ||
|
|
58d0f2828f | ||
|
|
ddb285245a | ||
|
|
a46a2a5a05 | ||
|
|
39a9f38e8f | ||
|
|
6aec472374 | ||
|
|
cc39b76a6e | ||
|
|
fb5b310443 | ||
|
|
83014bff40 | ||
|
|
5c3a5190eb | ||
|
|
a74deb6a03 | ||
|
|
2922fc8b79 | ||
|
|
77f5fd47b1 | ||
|
|
6cb9cc807e | ||
|
|
7a6f91f078 | ||
|
|
d57e301cd7 | ||
|
|
52a92e6a9e | ||
|
|
a44af459c2 | ||
|
|
953a7f54c7 | ||
|
|
2ac4748ae4 | ||
|
|
017c9a2ff4 |
BIN
assets/img/rippleThrobber.png
Normal file
BIN
assets/img/rippleThrobber.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 734 B |
@@ -99,7 +99,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -157,6 +163,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -87,7 +87,7 @@ h2 {
|
||||
margin:0;
|
||||
padding:0;
|
||||
}
|
||||
#response {
|
||||
#response, #response_body {
|
||||
min-height:100px;
|
||||
border-top-left-radius:0px !important;
|
||||
border-top-right-radius:0px !important;
|
||||
@@ -98,7 +98,7 @@ h2 {
|
||||
#output {
|
||||
width: 60%;
|
||||
}
|
||||
p, h3 {
|
||||
h3 {
|
||||
margin:16px 0;
|
||||
font-family:'open sans';
|
||||
font-weight:300;
|
||||
@@ -150,7 +150,7 @@ p, h3 {
|
||||
}
|
||||
|
||||
#request_options > div {
|
||||
float:right;
|
||||
/* float:right;
|
||||
margin:0;
|
||||
width:200px;
|
||||
color:#fff;
|
||||
@@ -161,23 +161,25 @@ p, h3 {
|
||||
background-image:linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), linear-gradient(top, rgba(255,255,255,0.15), transparent);
|
||||
background-image:-webkit-linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), -webkit-linear-gradient(top, rgba(255,255,255,0.15), transparent);
|
||||
background-image:-moz-linear-gradient(283deg, rgba(255,255,255,0.1) 50%, transparent 55%), -moz-linear-gradient(top, rgba(255,255,255,0.15), transparent);
|
||||
*/
|
||||
|
||||
|
||||
border-radius:4px;
|
||||
border-bottom:1px solid #fff;
|
||||
background-color: #346AA9;
|
||||
font-weight:300;
|
||||
font-size:16px;
|
||||
/* line-height:50px; */
|
||||
/* line-height:50px;
|
||||
text-align:center;
|
||||
cursor:default;
|
||||
|
||||
user-select:none;
|
||||
-webkit-user-select:none;
|
||||
-moz-user-select:none;
|
||||
*/
|
||||
margin-top: 5px;
|
||||
}
|
||||
#request_button {
|
||||
background:#3a87ad;
|
||||
background-color: #346AA9;
|
||||
}
|
||||
#request_button.depressed {
|
||||
background:#295F7A;
|
||||
@@ -264,8 +266,9 @@ ul.toolbar li {
|
||||
|
||||
|
||||
/* JSON syntax highlighting */
|
||||
#request,
|
||||
#response {
|
||||
#request, #request_body,
|
||||
#response, #response_body,
|
||||
#rest_url_wrapper {
|
||||
font-family:'inconsolata',monospace;
|
||||
font-size:13px;
|
||||
line-height:20px;
|
||||
@@ -289,9 +292,9 @@ ul.toolbar li {
|
||||
border:1px dotted #3a87ad;
|
||||
}
|
||||
|
||||
#selected_command {
|
||||
/*#selected_command {
|
||||
margin-top:-32px;
|
||||
}
|
||||
}*/
|
||||
|
||||
#selected_command a {
|
||||
text-decoration:none;
|
||||
@@ -343,3 +346,112 @@ span.cm-number {
|
||||
span.cm-atom {
|
||||
color:#66327C !important;
|
||||
}
|
||||
|
||||
/* Progress spinner animation */
|
||||
@keyframes rotating {
|
||||
from {
|
||||
transform: rotate(0deg);
|
||||
-ms-transform: rotate(0deg);
|
||||
-moz-transform: rotate(0deg);
|
||||
-webkit-transform: rotate(0deg);
|
||||
-o-transform: rotate(0deg);
|
||||
}
|
||||
to {
|
||||
transform: rotate(360deg);
|
||||
-ms-transform: rotate(360deg);
|
||||
-moz-transform: rotate(360deg);
|
||||
-webkit-transform: rotate(360deg);
|
||||
-o-transform: rotate(360deg);
|
||||
}
|
||||
}
|
||||
|
||||
@-webkit-keyframes rotating /* Safari and Chrome */ {
|
||||
from {
|
||||
transform: rotate(0deg);
|
||||
-ms-transform: rotate(0deg);
|
||||
-moz-transform: rotate(0deg);
|
||||
-webkit-transform: rotate(0deg);
|
||||
-o-transform: rotate(0deg);
|
||||
}
|
||||
to {
|
||||
transform: rotate(360deg);
|
||||
-ms-transform: rotate(360deg);
|
||||
-moz-transform: rotate(360deg);
|
||||
-webkit-transform: rotate(360deg);
|
||||
-o-transform: rotate(360deg);
|
||||
}
|
||||
}
|
||||
|
||||
.loader {
|
||||
-webkit-animation: rotating 1s linear infinite;
|
||||
-moz-animation: rotating 1s linear infinite;
|
||||
-ms-animation: rotating 1s linear infinite;
|
||||
-o-animation: rotating 1s linear infinite;
|
||||
animation: rotating 1s linear infinite;
|
||||
width: 25px;height:25px;
|
||||
}
|
||||
|
||||
|
||||
/* Rest-tool-specific stuff */
|
||||
|
||||
#rest_method {
|
||||
display: inline-block;
|
||||
padding: 6px;
|
||||
vertical-align: middle;
|
||||
border: 1px dotted #aaa;
|
||||
border-radius: 4px;
|
||||
-moz-border-radius: 4px;
|
||||
-webkit-border-radius: 4px;
|
||||
margin-bottom: 3px;
|
||||
background-color: #c7254e;
|
||||
color: white;
|
||||
appearance: none;
|
||||
-moz-appearance: none;
|
||||
}
|
||||
|
||||
#rest_url_wrapper {
|
||||
font-family: sans-serif;
|
||||
display: inline-block;
|
||||
text-indent: -2em;
|
||||
padding-left: 2.5em;
|
||||
}
|
||||
|
||||
#rest_url {
|
||||
width: auto;
|
||||
border: 0;
|
||||
background: none;
|
||||
font-size:13px;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
#rest_url .editable {
|
||||
font-weight: bold;
|
||||
font-family:'inconsolata',monospace;
|
||||
border-width: 0 0px 1px 0;
|
||||
border-style: dotted;
|
||||
border-color: #aaa;
|
||||
min-width: 5em;
|
||||
background: none;
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
#rest_url .non_editable {
|
||||
vertical-align: top;
|
||||
}
|
||||
|
||||
#rest_url_wrapper p {
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
#rest_url div {
|
||||
display: inline-block;
|
||||
}
|
||||
|
||||
#rest_url input {
|
||||
margin: 0 !important;
|
||||
}
|
||||
|
||||
#rest_url div label,
|
||||
#rest_url div input {
|
||||
display: block;
|
||||
}
|
||||
|
||||
@@ -15,6 +15,10 @@ a:hover {
|
||||
text-decoration: none;
|
||||
}
|
||||
|
||||
.resources a {
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
|
||||
/************
|
||||
jumbotron
|
||||
|
||||
@@ -158,6 +158,18 @@ color: #f09 !important;
|
||||
|
||||
}
|
||||
|
||||
|
||||
/************
|
||||
api tool(s)
|
||||
*********** */
|
||||
|
||||
body #online_state {
|
||||
position: absolute;
|
||||
right: 50px;
|
||||
top: 70px;
|
||||
}
|
||||
|
||||
|
||||
/************
|
||||
nav
|
||||
*********** */
|
||||
|
||||
@@ -152,7 +152,7 @@
|
||||
-moz-box-sizing: border-box;
|
||||
}
|
||||
body {
|
||||
color: #898788;
|
||||
color: #393738;
|
||||
font-family: 'Open Sans', sans-serif;
|
||||
}
|
||||
body .content-root {
|
||||
|
||||
@@ -1,14 +1,15 @@
|
||||
.draft-comment {background: #faa; border: 1px solid #d88; padding: 2px;}
|
||||
|
||||
td {border: 1px solid #DBDDE2 !important; padding: .2em;}
|
||||
table { border-collapse: collapse; clear: left; width: 550px}
|
||||
th { padding: .2em; }
|
||||
table { border-collapse: collapse; clear: left; }
|
||||
th { padding: .2em; font-weight: bold; }
|
||||
|
||||
body .content-root {
|
||||
background-color: #F3F6FB;
|
||||
box-shadow: 930px 0 #FFFFFF inset, 931px 0 #DFE2E7 inset, 940px 0 5px -10px rgba(0, 0, 0, 0.1) inset;
|
||||
}
|
||||
code { max-height: 14em; overflow: auto;}
|
||||
.content code { color: #111; }
|
||||
.expanded { max-height: none; overflow: none;}
|
||||
|
||||
.content h2, .menu a.level-2 {
|
||||
|
||||
@@ -125,7 +125,6 @@ a {
|
||||
text-decoration: none;
|
||||
}
|
||||
a:hover {
|
||||
color: #228a8a;
|
||||
}
|
||||
/* ----------------------------------------------------------------------------
|
||||
* Content styling
|
||||
@@ -666,12 +665,8 @@ a.big.button {
|
||||
}
|
||||
a.big.button,
|
||||
a.big.button:visited {
|
||||
color: #2badad;
|
||||
text-decoration: none;
|
||||
}
|
||||
a.big.button:hover {
|
||||
background: #2badad;
|
||||
}
|
||||
a.big.button:hover,
|
||||
a.big.button:hover:visited {
|
||||
color: #fff;
|
||||
@@ -742,9 +737,6 @@ a.big.button:hover:visited {
|
||||
.menu a:visited {
|
||||
color: #2badad;
|
||||
}
|
||||
.menu a:hover {
|
||||
color: #228a8a;
|
||||
}
|
||||
.menu a.level-1 {
|
||||
font-family: montserrat, sans-serif;
|
||||
text-transform: uppercase;
|
||||
|
||||
@@ -90,7 +90,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -133,6 +139,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -77,7 +77,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -423,6 +429,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
11
index.html
11
index.html
@@ -74,7 +74,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -193,6 +199,7 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://github.com/ripple/rippled"><i class="fa fa-code"></i> Source </a></li>
|
||||
<li><a href="https://www.bountysource.com/trackers/304896-rippled"><i class="fa fa-dot-circle-o"></i> Bounties </a></li>
|
||||
<li><a href="consensus-whitepaper.html"><i class="fa fa-file"></i> Consensus Whitepaper </a></li>
|
||||
<li><a href="transactions.html"><i class="fa fa-cubes"></i> Transaction Format </a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
@@ -225,6 +232,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -15,6 +15,7 @@
|
||||
var request = $(command_wrapper).find('#request');
|
||||
var status = $(command_wrapper).find('#status');
|
||||
var info = $(command_wrapper).find('#info');
|
||||
var spinner = $(".loader");
|
||||
|
||||
var remote = new ripple.Remote({
|
||||
trusted: true,
|
||||
@@ -339,6 +340,7 @@
|
||||
if (is_response && parsed.id === id._c) {
|
||||
if (!WAITING) return;
|
||||
else WAITING = false;
|
||||
spinner.hide();
|
||||
|
||||
var request_header = '<span class="request_name">'
|
||||
+ selected_request.name;
|
||||
@@ -591,6 +593,7 @@
|
||||
WAITING = true;
|
||||
selected_request.message = message;
|
||||
selected_request.t = Date.now();
|
||||
spinner.show();
|
||||
|
||||
request.message = prepare_request(message);
|
||||
request.request();
|
||||
|
||||
462
js/apitool-rest.js
Normal file
462
js/apitool-rest.js
Normal file
@@ -0,0 +1,462 @@
|
||||
var commands = $("#command_list li");
|
||||
var request_body = $("#request_body");
|
||||
var request_button = $("#request_button");
|
||||
var response_body = $("#response_body");
|
||||
var response_code = $("#rest_responsecode");
|
||||
var rest_url = $('#rest_url');
|
||||
var rest_method = $("#rest_method");
|
||||
var selected_command = $("#selected_command");
|
||||
var spinner = $(".loader");
|
||||
var reminders = $("#rest_url_wrapper .rest_reminders");
|
||||
var test_warning = $("#test_warning");
|
||||
|
||||
var GET = "GET";
|
||||
var POST = "POST";
|
||||
var PUT = "PUT";
|
||||
var DELETE = "DELETE";
|
||||
var URL_BASE = "https://api.ripple.com:443";
|
||||
|
||||
var DOC_BASE = "ripple-rest.html";
|
||||
|
||||
|
||||
function slugify(str) {
|
||||
str = str.replace(/^\s+|\s+$/g, ''); // trim
|
||||
str = str.toLowerCase();
|
||||
|
||||
// remove accents, swap ñ for n, etc
|
||||
var from = "àáäâèéëêìíïîòóöôùúüûñç·/_,:;";
|
||||
var to = "aaaaeeeeiiiioooouuuunc------";
|
||||
for (var i=0, l=from.length ; i<l ; i++) {
|
||||
str = str.replace(new RegExp(from.charAt(i), 'g'), to.charAt(i));
|
||||
}
|
||||
|
||||
str = str.replace(/[^a-z0-9 -]/g, '') // remove invalid chars
|
||||
.replace(/\s+/g, '-') // collapse whitespace and replace by -
|
||||
.replace(/-+/g, '-'); // collapse dashes
|
||||
|
||||
return str;
|
||||
}
|
||||
|
||||
//Build requests
|
||||
var requests = { };
|
||||
function Request(name, obj) {
|
||||
obj.name = name;
|
||||
requests[slugify(name)] = obj;
|
||||
|
||||
return obj;
|
||||
};
|
||||
|
||||
$(commands).click(function() {
|
||||
var cmd = slugify($(this).text().trim());
|
||||
|
||||
if (!requests[cmd]) return;
|
||||
|
||||
select_request(cmd, true);
|
||||
window.location.hash = cmd;
|
||||
|
||||
$(this).siblings().removeClass('selected');
|
||||
$(this).addClass('selected');
|
||||
});
|
||||
|
||||
|
||||
//---------- List of requests ------------------------//
|
||||
|
||||
var DEFAULT_ADDRESS_1 = "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn";
|
||||
var DEFAULT_ADDRESS_2 = "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX";
|
||||
var DEFAULT_HASH = "9D591B18EDDD34F0B6CF4223A2940AEA2C3CC778925BABF289E0011CD8FA056E";
|
||||
|
||||
Request('Generate Account', {
|
||||
method: GET,
|
||||
path: "/v1/accounts/new",
|
||||
description: 'Generate the keys for a potential new account',
|
||||
link: '#generate-account'
|
||||
});
|
||||
|
||||
Request('Get Account Balances', {
|
||||
method: GET,
|
||||
path: '/v1/accounts/{:address}/balances?{:query_params}',
|
||||
description: 'Retrieve the current balances for the given Ripple account',
|
||||
link: '#get-account-balances',
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1,
|
||||
"{:query_params}": "currency=USD"
|
||||
}
|
||||
});
|
||||
|
||||
Request('Get Account Settings', {
|
||||
method: GET,
|
||||
path: '/v1/accounts/{:address}/settings',
|
||||
description: 'Retrieve the current settings for the given Ripple account',
|
||||
link: '#get-account-settings',
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1
|
||||
}
|
||||
});
|
||||
|
||||
Request('Update Account Settings', {
|
||||
method: POST,
|
||||
path: '/v1/accounts/{:address}/settings',
|
||||
description: 'Change the current settings for the given Ripple account.',
|
||||
link: '#update-account-settings',
|
||||
test_only: true,
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1
|
||||
},
|
||||
body: {
|
||||
secret: "sssssssssssssssssssssssssssss",
|
||||
settings: {
|
||||
require_destination_tag: false,
|
||||
require_authorization: false,
|
||||
disallow_xrp: false,
|
||||
disable_master: false,
|
||||
email_hash: "98b4375e1d753e5b91627516f6d70977"
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
Request('Prepare Payment', {
|
||||
method: GET,
|
||||
path: '/v1/accounts/{:source_address}/payments/paths/{:destination_address}/{:amount}?{:query_params}',
|
||||
description: 'Change the current settings for the given Ripple account',
|
||||
link: '#prepare-payment',
|
||||
params: {
|
||||
"{:source_address}": DEFAULT_ADDRESS_1,
|
||||
"{:destination_address}": DEFAULT_ADDRESS_2,
|
||||
"{:amount}": "1+USD+rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"{:query_params}": "source_currencies=USD"
|
||||
}
|
||||
});
|
||||
|
||||
Request('Submit Payment', {
|
||||
method: POST,
|
||||
path: '/v1/payments',
|
||||
description: 'Send a prepared payment to the network.',
|
||||
link: '#submit-payment',
|
||||
test_only: true,
|
||||
body: {
|
||||
"secret": "sssssssssssssssssssssssssssss",
|
||||
"client_resource_id": "348170b9-16b9-4927-854d-7f9d4a2a692d",
|
||||
"payment": {
|
||||
"source_account": DEFAULT_ADDRESS_1,
|
||||
"source_tag": "",
|
||||
"source_amount": {
|
||||
"value": "1",
|
||||
"currency": "USD",
|
||||
"issuer": ""
|
||||
},
|
||||
"source_slippage": "0",
|
||||
"destination_account": DEFAULT_ADDRESS_2,
|
||||
"destination_tag": "",
|
||||
"destination_amount": {
|
||||
"value": "1",
|
||||
"currency": "USD",
|
||||
"issuer": DEFAULT_ADDRESS_1
|
||||
},
|
||||
"invoice_id": "",
|
||||
"paths": "[]",
|
||||
"partial_payment": false,
|
||||
"no_direct_ripple": false
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
Request("Confirm Payment", {
|
||||
method: GET,
|
||||
path: "/v1/accounts/{:address}/payments/{:hash}",
|
||||
description: "Retrieve details of a payment and its status",
|
||||
link: "#confirm-payment",
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1,
|
||||
"{:hash}": DEFAULT_HASH
|
||||
}
|
||||
});
|
||||
|
||||
Request("Get Payment History", {
|
||||
method: GET,
|
||||
path: "/v1/accounts/{:address}/payments?{:query_params}",
|
||||
description: "Browse through the history of payments sent and received by an account",
|
||||
link: "#get-payment-history",
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1,
|
||||
"{:query_params}": "direction=incoming&exclude_failed=true"
|
||||
}
|
||||
});
|
||||
|
||||
Request("Get Trustlines", {
|
||||
method: GET,
|
||||
path: "/v1/accounts/{:address}/trustlines?{:query_params}",
|
||||
description: "Check the status of one or more trustlines attached to an account",
|
||||
link: "#reviewing-trustlines",
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1,
|
||||
"{:query_params}": "currency=USD&counterparty=ra5nK24KXen9AHvsdFTKHSANinZseWnPcX"
|
||||
}
|
||||
});
|
||||
|
||||
Request("Grant Trustline", {
|
||||
method: POST,
|
||||
path: "/v1/accounts/{:address}/trustlines",
|
||||
description: "Add or modify a trustline from this account.",
|
||||
link: "#granting-a-trustline",
|
||||
test_only: true,
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1
|
||||
},
|
||||
body: {
|
||||
"secret": "sneThnzgBgxc3zXPG....",
|
||||
"trustline": {
|
||||
"limit": "110",
|
||||
"currency": "USD",
|
||||
"counterparty": "rMwjYedjc7qqtKYVLiAccJSmCwih4LnE2q",
|
||||
"allows_rippling": false
|
||||
}
|
||||
}
|
||||
});
|
||||
|
||||
Request("Check Notifications", {
|
||||
method: GET,
|
||||
path: "/v1/accounts/{:address}/notifications/{:hash}",
|
||||
description: "Browse through the history of payments sent and received by an account",
|
||||
link: "#checking-notifications",
|
||||
params: {
|
||||
"{:address}": DEFAULT_ADDRESS_1,
|
||||
"{:hash}": DEFAULT_HASH
|
||||
}
|
||||
});
|
||||
|
||||
Request("Check Connection", {
|
||||
method: GET,
|
||||
path: "/v1/server/connected",
|
||||
description: "Check whether the REST server is connected to a rippled server",
|
||||
link: "#check-connection-state"
|
||||
});
|
||||
|
||||
Request("Get Server Status", {
|
||||
method: GET,
|
||||
path: "/v1/server",
|
||||
description: "Retrieve information about the current status of the Ripple-REST server and the rippled server it is connected to",
|
||||
link: "#get-server-status"
|
||||
});
|
||||
|
||||
Request("Retrieve Ripple Transaction", {
|
||||
method: GET,
|
||||
path: "/v1/tx/{:hash}",
|
||||
description: "Retrieve a raw Ripple transaction",
|
||||
link: "#retrieve-ripple-transaction",
|
||||
params: {
|
||||
"{:hash}": DEFAULT_HASH
|
||||
}
|
||||
});
|
||||
|
||||
Request("Generate UUID", {
|
||||
method: GET,
|
||||
path: "/v1/uuid",
|
||||
description: "Create a universally-unique identifier (UUID) to use as the client resource ID for a payment",
|
||||
link: "#create-client-resource-id"
|
||||
});
|
||||
|
||||
//---------- End req. List ---------------------------//
|
||||
|
||||
var cm_request = CodeMirror(request_body.get(0), {
|
||||
mode: 'javascript',
|
||||
json: true,
|
||||
smartIndent: false
|
||||
});
|
||||
|
||||
var cm_response = CodeMirror(response_body.get(0), {
|
||||
mode: 'javascript',
|
||||
json: true,
|
||||
smartIndent: false,
|
||||
readOnly: true
|
||||
});
|
||||
|
||||
function update_method(el) {
|
||||
if (el === undefined) {
|
||||
method = $(this).val();
|
||||
} else {
|
||||
method = $(el).val();
|
||||
}
|
||||
|
||||
if (method == GET || method == DELETE) {
|
||||
request_body.hide();
|
||||
} else {
|
||||
request_body.show();
|
||||
cm_request.refresh();
|
||||
}
|
||||
}
|
||||
|
||||
function change_path(command) {
|
||||
rest_url.empty();
|
||||
reminders.html(" ");
|
||||
|
||||
var re = /(\{:[^}]+\})/g; // match stuff like {:address}
|
||||
params = command.path.split(re);
|
||||
|
||||
//console.log(params);
|
||||
for (i=0; i<params.length; i++) {
|
||||
if (params[i].match(/\{:[^}]+\}/) !== null) {
|
||||
if (command.params === undefined || command.params[params[i]] === undefined) {
|
||||
var default_val = params[i];
|
||||
} else {
|
||||
var default_val = command.params[params[i]];
|
||||
}
|
||||
//rest_url.append("<span class='editable' contenteditable='true' id='resturl_"+params[i]+"'>"+default_val+"</span>");
|
||||
|
||||
var new_div = $("<div>").appendTo(rest_url);
|
||||
var new_param = $("<input type='text' id='resturl_"+params[i]+"' value='"+default_val+"' class='editable' title='"+params[i]+"' />").appendTo(new_div);
|
||||
new_param.autosizeInput({"space": 0});
|
||||
//var new_label = $("<label class='reminder' for='resturl_"+params[i]+"'>"+params[i]+"</label>").appendTo(new_div);
|
||||
|
||||
|
||||
} else {
|
||||
rest_url.append("<span class='non_editable'>"+params[i]+"</span>");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function select_request(request) {
|
||||
command = requests[request];
|
||||
|
||||
if (command.test_only === true) {
|
||||
test_warning.show();
|
||||
} else {
|
||||
test_warning.hide();
|
||||
}
|
||||
|
||||
if (command.description) {
|
||||
$(description).html($('<a>')
|
||||
.attr('href', DOC_BASE+command.link)
|
||||
.html(command.description));
|
||||
$(description).show();
|
||||
} else {
|
||||
$(description).hide();
|
||||
}
|
||||
|
||||
selected_command.html($('<a>')
|
||||
.attr('href', DOC_BASE+command.link)
|
||||
.text(command.name));
|
||||
|
||||
//rest_url.val(command.path);
|
||||
//rest_url.text(command.path);
|
||||
change_path(command);
|
||||
|
||||
|
||||
// rest_method.val(command.method);
|
||||
// rest_method.change();
|
||||
request_button.val(command.method);
|
||||
request_button.text(command.method+" request");
|
||||
update_method(request_button);
|
||||
|
||||
if (command.method == POST || command.method == PUT) {
|
||||
cm_request.setValue(JSON.stringify(command.body, null, 2));
|
||||
} else {
|
||||
//No body, so wipe out the current contents.
|
||||
//This prevents confusion if the user toggles the HTTP method dropdown
|
||||
cm_request.setValue("");
|
||||
}
|
||||
|
||||
reset_response_area();
|
||||
};
|
||||
|
||||
//helper to fill the default payment with a new UUID
|
||||
function get_uuid(callback) {
|
||||
$.get(URL_BASE + "/v1/uuid").done(callback);
|
||||
}
|
||||
|
||||
function get_path() {
|
||||
s = "";
|
||||
rest_url.find(".non_editable, .editable").each(function() {
|
||||
if (this.tagName == "INPUT") {
|
||||
s += $(this).val();
|
||||
} else {
|
||||
s += $(this).text();
|
||||
}
|
||||
});
|
||||
return s;
|
||||
}
|
||||
|
||||
function send_request() {
|
||||
//var method = rest_method.val();
|
||||
var method = request_button.val();
|
||||
if (method != GET && method != POST && method != PUT && method != DELETE) {
|
||||
console.log("ERROR: unrecognized http method");
|
||||
return;
|
||||
}
|
||||
//var path = rest_url.val();
|
||||
var path = get_path();
|
||||
|
||||
$(this).addClass('depressed');
|
||||
response_body.addClass('obscured');
|
||||
|
||||
if (method == PUT || method == POST) {
|
||||
var body = cm_request.getValue();
|
||||
$.ajax({
|
||||
type: method,
|
||||
url: URL_BASE + path,
|
||||
data: body,
|
||||
contentType: 'application/json',
|
||||
processData: false
|
||||
}).done(success_output).fail(error_output).always(reset_sending_status);
|
||||
} else {
|
||||
$.ajax({
|
||||
type: method,
|
||||
url: URL_BASE + path
|
||||
}).done(success_output).fail(error_output).always(reset_sending_status);
|
||||
}
|
||||
|
||||
spinner.show();
|
||||
}
|
||||
|
||||
function error_output(xhr,status,statusText) {
|
||||
response_code.text(xhr.status+" "+xhr.statusText);
|
||||
cm_response.setValue(xhr.responseText);
|
||||
}
|
||||
|
||||
function success_output(body,status,xhr) {
|
||||
response_code.text(xhr.status+" "+xhr.statusText);
|
||||
cm_response.setValue(JSON.stringify(body, null, 2));
|
||||
}
|
||||
|
||||
function reset_sending_status() {
|
||||
response_body.removeClass('obscured');
|
||||
request_button.removeClass('depressed');
|
||||
spinner.hide();
|
||||
}
|
||||
|
||||
function reset_response_area() {
|
||||
cm_response.setValue("");
|
||||
response_code.text("");
|
||||
}
|
||||
|
||||
$(document).ready(function() {
|
||||
request_button.click(send_request);
|
||||
//rest_method.change(update_method);
|
||||
|
||||
get_uuid(function(resp,status,xhr) {
|
||||
requests["submit-payment"].body.client_resource_id = resp.uuid;
|
||||
if (window.location.hash == "#submit-payment") {
|
||||
//we might have already loaded the call by the time the AJAX
|
||||
// completes, so refresh the default body.
|
||||
// Debatably a bad idea, because if the AJAX takes so long that the
|
||||
// user has already started editing the call, it'll reset it.
|
||||
select_request("submit-payment");
|
||||
}
|
||||
});
|
||||
|
||||
if (window.location.hash) {
|
||||
var cmd = window.location.hash.slice(1).toLowerCase();
|
||||
var keys = Object.keys(requests);
|
||||
var index = keys.indexOf(cmd);
|
||||
|
||||
if (index === -1) return;
|
||||
|
||||
var el = commands.eq(index);
|
||||
|
||||
select_request(cmd);
|
||||
|
||||
$(el).siblings().removeClass('selected');
|
||||
$(el).addClass('selected');
|
||||
} else {
|
||||
select_request('generate-account');
|
||||
}
|
||||
});
|
||||
1
js/jquery.autosize.input.min.js
vendored
Normal file
1
js/jquery.autosize.input.min.js
vendored
Normal file
@@ -0,0 +1 @@
|
||||
var Plugins;(function(n){var t=function(){function n(n){typeof n=="undefined"&&(n=30);this.space=n}return n}(),i;n.AutosizeInputOptions=t;i=function(){function n(t,i){var r=this;this._input=$(t);this._options=$.extend({},n.getDefaultOptions(),i);this._mirror=$('<span style="position:absolute; top:-999px; left:0; white-space:pre;"/>');$.each(["fontFamily","fontSize","fontWeight","fontStyle","letterSpacing","textTransform","wordSpacing","textIndent"],function(n,t){r._mirror[0].style[t]=r._input.css(t)});$("body").append(this._mirror);this._input.on("keydown keyup input propertychange change",function(){r.update()});(function(){r.update()})()}return n.prototype.getOptions=function(){return this._options},n.prototype.update=function(){var n=this._input.val()||"",t;n!==this._mirror.text()&&(this._mirror.text(n),t=this._mirror.width()+this._options.space,this._input.width(t))},n.getDefaultOptions=function(){return this._defaultOptions},n.getInstanceKey=function(){return"autosizeInputInstance"},n._defaultOptions=new t,n}();n.AutosizeInput=i,function(t){var i="autosize-input",r=["text","password","search","url","tel","email","number"];t.fn.autosizeInput=function(u){return this.each(function(){if(this.tagName=="INPUT"&&t.inArray(this.type,r)>-1){var f=t(this);f.data(n.AutosizeInput.getInstanceKey())||(u==undefined&&(u=f.data(i)),f.data(n.AutosizeInput.getInstanceKey(),new n.AutosizeInput(this,u)))}})};t(function(){t("input[data-"+i+"]").autosizeInput()})}(jQuery)})(Plugins||(Plugins={}))
|
||||
244
rest-api-tool.html
Normal file
244
rest-api-tool.html
Normal file
@@ -0,0 +1,244 @@
|
||||
<!doctype html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset='utf-8'>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
|
||||
<meta name="viewport" content="width=device-width">
|
||||
|
||||
<title>Ripple Developer Portal: Ripple-REST API Tool</title>
|
||||
|
||||
<!-- favicon -->
|
||||
<link rel="icon" href="favicon.ico" type="image/x-icon">
|
||||
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon">
|
||||
|
||||
<!-- Flatdoc -->
|
||||
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
|
||||
<script src='https://dev.ripple.com/vendor/flatdoc/v/0.8.0/legacy.js'></script>
|
||||
<script src='https://dev.ripple.com/vendor/flatdoc/v/0.8.0/flatdoc.js'></script>
|
||||
|
||||
<!-- Bootstrap -->
|
||||
|
||||
<link href="css/bootstrap.min.css" rel="stylesheet">
|
||||
<script src="js/bootstrap.min.js"></script>
|
||||
|
||||
|
||||
<!-- Custom Stylesheet -->
|
||||
<link href='https://fonts.googleapis.com/css?family=Montserrat' rel='stylesheet' type='text/css'>
|
||||
<link href='https://fonts.googleapis.com/css?family=Open+Sans:600italic,400,700,300' rel='stylesheet' type='text/css'>
|
||||
<link href='css/main.css' rel='stylesheet'>
|
||||
<link href='css/custom.css' rel='stylesheet'>
|
||||
|
||||
<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
|
||||
|
||||
|
||||
<!-- start Mixpanel -->
|
||||
<script type="text/javascript">(function(e,b){if(!b.__SV){var a,f,i,g;window.mixpanel=b;a=e.createElement("script");a.type="text/javascript";a.async=!0;a.src=("https:"===e.location.protocol?"https:":"http:")+'//cdn.mxpnl.com/libs/mixpanel-2.2.min.js';f=e.getElementsByTagName("script")[0];f.parentNode.insertBefore(a,f);b._i=[];b.init=function(a,e,d){function f(b,h){var a=h.split(".");2==a.length&&(b=b[a[0]],h=a[1]);b[h]=function(){b.push([h].concat(Array.prototype.slice.call(arguments,0)))}}var c=b;"undefined"!==
|
||||
typeof d?c=b[d]=[]:d="mixpanel";c.people=c.people||[];c.toString=function(b){var a="mixpanel";"mixpanel"!==d&&(a+="."+d);b||(a+=" (stub)");return a};c.people.toString=function(){return c.toString(1)+".people (stub)"};i="disable track track_pageview track_links track_forms register register_once alias unregister identify name_tag set_config people.set people.set_once people.increment people.append people.track_charge people.clear_charges people.delete_user".split(" ");for(g=0;g<i.length;g++)f(c,i[g]);
|
||||
b._i.push([a,e,d])};b.__SV=1.2}})(document,window.mixpanel||[]);
|
||||
mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
</script>
|
||||
|
||||
<script>if (window.location.host == "dev.ripple.com") { mixpanel.track("rest-api-tool"); }</script>
|
||||
<!-- end Mixpanel -->
|
||||
|
||||
<!-- start google analytics -->
|
||||
<script>
|
||||
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
|
||||
|
||||
ga('create', 'UA-49188512-1', 'ripple.com');
|
||||
ga('send', 'pageview');
|
||||
|
||||
</script>
|
||||
<!-- end google analytics -->
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Temporary shims until I modify the css directly -->
|
||||
<link type='text/css' rel='stylesheet' href='css/mod.css' />
|
||||
<script src='js/expandcode.js'></script>
|
||||
|
||||
</head>
|
||||
<body role='flatdoc' class='no-literate'>
|
||||
<!--Draft warning would go here-->
|
||||
<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
|
||||
<div class="container">
|
||||
<div class="navbar-header">
|
||||
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
|
||||
<span class="sr-only">Toggle navigation</span>
|
||||
<span class="icon-bar"></span>
|
||||
<span class="icon-bar"></span>
|
||||
<span class="icon-bar"></span>
|
||||
</button>
|
||||
<a class="navbar-brand" href="https://dev.ripple.com/"><img class="small_logo" src="assets/img/ripple_logo_small.png"></a>
|
||||
</div>
|
||||
<div class="navbar-collapse collapse">
|
||||
<ul class="nav navbar-nav">
|
||||
<li><a href="/">Resources</a></li>
|
||||
<li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a></li>
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li class="dropdown active">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li class="active"><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
<iframe src="https://dev.ripple.com/vendor/ghbtn.html?user=ripple&repo=ripple-dev-portal&type=watch&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="110" height="20"></iframe>
|
||||
</div>
|
||||
</div><!--/.nav-collapse -->
|
||||
</div>
|
||||
</div>
|
||||
<div class='content-root'>
|
||||
<div id='wrapper'>
|
||||
<div style="clear:both;"></div>
|
||||
<div id='command_wrapper'>
|
||||
<ul id='command_list'>
|
||||
<li class='selected'>Generate Account</li>
|
||||
<li>Get Account Balances</li>
|
||||
<li>Get Account Settings</li>
|
||||
<li>Update Account Settings</li>
|
||||
<br/>
|
||||
<li>Prepare Payment</li>
|
||||
<li>Submit Payment</li>
|
||||
<li>Confirm Payment</li>
|
||||
<li>Get Payment History</li>
|
||||
<br/>
|
||||
<li>Get Trustlines</li>
|
||||
<li>Grant Trustline</li>
|
||||
<br/>
|
||||
<li>Check Notifications</li>
|
||||
<br/>
|
||||
<li>Check Connection</li>
|
||||
<li>Get Server Status</li>
|
||||
<br/>
|
||||
<li>Retrieve Ripple Transaction</li>
|
||||
<li>Generate UUID</li>
|
||||
</ul>
|
||||
<div id='command_table'>
|
||||
<div id='io_wrapper'>
|
||||
<div id='input' class='io'>
|
||||
<h2>REST Request</h2>
|
||||
<div id='test_warning' class='alert alert-danger' style='display:none;'>
|
||||
<h4>Test accounts only!</h4>
|
||||
<p>Never submit account secrets to a server you do not control, unless you are prepared to lose ownership of the account!</p>
|
||||
</div>
|
||||
<div style="clear:both;"></div>
|
||||
<h3 id='selected_command' title='Reference information'></h3>
|
||||
<p id='description'></p>
|
||||
<div id='invalid'>Invalid JSON</div>
|
||||
<!-- <select id='rest_method'>
|
||||
<option value='GET'>GET</option>
|
||||
<option value='POST'>POST</option>
|
||||
</select>-->
|
||||
<div id='rest_url_wrapper'>
|
||||
<p><span id='rest_host'>https://api.ripple.com</span><span id='rest_url'></span></p>
|
||||
</div>
|
||||
<div id='request_body'></div>
|
||||
<div id='request_options'>
|
||||
<div class="button btn btn-primary api" id='request_button'>Send request</div>
|
||||
</div>
|
||||
</div>
|
||||
<div id='output' class='io'>
|
||||
<h2>Response</h2>
|
||||
<div>
|
||||
<img class="loader" src="assets/img/rippleThrobber.png" style="vertical-align: middle; display:none;"/>
|
||||
<span id='rest_responsecode'></span>
|
||||
</div>
|
||||
<div id='response_body'></div>
|
||||
<div id='tooltip'></div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="container">
|
||||
<p class="text-muted">
|
||||
<div class="row">
|
||||
<div class="col-md-2">
|
||||
|
||||
<ul class="footer_links applications">
|
||||
<li><a href="https://www.rippletrade.com">Ripple Trade</a>
|
||||
<li><a href="https://www.ripplecharts.com">Ripple Charts</a>
|
||||
<li><a href="https://ripple.com/graph">Ripple Graph</a>
|
||||
<li><a href="http://codius.org/">Codius</a>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="col-md-2">
|
||||
|
||||
<ul class="footer_links middleware">
|
||||
<li><a href="gatewayd.html">Gatewayd</a>
|
||||
<li><a href="ripple-rest.html">Ripple REST</a>
|
||||
<li><a href="https://github.com/ripple/ripple-lib">Ripple Lib</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-2">
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-2">
|
||||
<ul class="footer_links bounties">
|
||||
<li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a>
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug tracking</a>
|
||||
<li><a href="guidelines.html">Brand guidelines</a>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev blog</a>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a>
|
||||
<li><a href="https://ripple.com/wiki/Main_Page">Wiki</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4 mail_chimp">
|
||||
<p>Join the mailing list!</p>
|
||||
<label for="mce-EMAIL">Email address</label>
|
||||
<!-- Begin MailChimp Signup Form -->
|
||||
<link href="//cdn-images.mailchimp.com/embedcode/slim-081711.css" rel="stylesheet" type="text/css">
|
||||
<style type="text/css">
|
||||
#mc_embed_signup{clear:left; font:14px; }
|
||||
|
||||
</style>
|
||||
<div id="mc_embed_signup">
|
||||
<form action="//ripple.us4.list-manage.com/subscribe/post?u=245dbc1c47849f034390dc5bf&id=4dfbe160d0" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
|
||||
|
||||
<input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="" required>
|
||||
<!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
|
||||
<div style="position: absolute; left: -5000px; top: -50px;"><input type="text" name="b_245dbc1c47849f034390dc5bf_4dfbe160d0" tabindex="-1" value=""></div>
|
||||
<input type="submit" value="Submit" name="subscribe" id="mc-embedded-subscribe" class="button btn btn-primary">
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<!--End mc_embed_signup-->
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<link rel='stylesheet' type='text/css' href='css/api-style.css'/>
|
||||
<link rel='stylesheet' type='text/css' href='css/codemirror.css'/>
|
||||
<script type='text/javascript' src='js/es5-shim.js'></script>
|
||||
<script src='//cdnjs.cloudflare.com/ajax/libs/codemirror/3.16.0/codemirror.min.js'></script>
|
||||
<script type='text/javascript' src='js/cm-javascript.min.js'></script>
|
||||
<script type='text/javascript' src='js/jquery.autosize.input.min.js'></script>
|
||||
<script type='text/javascript' src='js/apitool-rest.js'></script>
|
||||
|
||||
|
||||
</body>
|
||||
</html>
|
||||
@@ -5,7 +5,7 @@
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
|
||||
<meta name="viewport" content="width=device-width">
|
||||
|
||||
<title>Ripple Developer Portal: Ripple API Tool</title>
|
||||
<title>Ripple Developer Portal: Websocket API Tool</title>
|
||||
|
||||
<!-- favicon -->
|
||||
<link rel="icon" href="favicon.ico" type="image/x-icon">
|
||||
@@ -25,11 +25,12 @@
|
||||
<!-- Custom Stylesheet -->
|
||||
<link href='https://fonts.googleapis.com/css?family=Montserrat' rel='stylesheet' type='text/css'>
|
||||
<link href='https://fonts.googleapis.com/css?family=Open+Sans:600italic,400,700,300' rel='stylesheet' type='text/css'>
|
||||
<link href='css/main.css' rel='stylesheet'>
|
||||
<link href='css/custom.css' rel='stylesheet'>
|
||||
<link href='css/main.css' rel='stylesheet'>
|
||||
<link href='css/custom.css' rel='stylesheet'>
|
||||
<link href='css/mod.css' type='text/css' rel='stylesheet' />
|
||||
|
||||
<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
|
||||
|
||||
|
||||
@@ -58,14 +59,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
|
||||
|
||||
|
||||
<!-- Temporary shims until I modify the css directly -->
|
||||
<link type='text/css' rel='stylesheet' href='css/mod.css' />
|
||||
<script src='js/expandcode.js'></script>
|
||||
|
||||
</head>
|
||||
<body role='flatdoc' class='no-literate'>
|
||||
<!--Draft warning would go here-->
|
||||
<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
|
||||
<div class="container">
|
||||
<div class="navbar-header">
|
||||
@@ -84,7 +79,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li class="active"><a target="_self" href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown active">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li class="active"><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -95,7 +96,6 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
</div>
|
||||
<div class='content-root'>
|
||||
<div id='wrapper'>
|
||||
<h1>Ripple WebSocket API tool</h1>
|
||||
<div id='online_state'>Offline</div>
|
||||
<div style="clear:both;"></div>
|
||||
<div id='command_wrapper'>
|
||||
@@ -131,16 +131,16 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<div id='command_table'>
|
||||
<div id='io_wrapper'>
|
||||
<div id='input' class='io'>
|
||||
<h2>Request</h2>
|
||||
<div id='request_options'>
|
||||
<div class="button btn btn-primary api" id='request_button'>Send request</div>
|
||||
</div>
|
||||
<h2>WebSocket Request</h2>
|
||||
<div style="clear:both;"></div>
|
||||
<h3 id='selected_command' title='Reference information'>server_info</h3>
|
||||
<p id='description'></p>
|
||||
<div id='invalid'>Invalid JSON</div>
|
||||
<p>JSON</p>
|
||||
<div id='request'></div>
|
||||
<div id='request_options'>
|
||||
<div class="button btn btn-primary api" id='request_button'>Send request</div>
|
||||
</div>
|
||||
</div>
|
||||
<div id='output' class='io'>
|
||||
<h2>Response</h2>
|
||||
@@ -149,7 +149,10 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li id='stream_show'>show</li>
|
||||
<li id='stream_pause'>pause</li>
|
||||
</ul>
|
||||
<div id='status'></div>
|
||||
<div>
|
||||
<img class="loader" src="assets/img/rippleThrobber.png" style="vertical-align: middle; display:none;"/>
|
||||
<p id='status'></p>
|
||||
</div>
|
||||
<p id='info'></p>
|
||||
<div id='response'></div>
|
||||
<div id='tooltip'></div>
|
||||
@@ -185,6 +188,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
@@ -61,11 +61,12 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
|
||||
<!-- syntax selection js -->
|
||||
<script src='js/multicodetab.js'></script>
|
||||
<script src="js/multicodetab.js"></script>
|
||||
<script>
|
||||
Flatdoc.run({
|
||||
fetcher: Flatdoc.file('ripplerest_api.md')
|
||||
});
|
||||
$(document).on('flatdoc:ready', $().multicode_tabs);
|
||||
</script>
|
||||
<link type='text/css' rel='stylesheet' href='css/mod.css' />
|
||||
<script src="js/fixsidebarscroll.js"></script>
|
||||
@@ -92,7 +93,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li><a href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -101,18 +108,6 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
</div><!--/.nav-collapse -->
|
||||
</div>
|
||||
</div>
|
||||
<!--
|
||||
<div class="header-subnav-wrapper">
|
||||
<div class='header-subnav navbar-fixed-top'>
|
||||
<ul>
|
||||
<li><a href='?p=introduction' id='subnav-intro'>Introduction</a></li>
|
||||
<li><a href='?p=ripple-rest-api' id='subnav-rest'>Ripple-REST API</a></li>
|
||||
<li><a href='?p=web-sockets-api' id='subnav-websocket'>WebSocket & JSON-RPC APIs</a></li>
|
||||
</ul>
|
||||
<div class='clearer'> </div>
|
||||
</div>
|
||||
</div>
|
||||
-->
|
||||
<div class='content-root'>
|
||||
<div class='menubar'>
|
||||
<div class='menu section' role='flatdoc-menu'></div>
|
||||
@@ -146,6 +141,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
File diff suppressed because one or more lines are too long
1528
ripplerest_api.md
1528
ripplerest_api.md
File diff suppressed because it is too large
Load Diff
@@ -74,7 +74,13 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li><a href="ripple-api-tool.html">API Tool</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
@@ -174,6 +180,8 @@ mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
|
||||
211
transactions.html
Normal file
211
transactions.html
Normal file
@@ -0,0 +1,211 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
|
||||
<meta name="viewport" content="width=device-width">
|
||||
|
||||
<title>Ripple Developer Portal: Transactions</title>
|
||||
|
||||
<!-- favicon -->
|
||||
<link rel="icon" href="favicon.ico" type="image/x-icon">
|
||||
<link rel="shortcut icon" href="favicon.ico" type="image/x-icon">
|
||||
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
|
||||
|
||||
<!-- Flatdoc -->
|
||||
<script src="https://dev.ripple.com/vendor/flatdoc/v/0.8.0/legacy.js"></script>
|
||||
<script src="https://dev.ripple.com/vendor/flatdoc/v/0.8.0/flatdoc.js"></script>
|
||||
|
||||
<!-- Bootstrap -->
|
||||
|
||||
<link href="css/bootstrap.min.css" rel="stylesheet">
|
||||
<script src="js/bootstrap.min.js"></script>
|
||||
|
||||
<!-- Flatdoc theme -->
|
||||
<link href="vendor/flatdoc/v/0.8.0/theme-white/style.css" rel="stylesheet">
|
||||
<script src="vendor/flatdoc/v/0.8.0/theme-white/script.js"></script>
|
||||
|
||||
<!-- Custom Stylesheets -->
|
||||
<link href="https://fonts.googleapis.com/css?family=Montserrat" rel="stylesheet" type="text/css">
|
||||
<link href="https://fonts.googleapis.com/css?family=Open+Sans:600italic,400,700,300" rel="stylesheet" type="text/css">
|
||||
<link href="css/main.css" rel="stylesheet">
|
||||
<link href="css/custom.css" rel="stylesheet">
|
||||
|
||||
<link rel="shortcut icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
<link rel="icon" href="favicon.ico?v=2" type="image/x-icon">
|
||||
|
||||
|
||||
<!-- start Mixpanel -->
|
||||
<script type="text/javascript">(function(e,b){if(!b.__SV){var a,f,i,g;window.mixpanel=b;a=e.createElement("script");a.type="text/javascript";a.async=!0;a.src=("https:"===e.location.protocol?"https:":"http:")+'//cdn.mxpnl.com/libs/mixpanel-2.2.min.js';f=e.getElementsByTagName("script")[0];f.parentNode.insertBefore(a,f);b._i=[];b.init=function(a,e,d){function f(b,h){var a=h.split(".");2==a.length&&(b=b[a[0]],h=a[1]);b[h]=function(){b.push([h].concat(Array.prototype.slice.call(arguments,0)))}}var c=b;"undefined"!==
|
||||
typeof d?c=b[d]=[]:d="mixpanel";c.people=c.people||[];c.toString=function(b){var a="mixpanel";"mixpanel"!==d&&(a+="."+d);b||(a+=" (stub)");return a};c.people.toString=function(){return c.toString(1)+".people (stub)"};i="disable track track_pageview track_links track_forms register register_once alias unregister identify name_tag set_config people.set people.set_once people.increment people.append people.track_charge people.clear_charges people.delete_user".split(" ");for(g=0;g<i.length;g++)f(c,i[g]);
|
||||
b._i.push([a,e,d])};b.__SV=1.2}})(document,window.mixpanel||[]);
|
||||
mixpanel.init("132d42885e094171f34467fc54da6fab");
|
||||
</script>
|
||||
|
||||
<script>if (window.location.host == "dev.ripple.com") { mixpanel.track("transactions"); }</script>
|
||||
<!-- end Mixpanel -->
|
||||
|
||||
<!-- start google analytics -->
|
||||
<script>
|
||||
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
||||
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
||||
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
||||
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
|
||||
|
||||
ga('create', 'UA-49188512-1', 'ripple.com');
|
||||
ga('send', 'pageview');
|
||||
|
||||
</script>
|
||||
<!-- end google analytics -->
|
||||
|
||||
|
||||
|
||||
<!-- syntax selection js -->
|
||||
<script src="js/multicodetab.js"></script>
|
||||
<!-- Code to load Flatdoc; commented out on compiled page -->
|
||||
<script>
|
||||
$(".flatdoc-content").empty();
|
||||
$(".content-root .menubar .menu").empty();
|
||||
Flatdoc.run({
|
||||
fetcher: Flatdoc.file('tx_format.md')
|
||||
});
|
||||
$(document).on('flatdoc:ready', $().multicode_tabs);
|
||||
</script>
|
||||
<!-- end flatdoc load -->
|
||||
<!-- Alternate multicode tabs for compiled page:
|
||||
<script>
|
||||
$(document).ready(function() {
|
||||
$(".multicode").minitabs()
|
||||
make_code_expandable();
|
||||
});
|
||||
</script>
|
||||
<!--end alt code for compiled page -->
|
||||
<link type="text/css" rel="stylesheet" href="css/mod.css">
|
||||
<script src="js/expandcode.js"></script>
|
||||
<script src="js/fixsidebarscroll.js"></script>
|
||||
|
||||
</head>
|
||||
<body role='flatdoc' class='no-literate'>
|
||||
<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
|
||||
<div class="container">
|
||||
<div class="navbar-header">
|
||||
<button type="button" class="navbar-toggle" data-toggle="collapse" data-target=".navbar-collapse">
|
||||
<span class="sr-only">Toggle navigation</span>
|
||||
<span class="icon-bar"></span>
|
||||
<span class="icon-bar"></span>
|
||||
<span class="icon-bar"></span>
|
||||
</button>
|
||||
<a class="navbar-brand" href="https://dev.ripple.com/"><img class="small_logo" src="assets/img/ripple_logo_small.png"></a>
|
||||
</div>
|
||||
<div class="navbar-collapse collapse">
|
||||
<ul class="nav navbar-nav">
|
||||
<li class="active"><a href="/">Resources</a></li>
|
||||
<li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a></li>
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug Tracking</a></li>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev Blog</a></li>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a></li>
|
||||
<li class="dropdown">
|
||||
<a href="#" class="dropdown-toggle" data-toggle="dropdown">API Tool <span class="caret"></span></a>
|
||||
<ul class="dropdown-menu" role="menu">
|
||||
<li><a href="ripple-api-tool.html">WebSocket Tool</a></li>
|
||||
<li><a href="rest-api-tool.html">REST Tool</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<div class='right'>
|
||||
<!-- GitHub buttons -->
|
||||
<iframe src="https://dev.ripple.com/vendor/ghbtn.html?user=ripple&repo=ripple-dev-portal&type=watch&count=true" allowtransparency="true" frameborder="0" scrolling="0" width="110" height="20"></iframe>
|
||||
</div>
|
||||
</div><!--/.nav-collapse -->
|
||||
</div>
|
||||
</div>
|
||||
<!--
|
||||
<div class="header-subnav-wrapper">
|
||||
<div class='header-subnav navbar-fixed-top'>
|
||||
<ul>
|
||||
<li><a href='?p=introduction' id='subnav-intro'>Introduction</a></li>
|
||||
<li><a href='?p=ripple-rest-api' id='subnav-rest'>Ripple-REST API</a></li>
|
||||
<li><a href='?p=web-sockets-api' id='subnav-websocket'>WebSocket & JSON-RPC APIs</a></li>
|
||||
</ul>
|
||||
<div class='clearer'> </div>
|
||||
</div>
|
||||
</div>
|
||||
-->
|
||||
<div class='content-root'>
|
||||
<div class='menubar'>
|
||||
<div class='menu section' role='flatdoc-menu'></div>
|
||||
</div>
|
||||
<div role='flatdoc-content' class='content'>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
<div class="footer">
|
||||
<div class="container">
|
||||
<p class="text-muted">
|
||||
<div class="row">
|
||||
<div class="col-md-2">
|
||||
|
||||
<ul class="footer_links applications">
|
||||
<li><a href="https://www.rippletrade.com">Ripple Trade</a>
|
||||
<li><a href="https://www.ripplecharts.com">Ripple Charts</a>
|
||||
<li><a href="https://ripple.com/graph">Ripple Graph</a>
|
||||
<li><a href="http://codius.org/">Codius</a>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="col-md-2">
|
||||
|
||||
<ul class="footer_links middleware">
|
||||
<li><a href="gatewayd.html">Gatewayd</a>
|
||||
<li><a href="ripple-rest.html">Ripple REST</a>
|
||||
<li><a href="https://github.com/ripple/ripple-lib">Ripple Lib</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-2">
|
||||
|
||||
<ul class="footer_links core_network">
|
||||
<li><a href="rippled-apis.html">rippled</a>
|
||||
<li><a href="transactions.html">Transactions</a>
|
||||
<li><a href="consensus-whitepaper.html">Consensus</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-2">
|
||||
<ul class="footer_links bounties">
|
||||
<li><a href="https://www.bountysource.com/teams/ripple/bounties">Bounties</a>
|
||||
<li><a href="https://ripplelabs.atlassian.net/">Bug tracking</a>
|
||||
<li><a href="guidelines.html">Brand guidelines</a>
|
||||
<li><a href="https://ripple.com/dev/blog/">Dev blog</a>
|
||||
<li><a href="https://ripple.com/forum/viewforum.php?f=2&sid=c016bc6b934120b7117c0e136e74de98">Forums</a>
|
||||
<li><a href="https://ripple.com/wiki/Main_Page">Wiki</a>
|
||||
</ul>
|
||||
|
||||
</div>
|
||||
<div class="col-md-4 mail_chimp">
|
||||
<p>Join the mailing list!</p>
|
||||
<label for="mce-EMAIL">Email address</label>
|
||||
<!-- Begin MailChimp Signup Form -->
|
||||
<link href="//cdn-images.mailchimp.com/embedcode/slim-081711.css" rel="stylesheet" type="text/css">
|
||||
<style type="text/css">
|
||||
#mc_embed_signup{clear:left; font:14px; }
|
||||
|
||||
</style>
|
||||
<div id="mc_embed_signup">
|
||||
<form action="//ripple.us4.list-manage.com/subscribe/post?u=245dbc1c47849f034390dc5bf&id=4dfbe160d0" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
|
||||
|
||||
<input type="email" value="" name="EMAIL" class="email" id="mce-EMAIL" placeholder="" required>
|
||||
<!-- real people should not fill this in and expect good things - do not remove this or risk form bot signups-->
|
||||
<div style="position: absolute; left: -5000px; top: -50px;"><input type="text" name="b_245dbc1c47849f034390dc5bf_4dfbe160d0" tabindex="-1" value=""></div>
|
||||
<input type="submit" value="Submit" name="subscribe" id="mc-embedded-subscribe" class="button btn btn-primary">
|
||||
</form>
|
||||
</div>
|
||||
|
||||
<!--End mc_embed_signup-->
|
||||
</div>
|
||||
</div>
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
||||
387
tx_format.md
387
tx_format.md
@@ -2,7 +2,7 @@
|
||||
|
||||
A *Transaction* is the only way to modify the Ripple Ledger. All transactions have certain fields in common:
|
||||
|
||||
* [All Transactions](#all-transactions)
|
||||
* [Common Fields](#common-fields)
|
||||
|
||||
There are several different types of transactions that perform different actions, each with additional fields relevant to that type of action:
|
||||
|
||||
@@ -15,12 +15,13 @@ There are several different types of transactions that perform different actions
|
||||
|
||||
Additionally, there are *Psuedo-Transactions* that are not created and submitted in the usual way, but may appear in ledgers:
|
||||
|
||||
* [Amendment - Adopt a new feature in the network](#amendment)
|
||||
* [Fee - Adjust the minimum transaction fee or account reserve](#fee)
|
||||
|
||||
## Signing Transactions ##
|
||||
## Signing and Sending Transactions ##
|
||||
|
||||
Signing a transaction cryptographically proves that the person in charge of the account sending the transaction really means to do so. Only signed transactions can be submitted to the network and included in ledgers. network, and possibly included in a validated ledger. A signed transaction is immutable: if any of the contents of the transaction change, the signature is not valid.
|
||||
Signing a transaction cryptographically proves that the person in charge of the account sending the transaction is authorized to do so. Only signed transactions can be submitted to the network and included in a validated ledger. A signed transaction is immutable: its contents cannot change, and the signature is not valid for any other transaction.
|
||||
|
||||
You can sign a transaction using a secret key: either the master secret, or a regular secret if the account has a regular key pair associated with it. (See [SetRegularKey](#setregularkey) for details.)
|
||||
|
||||
Multi-signature transactions are [in development](https://wiki.ripple.com/Multisign).
|
||||
|
||||
@@ -31,7 +32,7 @@ Typically, you create a transaction in JSON format first. Here is an example of
|
||||
"TransactionType" : "Payment",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount" : {
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
@@ -44,10 +45,10 @@ Typically, you create a transaction in JSON format first. Here is an example of
|
||||
|
||||
After doing that, you generate the signed binary format for the transaction. There are two ways to do this:
|
||||
|
||||
* Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
|
||||
* [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is the reference implementation for offline signing.
|
||||
* Have a `rippled` server sign the transaction for you. The [sign command](rippled-apis.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net.)
|
||||
* As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes.
|
||||
1. Convert it to a binary blob and sign it offline. This is preferable, since it means that the account secret used for signing the transaction is never transmitted over any network connection.
|
||||
* [rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) is a JavaScript implementation of offline signing.
|
||||
2. Have a `rippled` server sign the transaction for you. The [sign command](rippled-apis.html#sign) takes a JSON-format transaction and secret and returns the signed binary transaction format ready for submission. (Transmitting your account secret is dangerous, so you should only do this from within a trusted and encrypted sub-net, to a server you control.)
|
||||
* As a shortcut, you can use the [submit command](rippled-apis.html#submit) with a `tx_json` object to sign and submit a transaction all at once. This is only recommended for testing and development purposes.
|
||||
|
||||
In either case, signing a transaction generates a binary blob that can be submitted to the network. This means using `rippled`'s [submit command](rippled-apis.html#submit). Here is an example of the same transaction, as a signed blob, being submitted with the WebSocket API:
|
||||
|
||||
@@ -149,77 +150,114 @@ After a transaction has been submitted, if it gets accepted into a validated led
|
||||
}
|
||||
```
|
||||
|
||||
*Note:* The `"hash"` value needed to look up the transaction is in the response from the server when you submit the transaction, or you can find the relevant transaction by looking through an account's transaction history with the [account_tx command](rippled-apis.html#account_tx).
|
||||
### Identifying Transactions ###
|
||||
|
||||
## All Transactions ##
|
||||
The `"hash"` is the unique value that identifies a particular transaction. The server provides the hash in the response when you submit the transaction; you can also look up a transaction in an account's transaction history with the [account_tx command](rippled-apis.html#account_tx).
|
||||
|
||||
Every transaction has a the same set of fundamental properties:
|
||||
The transaction hash can be used as a "proof of payment" since anyone can look up the transaction using the hash and verify its final status.
|
||||
|
||||
## Common Fields ##
|
||||
|
||||
Every transaction type has the same set of fundamental fields:
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| Account | String | Account | The unique address of the account that initiated the transaction |
|
||||
| [Fee](#transaction-fees) | String | Amount | (Required, but auto-fillable) Integer amount of XRP, in drops, to be destroyed as a fee for redistributing this transaction to the network. |
|
||||
| Flags | Unsigned Integer | UInt32 | (Optional) Set of bit-flags for this transaction |
|
||||
| Account | String | Account | The unique address of the account that initiated the transaction. |
|
||||
| [AccountTxnID](#accounttxnid) | String | Hash256 | (Optional) Hash value identifying another transaction. This transaction is only valid if the sending account's previously-sent transaction matches the provided hash. |
|
||||
| [Fee](#transaction-fees) | String | Amount | (Required, but [auto-fillable](#auto-fillable-fields)) Integer amount of XRP, in drops, to be destroyed as a fee for redistributing this transaction to the network. |
|
||||
| [Flags](#flags) | Unsigned Integer | UInt32 | (Optional) Set of bit-flags for this transaction. |
|
||||
| [LastLedgerSequence](#lastledgersequence) | Number | UInt32 | (Optional, but strongly recommended) Highest ledger sequence number that a transaction can appear in. |
|
||||
| [Memos](#memos) | Array of Objects | Array | (Optional) Additional arbitrary information used to identify this transaction. |
|
||||
| [PreviousTxnID](#previoustxnid) | String | Hash256 | (Optional) Hash value identifying a transaction. If the transaction immediately prior this one by sequence number does not match the provided hash, this transaction is considered invalid. |
|
||||
| [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but auto-fillable) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. |
|
||||
| SigningPubKey | String | PubKey | (Omitted until signed) Hex representation of the public key that corresponds to the private key used to sign this transaction. |
|
||||
| [Sequence](#canceling-or-skipping-a-transaction) | Unsigned Integer | UInt32 | (Required, but [auto-fillable](#auto-fillable-fields)) The sequence number, relative to the initiating account, of this transaction. A transaction is only valid if the `Sequence` number is exactly 1 greater than the last-valided transaction from the same account. |
|
||||
| SigningPubKey | String | PubKey | (Automatically added when signing) Hex representation of the public key that corresponds to the private key used to sign this transaction. |
|
||||
| SourceTag | Unsigned Integer | UInt32 | (Optional) Arbitrary integer used to identify the reason for this payment, or the hosted wallet on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
|
||||
| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, and `AccountSet`. |
|
||||
| TxnSignature | String | VariableLength | (Omitted until signed) The signature that verifies this transaction as originating from the account it says it is from |
|
||||
| TransactionType | String | UInt16 | The type of transaction. Valid types include: `Payment`, `OfferCreate`, `OfferCancel`, `TrustSet`, `AccountSet`, and `SetRegularKey`. |
|
||||
| TxnSignature | String | VariableLength | (Automatically added when signing) The signature that verifies this transaction as originating from the account it says it is from. |
|
||||
|
||||
The field `PreviousTxnID` is **DEPRECATED**. It has been replaced by [AccountTxnID](#accounttxnid). Always use `AccountTxnID` instead.
|
||||
|
||||
### Auto-fillable Fields ###
|
||||
|
||||
Some fields can be automatically filled in before the transaction is signed, either by a `rippled` server or by the library used for offline signing. Both [ripple-lib](https://github.com/ripple/ripple-lib) and `rippled` can automatically provide the following values:
|
||||
|
||||
* `Fee` - Automatically use the current base network fee. (*Note:* `rippled`'s [sign command](rippled-apis.html#sign) supports limits on how high the filled-in-value is, using the `fee_mult_max` parameter.)
|
||||
* `Sequence` - Automatically use the next sequence number for the account sending the transaction.
|
||||
|
||||
For a production system, we recommend *not* leaving these fields to be filled by the server. For example if fees become temporarily high, you may want to wait for fees to decrease before sending some transactions, instead of continuing regardless of fee.
|
||||
|
||||
The [`Paths` field](#paths) of the [Payment](#payment) transaction type can also be automatically filled in.
|
||||
|
||||
### Transaction Fees ###
|
||||
|
||||
The `Fee` field specifies an amount, in drops of XRP, that must be deducted from the sender's balance in order to relay any transaction through the network. This is a measure to protect against spam and DDoS attacks weighing down the whole network. You can specify any amount in the `Fee` field when you create a transaction. If your transaction makes it into a validated leger (whether or not it achieves its intended purpose), then the deducted XRP is destroyed forever.
|
||||
The `Fee` field specifies an amount, in [drops of XRP](rippled-apis.html#specifying-currency-amounts), that must be deducted from the sender's balance in order to relay any transaction through the network. This is a measure to protect against spam and DDoS attacks weighing down the whole network. You can specify any amount in the `Fee` field when you create a transaction. If your transaction makes it into a validated leger (whether or not it achieves its intended purpose), then the deducted XRP is destroyed forever.
|
||||
|
||||
Each rippled server decides on the minimum fee to require, which is at least the global base transaction fee, and increases based on the individual server's current load. If a transaction's fee is not high enough, then the server does not relay the transaction to other servers. (*Exception:* If you send a transaction to your own server over an admin connection, it relays the transaction even under high load, so long as the fee meets the global base.)
|
||||
|
||||
Even if some servers have too much load to propagate a transaction, the transaction can still make it into a validated ledger as long as a large enough percentage of validating servers receive it, so the global base fee is generally enough to submit a transaction. If many servers in the network are under high load all at once (for example, due to a DDoS or a global event of some sort) then you must either set the fee higher or wait for the load to decrease.
|
||||
Even if some servers have too much load to propagate a transaction, the transaction can still make it into a validated ledger as long as a large enough percentage of validating servers receive it, so the global base fee is generally enough to submit a transaction. If many servers in the network are under high load all at once (for example, due to a DDoS or a global event of some sort) then you must either set the fee higher or wait for the load to decrease.
|
||||
|
||||
For more information, see the [Transaction Fee wiki article](https://wiki.ripple.com/Transaction_Fee).
|
||||
|
||||
### Canceling or Skipping a Transaction ###
|
||||
|
||||
An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger.
|
||||
An important and intentional feature of the Ripple Network is that a transaction is final as soon as it has been incorporated in a validated ledger.
|
||||
|
||||
However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want to perform the same transaction again, you can perform an [AccountSet](#accountset) transaction with no options.
|
||||
However, if a transaction has not yet been included in a validated ledger, you can effectively cancel it by rendering it invalid. Typically, this means sending another transaction with the same `Sequence` value from the same account. If you do not want to perform the same transaction again, you can perform an [AccountSet](#accountset) transaction with no options.
|
||||
|
||||
For example, if you attempted to submit 3 transactions with sequence numbers 11, 12, and 13, but transaction 11 gets lost somehow or does not have a high enough [transaction fee](#transaction-fees) to be propagated to the network, then you can cancel transaction 11 by submitting an AccountSet transaction with no options and sequence number 11. This does nothing (except destroying the transaction fee for the new transaction 11), but it allows transactions 12 and 13 to become valid.
|
||||
|
||||
This approach is preferable to renumbering and resubmitting transactions 12 and 13, because it prevents transactions from being effectively duplicated under different sequence numbers.
|
||||
|
||||
In this way, an AccountSet transaction with no options is the canonical "no-op" transaction.
|
||||
In this way, an AccountSet transaction with no options is the canonical "[no-op](http://en.wikipedia.org/wiki/NOP)" transaction.
|
||||
|
||||
### LastLedgerSequence ###
|
||||
|
||||
We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](rippled-apis.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds.
|
||||
We strongly recommend that you specify the `LastLedgerSequence` parameter on every transaction. Provide a value of about 3 higher than [the most recent ledger index](rippled-apis.html#ledger) to ensure that your transaction is either validated or rejected within a matter of seconds.
|
||||
|
||||
Without the `LastLedgerSequence` parameter, there is a particular situation that can occur and cause your transaction to be stuck in an undesirable state where it is neither validated nor rejected for a long time. Specifically, if the global base [transaction fee](#transaction-fees) increases after you send a transaction, your transaction may not get propagated enough to be included in a validated ledger, but you would have to pay the (increased) fee in order to send another transaction canceling it. Later, if the transaction fee decreases again, the transaction may become viable again. The `LastLedgerSequence` places a hard upper limit on how long the transaction can wait to be validated or rejected.
|
||||
|
||||
### PreviousTxnID ###
|
||||
### AccountTxnID ###
|
||||
|
||||
The `PreviousTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one is also valid and matches the transaction you expected.
|
||||
The `AccountTxnID` field lets you chain your transactions together, so that a current transaction is not valid unless the previous one (by Sequence Number) is also valid and matches the transaction you expected.
|
||||
|
||||
One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `PreviousTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.
|
||||
One situation in which this is useful is if you have a primary system for submitting transactions and a passive backup system. If the passive backup system becomes disconnected from the primary, but the primary is not fully dead, and they both begin operating at the same time, you could potentially encounter serious problems like some transactions sending twice and others not at all. Chaining your transactions together with `AccountTxnID` ensures that, even if both systems are active, only one of them can submit valid transactions at a time.
|
||||
|
||||
In order to use PreviousTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.
|
||||
In order to use AccountTxnID, you must first set the [asfAccountTxnID](#accountset-flags) flag, so that the ledger keeps track of the ID for the account's previous transaction.
|
||||
|
||||
### Memos ###
|
||||
|
||||
The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects, where each object has the following fields:
|
||||
The Memos field allows for arbitrary messaging data that can accompany the transaction. It is presented as an array of objects. Each object has only one field, `Memo`, which in turn contains another object with *one or more* of the following fields:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| MemoType | String | Arbitrary descriptor of the memo's format. We recommend using MIME types. |
|
||||
| MemoData | (Variable) | Any data representing the memo's content. |
|
||||
| (...) | (Variable) | Arbitrary additional fields such as `Account`, `RegularKey`, etc. that can be used to support features such as encryption. |
|
||||
| Field | Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|------|--------------------------------------------------------|-------------|
|
||||
| MemoType | String | VariableLength | Arbitrary hex value; conventionally should be ASCII for a unique relation (according to [RFC 5988](http://tools.ietf.org/html/rfc5988#section-4)) that defines the format of this memo. |
|
||||
| MemoData | String | VariableLength | Arbitrary hex value, conventionally containing the content of the memo. |
|
||||
| MemoFormat | String | VariableLength | Arbitrary hex value, conventionally containing information on how the memo is encoded, for example as a [MIME type](http://www.iana.org/assignments/media-types/media-types.xhtml) |
|
||||
|
||||
The `Memos` field is currently limited to no more than 1KB in size (when serialized in binary format).
|
||||
|
||||
Example of a transaction with a Memos field:
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType": "Payment",
|
||||
"Account": "rMmTCjGFRWPz8S2zAUUoNVSQHxtRQD4eCx",
|
||||
"Destination": "r3kmLJN5D28dHuH8vZNUZpMC43pEHpaocV",
|
||||
"Memos": [
|
||||
{
|
||||
"Memo": {
|
||||
"MemoType": "5061796d656e7420726561736f6e",
|
||||
"MemoData": "72656e74"
|
||||
}
|
||||
}
|
||||
],
|
||||
"Amount": "1"
|
||||
}
|
||||
```
|
||||
|
||||
The memos field is currently limited to no more than 1KB in size.
|
||||
|
||||
### Flags ###
|
||||
|
||||
The Flags field allows for additional boolean options regarding the behavior of a transaction. They are represented as binary values that can be bitwise-or added to set multiple flags at once.
|
||||
The Flags field allows for additional boolean options regarding the behavior of a transaction. They are represented as binary values that can be combined with bitwise-or operations to set multiple flags at once.
|
||||
|
||||
Most flags only have meaning for a specific transaction type. The same bitwise value may be reused for flags on different transaction types, so it is important to pay attention to the `TransactionType` field when setting and reading flags.
|
||||
|
||||
@@ -232,9 +270,12 @@ The only flag that applies globally to all transactions is as follows:
|
||||
|
||||
|
||||
## Payment ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/Payment.cpp "Source")
|
||||
|
||||
A Payment transaction represents a transfer of value from one account to another. (Depending on the path taken, additional exchanges of value may occur atomically to facilitate the payment.)
|
||||
|
||||
Payments are also the only way to [create accounts](#creating-accounts).
|
||||
|
||||
Example payment:
|
||||
|
||||
```
|
||||
@@ -242,7 +283,7 @@ Example payment:
|
||||
"TransactionType" : "Payment",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount" : {
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
@@ -254,21 +295,35 @@ Example payment:
|
||||
```
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| Amount | String (XRP)<br/>Object (Otherwise) | Amount | The amount of currency sent as part of this transaction. (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) |
|
||||
|-------|-----------|--------------------------------------------------------|-------------|
|
||||
| Amount | String (XRP)<br/>Object (Otherwise) | Amount | The amount of currency to deliver. *Note:* If the [*tfPartialPayment* flag](#payment-flags) is set, this is not the amount actually received. (Formatted as per [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts).) |
|
||||
| Destination | String | Account | The unique address of the account receiving the payment. |
|
||||
| DestinationTag | Unsigned Integer | UInt32 | (Optional) Arbitrary tag that identifies the reason for the payment to the destination, or the hosted wallet to make a payment to. |
|
||||
| InvoiceID | String | Hash256 | (Optional) Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
|
||||
| Paths | Array of path arrays | PathSet | (Optional, but recommended) Array of [payment paths](https://ripple.com/wiki/Payment_paths) to be used for this transaction. If omitted, the paths are chosen by the server. |
|
||||
| SendMax | String/Object | Amount | Highest amount of currency this transaction is allowed to cost; this is to compensate for [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) |
|
||||
| Paths | Array of path arrays | PathSet | (Optional, auto-fillable) Array of [payment paths](https://ripple.com/wiki/Payment_paths) to be used for this transaction. Must be omitted for XRP-to-XRP transactions. |
|
||||
| SendMax | String/Object | Amount | (Optional) Highest amount of source currency this transaction is allowed to cost, including fees, exchanges, and [slippage](http://en.wikipedia.org/wiki/Slippage_%28finance%29). (See [Specifying Currency Amounts](rippled-apis.html#specifying-currency-amounts)) Must be supplied for cross-currency/cross-issue payments (implies source balance). Must be omitted for XRP-to-XRP payments.|
|
||||
|
||||
### Creating Accounts ###
|
||||
|
||||
The Payment transaction type is the only way to create new accounts in the shared Ripple ledger. To do so, send an amount of XRP that is equal or greater than the [account reserve](https://wiki.ripple.com/Reserves) to a mathematically-valid account address that does not exist yet. When the payment is processed, a new [AccountRoot node](https://wiki.ripple.com/Ledger_Format#AccountRoot) will be added to the ledger to reflect the newly-created account.
|
||||
|
||||
If you attempt to send an insufficient amount of XRP, or any other currency, the Payment will fail.
|
||||
|
||||
### Paths ###
|
||||
|
||||
The `Paths` field is a set of different paths along which the payment can be made. A single transaction can potentially follow multiple paths, for example if the transaction exchanges currency using several different offers in order to achieve the best rate. The source and destination (that is, the endpoints of the path) are omitted from the path array because they are part of the transaction definition.
|
||||
The `Paths` field is a set of different paths along which the payment can be made. A single transaction can potentially follow multiple paths, for example if the transaction exchanges currency using several different offers in order to achieve the best rate. The source and destination (that is, the endpoints of the path) are omitted from a path. You can get suggestions of paths from rippled servers using the [`path_find`](#path-find) or [`ripple_path_find`](#ripple-path-find) commands.
|
||||
|
||||
You can get suggestions of paths from rippled servers using the [`path_find`](#path-find) or [`ripple_path_find`](#ripple-path-find) commands. We recommend always including looking up the paths and including them as part of the transaction, because there are no guarantees on how expensive the paths the server finds will be at the time of submission. (Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit.)
|
||||
If the `Paths` field is provided, the server decides at transaction processing time which paths to use out of the provided set. This decision is deterministic and attempts to minimize costs, but it is not guaranteed to be perfect.
|
||||
|
||||
If the `Paths` field is omitted, by definition the payment should take a direct path connecting the source and destination accounts. A direct path could be:
|
||||
|
||||
* An XRP-to-XRP transfer.
|
||||
* A payment along a single trust line that connects the two accounts in the currency being transferred.
|
||||
|
||||
The `Paths` field must not be an empty array, nor an array whose members are all empty arrays.
|
||||
|
||||
The `Paths` field can be automatically filled in when the transaction is signed, if the `build_path` field is provided to the [sign](rippled-apis.html#sign) or [submit](rippled-apis.html#submit) commands. However, we recommend pathfinding separately and confirming the results prior to signing, in order to avoid surprises. There are no guarantees on how expensive the paths the server finds will be at the time of submission. (Although `rippled` is designed to search for the cheapest paths possible, it may not always find them. Untrustworthy `rippled` instances could also be modified to change this behavior for profit.)
|
||||
|
||||
An empty `Paths` array indicates a direct transfer: either because the sending and receiving accounts are directly linked by a trust line in the currency being transferred, or because the transaction is sending XRP.
|
||||
|
||||
### Payment Flags ###
|
||||
|
||||
@@ -277,13 +332,34 @@ Transactions of the Payment type support additional values in the [`Flags` field
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
|-----------|-----------|---------------|-------------|
|
||||
| tfNoDirectRipple | 0x00010000 | 65536 | Do not use a direct path, if available. This is intended to force the transaction to take arbitrage opportunities. Most clients will not need this. |
|
||||
| tfPartialPayment | 0x00020000 | 131072 | Instead of deducting transfer and exchange fees from the sending account's balance, reduce the received amount by the fee amounts. This is useful for refunding payments. Note, the transaction fee is still subtracted from the sender's account. |
|
||||
| tfPartialPayment | 0x00020000 | 131072 | If the specified `Amount` cannot be sent without spending more than `SendMax`, reduce the received amount instead of failing outright. See [Partial Payments](#partial-payments) for more details. |
|
||||
|
||||
### Partial Payments ###
|
||||
|
||||
A partial payment allows a payment to succeed by reducing the amount received, instead of increasing the `SendMax`. Partial payments are useful for [returning payments](https://wiki.ripple.com/Returning_payments) without incurring additional costs to oneself.
|
||||
|
||||
By default, the `Amount` field of a Payment transaction specifies the amount of currency that is *received* by the account that is the destination of the payment. Any additional amount needed for fees or currency exchange is deducted from the sending account's balances, up to the `SendMax` amount. (If `SendMax` is not specified, that is equivalent to setting the `SendMax` to the `Amount` field.) If the amount needed in order to make the payment exceeds the `SendMax` parameter, or the full amount cannot be delivered for any other reason, the transaction fails.
|
||||
|
||||
The [*tfPartialPayment* flag](#payment-flags) allows you to make a "partial payment" instead. When this flag is enabled for a payment, it delivers as much as possible, up to the `Amount` value, without exceeding the `SendMax` value. Fees and currency exchange rates are calculated the same way, but the amount being sent automatically scales down until the total amount deducted from the sending account's balances is within `SendMax`. The transaction is always considered successful as long as it delivers any positive amount. This means that partial payments can succeed at sending *some* of the intended value despite limitations including fees, lack of liquidity, insufficient space in the receiving account's trustlines, or other reasons.
|
||||
|
||||
A partial payment cannot provide the initial XRP to fund an account; this case returns the error code `telNO_DST_PARTIAL`. Direct XRP-to-XRP payments also cannot be partial payments `temBAD_SEND_XRP_PARTIAL`.
|
||||
|
||||
The amount of XRP used for the [transaction fee](#transaction-fees) is always deducted from the sender’s account, regardless of the *tfPartialPayment* flag.
|
||||
|
||||
#### Partial Payments Warning ####
|
||||
|
||||
When the [*tfPartialPayment* flag](#payment-flags) is enabled, the `Amount` field __*is not guaranteed to be the amount received*__. In fact, __*there is no minimum guaranteed amount*__ that a partial payment actually delivers. Validated partial payment transactions have a `meta.DeliveredAmount` field, which indicates the amount of currency actually received by the destination account. When receiving a payment, you should confirm that, if the `meta.DeliveredAmount` field exists, you use that to determine how much your account received instead of relying on the `Amount` field.
|
||||
|
||||
*Note:* Early partial payments in historical ledgers do not have this field. If necessary, you can check the balance changes in the `meta` field to determine how much the destination account actually received.
|
||||
|
||||
|
||||
|
||||
|
||||
## AccountSet ##
|
||||
|
||||
An AccountSet transaction modifies the properties of an account object in the global ledger.
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/SetAccount.cpp "Source")
|
||||
|
||||
An AccountSet transaction modifies the properties of an [account in the global ledger]((https://wiki.ripple.com/Ledger_Format#AccountRoot).
|
||||
|
||||
Example AccountSet:
|
||||
|
||||
@@ -301,12 +377,12 @@ Example AccountSet:
|
||||
```
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
|-------|-----------|--------------------------------------------------------|-------------|
|
||||
| [ClearFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Unique identifier of a flag to disable for this account. |
|
||||
| [Domain](#domain) | String | VariableLength | (Optional) The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. |
|
||||
| EmailHash | String | Hash128 | (Optional) Hash of an email address to be used for generating an avatar image. Conventionally, clients use [Gravatar](http://en.gravatar.com/site/implement/hash/) to display this image. |
|
||||
| MessageKey | String | PubKey | (Optional) Public key for sending encrypted messages to this account. Conventionally, it should be a secp256k1 key, the same encryption that is used by the rest of Ripple |
|
||||
| [SetFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Unique identifier of a flag to enable for this account. |
|
||||
| MessageKey | String | PubKey | (Optional) Public key for sending encrypted messages to this account. Conventionally, it should be a secp256k1 key, the same encryption that is used by the rest of Ripple. |
|
||||
| [SetFlag](#accountset-flags) | Unsigned Integer | UInt32 | (Optional) Integer flag to enable for this account. |
|
||||
| [TransferRate](#transferrate) | Unsigned Integer | UInt32 | (Optional) The fee to charge when users transfer this account's issuances, represented as billionths of a unit. Use `0` to set no fee. |
|
||||
| WalletLocator | String | Hash256 | (Optional) Not used. |
|
||||
| WalletSize | Unsigned Integer | UInt32 | (Optional) Not used. |
|
||||
@@ -317,14 +393,16 @@ If none of these options are provided, then the AccountSet transaction has no ef
|
||||
|
||||
The `Domain` field is represented as the hex string of the lowercase ASCII of the domain. For example, the domain *example.com* would be represented as `"6578616d706c652e636f6d"`.
|
||||
|
||||
Client applications can use the [ripple.txt](https://ripple.com/wiki/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain.
|
||||
To remove the `Domain` field from an account, send an AccountSet with the Domain set to an empty string.
|
||||
|
||||
Client applications can use the [ripple.txt](https://ripple.com/wiki/Ripple.txt) file hosted by the domain to confirm that the account is actually operated by that domain. *Note:* We expect the *host-meta* component of [Gateway Services](https://wiki.ripple.com/Gateway_Services) to replace ripple.txt for this purpose.
|
||||
|
||||
### AccountSet Flags ###
|
||||
|
||||
There are several options which can be either enabled or disabled for an account. Account Options are represented by different types of flags depending on the situation:
|
||||
There are several options which can be either enabled or disabled for an account. Account options are represented by different types of flags depending on the situation:
|
||||
|
||||
* The `AccountSet` transaction type has several "AccountSet Flags" (prefixed *asf*) that can enable an option when passed as the `SetFlag` parameter, or disable an option when passed as the `ClearFlag` parameter.
|
||||
* The `AccountSet` transaction type has several **DEPRECATED** transaction flags (prefixed *tf*) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is deprecated, and new account options will not have new corresponding transaction flags.
|
||||
* The `AccountSet` transaction type has several transaction flags (prefixed *tf*) that can be used to enable or disable specific account options when passed in the `Flags` parameter. This style is discouraged, and new account options will not have new corresponding transaction flags.
|
||||
* The `AccountRoot` ledger node type has several ledger-specific-flags (prefixed *lsf*) which represent the state of particular account options within a particular ledger. Naturally, the values apply until a later ledger version changes them.
|
||||
|
||||
The preferred way to enable and disable Account Flags is using the `SetFlag` and `ClearFlag` parameters of an AccountSet transaction. AccountSet flags have names that begin with *asf*.
|
||||
@@ -336,14 +414,25 @@ The available AccountSet flags are:
|
||||
| Flag Name | Decimal Value | Description | Corresponding Ledger Flag |
|
||||
|-----------|---------------|-------------|---------------------------|
|
||||
| asfRequireDest | 1 | Require a destination tag to send transactions to this account. | lsfRequireDestTag |
|
||||
| asfRequireAuth | 2 | Require authorization for users to extend trust to this account. (This prevents users unknown to a gateway from holding funds issued by that gateway.) | lsfRequireAuth |
|
||||
| asfRequireAuth | 2 | Require authorization for users to hold balances issued by this account. (This prevents users unknown to a gateway from holding funds issued by that gateway.) | lsfRequireAuth |
|
||||
| asfDisallowXRP | 3 | XRP should not be sent to this account. (Enforced by client applications, not by `rippled`) | lsfDisallowXRP |
|
||||
| asfDisableMaster | 4 | Disallow use of the master key. Can only be enabled if the account has a [RegularKey](#setregularkey) configured. | lsfDisableMaster |
|
||||
| asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [PreviousTxnID](#previoustxnid) | (None) |
|
||||
| asfAccountTxnID | 5 | Track the ID of this account's most recent transaction. Required for [AccountTxnID](#accounttxnid) | (None) |
|
||||
| asfNoFreeze | 6 | Permanently give up the ability to freeze individual trust lines. This flag can never be cleared. | lsfNoFreeze |
|
||||
| asfGlobalFreeze | 7 | Freeze/Unfreeze all assets issued by this account | lsfGlobalFreeze |
|
||||
| asfGlobalFreeze | 7 | Freeze all assets issued by this account. | lsfGlobalFreeze |
|
||||
|
||||
The following [Transaction flags](#flags), specific to the AccountSet transaction type, serve the same purpose, but are discouraged:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Replaced by AccountSet Flag |
|
||||
|-----------|-----------|---------------|-----------------------------|
|
||||
| tfRequireDestTag | 0x00010000 | 65536 | asfRequireDest (SetFlag) |
|
||||
| tfOptionalDestTag | 0x00020000 | 131072 | asfRequireDest (ClearFlag) |
|
||||
| tfRequireAuth | 0x00040000 | 262144 | asfRequireAuth (SetFlag) |
|
||||
| tfOptionalAuth | 0x00080000 | 524288 | asfRequireAuth (ClearFlag) |
|
||||
| tfDisallowXRP | 0x00100000 | 1048576 | asfDisallowXRP (SetFlag) |
|
||||
| tfAllowXRP | 0x00200000 | 2097152 | asfDisallowXRP (ClearFlag) |
|
||||
|
||||
|
||||
The following [Transaction flags](#flags), specific to the AccountSet transaction type, are **DEPRECATED**: *tfRequireDestTag*, *tfOptionalDestTag*, *tfRequireAuth*, *tfOptionalAuth*, *tfDisallowXRP*, *tfAllowXRP*.
|
||||
|
||||
#### Blocking Incoming Transactions ####
|
||||
|
||||
@@ -351,7 +440,7 @@ Incoming transactions with unclear purposes may be an inconvenience for some gat
|
||||
|
||||
For example, a destination tag is typically used to identify which hosted balance should be credited when the gateway receives a payment. If the destination tag is omitted, it may be unclear which account should be credited, creating a need for refunds, among other problems. By using the `asfRequireDest` tag, the gateway (or any account) can ensure that every incoming payment has a destination tag, which makes it harder to send an ambiguous payment by accident.
|
||||
|
||||
Accounts can protect against unwanted incoming payments for non-XRP currencies simply by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to meet the reserve and make a transaction that disabled the flag, the account would never be able to send another transaction.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.
|
||||
Accounts can protect against unwanted incoming payments for non-XRP currencies simply by not creating trust lines in those currencies. Since XRP does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XRP to an account. However, this flag is not enforced in `rippled` because it could potentially cause accounts to become unusable. (If an account did not have enough XRP to send a transaction that disabled the flag, the account would be completely unusable.) Instead, client applications should disallow or discourage XRP payments to accounts with the `asfDisallowXRP` flag enabled.
|
||||
|
||||
### TransferRate ###
|
||||
|
||||
@@ -367,59 +456,98 @@ For example, if HighFeeGateway issues USD and sets the `TransferRate` to 1200000
|
||||
|
||||
A SetRegularKey transaction changes the regular key used by the account to sign future transactions.
|
||||
|
||||
```
|
||||
{
|
||||
"Flags": 0,
|
||||
"TransactionType": "SetRegularKey",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12",
|
||||
"RegularKey": "rAR8rR8sUkBoCZFawhkWzY4Y5YoyuznwD"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| RegularKey | String | PubKey | <span class='draft-comment'>(Optional?)</span> Public key of a new keypair to use as the regular key to this account, as a base-58-encoded string; or the value `0` to remove the existing regular key. |
|
||||
|-------|-----------|--------------------------------------------------------|-------------|
|
||||
| RegularKey | String | Account | (Optional) The public key of a new keypair, to use as the regular key to this account, as a base-58-encoded string in the same format as an account address. If omitted, removes the existing regular key. |
|
||||
|
||||
Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too.)
|
||||
Instead of using an account's master key to sign transactions, you can set an alternate key pair, called the "Regular Key". As long as the public key for this key pair is set in the `RegularKey` field of an account this way, then the secret of the Regular Key pair can be used to sign transactions. (The master secret can still be used, too, unless you set the [asfDisableMaster account flag](#accountset-flags).)
|
||||
|
||||
A Regular Key pair can be changed, but a Master Key pair is an intrinsic part of the account's identity (the address is derived from the master public key) so the Master Key cannot be changed. Therefore, using a Regular Key whenever possible is beneficial to security.
|
||||
A Regular Key pair is generated in the same way as any other Ripple keys (for example, with [wallet_propose](rippled-apis.html#wallet-propose)), but it can be changed. A Master Key pair is an intrinsic part of the account's identity (the address is derived from the master public key) so the Master Key cannot be changed. Therefore, using a Regular Key to sign transactions instead of the master key whenever possible is beneficial to security.
|
||||
|
||||
When the Regular Key is compromised, you can use the this transaction type to change it. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee exactly one time ever. To do so, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's master key. (This way, you can potentially take back your account even if an attacker has already used up all the account's spare XRP.) <span class='draft-comment'>(Note: confirm that this is still exactly how that works.)</span>
|
||||
If your regular key is compromised, but the master key is not, you can use this method to regain control of your account. As a special feature, each account is allowed to perform SetRegularKey transaction *without* a transaction fee as long as the [*lsfPasswordSpent* flag](https://wiki.ripple.com/Ledger_Format#AccountRoot) for the account is not set. To use this feature, submit a SetRegularKey transaction with a `Fee` value of 0, signed by the account's *master key*. (This way, you don't have to worry about whether the attacker has used up all the account's spare XRP.) The [*lsfPasswordSpent* flag]() is automatically cleared if your account receives a payment of XRP.
|
||||
|
||||
|
||||
|
||||
## OfferCreate ##
|
||||
|
||||
An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and typically creates an Offer node in the global ledger. Offers can be partially fulfilled.
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CreateOffer.cpp "Source")
|
||||
|
||||
An OfferCreate transaction is effectively a [limit order](http://en.wikipedia.org/wiki/limit_order). It defines an intent to exchange currencies, and creates an Offer node in the global ledger if not completely fulfilled when placed. Offers can be partially fulfilled.
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType": "OfferCreate",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108682,
|
||||
"Sequence": 8,
|
||||
"TakerGets": "6000000",
|
||||
"TakerPays": {
|
||||
"currency": "GKO",
|
||||
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
|
||||
"value": "2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| [Expiration](#expiration) | Unsigned Integer | UInt32 | (Optional) Time after which the offer is no longer active, in seconds since the Ripple Epoch. |
|
||||
| OfferSequence | Unsigned Integer | UInt32 | (Optional) The sequence number of a previous OfferCreate transaction. If specified, cancel any offer node in the ledger that was created by that transaction. |
|
||||
|-------|-----------|--------------------------------------------------------|-------------|
|
||||
| [Expiration](#expiration) | Unsigned Integer | UInt32 | (Optional) Time after which the offer is no longer active, in [seconds since the Ripple Epoch](rippled-apis.html#specifying-time). |
|
||||
| OfferSequence | Unsigned Integer | UInt32 | (Optional) The sequence number of a previous OfferCreate transaction. If specified, cancel any offer node in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
|
||||
| TakerGets | Object (Non-XRP), or <br/>String (XRP) | Amount | The amount and type of currency being provided by the offer creator. |
|
||||
| TakerPays | Object (Non-XRP), or <br/>String (XRP) | Amount | The amount and type of currency being requested by the offer creator. |
|
||||
|
||||
### Lifecycle of an Offer ###
|
||||
|
||||
When an OfferCreate transaction is processed, it automatically consumes matching offers to the extent possible. (These matching offers may even provide a better exchange rate than specified in the offer; if so, the offer creator could pay less than the full `TakerGets` amount in order to receive the entire `TakerPays` amount.) If that does not completely fulfill the `TakerPays` amount, then the offer becomes a passive offer node in the ledger. (You can use [OfferCreate Flags](#offercreate-flags) to modify this behavior.)
|
||||
When an OfferCreate transaction is processed, it automatically consumes matching or crossing offers to the extent possible. (If existing offers provide a better rate than requested, the offer creator could pay less than the full `TakerGets` amount in order to receive the entire `TakerPays` amount.) If that does not completely fulfill the `TakerPays` amount, then the offer becomes an Offer node in the ledger. (You can use [OfferCreate Flags](#offercreate-flags) to modify this behavior.)
|
||||
|
||||
An offer in the ledger can be fulfilled either by additional OfferCreate transactions that match up with the existing offers, or by [Payments](#payment) that use the offer to connect the payment path. Offers can be partially fulfilled and partially funded.
|
||||
|
||||
<span class='draft-comment'>Offer fulfillment ignores trust limits and creates a trust lines with a zero limit as necessary. If an insufficient reserve from the offer maker is available to create the line, the offer is considered unfunded. (Explanation needed)</span>
|
||||
You can create an Offer so long as you have at least some (any positive, nonzero amount) of the currency specified by the `TakerGets` parameter of the offer. Any amount of that currency you have, up to the `TakerGets` amount, will be sold until the `TakerPays` amount is satisfied. An offer cannot place anyone in debt.
|
||||
|
||||
You can create an Offer so long as you have at least some <span class='draft-comment'>(details needed)</span> of the currency specified by the `TakerGets` parameter of the offer. Any amount of that currency you have, up to the `TakerGets` amount, will be sold until the `TakerPays` amount is satisfied. An offer cannot place anyone in debt.
|
||||
It is possible for an offer to become temporarily or permanently *unfunded*:
|
||||
|
||||
It is possible for an offer to become temporarily *unfunded*:
|
||||
|
||||
* The creator no longer has any of the `TakerGets` currency.
|
||||
* The offer will become funded again when the creator obtains more of that currency.
|
||||
* If the creator no longer has any of the `TakerGets` currency.
|
||||
* The offer becomes funded again when the creator obtains more of that currency.
|
||||
* If the currency required to fund the offer is held in a [frozen trust line](https://wiki.ripple.com/Freeze).
|
||||
* The offer will become funded again when the trust line is no longer frozen.
|
||||
* The offer becomes funded again when the trust line is no longer frozen.
|
||||
* If the creator does not have enough XRP for the reserve amount of a new trust line required by the offer. (See [Offers and Trust](#offers-and-trust).)
|
||||
* The offer becomes funded again when the creator obtains more XRP, or the reserve requirements decrease.
|
||||
* If the Expiration time included in the offer is later than the close time of the most recently-closed ledger. (See [Expiration](#expiration).)
|
||||
|
||||
An offer becomes *permanently* inactive when any of the following happen:
|
||||
An unfunded transaction can remain on the ledger indefinitely, but it does not have any effect. The only ways an offer can be *permanently* removed from the ledger are:
|
||||
|
||||
* It becomes fully claimed by a Payment or a matching OfferCreate transaction.
|
||||
* The Expiration date included in the offer is prior to the most recently-closed ledger. (See [Expiration](#expiration).)
|
||||
* A subsequent OfferCancel or OfferCreate transaction explicitly cancels the offer.
|
||||
* <span class='draft-comment'>The creator of the offer places a new offer that crosses it (categorically? or just if the two offers cancel out? Does tfPassive matter?)</span>
|
||||
* <span class='draft-comment'>Unfunded offers are deleted when encountered during transaction processing. (Even if they might become funded later?)</span>
|
||||
* A subsequent OfferCreate from the same account crosses the earlier offer. (In this case, the older offer is automatically canceled.)
|
||||
* An offer is found to be unfunded during transaction processing, typically because it was at the tip of the orderbook.
|
||||
* This includes cases where one side or the other of an offer is found to be closer to 0 than `rippled`'s precision supports.
|
||||
* *Note:* there is a bug that can cause offers to be removed incorrectly in rare circumstances. (See [RIPD-456](https://ripplelabs.atlassian.net/browse/RIPD-456) for status.)
|
||||
|
||||
### Offers and Trust ###
|
||||
|
||||
The limit values of trust lines (See [TrustSet](#trustset)) do not affect offers. In other words, you can use an offer to acquire more than the maximum amount you trust an issuing gateway to redeem.
|
||||
|
||||
However, possessing non-XRP balances still requires a trust line to the account issuing those balances. When an offer is taken, it automatically creates any necessary trust lines, setting their limits to 0. Because [trust lines increase the reserve an account must hold](https://wiki.ripple.com/Reserves), any offers that would require a new trust line also require the account to have the necessary XRP to pay the reserve for that trust line.
|
||||
|
||||
A trust line indicates an issuer you trust enough to accept their issuances as payment, within limits. Offers are explicit instructions to acquire certain issuances, so they are allowed to go beyond those limits.
|
||||
|
||||
### Offer Preference ###
|
||||
|
||||
Existing offers are grouped by "quality", which is measured as the ratio between `TakerGets` and `TakerPays`. Offers with a higher quality are taken preferentially. (That is, the person accepting the offer receives as much as possible for the amount of currency they pay out.) Offers with the same quality are taken on the basis of which offer was placed in the earliest ledger version.
|
||||
|
||||
When offers of the same quality are placed in the same ledger version, the "canonical order" of the transactions, as agreed by consensus, determines which is taken first. <span class='draft-comment'>(Confirm what determines canonical order. This behavior has to be well-defined so that independent servers can remain in sync.)</span>
|
||||
When offers of the same quality are placed in the same ledger version, the order in which they are taken is determined by the [canonical order](https://github.com/ripple/rippled/blob/f65cea66ef99b1de149c02c15f06de6c61abf360/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering") in which the transactions were [applied to the ledger](https://github.com/ripple/rippled/blob/develop/src/ripple/app/consensus/LedgerConsensus.cpp#L1404-L1507 "Source: Applying transactions"). This behavior is designed to be deterministic, efficient, and hard to game.
|
||||
|
||||
### Expiration ###
|
||||
|
||||
@@ -435,19 +563,35 @@ Transactions of the OfferCreate type support additional values in the [`Flags` f
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
|-----------|-----------|---------------|-------------|
|
||||
| tfPassive | 0x00010000 | 65536 | If enabled, the offer will go straight to being a node in the ledger, without trying to consume matching offers first. |
|
||||
| tfPassive | 0x00010000 | 65536 | If enabled, the offer will not consume offers that exactly match it, and instead becomes an Offer node in the ledger. It will still consume offers that cross it. |
|
||||
| tfImmediateOrCancel | 0x00020000 | 131072 | Treat the offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). If enabled, the offer will never become a ledger node: it only attempts to match existing offers in the ledger. |
|
||||
| tfFillOrKill | 0x00040000 | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). Only attempt to match existing offers in the ledger, and only do so if the entire `TakerPays` quantity can be obtained. |
|
||||
| tfSell | 0x00080000 | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |
|
||||
|
||||
<span class='draft-comment'>(Some combinations of these are disallowed, right? For example, tfPassive vs. tfImmediateOrCancel seem mutually exclusive.)</span>
|
||||
The following invalid flag combination prompts a temINVALID_FLAG error:
|
||||
|
||||
* tfImmediateOrCancel and tfFillOrKill
|
||||
|
||||
## OfferCancel ##
|
||||
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/CancelOffer.cpp "Source")
|
||||
|
||||
An OfferCancel transaction removes an Offer node from the global ledger.
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType": "OfferCancel",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108629,
|
||||
"OfferSequence": 6,
|
||||
"Sequence": 7
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
|-------|-----------|--------------------------------------------------------|-------------|
|
||||
| OfferSequence | Unsigned Integer | UInt32 | The sequence number of the offer to cancel. |
|
||||
|
||||
*Tip:* To remove an old offer and replace it with a new one, you can use an [OfferCreate](#offercreate) transaction with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
|
||||
@@ -457,27 +601,46 @@ The OfferCancel method returns [tesSUCCESS](https://ripple.com/wiki/Transaction_
|
||||
|
||||
## TrustSet ##
|
||||
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/app/transactors/SetTrust.cpp "Source")
|
||||
|
||||
Create or modify a trust line linking two accounts.
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType": "TrustSet",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 262144,
|
||||
"LastLedgerSequence": 8007750,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rsP3mgGb2tcYUrxiLFiHJiQXhsziegtwBc",
|
||||
"value": "100"
|
||||
},
|
||||
"Sequence": 12
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| LimitAmount | Object | Amount | The maximum amount of currency, issued by the other party, that that the account is willing to hold. |
|
||||
| QualityIn | Unsigned Integer | UInt32 | (Optional) <span class='draft-comment'>% fee for incoming value on this line, represented as an integer over 1,000,000,000</span> |
|
||||
| QualityOut | Unsigned Integer | UInt32 | (Optional) <span class='draft-comment'>% fee for outgoing value on this line, represented as an integer over 1,000,000,000</span> |
|
||||
|
||||
<span class='draft-comment'>(Where do you specify which account you're extending trust to? In the LimitAmount object?</span>
|
||||
| [LimitAmount](#trust-limits) | Object | Amount | Object defining the trust line to create or modify, in the same format as [currency amounts](rippled-apis.html#specifying-currency-amounts). |
|
||||
| LimitAmount.currency | String | (Amount.currency) | The currency to this trust line applies to, as a three-letter [ISO 4217 Currency Code](http://www.xe.com/iso4217.php) or a 160-bit hex value according to [currency format](https://wiki.ripple.com/Currency_format). "XRP" is invalid. |
|
||||
| LimitAmount.value | String | (Amount.value) | Quoted decimal representation of the limit to set on this trust line. |
|
||||
| LimitAmount.issuer | String | (Amount.issuer) | The address of the account to extend trust to. |
|
||||
| QualityIn | Unsigned Integer | UInt32 | (Optional) % fee for incoming value on this line, represented as an integer over 1,000,000,000. A value of `0` is shorthand for no fee. |
|
||||
| QualityOut | Unsigned Integer | UInt32 | (Optional) % fee for outgoing value on this line, represented as an integer over 1,000,000,000. A value of `0` is shorthand for no fee. |
|
||||
|
||||
### Trust Limits ###
|
||||
|
||||
All balances on the Ripple Network, except for XRP, represent money owed in the real world. The account that issues those funds in Ripple (identified by the `issuer` field of the currency object) is responsible for paying money back, outside of the Ripple Network, when users redeem their Ripple balances by returning them to the issuing account.
|
||||
All balances on the Ripple Network, except for XRP, represent value owed in the world outside the Ripple Ledger. The account that issues those funds in Ripple (identified by the `issuer` field of the `LimitAmount` object) is responsible for paying the balance back, outside of the Ripple Network, when users redeem their Ripple balances by returning them to the issuing account.
|
||||
|
||||
Since a computer program cannot force the gateway to keep its promise and not default in real life, trust lines represent a way of configuring how much you are willing to trust the issuing account to hold on your behalf. Since a large, reputable issuing gateway is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuing account "owe" you (off the network) for the funds that you hold on the network. In the case that the issuing account defaults or goes out of business, you can lose up to that much money because the balances you hold in the Ripple Network can no longer be exchanged for equivalent balances off the network.
|
||||
Since a computer program cannot force the gateway to keep its promise and not default in real life, trust lines represent a way of configuring how much you are willing to trust the issuing account to hold on your behalf. Since a large, reputable issuing gateway is more likely to be able to pay you back than, say, your broke roommate, you can set different limits on each trust line, to indicate the maximum amount you are willing to let the issuing account "owe" you (off the network) for the funds that you hold on the network. In the case that the issuing gateway defaults or goes out of business, you can lose up to that much money because the balances you hold in the Ripple Network can no longer be exchanged for equivalent balances off the network. (The Ripple Ledger will still reflect that you possess the same balance with that issuing gateway, but you won't be able to redeem, making it unlikely to be worth anything.)
|
||||
|
||||
A trust line with a limit of 0 is equivalent to no trust line.
|
||||
There are two cases where you can hold a balance on a trust line that is *greater* than your limit: when you acquire more of that currency through [trading](#offercreate), or when you decrease the limit on your trust line.
|
||||
|
||||
### Quality ###
|
||||
Since a trust line occupies space in the ledger, [a trust line increases the XRP your account must hold in reserve](https://wiki.ripple.com/Reserves). This applies to the account extending trust, not to the account receiving it.
|
||||
|
||||
<span class='draft-comment'>(TODO)</span>
|
||||
A trust line with a limit *and* a balance of 0 is equivalent to no trust line.
|
||||
|
||||
### TrustSet Flags ###
|
||||
|
||||
@@ -486,20 +649,16 @@ Transactions of the TrustSet type support additional values in the [`Flags` fiel
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
|-----------|-----------|---------------|-------------|
|
||||
| tfSetAuth | 0x00010000 | 65536 | Authorize the other party to hold issuances from this account. (No effect unless using the [*asfRequireAuth* AccountSet flag](#accountset-flags).) Cannot be unset. |
|
||||
| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. |
|
||||
| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. |
|
||||
| tfSetNoRipple | 0x00020000 | 131072 | Blocks rippling between two trustlines of the same currency, if this flag is set on both. (See [No Ripple](https://wiki.ripple.com/No_Ripple) for details.) |
|
||||
| tfClearNoRipple | 0x00040000 | 262144 | Clears the No-Rippling flag. (See [No Ripple](https://wiki.ripple.com/No_Ripple) for details.) |
|
||||
| tfSetFreeze | 0x00100000 | 1048572 | [Freeze](https://wiki.ripple.com/Freeze) the trustline.
|
||||
| tfClearFreeze | 0x00200000 | 2097152 | Unfreeze the trustline. |
|
||||
|
||||
### High Account, Low Account ###
|
||||
|
||||
Trust lines are conceptualized as one-directional lines controlled by a single party; however, for optimization purposes, they are represented in the ledger as a single trust two-way trust line. Each account that is a party to a trust line is arbitrarily deemed either the "High" or "Low" account (depending on which one has higher the numerical representation of their account address). Flags and values generally apply to one or the other side of the trust line. <span class='draft-comment'>(This section should probably be rewritten or removed. It doesn't feel useful right now. Maybe more relevant in the ledger format page?)</span>
|
||||
|
||||
# Pseudo-Transactions #
|
||||
|
||||
Pseudo-Transactions are never submitted by users, nor propagated through the network. Instead, a server may choose to inject them in a proposed ledger directly. If enough servers inject an equivalent pseudo-transaction for it to pass consensus, then it becomes included in the ledger, and appears in ledger data thereafter.
|
||||
|
||||
Some of the fields that are mandatory for normal transactions do not make sense for psuedo-transactions. In those cases, the pseudo-transaction has the following default values:
|
||||
Some of the fields that are mandatory for normal transactions do not make sense for pseudo-transactions. In those cases, the pseudo-transaction has the following default values:
|
||||
|
||||
| Field | Default Value |
|
||||
|-------|---------------|
|
||||
@@ -509,27 +668,15 @@ Some of the fields that are mandatory for normal transactions do not make sense
|
||||
| SigningPubKey | "" |
|
||||
| Signature | "" |
|
||||
|
||||
## Amendment ##
|
||||
|
||||
A new feature. <span class='draft-comment'>Not implemented?</span>
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| Amendment | N/A | Hash256 | A unique identifier for the new feature or rule change to be applied. |
|
||||
|
||||
<span class='draft-comment'>(Supposedly there's a several-weeks-long waiting period before an Amendment applies. How is that determined? Based on closed ledger time, presumably?)</span>
|
||||
|
||||
<span class='draft-comment'>(TODO)</span>
|
||||
|
||||
## Fee ##
|
||||
|
||||
A change in transaction or account fees. This is typically in response to changes in the load on the network.
|
||||
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|---------------|-------------|
|
||||
| BaseFee | <span class='draft-comment'>String (quoted integer?)</span> | UInt64 | The charge, in drops, for the reference transaction |
|
||||
| ReferenceFeeUnits | <span class='draft-comment'>Unsigned Integer?</span> | UInt32 | The cost, in fee units, of the reference transaction |
|
||||
| ReserveBase | <span class='draft-comment'>Unsigned Integer?</span> | UInt32 | The base reserve, in drops |
|
||||
| ReserveIncrement | <span class='draft-comment'>Unsigned Integer?</span> |UInt32 | The incremental reserve, in drops |
|
||||
*Note:* There have been very few, if any, Fee psuedo-transactions, ever. It is possible, but very unlikely, that you may encounter one in a historical ledger.
|
||||
|
||||
<span class='draft-comment'>(TODO)</span>
|
||||
| Field | JSON Type | [Internal Type](https://wiki.ripple.com/Binary_Format) | Description |
|
||||
|-------|-----------|--------------------------------------------------------|-------------|
|
||||
| BaseFee | String (Quoted Integer) | UInt64 | The charge, in drops, for the reference transaction. (See [Transaction Fee Terminology](https://ripple.com/wiki/Transaction_Fee#Fee_Terminology) |
|
||||
| ReferenceFeeUnits | Unsigned Integer | UInt32 | The cost, in fee units, of the reference transaction |
|
||||
| ReserveBase | Unsigned Integer | UInt32 | The base reserve, in drops |
|
||||
| ReserveIncrement | Unsigned Integer | UInt32 | The incremental reserve, in drops |
|
||||
|
||||
213
websocket_api.md
213
websocket_api.md
@@ -1,5 +1,5 @@
|
||||
# WebSocket and JSON-RPC APIs #
|
||||
If you want to communicate directly with the `rippled` server, you have three fairly similar options for how to do that. All of these APIs use the same list of commands, with almost entirely the same parameters in each command. Whereas the [Ripple-REST API](?p=ripple-rest-api) provides a simplified interface on top of the WebSocket API for easier integration, these APIs provide the full power of Ripple but require slightly more complexity:
|
||||
If you want to communicate directly with the `rippled` server, you have three fairly similar options for how to do that. All of these APIs use the same list of commands, with almost entirely the same parameters in each command. Whereas the [Ripple-REST API](ripple-rest.html) provides a simplified interface on top of the WebSocket API for easier integration, these APIs provide the full power of Ripple but require slightly more complexity:
|
||||
|
||||
* The WebSocket API uses the [WebSocket protocol](http://www.html5rocks.com/en/tutorials/websockets/basics/), available in most browsers and Javascript implementations, to achieve persistent two-way communication. There is not a 1:1 correlation between requests and responses. Some requests prompt the server to send multiple messages back asynchronously; other times, responses may arrive in a different order than the requests that prompted them.
|
||||
* The JSON-RPC API relies on simple request-response communication via HTTP. For commands that prompt multiple responses, you can provide a callback URL.
|
||||
@@ -386,6 +386,12 @@ Depending on how the `rippled` server is configured, how long it has been runnin
|
||||
|
||||
*Note:* The distinction between `full`, `validating`, and `proposing` is based on synchronization with the rest of the global network, and it is normal for a server to fluctuate between these states as a course of general operation.
|
||||
|
||||
## Modifying the Ledger ##
|
||||
|
||||
All changes to Ripple's global shared ledger happen as the result of transactions. Consequently, this means that there is *only one* public API method that causes a change in the state of the Ripple Network at all: the [*submit*](#submit) command. Most of the other methods represent different ways to view the data represented in the Ripple Network, and the remaining ones just generate data for your convenience. (The [wallet_propose](#wallet-propose), [path_find](#path-find), and [random](#random) commands fall into this category.)
|
||||
|
||||
For more information on the various transactions you can submit, consult the [Transaction Format](transactions.html).
|
||||
|
||||
# API Methods #
|
||||
|
||||
API methods for the Websocket and JSON-RPC APIs are defined by command names, and are divided into Public Commands and Admin Commands. Public Commands are not necessarily meant for the general public, but they are used by any client attached to the server. (Think of Public Commands as being for members or customers of the organization running the server, while the Admin Commands are for the personnel in charge of keeping the server operational.) Public Commands include the general operations for Ripple use, including checking the state of the ledger, finding a path to connecting users, and submitting a transaction, among others. Admin Commands, on the other hand, are meant only for the operators of the server, and include commands for managing the state of the server, the nodes it uses for validation, and other administrative features.
|
||||
@@ -438,6 +444,7 @@ The `rippled` application, in addition to acting as a server, can be run (as a s
|
||||
Accounts are the core unit of authentication in the Ripple Network. Each account can hold balances in multiple currencies, and all transactions must be signed by an account's secret key. In order for an account to exist in a validated ledger version, it must hold a minimum reserve amount of XRP. (The [reserve for an account](https://ripple.com/wiki/Reserves) increases with the amount of data it is responsible for in the shared ledger.) It is expected that accounts will correspond loosely to individual users.
|
||||
|
||||
## account_info ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountInfo.cpp "Source")
|
||||
|
||||
The `account_info` command retrieves information about an account, its activity, and its XRP balance. All information retrieved is relative to a particular version of the ledger.
|
||||
|
||||
@@ -526,17 +533,18 @@ The response follows the [standard format](#response-formatting), with the resul
|
||||
| account_data | Object | Information about the requested account |
|
||||
| account_data.Account | String | Address of the requested account |
|
||||
| account_data.Balance | String | XRP balance in "drops" represented as a string |
|
||||
| account_data.Flags | 32-bit unsigned integer | Integer with different bits representing the status of several [account flags](https://ripple.com/wiki/Transactions#AccountSet_.283.29) |
|
||||
| account_data.Flags | 32-bit unsigned integer | Integer with different bits representing the status of several [account flags](transactions.html#accountset-flags) |
|
||||
| account_data.LedgerEntryType | String | "AccountRoot" is the type of ledger entry that holds an account's data |
|
||||
| account_data.OwnerCount | Integer | Number of other ledger entries (specifically, trust lines and offers) attributed to this account. This is used to calculate the total reserve required to use the account. |
|
||||
| account_data.PreviousTxnID | String | Hash value representing the most recent transaction that affected this account |
|
||||
| account_data.Sequence | Integer | The sequence number of the next valid transaction for this account. (Each account starts with Sequence = 1 and increases each time a transaction is made.) |
|
||||
| account_data.index | String | (Deprecated) Data on another deterministic wallet that can be derived from the account's secret. (Not widely supported; this feature may be dropped in the future.) |
|
||||
| account_data.index | String | A unique index for the AccountRoot node that represents this account in the ledger. |
|
||||
| ledger_current_index | Integer | (Omitted if `ledger_index` is provided instead) The sequence number of the most-current ledger, which was used when retrieving this information. The information does not contain any changes from ledgers newer than this one. |
|
||||
| ledger_index | Integer | (Omitted if `ledger_current_index` is provided instead) The sequence number of the ledger used when retrieving this information. The information does not contain any changes from ledgers newer than this one. |
|
||||
| validated | Boolean | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-275)) True if this data is from a validated ledger version; if omitted or set to false, this data is not final. |
|
||||
| validated | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. ([New in version 0.26](https://ripplelabs.atlassian.net/browse/RIPD-275)) |
|
||||
|
||||
## account_lines ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountLines.cpp "Source")
|
||||
|
||||
The `account_lines` method returns information about the account's lines of trust, including balances in all non-XRP currencies and assets. All information retrieved is relative to a particular version of the ledger.
|
||||
|
||||
@@ -579,11 +587,11 @@ The request accepts the following paramters:
|
||||
| ledger_hash | String | (Optional) A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-a-ledger-instance)) |
|
||||
| ledger_index | String or Unsigned Integer| (Optional) The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-a-ledger-instance))|
|
||||
| peer | String | (Optional) A unique ID for a second account. If provided, show only lines of trust connecting the two accounts. |
|
||||
| limit | Integer | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-343), Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. |
|
||||
| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-343)) Server-provided value to specify where to resume retrieving data from. |
|
||||
|
||||
The following parameters are deprecated and may be removed without further notice: `ledger` and `peer_index`.
|
||||
|
||||
This method may be changed in the future to provide better scalability. See [RIPD-343](https://ripplelabs.atlassian.net/browse/RIPD-343) for details and status.
|
||||
|
||||
#### Response Format ####
|
||||
|
||||
An example of a successful response:
|
||||
@@ -884,6 +892,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
|-------|------|-------------|
|
||||
| account | String | Unique address of the account this request corresponds to |
|
||||
| lines | Array | Array of trust-line objects, as described below. |
|
||||
| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-343)) Server-defined value. Pass this to the next call in order to resume where this call left off. |
|
||||
|
||||
Each trust-line object has some combination of the following fields, although not necessarily all of them:
|
||||
|
||||
@@ -899,7 +908,9 @@ Each trust-line object has some combination of the following fields, although no
|
||||
| quality_in | Unsigned Integer | Ratio for incoming [transit fees](https://ripple.com/wiki/Transit_Fees) represented in billionths. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
|
||||
| quality_out | Unsigned Integer | Ratio for outgoing [transit fees](https://ripple.com/wiki/Transit_Fees) represented in billionths. (For example, a value of 500 million represents a 0.5:1 ratio.) As a special case, 0 is treated as a 1:1 ratio. |
|
||||
|
||||
|
||||
## account_offers ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountOffers.cpp "Source")
|
||||
|
||||
The `account_offers` method retrieves a list of offers made by a given account that are outstanding as of a particular ledger version.
|
||||
|
||||
@@ -948,11 +959,11 @@ A request can include the following parameters:
|
||||
| ledger | Unsigned integer, or String | (Deprecated, Optional) A unique identifier for the ledger version to use, such as a ledger sequence number, a hash, or a shortcut such as "validated". |
|
||||
| ledger_hash | String | (Optional) A 20-byte hex string identifying the ledger version to use. |
|
||||
| ledger_index | (Optional) Unsigned integer, or String | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See Ledger Indexes.) |
|
||||
| limit | Integer | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-344), Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. |
|
||||
| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-344)) Server-provided value to specify where to resume retrieving data from. |
|
||||
|
||||
The following parameter is deprecated and may be removed without further notice: `ledger`.
|
||||
|
||||
*Note:* This method may be changed in the future to support better scalability. See [RIPD-344](https://ripplelabs.atlassian.net/browse/RIPD-344) for details and status.
|
||||
|
||||
#### Response Format ####
|
||||
|
||||
An example of a successful response:
|
||||
@@ -1003,6 +1014,8 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
|-------|------|-------------|
|
||||
| account | String | Unique address identifying the account that made the offers |
|
||||
| offers | Array | Array of objects, where each object represents an offer made by this account that is outstanding as of the requested ledger version. |
|
||||
| marker | (Not Specified) | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-344)) Server-defined value. Pass this to the next call in order to resume where this call left off. |
|
||||
|
||||
|
||||
Each offer object contains the following fields:
|
||||
|
||||
@@ -1014,6 +1027,7 @@ Each offer object contains the following fields:
|
||||
| taker_pays | String or Object | The amount the account accepting the offer provides, as a String representing an amount in XRP, or a currency specification object. (See [Specifying Currency Amounts](#specifying-currency-amounts)) |
|
||||
|
||||
## account_tx ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountTx.cpp "Source")
|
||||
|
||||
The `account_tx` method retrieves a list of transactions that involved the specified account.
|
||||
|
||||
@@ -1082,7 +1096,8 @@ The request includes the following parameters:
|
||||
| limit | Integer | (Optional, default varies) Limit the number of transactions to retrieve. The server is not required to honor this value. |
|
||||
| marker | (Not Specified) | Server-provided value to specify where to resume retrieving data from. |
|
||||
|
||||
There is also a deprecated legacy variation of the `account_tx` method. For that reason, we recommend *not using any of the following fields*: `offset`, `count`, `descending`, `ledger_max`, `ledger_min`
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/AccountTxSwitch.cpp "Source")
|
||||
There is also a deprecated legacy variation of the `account_tx` method. For that reason, we recommend *not using any of the following fields*: `offset`, `count`, `descending`, `ledger_max`, `ledger_min`.
|
||||
|
||||
##### Iterating over queried data ######
|
||||
|
||||
@@ -1594,6 +1609,7 @@ Each transaction object includes the following fields, depending on whether it w
|
||||
| validated | Boolean | Whether or not the transaction is included in a validated ledger. Any transaction not yet in a validated ledger is subject to change. |
|
||||
|
||||
## wallet_propose ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/WalletPropose.cpp "Source")
|
||||
|
||||
Use the `wallet_propose` method to generate the keys needed for a new account. The account created this way will only become officially included in the Ripple network when it receives a transaction that provides enough XRP to meet the account reserve. (The `wallet_propose` command does not affect the global network. Technically, it is not strictly necessary for creating a new account: you could generate keys some other way, but that is not recommended.)
|
||||
|
||||
@@ -1669,7 +1685,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| public_key | String | The public key of the account, in encoded string format. |
|
||||
| public_key_hex | String | The public key of the account, in hex format. |
|
||||
|
||||
The key generated by this method can also be used as a regular key for an account if you use the [SetRegularKey transaction type](https://ripple.com/wiki/index.php/API_Example_Transactions#Set_Regular_Key) to do so.
|
||||
The key generated by this method can also be used as a regular key for an account if you use the [SetRegularKey transaction type](transactions.html#setregularkey) to do so.
|
||||
|
||||
|
||||
|
||||
@@ -1678,6 +1694,7 @@ The key generated by this method can also be used as a regular key for an accoun
|
||||
The globally-shared ledger is the core of the Ripple Network. Each `rippled` server keeps a current version of the ledger, which contains all the accounts, transactions, offers, and other data in the network in an optimized tree format. As transactions and offers are proposed, each server incorporates them into its current copy of the ledger, closes it periodically, and (if configured) participates in the process of advancing the globally-validated version. After concensus is reached in the network, that ledger version is validated and becomes permanently immutable. Any transactions that were not included in one ledger become candidates to be included in the next validated version.
|
||||
|
||||
## ledger ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Ledger.cpp "Source")
|
||||
|
||||
Retrieve information about the public ledger.
|
||||
|
||||
@@ -1730,8 +1747,8 @@ The request can contain the following parameters:
|
||||
| transactions | Boolean | (Optional, defaults to false) If true, return information on transactions in the specified ledger version. |
|
||||
| full | Boolean | (Optional, defaults to false) If true, return full information on the entire ledger. (Equivalent to enabling `transactions`, `accounts`, and `expand` *Admin required* |
|
||||
| expand | Boolean | (Optional, defaults to false) Provide full JSON-formatted information for transaction/account information instead of just hashes |
|
||||
| ledger_hash | String | (Optional) A 20-byte hex string identifying the ledger version to use. |
|
||||
| ledger_index | (Optional) Unsigned integer, or String | (Optional, defaults to `current`) The sequence number of the ledger to use, or "current", "closed", or "validated" to select a ledger dynamically. (See Ledger Indexes.) |
|
||||
| ledger_hash | String | (Optional) A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-a-ledger-instance)) |
|
||||
| ledger_index | String or Unsigned Integer| (Optional) The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-a-ledger-instance))|
|
||||
|
||||
The `ledger` field is deprecated and may be removed without further notice.
|
||||
|
||||
@@ -1799,11 +1816,13 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| parent_hash | String | Unique identifying hash of the ledger that came immediately before this one. |
|
||||
| total_coins | String | Total number of XRP drops in the network, as a quoted integer. (This decreases as transaction fees cause XRP to be destroyed.) |
|
||||
| transaction_hash | String | Hash of the transaction information included in this ledger, as hex |
|
||||
| validated | Boolean | ([Upcoming](https://ripplelabs.atlassian.net/browse/RIPD-569)) If included and set to `true`, the information in this request describes a validated ledger version. Otherwise, the information is subject to change. |
|
||||
|
||||
The following fields are deprecated and may be removed without further notice: `hash`, `seqNum`, `totalCoins`.
|
||||
|
||||
|
||||
## ledger_closed ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerClosed.cpp "Source")
|
||||
|
||||
The `ledger_closed` method returns the unique identifiers of the most recently closed ledger. (This ledger is not necessarily validated and immutable yet.)
|
||||
|
||||
@@ -1878,6 +1897,8 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| ledger_index | Unsigned Integer | Sequence number of this ledger |
|
||||
|
||||
## ledger_current ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerCurrent.cpp "Source")
|
||||
|
||||
The `ledger_current` method returns the unique identifiers of the current in-progress ledger. This command is mostly useful for testing, because the ledger returned is still in flux.
|
||||
|
||||
#### Request Format ####
|
||||
@@ -1952,6 +1973,8 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
A `ledger_hash` field is not provided, because the hash of the current ledger is constantly changing along with its contents.
|
||||
|
||||
## ledger_data ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerData.cpp "Source")
|
||||
|
||||
The `ledger_data` method retrieves contents of the specified ledger. You can iterate through several calls in order to retrieve the entire contents of a single ledger version.
|
||||
|
||||
#### Request Format ####
|
||||
@@ -2193,6 +2216,8 @@ The format of each object in the `state` array depends on whether `binary` was s
|
||||
|
||||
|
||||
## ledger_entry ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/LedgerEntry.cpp "Source")
|
||||
|
||||
The `ledger_entry` method returns a single entry from the specified ledger. See [LedgerEntryType](https://ripple.com/wiki/Ledger_Format#Entries) for information on the different types of objects you can retrieve. *Note:* There is no commandline version of this method. You can use the [`json`](#json) command to access this method from the commandline instead.
|
||||
|
||||
#### Request Format ####
|
||||
@@ -2230,11 +2255,11 @@ An example of the request format:
|
||||
|
||||
This method can retrieve several different types of data. You can select which type of item to retrieve by passing the appropriate parameters. Specifically, you should provide exactly one of the following fields:
|
||||
|
||||
1. `index` - Retrieve an individual ledger entry by its unique index
|
||||
1. `index` - Retrieve an individual ledger node by its unique index
|
||||
2. `account_root` - Retrieve an account node, similar to the [account_info](#account-info) command
|
||||
3. `directory` - Retrieve a directory node, which contains a list of IDs linking things
|
||||
4. `offer` - Retrieve an offer node, which defines an offer to exchange currency
|
||||
5. `ripple_state` - Retrieve a RippleState node, which defines currency (IOU) balances and credit limits between accounts
|
||||
5. `ripple_state` - Retrieve a RippleState node, which a trust line along which non-XRP balances are held
|
||||
|
||||
If you specify more than one of the above items, the server will retrieve only of them; it is undefined which one will be chosen.
|
||||
|
||||
@@ -2255,8 +2280,10 @@ The full list of parameters recognized by this method is as follows:
|
||||
| ripple_state.accounts | Array | (Required if `ripple_state` specified) 2-length array of account address strings, defining the two accounts linked by this RippleState entry |
|
||||
| ripple_state.currency | String | (Required if `ripple_state` specified) String representation of a currency that this RippleState entry relates to, as either a 3-letter currency code or a 40-character hex code |
|
||||
| binary | Boolean | (Optional, defaults to false) If true, return hashed data as hex strings. Otherwise, return data in JSON format. |
|
||||
| ledger_hash | String | (Optional) A 20-byte hex string for the ledger version to use. (See [Specifying a Ledger](#specifying-a-ledger-instance)) |
|
||||
| ledger_index | String or Unsigned Integer| (Optional) The sequence number of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying a Ledger](#specifying-a-ledger-instance))|
|
||||
|
||||
The `generator` parameter is deprecated and may be removed without further notice.
|
||||
The `generator` and `ledger` parameters are deprecated and may be removed without further notice.
|
||||
|
||||
#### Response Format ####
|
||||
|
||||
@@ -2326,6 +2353,7 @@ Transactions are the only thing that can modify the shared global ledger of the
|
||||
There are several sources of complication in transactions. Unlike traditional banking, where a trusted third party (the bank, or the [ACH](http://en.wikipedia.org/wiki/Automated_Clearing_House)) verifies the participants' identities and ensures their balances are adjusted accurately, Ripple uses cryptography and decentralized computing power to accomplish the same thing. Sending XRP, the Ripple Network's native crypto-currency, requires no third party aside from the distributed network itself. However, that is missing out on the key feature of Ripple: unlike individual crypto-currencies, the Ripple Network natively supports balances in any currency. This brings far more power, but it also means that the system must account for [counterparty risk](http://en.wikipedia.org/wiki/Counterparty_risk#Counterparty_risk), currency conversions, and other issues. The Ripple Network must be robust to keep track of which transactions have been completely validated, even when subject to hardware failures, attacks, or natural disasters.
|
||||
|
||||
## tx ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Tx.cpp "Source")
|
||||
|
||||
The `tx` method retrieves information on a single transaction.
|
||||
|
||||
@@ -2503,7 +2531,7 @@ An example of a successful response:
|
||||
```
|
||||
</div>
|
||||
|
||||
The response follows the [standard format](#response-formatting), with a successful result containing the fields of the [Transaction object](https://ripple.com/wiki/Transaction_Format) as well as the following additional fields:
|
||||
The response follows the [standard format](#response-formatting), with a successful result containing the fields of the [Transaction object](transactions.html) as well as the following additional fields:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
@@ -2512,11 +2540,12 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| ledger_index | Unsigned Integer | The sequence number of the ledger that includes this transaction. |
|
||||
| meta | Object | Various metadata about the transaction. |
|
||||
| validated | Boolean | True if this data is from a validated ledger version; if omitted or set to false, this data is not final. |
|
||||
| (Various) | (Various) | Other fields from the [Transaction object](https://ripple.com/wiki/Transaction_Format) |
|
||||
| (Various) | (Various) | Other fields from the [Transaction object](transactions.html) |
|
||||
|
||||
*Note:* If the transaction was not found, it means that the rippled server could not find it from the ledger versions on hand. However, that does not mean that the transaction does not exist; it may simply have been included in an older ledger version that the `rippled` does not have on hand anymore.
|
||||
|
||||
## transaction_entry ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/TransactionEntry.cpp "Source")
|
||||
|
||||
The `transaction_entry` method retrieves information on a single transaction from a specific ledger version. (The [`tx`](#tx) command, by contrast, searches all ledgers for the specified transaction. We recommend using that method instead.)
|
||||
|
||||
@@ -2706,7 +2735,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| ledger_index | Unsigned Integer | Sequence number of the ledger version the transaction was found in; this is the same as the one from the request. |
|
||||
| ledger_hash | String | (May be omitted) Unique hash of the ledger version the transaction was found in; this is the same as the one from the request. |
|
||||
| metadata | Object | Various metadata about the transaction. |
|
||||
| tx_json | Object | JSON representation of the [Transaction object](https://ripple.com/wiki/Transaction_Format) |
|
||||
| tx_json | Object | JSON representation of the [Transaction object](transactions.html) |
|
||||
|
||||
There are a couple possible reasons the server may fail to find the transaction:
|
||||
|
||||
@@ -2715,6 +2744,7 @@ There are a couple possible reasons the server may fail to find the transaction:
|
||||
* The server does not have the specified ledger version available. Another server that has the correct version on hand may have a different response.
|
||||
|
||||
## tx_history ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/TxHistory.cpp "Source")
|
||||
|
||||
The `tx_history` method retrieves a selection of the most recent transactions made.
|
||||
|
||||
@@ -3591,9 +3621,10 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| index | Unsigned Integer | The value of `start` used in the request. |
|
||||
| txs | Array | Array of transaction objects. |
|
||||
|
||||
The fields included in each transaction object vary slightly depending on the type of transaction. See [Transaction Format](https://ripple.com/wiki/Transaction_Format) for details.
|
||||
The fields included in each transaction object vary slightly depending on the type of transaction. See [Transaction Format](transactions.html) for details.
|
||||
|
||||
## path_find ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp "Source")
|
||||
|
||||
*WebSocket API only!* The `path_find` method searches for a path along which a transaction can possibly be made, and periodically sends updates when the path changes over time. For a simpler version that is supported by JSON-RPC, see [`ripple_path_find`](#ripple-path-find). For payments occurring strictly in XRP, it is not necessary to find a path, because XRP can be sent directly to any account.
|
||||
|
||||
@@ -3606,6 +3637,7 @@ There are three different modes, or sub-commands, of the path_find command. Spec
|
||||
Although the `rippled` server attempts to find the cheapest path or combination of paths for making a payment, it is not guaranteed that the paths returned by this method are, in fact, the best paths. Due to server load, pathfinding may not find the best results. Additionally, you should be careful with the pathfinding results from untrusted servers. A server could be modified to return less-than-optimal paths in order to earn money for its operators. If you do not have your own server that you can trust with pathfinding, you should compare the results of pathfinding from multiple servers operated by different parties, to minimize the risk of a single server returning poor results. (*Note:* A server returning less-than-optimal results is not necessarily proof of malicious behavior; it could also be a symptom of heavy server load.)
|
||||
|
||||
### path_find create ###
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp#L38 "Source")
|
||||
|
||||
The `create` subcommand of `path_find` creates an ongoing request to find possible paths along which a payment transaction could be made from one specified account such that another account receives a desired amount of some currency. The initial response contains a suggested path between the two addresses that would result in the desired amount being received. After that, the server sends additional messages, with `"type": "path_find"`, with updates to the potential paths. The frequency of updates is left to the discretion of the server, but it usually means once every few seconds when there is a new ledger version.
|
||||
|
||||
@@ -4884,6 +4916,7 @@ Here is an example of an asychronous follow-up from a path_find create request:
|
||||
</div>
|
||||
|
||||
### path_find close ###
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp#L46 "Source")
|
||||
|
||||
The `close` subcommand of `path_find` instructs the server to stop sending information about the current open pathfinding request.
|
||||
|
||||
@@ -4912,6 +4945,7 @@ The request includes the following parameters:
|
||||
If a pathfinding request was successfully closed, the response follows the same format as the initial response to [`path_find create`](#path_find-create). If there was no outstanding pathfinding request, an error is returned instead.
|
||||
|
||||
### path_find status ###
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/PathFind.cpp#L57 "Source")
|
||||
|
||||
The `status` subcommand of `path_find` requests an immediate update about the client's currently-open pathfinding request.
|
||||
|
||||
@@ -4941,6 +4975,7 @@ If a pathfinding request is open, the response follows the same format as the in
|
||||
|
||||
|
||||
## ripple_path_find ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/RipplePathFind.cpp "Source")
|
||||
|
||||
The `ripple_path_find` method is a simplified version of [`path_find`](#path-find) that provides a single response to be used to make a payment transaction immediately. It is available in both the WebSocket and JSON-RPC APIs. However, the results tend to become outdated as time passes. Instead of making many subsequent calls, you should use [`path_find`](#path-find) instead where possible.
|
||||
|
||||
@@ -5257,10 +5292,11 @@ Each element in the `alternatives` array is an object that represents a path fro
|
||||
The following fields are deprecated, and may be omitted: `paths_canonical`, and `paths_expanded`. If they appear, you should disregard them.
|
||||
|
||||
## sign ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Sign.cpp "Source")
|
||||
|
||||
The `sign` method takes a transaction, specified as JSON, and a secret key, and returns a signed binary representation of the transaction that can be submitted. The result is always different, even when you provide the same transaction and secret key.
|
||||
The `sign` method takes a transaction, specified as JSON, and a secret key, and returns a signed binary representation of the transaction that can be submitted. The result is always different, even when you provide the same transaction JSON and secret key.
|
||||
|
||||
*Note:* It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you.
|
||||
*Note:* It is possible and preferable to sign a transaction without connecting to a server instead of using this command. For example, [ripple-lib's rsign.js](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js) demonstrates offline signing of a transaction. You should prefer to do offline signing of a transaction, especially when you do not control the server you are sending a transaction to. An untrustworthy server can abuse its position to change the transaction before signing it, or worse, use your secret to sign additional arbitrary transactions as if they came from you.
|
||||
|
||||
#### Request Format ####
|
||||
An example of the request format:
|
||||
@@ -5316,18 +5352,24 @@ rippled -- sign sssssssssssssssssssssssssssss '{"TransactionType": "Payment", "A
|
||||
```
|
||||
</div>
|
||||
|
||||
[Try it! >](ripple-api-tool.html#sign)
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| tx_json | Object | [Transaction definition](https://ripple.com/wiki/Transaction_Format) in JSON format |
|
||||
| tx_json | Object | [Transaction definition](transactions.html) in JSON format |
|
||||
| secret | String | Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
|
||||
| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. |
|
||||
| build_path | Boolean | (Optional) If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. *Caution:* The server looks for the presence or absence of this field, not its value. This behavior may change. (See [RIPD-173](https://ripplelabs.atlassian.net/browse/RIPD-173) for status.) |
|
||||
| fee\_mult\_max | Integer | (Optional) If the transaction `Fee` is omitted, this field limits the `Fee` value that is automatically filled so that it is less than or equal to the long-term base fee times this value. |
|
||||
|
||||
The server automatically attempts to fill in certain fields from the `tx_json` object if they are omitted, unless you specified `offline` as true. Otherwise, the following fields are automatic:
|
||||
The server automatically attempts to fill in certain fields from the `tx_json` object if they are omitted, unless you specified `offline` as true. Otherwise, the following fields from the [transaction format](transactions.html) are automatically filled in:
|
||||
|
||||
* `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request.
|
||||
* `Fee` - The server can automatically fill in an appropriate transaction fee (in drops of XRP) unless you specified `offline` as true. Otherwise, you must fill in the appropriate fee. Be careful: a malicious server can specify an excessively high fee.
|
||||
* `Sequence` - The server automatically uses the next Sequence number from the sender's account information. Be careful: the next sequence number for the account is not incremented until this transaction is applied. If you sign multiple transactions without submitting and waiting for the response to each one, you must provide the correct sequence numbers in the request. Automatically filled unless `offline` is true.
|
||||
* `Fee` - The server can automatically fill in an appropriate transaction fee (in drops of XRP) unless you specified `offline` as true. Otherwise, you must fill in the appropriate fee. Be careful: a malicious server can specify an excessively high fee. Automatically filled unless `offline` is true.
|
||||
* If `fee_mult_max` is included, and the automatically generated Fee is greater than the long-term base fee times `fee_mult_max`, then the transaction fails with the error `rpcHIGH_FEE`. This way, you can let the server fill in the current minimum `Fee` value as long as the current load fee is not too high.
|
||||
* `Paths` - For Payment-type transactions (excluding XRP-to-XRP transfers), the Paths field can be automatically filled, as if you did a [ripple_path_find](#ripple-path-find). Only filled if `build_path` is provided.
|
||||
|
||||
#### Response Format ####
|
||||
|
||||
@@ -5394,7 +5436,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| tx_blob | String | Binary representation of the fully-qualified, signed transaction, as hex |
|
||||
| tx_json | Object | JSON specification of the [complete transaction](https://ripple.com/wiki/Transaction_Format) as signed, including any fields that were automatically filled in |
|
||||
| tx_json | Object | JSON specification of the [complete transaction](transactions.html) as signed, including any fields that were automatically filled in |
|
||||
|
||||
*Warning:* If this command results in an error messages, the message can contain the account secret from the request. Make sure that these errors are not visible to others, including:
|
||||
|
||||
@@ -5403,8 +5445,75 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
* Do not display the error message on a website, even by accident
|
||||
|
||||
## submit ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Submit.cpp "Source")
|
||||
|
||||
The `submit` method sends a transaction to the network to be confirmed and included in future ledgers. There are two ways to use it: either you can supply JSON along with your secret key (not recommended), or you can take a pre-signed transaction blob (for example, one created with [`sign`](#sign), or better yet, something [signed offline](https://github.com/ripple/ripple-lib/blob/develop/bin/rsign.js)) and submit it as-is.
|
||||
The `submit` method sends a [transaction](transactions.html) to the network to be confirmed and included in future ledgers.
|
||||
|
||||
This command has two modes:
|
||||
|
||||
* Submit-only mode takes a signed, serialized transaction as a binary blob, and submits it to the network as-is. Since signed transaction objects are immutable, no portion of the transaction can be modified or automatically filled in after submission.
|
||||
* Sign-and-submit mode takes a JSON-formatted Transaction object, completes and signs the transaction in the same manner as the [sign command](#sign), and then submits the signed transaction. We recommend only using this mode for testing and development.
|
||||
|
||||
To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction.
|
||||
|
||||
### Submit-Only Mode ###
|
||||
|
||||
A submit-only request includes the following parameters:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| tx_blob | String | Hex representation of the signed transaction to submit. |
|
||||
| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
|
||||
|
||||
#### Request Format ####
|
||||
|
||||
|
||||
<div class='multicode'>
|
||||
*WebSocket*
|
||||
```
|
||||
{
|
||||
"id": 3,
|
||||
"command": "submit",
|
||||
"tx_blob": "1200002280000000240000001E61D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000B732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7447304502210095D23D8AF107DF50651F266259CC7139D0CD0C64ABBA3A958156352A0D95A21E02207FCF9B77D7510380E49FF250C21B57169E14E9B4ACFD314CEDC79DDD0A38B8A681144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
```
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"tx_blob": "1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*Commandline*
|
||||
```
|
||||
#Syntax: submit tx_blob
|
||||
submit 1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754
|
||||
```
|
||||
</div>
|
||||
|
||||
[Try it! >](ripple-api-tool.html#submit)
|
||||
|
||||
|
||||
### Sign-and-Submit Mode ###
|
||||
|
||||
A sign-and-submit request includes the following parameters:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| tx_json | Object | [Transaction definition](transactions.html) in JSON format, optionally omitting any auto-fillable fields. |
|
||||
| secret | String | (Required if `tx_json` is supplied) Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
|
||||
| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
|
||||
| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. |
|
||||
| build_path | Boolean | (Optional) If provided for a Payment-type transaction, automatically fill in the `Paths` field before signing. You must omit this field if the transaction is a direct XRP-to-XRP transfer. *Caution:* The server looks for the presence or absence of this field, not its value. This behavior may change. (See [RIPD-173](https://ripplelabs.atlassian.net/browse/RIPD-173) for status.) |
|
||||
| fee\_mult\_max | Integer | (Optional) If the transaction `Fee` is omitted, this field limits the `Fee` value that is automatically filled so that it is less than or equal to the long-term base fee times this value. |
|
||||
|
||||
See the [sign command](#sign) for detailed information on how the server automatically fills in certain fields.
|
||||
|
||||
#### Request Format ####
|
||||
An example of the request format:
|
||||
@@ -5435,7 +5544,17 @@ An example of the request format:
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"tx_blob": "1200002280000000240000000361D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000A732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74473045022100D184EB4AE5956FF600E7536EE459345C7BBCF097A84CC61A93B9AF7197EDB98702201CEA8009B7BEEBAA2AACC0359B41C427C1C5B550A4CA4B80CF2174AF2D6D5DCE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
|
||||
"secret": "sssssssssssssssssssssssssssss",
|
||||
"tx_json": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "1"
|
||||
},
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"TransactionType": "Payment"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -5450,26 +5569,6 @@ submit sssssssssssssssssssssssssssss '{"TransactionType":"Payment", "Account":"r
|
||||
|
||||
[Try it! >](ripple-api-tool.html#submit)
|
||||
|
||||
The request includes the following parameters:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| tx_blob | String | (Do not include if tx_json and secret are supplied) Hex representation of the signed transaction to submit. |
|
||||
| tx_json | Object | (Do not include if tx_blob is supplied) [Transaction definition](https://ripple.com/wiki/Transaction_Format) in JSON format |
|
||||
| secret | String | (Required if tx_json is supplied) Secret key of the account supplying the transaction, used to sign it. Do not send your secret to untrusted servers or through unsecured network connections. |
|
||||
| fail_hard | Boolean | (Optional, defaults to false) If true, and the transaction fails locally, do not retry or relay the transaction to other servers |
|
||||
| offline | Boolean | (Optional, defaults to false) If true, when constructing the transaction, do not attempt to automatically fill in or validate values. (No effect when specifying the transaction as tx_blob.) |
|
||||
|
||||
The JSON format for `tx_json` varies depending on the type of transaction. In the case of sending non-XRP currency (IOUs), you can obtain appropriate values for the `Paths` field by doing a `find_path` or `ripple_find_path` command first. The `Paths` field is not required for sending XRP. The provided path or paths are used as options for the path the payment takes; the server selects one or more of them to use according to its own criteria. You can omit the `Paths` field, but that leaves it up to the server to choose a path on the fly. Since the total cost of making the payment, including transit fees, is automatically deducted from the sending account, you should find paths ahead of time to avoid getting surprised.
|
||||
|
||||
By default, `rippled` tries to compute the cheapest combination of paths, but it may not have the resources to find the best option. A payment may even be broken up into multiple parts that take different paths if that is the cheapest way. An untrustworthy server could be modified to choose paths maliciously.
|
||||
|
||||
If `offline` is not set to true, then the server tries to automatically fill the `Sequence` and `Fee` parameters appropriately.
|
||||
|
||||
To send a transaction as robustly as possible, you should construct and [`sign`](#sign) it in advance, persist it somewhere that you can access even after a power outage, then `submit` it as a `tx_blob`. After submission, monitor the network with the [`tx`](#tx) command to see if the transaction was successfully applied; if a restart or other problem occurs, you can safely re-submit the `tx_blob` transaction: it won't be applied twice since it has the same sequence number as the old transaction.
|
||||
|
||||
You should provide a [LastLedgerSequence](https://ripple.com/wiki/Transaction_Format#Basic_Transaction_Format) field in your transaction to make sure that it expires quickly in the case that it does not succeed. Otherwise, a transaction may end up in limbo, neither failing nor confirming, for a long time.
|
||||
|
||||
#### Response Format ####
|
||||
|
||||
An example of a successful response:
|
||||
@@ -5550,11 +5649,12 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
|
||||
*Warning:* If this command results in an error messages, the message can contain an account secret, if one was provided in the request. (This is not a problem if the request contained a signed tx_blob instead.) Make sure that these errors are not visible to others, including:
|
||||
|
||||
* Do not write this error to a log file that can be seen by multiple people
|
||||
* Do not paste this error to a public place for debugging
|
||||
* Do not display the error message on a website, even by accident
|
||||
* Do not write an error including your secret to a log file that can be seen by multiple people
|
||||
* Do not paste an error including your secret to a public place for debugging
|
||||
* Do not display an error message including your secret on a website, even by accident
|
||||
|
||||
## book_offers ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/BookOffers.cpp "Source")
|
||||
|
||||
The `book_offers` method retrieves a list of offers, also known as the [order book](http://www.investopedia.com/terms/o/order-book.asp), between two currencies. If the results are very large, a partial result is returned with a marker so that subsequent requests can resume from where the previous one left off.
|
||||
|
||||
@@ -5710,7 +5810,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
| ledger_current_index | Integer | (Omitted if ledger version provided) Sequence number of the ledger version used when retrieving this data. |
|
||||
| ledger_index | Integer | (Omitted if ledger_current_index provided instead) Sequence number, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| ledger_hash | String | (May be omitted) Hex hash, provided in the request, of the ledger version that was used when retrieving this data. |
|
||||
| offers | Array | Array of offer objects, each of which has the fields of an [offer transaction](https://ripple.com/wiki/Transaction_Format#OfferCreate_.287.29) |
|
||||
| offers | Array | Array of offer objects, each of which has the fields of an [OfferCreate transaction](transactions.html#offercreate) |
|
||||
|
||||
In addition to the standard Offer fields, the following fields may be included in members of the `offers` array:
|
||||
|
||||
@@ -5726,7 +5826,9 @@ In addition to the standard Offer fields, the following fields may be included i
|
||||
Using subscriptions, you can have the server push updates to your client when various events happen, so that you can know right away and react accordingly. Subscriptions are only supported in the WebSocket API, where you can receive additional responses in the same channel.
|
||||
|
||||
JSON-RPC support for subscription callbacks is deprecated and may not work as expected.
|
||||
|
||||
## subscribe ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Subscribe.cpp "Source")
|
||||
|
||||
The `subscribe` method requests periodic notifications from the server when certain events happen.
|
||||
|
||||
@@ -5980,11 +6082,12 @@ The `accounts_proposed` subscription works the same way, except it also includes
|
||||
| ledger_hash | String | (Omitted for unvalidated transactions) Unique hash of the ledger version that includes this transaction, as hex |
|
||||
| ledger_index | Unsigned Integer | (Omitted for unvalidated transactions) Sequence number of the ledger version that includes this transaction |
|
||||
| meta | Object | (Omitted for unvalidated transactions) Various metadata about the transaction, including which ledger entries it affected |
|
||||
| transaction | Object | The [definition of the transaction](https://ripple.com/wiki/Transaction_Format) in JSON format |
|
||||
| transaction | Object | The [definition of the transaction](transactions.html) in JSON format |
|
||||
| validated | Boolean | If true, this transaction is included in a validated ledger. Responses from the `transaction` stream should always be validated. |
|
||||
|
||||
|
||||
## unsubscribe ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Unsubscribe.cpp "Source")
|
||||
|
||||
The `unsubscribe` command tells the server to stop sending messages for a particular subscription or set of subscriptions.
|
||||
|
||||
@@ -6059,6 +6162,7 @@ The response follows the [standard format](#response-formatting), with a success
|
||||
There are also commands that retrieve information about the current state of the server. These may be useful for monitoring the health of the server, or in preparing for making other API methods. For example, you may query for the current fee schedule before sending a transaction, or you may check which ledger versions are available before digging into the ledger history for a specific record.
|
||||
|
||||
## server_info ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/ServerInfo.cpp "Source")
|
||||
|
||||
The `server_info` command asks the server for a human-readable version of various information about the `rippled` server being queried.
|
||||
|
||||
@@ -6190,6 +6294,7 @@ The `info` object may have some arrangement of the following fields:
|
||||
| validation_quorum | Number | Minimum number of trusted validations required in order to validate a ledger version. Some circumstances may cause the server to require more validations. |
|
||||
|
||||
## server_state ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/ServerState.cpp "Source")
|
||||
|
||||
The `server_state` command asks the server for various machine-readable information about the `rippled` server's current state. The results are very similar to [`server_info`](#server-info), but generally the units are chosen to be easier to process instead of easier to read. (For example, XRP values are given in integer drops instead of scientific notation or decimal values, and time is given in milliseconds instead of seconds.)
|
||||
|
||||
@@ -6326,6 +6431,7 @@ The `state` object may have some arrangement of the following fields:
|
||||
The rippled server also provides a few simple commands purely for convenience.
|
||||
|
||||
## ping ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Ping.cpp "Source")
|
||||
|
||||
The `ping` command returns an acknowledgement, so that clients can test the connection status and latency.
|
||||
|
||||
@@ -6390,6 +6496,7 @@ An example of a successful response:
|
||||
The response follows the [standard format](#response-formatting), with a successful result containing no fields. The client can measure the round-trip time from request to response as latency.
|
||||
|
||||
## random ##
|
||||
[[Source]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/module/rpc/handlers/Random.cpp "Source")
|
||||
|
||||
The `random` command provides a random number to be used as a source of entropy for random number generation by clients.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user