mirror of
https://github.com/Xahau/xahau-web.git
synced 2026-08-03 12:10:53 +00:00
feat: refactor to pt-br and added more i18n pages
This commit is contained in:
Andrei Rosseti
@@ -20,7 +20,7 @@ export default defineConfig({
|
||||
locales: {
|
||||
root: { label: 'English', lang: 'en' },
|
||||
es: { label: 'Español', lang: 'es' },
|
||||
'br': { label: 'Português (Brasil)', lang: 'br' },
|
||||
'pt-br': { label: 'Português (Brasil)', lang: 'pt-BR' },
|
||||
ja: { label: '日本語', lang: 'ja' },
|
||||
},
|
||||
tableOfContents: {
|
||||
@@ -76,12 +76,12 @@ export default defineConfig({
|
||||
sidebar: [
|
||||
{
|
||||
label: 'Get started',
|
||||
translations: { es: 'Primeros pasos', ja: 'はじめる', 'br': 'Primeiros Passos' },
|
||||
translations: { es: 'Primeros pasos', ja: 'はじめる', 'pt-BR': 'Primeiros Passos' },
|
||||
items: ['docs', 'docs/what-is-different'],
|
||||
},
|
||||
{
|
||||
label: 'Features',
|
||||
translations: { es: 'Características', ja: '機能', 'br': 'Recursos' },
|
||||
translations: { es: 'Características', ja: '機能', 'pt-BR': 'Recursos' },
|
||||
items: [
|
||||
'docs/features/public-nodes-rpc',
|
||||
'docs/features/amendments',
|
||||
@@ -90,7 +90,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Firma de Transacciones',
|
||||
ja: 'トランザクション署名',
|
||||
'br': 'Assinatura de Transações',
|
||||
'pt-BR': 'Assinatura de Transações',
|
||||
},
|
||||
autogenerate: { directory: 'docs/features/transaction-signing' },
|
||||
collapsed: true,
|
||||
@@ -100,7 +100,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Herramientas para Desarrolladores',
|
||||
ja: '開発者ツール',
|
||||
'br': 'Ferramentas para Desenvolvedores',
|
||||
'pt-BR': 'Ferramentas para Desenvolvedores',
|
||||
},
|
||||
autogenerate: { directory: 'docs/features/developer-tooling' },
|
||||
collapsed: true,
|
||||
@@ -110,7 +110,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'APIs HTTP / WebSocket',
|
||||
ja: 'HTTP / WebSocket API',
|
||||
'br': 'APIs HTTP / WebSocket',
|
||||
'pt-BR': 'APIs HTTP / WebSocket',
|
||||
},
|
||||
autogenerate: { directory: 'docs/features/http-websocket-apis' },
|
||||
collapsed: true,
|
||||
@@ -120,7 +120,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Funcionalidades de Red',
|
||||
ja: 'ネットワーク機能',
|
||||
'br': 'Funcionalidades da Rede',
|
||||
'pt-BR': 'Funcionalidades da Rede',
|
||||
},
|
||||
autogenerate: { directory: 'docs/features/network-features' },
|
||||
collapsed: true,
|
||||
@@ -137,12 +137,12 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Referencia del Protocolo',
|
||||
ja: 'プロトコルリファレンス',
|
||||
'br': 'Referência do Protocolo',
|
||||
'pt-BR': 'Referência do Protocolo',
|
||||
},
|
||||
items: [
|
||||
{
|
||||
label: 'Transactions',
|
||||
translations: { es: 'Transacciones', ja: 'トランザクション', 'br': 'Transações' },
|
||||
translations: { es: 'Transacciones', ja: 'トランザクション', 'pt-BR': 'Transações' },
|
||||
collapsed: true,
|
||||
items: [
|
||||
'docs/protocol-reference/transactions',
|
||||
@@ -151,7 +151,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Tipos de Transacción',
|
||||
ja: 'トランザクションタイプ',
|
||||
'br': 'Tipos de Transação',
|
||||
'pt-BR': 'Tipos de Transação',
|
||||
},
|
||||
autogenerate: {
|
||||
directory:
|
||||
@@ -164,7 +164,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Tipos de Pseudotransacción',
|
||||
ja: '擬似トランザクションタイプ',
|
||||
'br': 'Tipos de Pseudotransação',
|
||||
'pt-BR': 'Tipos de Pseudotransação',
|
||||
},
|
||||
autogenerate: {
|
||||
directory:
|
||||
@@ -177,7 +177,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Resultados de Transacción',
|
||||
ja: 'トランザクション結果',
|
||||
'br': 'Resultados de Transação',
|
||||
'pt-BR': 'Resultados de Transação',
|
||||
},
|
||||
autogenerate: {
|
||||
directory:
|
||||
@@ -191,7 +191,7 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Ledger Data',
|
||||
translations: { es: 'Datos del Ledger', ja: 'レジャーデータ', 'br': 'Dados do Ledger' },
|
||||
translations: { es: 'Datos del Ledger', ja: 'レジャーデータ', 'pt-BR': 'Dados do Ledger' },
|
||||
collapsed: true,
|
||||
items: [
|
||||
'docs/protocol-reference/ledger-data',
|
||||
@@ -200,7 +200,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Tipos de Objetos del Ledger',
|
||||
ja: 'レジャーオブジェクトタイプ',
|
||||
'br': 'Tipos de Objetos do Ledger',
|
||||
'pt-BR': 'Tipos de Objetos do Ledger',
|
||||
},
|
||||
autogenerate: {
|
||||
directory:
|
||||
@@ -214,7 +214,7 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Data Types',
|
||||
translations: { es: 'Tipos de Datos', ja: 'データ型', 'br': 'Tipos de Dados' },
|
||||
translations: { es: 'Tipos de Datos', ja: 'データ型', 'pt-BR': 'Tipos de Dados' },
|
||||
collapsed: true,
|
||||
items: [
|
||||
'docs/protocol-reference/data-types',
|
||||
@@ -231,7 +231,7 @@ export default defineConfig({
|
||||
'docs/hooks',
|
||||
{
|
||||
label: 'Concepts',
|
||||
translations: { es: 'Conceptos', ja: 'コンセプト', 'br': 'Conceitos' },
|
||||
translations: { es: 'Conceptos', ja: 'コンセプト', 'pt-BR': 'Conceitos' },
|
||||
collapsed: true,
|
||||
items: [
|
||||
'docs/hooks/concepts/introduction',
|
||||
@@ -259,12 +259,12 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Functions',
|
||||
translations: { es: 'Funciones', ja: '関数', 'br': 'Funções' },
|
||||
translations: { es: 'Funciones', ja: '関数', 'pt-BR': 'Funções' },
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
label: 'Overview',
|
||||
translations: { es: 'Descripción General', ja: '概要', 'br': 'Visão Geral' },
|
||||
translations: { es: 'Descripción General', ja: '概要', 'pt-BR': 'Visão Geral' },
|
||||
collapsed: true,
|
||||
autogenerate: { directory: 'docs/hooks/functions/overview' },
|
||||
},
|
||||
@@ -273,7 +273,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Definidas por el Desarrollador',
|
||||
ja: '開発者定義',
|
||||
'br': 'Definidas pelo Desenvolvedor',
|
||||
'pt-BR': 'Definidas pelo Desenvolvedor',
|
||||
},
|
||||
collapsed: true,
|
||||
autogenerate: {
|
||||
@@ -287,7 +287,7 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Utilities',
|
||||
translations: { es: 'Utilidades', ja: 'ユーティリティ', 'br': 'Utilitários' },
|
||||
translations: { es: 'Utilidades', ja: 'ユーティリティ', 'pt-BR': 'Utilitários' },
|
||||
collapsed: true,
|
||||
autogenerate: { directory: 'docs/hooks/functions/utilities' },
|
||||
},
|
||||
@@ -296,7 +296,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Serialización',
|
||||
ja: 'シリアライゼーション',
|
||||
'br': 'Serialização',
|
||||
'pt-BR': 'Serialização',
|
||||
},
|
||||
collapsed: true,
|
||||
autogenerate: {
|
||||
@@ -308,7 +308,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Transacción Emitida',
|
||||
ja: '発行トランザクション',
|
||||
'br': 'Transação Emitida',
|
||||
'pt-BR': 'Transação Emitida',
|
||||
},
|
||||
collapsed: true,
|
||||
autogenerate: {
|
||||
@@ -330,7 +330,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Contexto del Hook',
|
||||
ja: 'フックコンテキスト',
|
||||
'br': 'Contexto do Hook',
|
||||
'pt-BR': 'Contexto do Hook',
|
||||
},
|
||||
collapsed: true,
|
||||
autogenerate: {
|
||||
@@ -344,7 +344,7 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'State',
|
||||
translations: { es: 'Estado', ja: '状態', 'br': 'Estado' },
|
||||
translations: { es: 'Estado', ja: '状態', 'pt-BR': 'Estado' },
|
||||
collapsed: true,
|
||||
autogenerate: { directory: 'docs/hooks/functions/state' },
|
||||
},
|
||||
@@ -353,7 +353,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Traza (Debug)',
|
||||
ja: 'トレース（デバッグ）',
|
||||
'br': 'Rastreamento (Debug)',
|
||||
'pt-BR': 'Rastreamento (Debug)',
|
||||
},
|
||||
collapsed: true,
|
||||
autogenerate: {
|
||||
@@ -365,7 +365,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Transacción de Origen',
|
||||
ja: '発信トランザクション',
|
||||
'br': 'Transação de Origem',
|
||||
'pt-BR': 'Transação de Origem',
|
||||
},
|
||||
collapsed: true,
|
||||
autogenerate: {
|
||||
@@ -389,7 +389,7 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Compliance',
|
||||
translations: { es: 'Cumplimiento', ja: 'コンプライアンス', 'br': 'Conformidade' },
|
||||
translations: { es: 'Cumplimiento', ja: 'コンプライアンス', 'pt-BR': 'Conformidade' },
|
||||
items: [
|
||||
'docs/compliance/security-audit',
|
||||
'docs/compliance/responsible-disclosure',
|
||||
@@ -397,7 +397,7 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Infrastructure',
|
||||
translations: { es: 'Infraestructura', ja: 'インフラストラクチャ', 'br': 'Infraestrutura' },
|
||||
translations: { es: 'Infraestructura', ja: 'インフラストラクチャ', 'pt-BR': 'Infraestrutura' },
|
||||
items: [
|
||||
'docs/infrastructure/system-requirements',
|
||||
'docs/infrastructure/installing-xahaud',
|
||||
@@ -411,7 +411,7 @@ export default defineConfig({
|
||||
translations: {
|
||||
es: 'Compilar xahaud (Avanzado)',
|
||||
ja: 'xahaudをビルド（上級）',
|
||||
'br': 'Compilar xahaud (Avançado)',
|
||||
'pt-BR': 'Compilar xahaud (Avançado)',
|
||||
},
|
||||
collapsed: true,
|
||||
items: [
|
||||
@@ -424,12 +424,12 @@ export default defineConfig({
|
||||
},
|
||||
{
|
||||
label: 'Resources',
|
||||
translations: { es: 'Recursos', ja: 'リソース', 'br': 'Recursos' },
|
||||
translations: { es: 'Recursos', ja: 'リソース', 'pt-BR': 'Recursos' },
|
||||
items: ['docs/resources/whitepaper', 'docs/resources/media-kit'],
|
||||
},
|
||||
{
|
||||
label: 'Support',
|
||||
translations: { es: 'Soporte', ja: 'サポート', 'br': 'Suporte' },
|
||||
translations: { es: 'Soporte', ja: 'サポート', 'pt-BR': 'Suporte' },
|
||||
autogenerate: { directory: 'docs/support' },
|
||||
},
|
||||
],
|
||||
|
||||
@@ -4,6 +4,7 @@ import SidebarPersister from '@astrojs/starlight/components/SidebarPersister.ast
|
||||
import SidebarSublist from '@astrojs/starlight/components/SidebarSublist.astro'
|
||||
|
||||
const _sidebar = Astro.locals.starlightRoute.sidebar
|
||||
console.log(_sidebar)
|
||||
---
|
||||
|
||||
<SidebarPersister>
|
||||
|
||||
@@ -25,7 +25,7 @@ import { getAlternateLocaleHref } from '../utils/localizedHref'
|
||||
const languages = [
|
||||
{ code: 'en', label: 'English' },
|
||||
{ code: 'es', label: 'Español' },
|
||||
{ code: 'br', label: 'Português (Brasil)' },
|
||||
{ code: 'pt-BR', label: 'Português (Brasil)' },
|
||||
// { code: 'ja', label: '日本語' },
|
||||
]
|
||||
|
||||
@@ -58,7 +58,7 @@ const nav = {
|
||||
infra: 'Infraestructura',
|
||||
discord: 'Discord de la Comunidad',
|
||||
},
|
||||
'br': {
|
||||
'pt-BR': {
|
||||
about: 'Sobre',
|
||||
features: 'Recursos',
|
||||
ecosystem: 'Ecossistema',
|
||||
|
||||
480
src/components/XahauAboutPtBR.astro
Normal file
480
src/components/XahauAboutPtBR.astro
Normal file
@@ -0,0 +1,480 @@
|
||||
---
|
||||
/**
|
||||
* XahauAbout.astro — Hand-crafted editorial layout (English)
|
||||
*
|
||||
* No JSON loops. Three thematic acts: Network · Protocol · Currency.
|
||||
* Matches XahauFeatures.astro philosophy exactly.
|
||||
* For ES/JA: see XahauAboutEs.astro / XahauAboutJa.astro
|
||||
*/
|
||||
|
||||
import networkGraphic from '../assets/enterprise/about-network.svg'
|
||||
import protocolGraphic from '../assets/enterprise/about-protocol.svg'
|
||||
import xahGraphic from '../assets/enterprise/about-xah.svg'
|
||||
|
||||
const videoId = '4pruN6sWJho'
|
||||
---
|
||||
|
||||
<section class="xabout" aria-label="Sobre o Xahau">
|
||||
<!-- ══ PAGE HEADER ══════════════════════════════════════════════════════ -->
|
||||
<header class="xa-head">
|
||||
<div class="xa-head-title">
|
||||
<h2>Sobre o Xahau</h2>
|
||||
<p class="xa-sub">
|
||||
Blockchain L1 empresarial com programabilidade baseada em conta
|
||||
</p>
|
||||
</div>
|
||||
<div class="xa-chips">
|
||||
<span class="xa-chip">Fund. Outubro 2023</span>
|
||||
<span class="xa-chip">200k+ Contas</span>
|
||||
<span class="xa-chip">~4s Liquidação</span>
|
||||
<span class="xa-chip">10k tx / ledger</span>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<!-- ══════════════════════════════════════════════════════════════════════
|
||||
ACT I — THE NETWORK
|
||||
══════════════════════════════════════════════════════════════════════════ -->
|
||||
<div class="xa-act act-net">
|
||||
<p class="xa-act-label"><span class="act-pip pip-grn"></span>A Rede</p>
|
||||
|
||||
<!-- O QUE É XAHAU ─ statement opener ──────────────────────────────── -->
|
||||
<div class="xa-statement stmt-net">
|
||||
<div class="xa-stmt-body">
|
||||
<span class="xa-lbl lbl-net">Visão Geral</span>
|
||||
<h3>
|
||||
O que é o Xahau?
|
||||
<br>
|
||||
A explicação rápida
|
||||
</h3>
|
||||
<p>
|
||||
O Xahau é uma blockchain L1 com uma composição única de recursos e uma
|
||||
abordagem inovadora à programabilidade de blockchain, também conhecida
|
||||
como contratos inteligentes.
|
||||
</p>
|
||||
<p>
|
||||
A tecnologia comprovada a longo prazo liquida transações em ~4 segundos
|
||||
com custos muito baixos, chegando a frações de um centavo de dólar. É
|
||||
escalável, atualmente com até 10.000 transações por ledger, e é uma
|
||||
blockchain inerentemente verde e amigável ao meio ambiente.
|
||||
</p>
|
||||
<p>
|
||||
O Xahau oferece recursos nativos para emissão e negociação de moedas na
|
||||
exchange descentralizada integrada, tokens não fungíveis nativos e
|
||||
infinitas oportunidades de DeFi com lógica personalizada através dos
|
||||
contratos inteligentes do Xahau, conhecidos como Hooks.
|
||||
</p>
|
||||
<p>
|
||||
Os Hooks vivem nas contas, oferecendo uma visão renovada de como a
|
||||
lógica personalizada pode ser usada para reagir a eventos baseados em
|
||||
conta, como o recebimento de transações. Os Hooks são desenvolvidos
|
||||
atualmente em C, mas o suporte a JavaScript já está desenvolvido e em
|
||||
testes, com outras linguagens de programação também no escopo. Isso
|
||||
coloca o mundo dos contratos inteligentes ao alcance de milhões de
|
||||
desenvolvedores, sem uma curva de aprendizado íngreme.
|
||||
</p>
|
||||
</div>
|
||||
<div class="xa-stmt-graphic">
|
||||
<img
|
||||
src={networkGraphic.src}
|
||||
width="380"
|
||||
height="380"
|
||||
alt="Ilustração da topologia de rede do Xahau"
|
||||
>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- VIDEO ─────────────────────────────────────────────────────────── -->
|
||||
<div class="xa-video-section">
|
||||
<div class="xa-video-wrap">
|
||||
<iframe
|
||||
src={`https://www.youtube.com/embed/${videoId}?si=IlxKDlD2LFLwS6EK`}
|
||||
title="Visão geral do Xahau"
|
||||
frameborder="0"
|
||||
allow="
|
||||
accelerometer;
|
||||
autoplay;
|
||||
clipboard-write;
|
||||
encrypted-media;
|
||||
gyroscope;
|
||||
picture-in-picture;
|
||||
web-share;
|
||||
"
|
||||
referrerpolicy="strict-origin-when-cross-origin"
|
||||
allowfullscreen
|
||||
></iframe>
|
||||
</div>
|
||||
</div>
|
||||
</div><!-- /act-net -->
|
||||
|
||||
<!-- ══════════════════════════════════════════════════════════════════════
|
||||
ACT II — THE PROTOCOL
|
||||
══════════════════════════════════════════════════════════════════════════ -->
|
||||
<div class="xa-act act-proto">
|
||||
<p class="xa-act-label">
|
||||
<span class="act-pip pip-teal"></span>O Protocolo
|
||||
</p>
|
||||
|
||||
<!-- TECNOLOGIA ─ statement opener ────────────────────────────────── -->
|
||||
<div class="xa-statement stmt-proto">
|
||||
<div class="xa-stmt-body">
|
||||
<span class="xa-lbl lbl-proto">Tecnologia</span>
|
||||
<h3>
|
||||
Qual é a tecnologia
|
||||
<br>
|
||||
por trás do Xahau?
|
||||
</h3>
|
||||
<p>
|
||||
O Xahau é uma tecnologia comprovada, sendo uma evolução do código do
|
||||
XRP Ledger, aprimorada com contrato inteligente, programabilidade
|
||||
baseada em conta (Hooks) e suporte igualitário para moedas emitidas
|
||||
em recursos nativos como escrows e canais de pagamento.
|
||||
</p>
|
||||
<p>
|
||||
O Xahau, assim como o XRPL, utiliza um mecanismo de Consenso Federado
|
||||
para validar transações. As transações são confirmadas através de um
|
||||
protocolo de consenso, no qual servidores independentes designados,
|
||||
chamados de validadores, chegam a um acordo sobre a ordem e o resultado
|
||||
das transações. Todos os servidores da rede processam cada transação
|
||||
segundo as mesmas regras, e qualquer transação que siga o protocolo é
|
||||
confirmada imediatamente. Todas as transações são públicas e
|
||||
transparentes, e qualquer pessoa pode operar um validador.
|
||||
</p>
|
||||
<p>
|
||||
O Xahau introduz um jogo de governança para garantir uma abordagem
|
||||
centrada na comunidade para a tomada de decisões da rede. Para
|
||||
participar, os membros das mesas votam. Os temas discutidos neste
|
||||
sistema de 2 camadas de mesas incluem assentos, hooks e recompensas.
|
||||
</p>
|
||||
</div>
|
||||
<div class="xa-stmt-graphic">
|
||||
<img
|
||||
src={protocolGraphic.src}
|
||||
width="380"
|
||||
height="380"
|
||||
alt="Ilustração da arquitetura do protocolo Xahau"
|
||||
>
|
||||
</div>
|
||||
</div>
|
||||
</div><!-- /act-proto -->
|
||||
|
||||
<!-- ══════════════════════════════════════════════════════════════════════
|
||||
ACT III — THE CURRENCY
|
||||
══════════════════════════════════════════════════════════════════════════ -->
|
||||
<div class="xa-act act-curr">
|
||||
<p class="xa-act-label">
|
||||
<span class="act-pip pip-vlt"></span>A Moeda
|
||||
</p>
|
||||
|
||||
<!-- XAH ─ statement opener ────────────────────────────────────────── -->
|
||||
<div class="xa-statement stmt-curr">
|
||||
<div class="xa-stmt-body">
|
||||
<span class="xa-lbl lbl-curr">Economia</span>
|
||||
<h3>
|
||||
XAH, a moeda
|
||||
<br>
|
||||
nativa do Xahau
|
||||
</h3>
|
||||
<p>
|
||||
A moeda nativa do Xahau é chamada XAH e é uma moeda inflacionária.
|
||||
Toda conta pode participar do ajuste de saldo interagindo com um Hook
|
||||
na conta genesis, acumulando mensalmente 4% do saldo da conta.
|
||||
</p>
|
||||
<p>
|
||||
O XAH é usado para prevenir spam na rede, adicionando um custo às
|
||||
transações. Transações normais custam frações de um XAH, enquanto o
|
||||
custo aumenta ao interagir com Hooks. O XAH também é exigido como
|
||||
saldo bloqueado, ou reserva, para possuir uma conta, objetos ou
|
||||
armazenar dados para consumo de contratos inteligentes.
|
||||
</p>
|
||||
<p>
|
||||
Por causa dos Hooks, a taxa de queima do XAH é maior em comparação
|
||||
com o XRPL. Para projetos que dependem de Hooks para lógica
|
||||
personalizada, recomenda-se manter um saldo de XAH capaz de gerar um
|
||||
ajuste de saldo mensal para cobrir as taxas.
|
||||
</p>
|
||||
</div>
|
||||
<div class="xa-stmt-graphic">
|
||||
<img
|
||||
src={xahGraphic.src}
|
||||
width="380"
|
||||
height="380"
|
||||
alt="Ilustração da moeda XAH"
|
||||
>
|
||||
</div>
|
||||
</div>
|
||||
</div><!-- /act-curr -->
|
||||
</section>
|
||||
|
||||
<style>
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Design tokens — mirrors XahauFeatures exactly
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xabout {
|
||||
--ink: #0f2328;
|
||||
--dim: #2d3e44;
|
||||
--mute: #556068;
|
||||
--grn2: #007a28;
|
||||
--teal2: #006f87;
|
||||
--vlt2: #4e18b8;
|
||||
--grn-hi: #00c940;
|
||||
--teal-hi: #00c4e8;
|
||||
--vlt-hi: #a050ff;
|
||||
|
||||
background: #ffffff;
|
||||
border-radius: 24px;
|
||||
padding: 48px 56px 72px;
|
||||
font-family: 'Onest', system-ui, sans-serif;
|
||||
color: var(--ink);
|
||||
box-shadow:
|
||||
0 2px 4px rgba(0, 0, 0, 0.04),
|
||||
0 20px 64px -24px rgba(15, 35, 40, 0.13);
|
||||
}
|
||||
.xabout * {
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Page header
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xa-head {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: flex-start;
|
||||
gap: 24px;
|
||||
flex-wrap: wrap;
|
||||
padding-bottom: 40px;
|
||||
}
|
||||
.xabout h2 {
|
||||
margin: 0;
|
||||
font-size: 36px;
|
||||
font-weight: 800;
|
||||
letter-spacing: -0.03em;
|
||||
line-height: 1.08;
|
||||
color: var(--ink);
|
||||
}
|
||||
.xa-sub {
|
||||
margin: 6px 0 0;
|
||||
font-size: 15px;
|
||||
color: var(--mute);
|
||||
}
|
||||
.xa-chips {
|
||||
display: flex;
|
||||
gap: 8px;
|
||||
flex-wrap: wrap;
|
||||
align-items: flex-start;
|
||||
padding-top: 4px;
|
||||
}
|
||||
.xa-chip {
|
||||
font-family: ui-monospace, monospace;
|
||||
font-size: 11px;
|
||||
padding: 5px 13px;
|
||||
border: 1px solid #cdd7dc;
|
||||
border-radius: 999px;
|
||||
color: var(--mute);
|
||||
white-space: nowrap;
|
||||
letter-spacing: 0.03em;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Acts
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xa-act {
|
||||
padding-top: 52px;
|
||||
}
|
||||
|
||||
.xa-act-label {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
font-family: ui-monospace, monospace;
|
||||
font-size: 10px;
|
||||
font-weight: 700;
|
||||
letter-spacing: 0.2em;
|
||||
text-transform: uppercase;
|
||||
color: var(--mute);
|
||||
margin: 0 0 44px;
|
||||
}
|
||||
.act-pip {
|
||||
display: block;
|
||||
width: 6px;
|
||||
height: 6px;
|
||||
border-radius: 50%;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
.pip-grn {
|
||||
background: var(--grn2);
|
||||
}
|
||||
.pip-teal {
|
||||
background: var(--teal2);
|
||||
}
|
||||
.pip-vlt {
|
||||
background: var(--vlt2);
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Labels
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xa-lbl {
|
||||
display: inline-block;
|
||||
font-family: ui-monospace, monospace;
|
||||
font-size: 10px;
|
||||
font-weight: 700;
|
||||
letter-spacing: 0.18em;
|
||||
text-transform: uppercase;
|
||||
padding: 3px 9px;
|
||||
border-radius: 4px;
|
||||
margin-bottom: 14px;
|
||||
}
|
||||
.lbl-net {
|
||||
color: var(--grn2);
|
||||
background: rgba(0, 122, 40, 0.1);
|
||||
}
|
||||
.lbl-proto {
|
||||
color: var(--teal2);
|
||||
background: rgba(0, 111, 135, 0.1);
|
||||
}
|
||||
.lbl-curr {
|
||||
color: var(--vlt2);
|
||||
background: rgba(78, 24, 184, 0.1);
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Statement sections
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xa-statement {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
}
|
||||
.xa-stmt-body {
|
||||
flex: 0 0 57%;
|
||||
max-width: 57%;
|
||||
padding: 64px 0 64px 28px;
|
||||
}
|
||||
.xa-stmt-graphic {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 32px 8px 32px 16px;
|
||||
opacity: 0.95;
|
||||
}
|
||||
.xa-stmt-graphic img {
|
||||
width: 100%;
|
||||
max-width: 340px;
|
||||
height: auto;
|
||||
display: block;
|
||||
}
|
||||
|
||||
.xa-statement h3 {
|
||||
margin: 0 0 22px;
|
||||
font-size: 40px;
|
||||
font-weight: 800;
|
||||
line-height: 1.12;
|
||||
letter-spacing: -0.03em;
|
||||
color: var(--ink);
|
||||
}
|
||||
|
||||
/* Gradient text per act */
|
||||
.stmt-net h3 {
|
||||
background: linear-gradient(140deg, #004d1a 15%, var(--grn-hi) 100%);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
background-clip: text;
|
||||
}
|
||||
.stmt-proto h3 {
|
||||
background: linear-gradient(140deg, #003d50 15%, var(--teal-hi) 100%);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
background-clip: text;
|
||||
}
|
||||
.stmt-curr h3 {
|
||||
background: linear-gradient(140deg, #2a0875 15%, var(--vlt-hi) 100%);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
background-clip: text;
|
||||
}
|
||||
|
||||
.xa-statement p {
|
||||
font-size: 15.5px;
|
||||
line-height: 1.72;
|
||||
color: var(--dim);
|
||||
margin: 0 0 16px;
|
||||
}
|
||||
.xa-statement p:last-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Video section
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xa-video-section {
|
||||
padding: 20px 28px 52px;
|
||||
}
|
||||
.xa-video-wrap {
|
||||
position: relative;
|
||||
width: 100%;
|
||||
max-width: 780px;
|
||||
margin: 0 auto;
|
||||
aspect-ratio: 16 / 9;
|
||||
border-radius: 16px;
|
||||
overflow: hidden;
|
||||
background: #000;
|
||||
box-shadow:
|
||||
0 4px 12px rgba(0, 0, 0, 0.08),
|
||||
0 24px 56px -16px rgba(0, 120, 40, 0.18);
|
||||
}
|
||||
.xa-video-wrap iframe {
|
||||
position: absolute;
|
||||
inset: 0;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
border: none;
|
||||
display: block;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Responsive
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
@media (max-width: 900px) {
|
||||
.xa-statement {
|
||||
flex-direction: column;
|
||||
align-items: flex-start;
|
||||
}
|
||||
.xa-stmt-body {
|
||||
flex: none;
|
||||
max-width: 100%;
|
||||
}
|
||||
.xa-stmt-graphic {
|
||||
width: 100%;
|
||||
padding: 0 0 32px;
|
||||
opacity: 0.85;
|
||||
}
|
||||
.xa-stmt-graphic img {
|
||||
max-width: 240px;
|
||||
margin: 0 auto;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 640px) {
|
||||
.xabout {
|
||||
padding: 32px 24px 48px;
|
||||
border-radius: 16px;
|
||||
}
|
||||
.xabout h2 {
|
||||
font-size: 28px;
|
||||
}
|
||||
.xa-statement h3 {
|
||||
font-size: 26px;
|
||||
}
|
||||
.xa-head {
|
||||
flex-direction: column;
|
||||
gap: 14px;
|
||||
}
|
||||
.xa-stmt-body {
|
||||
padding: 44px 0 44px 22px;
|
||||
}
|
||||
.xa-video-section {
|
||||
padding: 12px 22px 40px;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
@@ -12,9 +12,10 @@
|
||||
*/
|
||||
|
||||
import connectData from '../data/connect.json'
|
||||
import { normalizeLocale } from '../utils/localizedHref'
|
||||
|
||||
type Locale = 'en' | 'es' | 'ja'
|
||||
const locale = (Astro.currentLocale ?? 'en') as Locale
|
||||
type Locale = 'en' | 'es' | 'ja' | 'pt-BR'
|
||||
const locale = normalizeLocale(Astro.currentLocale ?? 'en') as Locale
|
||||
|
||||
// ── Date-based split (build time) ────────────────────────────────────────────
|
||||
const today = new Date()
|
||||
@@ -114,6 +115,33 @@ const ui = {
|
||||
contact_on_x: '（X）',
|
||||
contact_or: 'またはメール：',
|
||||
},
|
||||
'pt-BR': {
|
||||
page_title: 'Xahau Connect',
|
||||
page_sub:
|
||||
'Eventos profissionais de blockchain para discussões sérias e inovação',
|
||||
chip_inftf: 'Por INFTF',
|
||||
chip_location: 'Madri, Espanha',
|
||||
chip_upcoming: (n: number) => (n === 1 ? '1 Próximo' : `${n} Próximos`),
|
||||
lbl_upcoming: 'Próximos Eventos',
|
||||
lbl_past: 'Eventos Anteriores',
|
||||
lbl_about: 'Sobre',
|
||||
lbl_contact: 'Participe',
|
||||
no_upcoming: 'Nenhum evento agendado no momento.',
|
||||
no_upcoming_sub:
|
||||
'Siga @XahauNetwork ou envie um e-mail para connect@xahau.org para receber comunicados.',
|
||||
location_view: 'Ver no mapa',
|
||||
about_title: 'Sobre o Xahau Connect',
|
||||
mission_title: 'Nossa Missão',
|
||||
contact_title: 'Palestrantes, Patrocinadores e Contato',
|
||||
contact_body:
|
||||
'Agradecemos aos nossos parceiros que apoiam a missão do Xahau Connect de promover o debate profissional sobre blockchain. Detalhes sobre parceiros e palestrantes serão divulgados conforme confirmarmos a participação nos próximos eventos.',
|
||||
contact_speaking: 'Propostas de palestras e patrocínio:',
|
||||
contact_updates: 'Inscreva-se para receber novidades:',
|
||||
contact_follow: 'Siga',
|
||||
contact_follow2: 'e',
|
||||
contact_on_x: 'no X',
|
||||
contact_or: 'ou envie um e-mail para',
|
||||
}
|
||||
}
|
||||
const t = ui[locale]
|
||||
---
|
||||
|
||||
@@ -11,6 +11,7 @@
|
||||
*/
|
||||
|
||||
import { Image } from 'astro:assets'
|
||||
import { normalizeLocale } from '../utils/localizedHref'
|
||||
import logoAfricanUnion from '../assets/ecosystem-logos/AUPF.png'
|
||||
import logoBithomp from '../assets/ecosystem-logos/bithomp.png'
|
||||
import logoBitmart from '../assets/ecosystem-logos/bitmart.png'
|
||||
@@ -44,7 +45,7 @@ const logoMap: Record<string, ImageMetadata> = {
|
||||
quantoz: logoQuantoz,
|
||||
}
|
||||
|
||||
type Locale = 'en' | 'es' | 'ja'
|
||||
type Locale = 'en' | 'es' | 'ja' | 'pt-br'
|
||||
const locale = (Astro.currentLocale ?? 'en') as Locale
|
||||
|
||||
// Projects sorted alphabetically at build time; others keep editorial order.
|
||||
|
||||
729
src/components/XahauFeaturesPtBR.astro
Normal file
729
src/components/XahauFeaturesPtBR.astro
Normal file
@@ -0,0 +1,729 @@
|
||||
---
|
||||
/**
|
||||
* XahauFeatures.astro — Hand-crafted editorial layout
|
||||
*
|
||||
* No JSON, no loops. Each feature section is individually composed.
|
||||
* Three thematic acts: Protocol · Finance · Governance.
|
||||
* Statement openers + varied pair/trio detail sections.
|
||||
*
|
||||
* Edit content directly in this file.
|
||||
* For ES/JA: duplicate this file and translate in-place.
|
||||
*/
|
||||
|
||||
import consensusGraphic from '../assets/enterprise/consensus.svg'
|
||||
import globalGraphic from '../assets/enterprise/global.svg'
|
||||
import hooksGraphic from '../assets/enterprise/hooks.svg'
|
||||
|
||||
interface Props {
|
||||
lang?: string
|
||||
}
|
||||
const { lang = 'pt-BR' } = Astro.props
|
||||
---
|
||||
|
||||
<section class="xfeat" aria-label="Funcionalidades do Xahau">
|
||||
<!-- ══ PAGE HEADER ══════════════════════════════════════════════════════ -->
|
||||
<header class="xf-head">
|
||||
<div class="xf-head-title">
|
||||
<h2>Funcionalidades</h2>
|
||||
<p class="xf-sub">Tecnologia comprovada com uma abordagem inovadora</p>
|
||||
</div>
|
||||
<div class="xf-chips">
|
||||
<span class="xf-chip">10+ Funcionalidades de Protocolo</span>
|
||||
<span class="xf-chip">DEX Nativa</span>
|
||||
<span class="xf-chip">NFTs Integrados</span>
|
||||
<span class="xf-chip">Sem Overhead em Tempo de Execução</span>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<!-- ══════════════════════════════════════════════════════════════════════
|
||||
ACT I — PROTOCOL LAYER
|
||||
══════════════════════════════════════════════════════════════════════════ -->
|
||||
<div class="xf-act act-proto">
|
||||
<p class="xf-act-label">
|
||||
<span class="act-pip pip-grn"></span>Camada de Protocolo
|
||||
</p>
|
||||
|
||||
<!-- HOOKS ─ statement opener ────────────────────────────────────────── -->
|
||||
<div class="xf-statement stmt-proto">
|
||||
<div class="xf-stmt-body">
|
||||
<span class="xf-lbl lbl-proto">Programabilidade</span>
|
||||
<h3>
|
||||
Hooks: Lógica de
|
||||
<br>
|
||||
Contrato Inteligente
|
||||
<br>
|
||||
no Nível da Conta
|
||||
</h3>
|
||||
<p>
|
||||
O Xahau introduz os Hooks — uma forma única de lógica de contrato inteligente
|
||||
no ledger que é executada diretamente no nível da conta. Ao contrário dos contratos
|
||||
inteligentes na maioria das blockchains, que exigem interação com endereços de
|
||||
contrato externos, os Hooks são programas leves embutidos nas próprias contas dos
|
||||
usuários. Esses Hooks podem inspecionar, modificar ou rejeitar automaticamente
|
||||
qualquer transação envolvendo aquela conta, sem necessidade de chamadas de função
|
||||
explícitas.
|
||||
</p>
|
||||
<p>
|
||||
Por serem executados de forma inline e dentro do consenso, os Hooks oferecem
|
||||
programabilidade em tempo real com overhead mínimo. Isso permite casos de uso
|
||||
poderosos, como rejeitar transferências de tokens não autorizadas, disparar ações
|
||||
em depósitos ou implementar lógica de conformidade — tudo sem desacelerar a rede.
|
||||
Os Hooks representam um novo paradigma de segurança e programabilidade, tornando
|
||||
as contas participantes ativas na lógica de transações.
|
||||
</p>
|
||||
</div>
|
||||
<div class="xf-stmt-graphic">
|
||||
<img
|
||||
src={hooksGraphic.src}
|
||||
width="380"
|
||||
height="380"
|
||||
alt="Hooks smart contract logic illustration"
|
||||
>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- DEX + FEES ─ asymmetric pair ────────────────────────────────────── -->
|
||||
<div class="xf-pair pair-6040">
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-proto">Exchange</span>
|
||||
<h4>Offers: Exchange Descentralizado (DEX) Nativo</h4>
|
||||
<p>
|
||||
O Xahau inclui um sistema nativo de Offers, que alimenta uma exchange
|
||||
descentralizada integrada ao ledger. Os usuários podem criar entradas de Offer
|
||||
para comprar ou vender ativos (como tokens ou moedas emitidas) diretamente na
|
||||
rede, e essas ofertas são automaticamente combinadas pelo livro de ordens do
|
||||
protocolo.
|
||||
</p>
|
||||
<p>
|
||||
Ao contrário de muitas blockchains que exigem contratos inteligentes ou
|
||||
plataformas externas para negociação, a DEX do Xahau é uma funcionalidade de
|
||||
primeira classe do ledger. Essa exchange no ledger oferece liquidação rápida e
|
||||
taxas baixas, tornando a negociação de ativos fluida para usuários e aplicações.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-proto">Economia</span>
|
||||
<h4>Taxas Baixas com Queima de Taxas</h4>
|
||||
<p>
|
||||
O Xahau mantém taxas de transação consistentemente baixas, com um modelo
|
||||
integrado de queima de taxas que reduz spam e recompensa a saúde de longo prazo
|
||||
da rede. Cada transação paga uma taxa mínima em XAH, e uma parte dessa taxa é
|
||||
permanentemente destruída — criando um efeito deflacionário ao longo do tempo.
|
||||
</p>
|
||||
<p>
|
||||
Essa abordagem desencoraja o abuso da rede enquanto preserva a acessibilidade,
|
||||
especialmente para aplicações de alto volume ou sensíveis a custos. Ao contrário
|
||||
de modelos inflacionários ou taxas estilo leilão, o Xahau oferece
|
||||
previsibilidade e alinhamento econômico para todos os usuários.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- PERFORMANCE ─ solo wide ─────────────────────────────────────────── -->
|
||||
<div class="xf-solo">
|
||||
<span class="xf-lbl lbl-proto">Infraestrutura</span>
|
||||
<h4>Rápido, Verde e Escalável</h4>
|
||||
<div class="xf-solo-cols">
|
||||
<p>
|
||||
Construído sobre uma versão aprimorada do protocolo de consenso do XRPL, o
|
||||
Xahau oferece finalidade rápida, baixo consumo de energia e escalabilidade
|
||||
confiável. As transações são confirmadas em segundos, sem mineração e com
|
||||
requisitos mínimos de hardware. O resultado é uma rede capaz de atender a casos
|
||||
de uso financeiros e empresariais do mundo real sem comprometer o meio ambiente
|
||||
ou a experiência do usuário.
|
||||
</p>
|
||||
<p>
|
||||
A arquitetura do Xahau é ideal para sistemas de pagamento globais, plataformas
|
||||
de ativos tokenizados ou aplicações de alto volume onde desempenho e
|
||||
sustentabilidade são inegociáveis.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</div><!-- /act-proto -->
|
||||
|
||||
<!-- ══════════════════════════════════════════════════════════════════════
|
||||
ACT II — FINANCIAL PRIMITIVES
|
||||
══════════════════════════════════════════════════════════════════════════ -->
|
||||
<div class="xf-act act-fin">
|
||||
<p class="xf-act-label">
|
||||
<span class="act-pip pip-teal"></span>Primitivas Financeiras
|
||||
</p>
|
||||
|
||||
<!-- PAYMENTS ─ statement opener ─────────────────────────────────────── -->
|
||||
<div class="xf-statement stmt-fin">
|
||||
<div class="xf-stmt-body">
|
||||
<span class="xf-lbl lbl-fin">Pagamentos</span>
|
||||
<h3>
|
||||
Pagamentos:
|
||||
<br>
|
||||
Transferências Multi-Ativo
|
||||
<br>
|
||||
& Canais
|
||||
</h3>
|
||||
<p>
|
||||
A funcionalidade de Pagamentos do Xahau é projetada para facilitar a
|
||||
transferência de valor de forma rápida e flexível pela rede. De forma única, o
|
||||
Xahau (como o XRPL) suporta pagamentos multi-ativo por meio de um sistema de
|
||||
linhas de confiança e moedas emitidas. Usando uma transação TrustSet, duas
|
||||
partes podem estabelecer uma linha de confiança para transacionar em um ativo
|
||||
personalizado ou IOU, habilitando suporte nativo a múltiplas moedas ou tokens
|
||||
sem necessidade de contratos inteligentes.
|
||||
</p>
|
||||
<p>
|
||||
Isso significa que empresas podem emitir stablecoins ou tokens no Xahau e os
|
||||
usuários podem enviá-los ou trocá-los nativamente. O conjunto de Pagamentos
|
||||
também inclui funcionalidades avançadas como Pré-autorização de Depósito, que
|
||||
permite a uma conta criar uma lista de permissão de quem pode enviar fundos,
|
||||
adicionando segurança contra transações indesejadas.
|
||||
</p>
|
||||
<p>
|
||||
Além disso, o Xahau suporta canais de pagamento para escalabilidade. Os canais
|
||||
de pagamento permitem que duas partes realizem transações rápidas e de alto
|
||||
volume fora do ledger e depois liquidem o resultado líquido na blockchain. Com
|
||||
transações como PaymentChannelCreate, Fund e Claim, o Xahau viabiliza
|
||||
micropagamentos ou pagamentos em streaming que são assegurados pelo ledger sem
|
||||
congestioná-lo.
|
||||
</p>
|
||||
</div>
|
||||
<div class="xf-stmt-graphic">
|
||||
<img
|
||||
src={globalGraphic.src}
|
||||
width="380"
|
||||
height="380"
|
||||
alt="Global network infrastructure illustration"
|
||||
>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- TOKENS + REWARDS ─ pair ─────────────────────────────────────────── -->
|
||||
<div class="xf-pair pair-5545">
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-fin">Controle de Ativos</span>
|
||||
<h4>Controle de Tokens e Ativos por Design</h4>
|
||||
<p>
|
||||
O Xahau oferece a emissores e usuários controle granular sobre tokens e linhas
|
||||
de confiança. Funcionalidades como TrustSet, Clawback, Freeze e Autorização de
|
||||
Depósito permitem personalização completa de como os tokens podem ser usados ou
|
||||
recebidos. Os ativos podem ser autorizados, bloqueados ou destruídos, tudo
|
||||
aplicado no nível do protocolo.
|
||||
</p>
|
||||
<p>
|
||||
Isso torna o Xahau excepcionalmente adequado para instrumentos financeiros
|
||||
regulados, stablecoins, programas de fidelidade ou cadeias de suprimentos
|
||||
empresariais — qualquer cenário onde conformidade, segurança e precisão são
|
||||
críticos.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-fin">Economia</span>
|
||||
<h4>Recompensas de Saldo: Rendimento Passivo Sem Staking</h4>
|
||||
<p>
|
||||
O Xahau oferece um sistema de Recompensas de Saldo que permite às contas
|
||||
acumular valor passivamente apenas por manter ativos. Essas recompensas são
|
||||
calculadas com base no saldo da conta e distribuídas por um mecanismo aplicado
|
||||
pelo consenso, sem necessidade de staking, delegação ou contratos de terceiros.
|
||||
</p>
|
||||
<p>
|
||||
O mecanismo é alimentado por lógica no nível do protocolo e Hooks on-chain,
|
||||
garantindo que as recompensas sejam automáticas, justas e sustentáveis. Ao
|
||||
contrário do yield farming ou sistemas de staking em outras blockchains, o
|
||||
modelo de recompensas do Xahau não exige que os usuários travem ativos ou
|
||||
persigam estratégias complexas de DeFi — ele funciona nativamente, com
|
||||
transparência e simplicidade.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- ESCROW + REMIT + CHECKS ─ trio ──────────────────────────────────── -->
|
||||
<div class="xf-trio">
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-fin">Primitivas</span>
|
||||
<h4>Escrow: Transferências Condicionais para Qualquer Ativo</h4>
|
||||
<p>
|
||||
O Xahau suporta escrow no ledger de tokens nativos e emitidos, permitindo
|
||||
transferências condicionais seguras para uma ampla gama de casos de uso
|
||||
empresariais e financeiros. Fundos ou tokens podem ser bloqueados com lógica de
|
||||
liberação baseada em tempo ou condição, aplicada pela própria rede.
|
||||
</p>
|
||||
<p>
|
||||
Seja para construir um sistema de pagamento baseado em marcos, liquidação de
|
||||
marketplace ou distribuição confiável de tokens, os escrows do Xahau oferecem
|
||||
uma ferramenta simples mas poderosa — sem necessidade de contratos inteligentes
|
||||
externos. O suporte nativo a ativos fungíveis e não fungíveis em escrow torna
|
||||
esse um recurso excepcionalmente versátil.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-fin">Pagamentos</span>
|
||||
<h4>Remit: Transferências Nativas Entre Contas</h4>
|
||||
<p>
|
||||
O recurso Remit permite transações simplificadas e multi-operação entre contas
|
||||
— ideal para fluxos de pagamento complexos ou de alto volume. Em vez de enviar
|
||||
múltiplas instruções separadas, uma única transação Remit pode distribuir valor
|
||||
para múltiplos destinatários ou acionar múltiplas alterações de saldo
|
||||
atomicamente.
|
||||
</p>
|
||||
<p>
|
||||
Isso melhora a eficiência e a confiabilidade, especialmente para processadores
|
||||
de pagamento, marketplaces ou aplicações que precisam realizar operações
|
||||
agrupadas. Por ser integrado ao protocolo, o Remit garante desempenho
|
||||
previsível, baixa latência e forte auditabilidade.
|
||||
</p>
|
||||
</div>
|
||||
|
||||
<div class="xf-detail">
|
||||
<span class="xf-lbl lbl-fin">Pagamentos</span>
|
||||
<h4>Checks: Sistema de Pagamento Diferido</h4>
|
||||
<p>
|
||||
O Xahau suporta Checks, um sistema de pagamento diferido semelhante a emitir
|
||||
cheques digitais na blockchain. Uma parte pode emitir um Check (promessa de
|
||||
pagamento) que o destinatário pretendido pode sacar posteriormente ou cancelar
|
||||
se necessário. Esse recurso permite transações seguras e flexíveis — por
|
||||
exemplo, uma empresa pode emitir um pagamento que o receptor irá resgatar
|
||||
quando determinadas condições forem atendidas.
|
||||
</p>
|
||||
<p>
|
||||
O ledger possui transações dedicadas para criar, sacar ou cancelar um cheque.
|
||||
Poucas outras plataformas possuem esse tipo de instrumento de pagamento diferido
|
||||
nativo; o sistema de checks do Xahau oferece uma camada extra de controle de
|
||||
pagamentos, tudo aplicado pelas regras da rede sem necessidade de contratos
|
||||
inteligentes personalizados.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</div><!-- /act-fin -->
|
||||
|
||||
<!-- ══════════════════════════════════════════════════════════════════════
|
||||
ACT III — GOVERNANCE & IDENTITY
|
||||
══════════════════════════════════════════════════════════════════════════ -->
|
||||
<div class="xf-act act-gov">
|
||||
<p class="xf-act-label">
|
||||
<span class="act-pip pip-vlt"></span>Governança & Identidade
|
||||
</p>
|
||||
|
||||
<!-- GOVERNANCE ─ statement opener ──────────────────────────────────── -->
|
||||
<div class="xf-statement stmt-gov">
|
||||
<div class="xf-stmt-body">
|
||||
<span class="xf-lbl lbl-gov">Governança</span>
|
||||
<h3>
|
||||
Jogo de Governança:
|
||||
<br>
|
||||
Coordenação Descentralizada
|
||||
<br>
|
||||
com Propósito
|
||||
</h3>
|
||||
<p>
|
||||
O Xahau apresenta um sistema de governança inovador sustentado pelo Jogo de
|
||||
Governança, um mecanismo transparente e no ledger para propor, revisar e votar
|
||||
em emendas. Os operadores de validadores (Governadores) participam diretamente
|
||||
na modelagem do protocolo, enquanto também competem em um sistema de recompensas
|
||||
estruturado com base em responsabilidade e engajamento.
|
||||
</p>
|
||||
<p>
|
||||
Este sistema garante que as atualizações do protocolo e as decisões de política
|
||||
sejam abertas e participativas, não ditadas por uma entidade centralizada. Ele
|
||||
combina os benefícios da coordenação empresarial estruturada com a transparência
|
||||
e resiliência do consenso descentralizado. Ao gamificar a governança de forma
|
||||
segura e com incentivos alinhados, o Xahau estabelece um novo padrão para
|
||||
coordenação on-chain.
|
||||
</p>
|
||||
</div>
|
||||
<div class="xf-stmt-graphic">
|
||||
<img
|
||||
src={consensusGraphic.src}
|
||||
width="380"
|
||||
height="380"
|
||||
alt="Consensus mechanism illustration"
|
||||
>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- URITOKENS ─ closing section ─────────────────────────────────────── -->
|
||||
<div class="xf-closing">
|
||||
<div class="xf-closing-inner">
|
||||
<span class="xf-lbl lbl-gov">NFTs</span>
|
||||
<h4>URITokens: NFTs Nativos no Xahau</h4>
|
||||
<p>
|
||||
Os URITokens representam a abordagem do Xahau para tokens não fungíveis (NFTs),
|
||||
implementados como parte nativa do ledger em vez de contratos inteligentes
|
||||
separados. Um URIToken é um objeto de primeira classe no ledger, identificado
|
||||
exclusivamente pela conta emissora e por um Identificador Uniforme de Recurso
|
||||
(URI) que normalmente aponta para os metadados ou conteúdo do token. Apenas um
|
||||
URIToken com um determinado URI pode existir por conta, garantindo verdadeira
|
||||
unicidade para cada ativo digital.
|
||||
</p>
|
||||
<p>
|
||||
Esse padrão de NFT integrado significa que criadores podem cunhar, negociar ou
|
||||
destruir NFTs com transações simples (ex.: URITokenMint, URITokenBuy,
|
||||
URITokenBurn) sem implantar código personalizado. O emissor de um URIToken pode
|
||||
até permitir que ele seja destruído (queimado) configurando uma flag, dando
|
||||
flexibilidade na gestão dos NFTs. Ao integrar NFTs no nível do protocolo, o
|
||||
Xahau torna a emissão e o gerenciamento de colecionáveis digitais ou
|
||||
credenciais mais eficientes e seguros.
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
</div><!-- /act-gov -->
|
||||
</section>
|
||||
|
||||
<style>
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Design tokens
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xfeat {
|
||||
--ink: #0f2328;
|
||||
--dim: #2d3e44;
|
||||
--mute: #556068;
|
||||
--grn2: #007a28;
|
||||
--teal2: #006f87;
|
||||
--vlt2: #4e18b8;
|
||||
--grn-hi: #00c940;
|
||||
--teal-hi: #00c4e8;
|
||||
--vlt-hi: #a050ff;
|
||||
|
||||
background: #ffffff;
|
||||
border-radius: 24px;
|
||||
padding: 48px 56px 72px;
|
||||
font-family: 'Onest', system-ui, sans-serif;
|
||||
color: var(--ink);
|
||||
box-shadow:
|
||||
0 2px 4px rgba(0, 0, 0, 0.04),
|
||||
0 20px 64px -24px rgba(15, 35, 40, 0.13);
|
||||
}
|
||||
.xfeat * {
|
||||
box-sizing: border-box;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Page header
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-head {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
align-items: flex-start;
|
||||
gap: 24px;
|
||||
flex-wrap: wrap;
|
||||
padding-bottom: 40px;
|
||||
}
|
||||
.xfeat h2 {
|
||||
margin: 0;
|
||||
font-size: 36px;
|
||||
font-weight: 800;
|
||||
letter-spacing: -0.03em;
|
||||
line-height: 1.08;
|
||||
color: var(--ink);
|
||||
}
|
||||
.xf-sub {
|
||||
margin: 6px 0 0;
|
||||
font-size: 15px;
|
||||
color: var(--mute);
|
||||
}
|
||||
.xf-chips {
|
||||
display: flex;
|
||||
gap: 8px;
|
||||
flex-wrap: wrap;
|
||||
align-items: flex-start;
|
||||
padding-top: 4px;
|
||||
}
|
||||
.xf-chip {
|
||||
font-family: ui-monospace, monospace;
|
||||
font-size: 11px;
|
||||
padding: 5px 13px;
|
||||
border: 1px solid #cdd7dc;
|
||||
border-radius: 999px;
|
||||
color: var(--mute);
|
||||
white-space: nowrap;
|
||||
letter-spacing: 0.03em;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Acts
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-act {
|
||||
padding-top: 52px;
|
||||
}
|
||||
|
||||
.xf-act-label {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
font-family: ui-monospace, monospace;
|
||||
font-size: 10px;
|
||||
font-weight: 700;
|
||||
letter-spacing: 0.2em;
|
||||
text-transform: uppercase;
|
||||
color: var(--mute);
|
||||
margin: 0 0 44px;
|
||||
}
|
||||
.act-pip {
|
||||
display: block;
|
||||
width: 6px;
|
||||
height: 6px;
|
||||
border-radius: 50%;
|
||||
flex-shrink: 0;
|
||||
}
|
||||
.pip-grn {
|
||||
background: var(--grn2);
|
||||
}
|
||||
.pip-teal {
|
||||
background: var(--teal2);
|
||||
}
|
||||
.pip-vlt {
|
||||
background: var(--vlt2);
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Labels
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-lbl {
|
||||
display: inline-block;
|
||||
font-family: ui-monospace, monospace;
|
||||
font-size: 10px;
|
||||
font-weight: 700;
|
||||
letter-spacing: 0.18em;
|
||||
text-transform: uppercase;
|
||||
padding: 3px 9px;
|
||||
border-radius: 4px;
|
||||
margin-bottom: 14px;
|
||||
}
|
||||
.lbl-proto {
|
||||
color: var(--grn2);
|
||||
background: rgba(0, 140, 43, 0.1);
|
||||
}
|
||||
.lbl-fin {
|
||||
color: var(--teal2);
|
||||
background: rgba(0, 144, 171, 0.1);
|
||||
}
|
||||
.lbl-gov {
|
||||
color: var(--vlt2);
|
||||
background: rgba(91, 30, 200, 0.1);
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Statement sections
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-statement {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
}
|
||||
.xf-stmt-body {
|
||||
flex: 0 0 57%;
|
||||
max-width: 57%;
|
||||
padding: 64px 0 64px 28px;
|
||||
}
|
||||
.xf-stmt-graphic {
|
||||
flex: 1;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
padding: 32px 8px 32px 16px;
|
||||
opacity: 0.95;
|
||||
}
|
||||
.xf-stmt-graphic img {
|
||||
width: 100%;
|
||||
max-width: 340px;
|
||||
height: auto;
|
||||
display: block;
|
||||
}
|
||||
|
||||
.xf-statement h3 {
|
||||
margin: 0 0 22px;
|
||||
font-size: 40px;
|
||||
font-weight: 800;
|
||||
line-height: 1.12;
|
||||
letter-spacing: -0.03em;
|
||||
color: var(--ink); /* fallback */
|
||||
}
|
||||
|
||||
/* ── Gradient text on statement h3 per act ── */
|
||||
.stmt-proto h3 {
|
||||
background: linear-gradient(140deg, #004d1a 15%, var(--grn-hi) 100%);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
background-clip: text;
|
||||
}
|
||||
.stmt-fin h3 {
|
||||
background: linear-gradient(140deg, #003d50 15%, var(--teal-hi) 100%);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
background-clip: text;
|
||||
}
|
||||
.stmt-gov h3 {
|
||||
background: linear-gradient(140deg, #2a0875 15%, var(--vlt-hi) 100%);
|
||||
-webkit-background-clip: text;
|
||||
-webkit-text-fill-color: transparent;
|
||||
background-clip: text;
|
||||
}
|
||||
.xf-statement p {
|
||||
font-size: 15.5px;
|
||||
line-height: 1.72;
|
||||
color: var(--dim);
|
||||
margin: 0 0 16px;
|
||||
}
|
||||
.xf-statement p:last-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Detail sections — pairs and trios
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-pair,
|
||||
.xf-trio {
|
||||
display: grid;
|
||||
}
|
||||
.pair-6040 {
|
||||
grid-template-columns: 3fr 2fr;
|
||||
}
|
||||
.pair-5545 {
|
||||
grid-template-columns: 11fr 9fr;
|
||||
}
|
||||
.xf-trio {
|
||||
grid-template-columns: repeat(3, 1fr);
|
||||
}
|
||||
|
||||
.xf-detail {
|
||||
padding: 48px 40px 48px 28px;
|
||||
}
|
||||
.xf-detail h4 {
|
||||
margin: 0 0 14px;
|
||||
font-size: 19px;
|
||||
font-weight: 700;
|
||||
line-height: 1.28;
|
||||
letter-spacing: -0.014em;
|
||||
color: var(--ink); /* overridden per-act below */
|
||||
}
|
||||
|
||||
/* ── Solid colour on detail/solo/closing h4 per act ── */
|
||||
.act-proto .xf-detail h4,
|
||||
.act-proto .xf-solo h4 {
|
||||
color: var(--grn2);
|
||||
}
|
||||
.act-fin .xf-detail h4 {
|
||||
color: var(--teal2);
|
||||
}
|
||||
.act-gov .xf-detail h4,
|
||||
.act-gov .xf-closing h4 {
|
||||
color: var(--vlt2);
|
||||
}
|
||||
.xf-detail p {
|
||||
font-size: 14px;
|
||||
line-height: 1.72;
|
||||
color: var(--dim);
|
||||
margin: 0 0 12px;
|
||||
}
|
||||
.xf-detail p:last-of-type {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Solo wide section
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-solo {
|
||||
padding: 52px 0 52px 28px;
|
||||
}
|
||||
.xf-solo h4 {
|
||||
margin: 0 0 18px;
|
||||
font-size: 22px;
|
||||
font-weight: 700;
|
||||
letter-spacing: -0.016em;
|
||||
color: var(--ink); /* overridden per-act above */
|
||||
}
|
||||
.xf-solo-cols {
|
||||
display: grid;
|
||||
grid-template-columns: 1fr 1fr;
|
||||
gap: 40px;
|
||||
max-width: 900px;
|
||||
}
|
||||
.xf-solo-cols p {
|
||||
font-size: 14.5px;
|
||||
line-height: 1.72;
|
||||
color: var(--dim);
|
||||
margin: 0;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Closing section
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
.xf-closing {
|
||||
padding: 52px 0 52px 28px;
|
||||
}
|
||||
.xf-closing-inner {
|
||||
max-width: 640px;
|
||||
}
|
||||
.xf-closing h4 {
|
||||
margin: 0 0 16px;
|
||||
font-size: 22px;
|
||||
font-weight: 700;
|
||||
letter-spacing: -0.016em;
|
||||
color: var(--ink); /* overridden per-act above */
|
||||
}
|
||||
.xf-closing p {
|
||||
font-size: 14.5px;
|
||||
line-height: 1.72;
|
||||
color: var(--dim);
|
||||
margin: 0 0 14px;
|
||||
}
|
||||
.xf-closing p:last-child {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
|
||||
/* ══════════════════════════════════════════════════════════════════════════
|
||||
Responsive
|
||||
══════════════════════════════════════════════════════════════════════════ */
|
||||
@media (max-width: 900px) {
|
||||
.xf-statement {
|
||||
flex-direction: column;
|
||||
align-items: flex-start;
|
||||
}
|
||||
.xf-stmt-body {
|
||||
flex: none;
|
||||
max-width: 100%;
|
||||
}
|
||||
.xf-stmt-graphic {
|
||||
width: 100%;
|
||||
padding: 0 0 32px;
|
||||
opacity: 0.6;
|
||||
}
|
||||
.xf-stmt-graphic img {
|
||||
max-width: 240px;
|
||||
margin: 0 auto;
|
||||
}
|
||||
.xf-pair,
|
||||
.xf-trio {
|
||||
grid-template-columns: 1fr;
|
||||
}
|
||||
.xf-solo-cols {
|
||||
grid-template-columns: 1fr;
|
||||
gap: 0;
|
||||
}
|
||||
.xf-solo-cols p {
|
||||
margin-bottom: 14px;
|
||||
}
|
||||
}
|
||||
|
||||
@media (max-width: 640px) {
|
||||
.xfeat {
|
||||
padding: 32px 24px 48px;
|
||||
border-radius: 16px;
|
||||
}
|
||||
.xfeat h2 {
|
||||
font-size: 28px;
|
||||
}
|
||||
.xf-statement h3 {
|
||||
font-size: 26px;
|
||||
}
|
||||
.xf-head {
|
||||
flex-direction: column;
|
||||
gap: 14px;
|
||||
}
|
||||
.xf-stmt-body {
|
||||
padding: 44px 0 44px 22px;
|
||||
}
|
||||
.xf-detail {
|
||||
padding: 36px 20px 36px 22px;
|
||||
}
|
||||
}
|
||||
</style>
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: Deposit Pre Auth
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L172-L178)
|
||||
|
||||
A `DepositPreauth` object tracks a preauthorization from one account to another. \[DepositPreauth transactions]\[] create these objects.
|
||||
|
||||
This has no effect on the processing of transactions unless the account that provided the preauthorization requires Deposit Authorization. In that case, the account that was preauthorized can send payments and other transactions directly to the account that provided the preauthorization. Preauthorizations are one-directional and have no effect on payments going the opposite direction.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"LedgerEntryType": "DepositPreauth",
|
||||
"Account": "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
|
||||
"Authorize": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
|
||||
"Flags": 0,
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "3E8964D5A86B3CD6B9ECB33310D4E073D64C865A5B866200AD2B7E29F8326702",
|
||||
"PreviousTxnLgrSeq": 7,
|
||||
"index": "4A255038CC3ADCC1A9C91509279B59908251728D0DAADB248FFE297D0F7E068C"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `DepositPreauth` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | --------- | ------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | Account | Yes | The account that granted the preauthorization. (The destination of the preauthorized payments.) |
|
||||
| `Authorize` | String | Account | Yes | The account that received the preauthorization. (The sender of the preauthorized payments.) |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `DepositPreauth` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0070`, mapped to the string `DepositPreauth`, indicates that this is a DepositPreauth object. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the sender's owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
|
||||
### DepositPreauth ID Format
|
||||
|
||||
The ID of a `DepositPreauth` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The DepositPreauth space key (`0x0070`)
|
||||
* The AccountID of the owner of this object (the sender of the \[DepositPreauth transaction]\[] that created this object; in other words, the one that granted the preauthorization)
|
||||
* The AccountID of the preauthorized account (the `Authorized` field of the \[DepositPreauth transaction]\[] that created this object; in other words, the one that received the preauthorization)
|
||||
@@ -1,96 +0,0 @@
|
||||
---
|
||||
title: Directory Node
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L44)
|
||||
|
||||
The `DirectoryNode` object type provides a list of links to other objects in the ledger's state tree. A single conceptual _Directory_ takes the form of a doubly linked list, with one or more DirectoryNode objects each containing up to 32 IDs of other objects. The first object is called the root of the directory, and all objects other than the root object can be added or deleted as necessary.
|
||||
|
||||
There are two kinds of Directories:
|
||||
|
||||
* **Owner directories** list other objects owned by an account, such as `RippleState` (trust line) or `Offer` objects.
|
||||
* **Offer directories** list the offers available in the decentralized exchange. A single Offer directory contains all the offers that have the same exchange rate for the same token (currency code and issuer).
|
||||
|
||||
### Example JSON
|
||||
|
||||
_Offer Directory_
|
||||
|
||||
```json
|
||||
{
|
||||
"ExchangeRate": "4F069BA8FF484000",
|
||||
"Flags": 0,
|
||||
"Indexes": [
|
||||
"AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD"
|
||||
],
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"RootIndex": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000",
|
||||
"TakerGetsCurrency": "0000000000000000000000000000000000000000",
|
||||
"TakerGetsIssuer": "0000000000000000000000000000000000000000",
|
||||
"TakerPaysCurrency": "0000000000000000000000004A50590000000000",
|
||||
"TakerPaysIssuer": "5BBC0F22F61D9224A110650CFE21CC0C4BE13098",
|
||||
"index": "1BBEF97EDE88D40CEE2ADE6FEF121166AFE80D99EBADB01A4F069BA8FF484000"
|
||||
}
|
||||
```
|
||||
|
||||
_Owner Directory_
|
||||
|
||||
```json
|
||||
{
|
||||
"Flags": 0,
|
||||
"Indexes": [
|
||||
"AD7EAE148287EF12D213A251015F86E6D4BD34B3C4A0A1ED9A17198373F908AD",
|
||||
"E83BBB58949A8303DF07172B16FB8EFBA66B9191F3836EC27A4568ED5997BAC5"
|
||||
],
|
||||
"ReferenceCount": "1",
|
||||
"LedgerEntryType": "DirectoryNode",
|
||||
"Owner": "rpR95n1iFkTqpoy1e878f4Z1pVHVtWKMNQ",
|
||||
"RootIndex": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94",
|
||||
"index": "193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | --------- | ------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Owner` | String | AccountID | No | (Owner Directories only) The address of the account that owns the objects in this directory. |
|
||||
| `TakerGetsCurrency` | String | Hash160 | No | (Offer Directories only) The currency code of the `TakerGets` amount from the offers in this directory. |
|
||||
| `TakerGetsIssuer` | String | Hash160 | No | (Offer Directories only) The issuer of the `TakerGets` amount from the offers in this directory. |
|
||||
| `TakerPaysCurrency` | String | Hash160 | No | (Offer Directories only) The currency code of the `TakerPays` amount from the offers in this directory. |
|
||||
| `TakerPaysIssuer` | String | Hash160 | No | (Offer Directories only) The issuer of the `TakerPays` amount from the offers in this directory. |
|
||||
| `ExchangeRate` | String | UInt64 | No | (Offer Directories only) **DEPRECATED**. Do not use. |
|
||||
| `ReferenceCount` | String | UInt64 | No | Reference counting in the ledger reduces storage burden and fees by allowing multiple installations of the same Hook to point to the same object on the ledger, only removing it when no accounts have the Hook installed. |
|
||||
| `Indexes` | Array | Vector256 | Yes | The contents of this Directory: an array of IDs of other objects. |
|
||||
| `IndexNext` | Number | UInt64 | No | If this Directory consists of multiple pages, this ID links to the next object in the chain, wrapping around at the end. |
|
||||
| `IndexPrevious` | Number | UInt64 | No | If this Directory consists of multiple pages, this ID links to the previous object in the chain, wrapping around at the beginning. |
|
||||
| `NFTokenID` | String | Hash256 | No | Unused |
|
||||
|
||||
### Directory ID Formats
|
||||
|
||||
There are three different formulas for creating the ID of a DirectoryNode, depending on which of the following the DirectoryNode represents:
|
||||
|
||||
* The first page (also called the root) of an Owner Directory
|
||||
* The first page of an Offer Directory
|
||||
* Later pages of either type
|
||||
|
||||
**The first page of an Owner Directory** has an ID that is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The Owner Directory space key (`0x004F`)
|
||||
* The AccountID from the `Owner` field.
|
||||
|
||||
**The first page of an Offer Directory** has a special ID: the higher 192 bits define the order book, and the remaining 64 bits define the exchange rate of the offers in that directory. (The ID is big-endian, so the book is in the more significant bits, which come first, and the quality is in the less significant bits which come last.) 
|
||||
|
||||
This provides a way to iterate through an order book from best offers to worst. Specifically: the first 192 bits are the first 192 bits of the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The Book Directory space key (`0x0042`)
|
||||
* The 160-bit currency code from the `TakerPaysCurrency`
|
||||
* The 160-bit currency code from the `TakerGetsCurrency`
|
||||
* The AccountID from the `TakerPaysIssuer`
|
||||
* The AccountID from the `TakerGetsIssuer`
|
||||
|
||||
The lower 64 bits of an Offer Directory's ID represent the `TakerPays` amount divided by `TakerGets` amount from the offer(s) in that directory as a 64-bit number in Xahau's internal amount format.
|
||||
|
||||
**If the DirectoryNode is not the first page in the Directory** (regardless of whether it is an Owner Directory or an Offer Directory), then it has an ID that is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The DirectoryNode space key (`0x0064`)
|
||||
* The ID of the root DirectoryNode
|
||||
* The page number of this object. (Since 0 is the root DirectoryNode, this value is an integer 1 or higher.)
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
title: Emitted Txn
|
||||
---
|
||||
_(Added by the \[Hooks amendment]\[].)_
|
||||
|
||||
An `EmittedTxn` object describes a transaction that has been emitted by a hook. The object contains all the fields of the original transaction, along with additional details about the emission.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rMPwD1b8dJUaqZHaBgEvFx4ENhtpPVvDsv",
|
||||
"Amount": "999999",
|
||||
"Destination": "rfCarbonVNTuXckX6x2qTMFmFSnm6dEWGX",
|
||||
"DestinationTag": 0,
|
||||
"EmitDetails": {
|
||||
"EmitBurden": "1",
|
||||
"EmitCallback": "rMPwD1b8dJUaqZHaBgEvFx4ENhtpPVvDsv",
|
||||
"EmitGeneration": 1,
|
||||
"EmitHookHash": "A9B5411F4A4368008B4736EEE47A34B0EFCBE74016B9B94CC6208FBC0BF5C0C2",
|
||||
"EmitNonce": "6B2A27D6864903A479614581A79D18E8C8ADCE01E3440C6E993BE07298ADC2A4",
|
||||
"EmitParentTxnID": "9763EB6B74AEF0F55F642243AD51F48490594434439002A6142E545E47318D56"
|
||||
},
|
||||
"Fee": "31",
|
||||
"FirstLedgerSequence": 7186113,
|
||||
"Flags": 2147483648,
|
||||
"LastLedgerSequence": 7186117,
|
||||
"Sequence": 0,
|
||||
"SigningPubKey": "000000000000000000000000000000000000000000000000000000000000000000",
|
||||
"SourceTag": 0,
|
||||
"TransactionType": "Payment"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
An `EmittedTxn` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------- | --------- | ------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `EmitDetails` | Object | Object | Yes | Contains details about the emission. This includes the generation of the emission, the burden of the emission, the callback address, the hash of the hook that emitted the transaction, the nonce of the emission, and the ID of the parent transaction. |
|
||||
| `TransactionType` | String | UInt16 | Yes | The type of the transaction that was emitted. |
|
||||
| `Account` | String | Account | Yes | The account that emitted the transaction. |
|
||||
| `Fee` | String | Amount | Yes | The fee paid for the transaction. |
|
||||
| `Sequence` | Number | UInt32 | Yes | The sequence number of the transaction. |
|
||||
| `SigningPubKey` | String | Blob | Yes | The public key that signs the transaction. |
|
||||
|
||||
The `EmittedTxn` object also contains all the fields of the original transaction.
|
||||
|
||||
### EmitDetails Fields
|
||||
|
||||
An `EmitDetails` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------- | --------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `EmitGeneration` | Number | UInt32 | Yes | This field keeps track of a chain of emitted transactions that in turn cause other transactions to be emitted. |
|
||||
| `EmitBurden` | String | UInt64 | Yes | This field is a heuristic for detecting forkbombs. Fees are based on burden and will increase exponentially when a chain reaction is started to prevent the network becoming overun by self-reinforcing emitted transactions. |
|
||||
| `EmitParentTxnID` | String | Hash256 | Yes | The Hook Execution that emitted the transaction is connected to the Originating Transaction. Therefore this field is always required for the efficient tracing of behaviour. |
|
||||
| `EmitNonce` | String | Hash256 | Yes | Emitted Transactions would be identical with the same fields and therefore have identical transaction hashes if a nonce were not used. However every node on the network needs to agree on the nonce, so a special Hook API to produce a deterministic nonce is made available. |
|
||||
| `EmitCallback` | String | AccountID | No | This field is used by xahld when it needs to intitate a callback, such that it knows which Hook and account to initate the callback on. Callbacks happen when an emitted transaction is accepted into a ledger. |
|
||||
| `EmitHookHash` | String | Hash256 | Yes | The SHA512H of the Hook at the time it was executed. |
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
title: Escrow
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/c6b6d82a754fe449cc533e18659df483c10a5c98/src/ripple/protocol/impl/LedgerFormats.cpp#L90-L101)
|
||||
|
||||
_(Added by the \[Escrow amendment]\[].)_
|
||||
|
||||
The `Escrow` object type represents a held payment of XAH or IOU waiting to be executed or canceled. An \[EscrowCreate transaction]\[] creates an `Escrow` object in the ledger. A successful \[EscrowFinish]\[] or \[EscrowCancel]\[] transaction deletes the object. 
|
||||
|
||||
If the `Escrow` object has a [_crypto-condition_](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02), the payment can only succeed if an EscrowFinish transaction provides the corresponding _fulfillment_ that satisfies the condition. (The only supported crypto-condition type is [PREIMAGE-SHA-256](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1).) If the `Escrow` object has a `FinishAfter` time, the held payment can only execute after that time.
|
||||
|
||||
An `Escrow` object is associated with two addresses:
|
||||
|
||||
* The owner, who provides the XAH or IOU when creating the `Escrow` object. If the held payment is canceled, the XAH or IOU returns to the owner.
|
||||
* The destination, where the XAH or IOU is paid when the held payment succeeds. The destination can be the same as the owner.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": "10000",
|
||||
"CancelAfter": 545440232,
|
||||
"Condition": "A0258020A82A88B2DF843A54F58772E4A3861866ECDB4157645DD9AE528C1D3AEEDABAB6810120",
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"DestinationTag": 23480,
|
||||
"FinishAfter": 545354132,
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "Escrow",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"DestinationNode": "0000000000000000",
|
||||
"PreviousTxnID": "C44F2EB84196B9AD820313DBEBA6316A15C9A2D35787579ED172B87A30131DA7",
|
||||
"PreviousTxnLgrSeq": 28991004,
|
||||
"SourceTag": 11747,
|
||||
"index": "DC5F3851D8A1AB622F957761E5963BC5BD439D5C24AC6AD7AC4523F0640244AC"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
An `Escrow` object has the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | ---------------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | Yes | The address of the owner (sender) of this held payment. This is the account that provided the amount, and gets it back if the held payment is canceled. |
|
||||
| `Amount` | String or Object | Amount | Yes | The amount to be delivered by the held payment. |
|
||||
| `CancelAfter` | Number | UInt32 | No | The held payment can be canceled if and only if this field is present _and_ the time it specifies has passed. Specifically, this is specified as \[seconds since the Ripple Epoch]\[] and it "has passed" if it's earlier than the close time of the previous validated ledger. |
|
||||
| `Condition` | String | Blob | No | A [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1), as hexadecimal. If present, the \[EscrowFinish transaction]\[] must contain a fulfillment that satisfies this condition. |
|
||||
| `Destination` | String | AccountID | Yes | The destination address where the amount is paid if the held payment is successful. |
|
||||
| `DestinationNode` | String | UInt64 | No | A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. Omitted on escrows created before enabling the \[fix1523 amendment]\[]. |
|
||||
| `DestinationTag` | Number | UInt32 | No | An arbitrary tag to further specify the destination for this held payment, such as a hosted recipient at the destination address. |
|
||||
| `FinishAfter` | Number | UInt32 | No | The time, in \[seconds since the Ripple Epoch]\[], after which this held payment can be finished. Any \[EscrowFinish transaction]\[] before this time fails. (Specifically, this is compared with the close time of the previous validated ledger.) |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Escrow` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0075`, mapped to the string `Escrow`, indicates that this object is an `Escrow` object. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `SourceTag` | Number | UInt32 | No | An arbitrary tag to further specify the source for this held payment, such as a hosted recipient at the owner's address. |
|
||||
| `TransferRate` | Number | UInt32 | No | |
|
||||
|
||||
### Escrow ID Format
|
||||
|
||||
The ID of an `Escrow` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The Escrow space key (`0x0075`)
|
||||
* The AccountID of the sender of the \[EscrowCreate transaction]\[] that created the `Escrow` object
|
||||
* The Sequence number of the \[EscrowCreate transaction]\[] that created the `Escrow` object If the EscrowCreate transaction used a Ticket, use the `TicketSequence` value instead.
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Fee Settings
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L115-L120)
|
||||
|
||||
The `FeeSettings` object type contains the current base transaction cost and reserve amounts as determined by fee voting. Each ledger version contains **at most one** `FeeSettings` object.
|
||||
|
||||
### Example JSON
|
||||
|
||||
Example `FeeSettings` object:
|
||||
|
||||
```json
|
||||
{
|
||||
"BaseFee": "000000000000000A",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "FeeSettings",
|
||||
"ReferenceFeeUnits": 10,
|
||||
"ReserveBase": 20000000,
|
||||
"ReserveIncrement": 5000000,
|
||||
"XahauActivationLgrSeq": 0,
|
||||
"NetworkID": 21337,
|
||||
"AccountCount": 0,
|
||||
"index": "4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
The `FeeSettings` object has the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------------- | --------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `BaseFee` | String | UInt64 | Yes | The transaction cost of the "reference transaction" in drops of XAH as hexadecimal. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `FeeSettings` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. |
|
||||
| `ReferenceFeeUnits` | Number | UInt32 | Yes | The `BaseFee` translated into "fee units". |
|
||||
| `ReserveBase` | Number | UInt32 | Yes | The base reserve for an account in Xahau, as drops of XAH. |
|
||||
| `ReserveIncrement` | Number | UInt32 | Yes | The incremental owner reserve for owning objects, as drops of XAH. |
|
||||
| `XahauActivationLgrSeq` | Number | UInt32 | No | The ledger index where Xahau genesis was activated. |
|
||||
| `AccountCount` | Number | UInt32 | No | The number of accounts created on the Xahau network. |
|
||||
| `NetworkID` | Number | UInt32 | No | The ID of the network |
|
||||
|
||||
**Warning:** The JSON format for this ledger object type is unusual. The `BaseFee`, `ReserveBase`, and `ReserveIncrement` indicate drops of XAH but _**not**_ in the usual format for \[specifying XAH]\[Currency Amount].
|
||||
|
||||
If the _\[XAHFees amendment]\[]_ is enabled, the `FeeSettings` object has these fields instead:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------------- | --------- | ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `BaseFeeDrops` | String | Amount | Yes | The transaction cost of the "reference transaction" in drops of XAH. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bitmap of boolean flags enabled for this object. Currently, the protocol defines no flags for `FeeSettings` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `FeeSettings`, indicates that this object contains the ledger's fee settings. |
|
||||
| `ReserveBaseDrops` | String | Amount | Yes | The base reserve for an account in the XAH Ledger, as drops of XAH. |
|
||||
| `ReserveIncrementDrops` | String | Amount | Yes | The incremental owner reserve for owning objects, as drops of XAH. |
|
||||
| `XahauActivationLgrSeq` | Number | UInt32 | No | The ledger index where Xahau genesis was activated. |
|
||||
| `AccountCount` | Number | UInt32 | No | The number of accounts created on the Xahau network. |
|
||||
| `NetworkID` | Number | UInt32 | No | |
|
||||
|
||||
### FeeSettings ID Format
|
||||
|
||||
The `FeeSettings` object ID is the hash of the `FeeSettings` space key (`0x0065`) only. This means that the ID of the `FeeSettings` object in a ledger is always:
|
||||
|
||||
```
|
||||
4BC50C9B0D8515D3EAAE1E74B29A95804346C491EE1A95BF25E4AAB854A6A651
|
||||
```
|
||||
@@ -1,58 +0,0 @@
|
||||
---
|
||||
title: Hook Definition
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170)
|
||||
|
||||
_(Added by the \[Hooks amendment]\[].)_
|
||||
|
||||
A `HookDefinition` object describes a hook, which is a piece of code that is executed in response to certain transactions. The hook can modify the transaction, emit new transactions, or perform other actions.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"HookHash": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
|
||||
"HookOn": "0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"HookNamespace": "0000000000000000000000000000000000000000000000000000000000000000",
|
||||
"HookParameters": {
|
||||
"HookParameter": {
|
||||
"HookParameterName": "DEADBEEF",
|
||||
"HookParameterValue": "DEADBEEF",
|
||||
}
|
||||
},
|
||||
"HookApiVersion": 1,
|
||||
"CreateCode": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
|
||||
"HookSetTxnID": "0000000000000000",
|
||||
"ReferenceCount": "6",
|
||||
"Fee": "100000000",
|
||||
"HookCallbackFee": "200000000",
|
||||
"LedgerEntryType": "HookDefinition",
|
||||
"index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `HookDefinition` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------- | --------- | ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------- |
|
||||
| `HookHash` | String | Hash256 | Yes | The unique identifier of the hook. |
|
||||
| `HookOn` | String | Hash256 | Yes | The transaction/s on which the hook is triggered. |
|
||||
| `HookCanEmit` | String | Hash256 | No | The transaction/s which the hook can emit. |
|
||||
| `HookNamespace` | String | Hash256 | Yes | The namespace of the hook. |
|
||||
| `HookParameters` | String | Vector | Yes | The parameters that the hook accepts. |
|
||||
| `HookApiVersion` | Number | UInt16 | Yes | The version of the hook API that the hook uses. |
|
||||
| `CreateCode` | String | VL | Yes | The code that is executed when the hook is created. |
|
||||
| `HookSetTxnID` | String | Hash256 | Yes | The ID of the transaction that set the hook. |
|
||||
| `ReferenceCount` | String | UInt64 | Yes | The number of references to the hook. |
|
||||
| `Fee` | String | Amount | Yes | The fee for executing the hook. |
|
||||
| `HookCallbackFee` | String | Amount | No | The fee for executing the hook's callback function. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0043`, mapped to the string `HookDefinition`, indicates that this object is a HookDefinition object. |
|
||||
|
||||
#### Hook Definition ID Format
|
||||
|
||||
The ID of a `HookDefinition` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The HookDefinition space key (`0x0044`)
|
||||
* The `HookHash` of the hook
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: Hook State
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170)
|
||||
|
||||
_(Added by the \[Hooks amendment]\[].)_
|
||||
|
||||
A `HookState` object describes the state of a hook, which is a piece of code running on Xahau that can interact with transactions. The `HookState` object stores the state of the hook, which can be modified by the hook's code.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"OwnerNode": "0000000000000000",
|
||||
"HookStateKey": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
|
||||
"HookStateData": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
|
||||
"LedgerEntryType": "HookState",
|
||||
"index": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `HookState` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------- | --------- | ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner's directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `HookStateKey` | String | Hash256 | Yes | The key that uniquely identifies this hook state. |
|
||||
| `HookStateData` | String | VL | Yes | The data stored by the hook. This can be any data that the hook's code decides to store. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0043`, mapped to the string `HookState`, indicates that this object is a HookState object. |
|
||||
|
||||
#### HookState ID Format
|
||||
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/Indexes.cpp#L193-L200)
|
||||
|
||||
The ID of a `HookState` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The HookState space key (`0x0076`)
|
||||
* The AccountID of the account that owns the hook
|
||||
* The `HookStateKey` of the `HookState` object
|
||||
* The `HookNamespace` of the hook.
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: Hook
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170)
|
||||
|
||||
_(Added by the \[Hooks amendment]\[].)_
|
||||
|
||||
A `Hook` object describes a smart contract, which can be triggered by a transaction to perform predefined operations. The operations are defined by the `Hook` creator and can interact with the ledger and transactions.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
|
||||
"PreviousTxnLgrSeq": 6,
|
||||
"Hooks": [
|
||||
{
|
||||
"HookHash": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
|
||||
"HookParameters": []
|
||||
}
|
||||
],
|
||||
"LedgerEntryType": "Hook",
|
||||
"index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `Hook` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | --------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | Account | Yes | The account that created the Hook. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner's directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The ID of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[ledger index]\[] of the ledger that contains the transaction that most recently modified this object. |
|
||||
| `Hooks` | Array | Array | Yes | An array of hook objects. Each object has the following fields: `HookHash`, `CreateCode`, `HookGrants`, `HookNamespace`, `HookParameters`, `HookOn`, `HookApiVersion`, `Flags`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0043`, mapped to the string `Hook`, indicates that this object is a Hook object. |
|
||||
|
||||
### Hook Fields
|
||||
|
||||
The following fields are used in the hook object:
|
||||
|
||||
| Field | JSON Type | Internal Type | Description |
|
||||
| ---------------- | --------- | ------------- | ------------------------------ |
|
||||
| `HookHash` | String | Hash256 | The hash of the hook. |
|
||||
| `HookParameters` | Array | Array | The parameters of the hook. |
|
||||
| `Flags` | Number | UInt32 | Additional flags for the hook. |
|
||||
|
||||
#### Hook ID Format
|
||||
|
||||
The ID of a `Hook` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The Hook space key (`0x0048`)
|
||||
* The AccountID of the sender of the \[SetHook transaction]\[] that created the `Hook` object
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: Import VL Sequence
|
||||
---
|
||||
_(Added by the \[Import amendment]\[].)_
|
||||
|
||||
The `ImportVLSequence` helps track and validate the order of operations during the import process. It is used to ensure that the correct sequence of events occurs and to handle any discrepancies or updates to the dUNL on the "burning" ledger.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"LedgerEntryType": "ImportVLSequence",
|
||||
"Flags": 0,
|
||||
"ImportSequence": 2023102101,
|
||||
"PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy",
|
||||
"index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `ImportVLSequence` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------------- | --------- | ------------------- | --------- | --------------------------------------------------------------------------------------------------------------------- |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0049`, mapped to the string `ImportVLSequence`, indicates that this object is a ImportVLSequence object. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags. No flags are defined for the `ImportVLSequence` object type, so this value is always `0`. |
|
||||
| `ImportSequence` | Number | UInt32 | Yes | The current sequence number of the dUNL list on the "burning" ledger. |
|
||||
| `PublicKey` | String | Blob | Yes | The `PublicKey` of the dUNL list from the "burning" ledger. |
|
||||
|
||||
#### Import VL Sequence ID Format
|
||||
|
||||
The ID of a `ImportVLSequence` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The Import VL Sequence space key (`0x0049`)
|
||||
* The Public Key of the Import Validator List
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
title: Ledger Hashes
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L104-L108)
|
||||
|
||||
(Not to be confused with the \["ledger hash" string data type]\[Hash], which uniquely identifies a ledger version. This section describes the `LedgerHashes` ledger object type.)
|
||||
|
||||
The `LedgerHashes` object type contains a history of prior ledgers that led up to this ledger version, in the form of their hashes. Objects of this ledger type are modified automatically when closing a ledger. (This is one of the only times a ledger's state data is modified without a transaction or pseudo-transaction.) The `LedgerHashes` objects exist to make it possible to look up a previous ledger's hash with only the current ledger version and at most one lookup of a previous ledger version.
|
||||
|
||||
There are two kinds of `LedgerHashes` object. Both types have the same fields. Each ledger version contains:
|
||||
|
||||
* Exactly one "recent history" `LedgerHashes` object
|
||||
* A number of "previous history" `LedgerHashes` objects based on the current ledger index (that is, the length of the ledger history). Specifically, Xahau adds a new "previous history" object every 65536 ledger versions.
|
||||
|
||||
**Note:** As an exception, a new genesis ledger has no `LedgerHashes` objects at all, because it has no ledger history.
|
||||
|
||||
Example `LedgerHashes` object (trimmed for length):
|
||||
|
||||
```json
|
||||
{
|
||||
"LedgerEntryType": "LedgerHashes",
|
||||
"Flags": 0,
|
||||
"FirstLedgerSequence": 2,
|
||||
"LastLedgerSequence": 33872029,
|
||||
"Hashes": [
|
||||
"D638208ADBD04CBB10DE7B645D3AB4BA31489379411A3A347151702B6401AA78",
|
||||
"254D690864E418DDD9BCAC93F41B1F53B1AE693FC5FE667CE40205C322D1BE3B",
|
||||
"A2B31D28905E2DEF926362822BC412B12ABF6942B73B72A32D46ED2ABB7ACCFA",
|
||||
"AB4014846DF818A4B43D6B1686D0DE0644FE711577C5AB6F0B2A21CCEE280140",
|
||||
"3383784E82A8BA45F4DD5EF4EE90A1B2D3B4571317DBAC37B859836ADDE644C1",
|
||||
... (up to 256 ledger hashes) ...
|
||||
],
|
||||
"index": "B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B"
|
||||
}
|
||||
```
|
||||
|
||||
A `LedgerHashes` object has the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| --------------------- | ---------------- | ------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `FirstLedgerSequence` | Number | UInt32 | Yes | **DEPRECATED** Do not use. (The "recent hashes" object of the production Xahau has the value `2` in this field as a result of a previous `rippled` software. That value gets carried forward as the "recent hashes" object is updated. New "previous history" objects do not have this field, nor do "recent hashes" objects in parallel networks started with more recent versions of `rippled`.) |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `LedgerHashes` objects. The value is always `0`. |
|
||||
| `Hashes` | Array of Strings | Vector256 | Yes | An array of up to 256 ledger hashes. The contents depend on which sub-type of `LedgerHashes` object this is. |
|
||||
| `LastLedgerSequence` | Number | UInt32 | Yes | The \[Ledger Index]\[] of the last entry in this object's `Hashes` array. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0068`, mapped to the string `LedgerHashes`, indicates that this object is a list of ledger hashes. |
|
||||
|
||||
### Recent History LedgerHashes
|
||||
|
||||
There is exactly one `LedgerHashes` object of the "recent history" sub-type in every ledger after the genesis ledger. This object contains the identifying hashes of the most recent 256 ledger versions (or fewer, if the ledger history has less than 256 ledgers total) in the `Hashes` array. Whenever a new ledger is closed, part of the process of closing it involves updating the "recent history" object with the hash of the previous ledger version this ledger version is derived from (also known as this ledger version's _parent ledger_). When there are more than 256 hashes, the oldest one is removed.
|
||||
|
||||
Using the "recent history" `LedgerHashes` object of a given ledger, you can get the hash of any ledger index within the 256 ledger versions before the given ledger version.
|
||||
|
||||
### Previous History LedgerHashes
|
||||
|
||||
The "previous history" `LedgerHashes` entries collectively contain the hash of every 256th ledger version (also called "flag ledgers") in the full history of the ledger. When the child of a flag ledger closes, the flag ledger's hash is added to the `Hashes` array of the newest "previous history" `LedgerHashes` object. Every 65536 ledgers, `rippled` creates a new `LedgerHashes` object, so that each "previous history" object has the hashes of 256 flag ledgers.
|
||||
|
||||
**Note:** The oldest "previous history" `LedgerHashes` object contains only 255 entries because the genesis ledger has a ledger index of 1, not 0.
|
||||
|
||||
The "previous history" `LedgerHashes` objects act as a [skip list](https://en.wikipedia.org/wiki/Skip_list) so you can get the hash of any historical flag ledger from its index. From there, you can use that flag ledger's "recent history" object to get the hash of any other ledger.
|
||||
|
||||
### LedgerHashes ID Formats
|
||||
|
||||
There are two formats for `LedgerHashes` object IDs, depending on whether the object is a "recent history" sub-type or a "previous history" sub-type.
|
||||
|
||||
The **"recent history"** `LedgerHashes` object has an ID that is the \[SHA-512Half]\[] of the `LedgerHashes` space key (`0x0073`). In other words, the "recent history" always has the ID `B4979A36CDC7F3D3D5C31A4EAE2AC7D7209DDA877588B9AFC66799692AB0D66B`.
|
||||
|
||||
The **"previous history"** `LedgerHashes` objects have an ID that is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The `LedgerHashes` space key (`0x0073`)
|
||||
* The 32-bit \[Ledger Index]\[] of a flag ledger in the object's `Hashes` array, divided by 65536.
|
||||
|
||||
**Tip:** Dividing by 65536 keeps the most significant 16 bits, which are the same for all the flag ledgers listed in a "previous history" object, and only those ledgers. You can use this fact to look up the `LedgerHashes` object that contains the hash of any flag ledger.
|
||||
@@ -1,53 +0,0 @@
|
||||
---
|
||||
title: Negative UNL
|
||||
---
|
||||
_(Added by the \[NegativeUNL amendment]\[].)_
|
||||
|
||||
The `NegativeUNL` object type contains the current status of the Negative UNL, a list of trusted validators currently believed to be offline.
|
||||
|
||||
Each ledger version contains **at most one** `NegativeUNL` object. If no validators are currently disabled or scheduled to be disabled, there is no `NegativeUNL` object in the ledger.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"DisabledValidators": [
|
||||
{
|
||||
"DisabledValidator": {
|
||||
"FirstLedgerSequence": 1609728,
|
||||
"PublicKey": "ED6629D456285AE3613B285F65BBFF168D695BA3921F309949AFCD2CA7AFEC16FE"
|
||||
}
|
||||
}
|
||||
],
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "NegativeUNL",
|
||||
"index": "2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244"
|
||||
}
|
||||
```
|
||||
|
||||
A `NegativeUNL` object has the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| --------------------- | --------- | ------------------- | --------- | --------------------------------------------------------------------------------------------------------------------- |
|
||||
| `DisabledValidators` | Array | Array | No | A list of `DisabledValidator` objects (see below), each representing a trusted validator that is currently disabled. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags. No flags are defined for the NegativeUNL object type, so this value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x004E`, mapped to the string `NegativeUNL`, indicates that this object is the Negative UNL. |
|
||||
| `ValidatorToDisable` | String | Blob | No | The public key of a trusted validator that is scheduled to be disabled in the next flag ledger. |
|
||||
| `ValidatorToReEnable` | String | Blob | No | The public key of a trusted validator in the Negative UNL that is scheduled to be re-enabled in the next flag ledger. |
|
||||
|
||||
### DisabledValidator Objects
|
||||
|
||||
Each `DisabledValidator` object represents one disabled validator. In JSON, a `DisabledValidator` object has one field, `DisabledValidator`, which in turn contains another object with the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------------------- | --------- | ------------------- | ------------------------------------------------------------------------ |
|
||||
| `FirstLedgerSequence` | Number | UInt32 | The \[ledger index]\[] when the validator was added to the Negative UNL. |
|
||||
| `PublicKey` | String | Blob | The master public key of the validator, in hexadecimal. |
|
||||
|
||||
### NegativeUNL ID Format
|
||||
|
||||
The `NegativeUNL` object ID is the hash of the `NegativeUNL` space key (`0x004E`) only. This means that the ID of the `NegativeUNL` object in a ledger is always:
|
||||
|
||||
```
|
||||
2E8A59AA9D3B5B186B0B9E0F62E6C02587CA74A4D778938E957B6357D364B244
|
||||
```
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Offer
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L57)
|
||||
|
||||
The `Offer` ledger entry describes an Offer to exchange currencies in Xahau's decentralized exchange. (In finance, this is more traditionally known as an _order_.) An \[OfferCreate transaction]\[] only creates an `Offer` entry in the ledger when the Offer cannot be fully executed immediately by consuming other Offers already in the ledger.
|
||||
|
||||
An Offer can become unfunded through other activities in the network while remaining in the ledger. When processing transactions, the network automatically prunes any unfunded Offers that those transactions come across. (Otherwise, unfunded Offers remain because _only_ transactions can change the ledger state.)
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rBqb89MRQJnMPq8wTwEbtz4kvxrEDfcYvt",
|
||||
"BookDirectory": "ACC27DE91DBA86FC509069EAF4BC511D73128B780F2E54BF5E07A369E2446000",
|
||||
"BookNode": "0000000000000000",
|
||||
"Flags": 131072,
|
||||
"LedgerEntryType": "Offer",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "F0AB71E777B2DA54B86231E19B82554EF1F8211F92ECA473121C655BFC5329BF",
|
||||
"PreviousTxnLgrSeq": 14524914,
|
||||
"Sequence": 866,
|
||||
"TakerGets": {
|
||||
"currency": "XAG",
|
||||
"issuer": "r9Dr5xwkeLegBeXq6ujinjSBLQzQ1zQGjH",
|
||||
"value": "37"
|
||||
},
|
||||
"TakerPays": "79550000000",
|
||||
"index": "96F76F27D8A327FC48753167EC04A46AA0E382E6F57F32FD12274144D00F1797"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
An `Offer` object has the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | ---------------- | ------------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `Account` | String | AccountID | Yes | The address of the account that owns this Offer. |
|
||||
| `BookDirectory` | String | Hash256 | Yes | The ID of the Offer Directory that links to this Offer. |
|
||||
| `BookNode` | String | UInt64 | Yes | A hint indicating which page of the offer directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `Expiration` | Number | UInt32 | No | Indicates the time after which this Offer is considered unfunded. See \[Specifying Time]\[] for details. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this offer. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x006F`, mapped to the string `Offer`, indicates that this object describes an Offer. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The offer does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `Sequence` | Number | UInt32 | Yes | The `Sequence` value of the \[OfferCreate]\[] transaction that created this `Offer` object. Used in combination with the `Account` to identify this Offer. |
|
||||
| `TakerPays` | String or Object | Amount | Yes | The remaining amount and type of currency requested by the Offer creator. |
|
||||
| `TakerGets` | String or Object | Amount | Yes | The remaining amount and type of currency being provided by the Offer creator. |
|
||||
|
||||
### Offer Flags
|
||||
|
||||
There are several options that can be either enabled or disabled when an \[OfferCreate transaction]\[] creates an offer object. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with **`lsf`**.
|
||||
|
||||
`Offer` objects can have the following flag values:
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="135"></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td>Flag Name</td><td>Hex Value</td><td>Decimal Value</td><td>Corresponding OfferCreate Flag</td><td>Description</td></tr><tr><td><code>lsfPassive</code></td><td><code>0x00010000</code></td><td>65536</td><td><code>tfPassive</code></td><td>The object was placed as a passive Offer. This has no effect on the object in the ledger.</td></tr><tr><td><code>lsfSell</code></td><td><code>0x00020000</code></td><td>131072</td><td><code>tfSell</code></td><td>The object was placed as a sell Offer. This has no effect on the object in the ledger (because <code>tfSell</code> only matters if you get a better rate than you asked for, which cannot happen after the object enters the ledger).</td></tr></tbody></table>
|
||||
|
||||
### Offer ID Format
|
||||
|
||||
The ID of an `Offer` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The Offer space key (`0x006F`)
|
||||
* The AccountID of the account placing the Offer
|
||||
* The Sequence number of the \[OfferCreate transaction]\[] that created the Offer.
|
||||
|
||||
If the OfferCreate transaction used a Ticket, use the `TicketSequence` value instead.
|
||||
@@ -1,99 +0,0 @@
|
||||
---
|
||||
title: Pay Channel
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/c0a0b79d2d483b318ce1d82e526bd53df83a4a2c/src/ripple/protocol/impl/LedgerFormats.cpp#L180-L198)
|
||||
|
||||
_(Added by the \[PayChan amendment]\[].)_
|
||||
|
||||
The `PayChannel` object type represents a payment channel. Payment channels enable small, rapid off-ledger payments of XAH or IOU that can be later reconciled with the consensus ledger. A payment channel holds a balance of XAH or IOU that can only be paid out to a specific destination address until the channel is closed. Any unspent XAH or IOU is returned to the channel's owner (the source address that created and funded it) when the channel closes.
|
||||
|
||||
The \[PaymentChannelCreate transaction]\[] type creates a `PayChannel` object. The \[PaymentChannelFund]\[] and \[PaymentChannelClaim transaction]\[] types modify existing `PayChannel` objects.
|
||||
|
||||
When a payment channel expires, at first it remains on the ledger, because only new transactions can modify ledger contents. Transaction processing automatically closes a payment channel when any transaction accesses it after the expiration. To close an expired channel and return the unspent XAH or IOU to the owner, some addresses must send a new PaymentChannelClaim or PaymentChannelFund transaction accessing the channel.
|
||||
|
||||
For an example of using payment channels, see the Payment Channels Tutorial.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rBqb89MRQJnMPq8wTwEbtz4kvxrEDfcYvt",
|
||||
"Destination": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": "4325800",
|
||||
"Balance": "2323423",
|
||||
"PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A",
|
||||
"SettleDelay": 3600,
|
||||
"Expiration": 536027313,
|
||||
"CancelAfter": 536891313,
|
||||
"SourceTag": 0,
|
||||
"DestinationTag": 1002341,
|
||||
"DestinationNode": "0000000000000000",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "PayChannel",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "F0AB71E777B2DA54B86231E19B82554EF1F8211F92ECA473121C655BFC5329BF",
|
||||
"PreviousTxnLgrSeq": 14524914,
|
||||
"index": "96F76F27D8A327FC48753167EC04A46AA0E382E6F57F32FD12274144D00F1797"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `PayChannel` object has the following fields:
|
||||
|
||||
| Name | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | ---------------- | ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | Yes | The source address that owns this payment channel. This comes from the sending address of the transaction that created the channel. |
|
||||
| `Amount` | String or Object | Amount | Yes | Total amount, that has been allocated to this channel. This includes amounts that has been paid to the destination address. This is initially set by the transaction that created the channel and can be increased if the source address sends a PaymentChannelFund transaction. |
|
||||
| `Balance` | String or Object | Amount | Yes | Total amount already paid out by the channel. The difference between this value and the `Amount` field is how much amount can still be paid to the destination address with PaymentChannelClaim transactions. If the channel closes, the remaining difference is returned to the source address. |
|
||||
| `CancelAfter` | Number | UInt32 | No | The immutable expiration time for this payment channel, in \[seconds since the Ripple Epoch]\[]. This channel is expired if this value is present and smaller than the previous ledger's `close_time` field. This is optionally set by the transaction that created the channel, and cannot be changed. |
|
||||
| `Destination` | String | AccountID | Yes | The destination address for this payment channel. While the payment channel is open, this address is the only one that can receive the amount from the channel. This comes from the `Destination` field of the transaction that created the channel. |
|
||||
| `DestinationTag` | Number | UInt32 | No | An arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. |
|
||||
| `DestinationNode` | String | UInt64 | No | A hint indicating which page of the destination's owner directory links to this object, in case the directory consists of multiple pages. Omitted on payment channels created before enabling the \[fixPayChanRecipientOwnerDir amendment]\[]. |
|
||||
| `Expiration` | Number | UInt32 | No | The mutable expiration time for this payment channel, in \[seconds since the Ripple Epoch]\[]. The channel is expired if this value is present and smaller than the previous ledger's `close_time` field. See Setting Channel Expiration for more details. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `PayChannel` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0078`, mapped to the string `PayChannel`, indicates that this object is a payment channel object. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the source address's owner directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `PublicKey` | String | Blob | Yes | Public key, in hexadecimal, of the key pair that can be used to sign claims against this channel. This can be any valid secp256k1 or Ed25519 public key. This is set by the transaction that created the channel and must match the public key used in claims against the channel. The channel source address can also send amounts from this channel to the destination without signed claims. |
|
||||
| `SettleDelay` | Number | UInt32 | Yes | Number of seconds the source address must wait to close the channel if it still has any amount in it. Smaller values mean that the destination address has less time to redeem any outstanding claims after the source address requests to close the channel. Can be any value that fits in a 32-bit unsigned integer (0 to 2^32-1). This is set by the transaction that creates the channel. |
|
||||
| `SourceTag` | Number | UInt32 | No | An arbitrary tag to further specify the source for this payment channel, such as a hosted recipient at the owner's address. |
|
||||
| `TransferRate` | Number | UInt32 | No | |
|
||||
|
||||
### Setting Channel Expiration
|
||||
|
||||
The `Expiration` field of a payment channel is the mutable expiration time, in contrast to the immutable expiration time represented by the `CancelAfter` field. The expiration of a channel is always considered relative to the `close_time` field of the previous ledger. The `Expiration` field is omitted when a `PayChannel` object is created. There are several ways the `Expiration` field of a `PayChannel` object can be updated, which can be summarized as follows: a channel's source address can set the `Expiration` of the channel freely as long as the channel always remains open at least `SettleDelay` seconds after the first attempt to close it.
|
||||
|
||||
#### Source Address
|
||||
|
||||
The source address can set the `Expiration` directly with the PaymentChannelFund transaction type. The new value must not be earlier than whichever of the following values is earliest:
|
||||
|
||||
* The current `Expiration` value (if one is set)
|
||||
* The previous ledger's close time plus the `SettleDelay` of the channel
|
||||
|
||||
In other words, the source address can always make the `Expiration` later if an expiration is already set. The source can make an `Expiration` value earlier or set an `Expiration` if one isn't currently set, as long as the new value is at least `SettleDelay` seconds in the future. If the source address attempts to set an invalid `Expiration` date, the transaction fails with the `temBAD_EXPIRATION` error code.
|
||||
|
||||
The source address can also set the `Expiration` with the `tfClose` flag of the PaymentChannelClaim transaction type. If the flag is enabled, the ledger automatically sets the `Expiration` to whichever of the following values is earlier:
|
||||
|
||||
* The current `Expiration` value (if one is set)
|
||||
* The previous ledger's close time plus the `SettleDelay` of the channel
|
||||
|
||||
The source address can remove the `Expiration` with the `tfRenew` flag of the PaymentChannelClaim transaction type.
|
||||
|
||||
#### Destination Address
|
||||
|
||||
The destination address cannot set the `Expiration` field. However, the destination address can use the PaymentChannelClaim's `tfClose` flag to close a channel immediately.
|
||||
|
||||
#### Other Addresses
|
||||
|
||||
If any other address attempts to set an `Expiration` field, the transaction fails with the `tecNO_PERMISSION` error code. However, if the channel is already expired, the transaction causes the channel to close and results in `tesSUCCESS` instead.
|
||||
|
||||
### PayChannel ID Format
|
||||
|
||||
The ID of a `PayChannel` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The PayChannel space key (`0x0078`)
|
||||
* The AccountID of the source account
|
||||
* The AccountID of the destination account
|
||||
* The Sequence number of the \[PaymentChannelCreate transaction]\[] that created the channel If the PaymentChannelCreate transaction used a Ticket, use the `TicketSequence` value instead.
|
||||
@@ -1,120 +0,0 @@
|
||||
---
|
||||
title: Ripple State
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L70)
|
||||
|
||||
The `RippleState` object type connects two accounts in a single currency. Conceptually, a `RippleState` object represents two trust lines between the accounts, one from each side. Each account can change the settings for its side of the `RippleState` object, but the balance is a single shared value. A trust line that is entirely in its default state is considered the same as a trust line that does not exist, so `rippled` deletes `RippleState` objects when their properties are entirely default.
|
||||
|
||||
### High vs. Low Account
|
||||
|
||||
There can only be one `RippleState` object per currency for any given pair of accounts. Since no account is privileged in Xahau, a `RippleState` object sorts account addresses numerically, to ensure a canonical form. Whichever address is numerically lower when decoded is deemed the "low account" and the other is the "high account". The net balance of the trust line is stored from the low account's perspective.
|
||||
|
||||
The "issuer" for the balance in a trust line depends on whether the balance is positive or negative. If a `RippleState` object shows a positive balance, the high account is the issuer. If the balance is negative, the low account is the issuer. Often, the issuer has its limit set to 0 and the other account has a positive limit, but this is not reliable because limits can change without affecting an existing balance.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "-10"
|
||||
},
|
||||
"Flags": 393216,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "110"
|
||||
},
|
||||
"HighNode": "0000000000000000",
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"value": "0"
|
||||
},
|
||||
"LowNode": "0000000000000000",
|
||||
"PreviousTxnID": "E3FE6EA3D48F0C2B639448020EA4F03D4F4F8FFDB243A852A0F59177921B4879",
|
||||
"PreviousTxnLgrSeq": 14090896,
|
||||
"LockCount": 1,
|
||||
"LockedBalance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"value": "10"
|
||||
}
|
||||
"index": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `RippleState` object has the following fields:
|
||||
|
||||
| Name | JSON Type | Internal Type | Required? | Description |
|
||||
| ------------------- | --------- | ------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Balance` | Object | Amount | Yes | The balance of the trust line, from the perspective of the low account. A negative balance indicates that the high account holds tokens issued by the low account. The issuer in this is always set to the neutral value ACCOUNT_ONE. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean options enabled for this object. |
|
||||
| `HighLimit` | Object | Amount | Yes | The limit that the high account has set on the trust line. The `issuer` is the address of the high account that set this limit. |
|
||||
| `HighNode` | String | UInt64 | Yes | (Omitted in some historical ledgers) A hint indicating which page of the high account's owner directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `HighQualityIn` | Number | UInt32 | No | The inbound quality set by the high account, as an integer in the implied ratio `HighQualityIn`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
|
||||
| `HighQualityOut` | Number | UInt32 | No | The outbound quality set by the high account, as an integer in the implied ratio `HighQualityOut`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0072`, mapped to the string `RippleState`, indicates that this object is a RippleState object. |
|
||||
| `LowLimit` | Object | Amount | Yes | The limit that the low account has set on the trust line. The `issuer` is the address of the low account that set this limit. |
|
||||
| `LowNode` | String | UInt64 | Yes | (Omitted in some historical ledgers) A hint indicating which page of the low account's owner directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `LowQualityIn` | Number | UInt32 | No | The inbound quality set by the low account, as an integer in the implied ratio `LowQualityIn`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
|
||||
| `LowQualityOut` | Number | UInt32 | No | The outbound quality set by the low account, as an integer in the implied ratio `LowQualityOut`:1,000,000,000. As a special case, the value 0 is equivalent to 1 billion, or face value. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `LockCount` | Number | UInt32 | No | The total number of lock balances on a RippleState ledger object |
|
||||
| `LockedBalance` | Object | Amount | No | The current amount of locked tokens for a specific trustline |
|
||||
|
||||
### RippleState Flags
|
||||
|
||||
There are several options which can be either enabled or disabled for a trust line. These options can be changed with a \[TrustSet transaction]\[]. In the ledger, flags are represented as binary values that can be combined with bitwise-or operations. The bit values for the flags in the ledger are different than the values used to enable or disable those flags in a transaction. Ledger flags have names that begin with **`lsf`**.
|
||||
|
||||
RippleState objects can have the following flag values:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Corresponding TrustSet Flag | Description |
|
||||
| ----------------- | ------------ | ------------- | --------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| `lsfLowReserve` | `0x00010000` | 65536 | (None) | This RippleState object contributes to the low account's owner reserve. |
|
||||
| `lsfHighReserve` | `0x00020000` | 131072 | (None) | This RippleState object contributes to the high account's owner reserve. |
|
||||
| `lsfLowAuth` | `0x00040000` | 262144 | `tfSetAuth` | The low account has authorized the high account to hold tokens issued by the low account. |
|
||||
| `lsfHighAuth` | `0x00080000` | 524288 | `tfSetAuth` | The high account has authorized the low account to hold tokens issued by the high account. |
|
||||
| `lsfLowNoRipple` | `0x00100000` | 1048576 | `tfSetNoRipple` | The low account has disabled rippling from this trust line. |
|
||||
| `lsfHighNoRipple` | `0x00200000` | 2097152 | `tfSetNoRipple` | The high account has disabled rippling from this trust line. |
|
||||
| `lsfLowFreeze` | `0x00400000` | 4194304 | `tfSetFreeze` | The low account has frozen the trust line, preventing the high account from transferring the asset. |
|
||||
| `lsfHighFreeze` | `0x00800000` | 8388608 | `tfSetFreeze` | The high account has frozen the trust line, preventing the low account from transferring the asset. |
|
||||
| `lsfLowDeepFreeze` | `0x02000000` | 33554432 | `tfSetDeepFreeze` | The low account has deep-frozen the trust line, preventing the high account from sending and receiving the asset. _(Requires the \[DeepFreeze amendment]\[])_ |
|
||||
| `lsfHighDeepFreeze` | `0x04000000` | 67108864 | `tfSetDeepFreeze` | The high account has deep-frozen the trust line, preventing the low account from sending and receiving the asset. _(Requires the \[DeepFreeze amendment]\[])_ |
|
||||
|
||||
### Contributing to the Owner Reserve
|
||||
|
||||
If an account modifies a trust line to put it in a non-default state, then that trust line counts towards the account's owner reserve. In a RippleState object, the `lsfLowReserve` and `lsfHighReserve` flags indicate which account(s) are responsible for the owner reserve. The `rippled` server automatically sets these flags when it modifies a trust line.
|
||||
|
||||
The values that count towards a trust line's non-default state are as follows:
|
||||
|
||||
| High account responsible if... | Low account responsible if... |
|
||||
| ------------------------------------------------------- | ------------------------------------------------------ |
|
||||
| `Balance` is negative (the high account holds currency) | `Balance` is positive (the low account holds currency) |
|
||||
| `HighLimit` is not `0` | `LowLimit` is not `0` |
|
||||
| `LowQualityIn` is not `0` and not `1000000000` | `HighQualityIn` is not `0` and not `1000000000` |
|
||||
| `LowQualityOut` is not `0` and not `1000000000` | `HighQualityOut` is not `0` and not `1000000000` |
|
||||
| `lsfHighNoRipple` flag is not in its default state | `lsfLowNoRipple` flag is not in its default state |
|
||||
| `lsfHighFreeze` flag is enabled | `lsfLowFreeze` flag is enabled |
|
||||
|
||||
The **`lsfLowAuth`** and **`lsfHighAuth`** flags do not count against the default state, because they cannot be disabled.
|
||||
|
||||
The default state of the two No Ripple flags depends on the state of the `lsfDefaultRipple` flag in their corresponding AccountRoot objects. If Default Ripple is disabled (the default), then the default state of the `lsfNoRipple` flag is _enabled_ for all of an account's trust lines. If an account enables Default Ripple, then the `lsfNoRipple` flag is _disabled_ (rippling is enabled) for an account's trust lines by default.
|
||||
|
||||
**Note:** Prior to the introduction of the Default Ripple flag in `rippled` version 0.27.3 (March 10, 2015), the default state for all trust lines was with both No Ripple flags disabled (rippling enabled).
|
||||
|
||||
Fortunately, `rippled` uses lazy evaluation to calculate the owner reserve. This means that even if an account changes the default state of all its trust lines by changing the Default Ripple flag, that account's reserve stays the same initially. If an account modifies a trust line, `rippled` re-evaluates whether that individual trust line is in its default state and should contribute to the owner reserve.
|
||||
|
||||
### RippleState ID Format
|
||||
|
||||
The ID of a RippleState object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The RippleState space key (`0x0072`)
|
||||
* The AccountID of the low account
|
||||
* The AccountID of the high account
|
||||
* The 160-bit currency code of the trust line(s)
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
title: Signers List
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/6d2e3da30696bd10e3bb11a5ff6d45d2c4dae90f/src/ripple/protocol/impl/LedgerFormats.cpp#L127)
|
||||
|
||||
_(Added by the \[MultiSign amendment]\[].)_
|
||||
|
||||
The `SignerList` object type represents a list of parties that, as a group, are authorized to sign a transaction in place of an individual account. You can create, replace, or remove a signer list using a \[SignerListSet transaction]\[].
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "SignerList",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "5904C0DC72C58A83AEFED2FFC5386356AA83FCA6A88C89D00646E51E687CDBE4",
|
||||
"PreviousTxnLgrSeq": 16061435,
|
||||
"SignerEntries": [
|
||||
{
|
||||
"SignerEntry": {
|
||||
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SignerWeight": 2
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry": {
|
||||
"Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"SignerWeight": 1
|
||||
}
|
||||
},
|
||||
{
|
||||
"SignerEntry": {
|
||||
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"SignerWeight": 1
|
||||
}
|
||||
}
|
||||
],
|
||||
"SignerListID": 0,
|
||||
"SignerQuorum": 3,
|
||||
"index": "A9C28A28B85CD533217F5C0A0C7767666B093FA58A0F2D80026FCC4CD932DDC7"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `SignerList` object has the following fields:
|
||||
|
||||
| Name | JSON Type | Internal Type | Required? | Description |
|
||||
| ------------------- | --------- | ------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of Boolean flags enabled for this signer list. For more information, see SignerList Flags. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0053`, mapped to the string `SignerList`, indicates that this object is a SignerList object. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `SignerEntries` | Array | Array | Yes | An array of Signer Entry objects representing the parties who are part of this signer list. |
|
||||
| `SignerListID` | Number | UInt32 | Yes | An ID for this signer list. Currently always set to `0`. If a future amendment allows multiple signer lists for an account, this may change. |
|
||||
| `SignerQuorum` | Number | UInt32 | Yes | A target number for signer weights. To produce a valid signature for the owner of this SignerList, the signers must provide valid signatures whose weights sum to this value or more. |
|
||||
|
||||
The `SignerEntries` may be any combination of funded and unfunded addresses that use either secp256k1 or ed25519 keys.
|
||||
|
||||
#### Signer Entry Object
|
||||
|
||||
Each member of the `SignerEntries` field is an object that describes that signer in the list. A Signer Entry has the following fields:
|
||||
|
||||
| Name | JSON Type | Internal Type | Description |
|
||||
| --------------- | --------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | A Xahau address whose signature contributes to the multi-signature. It does not need to be a funded address in the ledger. |
|
||||
| `SignerWeight` | Number | UInt16 | The weight of a signature from this signer. A multi-signature is only valid if the sum weight of the signatures provided meets or exceeds the signer list's `SignerQuorum` value. |
|
||||
| `WalletLocator` | String | Hash256 | _(Optional)_ Arbitrary hexadecimal data. This can be used to identify the signer or for other, related purposes. _(Added by the \[ExpandedSignerList amendment]\[].)_ |
|
||||
|
||||
When processing a multi-signed transaction, the server looks up the `Account` values with respect to the ledger at the time of transaction execution. If the address _does not_ correspond to a funded AccountRoot object, then only the master private key associated with that address can be used to produce a valid signature. If the account _does_ exist in the ledger, then it depends on the state of that account. If the account has a Regular Key configured, the Regular Key can be used. The account's master key can only be used if it is not disabled. A multi-signature cannot be used as part of another multi-signature.
|
||||
|
||||
### SignerList Flags
|
||||
|
||||
_(Added by the \[MultiSignReserve amendment]\[].)_
|
||||
|
||||
SignerList objects can have the following flag value:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| ------------------ | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `lsfOneOwnerCount` | `0x00010000` | 65536 | If this flag is enabled, this SignerList counts as one item for purposes of the owner reserve. Otherwise, this list counts as N+2 items, where N is the number of signers it contains. This flag is automatically enabled if you add or update a signer list after the \[MultiSignReserve amendment]\[] is enabled. |
|
||||
|
||||
### Signer Lists and Reserves
|
||||
|
||||
A signer list contributes to its owner's reserve requirement.
|
||||
|
||||
The \[MultiSignReserve amendment]\[] (enabled 2019-04-17) made it so each signer list counts as one object, regardless of how many members it has. As a result, the owner reserve associated with a new signer list is 2 XAH.
|
||||
|
||||
A signer list created before the \[MultiSignReserve amendment]\[] itself counts as two objects, and each member of the list counts as one. As a result, the total owner reserve associated with the signer list is anywhere from 3 times to 10 times the reserve required by a single trust line (RippleState) or Offer object in the ledger. To update a signer list to use the new, reduced reserve, update the signer list by sending a \[SignerListSet transaction]\[].
|
||||
|
||||
### SignerList ID Format
|
||||
|
||||
The ID of a signer list object is the SHA-512Half of the following values, concatenated in order:
|
||||
|
||||
* The RippleState space key (`0x0053`)
|
||||
* The AccountID of the owner of the signer list
|
||||
* The `SignerListID` (currently always `0`)
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Ticket
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/76a6956138c4ecd156c5c408f136ed3d6ab7d0c1/src/ripple/protocol/impl/LedgerFormats.cpp#L155-L164)
|
||||
|
||||
_(Added by the \[TicketBatch amendment]\[].)_
|
||||
|
||||
The `Ticket` object type represents a Ticket, which tracks an account \[sequence number]\[Sequence Number] that has been set aside for future use. You can create new tickets with a \[TicketCreate transaction]\[]. \[New in: rippled 1.7.0]\[]
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "Ticket",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"PreviousTxnID": "F19AD4577212D3BEACA0F75FE1BA1644F2E854D46E8D62E9C95D18E9708CBFB1",
|
||||
"PreviousTxnLgrSeq": 4,
|
||||
"TicketSequence": 3
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `Ticket` object has the following fields:
|
||||
|
||||
| Name | JSON Type | Internal Type | Required? | Description |
|
||||
| ------------------- | --------- | ------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | Yes | The account that owns this Ticket. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Ticket` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0054`, mapped to the string `Ticket`, indicates that this object is a Ticket object. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner directory links to this object, in case the directory consists of multiple pages. **Note:** The object does not contain a direct link to the owner directory containing it, since that value can be derived from the `Account`. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The \[index of the ledger]\[Ledger Index] that contains the transaction that most recently modified this object. |
|
||||
| `TicketSequence` | Number | UInt32 | Yes | The \[Sequence Number]\[] this Ticket sets aside. |
|
||||
|
||||
### Ticket ID Format
|
||||
|
||||
The ID of a Ticket object is the SHA-512Half of the following values, concatenated in order:
|
||||
|
||||
* The Ticket space key (`0x0054`)
|
||||
* The AccountID of the owner of the Ticket
|
||||
* The `TicketSequence` number of the Ticket
|
||||
@@ -1,63 +0,0 @@
|
||||
---
|
||||
title: UNL Report
|
||||
---
|
||||
_(Added by the \[Hooks amendment]\[].)_
|
||||
|
||||
A `UNLReport` object describes a report of the Unique Node List (UNL) which is a list of validator nodes that are trusted by the network to validate transactions.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"LedgerEntryType": "UNLReport",
|
||||
"PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
|
||||
"PreviousTxnLgrSeq": 6,
|
||||
"ImportVLKeys": [
|
||||
{
|
||||
"PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy",
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo"
|
||||
}
|
||||
],
|
||||
"ActiveValidators": [
|
||||
{
|
||||
"PublicKey": "n9LigbVAi4pQc6pU2KJvQZV5wqJ8C3sVvZvBZUopchH8vqa6PEKy",
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo"
|
||||
}
|
||||
],
|
||||
"index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `UNLReport` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | --------- | ------------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `UNLReport`, indicates that this object is a UNLReport object. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The index of the ledger that contains the transaction that most recently modified this object. |
|
||||
| `ImportVLKeys` | Array | Array | No | An array of objects, each representing a validator key that has been imported. Each object has a `PublicKey` field and an optional `Account` field. |
|
||||
| `ActiveValidators` | Array | Array | No | An array of objects, each representing an active validator. Each object has a `PublicKey` field and an optional `Account` field. |
|
||||
|
||||
### ImportVLKey Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------- | --------- | ------------------- | --------- | ------------------------------------------------------------------------------- |
|
||||
| `PublicKey` | String | VL | Yes | The public key of the imported validator. |
|
||||
| `Account` | String | Account | No | The account associated with the imported validator key. This field is optional. |
|
||||
|
||||
### ActiveValidator Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ----------- | --------- | ------------------- | --------- | ------------------------------------------------------------------------- |
|
||||
| `PublicKey` | String | VL | Yes | The public key of the active validator. |
|
||||
| `Account` | String | Account | No | The account associated with the active validator. This field is optional. |
|
||||
|
||||
### UNLReport ID Format
|
||||
|
||||
The `UNLReport` object ID is the hash of the `UNLReport` space key (`0x0052`) only. This means that the ID of the `UNLReport` object in a ledger is always:
|
||||
|
||||
```
|
||||
61E32E7A24A238F1C619D5F9DDCC41A94B33B66C0163F7EFCC8A19C9FD6F28DC
|
||||
```
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
title: URIToken
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/LedgerFormats.cpp#L157-L170)
|
||||
|
||||
_(Added by the \[URI Token amendment]\[].)_
|
||||
|
||||
A `URIToken` object describes a URI token, which can be used to represent a unique resource identifier in the ledger.
|
||||
|
||||
### Example JSON
|
||||
|
||||
```json
|
||||
{
|
||||
"Owner": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"OwnerNode": "0000000000000000",
|
||||
"Issuer": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
|
||||
"URI": "DEADBEEF",
|
||||
"Digest": "46060241FABCF692D4D934BA2A6C4427CD4279083E38C77CBE642243E43BE291",
|
||||
"Amount": "100000000",
|
||||
"Destination": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"PreviousTxnID": "5463C6E08862A1FAE5EDAC12D70ADB16546A1F674930521295BC082494B62924",
|
||||
"PreviousTxnLgrSeq": 6,
|
||||
"LedgerEntryType": "URIToken",
|
||||
"index": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
A `URIToken` object has the following fields:
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ------------------- | ---------------- | ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Owner` | String | Account | Yes | The owner of the URI Token. |
|
||||
| `OwnerNode` | String | UInt64 | Yes | A hint indicating which page of the owner's directory links to this object, in case the directory consists of multiple pages. |
|
||||
| `Issuer` | String | Account | Yes | The issuer of the URI Token. |
|
||||
| `URI` | String | VL | Yes | The URI represented by this token. |
|
||||
| `Digest` | String | Hash256 | No | Arbitrary 256-bit hash provided by the owner as a specific identifier for this URI Token. |
|
||||
| `Amount` | String or Object | Amount | No | The amount of the URI Token. |
|
||||
| `Destination` | String | Account | No | The intended recipient of the URI Token. |
|
||||
| `PreviousTxnID` | String | Hash256 | Yes | The identifying hash of the transaction that most recently modified this object. |
|
||||
| `PreviousTxnLgrSeq` | Number | UInt32 | Yes | The index of the ledger that contains the transaction that most recently modified this object. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0073`, mapped to the string `URIToken`, indicates that this object is a URI Token object. |
|
||||
|
||||
### URIToken Flags
|
||||
|
||||
`URIToken` objects can have the following flag values:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Corresponding URITokenMint Flag | Description |
|
||||
| ------------- | ------------ | ------------- | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `lsfBurnable` | `0x00000001` | 1 | `tfBurnable` | The issuer (or an entity authorized by the issuer) to destroy the minted `URIToken`. (The `URIToken`'s owner can _always_ do so.) |
|
||||
|
||||
### URIToken ID Format
|
||||
|
||||
The ID of a `URIToken` object is the \[SHA-512Half]\[] of the following values, concatenated in order:
|
||||
|
||||
* The URI Token space key (`0x0055`)
|
||||
* The AccountID of the issuer of the URI Token
|
||||
* The URI represented by the URI Token
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
title: AccountDelete
|
||||
description: >-
|
||||
An AccountDelete transaction deletes an account and any objects it owns in
|
||||
Xahau, if possible, sending the account's remaining XAH to a specified
|
||||
destination account.
|
||||
sidebar:
|
||||
badge:
|
||||
text: Disabled
|
||||
variant: danger
|
||||
---
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/DeleteAccount.cpp)]
|
||||
|
||||
_Added by the DeletableAccounts amendment_
|
||||
|
||||
<Aside type="danger" title="Not enabled">
|
||||
The _DeletableAccounts_ amendment is not enabled at this time.
|
||||
</Aside>
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "AccountDelete",
|
||||
"Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
|
||||
"Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
|
||||
"DestinationTag": 13,
|
||||
"Fee": "2000000",
|
||||
"Sequence": 2470665,
|
||||
"Flags": 2147483648
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ---------------- | ---------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Destination` | String - \[Address]\[] | AccountID | The address of an account to receive any leftover XAH after deleting the sending account. Must be a funded account in the ledger, and must not be the sending account. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary destination tag that identifies a hosted recipient or other information for the recipient of the deleted account's leftover XAH. |
|
||||
|
||||
### Special Transaction Cost
|
||||
|
||||
As an additional deterrent against ledger spam, the AccountDelete transaction requires a much higher than usual transaction cost: instead of the standard minimum of 0.00001 XAH, AccountDelete must destroy at least the owner reserve amount, currently 2 XRP. This discourages excessive creation of new accounts because the reserve requirement cannot be fully recouped by deleting the account.
|
||||
|
||||
The transaction cost always applies when a transaction is included in a validated ledger, even if the transaction fails to delete the account. (See Error Cases.) To greatly reduce the chances of paying the high transaction cost if the account cannot be deleted, submit the transaction with `fail_hard` enabled.
|
||||
|
||||
### Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, AccountDelete transactions can result in the following transaction result codes:
|
||||
|
||||
| Error Code | Description |
|
||||
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `temDISABLED` | Occurs if the DeletableAccounts amendment is not enabled. |
|
||||
| `temDST_IS_SRC` | Occurs if the `Destination` matches the sender of the transaction (`Account` field). |
|
||||
| `tecDST_TAG_NEEDED` | Occurs if the `Destination` account requires a destination tag, but the `DestinationTag` field was not provided. |
|
||||
| `tecNO_DST` | Occurs if the `Destination` account is not a funded account in the ledger. |
|
||||
| `tecNO_PERMISSION` | Occurs if the `Destination` account requires deposit authorization and the sender is not preauthorized. |
|
||||
| `tecTOO_SOON` | Occurs if the sender's `Sequence` number is too high. The transaction's `Sequence` number plus 256 must be less than the current \[Ledger Index]\[]. This prevents replay of old transactions if this account is resurrected after it is deleted. |
|
||||
| `tecHAS_OBLIGATIONS` | Occurs if the account to be deleted is connected to objects that cannot be deleted in the ledger. (This includes objects created by other accounts, such as escrows and for example NFT's minted, [even if owned by another account](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/DeleteAccount.cpp#L197).) |
|
||||
| `tefTOO_BIG` | Occurs if the sending account is linked to more than 1000 objects in the ledger. The transaction could succeed on retry if some of those objects were deleted separately first. |
|
||||
|
||||
@@ -1,116 +0,0 @@
|
||||
---
|
||||
title: AccountSet
|
||||
description: An AccountSet transaction modifies the properties of an account in Xahau.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/SetAccount.cpp)]
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "AccountSet",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12",
|
||||
"Sequence": 5,
|
||||
"Domain": "6578616D706C652E636F6D",
|
||||
"SetFlag": 5,
|
||||
"MessageKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
|
||||
"HookStateScale": 10
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------------- | --------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ClearFlag` | Number | UInt32 | _(Optional)_ Unique identifier of a flag to disable for this account. |
|
||||
| `Domain` | String | Blob | _(Optional)_ The domain that owns this account, as a string of hex representing the ASCII for the domain in lowercase. [Cannot be more than 256 bytes in length.](https://github.com/Xahau/xahaud/blob/55dc7a252e08a0b02cd5aa39e9b4777af3eafe77/src/ripple/app/tx/impl/SetAccount.h#L34) |
|
||||
| `EmailHash` | String | Hash128 | _(Optional)_ An arbitrary 128-bit value. Conventionally, clients treat this as the md5 hash of an email address to use for displaying a [Gravatar](http://en.gravatar.com/site/implement/hash/) image. |
|
||||
| `MessageKey` | String | Blob | _(Optional)_ Public key for sending encrypted messages to this account. To set the key, it must be exactly 33 bytes, with the first byte indicating the key type: `0x02` or `0x03` for secp256k1 keys, `0xED` for Ed25519 keys. To remove the key, use an empty value. |
|
||||
| `NFTokenMinter` | String | Blob | _(Optional)_ Another account that can mint NFTokens for you. _(Added by the \[NonFungibleTokensV1_1 amendment]\[].)_ |
|
||||
| `SetFlag` | Number | UInt32 | _(Optional)_ Integer flag to enable for this account. |
|
||||
| `TransferRate` | Number | UInt32 | _(Optional)_ The fee to charge when users transfer this account's tokens, represented as billionths of a unit. Cannot be more than `2000000000` or less than `1000000000`, except for the special case `0` meaning no fee. |
|
||||
| `TickSize` | Number | UInt8 | _(Optional)_ Tick size to use for offers involving a currency issued by this address. The exchange rates of those offers is rounded to this many significant digits. Valid values are `3` to `15` inclusive, or `0` to disable. _(Added by the \[TickSize amendment]\[])_ |
|
||||
| `WalletLocator` | String | Hash256 | _(Optional)_ An arbitrary 256-bit value. If specified, the value is stored as part of the account but has no inherent meaning or requirements. |
|
||||
| `WalletSize` | Number | UInt32 | _(Optional)_ Not used. This field is valid in AccountSet transactions but does nothing. |
|
||||
| `HookStateScale` | Number | UInt16 | _(Optional)_ Scale factor for determining when Hook state entries become stale. Valid values are `1` to `16` inclusive. _(Added by the [ExtendedHookState amendment][].)_ |
|
||||
|
||||
If none of these options are provided, then the AccountSet transaction has no effect (beyond destroying the transaction cost). See Cancel or Skip a Transaction for more details.
|
||||
|
||||
### Domain
|
||||
|
||||
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"`.
|
||||
|
||||
To remove the `Domain` field from an account, send an AccountSet with the Domain set to an empty string.
|
||||
|
||||
You can put any domain in your account's `Domain` field. To prove that an account and domain belong to the same person or business, you need a "two-way link":
|
||||
|
||||
* Accounts you own should have a domain you own in the `Domain` field.
|
||||
* At that domain, host a [xahau.toml](/docs/infrastructure/identity) file listing accounts you own, and optionally other information about how you use Xahau.
|
||||
|
||||
### 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:
|
||||
|
||||
* 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. Newer options have only this style of flag. You can enable up to one `asf` flag per transaction, and disable up to one `asf` flag per transaction.
|
||||
* 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. You can enable and disable a combination of settings in one transaction using multiple `tf` flags, but not all settings have `tf` flags.
|
||||
* The `AccountRoot` ledger object type has several ledger-state-flags (prefixed **`lsf`**) which represent the state of particular account options within a particular ledger. These settings apply until a transaction changes them.
|
||||
|
||||
To enable or disable Account Flags, use the `SetFlag` and `ClearFlag` parameters of an AccountSet transaction. AccountSet flags have names that begin with **`asf`**.
|
||||
|
||||
All flags are disabled by default.
|
||||
|
||||
The available AccountSet flags are:
|
||||
|
||||
| Flag Name | Decimal Value | Corresponding Ledger Flag | Description |
|
||||
| --------------------------------- | ------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `asfAccountTxnID` | 5 | (None) | Track the ID of this account's most recent transaction. Required for `AccountTxnID` |
|
||||
| `asfAllowTrustLineClawback` | 17 | `lsfAllowTrustLineClawback` | Enables an account to clawback tokens it has issued. This flag can only be enabled if the account’s owner directory is empty (no trust lines, offers, escrows, payment channels, checks, or signer lists). Once set, it cannot be undone. |
|
||||
| `asfAuthorizedNFTokenMinter` | 10 | (None) | Enable to allow another account to mint non-fungible tokens (NFTokens) on this account's behalf. Specify the authorized account in the `NFTokenMinter` field of the AccountRoot object. To remove an authorized minter, enable this flag and omit the `NFTokenMinter` field. _(Added by the \[NonFungibleTokensV1_1 amendment]\[].)_ |
|
||||
| `asfDefaultRipple` | 8 | `lsfDefaultRipple` | Enable rippling on this account's trust lines by default. |
|
||||
| `asfDepositAuth` | 9 | `lsfDepositAuth` | Enable Deposit Authorization on this account. _(Added by the \[DepositAuth amendment]\[].)_ |
|
||||
| `asfDisableMaster` | 4 | `lsfDisableMaster` | Disallow use of the master key pair. Can only be enabled if the account has configured another way to sign transactions, such as a Regular Key or a Signer List. |
|
||||
| `asfDisallowIncomingCheck` | 13 | `lsfDisallowIncomingCheck` | Block incoming Checks. _Added by the \[DisallowIncoming amendment]\[]._ |
|
||||
| `asfDisallowIncomingNFTokenOffer` | 12 | `lsfDisallowIncomingNFTokenOffer` | Block incoming NFTokenOffers. _Added by the \[DisallowIncoming amendment]\[]._ |
|
||||
| `asfDisallowIncomingPayChan` | 14 | `lsfDisallowIncomingPayChan` | Block incoming Payment Channels. _Added by the \[DisallowIncoming amendment]\[]._ |
|
||||
| `asfDisallowIncomingTrustline` | 15 | `lsfDisallowIncomingTrustline` | Block incoming trust lines._Added by the \[DisallowIncoming amendment]\[]._ |
|
||||
| `asfDisallowIncomingRemit` | 16 | `lsfDisallowIncomingRemit` | Block incoming Remit txn._Added by the \[Remit amendment]\[]._ |
|
||||
| `asfDisallowXRP` | 3 | `lsfDisallowXRP` | XAH should not be sent to this account. (Advisory; not enforced by Xahau protocol.) |
|
||||
| `asfGlobalFreeze` | 7 | `lsfGlobalFreeze` | Freeze all assets issued by this account. |
|
||||
| `asfNoFreeze` | 6 | `lsfNoFreeze` | Permanently give up the ability to freeze individual trust lines or disable Global Freeze. This flag can never be disabled after being enabled. |
|
||||
| `asfRequireAuth` | 2 | `lsfRequireAuth` | Require authorization for users to hold balances issued by this address. Can only be enabled if the address has no trust lines connected to it. |
|
||||
| `asfRequireDest` | 1 | `lsfRequireDestTag` | Require a destination tag to send transactions to this account. |
|
||||
| `asfTshCollect` | 11 | `lsfTshCollect` | The TSH pays for the execution of their own Hook Chain. _Added by the \[Hooks amendment]\[]._ |
|
||||
|
||||
To enable the `asfDisableMaster` or `asfNoFreeze` flags, you must authorize the transaction by signing it with the master key pair. You cannot use a regular key pair or a multi-signature. You can disable `asfDisableMaster` (that is, re-enable the master key pair) using a regular key pair or multi-signature.
|
||||
|
||||
The following Transaction flags (`tf` flags), specific to the AccountSet transaction type, serve the same purpose. Due to limited space, some settings do not have associated `tf` flags, and new `tf` flags are not being added to the `AccountSet` transaction type. You can use a combination of `tf` and `asf` flags to enable multiple settings with a single transaction.
|
||||
|
||||
<table><thead><tr><th>Flag Name</th><th>Hex Value</th><th width="183">Decimal Value</th><th>Replaced by AccountSet Flag</th></tr></thead><tbody><tr><td><code>tfRequireDestTag</code></td><td><code>0x00010000</code></td><td>65536</td><td><code>asfRequireDest</code> (<code>SetFlag</code>)</td></tr><tr><td><code>tfOptionalDestTag</code></td><td><code>0x00020000</code></td><td>131072</td><td><code>asfRequireDest</code> (<code>ClearFlag</code>)</td></tr><tr><td><code>tfRequireAuth</code></td><td><code>0x00040000</code></td><td>262144</td><td><code>asfRequireAuth</code> (<code>SetFlag</code>)</td></tr><tr><td><code>tfOptionalAuth</code></td><td><code>0x00080000</code></td><td>524288</td><td><code>asfRequireAuth</code> (<code>ClearFlag</code>)</td></tr><tr><td><code>tfDisallowXRP</code></td><td><code>0x00100000</code></td><td>1048576</td><td><code>asfDisallowXRP</code> (<code>SetFlag</code>)</td></tr><tr><td><code>tfAllowXRP</code></td><td><code>0x00200000</code></td><td>2097152</td><td><code>asfDisallowXRP</code> (<code>ClearFlag</code>)</td></tr></tbody></table>
|
||||
|
||||
**Caution:** The numeric values of `tf` and `asf` flags in transactions do not match up with the values they set in the accounts "at rest" in the ledger. To read the flags of an account in the ledger, see `AccountRoot` flags.
|
||||
|
||||
#### Blocking Incoming Transactions
|
||||
|
||||
Incoming transactions with unclear purposes may be an inconvenience for financial institutions, who would have to recognize when a customer made a mistake, and then potentially refund accounts or adjust balances depending on the mistake. The `asfRequireDest` and `asfDisallowXRP` flags are intended to protect users from accidentally sending funds in a way that is unclear about the reason the funds were sent.
|
||||
|
||||
For example, a destination tag is typically used to identify which hosted balance should be credited when a financial institution 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, you can ensure that every incoming payment has a destination tag, which makes it harder for others to send you an ambiguous payment by accident.
|
||||
|
||||
You can protect against unwanted incoming payments for non-XAH currencies by not creating trust lines in those currencies. Since XAH does not require trust, the `asfDisallowXRP` flag is used to discourage users from sending XAH to an account. However, this flag is not enforced in Xahau protocol because it could potentially cause accounts to become unusable if they run out of XAH. Instead, client applications should disallow or discourage XAH payments to accounts with the `asfDisallowXRP` flag enabled.
|
||||
|
||||
If you want to block _all_ incoming payments, you can enable Deposit Authorization. This prevents any transaction from sending money to you, even XAH, unless your account is below the reserve requirement.
|
||||
|
||||
If the \[DisallowIncoming amendment]\[] :not_enabled: is enabled, you also have the option to block all incoming Checks, NFTokenOffers, Payment Channels, and trust lines. It is generally harmless to be on the receiving end of these objects, but they can block you from deleting your account and it can be confusing to have objects you didn't expect mixed in with the list of objects you created. To block incoming objects, use one or more of these account flags:
|
||||
|
||||
* `asfDisallowIncomingCheck` - for Check objects
|
||||
* `asfDisallowIncomingNFTOffer` - for NFTokenOffer objects
|
||||
* `asfDisallowIncomingPayChan` - for PayChannel objects
|
||||
* `asfDisallowIncomingTrustline` - for RippleState (trust line) objects
|
||||
|
||||
When a transaction would create one of these ledger entries, if the destination account has the corresponding flag enabled, the transaction fails with the result code `tecNO_PERMISSION`. Unlike Deposit Authorization, these settings do not prevent you from receiving payments in general. Also, enabling this setting doesn't stop you from creating these types of objects yourself (unless the destination of your transaction is also using the setting, of course).
|
||||
|
||||
### TransferRate
|
||||
|
||||
The `TransferRate` field specifies a fee to charge whenever counterparties transfer the currency you issue.
|
||||
|
||||
In the HTTP and WebSocket APIs, the transfer fee is represented as an integer, the amount that must be sent for 1 billion units to arrive. For example, a 20% transfer fee is represented as the value `1200000000`. The value cannot be less than 1000000000. (Less than that would indicate giving away money for sending transactions, which is exploitable.) You can specify `0` as a shortcut for `1000000000`, meaning no fee.
|
||||
|
||||
See Transfer Fees for more information.
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
title: CheckCancel
|
||||
description: >-
|
||||
Cancels an unredeemed Check, removing it from the ledger without sending any
|
||||
money. The source or the destination of the check can cancel a Check at any
|
||||
time using this transaction type.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_(Added by the \[Checks amendment]\[].)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"TransactionType": "CheckCancel",
|
||||
"CheckID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
|
||||
"Fee": "12"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------- | --------- | ------------------- | ---------------------------------------------------------------------------------- |
|
||||
| `CheckID` | String | Hash256 | The ID of the Check ledger object to cancel, as a 64-character hexadecimal string. |
|
||||
|
||||
### Error Cases
|
||||
|
||||
* If the object identified by the `CheckID` does not exist or is not a Check, the transaction fails with the result `tecNO_ENTRY`.
|
||||
* If the Check is not expired and the sender of the CheckCancel transaction is not the source or destination of the Check, the transaction fails with the result `tecNO_PERMISSION`.
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: CheckCash
|
||||
description: >-
|
||||
Attempts to redeem a Check object in the ledger to receive up to the amount
|
||||
authorized by the corresponding CheckCreate transaction.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_(Added by the \[Checks amendment]\[].)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
|
||||
"TransactionType": "CheckCash",
|
||||
"Amount": "100000000",
|
||||
"CheckID": "838766BA2B995C00744175F69A1B11E32C3DBC40E64801A4056FCBD657F57334",
|
||||
"Fee": "12"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `CheckID` | String | Hash256 | The ID of the Check ledger object to cash, as a 64-character hexadecimal string. |
|
||||
| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Optional)_ Redeem the Check for exactly this amount, if possible. The currency must match that of the `SendMax` of the corresponding CheckCreate transaction. You must provide either this field or `DeliverMin`. |
|
||||
| `DeliverMin` | \[Currency Amount]\[] | Amount | _(Optional)_ Redeem the Check for at least this amount and for as much as possible. The currency must match that of the `SendMax` of the corresponding CheckCreate transaction. You must provide either this field or `Amount`. |
|
||||
|
||||
The transaction _**must**_ include either `Amount` or `DeliverMin`, but not both.
|
||||
|
||||
### Error Cases
|
||||
|
||||
* If the sender of the CheckCash transaction is not the `Destination` of the check, the transaction fails with the result code `tecNO_PERMISSION`.
|
||||
* If the Check identified by the `CheckID` field does not exist, the transaction fails with the result `tecNO_ENTRY`.
|
||||
* If the Check identified by the `CheckID` field has already expired, the transaction fails with the result `tecEXPIRED`.
|
||||
* If the destination of the Check has the `RequireDest` flag enabled but the Check, as created, does not have a destination tag, the transaction fails with the result code `tecDST_TAG_NEEDED`.
|
||||
* If the transaction specifies both `Amount` and `DeliverMin`, or omits both, the transaction fails with the result `temMALFORMED`.
|
||||
* If the `Amount` or `DeliverMin` does not match the currency (and issuer, if not XAH) of the Check, the transaction fails with the result `temBAD_CURRENCY`.
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: CheckCreate
|
||||
description: >-
|
||||
Create a Check object in the ledger, which is a deferred payment that can be
|
||||
cashed by its intended destination. The sender of this transaction is the
|
||||
sender of the Check.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_(Added by the \[Checks amendment]\[].)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "CheckCreate",
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"Destination": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
|
||||
"SendMax": "100000000",
|
||||
"Expiration": 570113521,
|
||||
"InvoiceID": "6F1DFD1D0FE8A32E40E1F2C05CF1C15545BAB56B617F9C6C2D63A6B704BEF59B",
|
||||
"DestinationTag": 1,
|
||||
"Fee": "12"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Destination` | String | AccountID | The unique address of the account that can cash the Check. |
|
||||
| `SendMax` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Maximum amount of source currency the Check is allowed to debit the sender, including transfer fees on non-XAH currencies. The Check can only credit the destination with the same currency (from the same issuer, for non-XAH currencies). For non-XAH amounts, the nested field names MUST be lower-case. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the Check, or a hosted recipient to pay. |
|
||||
| `Expiration` | Number | UInt32 | _(Optional)_ Time after which the Check is no longer valid, in \[seconds since the Ripple Epoch]\[]. |
|
||||
| `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this Check. |
|
||||
|
||||
### Error Cases
|
||||
|
||||
* If the `Destination` account is blocking incoming Checks, the transaction fails with the result code `tecNO_PERMISSION`. 
|
||||
* If the `Destination` is the sender of the transaction, the transaction fails with the result code `temREDUNDANT`.
|
||||
* If the `Destination` account does not exist in the ledger, the transaction fails with the result code `tecNO_DST`.
|
||||
* If the `Destination` account has the `RequireDest` flag enabled but the transaction does not include a `DestinationTag` field, the transaction fails with the result code `tecDST_TAG_NEEDED`.
|
||||
* If `SendMax` specifies a token which is frozen, the transaction fails with the result `tecFROZEN`.
|
||||
* If the `Expiration` of the transaction is in the past, the transaction fails with the result `tecEXPIRED`.
|
||||
* If the sender does not have enough XAH to meet the owner reserve after adding the Check, the transaction fails with the result `tecINSUFFICIENT_RESERVE`.
|
||||
* If either the sender or the destination of the Check cannot own more objects in the ledger, the transaction fails with the result `tecDIR_FULL`.
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
title: ClaimReward
|
||||
description: >-
|
||||
A ClaimReward transaction allows an account to claim the rewards it has
|
||||
accumulated. The rewards can be claimed by the account owner or by a specified
|
||||
issuer. The account can also opt-out of rewards.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/ClaimReward.cpp)]
|
||||
|
||||
_(Added by the \[BalanceRewards amendment]\[].)_
|
||||
|
||||
### Opt-in + Claim
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "ClaimReward",
|
||||
"Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
|
||||
"Issuer": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"
|
||||
}
|
||||
```
|
||||
|
||||
### Opt-out
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "ClaimReward",
|
||||
"Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
|
||||
"Flags": 1
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------- | --------- | ------------------- | ------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | The address of the account that is claiming the reward. |
|
||||
| `Flags` | Number | UInt32 | _(Optional)_ Can have flag 1 set to opt-out of rewards. |
|
||||
| `Issuer` | String | AccountID | _(Optional)_ The genesis account. |
|
||||
|
||||
### ClaimReward Flags
|
||||
|
||||
Transactions of the ClaimReward type support additional values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| ---------- | ------------ | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `tfOptOut` | `0x00000001` | 1 | The `isOptOut` flag in the ClaimReward code is used to opt-out an account from rewards by removing reward-related fields from the account object in the ledger if the `sfFlags` field in the transaction is set to 1. |
|
||||
|
||||
### Special Transaction Cost
|
||||
|
||||
The ClaimReward transaction has a standard transaction cost, which is the minimum transaction cost required for all transactions.
|
||||
|
||||
### Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, ClaimReward transactions can result in the following transaction result codes:
|
||||
|
||||
| Error Code | Description |
|
||||
| ----------------- | ------------------------------------------------------------------------------------------------------- |
|
||||
| `temDISABLED` | Occurs if the feature is not enabled. |
|
||||
| `temINVALID_FLAG` | Occurs if the flag is set to a value other than 1. |
|
||||
| `temMALFORMED` | Occurs if the issuer is the same as the source account or if the flag and issuer are not correctly set. |
|
||||
| `tecNO_ISSUER` | Occurs if the issuer does not exist. |
|
||||
| `terNO_ACCOUNT` | Occurs if the sending account does not exist. |
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
title: Clawback
|
||||
description: >-
|
||||
Revoke tokens that were previously issued by your account.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/Clawback.cpp)]
|
||||
|
||||
_(Added by the \[Clawback amendment]\[].)_
|
||||
|
||||
Revoke tokens that were previously issued by your account. The **Clawback** feature is disabled by default. To use it, you must first submit an **AccountSet** transaction that enables *Allow Trust Line Clawback*. If your account has already issued tokens, you cannot enable Clawback afterward. You can only activate *Allow Trust Line Clawback* if your owner directory is completely empty — meaning before creating trust lines, offers, escrows, payment channels, checks, or signer lists. Once enabled, Clawback becomes a permanent capability of your account and cannot be undone.
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Clawback",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rfkE1aSy9G8Upk4JssnwBxhEv5p4mn2KTy",
|
||||
"value": "123.45"
|
||||
}
|
||||
}
|
||||
````
|
||||
|
||||
---
|
||||
|
||||
### Fields
|
||||
|
||||
A **Clawback** transaction includes:
|
||||
|
||||
| Field | JSON Type | Description |
|
||||
| -------- | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Amount` | *Currency Amount* | The quantity to be revoked, as well as the counterparty from which it is taken. The `value` must not be zero. If greater than the holder’s balance, the entire balance is revoked. In the `issuer` sub-field, specify the holder’s address (not the issuer’s). |
|
||||
|
||||
In Xahau, an IOU/Non-XAH token on a trust line always has an issuer, but trust lines are bidirectional and under certain settings both sides may act as issuers. In this transaction, the issuer’s address goes in the `Account` field, while the holder’s address goes in the `issuer` sub-field of `Amount`.
|
||||
|
||||
---
|
||||
|
||||
## Error Cases
|
||||
|
||||
Besides the standard transaction errors, Clawback may fail with:
|
||||
|
||||
| Error Code | Description |
|
||||
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `temDISABLED` | The **Clawback** amendment is not enabled on Xahau. |
|
||||
| `temBAD_AMOUNT` | The holder’s balance is zero. (It is not an error if the specified amount exceeds the holder’s balance — in that case, the full available balance is revoked). Also occurs if the counterparty in `Amount` is the same account submitting the transaction. |
|
||||
| `tecNO_LINE` | No trust line exists with the specified counterparty, or the trust line has a balance of zero. |
|
||||
| `tecNO_PERMISSION` | Happens if you try to enable `lsfAllowTrustLineClawback` while `lsfNoFreeze` is already enabled, or vice versa. |
|
||||
|
||||
@@ -1,101 +0,0 @@
|
||||
---
|
||||
title: CronSet
|
||||
description: >-
|
||||
A CronSet transaction enables Hooks to schedule recurring self-invocations at
|
||||
regular intervals, similar to Linux cronjobs. This facilitates complex
|
||||
governance structures and automated processes within Hook frameworks.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/CronSet.cpp)]
|
||||
|
||||
_(Added by the CronSet amendment.)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "CronSet",
|
||||
"Account": "rYourAccountAddress",
|
||||
"StartTime": 816348759,
|
||||
"RepeatCount": 3,
|
||||
"DelaySeconds": 120
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| -------------- | --------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | The Hook account initiating the cron. This is the account that will be invoked when the cron executes. |
|
||||
| `StartTime` | Number | UInt32 | _(Optional)_ Ripple Epoch timestamp when the first execution should occur. Use `0` for immediate execution. If omitted when deleting a cron, the transaction removes the cron. |
|
||||
| `RepeatCount` | Number | UInt32 | _(Optional)_ Number of times the cron should execute (maximum 256 per transaction). Can be extended via subsequent CronSet transactions. Omit when deleting a cron. |
|
||||
| `DelaySeconds` | Number | UInt32 | _(Optional)_ Time interval in seconds between each execution. Omit when deleting a cron. |
|
||||
|
||||
### How CronSet Works
|
||||
|
||||
CronSet transactions enable scheduled, automated Hook execution on the Xahau blockchain at regular intervals, eliminating the need for external services or manual triggers.
|
||||
|
||||
The workflow involves four key steps:
|
||||
|
||||
1. Install a Hook with the `hsfCOLLECT` flag enabled
|
||||
2. Enable Transaction Signature Hook Collection `asfTshCollect` on your account (SetFlag: 11)
|
||||
3. Create a CronSet transaction with scheduling parameters
|
||||
4. Let Xahau handle automatic execution
|
||||
|
||||
### Execution Mechanism
|
||||
|
||||
When a cron is ready to execute, the Cron engine inserts a pseudo-transaction of type `Cron` into the ledger, containing an `Owner` field referencing the originating Hook account. Hook developers must enable collect calls, as the Owner constitutes a weak transactional stakeholder.
|
||||
|
||||
The scheduled Hook will be invoked automatically at the specified intervals without requiring external triggers.
|
||||
|
||||
### Time Format
|
||||
|
||||
Xahau uses Ripple Epoch time (seconds since January 1, 2000), not Unix time. To convert from JavaScript Date:
|
||||
|
||||
```javascript
|
||||
const rippleEpochTime = Math.floor(Date.now() / 1000) - 946684800;
|
||||
```
|
||||
|
||||
### Deleting a Cron
|
||||
|
||||
To remove an existing Cron, omit `StartTime`, `RepeatCount`, and `DelaySeconds` while setting `Flags: 1` (tfCronUnset):
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "CronSet",
|
||||
"Account": "rYourAccountAddress",
|
||||
"Flags": 1
|
||||
}
|
||||
```
|
||||
|
||||
### Extending Repeat Count
|
||||
|
||||
Upon reaching a minimum threshold, a subsequent CronSet transaction can extend the repeat count beyond the initial 256 execution limit by submitting a new CronSet transaction with an updated `RepeatCount`.
|
||||
|
||||
### CronSet Flags
|
||||
|
||||
Transactions of the CronSet type support additional values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| ------------- | ------------ | ------------- | -------------------------------------------------------------------------------- |
|
||||
| `tfCronUnset` | `0x00000001` | 1 | Removes an existing Cron. All scheduling fields must be omitted when this is set. |
|
||||
|
||||
### Limitations and Constraints
|
||||
|
||||
- CronSet cannot currently be delegated to another account
|
||||
- Hooks must self-emit CronSet transactions or operate under joint management arrangements
|
||||
- `RepeatCount`: Must be greater than 0 and cannot exceed 256 per transaction (extendable via subsequent transactions)
|
||||
- `DelaySeconds`: Maximum of 31,536,000 seconds (365 days)
|
||||
- `StartTime`: Must be current time or future; cannot exceed 365 days ahead
|
||||
- Cannot combine `tfCronUnset` flag with `DelaySeconds`, `RepeatCount`, or `StartTime` fields
|
||||
- When creating a cron, `DelaySeconds` and `RepeatCount` must both exist or both be absent
|
||||
|
||||
### Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, CronSet transactions can result in the following transaction result codes:
|
||||
|
||||
| Error Code | Description |
|
||||
| ------------------ | -------------------------------------------------------------------------------------------------- |
|
||||
| `temDISABLED` | Occurs if the Cron feature is not enabled. |
|
||||
| `temINVALID_FLAG` | Occurs if invalid flags are set in the transaction. |
|
||||
| `temMALFORMED` | Occurs if the transaction is malformed with invalid field combinations. |
|
||||
| `tecEXPIRED` | Occurs if `StartTime` is in the past or more than 365 days in the future. |
|
||||
| `tefINTERNAL` | Occurs if the account ledger entry is missing. |
|
||||
| `tefBAD_LEDGER` | Occurs if the Cron object is missing, points to a non-cron entry, or owner directory removal fails. |
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: DepositPreauth
|
||||
description: >-
|
||||
A DepositPreauth transaction gives another account pre-approval to deliver
|
||||
payments to the sender of this transaction.
|
||||
---
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
|
||||
<Aside type="tip">
|
||||
You can use this transaction to preauthorize certain counterparties before you enable Deposit Authorization. This may be useful to ensure a smooth transition from not requiring deposit authorization to requiring it.
|
||||
</Aside>
|
||||
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_Added by the \[DepositPreauth amendment]\[]._
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType" : "DepositPreauth",
|
||||
"Account" : "rsUiUMpnrgxQp24dJYZDhmV4bE3aBtQyt8",
|
||||
"Authorize" : "rEhxGqkqPPSxQ3P25J66ft5TwpzV14k2de",
|
||||
"Fee" : "10",
|
||||
"Flags" : 2147483648,
|
||||
"Sequence" : 2
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ------------- | --------- | ------------------- | -------------------------------------------------------------------------------- |
|
||||
| `Authorize` | String | AccountID | _(Optional)_ Xahau address of the sender to preauthorize. |
|
||||
| `Unauthorize` | String | AccountID | _(Optional)_ Xahau address of a sender whose preauthorization should be revoked. |
|
||||
|
||||
You must provide _either_ `Authorize` or `Unauthorize`, but not both.
|
||||
|
||||
### Error Cases
|
||||
|
||||
* An account cannot preauthorize (or unauthorize) its own address. Attempting to do so fails with the result `temCANNOT_PREAUTH_SELF`.
|
||||
* Attempting to preauthorize an account which is already preauthorized fails with the result `tecDUPLICATE`.
|
||||
* Attempting to unauthorize an account which is not preauthorized fails with the result `tecNO_ENTRY`.
|
||||
* Attempting to preauthorize an address that is not funded in the ledger fails with the result `tecNO_TARGET`.
|
||||
* Adding authorization adds a DepositPreauth object to the ledger, which counts toward the owner reserve requirement. If the sender of the transaction does not have enough XAH to pay for the increased reserve, the transaction fails with the result `tecINSUFFICIENT_RESERVE`. If the sender of the account is already at the maximum number of owned objects, the transaction fails with the result `tecDIR_FULL`.
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
title: EscrowCancel
|
||||
description: Return escrowed XAH or IOU to the sender.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_Added by the \[Escrow amendment]\[]._
|
||||
|
||||
### Cancel Using OfferSequence
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"TransactionType": "EscrowCancel",
|
||||
"Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"OfferSequence": 7,
|
||||
}
|
||||
```
|
||||
|
||||
### Cancel Using EscrowID
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"TransactionType": "EscrowCancel",
|
||||
"Owner": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"EscrowID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------------- | --------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Owner` | String | AccountID | Address of the source account that funded the escrow payment. |
|
||||
| `OfferSequence` | Number | UInt32 | _(Optional)_ Transaction sequence (or Ticket number) of \[EscrowCreate transaction]\[] that created the escrow to cancel. |
|
||||
| `EscrowID` | String | Hash256 | _(Optional)_ The ID of the Escrow ledger object to cancel, as a 64-character hexadecimal string. |
|
||||
|
||||
Any account may submit an EscrowCancel transaction.
|
||||
|
||||
* If the corresponding \[EscrowCreate transaction]\[] did not specify a `CancelAfter` time, the EscrowCancel transaction fails.
|
||||
* Otherwise the EscrowCancel transaction fails if the `CancelAfter` time is after the close time of the most recently-closed ledger.
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: EscrowCreate
|
||||
description: Sequester XAH or IOU until the escrow process either finishes or is canceled.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_Added by the \[Escrow amendment]\[]._
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"TransactionType": "EscrowCreate",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Destination": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"CancelAfter": 533257958,
|
||||
"FinishAfter": 533171558,
|
||||
"Condition": "A0258020E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855810100",
|
||||
"DestinationTag": 23480,
|
||||
"SourceTag": 11747
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Amount to deduct from the sender's balance and escrow. Once escrowed, the Amount can either go to the `Destination` address (after the `FinishAfter` time) or returned to the sender (after the `CancelAfter` time). |
|
||||
| `Destination` | String | AccountID | Address to receive escrowed Amount. |
|
||||
| `CancelAfter` | Number | UInt32 | _(Optional)_ The time, in \[seconds since the Ripple Epoch]\[], when this escrow expires. This value is immutable; the funds can only be returned to the sender after this time. |
|
||||
| `FinishAfter` | Number | UInt32 | _(Optional)_ The time, in \[seconds since the Ripple Epoch]\[], when the escrowed Amount can be released to the recipient. This value is immutable; the funds cannot move until this time is reached. |
|
||||
| `Condition` | String | Blob | _(Optional)_ Hex value representing a [PREIMAGE-SHA-256 crypto-condition](https://tools.ietf.org/html/draft-thomas-crypto-conditions-02#section-8.1). The funds can only be delivered to the recipient if this condition is fulfilled. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag to further specify the destination for this escrowed payment, such as a hosted recipient at the destination address. |
|
||||
|
||||
Either `CancelAfter` or `FinishAfter` must be specified. If both are included, the `FinishAfter` time must be before the `CancelAfter` time.
|
||||
|
||||
With the \[fix1571 amendment]\[] enabled, you must supply `FinishAfter`, `Condition`, or both. \[New in: rippled 1.0.0]\[]
|
||||
|
||||
@@ -1,57 +0,0 @@
|
||||
---
|
||||
title: GenesisMint - (Emitted Txn)
|
||||
description: >-
|
||||
The GenesisMint transaction is used to mint new XAH and distribute it to
|
||||
multiple accounts. This transaction can only be used by the genesis account.
|
||||
---
|
||||
\[[Source](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/GenesisMint.cpp)]
|
||||
|
||||
_Added by the \[XahauGenesis amendment]\[] and the \[Hooks amendment]\[]_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "GenesisMint",
|
||||
"Account": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"GenesisMints": [
|
||||
{
|
||||
"GenesisMint": {
|
||||
"Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
|
||||
"Amount": "1000000000"
|
||||
},
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | Internal Type | Description |
|
||||
| -------------- | --------- | ------------- | -------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | The address of the genesis account that will mint and distribute XAH. |
|
||||
| `GenesisMints` | Array | Array | An array of objects representing the destinations and amounts of the minted XAH. |
|
||||
|
||||
### GenesisMint Object
|
||||
|
||||
The GenesisMint transaction includes an array of objects called `GenesisMints`. Each object represents a destination account and the amount of XAH to be minted and distributed to that account.
|
||||
|
||||
| Field | JSON Type | Internal Type | Description |
|
||||
| ----------------- | --------- | ------------- | -------------------------------------------------------------------------- |
|
||||
| `Destination` | String | AccountID | The address of the account that will receive the minted XAH. |
|
||||
| `Amount` | String | Amount | The amount of XAH to be minted and distributed to the destination account. |
|
||||
| `GovernanceFlags` | String | Hash256 | _(Optional)_ The governance flags associated with the destination account. |
|
||||
| `GovernanceMarks` | String | Hash256 | _(Optional)_ The governance marks associated with the destination account. |
|
||||
|
||||
### Special Transaction Cost
|
||||
|
||||
The GenesisMint transaction has a standard transaction cost, which is the minimum transaction cost required for all transactions.
|
||||
|
||||
### Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, the GenesisMint transaction can result in the following transaction result codes:
|
||||
|
||||
| Error Code | Description |
|
||||
| -------------- | ------------------------------------------------------------------------------------------ |
|
||||
| `temDISABLED` | Occurs if the "Hooks" or "XahauGenesis" amendments are not enabled. |
|
||||
| `temMALFORMED` | Occurs if the transaction is malformed, such as missing required fields or invalid values. |
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: Import
|
||||
description: >-
|
||||
Import is a new transaction which accepts an XPOP from the XRPL Mainnet chain
|
||||
(network_id=0) or Testnet (network_id=1) and provides account synchronisation.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
_(Added by the \[Import amendment]\[].)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Import",
|
||||
"Sequence": 0,
|
||||
"Fee": "0",
|
||||
"Account": "rUn84CUYbNjRoTQ6mSW7BVJPSVJNLb1QLo",
|
||||
"Blob" : "DEADBEEF"
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ------------- | --------- | ------------------- | ---------------------------------------------------- |
|
||||
| `Blob` | String | Blob | Hex value representing an XPOP |
|
||||
| `Issuer` | String | AccountID | (Optional) Address that can be used inside the Hook. |
|
||||
| `Destination` | String | AccountID | (Optional) Address that can be used inside the Hook. |
|
||||
|
||||
### Error Cases
|
||||
|
||||
* If the account is Non Activated then the `Sequence` must be 0 and the `Fee` must also be 0
|
||||
* If the account is Activated then the `Sequence` and the `Fee` are calculated using the standard method.
|
||||
* If the `Issuer` field is present then the `Fee` must be calculated using the standard method.
|
||||
|
||||
### Notes
|
||||
|
||||
_It is recommended that if you use a `SignerList` or `RegularKey` to sign your transactions that you key your accounts **FIRST** before attempting to _B2M_ XAH_ .
|
||||
|
||||
* If the inner (xpop) transaction is `AccountSet` the mainet existing flags will be transfered to the new network.
|
||||
* If the inner (xpop) transaction is `SetRegularKey` with the `RegularKey` field omitted or empty, and a signers list does not exist for the account then the `lsfDisableMaster` flag will be set on the account.
|
||||
* If the inner (xpop) transaction is `SetRegularKey` then the `lsfPasswordSpent` flag will be set on the account.
|
||||
* TicketSequence is not available on `Import`
|
||||
|
||||
### Importing for the Issuer
|
||||
|
||||
For issuers, there are additional steps to follow before their asset holders can import transactions.
|
||||
|
||||
Firstly, issuers need to install a hook. There are two options for this: `B2MNFToken` or `B2MPayment`.
|
||||
|
||||
#### B2MNFToken
|
||||
|
||||
A `NFTokenBurn` transaction on mainnet will result in a `URITokenMint` transaction on the network.
|
||||
|
||||
> c hook: https://example.com
|
||||
|
||||
#### B2MPayment
|
||||
|
||||
A `Payment` transaction on mainnet to the Issuer will result in a `Payment` transaction from the Issuer on the network.
|
||||
|
||||
> c hook: https://example.com
|
||||
|
||||
_Please note that the process of importing for the issuer involves specific transaction types and requires careful configuration. Always ensure that the hooks are correctly set up and that the transactions are valid for the intended operations._
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: Invoke
|
||||
description: >-
|
||||
An Invoke transaction is used to call a hook, which is a piece of code that is
|
||||
executed in response to certain ledger operations.
|
||||
---
|
||||
\[[Source](https://github.com/ripple/rippled/blob/develop/src/ripple/app/tx/impl/Invoke.cpp)]
|
||||
|
||||
_(Added by the [Hooks amendment][].)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Invoke",
|
||||
"Account": "rWYkbWkCeg8dP6rXALnjgZSjjLyih5NXm",
|
||||
"Blob": "697066733A2F2F4445414442454546",
|
||||
"Destination": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Required? | Description |
|
||||
| ---------------- | --------- | ------------------- | --------- | -------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | Yes | The address of the account that is invoking the hook. |
|
||||
| `Blob` | String | Blob | No | A blob of data that is passed to the hook. (128k byte max) |
|
||||
| `Destination` | String | AccountID | No | The address of the account that is the target of the hook. |
|
||||
|
||||
### Special Transaction Cost
|
||||
|
||||
The Invoke transaction has a standard transaction cost, plus an additional cost based on the size of the Blob field.
|
||||
|
||||
### Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, Invoke transactions can result in the following transaction result codes:
|
||||
|
||||
| Error Code | Description |
|
||||
| --------------- | ------------------------------------------------------------------------ |
|
||||
| `temDISABLED` | Occurs if the Hooks amendment is not enabled. |
|
||||
| `temMALFORMED` | Occurs if the Blob field is larger than 128k bytes. |
|
||||
| `terNO_ACCOUNT` | Occurs if the sending account or the destination account does not exist. |
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: OfferCancel
|
||||
description: An OfferCancel transaction removes an Offer object from Xahau.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
### Cancel with OfferSequence
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "OfferCancel",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108629,
|
||||
"OfferSequence": 6,
|
||||
"Sequence": 7
|
||||
}
|
||||
```
|
||||
|
||||
### Cancel with OfferID
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "OfferCancel",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108629,
|
||||
"OfferID": "49647F0D748DC3FE26BDACBC57F251AADEFFF391403EC9BF87C97F67E9977FB0",
|
||||
"Sequence": 7
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------------- | --------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `OfferSequence` | Number | UInt32 | _(Optional)_ The sequence number (or Ticket number) of a previous OfferCreate transaction. If specified, cancel any offer object in the ledger that was created by that transaction. It is not considered an error if the offer specified does not exist. |
|
||||
| `OfferID` | String | Hash256 | _(Optional)_ The ID of the Offer ledger object to cancel, as a 64-character hexadecimal string. |
|
||||
|
||||
_Tip:_ To remove an old offer and replace it with a new one, you can use an \[OfferCreate transaction]\[] with an `OfferSequence` parameter, instead of using OfferCancel and another OfferCreate.
|
||||
|
||||
The OfferCancel method returns `tesSUCCESS` even if it did not find an offer with the matching sequence number.
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
title: OfferCreate
|
||||
description: >-
|
||||
An OfferCreate transaction places an Offer in the
|
||||
decentralized exchange.
|
||||
---
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/URIToken.cpp)]
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "OfferCreate",
|
||||
"Account": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "12",
|
||||
"Flags": 0,
|
||||
"LastLedgerSequence": 7108682,
|
||||
"Sequence": 8,
|
||||
"TakerGets": "6000000",
|
||||
"TakerPays": {
|
||||
"currency": "GKO",
|
||||
"issuer": "ruazs5h1qEsqpke88pcqnaseXdm6od2xc",
|
||||
"value": "2"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------- |
|
||||
| `Expiration` | Number | UInt32 | _(Optional)_ Time after which the Offer is no longer active, in \[seconds since the Ripple Epoch]\[]. |
|
||||
| `OfferSequence` | Number | UInt32 | _(Optional)_ An Offer to delete first, specified in the same way as \[OfferCancel]\[]. |
|
||||
| `OfferID` | String | Hash256 | _(Optional)_ The ID of the Offer ledger object to cancel, as a 64-character hexadecimal string. |
|
||||
| `TakerGets` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | The amount and type of currency being sold. |
|
||||
| `TakerPays` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | The amount and type of currency being bought. |
|
||||
|
||||
### OfferCreate Flags
|
||||
|
||||
Transactions of the OfferCreate type support additional values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| --------------------- | ------------ | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `tfPassive` | `0x00010000` | 65536 | If enabled, the Offer does not consume Offers that exactly match it, and instead becomes an Offer object in the ledger. It still consumes Offers that cross it. |
|
||||
| `tfImmediateOrCancel` | `0x00020000` | 131072 | Treat the Offer as an [Immediate or Cancel order](http://en.wikipedia.org/wiki/Immediate_or_cancel). The Offer never creates an \[Offer object]\[] in the ledger: it only trades as much as it can by consuming existing Offers at the time the transaction is processed. If no Offers match, it executes "successfully" without trading anything. In this case, the transaction still uses the result code `tesSUCCESS`. |
|
||||
| `tfFillOrKill` | `0x00040000` | 262144 | Treat the offer as a [Fill or Kill order](http://en.wikipedia.org/wiki/Fill_or_kill). The Offer never creates an \[Offer object]\[] in the ledger, and is canceled if it cannot be fully filled at the time of execution. By default, this means that the owner must receive the full `TakerPays` amount; if the `tfSell` flag is enabled, the owner must be able to spend the entire `TakerGets` amount instead. |
|
||||
| `tfSell` | `0x00080000` | 524288 | Exchange the entire `TakerGets` amount, even if it means obtaining more than the `TakerPays` amount in exchange. |
|
||||
|
||||
### Error Cases
|
||||
|
||||
| Error Code | Description |
|
||||
| ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `temINVALID_FLAG` | Occurs if the transaction specifies both `tfImmediateOrCancel` and `tfFillOrKill`. |
|
||||
| `tecEXPIRED` | Occurs if the transaction specifies an `Expiration` time that has already passed. |
|
||||
| `tecKILLED` | Occurs if the transaction specifies `tfFillOrKill`, and the full amount cannot be filled. If the _\[ImmediateOfferKilled amendment]\[]_ is enabled, this result code also occurs when the transaction specifies `tfImmediateOrCancel` and executes without moving funds (previously, this would return `tesSUCCESS`). |
|
||||
| `temBAD_EXPIRATION` | Occurs if the transaction contains an `Expiration` field that is not validly formatted. |
|
||||
| `temBAD_SEQUENCE` | Occurs if the transaction contains an `OfferSequence` that is not validly formatted, or is higher than the transaction's own `Sequence` number. |
|
||||
| `temBAD_OFFER` | Occurs if the Offer tries to trade XAH for XAH, or tries to trade an invalid or negative amount of a token. |
|
||||
| `temREDUNDANT` | Occurs if the transaction specifies a token for the same token (same issuer and currency code). |
|
||||
| `temBAD_CURRENCY` | Occurs if the transaction specifies a token with the currency code "XAH". |
|
||||
| `temBAD_ISSUER` | Occurs if the transaction specifies a token with an invalid `issuer` value. |
|
||||
| `tecNO_ISSUER` | Occurs if the transaction specifies a token whose `issuer` value is not a funded account in the ledger. |
|
||||
| `tecFROZEN` | Occurs if the transaction involves a token on a frozen trust line (including local and global freezes). |
|
||||
| `tecUNFUNDED_OFFER` | Occurs if the owner does not hold a positive amount of the `TakerGets` currency. (Exception: if `TakerGets` specifies a token that the owner issues, the transaction can succeed.) |
|
||||
| `tecNO_LINE` | Occurs if the transaction involves a token whose issuer uses Authorized Trust Lines and the necessary trust line does not exist. |
|
||||
| `tecNO_AUTH` | Occurs if the transaction involves a token whose issuer uses Authorized Trust Lines and the the trust line that would receive the tokens exists but has not been authorized. |
|
||||
| `tecINSUF_RESERVE_OFFER` | Occurs if the owner does not have enough XAH to meet the reserve requirement of adding a new Offer object to the ledger, and the transaction did not convert any currency. (If the transaction successfully traded any amount, the transaction succeeds with the result code `tesSUCCESS`, but does not create an Offer object in the ledger for the rest.) |
|
||||
| `tecDIR_FULL` | Occurs if the owner owns too many items in the ledger, or the order book contains too many Offers at the same exchange rate already. |
|
||||
@@ -1,113 +0,0 @@
|
||||
---
|
||||
title: Payment
|
||||
description: >-
|
||||
A Payment transaction represents a transfer of value from one account to
|
||||
another. (Depending on the path taken, this can involve additional exchanges
|
||||
of value, which occur atomically.) This transactio
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/transactors/Payment.cpp)
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType" : "Payment",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Fee": "12",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | The amount of currency to deliver. For non-XAH amounts, the nested field names MUST be lower-case. If the `tfPartialPayment` flag is set, deliver _up to_ this amount instead. |
|
||||
| `Destination` | String | AccountID | The unique address of the account receiving the payment. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag that identifies the reason for the payment to the destination, or a hosted recipient to pay. |
|
||||
| `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this payment. |
|
||||
| `Paths` | Array of path arrays | PathSet | (Optional, auto-fillable) Array of payment paths to be used for this transaction. Must be omitted for XAH-to-XAH transactions. |
|
||||
| `SendMax` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Optional)_ Highest amount of source currency this transaction is allowed to cost, including transfer fees, exchange rates, and [slippage](http://en.wikipedia.org/wiki/Slippage_\(finance\)). Does not include the XAH destroyed as a cost for submitting the transaction. For non-XAH amounts, the nested field names MUST be lower-case. Must be supplied for cross-currency/cross-issue payments. Must be omitted for XAH-to-XAH payments. |
|
||||
| `DeliverMin` | \[Currency Amount]\[] | Amount | _(Optional)_ Minimum amount of destination currency this transaction should deliver. Only valid if this is a partial payment. For non-XAH amounts, the nested field names are lower-case. |
|
||||
|
||||
### Types of Payments
|
||||
|
||||
The Payment transaction type is a general-purpose tool that can represent several different types of abstract actions. You can identify the transaction type based on the transaction's fields, as described in the table below:
|
||||
|
||||
| Payment type | `Amount` | `SendMax` | `Paths` | `Address` = `Destination`? | Description |
|
||||
| ---------------------------- | ------------------------------- | ------------------------------- | ---------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Direct XAH-to-XAH Payment | String (XAH) | Omitted | Omitted | No | Transfers XAH directly from one account to another. Always delivers the exact amount. No fee applies other than the basic transaction cost. |
|
||||
| Creating or redeeming tokens | Object | Object (optional) | Optional | No | Increases or decreases the amount of a non-XAH currency or asset tracked in Xahau. Transfer fees and freezes do not apply when sending and redeeming directly. |
|
||||
| Cross-currency Payment | Object (non-XAH) / String (XAH) | Object (non-XAH) / String (XAH) | Usually required | No | Send tokens from one holder to another. The `Amount` or `SendMax` can be XAH or tokens, but they cannot both be XAH. These payments ripple through the issuer and can take longer paths through several intermediaries if the transaction specifies a path set. Transfer fees set by the issuer(s) apply to this type of transaction. These transactions consume offers in the decentralized exchange to connect between different currencies, or possibly even between currencies with the same currency code and different issuers. |
|
||||
| Partial payment | Object (non-XAH) / String (XAH) | Object (non-XAH) / String (XAH) | Usually required | No | Sends _up to_ a specific amount of any currency. Uses the `tfPartialPayment` flag. May include a `DeliverMin` amount specifying the minimum that the transaction must deliver to be successful; if the transaction does not specify `DeliverMin`, it can succeed by delivering _any positive amount_. |
|
||||
| Currency conversion | Object (non-XAH) / String (XAH) | Object (non-XAH) / String (XAH) | Required | Yes | Consumes offers in the decentralized exchange to convert one currency to another, possibly taking [arbitrage](https://en.wikipedia.org/wiki/Arbitrage) opportunities. The `Amount` and `SendMax` cannot both be XAH. Also called a _circular payment_ because it delivers money to the sender. The Data API tracks this type of transaction as an "exchange" and not a "payment". |
|
||||
|
||||
### Special issuer Values for SendMax and Amount
|
||||
|
||||
Most of the time, the `issuer` field of a non-XAH \[Currency Amount]\[] indicates the issuer of a token. However, when describing payments, there are special rules for the `issuer` field in the `Amount` and `SendMax` fields of a payment.
|
||||
|
||||
* There is only ever one balance between two addresses for the same currency code. This means that, sometimes, the `issuer` field of an amount actually refers to a counterparty, instead of the address that issued the token.
|
||||
* When the `issuer` field of the destination `Amount` field matches the `Destination` address, it is treated as a special case meaning "any issuer that the destination accepts." This includes all addresses to which the destination has trust lines with a positive limit, as well as tokens with the same currency code issued by the destination.
|
||||
* When the `issuer` field of the `SendMax` field matches the source account's address, it is treated as a special case meaning "any issuer that the source can use." This includes creating new tokens on trust lines that other accounts have extended to the source account, and sending tokens the source account holds from other issuers.
|
||||
|
||||
### Creating Accounts
|
||||
|
||||
The Payment transaction type can create new accounts in Xahau by sending enough XAH to an unfunded address. Other transactions to unfunded addresses always fail.
|
||||
|
||||
For more information, see Accounts.
|
||||
|
||||
### Paths
|
||||
|
||||
If present, the `Paths` field must contain a _path set_ - an array of path arrays. Each individual path represents one way value can flow from the sender to receiver through various intermediary accounts and order books. A single transaction can potentially use multiple paths, for example if the transaction exchanges currency using several different order books to achieve the best rate.
|
||||
|
||||
You must omit the `Paths` field for direct payments, including:
|
||||
|
||||
* An XAH-to-XAH transfer.
|
||||
* A direct transfer on a trust line that connects the sender and receiver.
|
||||
|
||||
If the `Paths` field is provided, the server decides at transaction processing time which paths to use, from the provided set plus a _default path_ (the most direct way possible to connect the specified accounts). This decision is deterministic and attempts to minimize costs, but it is not guaranteed to be perfect.
|
||||
|
||||
The `Paths` field must not be an empty array, nor an array whose members are all empty arrays.
|
||||
|
||||
For more information, see Paths.
|
||||
|
||||
### Payment Flags
|
||||
|
||||
Transactions of the Payment type support additional values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| ------------------ | ------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `tfNoDirectRipple` | `0x00010000` | 65536 | Do not use the default path; only use paths included in the `Paths` field. This is intended to force the transaction to take arbitrage opportunities. Most clients do not need this. |
|
||||
| `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 for more details. |
|
||||
| `tfLimitQuality` | `0x00040000` | 262144 | Only take paths where all the conversions have an input:output ratio that is equal or better than the ratio of `Amount`:`SendMax`. See Limit Quality for details. |
|
||||
|
||||
### Partial Payments
|
||||
|
||||
A partial payment allows a payment to succeed by reducing the amount received. Partial payments are useful for returning payments without incurring additional costs to oneself. However, partial payments can also be used to exploit integrations that naively assume the `Amount` field of a successful transaction always describes the exact amount delivered.
|
||||
|
||||
A partial payment is any \[Payment transaction]\[] with the `tfPartialPayment` flag enabled. A partial payment can be successful if it delivers any positive amount greater than or equal to its `DeliverMin` field (or any positive amount at all if `DeliverMin` is not specified) without sending more than the `SendMax` value.
|
||||
|
||||
The `delivered_amount` field of a payment's metadata indicates the amount of currency actually received by the destination account.
|
||||
|
||||
For more information, see the full article on Partial Payments.
|
||||
|
||||
### Limit Quality
|
||||
|
||||
Xahau defines the "quality" of a currency exchange as the ratio of the numeric amount in to the numeric amount out. For example, if you spend $2 USD to receive £1 GBP, then the "quality" of that exchange is `0.5`.
|
||||
|
||||
The `tfLimitQuality` flag allows you to set a minimum quality of conversions that you are willing to take. This limit quality is defined as the destination `Amount` divided by the `SendMax` amount (the numeric amounts only, regardless of currency). When set, the payment processing engine avoids using any paths whose quality (conversion rate) is worse (numerically lower) than the limit quality.
|
||||
|
||||
By itself, the `tfLimitQuality` flag reduces the number of situations in which a transaction can succeed. Specifically, it rejects payments where some part of the payment uses an unfavorable conversion, even if the overall _average_ quality of conversions in the payment is equal or better than the limit quality. If a payment is rejected in this way, the transaction result is `tecPATH_DRY`.
|
||||
|
||||
Consider the following example. If I am trying to send you 100 Chinese Yuan (`Amount` = 100 CNY) for 20 United States dollars (`SendMax` = 20 USD) or less, then the limit quality is `5`. Imagine one trader is offering ¥95 for $15 (a ratio of about `6.3` CNY per USD), but the next best offer in the market is ¥5 for $2 (a ratio of `2.5` CNY per USD). If I were to take both offers to send you 100 CNY, then it would cost me 17 USD, for an average quality of about `5.9`.
|
||||
|
||||
Without the `tfLimitQuality` flag set, this transaction would succeed, because the $17 it costs me is within my specified `SendMax`. However, with the `tfLimitQuality` flag enabled, the transaction would fail instead, because the path to take the second offer has a quality of `2.5`, which is worse than the limit quality of `5`.
|
||||
|
||||
The `tfLimitQuality` flag is most useful when combined with partial payments. When both `tfPartialPayment` and `tfLimitQuality` are set on a transaction, then the transaction delivers as much of the destination `Amount` as it can, without using any conversions that are worse than the limit quality.
|
||||
|
||||
In the above example with a ¥95/$15 offer and a ¥5/$2 offer, the situation is different if my transaction has both `tfPartialPayment` and `tfLimitQuality` enabled. If we keep my `SendMax` of 20 USD and a destination `Amount` of 100 CNY, then the limit quality is still `5`. However, because I am doing a partial payment, the transaction sends as much as it can instead of failing if the full destination amount cannot be sent. This means that my transaction consumes the ¥95/$15 offer, whose quality is about `6.3`, but it rejects the ¥5/$2 offer because that offer's quality of `2.5` is worse than the quality limit of `5`. In the end, my transaction only delivers ¥95 instead of the full ¥100, but it avoids wasting money on poor exchange rates.
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: PaymentChannelClaim
|
||||
description: >-
|
||||
Claim Amount from a payment channel, adjust the payment channel's expiration,
|
||||
or both. This transaction can be used differently depending on the transaction
|
||||
sender's role in the specified channel:
|
||||
---
|
||||
[\[Source\]](https://github.com/ripple/rippled/blob/master/src/ripple/app/tx/impl/PayChan.cpp)
|
||||
|
||||
_Added by the \[PayChan amendment]\[]._
|
||||
|
||||
The **source address** of a channel can:
|
||||
|
||||
* Send Amount from the channel to the destination with _or without_ a signed Claim.
|
||||
* Set the channel to expire as soon as the channel's `SettleDelay` has passed.
|
||||
* Clear a pending `Expiration` time.
|
||||
* Close a channel immediately, with or without processing a claim first. The source address cannot close the channel immediately if the channel has Amount remaining.
|
||||
|
||||
The **destination address** of a channel can:
|
||||
|
||||
* Receive Amount from the channel using a signed Claim.
|
||||
* Close the channel immediately after processing a Claim, refunding any unclaimed Amount to the channel's source.
|
||||
|
||||
**Any address** sending this transaction can:
|
||||
|
||||
* Cause a channel to be closed if its `Expiration` or `CancelAfter` time is older than the previous ledger's close time. Any validly-formed PaymentChannelClaim transaction has this effect regardless of the contents of the transaction.
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"Channel": "C1AE6DDDEEC05CF2978C0BAD6FE302948E9533691DC749DCDD3B9E5992CA6198",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Signature": "30440220718D264EF05CAED7C781FF6DE298DCAC68D002562C9BF3A07C1E721B420C0DAB02203A5A4779EF4D2CCC7BC3EF886676D803A9981B928D3B8ACA483B80ECA3CD7B9B",
|
||||
"PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Channel` | String | Hash256 | The unique ID of the channel, as a 64-character hexadecimal string. |
|
||||
| `Balance` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Optional)_ Total amount delivered by this channel after processing this claim. Required to deliver Amount. Must be more than the total amount delivered by the channel so far, but not greater than the `Amount` of the signed claim. Must be provided except when closing the channel. |
|
||||
| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | _(Optional)_ The amount authorized by the `Signature`. This must match the amount in the signed message. This is the cumulative amount of Amount that can be dispensed by the channel, including XAH previously redeemed. |
|
||||
| `Signature` | String | Blob | _(Optional)_ The signature of this claim, as hexadecimal. The signed message contains the channel ID and the amount of the claim. Required unless the sender of the transaction is the source address of the channel. |
|
||||
| `PublicKey` | String | Blob | _(Optional)_ The public key used for the signature, as hexadecimal. This must match the `PublicKey` stored in the ledger for the channel. Required unless the sender of the transaction is the source address of the channel and the `Signature` field is omitted. (The transaction includes the public key so that `rippled` can check the validity of the signature before trying to apply the transaction to the ledger.) |
|
||||
|
||||
If the payment channel was created before the fixPayChanRecipientOwnerDir amendment became enabled (on 2020-05-01), it is possible that the destination of the payment channel has been deleted and does not currently exist in the ledger. If the destination has been deleted, the source account cannot send XAH from the channel to the destination; instead, the transaction fails with `tecNO_DST`. (And, of course, the deleted account cannot send any transactions at all.) Other uses of this transaction type are unaffected when the destination account has been deleted, including adjusting the channel expiration, closing a channel with no Amount, or removing a channel that has passed its expiration time.
|
||||
|
||||
### PaymentChannelClaim Flags
|
||||
|
||||
Transactions of the PaymentChannelClaim type support additional values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| --------- | ------------ | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `tfRenew` | `0x00010000` | 65536 | Clear the channel's `Expiration` time. (`Expiration` is different from the channel's immutable `CancelAfter` time.) Only the source address of the payment channel can use this flag. |
|
||||
| `tfClose` | `0x00020000` | 131072 | Request to close the channel. Only the channel source and destination addresses can use this flag. This flag closes the channel immediately if it has no more Amount allocated to it after processing the current claim, or if the destination address uses it. If the source address uses this flag when the channel still holds an Amount, this schedules the channel to close after `SettleDelay` seconds have passed. (Specifically, this sets the `Expiration` of the channel to the close time of the previous ledger plus the channel's `SettleDelay` time, unless the channel already has an earlier `Expiration` time.) If the destination address uses this flag when the channel still holds an Amount, any Amount that remains after processing the claim is returned to the source address. |
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: PaymentChannelCreate
|
||||
description: >-
|
||||
Create a payment channel and fund it with an Amount. The address sending this
|
||||
transaction becomes the "source address" of the payment channel.
|
||||
---
|
||||
[\[Source\]](https://github.com/Xahau/xahaud/blob/master/src/ripple/app/tx/impl/PayChan.cpp)
|
||||
|
||||
_Added by the \[PayChan amendment]\[]._
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"TransactionType": "PaymentChannelCreate",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Destination": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"SettleDelay": 86400,
|
||||
"PublicKey": "32D2471DB72B27E3310F355BB33E339BF26F8392D5A93D3BC0FC3B566612DA0F0A",
|
||||
"CancelAfter": 533171558,
|
||||
"DestinationTag": 23480,
|
||||
"SourceTag": 11747
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | Amount to deduct from the sender's balance and set aside in this channel. While the channel is open, the Amount can only go to the `Destination` address. When the channel closes, any unclaimed Amount is returned to the source address's balance. |
|
||||
| `Destination` | String | AccountID | Address to receive claims against this channel. This is also known as the "destination address" for the channel. Cannot be the same as the sender (`Account`). |
|
||||
| `SettleDelay` | Number | UInt32 | Amount of time the source address must wait before closing the channel if it has unclaimed Amount. |
|
||||
| `PublicKey` | String | Blob | The 33-byte public key of the key pair the source will use to sign claims against this channel, in hexadecimal. This can be any secp256k1 or Ed25519 public key. For more information on key pairs, see Key Derivation |
|
||||
| `CancelAfter` | Number | UInt32 | _(Optional)_ The time, in \[seconds since the Ripple Epoch]\[], when this channel expires. Any transaction that would modify the channel after this time closes the channel without otherwise affecting it. This value is immutable; the channel can be closed earlier than this time but cannot remain open after this time. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ Arbitrary tag to further specify the destination for this payment channel, such as a hosted recipient at the destination address. |
|
||||
|
||||
If the `Destination` account is blocking incoming payment channels, the transaction fails with result code `tecNO_PERMISSION`. _(Requires the \[DisallowIncoming amendment]\[] :not_enabled:)_
|
||||
@@ -1,119 +0,0 @@
|
||||
---
|
||||
title: Remit
|
||||
description: >-
|
||||
The Remit transaction allows the user to send multiple payment types, mint a
|
||||
URIToken, transfer a list of URITokens and activate an account.
|
||||
---
|
||||
import { Aside } from '@astrojs/starlight/components';
|
||||
|
||||
<Aside type="caution">
|
||||
The Remit transaction pays all fees for _Account Activation, Trustlines and URIToken Reserves._
|
||||
</Aside>
|
||||
|
||||
\[[Source](https://github.com/Xahau/xahaud/blob/dev/src/ripple/app/tx/impl/Remit.cpp)]
|
||||
|
||||
_(Added by the \[Remit amendment]\[].)_
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"TransactionType": "Remit",
|
||||
"Account": "rGvbdrdCxG2tk9ZU2673XmsjRdHCDQEpt7",
|
||||
"Amounts": [
|
||||
{
|
||||
"AmountEntry": {
|
||||
"Amount": "1000000"
|
||||
}
|
||||
}, {
|
||||
"AmountEntry": {
|
||||
"Amount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rExKpRKXNz25UAjbckCRtQsJFcSfjL9Er3",
|
||||
"value": "1"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"Destination": "rG1QQv2nh2gr7RCZ1P8YYcBUKCCN633jCn",
|
||||
"URITokenIDs": [
|
||||
"714F206C865D334721B2F3388BEAF33AA91BC1D78C71941D10A2A653C873EDD3"
|
||||
],
|
||||
"MintURIToken": {
|
||||
"Digest": "6F11A4DF4EE794E2800BB361173D454BFBECB3D7506C4F4CB0EC5AE98BE43747",
|
||||
"Flags": 1,
|
||||
"URI": "697066733A2F2F"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| ---------------- | --------- | ------------------- | ---------------------------------------------------------------------------------------------------------------- |
|
||||
| `Account` | String | AccountID | The address of the account that will activate the account, send the payment and/or mint/transfer the URIToken/s. |
|
||||
| `Destination` | String | AccountID | The unique address of the account receiving the payment and/or URIToken/s. |
|
||||
| `DestinationTag` | Number | UInt32 | _(Optional)_ A DestinationTag for deposits to a shared custody account. |
|
||||
| `MintURIToken` | Object | STObject | _(Optional)_ A `MintURIToken` STObject containing the URIToken details you want to mint on the `Destination`. |
|
||||
| `URITokenIDs` | Array | STArray | _(Optional)_ An array of URITokenIDs (256-bit hash) to to be transferred to the `Destination`. _Limit 32._ |
|
||||
| `Amounts` | Array | STArray | _(Optional)_ An array of `AmountEntry` STObjects the account wants to send to the `Destination`. _Limit 32._ |
|
||||
| `Inform` | String | AccountID | _(Optional)_ A unique address of an account that can have a hook installed and be informed when a remit occurs. |
|
||||
| `Blob` | String | Blob | _(Optional)_ Arbitrary hex value that can be added to the tx for use in Hooks. |
|
||||
| `InvoiceID` | String | Hash256 | _(Optional)_ Arbitrary 256-bit hash representing a specific reason or identifier for this remit. |
|
||||
|
||||
### AmountEntry Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| -------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------- |
|
||||
| `Amount` | [Currency Amount](/docs/protocol-reference/data-types/currency-formats/#specifying-currency-amounts) | Amount | The amount of currency the account wants to send to the `Destination`. |
|
||||
|
||||
### MintURIToken Fields
|
||||
|
||||
| Field | JSON Type | \[Internal Type]\[] | Description |
|
||||
| -------- | --------- | ------------------- | ----------------------------------------------------------- |
|
||||
| `URI` | String | String | The URI associated with the minted URIToken. (256 byte max) |
|
||||
| `Digest` | String | Hash256 | _(Optional)_ The digest of the URIToken. |
|
||||
| `Flags` | Number | UInt32 | _(Optional)_ Flags on the mint transaction |
|
||||
|
||||
### MintURIToken Flags
|
||||
|
||||
The `MintURIToken` STObject supports the values in the `Flags` field, as follows:
|
||||
|
||||
| Flag Name | Hex Value | Decimal Value | Description |
|
||||
| ------------ | ------------ | ------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| `tfBurnable` | `0x00000001` | 1 | Allow the issuer to destroy the minted `URIToken`. (The `URIToken`'s owner can _always_ do so.) |
|
||||
|
||||
### Special Transaction Cost
|
||||
|
||||
The Remit transaction has a standard transaction cost, which is the minimum fee required for any transaction in Xahau.
|
||||
|
||||
In addition to the minimum fee required the Remit transaction will also deduct the fees for the following:
|
||||
|
||||
| Action | Fee |
|
||||
| -------------------- | ---------------------------- |
|
||||
| `Account Activation` | Standard Reserve Requirement |
|
||||
| `Create Trustline` | Standard Reserve Requirement |
|
||||
| `URIToken Mint` | Standard Reserve Requirement |
|
||||
| `URIToken Transfer` | Standard Reserve Requirement |
|
||||
|
||||
### Error Cases
|
||||
|
||||
Besides errors that can occur for all transactions, Remit transactions can result in the following transaction result codes:
|
||||
|
||||
| Error Code | Description |
|
||||
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `temINVALID_FLAG` | Occurs if any flag is specific `tfFullyCanonicalSig` |
|
||||
| `temREDUNDANT` | Occurs if the Account is the same as the Destination |
|
||||
| `temMALFORMED (Inform & Blob)` | Occurs when; sfInform is same as " "source or destination. Blob was more than 128kib. |
|
||||
| `temMALFORMED (AmountEntry)` | Occurs when; AmountEntry count exceeds `32.` Expected AmountEntry. Native Currency appears more than once. Issued Currency appears more than once. |
|
||||
| `temMALFORMED (MintURIToken)` | Occurs when; sfMintURIToken contains invalid field. URI was not provided. URI was too long/short. Invalid UTF8 inside MintURIToken. |
|
||||
| `temMALFORMED (URITokenIDs)` | Occurs when; URITokenIDs too short/long. Duplicate URITokenID. |
|
||||
| `temBAD_AMOUNT` | Occurs when an Amount in the AmountEntry is invalid. |
|
||||
| `terNO_ACCOUNT` | Occurs when the source account does not exist. |
|
||||
| `tecNO_TARGET` | Occurs when the `sfInform` field is present but the account does not exist. |
|
||||
| `tecNO_PERMISSION` | Occurs when `disallowIncomingRemit` is enabled on the `Destination` |
|
||||
| `tecNO_PERMISSION` | Occurs when the `Destination` has `DepositAuthorization` enabled. |
|
||||
| `tecDST_TAG_NEEDED` | Occurs if the destination account requires a destination tag, but the transaction does not include one. |
|
||||
| `tecDUPLICATE` | Occurs when the `MintURIToken` URI from that issuer already exists. |
|
||||
| `tecDIR_FULL` | Occurs when the source or destination accouts directory is full. |
|
||||
| `tecNO_ENTRY` | Occurs when the URIToken does not exist. |
|
||||
| `tecNO_PERMISSION` | Occurs when the URIToken is not owned by the source account. |
|
||||
| `tecUNFUNDED_PAYMENT` | Occurs when the source account does not have the required funds to execute the transaction. (XAH or Issued Currencies) |
|
||||
|
Before Width: | Height: | Size: 98 KiB After Width: | Height: | Size: 98 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user